为了降低添加或删除服务器节点，导致大量key无法命中的影响。就提出了一种更为合理的分法
优点之一：对现有缓存的命中影响较小。 但原本6380的区域200
300被6382侵入了。 6382的空间数值250正好划分一半，即200250的区域还归6380管，但250300的区域却归新来的管了。 (为示例而使用简单数字区分，实际上没这么精准) 优点之二：实现对数据的分片 同时也带来了缺点就是: 原本存储在6380(250300这部分)的旧缓存数据就无法命中了，要去新的6382拿。 所以说一致性hash并不能完全解决这种影响，只能尽量降低
虚拟节点
一致性Hash虽然实现了数据分片，但由于节点较少，key有可能会大量集中到某一台上面，导致缓存分布不均匀。 特别是在只有几台或十几台机器节点时。 为了降低这种影响，一致性hash算法提出虚拟节点的解决方案。 即一个物理机器节点对应着多个虚拟节点
虚拟节点使key分布的更加均衡，但不能解决添加机、删除节点带来的影响
①强一致性：当更新操作在某个副本上执行成功后，之后所有的读操作都要能够获得最新的数据。对于单副本而言，读写操作都是在同一数据上执行，很容易保证一致性；而对于多副本数据，则需要使用分布式协议如2PC协议。
②弱一致性：当更新某数据时，用户读到最新的数据需要一段时间。
③最终一致性：它是一种特殊形式的弱一致性。它不能保证当某个数据Ｘ更新后，在所有后续对Ｘ的操作能够看到新数据，而是需要一个时间片段，在经过该时间片段之后，则能保证。在这个时间片段内，数据可能是不一致的，该片段称“不一致窗口“
最终一致性 应用：Cassandra
在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，只要这些节可以通过网络连通，最终他们的状态都是一致的
简单的描述下这个协议，首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。这个协议的神奇就在于它从设计开始就没想到信息一定要传递给所有的节点，但是随着时间的增长，在最终的某一时刻，全网会得到相同的信息。当然这个时刻可能仅仅存在于理论，永远不可达
gossip 协议有多种实现，这里说一个例子当节点启动时，读配置文件，然后向一个 seed 发送信息，进行信息同步，然后开始没秒都随机选择一个 seed 节点来同步信息 1、随机取一个当前活着的节点，并向它发送同步请求 2、向随机一台不可达的机器发送同步请求 3、如果第一步中所选择的节点不是 seed，或者当前活着的节点数少于 seed 数，则向随意一台 seed 发送同步请求
强一致性 应用：zookeeper 使用的简化版的 Zab
说起paxos，需要稍微提提二段提交。简单来说，二阶段提交就是1.一个节点询问其他节点，我是不是可以进行消息提交。2.如果收到所有人的同意，则告诉大家，开始提交吧。这个协议在实际中并不能很好的解决分布式中信息同步问题。例如只要有节点失效，就会发生得不到所有人同意的结果，在超时后，这一次提交失败，等一系列问题。但是paxos在对二段提交进行了优化后，得到了一个比较好的解决办法。 paxos协议引入了多数派，以及消息编号的概念。 1.在准备时，询问2/n+1的参与者，要求他们保证不会接受小于编号n的提交。
2.如果得到了2/n+1的回复，则可以开始告诉2/n+1的参与者进行消息的提交。 可以明显的看出，这就是对二段提交的一个优化版。就是这么一个比较巧妙的思想，解决了一些二阶段提交带来的问题。 基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一
把提议人和审批人的算法结合在一起，我们得到下面两个阶段的算法：
阶段1
（a） 提议人生成议案编号n，向半数以上审批人发送编号为n的初审请求。
（b） 如果审批人收到的初审请求编号n大于他之前初审通过的议案编号，将回复两个信息：一个是保证不再对编号小于n的议案做出回应【包括初审和复审】，二是如果之前初审通过了议案，将其中编号最大的议案的编号和内容回复给提议人。
阶段2
（a） 如果提议人收到了半数以上的审批人的初审通过回复，他将会以议案（n,v）发送复审请求。对于议案内容v，如果审批人的初审回复中包含议案，那么v就是这些议案中编号最大的那个议案的内容，如果初审回复中不包含议案，提议人可以自行决定议案内容v。
（b） 如果审批人收到了编号为n的议案的复审请求，只要他没有初审通过编号大于n的议案【从而做出过保证】，他会复审通过这一议案
Raft是一个分布式一致性协议／算法，是Replicated And Fault Tolerant的缩写
一个由 Raft 协议组织的集群中有三类角色：
- Leader（领袖）
- Follower（群众）
- Candidate（候选人
一致性算法是从复制状态机的背景下提出的。在这种方法中，一组服务器上的状态机产生相同状态的副本 ，并且在一些机器宕掉的情况下也可以继续运行。复制状态机在分布式系统中被用于解决很多容错的问题
Raft中，问题分解为：领导选取、日志复制、安全和成员变化
任期(Term) RPC
Zookeeper使用了一种称为Zab(Zookeeper Atomic Broadcast)的协议
Zookeeper提供的一致性是弱一致性,首先数据的复制有如下规则:zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。那么就有可能有节点的数据不是最新的而被客户端访问到。并且会有一个时间点,在集群中是不一致的. 也就是Zookeeper只保证最终一致性, 但是实时的一致性可以由客户端调用自己来保证,通过调用sync()方法
很多情况下，系统中已经有一个保证一致性的中心服务，如某个单一服务器或者是实现了Paxos协议的一组服务器，但如果所有的功能都需要通过这个中心服务，很容易造成性能瓶颈。为了提高效率和扩展性，可以通过租约把一致性扩展到更多服务上。事实上用租约来维护缓存一致性也是相当于把服务器上的数据一致性扩展到了客户端
这里主要列举租约可以用来干什么？
a,进行故障检测。这类似于ZooKeeper中master 与 slaver 之间发送的心跳包的作用。在ZK中， master 和 slaver 之间通过交换心跳包来检测它们是否还存活。一个具体的例子参考：故障检测
b,维护缓存一致性维护缓存的一致性，第一种办法是轮询：每次读取数据时都先询问服务器数据是不是最新的，若不是，则先让服务器传输新数据，然后再读取该新数据。第二种方法是回调：由服务器记录有哪些客户端读取了数据，当服务器对数据做修改时先通知记录下来的这些客户端，上次读取过的数据已经失效。这二种方法都有一定的缺陷，参考：租约机制简介
因此，可以引入租约机制。在租约期限内，可以保证客户端缓存的数据是最新的。当租约过期后，客户端需要重新向服务器询问数据，重新续约。
租约的定义：租约就是在一定期限内给予持有者特定权力的 协议。每个租约都有一个期限，正是这个期限可以保证租约机制容忍机器失效和网络分割。
租约机制优化后台数据库访问的一个例子：使用租约机制解决缓存数据更新的问题