TiDB如何包管数据一致性
1. 分布式事务协议TiDB 采用了类似 Google Percolator 的分布式事务协议来处置惩罚分布式事务。这个协议基于两阶段提交（2PC）的头脑，但进行了优化和改进，以顺应分布式情况的特殊需求。在 TiDB 中，当一个事务需要跨多个节点执行时，它会首先向和谐者（Coordinator）发起事务哀求。和谐者负责和谐整个分布式事务的执行过程。它首先会向所有参与事务的节点发送预提交哀求（Prepare Request），这些节点在收到哀求后会执行当地事务操作，并将操作效果和状态信息返回给和谐者。和谐者在收到所有参与节点的响应后，会根据这些信息决定是否提交或回滚事务。如果所有节点都乐成执行了当地事务操作并且没有辩论或错误发生，和谐者会向所有节点发送提交哀求（Commit Request），否则发送回滚哀求（Rollback Request）。
TiDB两阶段提交：
https://i-blog.csdnimg.cn/direct/826338638da5432ca984aa09761ddefb.png
TiKV两阶段提交
https://i-blog.csdnimg.cn/direct/3958f7517c7f4319b94676a0961699d9.png
2. 多版本并发控制（MVCC）
TiDB 使用 MVCC 来实现高效的并发控制和数据一致性。MVCC 通过为每个数据版本分配一个唯一的版本号来实现并发控制。当事务读取数据时，它会获取数据的当前版本号，并基于该版本进行后续操作。其他事务在修改数据时会生成新的版本，而不会影响到正在执行的事务。通过这种方式，MVCC 能够确保并发事务之间的数据隔离和一致性。TiDB 还通过公道的垃圾接纳（GC）策略来管理存储空间，确保系统长期稳定运行。
3. Raft 协议
TiKV（TiDB 的分布式存储引擎）使用 Raft 协议来实现数据的一致性和高可用性。每个 Region（TiKV 中的数据分区）的副本组通过 Raft 协议进行日记复制，确保数据一致性。Raft 中的 Leader 负责处置惩罚客户端哀求，将操作日记复制到 Follower，并在多数副本确认后提交日记。当某个副本故障时，PD（Placement Driver）可以自动将其替换，并通过 Raft 协议确保新的副本能够恢复数据。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]