Consistent Hashing

一致性哈希算法
不管SQL 还是NoSQL都需要用它。 NoSQL帮你实现了， SQL没有帮你实现。需要自己实现

简单的一致性算法

将key模一个很大的数，比如360
找到相邻区间，均分。保证了连续性，但是没有必要。不够均匀。

更实用的方法

把圆周从0 - 359 变成 0 ~ 2^64 - 1;
机器也看成圆上的点。数据也看成圆上的点。 把数据放到它顺时针碰到的第一台机器上。

然而数据结构里没有环，用 BBST, 红黑树 实现

MicroShards/Virtual Nodes

让一台机器对应着环上的1000个点（比如） 一千个分身
memcache01.1 memcache01.2 memcache01.3..... 用mac地址， 或者名字， 然后加后缀， 不能用ip地址
用Hash函数投射，用机器名字算Hash,然后投射到环上。
分身投射： 让环更均匀。
这样子做对数据迁移会不会有很多影响 ？会！ 减小了数据的移动。 这是一个概率算法。

consistent hashing -ii, lintcode

Replica vs Backup

Backup： 是周期性的，（每天晚上一次？） 当数据丢失时backup只能恢复到之前的某个时间点。不能分摊读请求。
Replica: 在线数据服务，分摊读； 数据丢时可以马上通过其他replica恢复。 实时的 。
为什么还要 backup? 双重保险

MySQL Replica

通常自带Master Slave Replica。 Write ahead log
读请求分摊， 写请求不分摊。
Master挂了的话，就把其中一个slave promote to Master
手动的方式也可以consistent hashing环上一式三份

NoSQL Replica

自带的 以Cassandra为代表, 将数据顺时针存在consistent hashing环上的三个virtual nodes中
手动不需要了