Redis Cluster 是一个分布式系统。由多个 Redis 实例组成的整体,数据按照 Slot 存储分布在多个 Redis 实例上,通过 Gossip 协议来进行节点之间通信。
Redis Cluster 中有一个 16384 长度的槽的概念,每个 key 都会通过公式 CRC16(key) % 16384 来计算键 key 属于哪个槽,槽位是虚拟的,可以在不同节点之前迁移
客户端对 key 做哈希,得到槽位,并到本地路由缓存查找槽位对应的服务器节点,其中会有一些特殊情况要处理
cluster 服务端节点直接使用 gossip 协议进行节点间通信(redis cluster 这种单纯的哈希分布的方案下,好像除了交换节点存活情况和槽位信息,服务端节点之间的数据交互需求并不高,感觉不如谷歌大数据老三篇论文里面的弱 master 节点的设计,能节省很多不必要的节点通信)
twemproxy 应该是最早开源的集群方案了,不过功能太过简单了,尽管使用了一致性哈希,但是集群中节点有增加时,还是会产生部分数据的丢失,而且不值钱数据分片迁移,另外是单线程了,不过单线程的问题有唯品会 twemproxies 分支解决了
codis 的功能相对比较完整,支持新增节点,支持数据迁移,使用 go 语言开发,而 go 的协程非常适合这种并发请求的场景,也能轻松实现对多核 CPU 的利用,不过 codis 感觉最大的问题还是所有请求都需要结果代理转发,另外就是这个项目现在官方团队已经不再维护了(搞 TiDB 去了~)
redis cluster 这个 redis 官方的集群方案,优势和缺点也都很明显,与 codis 的预哈希方案类似,key 哈希到某个 slot(槽位)而不再是具体的节点,使得集群可以比较平滑的伸缩,另外一个优势就是客户端与 node 节点直连,省去了代理的开销,不过 cluster 的问题也同样明显,使用 gossip 这种无中心 p2p 的协议,导致所有节点都要频繁的与其他节点交换信息,另外一个问题就是使用 redis cluster 需要升级客户端,这对很多存量业务是很大的成本
corvus 是饿了么开发的,加载 redis cluster 前面的一个客户端代理,主要作用是在不侵入代码的情况下使用 redis cluster,业务代理里面对 redis 的使用与原来单点的实例没有区别
另外还有 SSDB/ledisdb/redisdb/tidis 等实现 redis 协议的第三方实现
参考:
1
haiyangcn 2019-02-18 10:06:18 +08:00
请教一个问题:有什么方案可以实现:redis 分布式部署,并且可以多写(在任意节点写入后同步到其他节点)
|
2
oncewosiwo OP @haiyangcn 好像目前并没有符合“任意节点写入”这个一条的方案,codis 是一个中心的代理服务器来接收所有请求,redis cluster 里的节点只接收其所管理的槽位下的 key 的请求。如果单纯说多节点写入的话,redis cluster 算是符合要求,客户端会自动将请求发送到对应的节点中,也会将请求同步到这个节点的从节点上
|
3
MarkrMelon 2021-04-25 16:49:14 +08:00
可以转载吗, 家里的网访问不了 v2
|