缓存选型方案

本文档用于在决定缓存选型方案时用于讨论使用Memcached还是Redis，以及何时选择使用Twemproxy+ MC/Redis的分布式部署方案（Mongodb等NewSQL服务暂不列入考虑之中）

 

1.Memcached的优点：

• Memcached可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，日常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。

• 支持直接配置为session handle。

• 坑少。

2.Memcached的局限性：

• 只支持简单的key/value数据结构，不像Redis可以支持丰富的数据类型。

• 无法进行持久化，数据不能备份，只能用于缓存使用，且重启后数据全部丢失。

• 无法进行数据同步，不能将MC中的数据迁移到其他MC实例中。

• Memcached内存分配采用Slab Allocation机制管理内存，value大小分布差异较大时会造成内存利用率降低，并引发低利用率时依然出现踢出等问题。需要用户注重value设计。 

 

3.Redis的优点：

• 支持多种数据结构，如 string（字符串）、 list(双向链表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基数估算）

• 支持持久化操作，可以进行aof及rdb数据持久化到磁盘，从而进行数据备份或数据恢复等操作，较好的防止数据丢失的手段。

• 支持通过Replication进行数据复制，通过master-slave机制，可以实时进行数据的同步复制，支持多级复制和增量复制，master-slave机制是Redis进行HA的重要手段。

• 单线程请求，所有命令串行执行，并发情况下不需要考虑数据一致性问题。

• 支持pub/sub消息订阅机制，可以用来进行消息订阅与通知。

• 支持简单的事务需求，但业界使用场景很少，并不成熟。

 

4.Redis的局限性：

• Redis只能使用单线程，性能受限于CPU性能，故单实例CPU最高才可能达到5-6wQPS每秒（取决于数据结构，数据大小以及服务器硬件性能，日常环境中QPS高峰大约在1-2w左右）。

• 支持简单的事务需求，但业界使用场景很少，并不成熟，既是优点也是缺点。

• Redis在string类型上会消耗较多内存，可以使用dict（hash表）压缩存储以降低内存耗用。

 

5.Twemproxy分布式方案的优点：

• 简单的分布式解决方案，业务方仅仅使用一个IP/PORT的映射即可（线上使用LVS+VIP+VPORT的方式部署），所有的分片数据存取都通过Twemproxy内部进行。

• Redis和Memcached都可以使用Twemproxy作为自己的分布式解决方案。

• 支持多种hash算法，较少的性能损失。

• 可以通过扩展Twemproxy来解决中间层单点性能低以及HA的问题（线上业务通常使用5-10个Twemproxy，通过LVS进行负载均衡和故障转移）

• Twemproxy内部支持简单的后端存储故障转移方案，比如后端MC实例down，则可以将路由到该MC的请求转移到其他MC实例上去。内部定制版本的Twemproxy，通过与Sentinel集群结合，支持Redis主从方案的故障转移，若Redis master down，则将请求路由到slave上。

• 可以简单方便的进行后端服务的迁移、扩容等操作，不再依赖与DNS或服务配置，所有的配置变更都可以在LVS及Twemproxy上完成，对服务是透明的，业务无需关心，方便运维。

 

6.Twemproxy分布式方案的局限性：

• 使用Redis作为后端存储时，很多原生的Redis命令请求会受到限制，Twemproxy本身并不支持。

• Twemproxy为中间层解决方案，增加一层会导致服务请求延时增加，且Twemproxy作为中间层本身可能成为服务的瓶颈，比如CPU或流量问题，当然可以通过增加Twemproxy实例的方式解决，但响应的增加了服务器的投入成本。

• 服务部署的难度增加，管理成本和复杂度增加，需要有快速简单的自动化服务部署及管理方案，对运维人员的要求增大。

• Twemproxy分布式中间层多节点需要LVS的支持，LVS本身的性能限制可能造成服务瓶颈，之前发生过一次LVS网卡丢包的问题，之后已经进行较大规模的优化和拆分。

 

选型考虑因素：

1. 是否需要多分片进行分布式部署？若是则请使用Twemproxy进行服务部署，使用Redis作为存储时需考虑命令的支持程度，部分Redis的命令在Twemproxy上并不支持；否则请使用单机的Redis或MC作为存储，或则自行在客户端进行分片操作。平台使用Twemproxy+MC部署的时候，会采用自动剔除异常服务实例的方式以保证整体服务的质量，剔除异常服务实例后，部分请求将会出现MISS；使用Twemproxy+Redis部署的时候会通过Redis的Master/Slave机制，在Master异常的是有自动提升Slave，以保证服务的质量。

2. 是否需要复杂的数据结构选择？若是则请使用Redis作为存储，否则Redis及MC都可以考虑。若只有简单的get/set请求，且需要较高的性能需求，可以使用MC代替Redis。

3. 是否需要进行数据持久化存储，数据不允许丢失？若是，则请使用Redis进行数据存储，并在申请服务的时候注明需要作为存储而非缓存，需要开启持久化存储及数据定期备份。

4. 是否需要Master/Slave机制保证服务的HA？若是，则请使用Redis进行数据存储，平台会默认为所有的Redis服务部署Slave从库，以保证Master/Slave机制。

5. 是否是计数服务？若是请使用Redis作为存储，性能保证的同时开启aof保证数据不会丢失。

 

典型使用场景：

Memcached：

• Session存储：全站Session业务，移动WAP Session

• 移动MAPI业务

• 等等

Redis：

• 计数服务

• 队列服务：消息队列

• 专场列表数据（hashset，通过hashset存储某个专场下面的所有商品）

• 集合去重：PMS用来发送短信服务的Redis，使用多个集合去重以防止同一用户收到多条短信，造成骚扰。

• 等等