1、在大型集群中每日宕机发生的概率为千分之一左右；在实践中，一台宕机的机器恢复时间通常认为是 24 小时。

2、由于网络数据丢失的异常存在，直接决定了分布式系统的协议必须能处理网络数据丢失的情况。

3、如果某些节点的直接的网络通信正常或丢包率在合理范围内，而某些节点之间始终无法正常通信，则称这种特殊的网络异常为“网络分化”。

4、消息乱序是指节点发送的网络消息有一定的概率不是按照发送时的顺序依次到达目的节点。网络报文乱序也是一种常见的网络异常。这就要求设计分布式协议时，考虑使用序列号等机制处理网络消息的乱序问题，使得无效的、过期的网络消息不影响系统的正确性。

5、网络上传输的数据有可能发生比特错误，从而造成数据错误。通常使用一定的校验码机制可以较为简单的检查出网络数据的错误，从而丢弃错误的数据。

6、在设计分布系统的网络协议时即使使用 TCP 协议，也依旧要考虑网络异常，不能简单的认为使用 TCP 协议后通信就是可靠的。另一方面，如果完全放弃使用 TCP 协议，使用 UDP 协议加自定义的传输控制机制，则会使得系统设计复杂。尤其是要设计、实现一个像 TCP 那样优秀的拥塞控制机制是非常困难的。

7、分布式系统中 RPC 执行的结果有三种状态：“成功”、“失败”、“超时（未知）”，称为分布式的三态。

8、被大量工程实践所检验过的异常处理黄金原则是：任何在设计阶段考虑到的异常情况一定会在系统实际运行中发生，但在系统实际运行遇到的异常却很有可能在设计时未能考虑，所以，除非需求指标允许，在系统设计时不能放过任何异常情况。

9、副本（replica/copy）指在分布式系统中为数据或服务提供的冗余。常见的有数据副本和服务副本，数据副本是分布式系统解决数据丢失异常的唯一手段；服务副本指数个节点提供某种相同的服务。

10、一致性的强弱分为：强一致性(strong consistency)、单调一致性(monotonic consistency)、会话一致性(session consistency)、最终一致性(session consistency)、弱一致性(session consistency)。

11、常见的性能指标如下，三个性能指标往往会相互制约，追求高吞吐的系统，往往很难做到低延迟；而系统平均响应时间较长时，也很难提高 QPS。

• 吞吐能力：指系统在某一时间可以处理的数据总量，通常可以用系统每秒处理的总的数据量来衡量；
• 响应延迟：指系统完成某一功能需要使用的时间；
• 并发能力：指系统可以同时完成某一功能的能力，通常也用 QPS(query per second)来衡量；

12、如何拆解分布式系统的输入数据成为分布式系统的基本问题。

13、一致性哈希的基本方式是使用一个哈希函数计算数据或数据特征的哈希值，令该哈希函数的输出值域为一个封闭的环，即哈希函数输出的最大值是最小值的前序。将节点随机分布到这个环上，每个节点负责处理从自己开始顺时针至下一个节点的全部哈希值域上的数据。

一致性哈希算法是一种特殊的哈希算法，理解一致性 hash 主要理解两点：

• 将普通哈希取模的 N 进行固定，从而确保了相同的 key 必然是相同的位置，从而避免了牵一发而动全身的问题；
• N 固定并且设置很大，实际上就是进行数据分片 Sharding，分布的小片就要和实际的机器产生关联关系；

一致性哈希算法并不是从彻底解决了由于动态调整服务器数据产生的数据迁移问题，而是将原来普通哈希取模造成的几乎全部迁移，降低为小部分数据的移动，是一种非常大的优化。

一致性哈希虽然对扩容和缩容友好，但是存在另外一个问题，就很容易出现数据倾斜。那么数据倾斜是如何解决的呢? 一个方案就是添加虚拟节点，对服务器节点也进行哈希操作，在整个哈希环上，均匀添加若干个节点。比如 a1 和 a2 都属于 A 节点，b1、b2 都属于 B 节点，这样在哈希时可以平衡各个节点的数据。

Redis 的一致性哈希实现：Redis cluster 拥有固定的 16384 个 slot，slot 是虚拟的且被分布到各个 master 中，当 key 映射到某个 master 负责 slot 时，就由对应的 master 为 key 提供服务。像 Redis 并没有使用 2^32 这种哈希环，而是采用了 16384 个固定 slot 来实现的，然后每个服务器 Master 使用 bitmap 来确定自己的管辖 slot。

14、数据副本合适的做法不是以机器作为副本单位，而是将数据拆为较合理的数据段，以数据段为单位作为副本。

15、副本控制协议指按特定的协议流程控制副本数据的读写行为，使得副本满足一定的可用性和一致性要求的分布式协议。副本控制协议要具有一定的对抗异常状态的容错能力，从而使得系统具有一定的可用性，同时副本控制协议要能提供一定一致性级别。

16、副本控制协议分类两大类：“中心化（centralized）副本控制协议” 和 “去中心化（decentralized）副本控制协议”。中心化副本控制协议的最大缺点就是系统的可用性依赖于中心化节点， 当中心节点切换时会带来一定的停服务时间；去中心化副本控制协议的最大缺点时协议过程通常比较复杂、效率和性能也较中心化协议低。

17、中心化副本控制协议的更新流程大抵如下：

• 1）数据更新都由 primary 节点协调完成；
• 2）外部节点更新操作发给 primary 节点；
• 3）primary 节点进行并发控制即确定并发更新操作的先后顺序；
• 4）primary 节点将更新操作发送给 secondary 节点；
• 5）primary 根据 secondary 节点的完成情况决定更新是否成功并将结果返回外部节点；

18、中心化副本控制协议强一致性读取的几种思路：

• 1）由于数据的更新流程都是由 primary 控制的，primary 副本上的数据一定时最新的，所以如果始终只读 primary 副本的数据，可以实现强一致性。
• 2）由 primary 控制节点 secondary 节点的可用性。当 primary 更新某个 secondary 副本不成功时，primary 将该 secondary 副本标记为不可用，从而用户不再读取该不可用的副本。
• 3）基于 Quorum 机制。

19、Paxos 是唯一在工程中得到应用的强一致性去中心化副本控制协议。

20、Zookeeper 中的 Lease 机制：Zookeeper 的 primary（leader） 节点会向 client 颁发 lease，lease 的时间正是 Zookeeper 中的 session 时间。在 Zookeeper 中，临时节点是与 session 的生命期绑定的，当一个 client 的 session 超时，那么这个 client 创建的临时节点会被 zookeeper 自动删除。通过监控临时节点的状态，也可以很容易的实现对节点状态的监控。

21、Zookeeper 中的 Quorum 机制：Zookeeper 使用的 Paxos 协议本身就是利用了 Quorum 机制，当利用 Paxos 协议外选出 primary 后，Zookeeper 的更新流量由 primary 节点控制，每次更新操作，primary 节点只需更新超过半数（含自身）的节点后就返回用户成功。每次更新操作都会递增各个节点的版本号（xzid）。当 primary 节点异常，利用 Paxos 协议选举新的 primary 时，每个节点都会以自己的版本号发起 Paxos 提议，从而保证了选出的新 primary 是某个超过半数副本集合中版本号最大的副本。

22、CAP 理论的定义很简单，CAP 三个字母分别代表了分布式系统中三个相互矛盾的属性：Consistency (一致性)、Availiablity（可用性）、Tolerance to the partition of network (分区容错性）。CAP 理论指出：无法设计一种分布式协议，使得同时具备 CAP 三种属性（即该协议下的副本始终是强一致性，服务始终是可用的，协议可以容忍任何网络分区异常），分布式系统协议只能在 CAP 这三者间所有折中。

• Lease 机制牺牲了部分情况下的 A，从而获得了完全的 C 与很好的 P。
• Quorum 机制，在 CAP 三大因素中都各做了折中，有一定的 C，有较好的 A，也有较好的 P，是一种较为平衡的分布式协议。
• 两阶段提交协议具有完全的 C，很糟糕的 A，很糟糕的 P。
• Paxos 协议具有完全的 C，较好的 A，较好的 P。Paxos 的 A 与 P 的属性与 Quorum 机制类似，因为 Paxos 的协议本身就具有 Quorum 机制的因素。

23、FLP 不可能原理：在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性共识算法。FLP 不可能原理实际上告诉人们，不要浪费时间，去为异步分布式系统设计在任意场景下都能实现共识的算法。

出　　处：https://www.cnblogs.com/jmcui/p/14623103.html