共计 749 个字符，预计需要花费 2 分钟才能阅读完成。
架构
节点角色
leader 节点
写和读。
从节点
1. 只读
2. 选举 leader
观察者节点
1. 只读
2. 不选举 leader
和从节点的区别？
就是不参加选举 leader。其余和从节点一样。
那有什么用呢？那为什么还要一个这种类型的节点呢？
作用在于可读，可读的话，就能够替 leader 节点分担流量。就像从节点一样。
然而，比从节点的长处在于，不参加选举的话，性能就更快。比方，如果 leader 节点挂了，这个时候就要选举——问题就在这里，如果参加选举的节点数量过多，就会导致选举速度变慢。所以，观察者节点的作用，就是分担读的流量，然而不参加选举，从而进步选举 leader 的性能。
leader 节点挂了
如果 leader 节点挂了，会选举，过半节点抉择某个从节点，该从节点就晋升为 leader 节点。
选举期间，集群短暂不可写。
过半节点
选举 leader 节点
如果 leader 节点挂了，会选举，过半节点抉择某个从节点，该从节点就晋升为 leader 节点。
数据一致性
每次写数据到 leader 节点的时候，都会复制数据到其余节点。
而且只有过半节点返回胜利，这次写数据才算胜利。也就是说，每次写数据，都要等过半节点确认胜利，能力返回给客户端。
上文有提到观察者节点的作用，分担读申请，然而不参加选举——这里的数据一致性过半节点确认，观察者节点也不参加，这样的话就缩小了参加确认节点的数量，从而进步写性能。
集群过半节点存活
通信
集群的每个节点之间，都会通信。
因为，
1. 须要把 leader 节点的数据复制到从节点和观察者
从节点和观察者，也要提供读服务。
2. 选举
选举的时候，须要投票。投票就要基于相互通信来实现。
转发写申请
1. 读申请
所有节点类型，都能够解决读数据。
2. 写申请
1）leader 节点
本人解决写数据。
2）非 leader 节点
转发给 leader 节点解决。
