Nodejs对接redis sentinel

注：该文档的实验环境基于《redis高可用方案redis sentinel的介绍和实践》搭建，如有疑问详见上述文档

本文档是对《redis高可用方案redis sentinel的介绍和实践》的一些补充，主要说明使用nodejs来对接redis sentinel，以及进行简单的容灾实验测试。

redis-sentinel对接

nodejs对接redis sentinel使用到的库是redis-sentinel，使用的详情如下

const sentinel = require('redis-sentinel');
const sentinels = [ // 哨兵节点的地址与端口集合
  { host: '172.17.0.1', port: 26380 },
  { host: '172.17.0.1', port: 26381 },
  { host: '172.17.0.1', port: 26382 },
]
const masterName = 'master'; // master节点的名字
const opts = { // node_redis的相关属性设置
  auth_pass: 'password', // 在版本较低的node_redis中使用auth_password作为密码，redis-sentinel及时属于版本较低的node_redis
  // password: 'password', // 在版本高的node_redis中的密码属性
  db: 0, // 如果设置，客户端将在连接上运行Redis select命令。
};

// 创建redisClient实例
const redisClient = sentinel.createClient(sentinels, masterName, opts);

redisClient.set('testName', 'lxjTest1');

实验

正常情况下读写操作

不出所料的读写操作正常，主节点和分支节点都能正确的查询到设置的值。

关闭master节点之后的读写操作

将master节点停掉之后，写入失败，获取不到信息

127.0.0.1:6382> get testName
(nil)

大约20-30秒之后，nodejs程序在控制台打出

Received +switch-master message from Redis Sentinel.  Reconnecting clients.

表示redis主从节点切换成功，此时通过slave-1和slave-2均能查到插入信息。通过命令行查看节点的状态，发现端口为6082的redis变成了master节点。

127.0.0.1:6382> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=172.17.0.1,port=6381,state=online,offset=1543804,lag=1

恢复关闭节点继续读写操作

将关闭的docker容器重新启动，待状态显示已经连上去之后继续进行模拟读写请求，结果也没有出人意表，可以正常进行读写操作。

127.0.0.1:6382> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.17.0.1,port=6381,state=online,offset=1576998,lag=1
slave1:ip=172.17.0.1,port=6380,state=online,offset=1576998,lag=1

仅剩一个节点的读写操作

使用docker命令关闭节点，在关闭节点过程中先关闭了一个slave节点，服务器控制台没有任何异常，读写操作正常。

当剩下两个节点的时候，尝试关闭当时的master节点。此时的情况与关闭主节点之后的读写操作一个情况。在大约20-30秒之后，nodejs程序在控制台打出

Received +switch-master message from Redis Sentinel.  Reconnecting clients.

表示redis主从节点切换成功，此时读写操作正常进行。

结论

redis sentinel主从节点在不全部挂掉的情况下，不会影响整个系统的正常运行。但是主节点挂掉会导致服务器处于十几秒的无法正常操作状态，从节点则不影响。