高可用Redis服务架构方案.pdfVIP

高可用 Redis 服务架构方案 1 基于内存的 Redis 应该是目前各种 web 开发业务中最为常用的 key-value 数据库了，我们经常在业 务中用其存储用户登陆态（ Session 存储），加速一些热数据的查询（相比较 mysql 而言，速度有数 量级的提升），做简单的消息队列（ LPUSH 和 BRPOP ）、订阅发布（ PUB/SUB ）系统等等。规模 比较大的互联网公司， 一般都会有专门的团队， 将 Redis 存储以基础服务的形式提供给各个业务调用。 不过任何一个基础服务的提供方，都会被调用方问起的一个问题是：你的服务是否具有高可用性？最 好不要因为你的服务经常出问题，导致我这边的业务跟着遭殃。最近我所在的项目中也自己搭了一套 小型的“高可用” Redis 服务，在此做一下自己的总结和思考。 首先我们要定义一下对于 Redis 服务来说怎样才算是高可用， 即在各种出现异常的情况下， 依然可以 正常提供服务。或者宽松一些，出现异常的情况下，只经过很短暂的时间即可恢复正常服务。所谓异 常，应该至少包含了以下几种可能性： 【异常 1 】某个节点服务器的某个进程突然 down 掉 （例如某开发手残，把一台服务器的 redis-server 进程 kill 了） 【异常 2 】某台节点服务器 down 掉，相当于这个节点上所有进程都停了（例如某运维手残，把一个 服务器的电源拔了；例如一些老旧机器出现硬件故障） 2 【异常 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 3 一般情况下，我们搭的个人网站，或者平时做开发时，会起一个单实例的 Redis Server 。调用方直接 连接 Redis 服务即可，甚至 Client 和 Redis 本身就处于同一台服务器上。这种搭配仅适合个人学习 娱乐， 毕竟这种配置总会有单点故障的问题无法解决。一旦 Redis 服务进程挂了，或者服务器 1 停机 了，那么服务就不可用了。并且如果没有配置 Redis 数据持久化的话， Redis 内部已经存储的数据也