前言
Redis 作为最常用的 key-value 服务,一直为我们带来了高性能的保障。但程序嘛,总不可能一直运行下去,而我们所要做的就是将这些风险降到最低。
所以,高可用也是 Redis 必然要考虑的了,而随着 Redis 的广泛使用,市面上也出现了有很多高可用方案。今天,就来好好认识下这些方案,或许也可以为我们自己的程序带来灵感。
高可用机制
Redis 的高可用从总体上来讲是通过 冗余 + 故障转移 来实现的,而对于冗余和故障转移又可以细化为:全部冗余或部分冗余;手动转移或自动转移。
全部冗余+手动转移的方案就是我们最熟悉的主从模式了;当手动转移变为自动转移时即哨兵模式。最后部分冗余 + 自动转移则是集群模式。
由于 Redis 不像 mysql,在数据的完整性、一致性上是没有比较好的保障的,所以当我们在使用高可用方案时,对数据的一致性就期望不了那么高了,这是需要提前注意的。
主从模式
主从模式在高可用方案中是最常用的一种。往往我们会在不同的机器上部署着同一 Redis 程序。在这多台机器里,我们会选择一个节点作为主节点,它负责数据的写入。其他节点作为从节点,定时的和主节点同步数据。一旦主节点不能使用了,那么就可以在从节点中挑选一个作为主节点,重新上岗服务。
主从模式往往还能进行读写分离,将读取数据的压力分散到多个从节点上。
在 Redis 进行主从数据同步时,会执行 bgsave 命令以生成 RDB 文件,同时会在缓冲区记录增量的命令。
当 Redis 将 RDB 文件同步给 Slave 后,会再次的将缓冲区的增量命令发送给从节点,从节点接收到这些数据后,就可以恢复到内存里了。
从节点除了恢复数据外,它还维护了一个复制偏移量,表示主节点向从节点传递命令的字节总数。这个复制偏移量会定时同步给主节点。
而主节点也有属于自己的一个写入偏移量,有了这 2 个参数后,主节点就知道要进行部分复制还是要全量复制了。
主从模式在出现故障时,需要人为进行干预,而且从节点一多,主节点的同步压力就会很大了。
哨兵模式
上面的主从模式需要人工的进行故障节点切换,这种方式对于追求完美的程序员来说,肯定是不够的。所以有了自动切换的哨兵模式。
哨兵模式主要实现了下面几个功能:
- 监控:不断的检测主从节点是否能正常工作。
- 自动转移故障:当某个 master 不能正常工作时,Sentinel 会启动一个故障转移过程,将其中的一个副本提升为 master,并通知其他从节点对应新的 master 相关信息。
- 通知:当某个节点出问题时,会告知所有节点。如果是新的主节点被选举出来,还会告知已连接过来的客户端程序关于主节点新的地址。
在哨兵模式中,会有一个或多个哨兵程序,对当前的 Redis 集群进行监控。哨兵服务之间通过 gossip 协议进行通信。当需要进行故障转移时,会通过选举算法,选出一个 leader 来主导过程。
而这也意味着,Sentinel 程序不能选举出 leader 的话,则不能继续执行后续动作了。包括客户端的请求,也会被阻塞住。
集群
主从模式和哨兵模式都会在多台机器中存储着同一份数据,这样对于内存的利用率并不高。如果能够将数据分散到各个节点上,同时配上主从模式,那么就能高效使用内存了。集群就是这么个机制。
Redis 的集群采用了哈希槽的概念,总共会有 16384 个哈希槽。这些哈希槽会被分配到各个节点上,比如:
- 节点 1 分配了 0 至 5500 的哈希槽。
- 节点 2 分配了 5501 至 11000 的哈希槽。
- 节点 3 分配了 11001 至 16384 的哈希槽。
当有 key 过来时,Redis 会对其进行 CRC16(key) % 16384 的运算,看当前的 key 要分散到哪个哈希槽上,再根据当前的哈希槽定位到对应的节点上。这样就完成了一次 key-value 的存储了。
读取也是按这规则来,不同的是,如果运算结果所对应的节点不在当前节点上,则会转发给对应的节点去处理。
当有节点进行新增或删除时,会重新划分这些哈希槽,当然,影响的只会是周围节点,不会造成整个集群不可用。
在这些节点背后还有属于它们的从节点,一旦主节点不可用,那么这些从节点就会被启用,以保证系统的正常运行。
总结
从主从到哨兵再到集群,它们的实施难度是从易到难。一般对于大多数项目来讲,主从模式就足够应付了。如果并发量比较高,数据量也很大,那再来考虑集群。毕竟,项目架构是在不断演变的,往往有了具体的使用场景,好的方案才能发挥出对应的价值。
感兴趣的朋友可以搜一搜公众号「 阅新技术 」,关注更多的推送文章。
可以的话,就顺便点个赞、留个言、分享下,感谢各位支持!
阅新技术,阅读更多的新知识。