在介绍一致性协议之前，我们可以先来了解一下分布式系统，原来我们在学校的时候练习项目肯定都是集中式部署，比如一个Tomcat就解决了，包括现在很多小型项目也是这样的，如下：
但是随着对服务性能要求的提供，或者为了避免单点故障等问题，集中式部署可能就满足不了我们的需求了，这时一个硬件或软件组件分布在不同的网络计算机上，它们彼此之间仅仅通过消息传递进行通信和协调的系统，这就是是分布式系统。
其特点如下：
分布性
对等性
并发性
缺乏全局时钟
故障随时发生
分布性
既然是分布式系统，最显著的特点肯定就是分布性，从简单来看，假设一个项目较为庞大，我们可以将整个项目会分成不同的功能，专业点就不同的微服务，比如用户微服务，产品微服务，订单微服务，这些服务部署在不同的Tomcat中，不同的服务器中，甚至不同的集群中，整个架构都是分布在不同的地方的，在空间上是随意的，而且随时会增加，删除服务器节点等。
对等性
对等性是分布式设计的一个目标，要完成一个分布式的系统架构，肯定不是简单的把一个大的单一系统拆分成一个个微服务，然后部署在不同的服务器集群就够了，其中拆分完成的每一个微服务都有可能发现问题，而导致整个项目出现问题。
比如订单服务，为了防止订单服务出现问题，一般情况需要有一个备份，在订单服务出现问题的时候能顶替原来的订单服务，也就是我们上述所说，为了避免单点故障。
这就要求这两个（或者2个以上）订单服务完全是对等的，功能完全是一致的，其实这就是一种服务副本的冗余。
还一种是数据副本的冗余，比如数据库，缓存等，都和上面说的订单服务一样，为了安全考虑需要有完全一样的备份存在，这就是对等性的意思。
并发性
并发性其实对我们来说并不陌生，在学习并发编程时，多线程是并发的基础。但现在我们要接触的不是多线程的角度，因为我们在介绍并发编码的时候，都是在同一台机器，同一个JVM的角度上出发，这里我们可能从多JVM的角度，例如在一个分布式系统中的多个节点，可能会并发地操作一些共享资源等问题，这就涉及到分布式锁的问题了。
缺乏全局时钟
在分布式系统中，节点是可能放在任意位置的，而每个位置，每个节点都有自己的时间系统，因此在分布式系统中，很难定义两个事务纠结谁先谁后，原因就是因为缺乏一个全局的时钟序列进行控制，当然我们可以是系统调用时间服务器进行解决该问题。
故障随时会发生
任何一个节点都可能出现停电、死机等现象，服务器集群越多，出现故障的可能性就越大，随着集群数目的增加，出现故障甚至都会成为一种常态。
上述我们简单介绍了一下分布式系统的特性，那么我们实际的分布式系统会带来哪些简单的问题呢？主要有：通信异常、网络分区、三态、节点故障
通信异常
通讯异常其实就是网络异常，网络系统本身是不可靠的，由于分布式系统需要通过网络进行数据传输，网络光纤，路由器等硬件难免出现问题。只要网络出现问题，也就会影响消息的发送与接受过程，因此数据消息的丢失或者延长就会变得非常普遍。
网络分区
网络分区，其实就是脑裂现象，本来有一个Leader，来管理整个系统的协调情况，一切井然有序，突然出现了网络问题，某些节点接受不到Leader的指令，可能在这种情况下，又会出现一个新的Leader来协调系统。但原来的Leader其实还在，并没有死机，只是网络系统暂时中断了，这时候就会出现问题了，在同一个系统中有不同Leader在协调，这样必然会引起这个系统的混乱。
这种由于种种问题导致同一个区域（分布式集群）有两个相互冲突的负责人的时候就会出现这种精神分裂的情况，在这里称为脑裂，也叫网络分区。
三态
三态是什么？三态其实就是成功，与失败以外的第三种状态，叫超时态。在一个JVM中，应用程序调用一个方法函数后会得到一个明确的相应，要么成功，要么失败，而在分布式系统中，虽然绝大多数情况下能够接受到成功或者失败的相应，但一旦网络出现异常，就非常有可能出现超时，当出现这样的超时现象，网络通讯的发起方，是无法确定请求是否成功处理的。
节点故障
这个其实在特性中就介绍过了，节点故障在分布式系统下是比较常见的问题，指的是组成服务器集群的节点会出现的宕机或“僵死”的现象，这种现象经常会发生。
CAP理论
好了，了解了上述的问题后，那我们该如何解决呢？首先我们一般可能从三个角度来解决上述的问题，就是我们的CAP理论，CAP其实就是 Consistency(一致性)，Availability(可用性)，Partition tolerance(分区容错性)
一致性
一致性是事务ACID的一个特性【原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）】，在介绍MySQL的时候就曾详细介绍过，这里的一致性基本类似，只是现在考虑的是分布式环境中，那么就可能不是单一的数据库了。
在分布式系统中，一致性是数据在多个副本之间是否能够保证一致的特性，这里说的一致性和前面说的对等性其实差不多。如果能够在分布式系统中针对某一个数据项的变更成功执行后，所有用户都可以马上读取到最新的值，那么这样的系统就被认为具有强一致性
可用性
可用性指系统提供服务必须一直处于可用状态，对于用户的操作请求总是能够在有限的时间内访问结果。为了做到有限的时间可能需要用到缓存，可能需要用到负载，这个时候服务器增加的节点是为性能考虑；为了可能返回结果，需要考虑服务器主备，当主节点出现问题的时候需要备份的节点能最快的顶替上来，避免单点故障等问题。
分区容错性
分布式系统在遇到任何网络分区故障的时候，仍然需要能够对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
BASE理论
那我们在一个分布式的系统中可以同时满足上述CAP理论的三个要求么，不好意思，是不可能的，最多只可能满足其中的两个要求，所以我们就必须对其有一定的取舍，如下：
| 取舍 | 描述 |
|---|---|
| 放弃P | (满足AC) 将数据和服务都放在一个节点上，避免因网络引起的负面影响，充分保证系统的可用性和一致性但放弃P意味着放弃了系统的可扩展性 |
| 放弃A | (满足PC) 当节点故障或者网络故障时，受到影响的服务需要等待一定的时间因此在等待时间里，系统无法对外提供正常服务，因此是不可用的 |
| 放弃C | (满足PA) 系统无法保证数据的实时一致性，但是承诺数据最终会保证一致性因此存在数据不一致的窗口期，至于窗口期的长短取决于系统的设计 |
但是我们发现，既然我们是一个分布式系统，如果放弃了P，那么不是又回来单节点了嘛，所以我们就是在放弃A或C之间考虑，但是又不能完全放弃，所以我们只能根据业务的需求，尽可能的取出一定的取舍，所以就来了我们的BASE理论
Basically Avaliable基本可用
当分布式系统出现不可预见的故障时，允许损失部分可用性，保障系统的“基本可用”；体现在“时间上的损失”和“功能上的损失”。比如：部分用户双十一高峰期淘宝页面卡顿或降级处理。
Soft state软状态
允许系统中的数据存在中间状态，既系统的不同节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性。比如：春节12306网站放票时，请求可能会进入排队队列。
Eventually consistent最终一致性
所有的数据在经过一段时间的数据同步后，最终能够达到一个一致的状态。比如在银行APP上转账等操作金额暂时不一致\
原文转载地址
https://blog.csdn.net/newbie0107/article/details/104976355
如果侵权请联系，立刻删除