实战部署redis的Sentinel？

Posted 6曦轩

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了实战部署redis的Sentinel？相关的知识，希望对你有一定的参考价值。

前言

在上个篇章我们阐述了Sentinel的原理，可能大家还是云里雾里，需要来点实战性的东西，那这个篇章我们来个实战篇吧～话不多说，我们开始今天的吹牛皮～

正文

Sentinel 实战

Sentinel 配置

为了保证 Sentinel 的高可用，Sentinel 也需要做集群部署，集群中至少需要三个 Sentinel 实例（推荐奇数个，防止脑裂）。

以 Redis 安装路径/usr/local/soft/redis-5.0.5/为例。

在 204 和 205 的 src/redis.conf 配置文件中添加

 
   
   
 
    
  
    
    
  
  1. slaveof 192.168.8.203 6379
    2.

在 203、204、205 创建 sentinel 配置文件（安装后根目录下默认有 sentinel.conf）：

 
   
   
 
    
  
    
    
  
  1. cd /usr/local/soft/redis-5.0.5
    2. 
  
    
    
  
  2. mkdir logs
    3. 
  
    
    
  
  3. mkdir rdbs
    4. 
  
    
    
  
  4. mkdir sentinel-tmp
    5. 
  
    
    
  
  5. vim sentinel.conf
    6.

三台服务器内容相同：

 
   
   
 
    
  
    
    
  
  1. daemonize yes
    2. 
  
    
    
  
  2. port 26379
    3. 
  
    
    
  
  3. protected-mode no
    4. 
  
    
    
  
  4. dir "/usr/local/soft/redis-5.0.5/sentinel-tmp"
    5. 
  
    
    
  
  5. sentinel monitor redis-master 192.168.8.203 6379 2
    6. 
  
    
    
  
  6. sentinel down-after-milliseconds redis-master 30000
    7. 
  
    
    
  
  7. sentinel failover-timeout redis-master 180000
    8. 
  
    
    
  
  8. sentinel parallel-syncs redis-master 1
    9.

上面出现了 4 个'redis-master'，这个名称要统一，并且使用客户端（比如 Jedis）连接的时候名称要正确。

Sentinel 验证

启动 Redis 服务和 Sentinel

 
   
   
 
    
  
    
    
  
  1. cd /usr/local/soft/redis-5.0.5/src
    2. 
  
    
    
  

    3. 
  
    
    
  
  3. #启动 Redis 节点
    4. 
  
    
    
  

    5. 
  
    
    
  
  5. ./redis-server ../redis.conf
    6. 
  
    
    
  

    7. 
  
    
    
  
  7. #启动 Sentinel 节点
    8. 
  
    
    
  

    9. 
  
    
    
  
  9. ./redis-sentinel ../sentinel.conf
    10. 
  
    
    
  

    11. 
  
    
    
  
  11. #或者
    12. 
  
    
    
  

    13. 
  
    
    
  
  13. ./redis-server ../sentinel.conf --sentinel
    14. 
  
    
    
  

    15. 
  
    
    
  

    16. 
  
    
    
  
  16. 查看集群状态：
    17. 
  
    
    
  

    18. 
  
    
    
  
  18. redis> info replication
    19.
203

204 和 205

实战部署redis的Sentinel？

模拟 master 宕机，在 203 执行：

 
   
   
 
    
  
    
    
  
  1. redis> shutdown
    2.

205 被选为新的 Master，只有一个 Slave 节点。

实战部署redis的Sentinel？

注意看 sentinel.conf 里面的 redis-master 被修改了！

模拟原 master 恢复，在 203 启动 redis-server。它还是 slave，但是 master 又有两个 slave 了。

slave 宕机和恢复省略。

Sentinel 连接使用

Jedis 连接 Sentinel（ck-jedis：JedisSentinelTest.java）

master name 来自于 sentinel.conf 的配置。

 
   
   
 
    
  
    
    
  
  1. private static JedisSentinelPool createJedisPool() {
    2. 
  
    
    
  
  2.  String masterName = "redis-master";
    3. 
  
    
    
  
  3.  Set<String> sentinels = new HashSet<String>();
    4. 
  
    
    
  
  4.  sentinels.add("192.168.8.203:26379");
    5. 
  
    
    
  
  5.  sentinels.add("192.168.8.204:26379");
    6. 
  
    
    
  
  6.  sentinels.add("192.168.8.205:26379");
    7. 
  
    
    
  
  7.  pool = new JedisSentinelPool(masterName, sentinels);
    8. 
  
    
    
  
  8.  return pool;
    9. 
  
    
    
  
  9. }
    10.

Spring Boot 连接 Sentinel（springboot-redis：RedisAppTest.java）

 
   
   
 
    
  
    
    
  
  1. spring.redis.sentinel.master=redis-master
    2. 
  
    
    
  
  2. spring.redis.sentinel.nodes=192.168.8.203:26379,192.168.8.204:26379,192.168.8.205:26379
    3.

哨兵机制的不足

主从切换的过程中会丢失数据，因为只有一个 master。只能单点写，没有解决水平扩容的问题。如果数据量非常大，这个时候我们需要多个 master-slave 的 group，把数据分布到不同的 group 中。

  • 问题来了，数据怎么分片？分片之后，怎么实现路由？

Redis 分布式方案

如果要实现 Redis 数据的分片，我们有三种方案：

  1. 在客户端实现相关的逻辑，例如用取模或者一致性哈希对 key 进行分片，查询和修改都先判断 key 的路由。

  2. 把做分片处理的逻辑抽取出来，运行一个独立的代理服务，客户端连接到这个代理服务，代理服务做请求的转发。

  3. 基于服务端实现。

客户端 Sharding

实战部署redis的Sentinel？Jedis 客户端提供了 Redis Sharding 的方案，并且支持连接池。

ShardedJedis

 
   
   
 
    
  
    
    
  
  1. public class ShardingTest {
    2. 
  
    
    
  
  2.  public static void main(String[] args) {
    3. 
  
    
    
  
  3.  JedisPoolConfig poolConfig = new JedisPoolConfig();
    4. 
  
    
    
  

    5. 
  
    
    
  
  5.  // Redis 服务器
    6. 
  
    
    
  
  6.  JedisShardInfo shardInfo1 = new JedisShardInfo("127.0.0.1", 6379); 
    7. 
  
    
    
  
  7.  JedisShardInfo shardInfo2 = new JedisShardInfo("192.168.8.205", 6379);
    8. 
  
    
    
  

    9. 
  
    
    
  
  9.  //连接池
    10. 
  
    
    
  
  10.  List<JedisShardInfo> infoList = Arrays.asList(shardInfo1, shardInfo2); 
    11. 
  
    
    
  
  11.  ShardedJedisPool jedisPool = new ShardedJedisPool(poolConfig, infoList);
    12. 
  
    
    
  
  12.  ShardedJedis jedis = null;
    13. 
  
    
    
  
  13.  try{
    14. 
  
    
    
  
  14.  jedis = jedisPool.getResource();
    15. 
  
    
    
  
  15.  for(int i=0; i<100; i++){
    16. 
  
    
    
  
  16.  jedis.set("k"+i, ""+i);
    17. 
  
    
    
  
  17.  }
    18. 
  
    
    
  
  18.  for(int i=0; i<100; i++){
    19. 
  
    
    
  
  19.  System.out.println(jedis.get("k"+i));
    20. 
  
    
    
  
  20.  }
    21. 
  
    
    
  
  21.  }finally{
    22. 
  
    
    
  
  22.  if(jedis!=null) {
    23. 
  
    
    
  
  23.  jedis.close();
    24. 
  
    
    
  
  24.  }
    25. 
  
    
    
  
  25.  }
    26. 
  
    
    
  
  26.  }
    27. 
  
    
    
  
  27. }
    28.

  • Sharded 分片的原理？怎么连接到某一个 Redis 服务？

使用 ShardedJedis 之类的客户端分片代码的优势是配置简单，不依赖于其他中间件，分区的逻辑可以自定义，比较灵活。但是基于客户端的方案，不能实现动态的服务增减，每个客户端需要自行维护分片策略，存在重复代码。
第二种思路就是把分片的代码抽取出来，做成一个公共服务，所有的客户端都连接到这个代理层。由代理层来实现请求和转发。

代理 Proxy

实战部署redis的Sentinel？

典型的代理分区方案有 Twitter 开源的 Twemproxy 和国内的豌豆荚开源的 Codis。

Twemproxy

Twemproxy 的优点：比较稳定，可用性高。不足：

  1. 出现故障不能自动转移，架构复杂，需要借助其他组件（LVS/HAProxy + Keepalived）实现 HA

  2. 扩缩容需要修改配置，不能实现平滑地扩缩容（需要重新分布数据）。

Codis

实战部署redis的Sentinel？

分片原理：Codis 把所有的 key 分成了 N 个槽（例如 1024），每个槽对应一个分组，一个分组对应于一个或者一组 Redis 实例。

Codis 对 key 进行 CRC32 运算，得到一个 32 位的数字，然后模以 N（槽的个数），得到余数，这个就是 key 对应的槽，槽后面就是 Redis 的实例。

比如 4 个槽：

实战部署redis的Sentinel？

Codis 的槽位映射关系是保存在 Proxy 中的，如果要解决单点的问题，Codis 也要做集群部署，多个 Codis 节点怎么同步槽和实例的关系呢？需要运行一个 Zookeeper（或者 etcd/本地文件）。

在新增节点的时候，可以为节点指定特定的槽位。Codis 也提供了自动均衡策略。Codis 不支持事务，其他的一些命令也不支持。不支持的命令获取数据原理（mget）：在 Redis 中的各个实例里获取到符合的 key，然后再汇总到 Codis 中。Codis 是第三方提供的分布式解决方案，在官方的集群功能稳定之前，Codis 也得到了大量的应用。

Redis Cluster

Redis Cluster介绍

Redis Cluster 是在 Redis 3.0 的版本正式推出的，用来解决分布式的需求，同时也可以实现高可用。跟 Codis 不一样，它是去中心化的，客户端可以连接到任意一个可用节点。

数据分片有几个关键的问题需要解决：

  1. 数据怎么相对均匀地分片

  2. 客户端怎么访问到相应的节点和数据

  3. 重新分片的过程，怎么保证正常服务

架构

Redis Cluster 可以看成是由多个 Redis 实例组成的数据集合。客户端不需要关注数据的子集到底存储在哪个节点，只需要关注这个集合整体。

以 3 主 3 从为例，节点之间两两交互，共享数据分片、节点状态等信息。实战部署redis的Sentinel？

搭建

点击跳转redis三主三从搭建教程

  • 配置

  • 启动

  • 进入客户端：

 
   
   
 
    
  
    
    
  
  1. redis-cli -p 7291
    2. 
  
    
    
  
  2. redis-cli -p 7292
    3. 
  
    
    
  
  3. redis-cli -p 7293
    4.

批量插入数据

类型 | 命令 -|- 集群 |cluster info ：打印集群的信息
cluster nodes ：列出集群当前已知的所有节点（node），以及这些节点的相关信息。节点| cluster meet ：将 ip 和 port 所指定的节点添加到集群当中，让它成为集群的一份子。
cluster forget ：从集群中移除 node id 指定的节点(保证空槽道)。
cluster replicate ：将当前节点设置为 node id 指定的节点的从节点。
cluster saveconfig ：将节点的配置文件保存到硬盘里面。槽(slot)| cluster addslots [slot ...] ：将一个或多个槽（slot）指派（assign）给当前节点。
cluster delslots [slot ...] ：移除一个或多个槽对当前节点的指派。
cluster flushslots ：移除指派给当前节点的所有槽，让当前节点变成一个没有指派任何槽的节点。
cluster setslot node ：将槽 slot 指派给 node id 指定的节点，如果槽已经指派给另一个节点，那么先让另一个节点删除该槽>，然后再进行指派。
cluster setslot migrating ：将本节点的槽 slot 迁移到 node id 指定的节点中。
cluster setslot importing ：从 node_id 指定的节点中导入槽 slot 到本节点。
cluster setslot stable ：取消对槽 slot 的导入（import）或者迁移（migrate）。键 | cluster keyslot ：计算键 key 应该被放置在哪个槽上。
cluster countkeysinslot ：返回槽 slot 目前包含的键值对数量。
cluster getkeysinslot ：返回 count 个 slot 槽中的键

  • 问题：Cluster 解决分片的问题，数据怎么分布？

数据分布

如果是希望数据分布相对均匀的话，我们首先可以考虑哈希后取模。

哈希后取模

例如，hash(key)%N，根据余数，决定映射到那一个节点。这种方式比较简单，属于静态的分片规则。但是一旦节点数量变化，新增或者减少，由于取模的 N 发生变化，数据需要重新分布。

为了解决这个问题，我们又有了一致性哈希算法。

一致性哈希

一致性哈希的原理：

把所有的哈希值空间组织成一个虚拟的圆环（哈希环），整个空间按顺时针方向组织。因为是环形空间，0 和 2^32-1 是重叠的。

假设我们有四台机器要哈希环来实现映射（分布数据），我们先根据机器的名称或者 IP 计算哈希值，然后分布到哈希环中（红色圆圈）。

实战部署redis的Sentinel？

现在有 4 条数据或者 4 个访问请求，对 key 计算后，得到哈希环中的位置（绿色圆圈）。沿哈希环顺时针找到的第一个 Node，就是数据存储的节点。实战部署redis的Sentinel？

在这种情况下，新增了一个 Node5 节点，不影响数据的分布。实战部署redis的Sentinel？

删除了一个节点 Node4，只影响相邻的一个节点。实战部署redis的Sentinel？

谷歌的 MurmurHash 就是一致性哈希算法。在分布式系统中，负载均衡、分库分表等场景中都有应用。一致性哈希解决了动态增减节点时，所有数据都需要重新分布的问题，它只会影响到下一个相邻的节点，对其他节点没有影响。

但是这样的一致性哈希算法有一个缺点，因为节点不一定是均匀地分布的，特别是在节点数比较少的情况下，所以数据不能得到均匀分布。解决这个问题的办法是引入虚拟节点（Virtual Node）。

比如：2 个节点，5 条数据，只有 1 条分布到 Node2，4 条分布到 Node1，不均匀。实战部署redis的Sentinel？

Node1 设置了两个虚拟节点，Node2 也设置了两个虚拟节点（虚线圆圈）。

这时候有 3 条数据分布到 Node1，1 条数据分布到 Node2。实战部署redis的Sentinel？

Redis 虚拟槽分区

Redis 既没有用哈希取模，也没有用一致性哈希，而是用虚拟槽来实现的。

Redis 创建了 16384 个槽（slot），每个节点负责一定区间的 slot。比如 Node1 负责 0-5460，Node2 负责 5461-10922，Node3 负责 10923-16383。Redis 的每个 master 节点维护一个 16384 位（2048bytes=2KB）的位序列，比如：序列的第 0 位是 1，就代表第一个 slot 是它负责；序列的第 1 位是 0，代表第二个 slot 不归它负责。

对象分布到 Redis 节点上时，对 key 用 CRC16 算法计算再%16384，得到一个 slot 的值，数据落到负责这个 slot 的 Redis 节点上。

查看 key 属于哪个 slot：

 
   
   
 
    
  
    
    
  
  1. redis> cluster keyslot qingshan
    2.

注意：key 与 slot 的关系是永远不会变的，会变的只有 slot 和 Redis 节点的关系。

问题：

  • 怎么让相关的数据落到同一个节点上？

  • 比如有些 multi key 操作是不能跨节点的，如果要让某些数据分布到一个节点上，例如用户 2673 的基本信息和金融信息，怎么办？

在key 里面加入{hash tag}即可。Redis 在计算槽编号的时候只会获取{}之间的字符串进行槽编号计算，这样由于上面两个不同的键，{}里面的字符串是相同的，因此他们可以被计算出相同的槽。

user{2673}base=… user{2673}fin=…

 
   
   
 
    
  
    
    
  
  1. 127.0.0.1:7293> set a{qs}a 1
    2. 
  
    
    
  
  2. OK
    3. 
  
    
    
  
  3. 127.0.0.1:7293> set a{qs}b 1
    4. 
  
    
    
  
  4. OK
    5. 
  
    
    
  
  5. 127.0.0.1:7293> set a{qs}c 1
    6. 
  
    
    
  
  6. OK
    7. 
  
    
    
  
  7. 127.0.0.1:7293> set a{qs}d 1
    8. 
  
    
    
  
  8. OK
    9. 
  
    
    
  
  9. 127.0.0.1:7293> set a{qs}e 1
    10. 
  
    
    
  
  10. OK
    11.

  • 问题：客户端连接到哪一台服务器？访问的数据不在当前节点上，怎么办？

客户端重定向

比如在 7291 端口的 Redis 的 redis-cli 客户端操作：

 
   
   
 
    
  
    
    
  
  1. 127.0.0.1:7291> set qs 1
    2. 
  
    
    
  
  2. (error) MOVED 13724 127.0.0.1:7293
    3.

服务端返回 MOVED，也就是根据 key 计算出来的 slot 不归 7191 端口管理，而是归 7293 端口管理，服务端返回 MOVED 告诉客户端去 7293 端口操作。

这个时候更换端口，用 redis-cli –p 7293 操作，才会返回 OK。或者用./redis-cli -c -p port 的命令（c 代表 cluster）。这样客户端需要连接两次。

Jedis 等客户端会在本地维护一份 slot——node 的映射关系，大部分时候不需要重定向，所以叫做 smart jedis（需要客户端支持）。

问题：新增或下线了 Master 节点，数据怎么迁移（重新分配）？

数据迁移

因为 key 和 slot 的关系是永远不会变的，当新增了节点的时候，需要把原有的 slot 分配给新的节点负责，并且把相关的数据迁移过来。添加新节点（新增一个 7297）：

 
   
   
 
    
  
    
    
  
  1. redis-cli --cluster add-node 127.0.0.1:7291 127.0.0.1:7297
    2.

新增的节点没有哈希槽，不能分布数据，在原来的任意一个节点上执行：

 
   
   
 
    
  
    
    
  
  1. redis-cli --cluster reshard 127.0.0.1:7291
    2.

输入需要分配的哈希槽的数量（比如 500），和哈希槽的来源节点（可以输入 all 或者 id）。

问题：只有主节点可以写，一个主节点挂了，从节点怎么变成主节点？

高可用和主从切换原理

当 slave 发现自己的 master 变为 FAIL 状态时，便尝试进行 Failover，以期成为新的 master。由于挂掉的 master 可能会有多个 slave，从而存在多个 slave 竞争成为 master 节点的过程， 其过程如下：

  1. slave 发现自己的 master 变为 FAIL

  2. 将自己记录的集群 currentEpoch 加 1，并广播 FAILOVERAUTHREQUEST 信息

  3. 其他节点收到该信息，只有 master 响应，判断请求者的合法性，并发送FAILOVERAUTHACK，对每一个 epoch 只发送一次 ack

  4. 尝试 failover 的 slave 收集 FAILOVERAUTHACK

  5. 超过半数后变成新 Master

  6. 广播 Pong 通知其他集群节点。

Redis Cluster 既能够实现主从的角色分配，又能够实现主从切换，相当于集成了 Replication 和 Sentinal 的功能。

总结：

优势

  1. 无中心架构。

  2. 数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。

  3. 可扩展性，可线性扩展到 1000 个节点（官方推荐不超过 1000 个），节点可动态添加或删除。

  4. 高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升。

  5. 降低运维成本，提高系统的扩展性和可用性。

不足

  1. Client 实现复杂，驱动要求实现 Smart Client，缓存 slots mapping 信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。

  2. 节点会因为某些原因发生阻塞（阻塞时间大于 clutser-node-timeout），被判断下线，这种 failover 是没有必要的。

  3. 数据通过异步复制，不保证数据的强一致性。

  4. 多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。

By the way

有问题？可以给我留言或私聊 有收获？那就顺手点个赞呗~ 想找工作机会也可以联系我噢～

回复“学习”，即可领取一份【Java工程师进阶架构师的视频教程】~

回复“面试”，可以获得：【本人呕心沥血整理的 Java 面试题】

回复“mysql脑图”，可以获得【MySQL 知识点梳理高清脑图】

还有【阿里云】【腾讯云】的购买优惠噢~具体请联系我


以上是关于实战部署redis的Sentinel？的主要内容，如果未能解决你的问题，请参考以下文章

Redis主从加哨兵模式集群部署

实战之部署Redis哨兵模式-Docker版本

使用bitnamiredis-sentinel部署Redis 哨兵模式

使用bitnamiredis-sentinel部署Redis 哨兵模式

Redis-Sentinel部署和配置

redis 集群热备自动切换sentinel配置实战