利用redis-sentinel+consul实现redis高可用

利用redis-sentinel+consul实现redis高可用

使用redis-sentinelkeepalive实现redis高可用的方案在之前的文章《用redis-sentinelkeepalive实现redis的高可用》中有详细解释。redis-sentinel在本文中的应用领域也是如此。这也是Redis的个案服务。当一个Redis(主)服务意外停止或服务所属的服务器出现服务器宕机或网络问题等常见故障时，另一个Redis服务会自动从从变为主，显示Redis读写能力服务。redis-sentinel的装备可以参考上一篇文章，本文省略，只讨论consul对keepalived的替换。

因为keepalived的应用领域有限，比如它的密钥协议VRRP只在工作中的局域网(LAN)内，而不在工作中的局域网(inter-network，LAN)外，在不会自己 *** 纵互联网的情况下无法使用基金会，除非设置的VIP是针对局域网应用。因此，尤其是在云计算平台，应用云服务器(如阿里云服务器ECS等。)无法使用keepalived，只好想办法替换keepalived。作为服务注册和服务发现的最佳选择，Consul无疑可以取代keepalived。

在上面的例子中，keepalived用于显示顶层应用程序的VIP，以显示浏览频道。本文将keepalived替换为consul，利用consul的DNS接口为顶层应用显示Redis(master)的IP。

必要条件:必须有一个可用的consul集群，可以使用consul集群本身和环境变量注册服务，也可以向独立服务器注册，还可以使用HTTPAPI向Consul注册。

为了更好的获取Redis(主)的IP而不是Redis(从)的IP，可以通过脚本制作来完成验证。类似于keepalived的脚本制作，只是返回值设置为1为2。因为consul中返回值0是没问题(通过)，1是警告，2是关键。

以下是向独立服务器注册的示例。

Json环境变量如下:

{   "services": [     {       "id": "redisnode1",       "name": "redis",       "tags": [         "master"       ],       "address": "192.168.1.241",       "port": 6379,       "checks": [         {           "script": "/usr/local/sbin/redis-cli -h 192.168.1.241 -p 6379 info | grep role:master || exit 2",           "interval": "5s"         }       ]     },     {       "id": "redisnode2",       "name": "redis",       "tags": [         "master"       ],       "address": "192.168.1.242",       "port": 6379,       "checks": [         {           "script": "/usr/local/sbin/redis-cli -h 192.168.1.242 -p 6379 info | grep role:master || exit 2",           "interval": "5s"         }       ]     },     {       "id": "redisnode3",       "name": "redis",       "tags": [         "master"       ],       "address": "192.168.1.243",       "port": 6379,       "checks": [         {           "script": "/usr/local/sbin/redis-cli -h 192.168.1.243 -p 6379 info | grep role:master || exit 2",           "interval": "5s"         }       ]     }   ] }

注册是通过使用consul代理作为客户端 *** 作来完成的，假设consul集群中的服务器的详细地址是192.168.1.245。

mkdir -p /usr/local/consul/data /usr/local/consul/config    cat >/usr/local/consul/config/rediscluster.json<<eof {   "services": [     {       "id": "redisnode1",       "name": "redis",       "tags": [         "master"       ],       "address": "192.168.1.241",       "port": 6379,       "checks": [         {           "script": "/usr/local/sbin/redis-cli -h 192.168.1.241 -p 6379 info | grep role:master || exit 2",           "interval": "5s"         }       ]     },     {       "id": "redisnode2",       "name": "redis",       "tags": [         "master"       ],       "address": "192.168.1.242",       "port": 6379,       "checks": [         {           "script": "/usr/local/sbin/redis-cli -h 192.168.1.242 -p 6379 info | grep role:master || exit 2",           "interval": "5s"         }       ]     },     {       "id": "redisnode3",       "name": "redis",       "tags": [         "master"       ],       "address": "192.168.1.243",       "port": 6379,       "checks": [         {           "script": "/usr/local/sbin/redis-cli -h 192.168.1.243 -p 6379 info | grep role:master || exit 2",           "interval": "5s"         }       ]     }   ] } eof /bin/consul agent -advertise=$(ifconfig $(route -n | awk '/^0.0.0.0/ && /UG/ {print $NF}') | grep inet | egrep -v "(inet6|127.0.0.1)" | cut -d ":" -f2 | cut -d " " -f1) -bind=$(ifconfig $(route -n | awk '/^0.0.0.0/ && /UG/ {print $NF}') | grep inet | egrep -v "(inet6|127.0.0.1)" | cut -d ":" -f2 | cut -d " " -f1) -data-dir=/usr/local/consul/data -config-dir=/usr/local/consul/config -join 192.168.1.245

Nohup这个命令行可以在需要后台程序时添加>:/path/to/logfile2>；&1&

注意:在consuljson环境变量中，每个consul代理的服务id不能重复，名称是强制的，所以必须存在。如果省略id，就和名字一样，其他都是可选的，无关紧要。但是为了更好的应用某个服务信息内容，需要有IP和端口。自然，端口在应用中可以是特定的。最好有检查，否则有问题不能从consul取消注册。

注:cmd使用同一个子网IP(公网IP的详细地址)作为默认网关，规定详细地址和consul集群的详细地址可以互相浏览。在启动consul代理之前，下面两行指令中的一行可以清楚地表明是否考虑该标准:

consul info -rpc-addr=192.168.1.245:8400    consul members -rpc-addr=192.168.1.245:8400

consul代理启动后，Redis的信息内容会显示在consul中，包括UI、DNS接口和HTTPAPI。Redis的应用要将DNS偏向consul集群的详细DNS地址，这样才能查看到与Redis服务匹配的IP。

根据consulHTTPAPI中呈现的“curlHTTP://192.168.1.245:8500/v1/catalog/service/redis”的方法，现在的服务中只有一些连接点的例子:redis，但是无法区分什么是正常运行的连接点，什么是有任何问题的连接点。但是DNS接口模式“dig@192.168.1.245-p53redis.service.dc1.consult.any”可以准确找到可用连接点的IP，如下图所示。

例如，使用redis-cli测试Redis集群。

原文中只使用了consul的DNS接口来获取来到Redis集群的master的IP，但是没有获得端口。虽然根据“dig@192.168.1.245-p53redis.service.consulSRV”可以获得端口，但是对于顶级应用来说并不是很容易。毕竟对于大部分申请的域名，查看SRV记录并不容易。本文的consult是consultv0.6.0，现阶段有0.6.3的升级版本号可以应用。https://www.consul.io/downloads.html和领事大概还有其他功能更强大的IP和端口来获取服务，在整个申请过程中都会填充。关于领事的很多信息，请参考领事官网:https://www.consul.io/.

注意:可能的缺点。如果Redis主服务器有常见故障，那么原来的从服务器将成为新的主服务器，DNS缓存文件可能不容易更新。因此，在解决常见故障时，必须注意清除顶层使用的DNS缓存文件。

标签:redis集群，Redis高可用性，redis-sentinel，consulAPI，Redis主从复制

-结束-