一致性哈希算法232取_redis一致性哈希算法_一致性哈希算法

调研比较了三个Redis集群的解决方案：

Go+C

1.基本架构

1.1 Twemproxy

增加Proxy层，由Proxy实现一致性哈希算法（支持：KETAMA/取模/随机）

数据分片算法：

采用一致性哈希算法，以KETAMA为例：

1.2 Redis Cluster

无中心自组织的结构

各节点维护Key->Server的映射关系

Client可以向任意节点发起请求，节点不会转发请求，只是重定向Client

如果在Client第一次请求和重定向请求之间，Cluster拓扑发生改变，则第二次重定向请求将被再次重定向，直到找到正确的Server为止

数据分片算法：

Key空间被划分为16384个区间,每个Master节点负责一部分区间。redis一致性哈希算法

1.3 Codis

客户端可以连接到任意的codis-proxy,就和连接原生的Redis Server

由Zookeeper维护数据路由表和 codis-proxy 节点的元信息

数据分片算法：

Key空间被划分为1024个区间, 对于每个key来说, 通过以下公式确定所属的 Slot Id : SlotId = crc32(key) % 1024

每一个 slot 都会有一个特定的 server group id 来表示这个 slot 的数据由哪个 server group 来提供

2.水平扩容

Twemproxy:

不支持运行时水平扩容，需要重启。

根据一致性哈希算法进行数据重新分片。

Redis Cluster:

支持通过运行时增加Master节点来水平扩容，提升存储容量，尽力降低命中率波动

存在节点A，需要迁出其中的部分Key区间。新增节点B，接收由节点A迁出的Key区间。

相应Key区间的请求首先还是会发送给A节点：如果请求为新建Key则直接重定向到B节点；如果请求不是新建Key且A节点存储有对应的Key则直接作出响应，否则重定向到B节点

同时Cluster会调用实用工具redis-trib向A节点发送MIGRATE命令，把迁移区间内的所有Key原子的迁移到B节点：同时锁住A、B节点=》在A节点删除Key=》在B节点新建Key=》解锁

运行时动态迁移大尺寸键值可能造成响应时延

Codis:

支持运行时水平扩容

底层基于Codis Server特殊实现原子的数据迁移指令

3.主从备份

3.1 主从备份是否必须

Twemproxy:

没有数据复制不影响可用节点顶替故障节点

故障发生时，没有数据复制的故障节点的Key会全部丢失

Redis Cluster:

没有主从备份的节点一旦故障，将导致整个集群失败：无法写入/读取任何Key；无法进行数据重新分片。

Codis:

若出现故障，需要手动配置节点，进行故障转移。

如果没有进行故障转移，只故障节点负责的slots 会失败

3.2 主从备份方案

Twemproxy本身不支持出从备份，和Redis Cluster一样，需要引入Redis本身的主备复制功能。

可以设置1主1备或者1主多备

当Slave节点接入Cluster时，就会向配置的Master节点发送SYNC命令。断开重连时，也会再次发送SYNC命令

此后Master将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个文件到Slave，以完成一次完全同步。而Slave服务器在接收到文件数据之后将其存盘并加载到内存中。此后，Master继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-30886-1.html