Redis集群
当使用网络分区的时候就会涉及数据的一致性,根据CAP定理:当网络分区发生时,一致性和可用性两难全,如何实现主节点与从节点的一致性就成为了难题,Redis通过保持最终一致的方式,实现主从数据异步同步,节点会努力追赶主节点,最终从节点的状态和主节点的状态保持一致。
增量同步
redis同步的是指令流,主节点会将哪些对自己的状态产生修改性影响的指令记录在本地的Buffer中,然后异步将buffer中的指令同步到从节点,从节点执行同步指令,主节点反馈自己同步到哪里
缺点:buffer是有限的,如果buffer内容太多,之后的指令则会覆盖前面的指令
快照同步
快照同步,主节点执行一次bgsave,将当前的内存数据全部存放到磁盘文件中,然后再将快照文件的内容全部传送回从节点
Sentinel
Sentinel负责监控redis集群的健康情况,如果一个节点挂了,集群可以正常运作
如果其中一个节点挂了,则会重新连接IP,查询数据的时候使用轮询的方式。
具体可以参考阿里Sentinel
Codis
在大数据高并发的场景下,单个的redis实例往往会比较受限制,限制在于redis的内存使用,而且单个redis的内存不宜过大,如果太大容易导致rdb文件过大,进一步导致主从同步的时候全量同步时间过长,在实例重启恢复时也会消耗很长的时间。所以应运而生出很多集群方案,类似codis
codies而且是无状态的,所以可以启动多个codies来支撑高QPS的场景
codies默认将所有的key划分为1024个槽位,首先对客户端的key进行crc32位运算得到hash值,然后对hash得到的整数对1024取余,这个余数就是对应的key的槽位,之后通过zookeeper方式维护一致性
Cluster
Cluster集群使用了三个redis节点组成,他们之间通过一种特殊的二进制协议交互集群信息,与codies不同的是cluster使用了16384个槽位