mysql、redis、zk、kafka、es的数据原子性、一致性保证、顺序性横评
2023-07-05 09:35:22 0 举报AI智能生成
知识要点和原理解析，详细信息和图片均在黄色图标的注释中，鼠标移动到黄色图标上即会显示，图片加载有时较慢。
作者其他创作
大纲/内容
mysql
四大特性(ACID)<br>
原子性（Atomicity）<br>
依靠undo log保证<br>
一致性（Consistency）<br>
依靠其他三大特性保证<br>
隔离性（Isolation）<br>
依靠MVCC保证<br>
持久性（Durability）<br>
由内存（buffer pool、LogBuffer）+redo log保证<br>
redis
单线程保证
zk
zookeeper中保证数据一致性用的是ZAB协议
顺序一致性<br>
原子性<br>
系统视图唯一性<br>
持久性<br>
及时性<br>
zk一致性保证的是<br>
写请求是线性一致性的，读不是
任何给定的client操作的执行顺序是<font color="#a23735">由client来决定的</font>，其称之为FIFO Client Order
工作方式<br>
FIFO client order会应用于<font color="#a23735">单个client的所有请求</font>
zk没有保证<b><font color="#a23735">跨客户端</font></b>的强一致性<br>
顺序一致性<br>
问题<br>
ZooKeeper 集群的写入是由 Leader 结点协调的，真实场景下写入会有一定的并发量，那 Zab 协议的两阶段提交是如何保证事务严格按顺序生效的
Leader 是如何判断当前 ZXID 之前是否还有未提交提案的
leader顺序性
follower顺序性<br>
leader下发提案到follower时
对比新提案的 ZXID 与自身最新 ZXID 是否相差“1”，来保证事务顺序生效
leader下发commit时<br>
通过对比commit request的zxid和pendingTxns的zxid
步骤<br>
总之：<font color="#f44336"><b>Follower通过队列和zxid等顺序标识保证请求的顺序处理，一言不合就会退出或者重新同步Leader</b></font>。
client回调顺序性<br>
按序出队
比较xzid
zookeeper如何保证半数提交后剩下的节点上最新的数据<br>
剩下的节点，会进行版本比对，发现版本不一致的话，会更新节点的数据(退出重新同步)
kafka
事务<br>
Kafka为什么要引入事务<br>
1、跨会话的幂等性写入<br>
2、跨会话的事务恢复<br>
3、跨多个 Topic-Partition 的幂等性写入<br>
<b><font color="#f44336">幂等性不能跨多个分区运作，而事务可以弥补这个缺陷。</font></b>
前面3个是针对producer的，Consumer 端难以保证事务性<br>
事务性保证<br>
拒绝僵尸实例（Zombie fencing）<br>
Kafka中的事务特性主要用于以下两种场景<br>
1、生产者发送多条消息可以封装在一个事务中，形成一个原子操作<br>
2、read-process-write模式：将消息消费和生产封装在一个事务中，形成一个原子操作<br>
使用示例源码<br>
事务性要解决的问题<br>
在写多个 Topic-Partition 时，执行的一批写入操作，有可能出现部分 Topic-Partition 写入成功，部分写入失败（比如达到重试次数），这相当于出现了中间的状态，这并不是我们期望的结果；
Producer 应用中间挂之后再恢复，无法做到 Exactly-Once 语义保证（<b><font color="#f44336">幂等性无法保证重启后精准一次性</font></b>）；<br>
事务性实现的关键<br>
1、事务原子性：2PC<br>
2、TransactionCoordinator高可用<br>
3、Producer 在 Fail 恢复后操作<br>
4、如何标识一个事务操作的状态<br>
事务性的整体流程<br>
1. Finding a TransactionCoordinator<br>
2. Getting a PID<br>
3. Starting a Transaction<br>
4. Consume-Porcess-Produce Loop
5.Committing or Aborting a Transaction<br>
思考<br>
如果多个 Producer 使用同一个 txn.id 会出现什么情况？<br>
Consumer 端如何消费事务数据？<br>
Consumer 的消费策略<br>
read_committed<br>
read_uncommitted<br>
Last Stable Offset（LSO）<br>
Server 处理 read_committed 类型的 Fetch 请求?<br>
这种机制有没有什么问题呢？<br>
Consumer 如何过滤 abort 的事务数据<br>
方案
Consume过滤abort
1、如果这个数据是 control msg（也即是 marker 数据）<br>
2、如果这个数据是正常的数据<br>
3、检查abortedProducerIds队列<br>
Consumer 消费数据时，其顺序如何保证<br>
如果 txn.id 长期不使用，server 端怎么处理？<br>
消息有序性
全局有序<br>
如何保证：<b><font color="#f44336">需要1个Topic只能对应1个Partition</font></b><br>
consumer也要使用<b><font color="#f44336">单线程</font></b>或者<font color="#f44336"><b>保证消费顺序的线程</b></font>模型<br>
局部有序<br>
不增加partition数量的情况下想提高消费速度<br>
消息重试对顺序消息的影响<br>
max.in.flight.requests.per.connection<br>
不设置该参数，失败记录捕获后自行处理<br>
es
Elasticsearch的写入流程特性<br>
可靠性<br>
一致性<br>
原子性<br>
实时性<br>
隔离性<br>
一致性（Consistency）<br>
三种设置来判断是否允许写操作<br>
One<br>
All<br>
Quorum（k-wu-wo/reng，法定人数）<br>
0 条评论
下一页
