Redis集群的工作原理_redis集群怎么工作的

Redis可以有主从复制，还可以备份数据。还有哨兵节点负责监控管理。

虽然有主从复制和哨兵，但只能解决高可用的问题，解决不了数据量大的问题。因为咱们看起来人手多，但都是存储的全量数据。

所以对于数据容量提升，并没有什么帮助，例如多个redis拼起来，每一个负责一部分数据，合体进化成一个大的缓存服务器，变成一个集群。

建立集群还需要考虑到扩容，扩容时的加入类似三次握手。需要告诉集群中的某个redis自己的IP和端口，那么该redis就给其发送一个MEET信息发起握手，对方需要回复一个PONG信息同意入伙，最后该redis再回他一个PING信息，三次握手就完成了。

然后，该redis再将这个事告诉集群中其他redis，那么新的伙伴就算正式成为集群的一份子了。

第二件很重要的事情就是要解决数据存储的公平问题，解决方案类似哈希表的方法。

总共划分了16384的哈希桶，将它叫做槽位Slot，程序员可以按照能力大小，给它们各自分配一部分槽位。

数据读写的时候，对键值做一下哈希计算，映射到哪个槽就由谁负责。为了让大家的信息达成一致，启动的时候，每个人都得把自己负责的槽位信息告诉其他伙伴，一共有1万多个槽要通知其他小伙伴。这样需要传输的内容还挺大的，因此为了压缩数据空间，每个槽位干脆就用一个bit来表示。

自己负责这一位就是1，否则就是0，总共也才16384个bit，也就是2048个字节。传输起来轻便快捷，一口气就发送过去了。这样传输是轻量，但是真正工作的时候还是不方便。

遇到读写的时候，总不能去看谁的那位是1吧。

考虑用空间换时间，准备了一个超大的数组来存储每个槽由哪个节点来负责，通过上面的方式拿到信息后就更新到这里来。

这样一来，遇到数据访问的时候，我们就能快速知道这个数据是由谁来负责了。

这16384的槽位必须都得有人来负责，这样整个集群才算是正常工作，处于上线状态，否则就是下线状态。

数据分配问题解决了，正式上线后和原来不同的是得先检查数据是不是由自己负责，如果是由自己负责，那就进行处理。不然的话，就要返回一个MOVED错误给请求端。同时把槽号、IP和端口告诉他，让他知道该去找谁处理。

集群中每个redis都得有一个backup，这样就有了从节点。这样一旦遇到故障就能快速顶上。

有了集群和主从复制，就能保证高可用的同时，提升了数据容量。

参考资料：趣话Redis：Redis集群是如何工作的？