近猫者喵提示您：看后求收藏（棉花糖小说网www.aaeconomics.com），接着再看更方便。
(实线)记住
是
候选人那里选出来的
首先我们一上来，所有的节点都是
接下来，所有的
节点都寻找
，当他们找不到的时候，就会自发成为候选人发起投票(问其它人是否赞成我成为
)，什么情况才会找不到呢?那肯定就是
挂了嘛
此时它就发送给其它节点投票的提案，然后其它节点也会给予它反馈，当它接收到超过半数的节点的反馈的时候，它就可以顺理成章的成为
了。
之后写数据的请求就会直接发给
，由
广播给其它的
，此时也是只要超过半数节点返回正反馈，那这个写数据的事务就会被执行，然后
再给它们发送提交命令，事务就算执行成功了。
.
协议
内容在从零开始的高并发(四)---
的分布式队列
的底层实现就是
协议，它实现了崩溃恢复(
崩溃)和消息广播(客户端写数据
要保证多节点都成功写入)功能。主要就是保证在
服务器上提交的事务最终让所有服务器都提交，并确保丢弃掉只在
服务器上所提出的事务
.
机制
：
机制是分布式场景中常用的，用来保证数据安全，并且在分布式环境中实现最终一致性的投票算法。这种算法的主要原理来源于鸽巢原理。它最大的优势，既能实现强一致性，而且还能自定义一致性级别。
鸽巢原理，又名狄利克雷抽屉原理、鸽笼原理。
其中一种简单的表述法为：若有
个笼子和
+
只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少
只鸽子。
另一种为：若有
个笼子和
+
只鸽子，所有的鸽子都被关在鸽笼里，那么至少有一个笼子有至少
+
只鸽子。
为什么从抽屉原理说起?一来大家对这个比较熟悉，也容易理解，二来它与
机制有异曲同工的地方。抽屉原理，
个抽屉每个抽屉最多容纳
个苹果，现在有
个苹果无论怎么放，其中的一个抽屉里面肯定会有
个苹果。那么我们把抽屉原理变变型，
个抽屉一个放了
个红苹果，另一个放了
个青苹果，我们取出
个苹果，无论怎么取至少有
个是红苹果，这个理解起来也很简单。我们把红苹果看成更新了的有效数据，青苹果看成未更新的无效数据。便可以看出来，不需要更新全部数据(并非全部是红苹果)我们就可以得到有效数据，当然我们需要读取多个副本(取出多个苹果)。
回到
机制的
到底指什么
：复制的节点数，即一份数据被保存的副本数。
：写操作成功的节点数，即每次数据写入写成功的副本数。
肯定是小于等于
的。
：读操作获取最新版本数据所需的最小节点数，即每次读取成功至少需要读取的副本数。
总结：这三个因素决定了可用性，一致性和分区容错性。只要保证(
+
&
;
)就一定能读取到最新的数据，数据一致性级别完全可以根据读写副本数的约束来达到强一致性!
分以下三种情况讨论：前提，当
已经固定了。
=
,
=
，
在分布式环境中，写一份，那么如果要读取到最新数据，就必须要读取所有节点，然后取最新版本的值了。写操作高效，但是读操作效率低。一致性高，分区容错性差，可用性低
=
,
=
,
在分布式环境中，所有节点都同步完毕，才能读取，所以只要读取任意一个节点就可以读取到最新数据。读操作高效，但是写操作效率低。分区容错性好，一致性差，实现难度更高，可用性高
=
,
=
=
/
+
可以简单理解为写超过一半节点，那么读也超过一半节点，取得读写性能平衡。一般应用适用，读写性能之间取得平衡。如
=
,
=
,
=
，分区容错性，可用性，一致性取得一个平衡。而
就是这么去设计的
需要补充的是，
并没有实现必须要客户端读取超过半数的节点，所以它是允许客户端读取到的不是最新同步完成的数据的，但是可能性比较小。数据没有同步完成的节点其实客户端也大概率是连接不上的，因为无论是网络问题还是机器问题导致
发送数据过去它做不了的话，客户端肯定也连不上它。要是刚好就是在同步数据的中间状态客户端发起了访问的话，也是有办法解决的，可以自己了解一下。
.
理论
理论：
年
月份被首次提出，
理论告诉我们，一个分布式系统不可能同时满足
,
,
三个需求
：
，强一致性，分布式环境中多个数据副本保持一致
：，高可用性，系统提供的服务必须一直处于可用，对于用户的每一个操作请求总是能在有限时间内返回结果
：分区容错性，分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务
既然一个分布式系统不能同时满足
,
,
三个需求，我们就要就我们的需求去取舍了。放弃
：最简单的极端做法，就是放置在一个节点上，也就只有一个数据副本，所有读写操作就集中在一台服务器上，有单点故障问题。放弃
也就意味着放弃了系统的可扩展性，所以分布式系统一般来说，都会保证
放弃
：一旦系统遇到网络分区或者其他故障时，服务需要等待一段时间，在等待时间内就无法正常对外提供服务，即服务不可用放弃
：事实上，放弃一致性是指放弃数据的强一致性，而保留最终一致性，具体多久达到数据同步取决于存储系统的设计
只能
选
，因为在分布式系统中，容错性
肯定是必须有的，所以这时候无非就两种情况，网络问题导致要么错误返回，要么阻塞等待，前者牺牲了一致性，后者牺牲了可用性。举个例子，比如
就是追求数据的一致性的，而
则是可用性。
经验总结：不要花费精力浪费在设计同时满足
的分布式系统分区容错性往往是分布式系统必然要面对和解决的问题。所以应该把精力放在如何根据业务特点在
和
之间寻求平衡。对于单机软件，因为不用考虑
，所以肯定是
型，比如
对于分布式软件，因为一定会考虑
，所以又不能兼顾
和
的情况下，只能在
和
做权衡，比如
,
等。做到服务基本可用，并且数据最终一致即可。
所以，就产生了
理论。
.
理论
多数情况下，其实我们也并非一定要求强一致性，部分业务可以容忍一定程度的延迟一致，所以为了兼顾效率，发展出来了最终一致性理论
，来自
的架构师提出。
理论全称：全称：(基本可用)，
(软状态),和(最终一致性)三个短语的缩写。核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。一句话概括，做事别走极端，
是对
理论中的
和
进行权衡得到的结果。
不是强一致，而是最终一致。不是高可用，而是基本可用。
(基本可用)：基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用
例如淘宝双
，&#
;&#
;&#
;．&#
;&#
;&#
;
ｕ&#
;为保护系统稳定性，正常下单，其他边缘服务可暂时不可用。部分非核心服务宕机此时是允许的。
(软状态)：软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。通俗的讲：允许存在不同节点同步数据时出现延迟，且出现数据同步延迟时存在的中间状态也不会影响系统的整体性能
(最终一致)：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况，要求最终达到一致，而不是实时强一致
总的来说，我们提到了集中式和分布式服务部署架构的分析，设计分布式系统会遇到的各种难题：数据一致性的问题
和
是通用的思路实现，还是有缺点。
就算出现了分布式网络通信异常等相关棘手的问题，以上这些算法也能实现一致性
议会制
机制：
+
&
;
===&
;少数服从多数
一致性和可用性的冲突问题，
和
：分布式系统一定要满足
，只能在
和
中做权衡
绝大部分系统都是
系统(基本可用+最终一致)
【编辑推荐】
【责任编辑：未丽燕
：（
）
】
点赞
