此篇简要介绍一下Redis的集群代理方案:Twemproxy。

背景

Redis单实例内存容量有限,为了提高系统承载能力,就必须使用到Redis集群

根据执行分片的位置,可以分为三种分片方式:

集群技术

1. 客户端分片

  1. 客户端分片:客户端使用一致性哈希等算法决定应当分布到哪个节点。
  2. 由业务方的程序代码设置路由规则,直接对多个Redis实例进行分布式访问
  3. 优点是可以灵活调整路由规则,另外性能比代理方式好一些(少了一个中间分发的环节)
  4. 缺点是Redis实例数量变化时需要手动调整分片,升级麻烦,可运维性较差

2. 代理分片

  1. 代理分片:将客户端的请求发送到代理上,由代理转发到正确的节点上。
  2. 通过增加一个对业务方使用透明的代理层,来执行分片工作
  3. 增加代理层虽然带来了一些多余的性能损耗,但是可以容忍
  4. 基于该机制的开源产品Twemproxy

3. 服务器分片:Redis Cluster

  1. 没有中心节点(和代理模式的重要不同之处)
  2. Redis Cluster将所有Key映射到多个Slot中,集群中每个Redis实例负责一部分,业务程序通过集成的Redis Cluster客户端进行操作。客户端可以向任一实例发出请求,如果所需数据不在该实例中,则该实例引导客户端自动去对应实例读写数据。
  3. 缺点是这是一个非常重的方案,Redis Cluster的成员管理(节点名称、IP、端口、状态、角色)等,都通过节点之间两两通讯,定期交换并更新,缺少了Redis单例的“简单、可依赖”的特点

Twemproxy

Twemproxy是Twitter公司开发的,代理分片构建Redis集群的一个开源解决方案

优势

  1. 单线程工作,用C语言开发
  2. 直接支持大部分Redis指令,对于业务层可以透明使用
  3. 应用层不必关心连接失败,,由代理负责重连
  4. 代理后边的升级,前端不关心,解决了HA的问题
  5. 把Hash算法放到了代理上做,路由策略多样,支持HashTag, 通过HashTag可以自己设定将同一类型的key映射到同一个实例上去
  6. 减少与redis的直接连接数,保持与redis的长连接,可设置代理与后台每个redis连接的数目
  7. 自带一致性hash算法,能够将数据自动分片到后端多个redis实例上
  8. 支持redis pipelining request,将多个连接请求,组成reids pipelining统一向redis请求
    高效,对连接的管理采用epoll机制,内部数据传输采用“Zero Copy”技术,以提高运行效率

高可用方案

因为Twemproxy本身是单点,所以需要用Keepalived做高可用方案

Keepalived是一种实现高可用的方案,它的功能主要包括两方面:

  1. 通过IP漂移,实现服务的高可用:服务器集群共享一个虚拟IP,同一时间只有一个服务器占有虚拟IP并对外提供服务,若该服务器不可用,则虚拟IP漂移(VIP自动切换的过程就称为IP漂移)至另一台服务器并对外提供服务
  2. 对LVS应用服务层的应用服务器集群进行状态监控:若应用服务器不可用,则keepalived将其从集群中摘除,若应用服务器恢复,则keepalived将其重新加入集群中

性能

经过一层代理后,官方给出的极限情况性能下降20%