CAP理论 一致性哈希算法

一致性哈希算法

最初提出是为了解决分布式Cache，网络中的热点（Hot spot）问题

一致性哈希算法原理 - lpfuture - 博客园

memcached服务器端本身不提供分布式cache的一致性，而是由客户端来提供，具体在计算一致性hash时采用如下步骤：

1. 首先求出memcached服务器（节点）的哈希值，并将其配置到0～232的圆（continuum）上。
2. 然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。
3. 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过232仍然找不到服务器，就会保存到第一台memcached服务器上。

一致性哈希解决数据分布不一致造成的数据倾斜问题？

引用虚拟节点，通过虚拟节点的二次映射解决数据分布不均引起的节点负荷不均。

CAP ： 分布式中的理论： 一致性、可用性、分区容错性。三者不可兼得，只能保证其中两个。因此，任何分布式系统的设计是三者之间的取舍。

分布式场景Webservice

一个Webservice后台运行着众多servers 对webservice的读写会反映到后台的server集群，并对CAP进行定义：

• C - 一致性： 所有节点上的数据时刻保持同步
• A - 可用性（高可用低延迟）： 每个请求都能得到响应，无论成功或失败 
• P-分区容错性： 系统应该能持续提供服务，即使系统内部有消息丢失

高可用、数据一致是很多分布式设计的目标，但是高可用不可避免的是分区

• CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。
• CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
• AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。