王心妍，毛莉君
（西安培华学院，陕西西安,710125）
摘要：当传统数据库面临大规模数据访问时，磁盘I/O往往成为性能瓶颈，从而导致过高的响应延迟。本文基于Rdeis缓存技术，构建一个分布式缓存系统，为应用系统提供高可用性，高性能、高可靠性的分布式缓存系统。
关键词：Redis集；Twemproxy；Redis Cluster
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
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分片变化时，则需要通知所有的客户端来更新版本或修改
配置，导致系统不容易控制。
因为少了一个中间分发环节，这种静态分片技术在性能上比
mysql 字符串转数组
代理式优秀，但是其每一个Redis实例的增减，都得程序员手工
调整分片程序来实现，这就造成了其对研发人员超强的依赖性，
需要有较强的程序开发能力做后盾。一旦公司的主力程序员离
职，就可能会使新的负责人重新来定制，而且系统的升级相对也
比较麻烦。所以这种方式下，系统的可运维性较差。出现故障，定
位和解决都得研发和运维配合着解决，故障时间变长。基于此分
片机制的开源产品，现在仍不多见。
1.2  代理分片
代理分片方案（Proxy）就是在Redis集上添加一个代理
层，将分片工作交给专门的代理程序来做。代理程序接收到来自
业务程序的数据请求，根据路由规则，将这些请求分发给正确的
Redis实例并返回给业务程序。在这种机制下，一般会选用第三
方代理程序（而不是自己研发），因为后端有多个Redis实例，所
以这类程序又称为分布式中间件。这样的好处是，业务程序不用
关心后端Redis实例，运维起来也方便。虽然会因此带来些性能
损耗，但对于Redis这种内存读写型应用，相对而言是能容忍的。
该方案应用最具代表性的就是Twitter的开源产品
Twemproxy，其性能相当不错，是目前应用范围最广、稳定性最本文系陕西省教育厅2015年专项科研计划项目 “基于Android平台的电商服务系统的开发”（项目编号：15JK2094）的研究成果。
DOI:10.16520/jki.1000-8519.2016.06.008
受来自多个客户端程序的访问，按照路由规则，转发给后台的各个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 方案进行了改进，其结构图如下：
客户端通过虚拟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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。