6 高可用Redis服务架构分析与搭建.docxVIP

高可用Redis服务架构分析与搭建 2021-03-26 基于内存的Redis应当是目前各种web开发业务中最为常用的key-value数据库了，我们经常在业务中用其存储用户登陆态（Session存储），加速一些热数据的查询（相比较mysql而言，速度有数量级的提升），做简约的消息队列（LPUSH和BRPOP）、订阅发布（PUB/SUB）系统等等。规模比较大的互联网公司，一般都会有特地的团队，将Redis存储以基础服务的方式供应应各个业务调用。 不过任何一个基础服务的供应方，都会被调用方问起的一个问题是：你的服务能否具有高可用性？最好不要由于你的服务经常出问题，导致我这边的业务跟着遭殃。最近我所在的项目中也本人搭了一套小型的“高可用”Redis服务，在此做一下本人的总结和思考。 首先我们要定义一下对于Redis服务来说怎样才算是高可用，即在各种消灭特别的情况下，照旧可以正常供应服务。或者宽松一些，消灭特别的情况下，只经过很短暂的时间即可恢复正常服务。所谓特别，应当至少包含了以下几种可能性： 【特别1】某个节点服务器的某个进程突然down掉（例如某开发手残，把一台服务器的redis-server进程kill了） 【特别2】某台节点服务器down掉，相当于这个节点上全部进程都停了（例如某运维手残，把一个服务器的电源拔了；例如一些老旧机器消灭硬件毛病） 【特别3】任意两个节点服务器之间的通信中缀了（例如某临时工手残，把用于两个机房通信的光缆挖断了） 其实以上任意一种特别都是小概率大事，而做到高可用性的基本指点思想就是：多个小概率大事同时发生的概率可以忽视不计。只需我们设计的系统可以容忍短时间内的单点毛病，即可实现高可用性。 对于搭建高可用Redis服务，网上已有了很多方案，例如Keepalived，Codis，Twemproxy，Redis Sentinel。其中Codis和Twemproxy次要是用于大规模的Redis集群中，也是在Redis官方发布Redis Sentinel之前twitter和豌豆荚供应的开源处理方案。我的业务中数据量并不大，所以搞集群服务反而是铺张机器了。最终在Keepalived和Redis Sentinel之间做了个选择，选择了官方的处理方案Redis Sentinel。 Redis Sentinel可以理解为一个监控Redis Server服务能否正常的进程，并且一旦检测到不正常，可以自动地将备份（slave）Redis Server启用，使得外部用户对Redis服务内部消灭的特别无感知。我们依据由简至繁的步骤，搭建一个最小型的高可用的Redis服务。 ? 方案1：单机版Redis Server，无Sentinel 一般情况下，我们搭的个人网站，或者平常做开发时，会起一个单实例的Redis Server。调用方直接连接Redis服务即可，甚至Client和Redis本身就处于同一台服务器上。这种搭配仅适合个人学习消遣，到底这种配置总会有单点毛病的问题无法处理。一旦Redis服务进程挂了，或者服务器1停机了，那么服务就不行用了。并且假如没有配置Redis数据长久化的话，Redis内部已经存储的数据也会丢失。 ? 方案2：主从同步Redis Server，单实例Sentinel 为了实现高可用，处理方案1中所述的单点毛病问题，我们必需添加一个备份服务，即在两台服务器上分别各启动一个Redis Server进程，一般情况下由master供应服务，slave只担任同步和备份。与此同时，在额外启动一个Sentinel进程，监控两个Redis Server实例的可用性，以便在master挂掉的时候，准时把slave提升到master的角色连续供应服务，这样就实现了Redis Server的高可用。这基于一个高可用服务设计的依据，即单点毛病本身就是个小概率大事，而多个单点同时毛病（即master和slave同时挂掉），可以认为是（基本）不行能发生的大事。 对于Redis服务的调用方来说，现在要连接的是Redis Sentinel服务，而不是Redis Server了。常见的调用过程是，client先连接Redis Sentinel并询问目前Redis Server中哪个服务是master，哪些是slave，然后再去连接相应的Redis Server进行操作。当然目前的第三方库一般都已经实现了这一调用过程，不再需要我们手动去实现（例如Nodejs的ioredis，PHP的predis，Golang的go-redis/redis，JAVA的jedis等）。 然而，我们实现了Redis Server服务的主从切换之后，又引入了一个新的问题，即Redis Sentinel本身也是个单点服务，一旦Sentinel