实战部署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

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

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

  2. mkdir logs

  3. mkdir rdbs

  4. mkdir sentinel-tmp

  5. vim sentinel.conf

三台服务器内容相同:

 
   
   
 
  1. daemonize yes

  2. port 26379

  3. protected-mode no

  4. dir "/usr/local/soft/redis-5.0.5/sentinel-tmp"

  5. sentinel monitor redis-master 192.168.8.203 6379 2

  6. sentinel down-after-milliseconds redis-master 30000

  7. sentinel failover-timeout redis-master 180000

  8. sentinel parallel-syncs redis-master 1

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

Sentinel 验证

启动 Redis 服务和 Sentinel

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


  2. #启动 Redis 节点


  3. ./redis-server ../redis.conf


  4. #启动 Sentinel 节点


  5. ./redis-sentinel ../sentinel.conf


  6. #或者


  7. ./redis-server ../sentinel.conf --sentinel



  8. 查看集群状态:


  9. redis> info replication

203

204 和 205

实战部署redis的Sentinel?

模拟 master 宕机,在 203 执行:

 
   
   
 
  1. redis> shutdown

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. String masterName = "redis-master";

  3. Set<String> sentinels = new HashSet<String>();

  4. sentinels.add("192.168.8.203:26379");

  5. sentinels.add("192.168.8.204:26379");

  6. sentinels.add("192.168.8.205:26379");

  7. pool = new JedisSentinelPool(masterName, sentinels);

  8. return pool;

  9. }

Spring Boot 连接 Sentinel(springboot-redis:RedisAppTest.java)

 
   
   
 
  1. spring.redis.sentinel.master=redis-master

  2. spring.redis.sentinel.nodes=192.168.8.203:26379,192.168.8.204:26379,192.168.8.205:26379

哨兵机制的不足

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

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

Redis 分布式方案

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

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

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

  3. 基于服务端实现。

客户端 Sharding

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

ShardedJedis

 
   
   
 
  1. public class ShardingTest {

  2. public static void main(String[] args) {

  3. JedisPoolConfig poolConfig = new JedisPoolConfig();


  4. // Redis 服务器

  5. JedisShardInfo shardInfo1 = new JedisShardInfo("127.0.0.1", 6379);

  6. JedisShardInfo shardInfo2 = new JedisShardInfo("192.168.8.205", 6379);


  7. //连接池

  8. List<JedisShardInfo> infoList = Arrays.asList(shardInfo1, shardInfo2);

  9. ShardedJedisPool jedisPool = new ShardedJedisPool(poolConfig, infoList);

  10. ShardedJedis jedis = null;

  11. try{

  12. jedis = jedisPool.getResource();

  13. for(int i=0; i<100; i++){

  14. jedis.set("k"+i, ""+i);

  15. }

  16. for(int i=0; i<100; i++){

  17. System.out.println(jedis.get("k"+i));

  18. }

  19. }finally{

  20. if(jedis!=null) {

  21. jedis.close();

  22. }

  23. }

  24. }

  25. }

  • 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. redis-cli -p 7292

  3. redis-cli -p 7293

批量插入数据

类型 | 命令 -|- 集群 |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

注意: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. OK

  3. 127.0.0.1:7293> set a{qs}b 1

  4. OK

  5. 127.0.0.1:7293> set a{qs}c 1

  6. OK

  7. 127.0.0.1:7293> set a{qs}d 1

  8. OK

  9. 127.0.0.1:7293> set a{qs}e 1

  10. OK

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

客户端重定向

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

 
   
   
 
  1. 127.0.0.1:7291> set qs 1

  2. (error) MOVED 13724 127.0.0.1:7293

服务端返回 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

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

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

输入需要分配的哈希槽的数量(比如 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配置实战