分布式系统的事务及一致性模型

下面PPT出自10gen的产品和工程高级副总裁 Roger Bodamer ，参加过Mongo Beijing的人应该记得会上的大个子. 下面PPT 主要就分布式系统的事务及一致性模型进行了分析和讨论. 对分布式存储在CAP原理下的选择和实现进行了描述. Google Megastore系统事务机制.

在分布式系统中，我们经常遇到多数据副本保持一致的问题，在我们所能找到的资料中该问题讲的很笼统，模模糊糊的，把多个问题或分类糅合在一起，难以理解. 在思考和翻阅资料后，通俗地把一致性的问题可分解为2个问题：. 1、任何一次修改保证数据一致性. 在弱一致性的算法，不要求每次修改的内容在修改后多副本的内容是一致的，对问题1的解决比较宽松，更多解决问题2，该类算法追求每次修改的高度并发性，减少多副本之间修改的关联性，以获得更好的并发性能.

现在先抛出问题，假设有一个主数据中心在北京M，然后有成都A，上海B两个地方数据中心，现在的问题是，假设成都上海各自的数据中心有记录变更，需要先同步到主数据中心，主数据中心更新完成之后，在把最新的数据分发到上海，成都的地方数据中心A，地方数据中心更新数据，保持和主数据中心一致性（数据库结构完全一致）.

编者按：本文由「高可用架构后花园」群讨论整理而成，后花园是一个面向架构师的增值服务，如需了解，请关注「高可用架构」后回复 VIP.                                                                                 问题的起源.

在分布式系统中，我们经常遇到多数据副本保持一致的问题，在我们所能找到的资料中该问题讲的很笼统，模模糊糊的，把多个问题或分类糅合在一起，难以理解. 在思考和翻阅资料后，通俗地把一致性的问题可分解为2个问题：. 1、任何一次修改保证数据一致性. 2、多次数据修改的一致性. 在弱一致性的算法，不要求每次修改的内容在修改后多副本的内容是一致的，对问题1的解决比较宽松，更多解决问题2，该类算法追求每次修改的高度并发性，减少多副本之间修改的关联性，以获得更好的并发性能.

猫友会群里经常卧虎藏龙，转载一篇百度大牛，投稿原创文章，大家交流学习 ，文末有作者个人公众号. 欢迎更多猫友投稿，发布原创文章和干货和大家分享交流.        在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”. 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的.

印象中CAP理论开始流行是从Amazon Dynamo的论文开始的，Amazon的CTO还在他的博客中介绍了最终一致性的概念，从此以后，各种会议和交流中都少不了CAP的影子. 然而，对于分布式系统工程设计和开发来说，CAP意味着什么呢. CAP 理论由 Berkerly 的 Brewer 教授提出，三者的含义如下：.

本文将会从实际应用场景出发，介绍一致性哈希算法（Consistent Hashing）及其在分布式系统中的应用. 首先本文会描述一个在日常开发中经常会遇到的问题场景，借此介绍一致性哈希算法以及这个算法如何解决此问题；接下来会对这个算法进行相对详细的描述，并讨论一些如虚拟节点等与此算法应用相关的话题.

摘要: 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性. 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败. 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性. 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败.

 两阶段提交协议是很常见的解决分布式事务的方式，他可以保证分布式事务中，要么所有参与的进程都提交事务成功，要么都取消事务，这样做可以在分布式环境中保持ACID中A(原子性).      在两阶段提交协议中，包含了两种角色：协调者与参与者. 参与者就是实际处理事务的机器，而协调者就是其中一台单独的处理分布式事务的机器.