Cache为缓解DB装有重要数据，下面经常使用memcached和redis要总结，促进技术的选择。
1 memcached
（1） 有限支持的操作，持经常使用的set。get。delete和过期删除等。
（2） 本身不支持分布式特性。分布式特性是通过client来提供，client须要维护多个server的信息，添加或者删除一个server节点，须要更新全部的client维护的信息。
（3） client支持一致性hash算法，不提供持久化，不提供Replaction机制。
（4） 性能高。操作简单，存储复杂的数据结构，须要自己提供序列化机制。
（5） 近期版本号不怎么更新，作为内存池的一种扩展。功能已经非常完备了。
2 redis
（1） 提供丰富的操作，支持丰富的数据结构。
（2） 本身不提供分布式特性。分布式特性可通过Redis cluster或者Twemproxy支持分布式操作。
（3）
提供持久化，提供主从同步机制。提供的机制都不是严格一致性的，会造成数据短暂的不一致性。
（4）
官方支持特别好，一直在提供和完好一些新特性。这个非常重要！ ！
这里简介下Twemproxy
1 这个是Twitter开源的Memcached和Redis的代理层，使用Twemproxy的集群方案例如以下：
2
Twemproxy的功能介绍
（1）前端使用 Twemproxy 做代理，后端的 Redis 数据能基本上依据 key 来进行比較均衡的分布。
（2）后端一台 Redis 挂掉后。Twemproxy 可以自己主动摘除。
恢复后，Twemproxy 可以自己主动识别、恢复并又一次增加到 Redis 组中又一次使用。
（3）Redis 挂掉后。后端数据是否丢失根据 Redis 本身的策略配置，与 Twemproxy 基本无关。
（4）假设要新添加一台 Redis。Twemproxy 须要重新启动才干生效；而且数据不会自己主动又一次 Reblance，须要人工单独写脚本来实现。
（5）如同一时候部署多个 Twemproxy，配置文件一致（測试配置为distribution：ketama,modula），则能够从随意一个读取。都能够正确读取 key相应的值。
（6）多台 Twemproxy 配置一样。client分别连接多台 Twemproxy能够在一定条件下提高性能。依据 Server 数量，提高比例在 110-150%之间。
（7）如原来已经有 2 个节点 Redis，兴许有添加 2 个 Redis，则数据分布计算与原来的 Redis 分布无关，现有数据假设须要分布均匀的话，须要人工单独处理。
（8）假设 Twemproxy 的后端节点数量发生变化，Twemproxy 同样算法的前提下，原来的数据必须又一次处理分布。否则会存在找不到key值的情况。
结合这边的业务特点，我认为能够使用Redis来提供Cache服务。
1 提供多个（大于1）Redis实例，且在不同机器上面，同一时候在多个机器上面都部署
Twemproxy代理，规避Cache的单点故障。
2 开启Redis的Replaction机制，通过区分不同业务。来区分使用主Cache和从Cache。分担请求压力。
3 经确认，Redis也存在delete删除失败的情形，这个须要配合Cache过期时间，异步删除来完好。
4 使用Cache的同一时候，须要区分业务。敏感业务不做Cache。保证数据的严格一致性。
5 Redis的持久化作用不大，能够考虑关闭。
版权声明：本文博客原创文章，博客，未经同意，不得转载。
本文转自mfrbuaa博客园博客，原文链接：http://www.cnblogs.com/mfrbuaa/p/4673612.html，如需转载请自行联系原作者
