memcached/redis比较 缓存代理比较(Twemproxy/Codis/Redis-cluster)

前言

在缓存代理中，基本都采用了paxos算法，进行分布式一致性管控。因此，读者有必要去了解一下paxos算法是干嘛的，以及它大致的流程。

memcached/redis比较

策略	Memcache	Redis
作用	缓存服务	缓存服务
数据结构	map	map,list，set，zset，hash
是否能持久化	无	支持(Snapshot,AOF)
key,value的大小	1MB(可修改配置文件变大)	512K(可修改配置文件变大)
并发	多线程(使用cas保证数据一致性)	单线程模型
内存管理	Slab Allocation(分配一系列块，根据大小进行存储)	malloc/free(链表方式，容易出现碎片)
缓存更新策略	LFU：最少使用,借助计数器实现	LRU：最久未被使用,借助计数器和队列实现

缓存代理比较(Twemproxy/Codis/Redis-cluster)比较

策略	Twemproxy	Codis	Redis-cluster
作用	缓存服务代理	缓存服务代理	分布式缓存
数据结构	依赖后端缓存服务	依赖后端缓存服务	map,list，set，zset，hash
可集成对象	memcached，redis	redis	redis
缺点	1.不支持针对多个值的操作，比如取sets的子交并补等。 2.不支持Redis的事务操作。 3.错误消息、日志信息匮乏，排查问题困难	1.采用自有的redis分支，不能与原版的redis保持同步 2.如果codis的proxy只有一个的情况下，redis的性能会下降20%左右 3.某些命令不支持，比如事务命令muti国内开源产品，活跃度相对弱一些	1.架构比较新，最佳实践较少 2.多键操作支持有限（驱动可以曲线救国） 3.为了性能提升，客户端需要缓存路由表信息 4.节点发现、reshard操作不够自动化 5.无中心的设计，难把程序写对 6.代码优点吓人，clusterProcessPacket函数有426行，大脑难处理到所有状态切换 7.没有正式版本，等了4年之久 8.目前还缺乏best practice，还没有人写一个redis cluster若干条注意事项 9.整个系统高度耦合，升级比较困难
优点	1.通过代理的方式减少缓存服务器的连接数。 2.自动在多台缓存服务器间共享数据。 3.通过不同的策略与散列函数支持一致性散列。4.通过配置的方式禁用失败的结点。 5.运行在多个实例上，客户端可以连接到首个可用的代理服务器。 6.支持请求的流式与批处理，因而能够降低来回的消耗。	1.Codis是一整套缓存解决方案，包含高可用、数据分片、监控、动态扩态 etc.。走的是 Apps->代理->redis cluster，一定规模后基本都采用这种方式。 2.Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改程序配置文件。 3.为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。 4.Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。 5.Codis仅负责维护当前Redis Server列表，由运维人员自己去保证主从数据的一致性。	1.无中心架构。 2.数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布。 3.可扩展性，可线性扩展到1000个节点，节点可动态添加或删除。 4.高可用性，部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升。 5.降低运维成本，提高系统的扩展性和可用性。”
厂商	Twtter	豌豆荚	redis官方

这篇内容，主要内容来自网络，是集合了多人的文章之后形成的，这里先说明一下。