背景介绍

主要介绍我们目前 redis 部署的架构,我们采用的 redis 是 2.8 版本,所以下面的讲解都是基于这个版本的讲解。

twemproxy

twemproxy 是 twitter 开发的项目,实现了 redis 和 Memcached 的协议,可以代理 redis 和 Memcached 的请求。关于 twemproxy 不做更多的介绍,我们使用 twemproxy 是采用的 fnv1a_64 hash 算法,twemproxy 支持多种 hash 一致性算法,具体的可以看说明文档,根据自身情况采用合适的算法。

redis-sentinel

因为我们使用的 Redis 版本是 2.8,所以在主从架构中我们使用了 redis-sentinel 来部署,关于 redis-sentinel 文档可以看这里,几个特性如下:

  • 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  • 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  • 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。

架构现状

目前的架构我们采用了多代理 + 主从结构,而且在代理 twemproxy 层面并没有做 keep-alived,相当于客户端直接面向了多个代理地址,需要客户端自己去完成代理地址是否可用的处理和判断,而 twemproxy 后端对应的是多个 master-slave 结构,master-slave 通过 redis-sentinel 可以进行自动故障迁移,架构图如下:

redis cluster 工作原理

客户端在使用的时候是面向了三个地址:

S1:26370
S2:26370
S3:26370

每个 26371 后面对应了三个 (S1,S2,S3):6370,6370 对应的是一个 master-slave 结构,并且是交叉部署在不同的服务器上,从上面的结构可以看出,如果其中一台服务器挂掉是不会有问题的,但是如果 2 台挂掉就会有问题,因为数据是通过 twemproxy hash 不同的 master-slave 结构上的,而 master-slave 也做了交叉部署,如果 1 台 Server 有问题,2 台是可以正常工作的,如果 2 台挂了,就会导致数据丢失。

优点&缺点

  • 通过代理在数据存储上进行了数据实例分片,提高了数据存储的容量
  • 通过多点部署,基本实现了高可用
  • 没有对 twemproxy 做 keepalived,客户端需要面向多个地址,自行判断 server 时否存活,向 PHP 这类语言带来了很大的开销,每次请求都要去处理验活
  • 如果两个服务器不可用,数据会丢失

从目前的整体架构上来看,缺点还是比较多的,除了 master-slave 可以自动迁移以外,客户端处理验活也是个问题。

使用过程中的问题

因为目前采用代理,数据是根据 key 进行了分片存储的,所以不支持批量数据操作和一些 select database 这样的操作,如果代码中配置了这样的初始化参数,可能导致无法建立连接等。

展望

  • twemproxy 配置 keepalived,客户端只关注一个地址
  • 升级 Redis,通过 redis-cluster 来做集群

总结本期的内容

  • twemproxy
  • redis-sentinel
  • redis-cluster

文中也涉及了一些引用链接,大家可以点进去读读,本次内容比较简单,现在也有一些其它的代理工具例如 Codis,都可以自己去了解下。

EOF;