共计 2559 个字符，预计需要花费 7 分钟才能阅读完成。
自动写代码机器人，免费开通
丸趣 TV 小编给大家分享一下 redis 中有什么集群方案，希望大家阅读完这篇文章后大所收获，下面让我们一起去探讨吧！
Redis 数据量日益增大，而且使用的公司越来越多，不仅用于做缓存，同时趋向于存储这块，这样必促使集群的发展，各个公司也在收集适合自己的集群方案，目前行业用的比较多的是下面几种集群架构，大部分都是采用分片技术，解决单实例内存增大带来的一系列问题。
本篇文章简单介绍五种方案：
官方 cluster 方案
twemproxy 代理方案
哨兵模式
codis
客户端分片
官方 cluser 方案
从 redis 3.0 版本开始支持 redis-cluster 集群，redis-cluster 采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他节点连接。redis-cluster 是一种服务端分片技术。
redis-cluster 架构图
redis-cluster 特点：
每个节点都和 n - 1 个节点通信，这被称为集群总线（cluster bus）。它们使用特殊的端口号，即对外服务端口号加 10000。所以要维护好这个集群的每个节点信息，不然会导致整个集群不可用，其内部采用特殊的二进制协议优化传输速度和带宽。
redis-cluster 把所有的物理节点映射到 [0,16383]slot（槽）上，cluster 负责维护 node–slot–value。
集群预分好 16384 个桶，当需要在 redis 集群中插入数据时，根据 CRC16(KEY) mod 16384 的值，决定将一个 key 放到哪个桶中。
客户端与 redis 节点直连，不需要连接集群所有的节点，连接集群中任何一个可用节点即可。
redis-trib.rb 脚本（rub 语言）为集群的管理工具，比如自动添加节点，规划槽位，迁移数据等一系列操作。
节点的 fail 是通过集群中超过半数的节点检测失效时才生效。
整个 cluster 被看做是一个整体，客户端可连接任意一个节点进行操作，当客户端操作的 key 没有分配在该节点上时，redis 会返回转向指令，指向正确的节点。
为了增加集群的可访问性，官方推荐的方案是将 node 配置成主从结构，即一个 master 主节点，挂 n 个 slave 从节点。如果主节点失效，redis cluster 会根据选举算法从 slave 节点中选择一个上升为 master 节点，整个集群继续对外提供服务。
twemproxy 代理方案
twemproxy 代理架构图：
Redis 代理中间件 twemproxy 是一种利用中间件做分片的技术。twemproxy 处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后（sharding），再转发给后端真正的 redis 服务器。也就是说，客户端不直接访问 redis 服务器，而是通过 twemproxy 代理中间件间接访问。降低了客户端直连后端服务器的连接数量，并且支持服务器集群水平扩展。
twemproxy 中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可以避免单点压力或故障。
twemproxy 又称 nutcracker，起源于推特系统中 redis、memcached 集群的轻量级代理。
Github 源码地址（https://github.com/twitter/twemproxy）
从上面架构图看到 twemproxy 是一个单点，很容易对其造成很大的压力，所以通常会结合 keepalived 来实现 twemproy 的高可用。这时，通常只有一台 twemproxy 在工作，另外一台处于备机，当一台挂掉以后，vip 自动漂移，备机接替工作。关于 keepalived 的用法可自行网上查阅资料。
哨兵模式
Sentinel 哨兵
Sentinel（哨兵）是 Redis 的高可用性解决方案：由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器以及这些主服务器下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。
例如:
在 Server1 掉线后：
升级 Server2 为新的主服务器：
Sentinel 的工作方式
每个 Sentinel 以每秒钟一次的频率向它所知的 Master、Slave 以及其他 Sentinel 实例发送一个 PING 命令。
如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel 标记为主观下线。
如果一个 Master 被标记为主观下线，则正在监视这个 Master 的所有 Sentinel 要以每秒一次的频率确认 Master 的确进入了主观下线状态。
当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认 Master 的确进入了主观下线状态，则 Master 会被标记为客观下线。
在一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它所知的所有 Master、Slave 发送 INFO 命令。
当 Master 被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
若没有足够数量的 Sentinel 同意 Master 已经下线，Master 的客观下线状态就会被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效值，Master 的主观下线状态就会被移除。
codis
codis 是一个分布式的 Redis 解决方案，由豌豆荚开源，对于上层的应用来说，连接 codis proxy 和连接原生的 redis server 没什么明显的区别，上层应用可以像使用单机的 redis 一样使用，codis 底层会处理请求的转发，不停机的数据迁移等工作，所有后边的事情，对于前面的客户端来说是透明的，可以简单的认为后边连接的是一个内存无限大的 redis 服务。
客户端分片
分区的逻辑在客户端实现，由客户端自己选择请求到哪个节点。方案可参考一致性哈希，这种方案通常适用于用户对客户端的行为有完全控制能力的场景。
总结：没有最好的方案，只有最合适的方案。
看完了这篇文章，相信你对 redis 中有什么集群方案有了一定的了解，想了解更多相关知识，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
向 AI 问一下细节丸趣 TV 网 – 提供最优质的资源集合！
