基于Twemproxy的Redis集群解决方案的设计与实现

王心妍,毛莉君（西安培华学院，陕西西安,710125）



基于Twemproxy的Redis集群解决方案的设计与实现

王心妍,毛莉君
（西安培华学院，陕西西安,710125）

摘要：当传统数据库面临大规模数据访问时,磁盘I/O往往成为性能瓶颈,从而导致过高的响应延迟。本文基于Rdeis缓存技术,构建一个分布式缓存系统,为应用系统提供高可用性,高性能、高可靠性的分布式缓存系统。

关键词：Redis集群；Twemproxy；Redis Cluster

本文系陕西省教育厅2015年专项科研计划项目“基于Android平台的电商微信服务系统的开发”（项目编号：15JK2094）的研究成果。

0 引言

随着移动4G的飞速发展，越来越多的人参与网络应用，在服务器面临海量请求压力的同时，用户对请求响应时间则提出了更高的要求，传统磁盘持久化数据库根本无法应对这样的需求，内存数据库则应运而生。

Redis是内存数据库中的佼佼者，是基于内存的开源的高性能Key/Value数据库，不仅支持多种数据结构和主从复制，还支持数据的持久化，即使服务器异常重启也不会导致内存数据的全部丢失。

原生的Redis是单进程单线程的，在处理超大数据请求时就造成其他请求的阻塞，而且如果单个Redis实例占用的容量过大，则会影响出现故障时服务的恢复速度以及平常的运行维护操作。因此仅仅使用单个Redis实例是无法满足生产环境中的I/O操作、稳定性、安全性、可靠性等方面的要求，所以我们需要考虑搭建一个稳定、可靠、高性能的Redis分布式集群来满足现实生产的需要，并满足用户对高一致性、可用性、分区容忍性的要求。

1 Redis集群解决方案

当单机Redis无法承受系统所产生的超量数据时，就需要依靠分布式的多机系统来解决。在对用户透明的情况下，分布式系统为数据配置多个副本，当其中一台或多台机器宕机，却不会丢失数据或者影响用户的访问，其可靠性安全性远远高于单机，当然对于高并发请求的处理也完胜单机系统。

目前各大互联网公司为解决Redis单机承载能力不足的问题，自主研发并实现了自己的Redis分布式集群化方案。在这些非官方集群解决方案中，物理上把数据“分片”（sharding）存储在多个Redis实例中，一般情况下，每一“片”就是一个Redis实例。目前Redis分布式集群方案主要有三种实现机制：客户端分片、代理分片和Redis Cluster。

1.1 客户端分片

客户端分片（Pre-sharding）方案就是将分片工作放在业务的程序端，程序代码根据预先设置的路由规则，直接对多个Redis实例进行分布式访问。该方案集中在客户端，在客户端预先对 key 进行 hash 取模，然后选择后端的 Redis实例，不依赖于第三方分布式中间件，要求开发者完全做自己的定制，实现方法和代码都自己掌控，可以随时调整，但是一旦遇到后端Redis分片变化时，则需要通知所有的客户端来更新版本或修改配置，导致系统不容易控制。

因为少了一个中间分发环节，这种静态分片技术在性能上比代理式优秀，但是其每一个Redis实例的增减，都得程序员手工调整分片程序来实现，这就造成了其对研发人员超强的依赖性，需要有较强的程序开发能力做后盾。一旦公司的主力程序员离职，就可能会使新的负责人重新来定制，而且系统的升级相对也比较麻烦。所以这种方式下，系统的可运维性较差。出现故障，定位和解决都得研发和运维配合着解决，故障时间变长。基于此分片机制的开源产品，现在仍不多见。

1.2 代理分片

代理分片方案（Proxy）就是在Redis集群上添加一个代理层，将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。在这种机制下，一般会选用第三方代理程序（而不是自己研发），因为后端有多个Redis实例，所以这类程序又称为分布式中间件。这样的好处是，业务程序不用关心后端Redis实例，运维起来也方便。虽然会因此带来些性能损耗，但对于Redis这种内存读写型应用，相对而言是能容忍的。

该方案应用最具代表性的就是Twitter的开源产品Twemproxy，其性能相当不错，是目前应用范围最广、稳定性最高、最久经考验的分布式中间件。Twemproxy作为代理，可接受来自多个客户端程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回，有效地解决了单个Redis实例承载能力的问题。当然，Twemproxy本身也是单点，需要用Keepalived做高可用方案。

该方案通过代理的方式减少了Redis服务器的连接数，支持一致性Hash，通过配置的方式封禁失效的节点，运行多个 Proxy时，客户端可以连接到首个可用的Proxy，支持请求的流式和批处理，可以降低请求的资源消耗，但是Twemproxy不支持自动的故障切换。

1.3 Redis Cluster

Redis Cluster和代理模式最大的不同之处在于没有中心节点。Redis Cluster将所有Key映射到16384个Slot中，集群中每个Redis实例负责一部分，业务程序通过集成的Redis Cluster客户端进行操作。客户端可以向任一实例发出请求，如果所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据，因此Redis进程既负责读写数据又负责集群交互，致使其严格依赖客户端driver的成熟度。而且Redis Cluster的节点名称、IP、端口、状态、角色等的管理，都是通过节点之间两两通讯，定期交换并更新，集群建立以及运行中新增结点时，都要通过手动执行meet命令或redis-trib.rb脚本添加到集群中，缺少结点的自动发现和自动Resharding功能。虽说它比代理分片少了中间件，理论上会更高效，但其是否完全适合现实的生产环境，还需要实践慢慢验证。因此，本文主提出基于twemproxy搭建高可用的Redis集群解决方案。

2 基于twemproxy的Redis集群解决方案

Twemproxy是由Twitter开发的开源Redis集群解决方案，其性能不错，也很适合现实的生产应用，但它不支持自动的故障切换。本方案对原生的Twemproxy方案进行了改进，其结构图如下：

客户端通过虚拟IP访问Redis，只需要用keepalived的虚拟IP地址和端口而不需要修改RedisClient代码。keepalived提供VIP漂移，避免Twemproxy的单点故障 ，减少与Redis的直接连接数，支持失败节点自动删除。keeypalived集群保证一个挂机,其他的可以继续服务，其中每个keepalive又连接多个Twemproxy(默认是连接主Twemproxy, 主代理挂机了,会去连接从Twemproxy)。Twemproxy的每个节点都连接Redis的主服务，Redis的主从服务器,一般分开机器存储,保证机器故障而数据不丢失。Sentinel起到一个监控的作用，一旦发现主Redis挂机了,就会自动切换将从Redis变为主Redis，以实现Redis的高可用性。Twemproxy_agent的作用是：如果sentinel发现变化，agent会去修改Twemproxy 的配置文件,然后重启Temproxy服务。

该方案中平行部署多个代理层，客户端可以自动选择可用的一个，Redis集群对客户端透明，每一个Redis划分主、从服务器，并交叉分开存储以确保数据的安全，支持状态监控，实现了高吞吐量。

参考文献

[1]黄健宏. Redis设计与实现[M]．北京：机械工业出版社，2014：1-300

[2]邱祝文.基于Redis的分布式缓存系统架构研究［J］．网络安全技术与应用，2014.10

Design and implementation of Redis cluster solution based on Twemproxy

Wang Xinyan,Mao Lijun
(Xi'an Peihua University,Xi'an,Shaanxi,710125)

Abstract：When the traditional database facing massive data access,disk I/O often become a performance bottleneck,resulting in high response delay.In this paper,Rdeis cache technology based on building a distributed cache system, provide high availability for application system,distributed caching system with high performance and high reliability.

Keywords：Redis Twemproxy;Redis Cluster cluster