首页 > 代码库 > Cache选型的一些思考
Cache选型的一些思考
Cache对于减轻DB负载有很重要的作用，下面对常用的memcached和redis做个总结，便于技术选型。
1 memcached
（1） 支持的操作有限，支持常用的set，get，delete和过期删除等。
（2） 本身不支持分布式特性，分布式特性是通过客户端来提供，客户端需要维护多个服务器的信息，增加或者删除一个服务器节点，需要更新所有的客户端维护的信息。
（3） 客户端支持一致性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 配置一样，客户端分别连接多台 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的持久化作用不大，可以考虑关闭。
参考文献：http://blog.jpush.cn/redis-twemproxy-benchmark/
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。