面试题：“选redis仍是memcache”

有时，面试官并无对本身的提问，预设任何答案，只要候选人的思路是清晰的，逻辑是自洽的，即便给出的未必是最优的方案，也是能让人眼前一亮。作技术方案，技术选型的时候，必定是针对业务需求来折衷的。

选型考虑因素：

• 是否须要复杂的数据结构选择？如果则请使用Redis做为存储，不然Redis及MC均可以考虑。若只有简单的get/set请求，且须要较高的性能需求，可使用MC代替Redis。
• 是否须要进行数据持久化存储，数据不容许丢失？如果，则请使用Redis进行数据存储，并在申请服务的时候注明须要做为存储而非缓存，须要开启持久化存储及数据按期备份。
• 是否须要Master/Slave机制保证服务的HA？如果，则请使用Redis进行数据存储，平台会默认为全部的Redis服务部署Slave从库，以保证Master/Slave机制。
• 是不是计数服务？如果请使用Redis做为存储，性能保证的同时开启aof保证数据不会丢失。
• 是否须要多分片进行分布式部署？如果则请使用Twemproxy进行服务部署，使用Redis做为存储时需考虑命令的支持程度，部分Redis的命令在Twemproxy上并不支持；不然请使用单机的Redis或MC做为存储，或则自行在客户端进行分片操做。平台使用Twemproxy+MC部署的时候，会采用自动剔除异常服务实例的方式以保证总体服务的质量，剔除异常服务实例后，部分请求将会出现MISS；使用Twemproxy+Redis部署的时候会经过Redis的Master/Slave机制，在Master异常的是有自动提高Slave，以保证服务的质量。

典型使用场景：

Memcached：

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

Redis：

• 计数服务
• 队列服务：消息队列
• 专场列表数据（hashset，经过hashset存储某个专场下面的全部商品）
• 集合去重：PMS用来发送短信服务的Redis，使用多个集合去重以防止同一用户收到多条短信，形成骚扰。

Memcached

Memcached的优势

• Memcached能够利用多核优点，单实例吞吐量极高，能够达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，平常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。
• 支持直接配置为session handle。
• 坑少。

Memcached的局限性：

• 只支持简单的key/value数据结构，不像Redis能够支持丰富的数据类型。
• 没法进行持久化，数据不能备份，只能用于缓存使用，且重启后数据所有丢失。
• 没法进行数据同步，不能将MC中的数据迁移到其余MC实例中。
• Memcached内存分配采用Slab Allocation机制管理内存，value大小分布差别较大时会形成内存利用率下降，并引起低利用率时依然出现踢出等问题。须要用户注重value设计。

Redis

Redis的优势：

• 支持多种数据结构，如 string（字符串）、 list(双向链表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基数估算）
• 支持持久化操做，能够进行aof及rdb数据持久化到磁盘，从而进行数据备份或数据恢复等操做，较好的防止数据丢失的手段。
• 支持经过Replication进行数据复制，经过master-slave机制，能够实时进行数据的同步复制，支持多级复制和增量复制，master-slave机制是Redis进行HA的重要手段。
• 单线程请求，全部命令串行执行，并发状况下不须要考虑数据一致性问题。
• 支持pub/sub消息订阅机制，能够用来进行消息订阅与通知。
• 支持简单的事务需求，但业界使用场景不多，并不成熟。

Redis的局限性：

• Redis只能使用单线程，性能受限于CPU性能，故单实例CPU最高才可能达到5-6wQPS每秒（取决于数据结构，数据大小以及服务器硬件性能，平常环境中QPS高峰大约在1-2w左右）。
• 支持简单的事务需求，但业界使用场景不多，并不成熟，既是优势也是缺点。
• Redis在string类型上会消耗较多内存，可使用dict（hash表）压缩存储以下降内存耗用。

Twemproxy

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上完成，对服务是透明的，业务无需关心，方便运维。

Twemproxy分布式方案的局限性：

• 使用Redis做为后端存储时，不少原生的Redis命令请求会受到限制，Twemproxy自己并不支持。
• Twemproxy为中间层解决方案，增长一层会致使服务请求延时增长，且Twemproxy做为中间层自己可能成为服务的瓶颈，好比CPU或流量问题，固然能够经过增长Twemproxy实例的方式解决，但响应的增长了服务器的投入成本。
• 服务部署的难度增长，管理成本和复杂度增长，须要有快速简单的自动化服务部署及管理方案，对运维人员的要求增大。
• Twemproxy分布式中间层多节点须要LVS的支持，LVS自己的性能限制可能形成服务瓶颈，以前发生过一次LVS网卡丢包的问题，以后已经进行较大规模的优化和拆分。