分布式缓存集群方案特性使用场景（Memcache/Redis(Twemproxy/Codis/Redis-cluster)）优缺点对比及选型

分布式缓存集群方案特性使用场景（Memcache/Redis(Twemproxy/Codis/Redis-cluster)）优缺点对比及选型

 

分布式缓存特性：

1) 高性能:当传统数据库面临大规模数据访问时,磁盘I/O 每每成为性能瓶颈,从而致使太高的响应延迟.分布式缓存将高速内存做为数据对象的存储介质,数据以key/value 形式存储,理想状况下能够得到DRAM 级的读写性能;
2) 动态扩展性:支持弹性扩展,经过动态增长或减小节点应对变化的数据访问负载,提供可预测的性能与扩展性;同时,最大限度地提升资源利用率;
3) 高可用性:可用性包含数据可用性与服务可用性两方面.基于冗余机制实现高可用性,无单点失效(single point of failure),支持故障的自动发现,透明地实施故障切换,不会因服务器故障而致使缓存服务中断或数据丢失.动态扩展时自动均衡数据分区,同时保障缓存服务持续可用;
4) 易用性:提供单一的数据与管理视图;API 接口简单,且与拓扑结构无关;动态扩展或失效恢复时无需人工配置;自动选取备份节点;多数缓存系统提供了图形化的管理控制台,便于统一维护;
5) 分布式代码执行(distributed code execution):将任务代码转移到各数据节点并行执行,客户端聚合返回结果,从而有效避免了缓存数据的移动与传输.最新的Java 数据网格规范JSR-347中加入了分布式代码执行与Map/reduce 的API 支持,各主流分布式缓存产品,如IBM WebSphere eXtreme Scale,VMware GemFire,GigaSpaces XAP 和Red Hat Infinispan 等也都支持这一新的编程模型.

 

 

分布式缓存应用场景：

1) 页面缓存.用来缓存Web 页面的内容片断,包括HTML、CSS 和图片等,多应用于社交网站等;
2) 应用对象缓存.缓存系统做为ORM 框架的二级缓存对外提供服务,目的是减轻数据库的负载压力,加速应用访问;
3) 状态缓存.缓存包括Session 会话状态及应用横向扩展时的状态数据等,这类数据通常是难以恢复的,对可用性要求较高,多应用于高可用集群;（解决分布式Web部署的session同步问题）
4) 并行处理.一般涉及大量中间计算结果须要共享;
5) 事件处理.分布式缓存提供了针对事件流的连续查询(continuous query)处理技术,知足实时性需求;
6) 极限事务处理.分布式缓存为事务型应用提供高吞吐率、低延时的解决方案,支持高并发事务请求处理,多应用于铁路、金融服务和电信等领域.

7）云计算领域提供分布式缓存服务（例如：青云、 

UnitedStack等）

6） 

任何须要用到缓存的地方，解决本地缓存数据量过小问题。分布式缓存能有效防止本地缓存失效数据库雪崩现象。

 

 

 

两大开源缓存系统对比，Memcache VS Redis：

一、Redis不只仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。而memcache只支持简单数据类型，须要客户端本身处理复杂对象

二、Redis支持数据的持久化，能够将内存中的数据保持在磁盘中，重启的时候能够再次加载进行使用（PS：持久化在rdb、aof）。Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，而后在子进程中循环全部的数据，将数据写成为RDB文件。  AOF日志的全称是append only file，从名字上咱们就能看出来，它是一个追加写入的日志文件。与通常数据库的binlog不一样的是，AOF文件是可识别的纯文本，它的内容就是一个个 的Redis标准命令。固然，并非发送发Redis的全部命令都要记录到AOF日志里面，只有那些会致使数据发生修改的命令才会追加到AOF文件。那么每一条修改数据的命令都生成一条日志。（PS：memcache不支持数据持久存储）

三、因为Memcache没有持久化机制，所以宕机全部缓存数据失效。Redis配置为持久化，宕机重启后，将自动加载宕机时刻的数据到缓存系统中。具备更好的灾备机制。

四、Memcache可使用Magent在客户端进行一致性hash作分布式。Redis支持在服务器端作分布式（PS:Twemproxy/Codis/Redis-cluster多种分布式实现方式）

五、Memcached的简单限制就是键（key）和Value的限制。最大键长为250个字符。能够接受的储存数据不能超过1MB（可修改配置文件变大），由于这是典型slab 的最大值，不适合虚拟机使用。而Redis的Key长度支持到512k。

六、Redis使用的是单线程模型，保证了数据按顺序提交。Memcache须要使用cas保证数据一致性。CAS（Check and Set）是一个确保并发一致性的机制，属于“乐观锁”范畴；原理很简单：拿版本号，操做，对比版本号，若是一致就操做，不一致就放弃任何操做

cpu利用。因为Redis只使用单核，而Memcached可使用多核，因此平均每个核上Redis在存储小数据时比Memcached性能更 高。而在100k以上的数据中，Memcached性能要高于Redis 。（PS：Redis能够经过开启多个实例来提升CPU利用率，Memcache默认是单线程，须要编译指定参数才能支持多线程。因为分布式缓存是IO密集型系统，因此性能不少程度受限于网络通讯，memcache使用了libevent网络库，redis本身实现了一套本身通讯的库。线程也不是影响吞吐量的重要因素。如第一点来讲，通常状况下，程序处理内存数据的速度远高于网卡接收的速度。使用线程好处是能够同时处理多条链接，在极端状况下，可能会提升响应速度。可是单线程有时候比多线程 或多进程更快，比须要考虑并发、锁，也不会增长上下文切换等开销，也即代码更加简洁，执行效率更高。）

七、memcache内存管理：使用Slab Allocation。原理至关简单，预先分配一系列大小固定的组，而后根据数据大小选择最合适的块存储。避免了内存碎片。（缺点：不能变长，浪费了必定空间）memcached默认状况下下一个slab的最大值为前一个的1.25倍。八、redis内存管理： Redis经过定义一个数组来记录全部的内存分配状况， Redis采用的是包装的malloc/free，相较于Memcached的内存 管理方法来讲，要简单不少。因为malloc 首先以链表的方式搜索已管理的内存中可用的空间分配，致使内存碎片比较多。

 

总结：

其实对于企业选型Memcache、Redis而言，更多仍是应该看业务使用场景（由于Memcache、Redis二者都具备足够高的性能和稳定性）。倘若业务场景须要用到持久化缓存功能、或者支持多种数据结构的缓存功能，那么Redis则是最佳选择。

（PS：Redis集群解决方式也优于Memcache，Memcache在客户端一致性hash的集群解决方案，Redis采用无中心的服务器端集群解决方案）

综上所述：为了让缓存系统可以支持更多的业务场景，选择Redis会更优。（目前也愈来愈多的厂商选择Redis）。

 

 

接下来重点对比Redis三大集群解决方案对比，Twemproxy VS Codis VS Redis-cluster

Redis集群三种常见的解决方案：

一、客户端分片：这种方案将分片工做放在业务程序端，程序代码根据预先设置的路由规则，直接对多个Redis实例进行分布式访问。这样的好处是，不依赖于第三方分布式中间件，实现方法和代码都本身掌控，可随时调整，不用担忧踩到坑。这其实是一种静态分片技术。Redis实例的增减，都得手工调整分片程序。基于此分片机制的开源产品，如今仍很少见。这种分片机制的性能比代理式更好（少了一个中间分发环节）。但缺点是升级麻烦，对研发人员的我的依赖性强——须要有较强的程序开发能力作后盾。若是主力程序员离职，可能新的负责人，会选择重写一遍。因此，这种方式下，可运维性较差。出现故障，定位和解决都得研发和运维配合着解决，故障时间变长。所以这种方案，难以进行标准化运维，不太适合中小公司（除非有足够的DevOPS）。

二、代理 分片：这种方案，将分片工做交给专门的代理程序来作。代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的Redis实例并返回给业务程序。这种机制下，通常会选用第三方代理程序（而不是本身研发），由于后端有多个Redis实例，因此这类程序又称为分布式中间件。这样的好处是，业务程序不用关心后端Redis实例，运维起来也方便。虽然会所以带来些性能损耗，但对于Redis这种内存读写型应用，相对而言是能容忍的。这是咱们推荐的集群实现方案。像基于该机制的开源产品Twemproxy，Codis即是其中表明，应用很是普遍。

三、服务器端分片：创建在基于无中心分布式架构之上（没有代理节点性能瓶颈问题）。Redis-Cluster即为官方基于该架构的解决方案。Redis Cluster将全部Key映射到16384个Slot中，集群中每一个Redis实例负责一部分，业务程序经过集成的Redis Cluster客户端进行操做。客户端能够向任一实例发出请求，若是所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据。Redis Cluster的成员管理（节点名称、IP、端口、状态、角色）等，都经过节点之间两两通信，按期交换并更新。

 

接下来分别讲解各解决方案表明产品实现方式优缺点：

Twemproxy：

Twemproxy是一种代理分片机制，由Twitter开源。Twemproxy做为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。这个方案瓜熟蒂落地解决了单个Redis实例承载能力的问题。固然，Twemproxy自己也是单点，须要用Keepalived作高可用方案。这么些年来，Twemproxy是应用范围最广、稳定性最高、最久经考验的分布式中间件。只是，他还有诸多不方便之处。Twemproxy最大的痛点在于，没法平滑地扩容/缩容。这样增长了运维难度：业务量突增，需增长Redis服务器；业务量萎缩，须要减小Redis服务器。但对Twemproxy而言，基本上都很难操做。或者说，Twemproxy更加像服务器端静态sharding。有时为了规避业务量突增致使的扩容需求，甚至被迫新开一个基于Twemproxy的Redis集群。Twemproxy另外一个痛点是，运维不友好，甚至没有控制面板。

 

Codis：

Codis由豌豆荚于2014年11月开源，基于Go和C开发，是近期涌现的、国人开发的优秀开源软件之一。现已普遍用于豌豆荚的各类Redis业务场景，从各类压力测试来看，稳定性符合高效运维的要求。性能更是改善不少，最初比Twemproxy慢20%；如今比Twemproxy快近100%（条件：多实例，通常Value长度）。Codis具备可视化运维管理界面。Codis无疑是为解决Twemproxy缺点而出的新解决方案。所以综合方面会因为Twemproxy不少。目前也愈来愈多公司选择Codis。Codis引入了Group的概念，每一个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样作的好处是，若是当前Master有问题，则运维人员可经过Dashboard“自助式”切换到Slave，而不须要当心翼翼地修改程序配置文件。为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分红1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。

 

Redis-cluster：

reids-cluster在redis3.0中推出，支持Redis分布式集群部署模式。采用无中心分布式架构。全部的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.节点的fail是经过集群中超过半数的节点检测失效时才生效.客户端与redis节点直连,不须要中间proxy层.客户端不须要链接集群全部节点,链接集群中任何一个可用节点便可，减小了代理层，大大提升了性能。redis-cluster把全部的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->key之间的关系。目前Jedis已经支持Redis-cluster。从计算架构或者性能方面无疑Redis-cluster是最佳的选择方案。（PS：虽然Redis-cluster从方案选型上面比较占据优点，可是因为Redis-cluster刚推出不久，虽然官方宣传已经发布的是文档版本，但稳定性方面还有待验证）