老刘是一名即将找工作的研二学生，写博客一方面是复习总结大数据开发的知识点，一方面是希望能够帮助和自己一样自学编程的伙伴。由于老刘是自学大数据开发，博客中肯定会存在一些不足，还希望大家能够批评指正，让我们一起进步！
今天给各位小伙伴聊聊分布式系统的数据一致性问题，这个一定要从服务器架构部署的发展历程讲起！文章篇幅较长，请大家耐心观看，精彩千万不要错过！
1.背景
1.1.集中式服务
首先要讲的是集中式服务，那集中式是什么？就是事情都由一台服务器搞定。
而集中式系统就是由一台或多台主计算机组成中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务都在这个中心节点上，系统所有的功能都由它做。
也就是说，在集中式系统中，每个客户端仅仅负责数据的输入和输出，而数据的存储与控制处理完全交给主机完成。
那集中式服务优点：
结构简单部署简单项目架构简单但是它的缺点也是非常明显：
大型主机的研发和维护成本非常高大型主机非常昂贵存在单点故障问题，主机一挂，所有服务终止大型主机的性能扩展受限于摩尔定律什么是摩尔定律？
摩尔定律是由英特尔（Intel）创始人之一戈登·摩尔（GordonMoore）提出来的。其内容为：当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。换言之，每一美元所能买到的电脑性能，将每隔18-24个月翻一倍以上。摘自：百度百科
摩尔定律告诉我们：纵向扩展理论上是受限的，所以只能考虑横向扩展，而且从理论上说，横向扩展理论上是不受限的！
那既然纵向扩展受限，我们就去尝试横向扩展，就有了分布式！
1.2.分布式服务
分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。
例如一个由分布式系统实现的电子商城，在功能上可能被拆分成多个应用，分别提供不同的功能，组成一个分布式系统对外提供服务。
所以，分布式系统中的计算机在空间上是几乎没有限制的，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中，还可能在不同的城市中。
和集中式系统相比，分布式系统的性价比更高、处理能力更强、可靠性更高、也有很好的扩展性。
但是，分布式解决了网站的高并发问题的同时也带来了一些其他问题。
首先，分布式的必要条件就是网络，这可能对性能甚至服务能力造成一定的影响。其次，一个集群中的服务器数量越多，服务器宕机的概率也就越大。另外，由于服务在集群中分布式部署，用户的请求只会落到其中一台机器上，所以，一旦处理不好就很容易产生数据一致性问题。
1.3.分布式存在的异常
1、通信异常：网络不可用（消息延迟或者丢失），会导致分布式系统内部无法顺利进行网络通信，所以可能造成多个节点数据丢失和状态不一致，还有可能造成数据乱序。
2、网络分区：网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成若干个孤立的区域，分布式系统就出现了局部小集群造成的数据不一致。
3、节点故障：服务器节点出现的宕机的现象。
4、存储数据丢失：对于有状态节点来说，数据丢失意味着状态丢失，通常只能从其他节点读取、恢复存储的状态。解决方案：利用多副本机制。
1.4.衡量分布式系统的性能指标
1、性能：这是一个非常让人头疼的问题，追求高吞吐的系统，往往很难做到低延迟；系统平均响应时间较长时，也很难提高QPS。
系统的吞吐能力，指系统在某一时间可以处理的数据总量，通常可以用系统每秒处理的总数据量来衡量；系统的响应延迟，指系统完成某一功能需要使用的时间；系统的并发能力，指系统可以同时完成某一功能的能力，通常也用QPS来衡量。2、可用性：系统的可用性(availability)指系统在面对各种异常时可以正确提供服务的能力。可用性是分布式的重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。
3、可扩展性：系统的可扩展性(scalability)指分布式系统通过扩展集群机器规模提高系统性能（吞吐、延迟、并发）、存储容量、计算能力的特性。
4、一致性：分布式系统为了提高可用性，总是不可避免地使用副本的机制，从而引发副本一致性的问题。
例如，就是一份数据存在分布式系统，存在多个不同的节点当中存着相同的数据。如果多个不同的节点存的数据不一样，多个客户端去访问的时候就会存在这种情况，第1个客户端去访问的结果为A，第2个客户端访问的结果为B，两个客户端访问得到不同的结果，那就是一致性做的不好。
说了这么多，我们如果设计一个优秀的分布式系统，它应该具有这些特点：吞吐高、响应延迟低、并发强、可用性很高、可扩展性很强、一致性很好。但并不是每个特点都能满足，有几个特点是相互矛盾的，需要我们想办法克服！
而在分布式场景中真正复杂的是数据一致性的问题！
1.5.一致性理解
一致性也分很多种，这里说说老刘了解的三个。
强一致性：写操作完成之后，读操作一定能读到最新数据。通俗地讲就是客户端只要把结果写进去了，什么时候访问都能拿到最新的数据。但是在分布式场景中很难实现，后续的Paxos算法，Quorum机制，ZAB协议等能实现！
弱一致性：不保证拿到最新的数据，也有可能拿到旧的数据。
最终一致性：不考虑中间的任何状态，只保证经过一段时间之后，最终系统内数据正确。在高并发场景中，它也是使用最广的一致性模型。
1.6.分布式一致性的作用
说了那么多分布式一致性的内容，那它的作用是什么呢？
1、为了提高系统的可用性，一般都会使用多副本机制，多副本就会有分布式一致性的问题，它就是为了提高系统的可用性，防止单点节点故障引起的系统不可用。
2、提高系统的整体性能，数据分布在集群中多个节点上，它们都能为用户提供服务。
老刘说了这么多，大家有没有猜到想引出什么内容呢？
上述那么多内容只为引出分布式系统的数据一致性问题！我们用来解决分布式系统的数据一致性问题的方案有如下：
分布式事务+事务分布式一致性算法Quorum机制CAP和BASE理论2.分布式事务
分布式系统中，每个节点都能知道自己的事务操作是否成功，但是没法知道系统中的其他节点的事务是否成功。这就有可能会造成分布式系统中的各节点的状态出现不一致。因此当一个事务需要跨越服务器节点，并且要保证事务的ACID特性时，就必须引入一个协调者的角色。那么其他的各个进行事务操作的节点就都叫做参与者。
现实生活中有两种典型的分布式事务的提交模式：2PC和3PC。
2.1.2PC提交过程
直接上图：
我让A去做一件事，让B去做另外一件事，并且这两件事在一个分布式事务中要保证同时成功或失败。那如何做到数据一致呢？
2PC分两个阶段：第一阶段：执行事务，但不提交。第二阶段：当协调者收到第一阶段中所有事务参与者的正反馈时(事务都执行成功了)，就去发命令让所有参与者提交事务。2.2.2PC的问题
看了2PC的两个提交阶段和图，有经验的人一眼就会看出里面存在的问题。
1阻塞问题
协调者发送命令给参与者，由于是网路发送命令，就会存在不同参与者收到的命令有先后、有延迟。例如参与者A很快就收到了，参与者B网络有问题，过了很久才收到命令。参与者A很快处理完发送反馈，而参与者B就很久之后才发送反馈，导致协调者等待时间特别长。这就是一个非常典型的阻塞问题，非常浪费资源，影响性能！2没有容错机制，存在单点故障问题
事务协调者是整个分布式事务的核心，一旦协调者出现故障，看看上面那张图，就会知道参与者就收不到