共计 5519 个字符，预计需要花费 14 分钟才能阅读完成。
行业资讯
服务器
云计算
Memcache 及 Redis 分布式缓存集群方案特性使用场景优缺点对比及选型是怎么样的
Memcache 及 Redis 分布式缓存集群方案特性使用场景优缺点对比及选型是怎么样的，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
分布式缓存集群方案特性使用场景优缺点对比及选型
分布式缓存特性：
1) 高性能: 当传统数据库面临大规模数据访问时, 磁盘 I /O 往往成为性能瓶颈, 从而导致过高的响应延迟. 分布式缓存将高速内存作为数据对象的存储介质, 数据以 key/value 形式存储, 理想情况下可以获得 DRAM 级的读写性能;
2) 动态扩展性: 支持弹性扩展, 通过动态增加或减少节点应对变化的数据访问负载, 提供可预测的性能与扩展性; 同时, 最大限度地提高资源利用率;
3) 高可用性: 可用性包含数据可用性与服务可用性两方面. 基于冗余机制实现高可用性, 无单点失效(single point of failure), 支持故障的自动发现, 透明地实施故障切换, 不会因服务器故障而导致缓存服务中断或数据丢失. 动态扩展时自动均衡数据分区, 同时保障缓存服务持续可用;
4) 易用性: 提供单一的数据与管理视图;API 接口简单, 且与拓扑结构无关; 动态扩展或失效恢复时无需人工配置; 自动选取备份节点; 多数缓存系统提供了图形化的管理控制台, 便于统一维护;
5) 分布式代码执行(distributed code execution): 将任务代码转移到各数据节点并行执行, 客户端聚合返回结果, 从而有效避免了缓存数据的移动与传输. 最新的 Java 数据网格规范 JSR-347 中加入了分布式代码执行与 Map/reduce 的 API 支持, 各主流分布式缓存产品, 如 IBM WebSphere eXtreme Scale,VMware GemFire,GigaSpaces XAP 和 Red Hat Infinispan 等也都支持这一新的编程模型.
分布式缓存应用场景：
1) 页面缓存. 用来缓存 Web 页面的内容片段, 包括 HTML、CSS 和图片等, 多应用于社交网站等;
2) 应用对象缓存. 缓存系统作为 ORM 框架的二级缓存对外提供服务, 目的是减轻数据库的负载压力, 加速应用访问;
3) 状态缓存. 缓存包括 Session 会话状态及应用横向扩展时的状态数据等, 这类数据一般是难以恢复的, 对可用性要求较高, 多应用于高可用集群;（解决分布式 Web 部署的 session 同步问题）
4) 并行处理. 通常涉及大量中间计算结果需要共享;
5) 事件处理. 分布式缓存提供了针对事件流的连续查询 (continuous query) 处理技术, 满足实时性需求;
6) 极限事务处理. 分布式缓存为事务型应用提供高吞吐率、低延时的解决方案, 支持高并发事务请求处理, 多应用于铁路、金融服务和电信等领域.
7）云计算领域提供分布式缓存服务（例如：青云、
UnitedStack 等）6）
任何需要用到缓存的地方，解决本地缓存数据量太小问题。分布式缓存能有效防止本地缓存失效数据库雪崩现象。
两大开源缓存系统对比，
Memcache VS Redis：
1、Redis 不仅仅支持简单的 k / v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。而
memcache 只支持简单数据类型，需要客户端自己处理复杂对象
2、Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用（PS：持久化在 rdb、aof）。Redis 借助了 fork 命令的 copy on write 机制。在生成快照时，将当前进程 fork 出一个子进程，然后在子进程中循环所有的数据，将数据写成为 RDB 文件。 AOF 日志的全称是 append only file，从名字上我们就能看出来，它是一个追加写入的日志文件。与一般数据库的 binlog 不同的是，AOF 文件是可识别的纯文本，它的内容就是一个个 的 Redis 标准命令。当然，并不是发送发 Redis 的所有命令都要记录到 AOF 日志里面，只有那些会导致数据发生修改的命令才会追加到 AOF 文件。那么每一条修改数据的命令都生成一条日志。（PS：memcache 不支持数据持久存储）
3、由于 Memcache 没有持久化机制，因此宕机所有缓存数据失效。Redis 配置为持久化，宕机重启后，将自动加载宕机时刻的数据到缓存系统中。具有更好的灾备机制。
4、Memcache 可以使用 Magent 在客户端进行一致性 hash 做分布式。Redis 支持在服务器端做分布式（PS:Twemproxy/Codis/Redis-cluster 多种分布式实现方式）
5、Memcached 的简单限制就是键（key）和 Value 的限制。最大键长为 250 个字符。可以接受的储存数据不能超过 1MB（可修改配置文件变大），因为这是典型 slab 的最大值，不适合虚拟机使用。而 Redis 的 Key 长度支持到 512k。
6、Redis 使用的是单线程模型，保证了数据按顺序提交。Memcache 需要使用 cas 保证数据一致性。CAS（Check and Set）是一个确保并发一致性的机制，属于“乐观锁”范畴；原理很简单：拿版本号，操作，对比版本号，如果一致就操作，不一致就放弃任何操作
cpu 利用。由于 Redis 只使用单核，而 Memcached 可以使用多核，所以平均每一个核上 Redis 在存储小数据时比 Memcached 性能更 高。而在 100k 以上的数据中，Memcached 性能要高于 Redis 。（PS：Redis 可以通过开启多个实例来提高 CPU 利用率，Memcache 默认是单线程，需要编译指定参数才能支持多线程。由于分布式缓存是 IO 密集型系统，所以性能很多程度受限于网络通信，memcache 使用了 libevent 网络库，redis 自己实现了一套自己通信的库。线程也不是影响吞吐量的重要因素。如第一点来说，一般情况下，程序处理内存数据的速度远高于网卡接收的速度。使用线程好处是可以同时处理多条连接，在极端情况下，可能会提高响应速度。但是单线程有时候比多线程 或多进程更快，比需要考虑并发、锁，也不会增加上下文切换等开销，也即代码更加简洁，执行效率更高。）
7、memcache 内存管理：使用 Slab Allocation。原理相当简单，预先分配一系列大小固定的组，然后根据数据大小选择最合适的块存储。避免了内存碎片。（缺点：不能变长，浪费了一定空间）memcached 默认情况下下一个 slab 的最大值为前一个的 1.25 倍。8、redis 内存管理：Redis 通过定义一个数组来记录所有的内存分配情况，Redis 采用的是包装的 malloc/free，相较于 Memcached 的内存 管理方法来说，要简单很多。由于 malloc 首先以链表的方式搜索已管理的内存中可用的空间分配，导致内存碎片比较多。
总结：
其实对于企业选型 Memcache、Redis 而言，更多还是应该看业务使用场景（因为 Memcache、Redis 两者都具有足够高的性能和稳定性）。假若业务场景需要用到持久化缓存功能、或者支持多种数据结构的缓存功能，那么 Redis 则是最佳选择。
（PS：Redis 集群解决方式也优于 Memcache，Memcache 在客户端一致性 hash 的集群解决方案，Redis 采用无中心的服务器端集群解决方案）
综上所述：为了让缓存系统能够支持更多的业务场景，选择 Redis 会更优。（目前也越来越多的厂商选择 Redis）。
接下来重点对比 Redis 三大集群解决方案对比，
Twemproxy VS Codis VS Redis-cluster
Redis 集群三种常见的解决方案：
1、客户端分片：这种方案将分片工作放在业务程序端，程序代码根据预先设置的路由规则，直接对多个 Redis 实例进行分布式访问。这样的好处是，不依赖于第三方分布式中间件，实现方法和代码都自己掌控，可随时调整，不用担心踩到坑。这实际上是一种静态分片技术。Redis 实例的增减，都得手工调整分片程序。基于此分片机制的开源产品，现在仍不多见。这种分片机制的性能比代理式更好（少了一个中间分发环节）。但缺点是升级麻烦，对研发人员的个人依赖性强——需要有较强的程序开发能力做后盾。如果主力程序员离职，可能新的负责人，会选择重写一遍。所以，这种方式下，可运维性较差。出现故障，定位和解决都得研发和运维配合着解决，故障时间变长。因此 这种方案，难以进行标准化运维，不太适合中小公司（除非有足够的 DevOPS）。
2、代理 分片：这种方案，将分片工作交给专门的代理程序来做。代理程序接收到来自业务程序的数据请求，根据路由规则，将这些请求分发给正确的 Redis 实例并返回给业务程序。
这种机制下，一般会选用第三方代理程序（而不是自己研发），因为后端有多个 Redis 实例，所以这类程序又称为分布式中间件。
这样的好处是，业务程序不用关心后端 Redis 实例，运维起来也方便。虽然会因此带来些性能损耗，但对于 Redis 这种内存读写型应用，相对而言是能容忍的。
这是我们推荐的集群实现方案。像基于该机制的开源产品 Twemproxy，Codis 便是其中代表，应用非常广泛。
3、服务器端分片：建立在基于无中心分布式架构之上（没有代理节点性能瓶颈问题）。Redis-Cluster 即为官方基于该架构的解决方案。
Redis Cluster 将所有 Key 映射到 16384 个 Slot 中，集群中每个 Redis 实例负责一部分，业务程序通过集成的 Redis Cluster 客户端进行操作。客户端可以向任一实例发出请求，如果所需数据不在该实例中，则该实例引导客户端自动去对应实例读写数据。
Redis Cluster 的成员管理（节点名称、IP、端口、状态、角色）等，都通过节点之间两两通讯，定期交换并更新。
接下来分别讲解各解决方案代表产品实现方式优缺点：
Twemproxy：
Twemproxy 是一种代理分片机制，由 Twitter 开源。Twemproxy 作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个 Redis 服务器，再原路返回。这个方案顺理成章地解决了单个 Redis 实例承载能力的问题。当然，Twemproxy 本身也是单点，需要用 Keepalived 做高可用方案。这么些年来，Twemproxy 是应用范围最广、稳定性最高、最久经考验的分布式中间件。只是，他还有诸多不方便之处。Twemproxy 最大的痛点在于，无法平滑地扩容 / 缩容。这样增加了运维难度：业务量突增，需增加 Redis 服务器；业务量萎缩，需要减少 Redis 服务器。但对 Twemproxy 而言，基本上都很难操作。或者说，Twemproxy 更加像服务器端静态 sharding。有时为了规避业务量突增导致的扩容需求，甚至被迫新开一个基于 Twemproxy 的 Redis 集群。Twemproxy 另一个痛点是，运维不友好，甚至没有控制面板。
Codis：
Codis 由豌豆荚于 2014 年 11 月开源，基于 Go 和 C 开发，是近期涌现的、国人开发的优秀开源软件之一。现已广泛用于豌豆荚的各种 Redis 业务场景，从各种压力测试来看，稳定性符合高效运维的要求。性能更是改善很多，最初比 Twemproxy 慢 20%；现在比 Twemproxy 快近 100%（条件：多实例，一般 Value 长度）。Codis 具有可视化运维管理界面。Codis 无疑是为解决 Twemproxy 缺点而出的新解决方案。因此综合方面会由于 Twemproxy 很多。目前也越来越多公司选择 Codis。Codis 引入了 Group 的概念，每个 Group 包括 1 个 Redis Master 及至少 1 个 Redis Slave，这是和 Twemproxy 的区别之一。这样做的好处是，如果当前 Master 有问题，则运维人员可通过 Dashboard“自助式”切换到 Slave，而不需要小心翼翼地修改程序配置文件。为支持数据热迁移（Auto Rebalance），出品方修改了 Redis Server 源码，并称之为 Codis Server。Codis 采用预先分片（Pre-Sharding）机制，事先规定好了，分成 1024 个 slots（也就是说，最多能支持后端 1024 个 Codis Server），这些路由信息保存在 ZooKeeper 中。
Redis-cluster：
reids-cluster 在 redis3.0 中推出，支持 Redis 分布式集群部署模式。采用无中心分布式架构。所有的 redis 节点彼此互联(PING-PONG 机制), 内部使用二进制协议优化传输速度和带宽. 节点的 fail 是通过集群中超过半数的节点检测失效时才生效. 客户端与 redis 节点直连, 不需要中间 proxy 层. 客户端不需要连接集群所有节点, 连接集群中任何一个可用节点即可，减少了代理层，大大提高了性能。redis-cluster 把所有的物理节点映射到[0-16383]slot 上,cluster 负责维护 node – slot – key 之间的关系。目前 Jedis 已经支持 Redis-cluster。从计算架构或者性能方面无疑 Redis-cluster 是最佳的选择方案。（PS：虽然 Redis-cluster 从方案选型上面比较占据优势，但是由于 Redis-cluster 刚推出不久，虽然官方宣传已经发布的是文档版本，但稳定性方面还有待验证）
看完上述内容，你们掌握 Memcache 及 Redis 分布式缓存集群方案特性使用场景优缺点对比及选型是怎么样的的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
