Redis集群方案的对比

Redis集群方案

长期以来，Redis本身仅支持单实例，内存一般最多10~20GB。这无法支撑大型线上业务系统的需求。而且也造成资源的利用率过低，毕竟现在服务器内存动辄100~200GB。

为解决单机承载能力不足的问题，出现了不少集群方案，物理上把数据“分片”存储在多个Redis实例。（一般情况下，每一片对应一个Redis实例）

其中最主要有下面两种方式：

l Redis官方近期推出的Redis Cluster，通过节点之间两两通讯来实现成员管理，去中心化。

l 代理分片：通过第三方代理程序来管理后端多个Redis分片，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。其中Twemproxy就是这种第三方代理的代表之一。

---------------------Twemproxy + Redis VS RedisCluster---------------------

Twemproxy + Redis分片

Redis单实例“简单、可依赖”但是承载能力不足，Twemproxy代理Redis分片恰恰弥补了这个缺陷。而且这些年来，应用范围广、稳定性高、技术也比较成熟。

不过其缺点也不可忽视：

Twemproxy最大的痛点在于，无法平滑地扩容/缩容。Twemproxy更加像服务器端静态sharding，有时为了规避业务量突增导致的扩容需求，甚至被迫新开一个基于Twemproxy的Redis集群。

另外，Twemproxy本身也是单点，需要用Keepalived做高可用方案，再加上lvs负载均衡等组件，导致架构复杂，维护管理成本高。而且层次负载增加了问题定位排查的成本。

Redis Cluster

官方推出的Redis集群解决方案，通过Redis节点之间两两通讯，定期交换并更新，来实现成员管理（节点名称、IP、端口、状态、角色）。在这种机制下，没有中心节点（和代理模式的重要不同之处）。客户端可以向任一实例发出请求，如果所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据。

而且解决了Twemproxy不能在线扩容的问题，支持HA，架构简单，更便于扩展和维护。

当然也会带来不足的地方：

l 加重Redis实例，已经不是“简单、可依赖”了。

l 对数据的批量读写性能不是很好。根本原因在于数据存在不同的分片，其次客户端驱动的支持目前不是很完善。（如pipeline 和 multi key等操作）

l 在线扩容和数据resharding需要自动化工具支持，rediscluster目前不能智能的实现auto resharding。

l 不能构建跨机房的只读集群。（twemproxy可以通过复制实现）



-----------相关阅读----------------------------------------------------------------------------------------

Twemproxy

twemproxy(也叫nutcraker)，是twitter开源的一个redis和memcache代理服务器，来统一管理多个redis。 （简介见http://cloudaice.com/twemproxy-explore/）

LVS

LVS是LinuxVirtual Server的简写，即Linux虚拟服务器，是一个虚拟的服务器集群系统。

LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。

一般来说，LVS集群采用三层结构，其主要组成部分为：

A. 负载调度器（loadbalancer），它是整个集群对外面的前端机-调度器，负责将客户的请求发送到一组服务器上执行，看起来是来自一个IP地址（可称之为虚拟IP地址）。

B. 服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。

C. 共享存储（sharedstorage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。【共享存储通常是数据库、网络文件系统或者分布式文件系统。】



对大多数网络服务来说，请求间不存在很强的相关性，请求可以在不同的结点上并行执行，所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。