Consistent Hashing

2019-03-16  本文已影响0人  尚无花名

一致性哈希算法
不管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中
手动不需要了

上一篇 下一篇

猜你喜欢

热点阅读