Cassandra教程FG010-Cassandra数据一致性级别配置实战
本文档风哥主要介绍Cassandra数据库数据一致性级别配置实战,包括一致性概述、一致性级别详解、CAP理论、一致性级别选择策略、一致性与性能权衡、一致性场景分析、一致性级别配置实战、查询一致性配置实战、一致性监控实战、金融场景一致性实战、社交场景一致性实战、IoT场景一致性实战等内容,风哥教程参考Cassandra官方文档Consistency内容编写,适合DBA人员和开发人员在学习和测试中使用,如果要应用于生产环境则需要自行确认。
Part01-基础概念与理论知识
1.1 Cassandra数据库一致性概述
Cassandra数据库采用最终一致性模型,通过可调一致性级别来平衡一致性和可用性。一致性级别决定了读写操作需要多少副本确认才算成功。更多视频教程www.fgedu.net.cn
1.1.1 Cassandra数据库一致性特点
# 1. 可调一致性
– 一致性级别可配置
– 读写可分别设置
– 支持动态调整
# 2. 最终一致性
– 数据最终达到一致状态
– 适合高可用场景
– 支持冲突解决
# 3. 副本因子影响
– 副本因子决定数据副本数
– 一致性级别决定确认数
– 两者共同决定一致性强度
# 4. 一致性级别类型
– 写一致性级别
– 读一致性级别
– 序列化一致性级别
# 一致性级别与副本因子关系
一致性级别 ≤ 副本因子
# 示例
副本因子 = 3
可用一致性级别: ONE, TWO, THREE, QUORUM, ALL
# 一致性保证
强一致性: W + R > N
– W: 写一致性级别
– R: 读一致性级别
– N: 副本因子
# 示例
N = 3, W = 2, R = 2
W + R = 4 > 3 = N
→ 强一致性保证
1.1.2 Cassandra数据库一致性模型
# 1. 强一致性
– 读写操作立即对所有节点可见
– 需要较高的一致性级别
– 性能较低
# 配置
写一致性: QUORUM 或 ALL
读一致性: QUORUM 或 ALL
# 2. 最终一致性
– 读写操作最终对所有节点可见
– 可使用较低的一致性级别
– 性能较高
# 配置
写一致性: ONE 或 ANY
读一致性: ONE
# 3. 因果一致性
– 保证因果关系的操作顺序
– 使用轻量级事务实现
– 性能开销较大
# 4. 单调读一致性
– 保证读取不会看到旧数据
– 使用较高读一致性级别
# 一致性级别选择原则
1. 根据业务需求选择
2. 平衡一致性和性能
3. 考虑网络延迟
4. 考虑节点故障容忍度
1.2 Cassandra数据库一致性级别详解
Cassandra数据库一致性级别详解:
1.2.1 Cassandra数据库写一致性级别
# 1. ANY
– 数据写入至少一个节点(可以是Hint)
– 最高可用性
– 最低一致性
– 适合高可用写入场景
# 特点
– 如果目标节点不可用,写入Hint
– 保证写入成功
– 可能暂时不可读
# 2. ONE / TWO / THREE
– 数据写入指定数量的副本
– ONE: 写入1个副本
– TWO: 写入2个副本
– THREE: 写入3个副本
# 特点
– 平衡性能和一致性
– 常用级别
– 适合大多数场景
# 3. QUORUM
– 数据写入多数副本
– QUORUM = floor(副本因子/2) + 1
# 示例
副本因子 = 3, QUORUM = 2
副本因子 = 5, QUORUM = 3
# 特点
– 强一致性保证(配合读QUORUM)
– 常用于关键数据
# 4. LOCAL_QUORUM
– 数据写入本地数据中心多数副本
– 适合多数据中心场景
# 特点
– 避免跨数据中心延迟
– 保证本地一致性
– 常用于多数据中心
# 5. EACH_QUORUM
– 数据写入每个数据中心的多数副本
– 最高一致性保证
# 特点
– 保证每个数据中心一致性
– 延迟较高
– 适合关键数据
# 6. ALL
– 数据写入所有副本
– 最高一致性
– 最低可用性
# 特点
– 任何一个节点故障则写入失败
– 适合关键配置数据
1.2.2 Cassandra数据库读一致性级别
# 1. ONE / TWO / THREE
– 从指定数量的副本读取
– ONE: 从1个副本读取
– TWO: 从2个副本读取
– THREE: 从3个副本读取
# 特点
– 性能最好
– 可能读到旧数据
– 适合非关键数据
# 2. QUORUM
– 从多数副本读取
– QUORUM = floor(副本因子/2) + 1
# 特点
– 配合写QUORUM保证强一致性
– 平衡性能和一致性
– 常用于关键数据
# 3. LOCAL_QUORUM
– 从本地数据中心多数副本读取
– 适合多数据中心场景
# 特点
– 避免跨数据中心延迟
– 保证本地一致性
– 常用于多数据中心
# 4. LOCAL_ONE
– 从本地数据中心1个副本读取
– 性能最好
# 特点
– 最低延迟
– 可能读到旧数据
– 适合非关键数据
# 5. ALL
– 从所有副本读取
– 最高一致性
– 最低性能
# 特点
– 任何一个节点故障则读取失败
– 保证读到最新数据
– 适合关键配置数据
# 一致性级别对比表
级别 | 写入确认数 | 读取确认数 | 性能 | 一致性 | 可用性
————–|——————-|——————-|——|——–|——–
ANY | 1 (含Hint) | – | 最高 | 最低 | 最高
ONE | 1 | 1 | 高 | 低 | 高
TWO | 2 | 2 | 中 | 中 | 中
QUORUM | floor(N/2)+1 | floor(N/2)+1 | 中 | 高 | 中
LOCAL_QUORUM | 本地多数 | 本地多数 | 中 | 高 | 中
ALL | N | N | 最低 | 最高 | 最低
1.3 Cassandra数据库CAP理论
Cassandra数据库CAP理论详解:
1.3.1 Cassandra数据库CAP理论说明
# 1. CAP定义
– Consistency (一致性)
– Availability (可用性)
– Partition Tolerance (分区容错)
# 2. CAP定理
在分布式系统中,最多只能同时满足CAP中的两项
# 3. 系统分类
# CA系统
– 一致性 + 可用性
– 不支持分区容错
– 示例: 传统关系型数据库
# CP系统
– 一致性 + 分区容错
– 可能牺牲可用性
– 示例: HBase, MongoDB
# AP系统
– 可用性 + 分区容错
– 可能牺牲一致性
– 示例: Cassandra, DynamoDB
# 4. Cassandra选择
Cassandra是AP系统
– 优先保证可用性
– 支持分区容错
– 通过可调一致性平衡一致性
# 5. Cassandra如何平衡
– 可调一致性级别
– 最终一致性模型
– 支持强一致性配置
1.3.2 Cassandra数据库一致性权衡
# 1. 一致性 vs 可用性
– 高一致性 → 低可用性
– 低一致性 → 高可用性
# 示例
ALL一致性: 任何一个节点故障则操作失败
ONE一致性: 只要有一个节点可用则操作成功
# 2. 一致性 vs 性能
– 高一致性 → 低性能
– 低一致性 → 高性能
# 示例
QUORUM一致性: 需要等待多数节点响应
ONE一致性: 只需等待一个节点响应
# 3. 一致性 vs 延迟
– 高一致性 → 高延迟
– 低一致性 → 低延迟
# 示例
跨数据中心QUORUM: 需要等待跨数据中心响应
LOCAL_QUORUM: 只需等待本地数据中心响应
# 4. 权衡策略
– 根据业务需求选择
– 不同场景使用不同级别
– 动态调整一致性级别
# 5. 最佳实践
– 关键数据: QUORUM或更高
– 普通数据: ONE或LOCAL_QUORUM
– 非关键数据: ONE或ANY
Part02-生产环境规划与建议
2.1 Cassandra数据库一致性级别选择策略
Cassandra数据库一致性级别选择策略详解:
2.1.1 Cassandra数据库一致性级别选择原则
# 1. 根据数据重要性选择
# 关键数据
– 金融交易: QUORUM或ALL
– 用户认证: QUORUM
– 配置数据: QUORUM或ALL
# 普通数据
– 用户资料: LOCAL_QUORUM
– 订单数据: QUORUM
– 日志数据: ONE
# 非关键数据
– 统计数据: ONE
– 缓存数据: ONE
– 临时数据: ANY
# 2. 根据读写模式选择
# 读多写少
– 写一致性: QUORUM
– 读一致性: ONE
# 写多读少
– 写一致性: ONE
– 读一致性: QUORUM
# 读写均衡
– 写一致性: QUORUM
– 读一致性: QUORUM
# 3. 根据网络环境选择
# 单数据中心
– 写一致性: QUORUM
– 读一致性: QUORUM
# 多数据中心
– 写一致性: LOCAL_QUORUM
– 读一致性: LOCAL_QUORUM
# 跨数据中心强一致
– 写一致性: EACH_QUORUM
– 读一致性: QUORUM
# 4. 根据性能要求选择
# 高性能要求
– 写一致性: ONE
– 读一致性: ONE
# 高一致性要求
– 写一致性: QUORUM
– 读一致性: QUORUM
2.1.2 Cassandra数据库一致性级别推荐配置
# 1. 金融场景
# 交易数据
写一致性: QUORUM
读一致性: QUORUM
副本因子: 5
# 账户余额
写一致性: ALL
读一致性: QUORUM
副本因子: 3
# 2. 电商场景
# 订单数据
写一致性: QUORUM
读一致性: QUORUM
副本因子: 3
# 商品信息
写一致性: LOCAL_QUORUM
读一致性: LOCAL_QUORUM
副本因子: 3
# 购物车
写一致性: ONE
读一致性: ONE
副本因子: 3
# 3. 社交场景
# 用户资料
写一致性: QUORUM
读一致性: ONE
副本因子: 3
# 好友关系
写一致性: QUORUM
读一致性: QUORUM
副本因子: 3
# 动态消息
写一致性: ONE
读一致性: ONE
副本因子: 3
# 4. IoT场景
# 设备数据
写一致性: ONE
读一致性: ONE
副本因子: 3
# 告警数据
写一致性: QUORUM
读一致性: ONE
副本因子: 3
# 统计数据
写一致性: ANY
读一致性: ONE
副本因子: 3
2.2 Cassandra数据库一致性与性能权衡
Cassandra数据库一致性与性能权衡详解:
2.2.1 Cassandra数据库一致性性能影响
# 1. 写入性能
一致性级别 | 相对性能 | 延迟(ms) | 说明
———-|———-|———-|——————
ANY | 100% | 1-5 | 最高性能
ONE | 90% | 2-10 | 高性能
TWO | 70% | 5-20 | 中等性能
QUORUM | 50% | 10-50 | 中等性能
ALL | 30% | 20-100 | 低性能
# 2. 读取性能
一致性级别 | 相对性能 | 延迟(ms) | 说明
———-|———-|———-|——————
ONE | 100% | 1-5 | 最高性能
TWO | 70% | 5-20 | 中等性能
QUORUM | 50% | 10-50 | 中等性能
ALL | 30% | 20-100 | 低性能
# 3. 性能测试结果
# 测试环境: 3节点集群, 副本因子=3
# 写入性能测试
cassandra-stress write n=100000
-col size=FIXED(100)
-rate threads=50
-cl ONE
结果:
– ONE: 50000 ops/s, 延迟 1ms
– QUORUM: 30000 ops/s, 延迟 2ms
– ALL: 15000 ops/s, 延迟 5ms
# 读取性能测试
cassandra-stress read n=100000
-col size=FIXED(100)
-rate threads=50
-cl ONE
结果:
– ONE: 80000 ops/s, 延迟 0.5ms
– QUORUM: 40000 ops/s, 延迟 1.5ms
– ALL: 20000 ops/s, 延迟 3ms
# 4. 性能优化建议
– 根据业务需求选择合适的一致性级别
– 使用LOCAL_QUORUM避免跨数据中心延迟
– 批量操作使用较低一致性级别
– 监控性能指标及时调整
2.2.2 Cassandra数据库一致性可用性影响
# 1. 写入可用性
副本因子=3, 节点故障容忍度
一致性级别 | 可容忍故障节点数 | 可用性
———-|——————|——–
ANY | 3 (全部) | 最高
ONE | 2 | 高
TWO | 1 | 中
QUORUM | 1 | 中
ALL | 0 | 最低
# 2. 读取可用性
副本因子=3, 节点故障容忍度
一致性级别 | 可容忍故障节点数 | 可用性
———-|——————|——–
ONE | 2 | 高
TWO | 1 | 中
QUORUM | 1 | 中
ALL | 0 | 最低
# 3. 可用性计算
# 公式
可容忍故障节点数 = 副本因子 – 一致性级别
# 示例
副本因子=5
– ONE: 可容忍4个节点故障
– QUORUM(3): 可容忍2个节点故障
– ALL: 可容忍0个节点故障
# 4. 可用性优化建议
– 关键数据使用QUORUM保证一致性
– 非关键数据使用ONE保证可用性
– 多数据中心使用LOCAL_QUORUM
– 监控节点状态及时处理故障
2.3 Cassandra数据库一致性场景分析
Cassandra数据库一致性场景分析:
2.3.1 Cassandra数据库典型场景一致性配置
# 场景1: 用户认证
# 需求: 强一致性,高可用性
# 配置
Keyspace:
replication = {‘class’: ‘NetworkTopologyStrategy’, ‘dc1’: 3}
写一致性: QUORUM
读一致性: QUORUM
# 说明
– 用户密码必须强一致
– 使用QUORUM平衡一致性和可用性
– 可容忍1个节点故障
# 场景2: 购物车
# 需求: 高可用性,最终一致性
# 配置
Keyspace:
replication = {‘class’: ‘NetworkTopologyStrategy’, ‘dc1’: 3}
写一致性: ONE
读一致性: ONE
# 说明
– 购物车数据可容忍短暂不一致
– 优先保证写入成功
– 高可用性
# 场景3: 商品库存
# 需求: 强一致性,防止超卖
# 配置
Keyspace:
replication = {‘class’: ‘NetworkTopologyStrategy’, ‘dc1’: 3}
写一致性: QUORUM
读一致性: QUORUM
使用轻量级事务
# 说明
– 库存必须准确
– 使用LWT保证原子性
– 性能较低但一致性高
# 场景4: 用户动态
# 需求: 高写入性能,最终一致性
# 配置
Keyspace:
replication = {‘class’: ‘NetworkTopologyStrategy’, ‘dc1’: 3}
写一致性: ONE
读一致性: ONE
# 说明
– 动态数据量大
– 可容忍短暂不一致
– 优先保证写入性能
# 场景5: 设备数据
# 需求: 高写入性能,最终一致性
# 配置
Keyspace:
replication = {‘class’: ‘NetworkTopologyStrategy’, ‘dc1’: 3}
写一致性: ONE
读一致性: ONE
# 说明
– IoT设备数据量大
– 可容忍短暂不一致
– 优先保证写入性能
Part03-生产环境项目实施方案
3.1 Cassandra数据库一致性级别配置实战
Cassandra数据库一致性级别配置实战:
3.1.1 Cassandra数据库全局一致性配置
# cqlsh 192.168.1.101 9042 -u fgedu -p Fgedu@2024
Connected to fgedu_cluster at 192.168.1.101:9042
# 查看当前一致性级别
cqlsh> CONSISTENCY
Current consistency level is ONE.
# 查看序列化一致性级别
cqlsh> SERIAL CONSISTENCY
Current serial consistency level is SERIAL.
# 设置全局写一致性级别
cqlsh> CONSISTENCY QUORUM
Consistency level set to QUORUM.
# 设置序列化一致性级别
cqlsh> SERIAL CONSISTENCY LOCAL_SERIAL
Serial consistency level set to LOCAL_SERIAL.
# 验证配置
cqlsh> CONSISTENCY
Current consistency level is QUORUM.
cqlsh> SERIAL CONSISTENCY
Current serial consistency level is LOCAL_SERIAL.
# 一致性级别配置说明
# 写一致性级别
CONSISTENCY ANY # 最低一致性
CONSISTENCY ONE # 常用级别
CONSISTENCY TWO # 中等一致性
CONSISTENCY THREE # 较高一致性
CONSISTENCY QUORUM # 强一致性
CONSISTENCY LOCAL_QUORUM # 本地强一致性
CONSISTENCY EACH_QUORUM # 跨数据中心强一致性
CONSISTENCY ALL # 最高一致性
# 序列化一致性级别(用于轻量级事务)
SERIAL CONSISTENCY SERIAL # 串行一致性
SERIAL CONSISTENCY LOCAL_SERIAL # 本地串行一致性
3.1.2 Cassandra数据库Keyspace一致性配置
# 单数据中心
cqlsh> CREATE KEYSPACE fgedudb
… WITH replication = {
… ‘class’: ‘SimpleStrategy’,
… ‘replication_factor’: 3
… };
# 多数据中心
cqlsh> CREATE KEYSPACE fgedudb
… WITH replication = {
… ‘class’: ‘NetworkTopologyStrategy’,
… ‘dc1’: 3,
… ‘dc2’: 2
… };
# 修改副本因子
cqlsh> ALTER KEYSPACE fgedudb
… WITH replication = {
… ‘class’: ‘NetworkTopologyStrategy’,
… ‘dc1’: 5
… };
# 查看Keyspace配置
cqlsh> DESCRIBE KEYSPACE fgedudb;
CREATE KEYSPACE fgedudb WITH replication = {‘class’: ‘NetworkTopologyStrategy’, ‘dc1’: ‘5’} AND durable_writes = true;
# 修改副本因子后需要运行repair
# nodetool repair fgedudb
# 查看Keyspace副本信息
cqlsh> SELECT * FROM system_schema.keyspaces WHERE keyspace_name = ‘fgedudb’;
keyspace_name | durable_writes | replication
—————+—————-+—————————-
fgedudb | True | {‘class’: ‘NetworkTopologyStrategy’, ‘dc1’: ‘5’}
(1 rows)
3.2 Cassandra数据库查询一致性配置实战
Cassandra数据库查询一致性配置实战:
3.2.1 Cassandra数据库单次查询一致性配置
# 使用USING CONSISTENCY子句
cqlsh:fgedudb> SELECT * FROM fgedu_users
… USING CONSISTENCY QUORUM
… WHERE user_id = ?;
# 写入操作设置一致性级别
cqlsh:fgedudb> INSERT INTO fgedu_users (user_id, user_name, email)
… USING CONSISTENCY QUORUM
… VALUES (?, ‘zhangsan’, ‘zhangsan@fgedu.net.cn’);
# 更新操作设置一致性级别
cqlsh:fgedudb> UPDATE fgedu_users
… USING CONSISTENCY QUORUM
… SET email = ‘new@fgedu.net.cn’
… WHERE user_id = ?;
# 删除操作设置一致性级别
cqlsh:fgedudb> DELETE FROM fgedu_users
… USING CONSISTENCY QUORUM
… WHERE user_id = ?;
# 批量操作设置一致性级别
cqlsh:fgedudb> BEGIN BATCH
… USING CONSISTENCY QUORUM
… INSERT INTO fgedu_users (user_id, user_name) VALUES (?, ‘user1’);
… INSERT INTO fgedu_users (user_id, user_name) VALUES (?, ‘user2’);
… APPLY BATCH;
# 轻量级事务设置序列化一致性
cqlsh:fgedudb> INSERT INTO fgedu_users (user_id, user_name)
… VALUES (?, ‘newuser’)
… IF NOT EXISTS
… USING CONSISTENCY QUORUM
… AND SERIAL CONSISTENCY LOCAL_SERIAL;
3.2.2 Cassandra数据库应用层一致性配置
# 1. 使用DataStax Java Driver
import com.datastax.oss.driver.api.core.ConsistencyLevel;
import com.datastax.oss.driver.api.core.CqlSession;
import com.datastax.oss.driver.api.core.cql.Statement;
import com.datastax.oss.driver.api.core.cql.SimpleStatement;
# 2. 创建Session
CqlSession session = CqlSession.builder()
.addContactPoint(new InetSocketAddress(“192.168.1.101”, 9042))
.withLocalDatacenter(“dc1”)
.withAuthCredentials(“fgedu”, “Fgedu@2024”)
.build();
# 3. 设置单条语句一致性级别
Statement statement = SimpleStatement.builder(
“SELECT * FROM fgedu_users WHERE user_id = ?”)
.addPositionalValues(userId)
.setConsistencyLevel(ConsistencyLevel.QUORUM)
.build();
ResultSet resultSet = session.execute(statement);
# 4. 设置全局一致性级别
# 在application.conf中配置
datastax-java-driver {
advanced {
consistency {
default = QUORUM
serial = LOCAL_SERIAL
}
}
}
# 5. 动态设置一致性级别
public ResultSet executeWithConsistency(String query, ConsistencyLevel consistency) {
Statement statement = SimpleStatement.builder(query)
.setConsistencyLevel(consistency)
.build();
return session.execute(statement);
}
# 使用示例
ResultSet result = executeWithConsistency(
“SELECT * FROM fgedu_users WHERE user_id = ?”,
ConsistencyLevel.QUORUM
);
# 6. 批量操作一致性级别
BatchStatement batch = BatchStatement.builder(BatchType.LOGGED)
.setConsistencyLevel(ConsistencyLevel.QUORUM)
.addStatement(SimpleStatement.newInstance(
“INSERT INTO fgedu_users (user_id, user_name) VALUES (?, ?)”,
uuid1, “user1”))
.addStatement(SimpleStatement.newInstance(
“INSERT INTO fgedu_users (user_id, user_name) VALUES (?, ?)”,
uuid2, “user2”))
.build();
session.execute(batch);
3.3 Cassandra数据库一致性监控实战
Cassandra数据库一致性监控实战:
3.3.1 Cassandra数据库一致性监控指标
# 1. 读写延迟监控
# nodetool tablestats fgedudb.fgedu_users
Table: fgedu_users
Read Count: 100000
Read Latency: 5.23 ms
Write Count: 500000
Write Latency: 2.15 ms
# 2. 一致性级别分布
# 通过JMX监控
# MBean: org.apache.cassandra.metrics:type=ClientRequest,scope=Read,name=Latency
# MBean: org.apache.cassandra.metrics:type=ClientRequest,scope=Write,name=Latency
# 3. 副本同步状态
# nodetool netstats
Mode: NORMAL
Not sending any streams.
Receive side:
/192.168.1.102 stream session 8e5f6a7b
Receiving stream #0 from /192.168.1.102
Progress: 50% (100/200 files)
# 4. 数据修复状态
# nodetool repair -pr
[2024-01-15 10:30:00,000] Starting repair…
[2024-01-15 10:30:05,000] Repair completed successfully
# 5. 墓碑监控
# nodetool tablehistograms fgedudb.fgedu_users
Percentile SSTables Tombstones
50% 0.00 0.00
75% 0.00 0.00
95% 0.00 10.00
98% 0.00 50.00
# 6. 监控脚本
#!/bin/bash
# consistency_monitor.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: http://www.fgedu.net.cn
echo “=== Cassandra一致性监控 ===”
echo “时间: $(date)”
echo “”
echo “1. 集群状态”
nodetool status
echo “”
echo “2. 读写延迟”
nodetool tablestats fgedudb | grep -E “Read|Write”
echo “”
echo “3. 副本同步状态”
nodetool netstats
echo “”
echo “4. 墓碑统计”
nodetool tablehistograms fgedudb.fgedu_users | grep Tombstones
echo “”
echo “监控完成”
3.3.2 Cassandra数据库一致性验证
# 1. 使用TRACING验证
cqlsh:fgedudb> TRACING ON;
cqlsh:fgedudb> SELECT * FROM fgedu_users WHERE user_id = ?;
Tracing session: 8e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b
activity | timestamp | source
—————————————————–+—————————-+————–
Execute CQL3 query | 2024-01-15 10:30:00.123000 | 192.168.1.101
Parsing statement | 2024-01-15 10:30:00.123100 | 192.168.1.101
determining replicas for query | 2024-01-15 10:30:00.123200 | 192.168.1.101
sending request to /192.168.1.101 | 2024-01-15 10:30:00.123300 | 192.168.1.101
sending request to /192.168.1.102 | 2024-01-15 10:30:00.123300 | 192.168.1.101
sending request to /192.168.1.103 | 2024-01-15 10:30:00.123300 | 192.168.1.101
reading data | 2024-01-15 10:30:00.123500 | 192.168.1.101
sending response | 2024-01-15 10:30:00.123600 | 192.168.1.101
# 关闭TRACING
cqlsh:fgedudb> TRACING OFF;
# 2. 数据一致性检查
# 使用nodetool repair验证
# nodetool repair -pr fgedudb
# 3. 手动数据对比
# 在不同节点查询同一数据
# cqlsh 192.168.1.101 -e “SELECT * FROM fgedudb.fgedu_users WHERE user_id = ?”
# cqlsh 192.168.1.102 -e “SELECT * FROM fgedudb.fgedu_users WHERE user_id = ?”
# cqlsh 192.168.1.103 -e “SELECT * FROM fgedudb.fgedu_users WHERE user_id = ?”
# 4. 使用cassandra-stress测试一致性
# cassandra-stress read n=100000 -node 192.168.1.101 -rate threads=50 -cl QUORUM
# 5. 一致性验证脚本
#!/bin/bash
# consistency_check.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: http://www.fgedu.net.cn
KEYSPACE=”fgedudb”
TABLE=”fgedu_users”
USER_ID=”8e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b”
echo “=== 一致性验证 ===”
# 在各节点查询数据
for node in 192.168.1.101 192.168.1.102 192.168.1.103; do
echo “节点: ${node}”
cqlsh ${node} -e “SELECT user_id, user_name, email, writetime(user_name) FROM ${KEYSPACE}.${TABLE} WHERE user_id = ${USER_ID}”
echo “”
done
echo “验证完成”
Part04-生产案例与实战讲解
4.1 Cassandra数据库金融场景一致性实战
Cassandra数据库金融场景一致性实战案例:
4.1.1 Cassandra数据库金融场景需求分析
# 1. 账户余额
– 强一致性要求
– 防止数据不一致
– 支持事务操作
# 2. 交易记录
– 强一致性要求
– 数据不可丢失
– 支持审计查询
# 3. 风控数据
– 实时性要求
– 高可用性要求
– 准确性要求
# 一致性配置方案
# 账户余额表
CREATE TABLE fgedu_account_balance (
account_id uuid PRIMARY KEY,
balance decimal,
version int,
updated_at timestamp
);
# 一致性配置
写一致性: QUORUM
读一致性: QUORUM
副本因子: 5
# 交易记录表
CREATE TABLE fgedu_transactions (
transaction_id uuid PRIMARY KEY,
account_id uuid,
amount decimal,
type text,
status text,
created_at timestamp
);
# 一致性配置
写一致性: QUORUM
读一致性: QUORUM
副本因子: 5
# 风控数据表
CREATE TABLE fgedu_risk_alerts (
alert_id uuid PRIMARY KEY,
account_id uuid,
alert_type text,
alert_level text,
created_at timestamp
);
# 一致性配置
写一致性: ONE
读一致性: ONE
副本因子: 3
4.1.2 Cassandra数据库金融场景转账实战
# 使用轻量级事务保证原子性
# 步骤1: 查询转出账户余额
cqlsh:fgedudb> SELECT balance, version FROM fgedu_account_balance
… WHERE account_id = ?
… USING CONSISTENCY QUORUM;
balance | version
———+———
1000.00 | 5
(1 rows)
# 步骤2: 检查余额是否充足
# 应用层判断: balance >= transfer_amount
# 步骤3: 执行转账(使用LWT)
cqlsh:fgedudb> BEGIN BATCH
… USING CONSISTENCY QUORUM
… AND SERIAL CONSISTENCY LOCAL_SERIAL
…
… — 扣减转出账户
… UPDATE fgedu_account_balance
… SET balance = balance – 100.00,
… version = version + 1,
… updated_at = toTimestamp(now())
… WHERE account_id = ?
… IF balance >= 100.00 AND version = 5;
…
… — 增加转入账户
… UPDATE fgedu_account_balance
… SET balance = balance + 100.00,
… version = version + 1,
… updated_at = toTimestamp(now())
… WHERE account_id = ?
… IF EXISTS;
…
… — 记录交易
… INSERT INTO fgedu_transactions
… (transaction_id, account_id, amount, type, status, created_at)
… VALUES (uuid(), ?, -100.00, ‘TRANSFER_OUT’, ‘SUCCESS’, toTimestamp(now()));
…
… INSERT INTO fgedu_transactions
… (transaction_id, account_id, amount, type, status, created_at)
… VALUES (uuid(), ?, 100.00, ‘TRANSFER_IN’, ‘SUCCESS’, toTimestamp(now()));
…
… APPLY BATCH;
[applied] | balance | version
———–+———+———
True | 900.00 | 6
(1 rows)
# 步骤4: 验证转账结果
cqlsh:fgedudb> SELECT * FROM fgedu_account_balance
… WHERE account_id IN (?, ?)
… USING CONSISTENCY QUORUM;
account_id | balance | updated_at | version
————————————–+———+———————————-+———
8e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b | 900.00 | 2024-01-15 10:30:00.123000+0000 | 6
9f7g8h9i-0j1k-2l3m-4n5o-6p7q8r9s0t1u | 1100.00 | 2024-01-15 10:30:00.123000+0000 | 3
(2 rows)
4.2 Cassandra数据库社交场景一致性实战
Cassandra数据库社交场景一致性实战案例:
4.2.1 Cassandra数据库社交场景需求分析
# 1. 用户资料
– 中等一致性要求
– 高可用性要求
– 可容忍短暂不一致
# 2. 好友关系
– 强一致性要求
– 双向关系同步
– 防止关系不一致
# 3. 动态消息
– 高写入性能要求
– 最终一致性可接受
– 支持大量数据
# 一致性配置方案
# 用户资料表
CREATE TABLE fgedu_user_profiles (
user_id uuid PRIMARY KEY,
user_name text,
nickname text,
avatar text,
status text,
updated_at timestamp
);
# 一致性配置
写一致性: QUORUM
读一致性: ONE
副本因子: 3
# 好友关系表
CREATE TABLE fgedu_friendships (
user_id uuid,
friend_id uuid,
status text,
created_at timestamp,
PRIMARY KEY (user_id, friend_id)
);
# 一致性配置
写一致性: QUORUM
读一致性: QUORUM
副本因子: 3
# 动态消息表
CREATE TABLE fgedu_posts (
user_id uuid,
post_time timestamp,
post_id uuid,
content text,
like_count int,
PRIMARY KEY (user_id, post_time)
) WITH CLUSTERING ORDER BY (post_time DESC);
# 一致性配置
写一致性: ONE
读一致性: ONE
副本因子: 3
4.2.2 Cassandra数据库社交场景好友添加实战
# 步骤1: 检查是否已是好友
cqlsh:fgedudb> SELECT * FROM fgedu_friendships
… WHERE user_id = ? AND friend_id = ?
… USING CONSISTENCY QUORUM;
# 步骤2: 添加好友关系(双向)
cqlsh:fgedudb> BEGIN BATCH
… USING CONSISTENCY QUORUM
…
… — 用户A添加用户B为好友
… INSERT INTO fgedu_friendships
… (user_id, friend_id, status, created_at)
… VALUES (?, ?, ‘ACCEPTED’, toTimestamp(now()));
…
… — 用户B添加用户A为好友
… INSERT INTO fgedu_friendships
… (user_id, friend_id, status, created_at)
… VALUES (?, ?, ‘ACCEPTED’, toTimestamp(now()));
…
… APPLY BATCH;
# 步骤3: 验证好友关系
cqlsh:fgedudb> SELECT * FROM fgedu_friendships
… WHERE user_id = ?
… USING CONSISTENCY QUORUM;
user_id | friend_id | created_at | status
————————————–+————————————–+———————————-+———
8e5f6a7b-8c9d-0e1f-2a3b-4c5d6e7f8a9b | 9f7g8h9i-0j1k-2l3m-4n5o-6p7q8r9s0t1u | 2024-01-15 10:30:00.123000+0000 | ACCEPTED
(1 rows)
# 步骤4: 查询好友列表
cqlsh:fgedudb> SELECT friend_id, status FROM fgedu_friendships
… WHERE user_id = ?
… USING CONSISTENCY ONE
… LIMIT 100;
4.3 Cassandra数据库IoT场景一致性实战
Cassandra数据库IoT场景一致性实战案例:
4.3.1 Cassandra数据库IoT场景需求分析
# 1. 设备数据
– 高写入性能要求
– 数据量大
– 可容忍短暂不一致
# 2. 告警数据
– 实时性要求
– 中等一致性要求
– 高可用性要求
# 3. 统计数据
– 最终一致性可接受
– 高写入性能要求
– 支持聚合查询
# 一致性配置方案
# 设备数据表
CREATE TABLE fgedu_device_data (
device_id text,
data_time timestamp,
data_id uuid,
temperature double,
humidity double,
pressure double,
PRIMARY KEY ((device_id), data_time)
) WITH CLUSTERING ORDER BY (data_time DESC)
AND default_time_to_live = 2592000;
# 一致性配置
写一致性: ONE
读一致性: ONE
副本因子: 3
# 告警数据表
CREATE TABLE fgedu_device_alerts (
device_id text,
alert_time timestamp,
alert_id uuid,
alert_type text,
alert_level text,
message text,
PRIMARY KEY ((device_id), alert_time)
) WITH CLUSTERING ORDER BY (alert_time DESC);
# 一致性配置
写一致性: QUORUM
读一致性: ONE
副本因子: 3
# 统计数据表
CREATE TABLE fgedu_device_stats (
device_id text,
stat_date date,
stat_hour int,
avg_temperature double,
max_temperature double,
min_temperature double,
sample_count int,
PRIMARY KEY ((device_id, stat_date), stat_hour)
);
# 一致性配置
写一致性: ANY
读一致性: ONE
副本因子: 3
4.3.2 Cassandra数据库IoT场景数据写入实战
# 步骤1: 写入设备数据
cqlsh:fgedudb> INSERT INTO fgedu_device_data
… (device_id, data_time, data_id, temperature, humidity, pressure)
… VALUES (
… ‘device-001’,
… toTimestamp(now()),
… uuid(),
… 25.5,
… 60.0,
… 1013.25
… )
… USING CONSISTENCY ONE;
# 步骤2: 批量写入设备数据
cqlsh:fgedudb> BEGIN UNLOGGED BATCH
… USING CONSISTENCY ONE
… INSERT INTO fgedu_device_data (device_id, data_time, data_id, temperature, humidity, pressure)
… VALUES (‘device-001’, toTimestamp(now()), uuid(), 25.5, 60.0, 1013.25);
… INSERT INTO fgedu_device_data (device_id, data_time, data_id, temperature, humidity, pressure)
… VALUES (‘device-002’, toTimestamp(now()), uuid(), 26.0, 58.0, 1013.50);
… INSERT INTO fgedu_device_data (device_id, data_time, data_id, temperature, humidity, pressure)
… VALUES (‘device-003’, toTimestamp(now()), uuid(), 24.5, 62.0, 1013.00);
… APPLY BATCH;
# 步骤3: 写入告警数据
cqlsh:fgedudb> INSERT INTO fgedu_device_alerts
… (device_id, alert_time, alert_id, alert_type, alert_level, message)
… VALUES (
… ‘device-001’,
… toTimestamp(now()),
… uuid(),
… ‘TEMPERATURE_HIGH’,
… ‘WARNING’,
… ‘Temperature exceeded threshold: 35.5°C’
… )
… USING CONSISTENCY QUORUM;
# 步骤4: 查询设备数据
cqlsh:fgedudb> SELECT * FROM fgedu_device_data
… WHERE device_id = ‘device-001’
… USING CONSISTENCY ONE
… LIMIT 100;
device_id | data_time | data_id | humidity | pressure | temperature
————+———————————–+————————————+———-+———-+————-
device-001 | 2024-01-15 10:30:00.123000+0000 | a1b2c3d4-e5f6-7890-abcd-ef1234567890 | 60.0 | 1013.25 | 25.5
(1 rows)
# 步骤5: 写入统计数据
cqlsh:fgedudb> INSERT INTO fgedu_device_stats
… (device_id, stat_date, stat_hour, avg_temperature, max_temperature, min_temperature, sample_count)
… VALUES (
… ‘device-001’,
… ‘2024-01-15’,
… 10,
… 25.5,
… 30.0,
… 20.0,
… 3600
… )
… USING CONSISTENCY ANY;
Part05-风哥经验总结与分享
5.1 Cassandra数据库一致性最佳实践
Cassandra数据库一致性最佳实践总结:
- 根据业务需求选择:关键数据使用高一致性级别,非关键数据使用低一致性级别
- 平衡一致性和性能:使用QUORUM平衡一致性和性能
- 多数据中心优化:使用LOCAL_QUORUM避免跨数据中心延迟
- 定期运行repair:保证数据最终一致性
- 监控一致性指标:及时发现和解决一致性问题
- 使用轻量级事务:关键操作使用LWT保证原子性
5.2 Cassandra数据库一致性问题排查
# 1. 数据不一致
# 症状: 不同节点数据不同
# 原因: 未运行repair、网络分区、写入失败
# 排查步骤
# 检查节点状态
nodetool status
# 检查数据同步
nodetool netstats
# 运行repair
nodetool repair -pr
# 验证数据
cqlsh -e “SELECT * FROM fgedudb.fgedu_users WHERE user_id = ?”
cqlsh -e “SELECT * FROM fgedudb.fgedu_users WHERE user_id = ?”
# 2. 读写延迟高
# 症状: 读写操作延迟高
# 原因: 一致性级别过高、网络延迟、节点负载高
# 排查步骤
# 检查一致性级别
cqlsh -e “CONSISTENCY”
# 检查网络延迟
ping
# 检查节点负载
nodetool info
# 降低一致性级别
CONSISTENCY ONE
# 3. 写入失败
# 症状: 写入操作失败
# 原因: 一致性级别过高、节点故障、网络问题
# 排查步骤
# 检查节点状态
nodetool status
# 检查日志
tail -100 /cassandra/logs/system.log
# 降低一致性级别
CONSISTENCY ONE
# 4. 读取旧数据
# 症状: 读取到旧数据
# 原因: 读一致性级别过低、数据未同步
# 排查步骤
# 提高读一致性级别
CONSISTENCY QUORUM
# 运行repair
nodetool repair -pr
# 检查数据时间戳
SELECT user_id, writetime(user_name) FROM fgedu_users WHERE user_id = ?
5.3 Cassandra数据库一致性工具推荐
Cassandra数据库一致性工具推荐:
5.3.1 Cassandra数据库一致性工具
# 1. nodetool repair
# 数据修复工具
nodetool repair -pr # 主范围修复
nodetool repair -pr -seq # 顺序修复
nodetool repair -pr -par # 并行修复
# 2. nodetool rebuild
# 数据重建工具
nodetool rebuild — dc1 # 从指定数据中心重建
# 3. cassandra-stress
# 性能测试工具
cassandra-stress write n=100000 -node 192.168.1.101 -cl QUORUM
cassandra-stress read n=100000 -node 192.168.1.101 -cl QUORUM
# 4. cqlsh TRACING
# 查询追踪工具
cqlsh> TRACING ON;
cqlsh> SELECT * FROM fgedu_users WHERE user_id = ?;
cqlsh> TRACING OFF;
# 5. JMX工具
# 监控工具
– JConsole
– VisualVM
– JMXTrans
# 6. 第三方工具
– DataStax OpsCenter
– Instaclustr
– Prometheus + Grafana
本文档详细介绍了Cassandra数据库数据一致性级别配置实战,包括一致性概述、一致性级别详解、CAP理论、一致性级别选择策略、一致性与性能权衡、一致性场景分析、一致性级别配置实战、查询一致性配置实战、一致性监控实战、金融场景一致性实战、社交场景一致性实战、IoT场景一致性实战、一致性最佳实践、一致性问题排查、一致性工具推荐等内容。通过学习本文档,读者可以掌握Cassandra数据库一致性配置和管理技能,为生产环境应用打下坚实基础。
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
