1、数据平台前端缓存技术方案（M/R）version: v1.0缓存 Memcached（M） M 的概念M 是高性能的分布式内存缓存服务器，协议简单。通过缓存数据库的查询结果，减少数据库访问次数，提高动态 Web 应用的速度和扩展性。M 支持下述语言M 的设计M 的机制守护进程机制：UNIX Daemon；Socket 事件处理机制：非阻塞、Libevent 异步事件处理、Epoll/Kqueue；内存管理机制：Slab 内存分配、LRU 对象清除、Hash 快速检索 Item。内存管理中，Slab 中分成小单位 Chunk，Chunk 中存有实际数据 Item。下述是 M 的 Slab 内存结
2、构图和分配实例图。Slab 内存结构图Slab 内存分配实例图Slab 计算占用内存图Item 数据存储格式图M 的架构设计M 的设计遵从原则是，首次访问从 RDBMS 中取得数据，按一定规则保存到 M 后，第二次访问从 M 中取得数据显示到浏览器页面中。M 架构层次图M 的服务端并没有分布式功能，各个服务器之间没有互相通信以共享信息。M 的分布式完全取决于客户端的实现，如下图所示。M 使用说明图如需要在 M 中保存键名为“tokyo”的数据时，通过客户端应用程序的算法，根据 Key 来决定选择哪个服务器节点进行存储。服务器选定之后，命令其保存键名“tokyo”和键值“data” 。Set 实
3、例图如需要在 M 中获取键名为“tokyo”的数据时。把键名“tokyo”传给客户端函数库，通过和数据保存相同的算法，根据Key 选择服务器节点。只要算法一致，就能选对服务器，发送命令取得键值“data” 。Get 实例图M 的客户端算法余数分散根据服务器台数的余数进行分散，求得 Key 的整数 Hash 值 H，除以服务器的台数 N，由余数指向选中服务器，即 H%N。算法的数据分散性比较优秀，但不足的是当添加/移除服务器时（包括服务器 Down 机事件） ，缓存重组的代价相当大。因为添加/移除服务器后，余数必定发生改变，客户端在获取数据时，就无法通过算法获取和保存时相同的服务器，严重影响了缓
4、存的命中率。大部分负载会在事件发生的同时，增大数据库的压力。一致性哈希一致性哈希算法，Consistent Hashing 是一种分布式算法，常用于负载均衡。M 客户端选择这种算法，解决将 Key-Value 均匀分配到众多 M 服务器上的问题。它可以取代传统的取模操作，解决了上述取模操作无法应对增删 M 服务器所遇到的问题。一致性哈希算法图一致性哈希算法增加节点图普通一致性哈希算法有个潜在的问题是：节点 Hash 后会不均匀地分布在环上，这样大量的 Key 在寻找节点时，会存在命中各个节点的概率差别较大，无法实现有效的负载均衡。如有三个节点Node1,Node2,Node3，分布在环上时三个
5、节点挨的很近，落在环上的key 寻找节点时，大量 key 顺时针总是分配给 Node2，而其它两个节点被找到的概率都会很小。这种问题的解决方案有: 改善 Hash 算法，均匀分配各节点到环上；使用虚拟节点的思想，为每个物理服务器节点在圆上分配 100200 个点。这样就能抑制分布不均匀，最大限度地减小服务器增减时的缓存重新分布。用户数据映射在虚拟节点上，就表示用户数据真正存储位置是在该虚拟节点对应的实际物理服务器上。M 的 Java 客户端实现（集群）Google 的 Memcached 实现官方推荐的 Java 客户端之一 Whalin 开源实现基础上做再次封装的产物。增加实现了缓存服务接口
6、化，使用配置文件代替代码初始化客户端，集群的实现，LocalCache 客户端本地缓存的使用。旧SocketIO 代码里面有太多的 Synchronized（同步） ，多多少少会影响性能，改造 SocketIO 部分，优化 Synchronized，添置了读入缓存页。接口类图集群、客户端的初始化通过配置文件生成，配置内容如下：集群中多节点软负载均衡，当前采用简单的 Hash 算法加取余来分发数据，数据在多节点上进行异步冗余存储，防止数据丢失，数据在分发到某一失败节点时可以转向到其他可用节点，节点恢复可用后数据 Lazy 复制，例如，当 A,B 两台机器作为集群的时候，如果A 出现了问题，系统会
7、去 B 获取数据，当 A 正常以后，如果应用在A 中没有拿到数据可以去 B 获取数据，并且复制到 A 上。Spring+XMemcached 实现M 的 Java 客户端中，XMemcached 支持所有的文本协议和二进制协议。支持动态添加和删除 M 节点。支持客户端统计。支持节点的权重设置,支持 nio 的连接池，网路实现层是长连接形式，无需重复创建多个 Client 对象，在高负载环境下提高吞吐量。利用 Spring 框架可以直接配置客户端集群，按照规定算法（Ketama 等） ，自动 Build 出客户端对象，具体如下图。集群服务配置图客户端对象配置图缓存 Redis（R）R 的简介re
8、dis 是一个 key-value 存储系统。和 Memcached 类似，它支持存储的 value 类型相对更多，包括 string(字符串) 、list(链表)、set(集合) 和 zset(有序集合) 。这些数据类型都支持push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis 支持各种不同方式的排序。与 memcached 一样，为了保证效率，数据都是缓存在内存中。区别的是 redis 会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了 master-slave(主从) 同步。R 的 m
9、aster-slave(主从) 架构图 2.1master-slave 模式当设置好 slave 服务器后，slave 会建立和 master 的连接，然后发送 sync 命令。无论是第一次同步建立的连接还是连接断开后的重新连接，master 都会启动一个后台进程，将数据库快照保存到文件中，同时 master 主进程会开始收集新的写命令并缓存起来。后台进程完成写文件后，master 就发送文件给 slave，slave将文件保存到磁盘上，然后加载到内存恢复数据库快照到 slave 上。接着 master 就会把缓存的命令转发给 slave。而且后续 master收到的写命令都会通过开始建立的连
10、接发送给 slave。从 master到 slave 的同步数据的命令和从 client 发送的命令使用相同的协议格式。当 master 和 slave 的连接断开时 slave 可以自动重新建立连接。如果 master 同时收到多个 slave 发来的同步连接命令，只会使用启动一个进程来写数据库镜像，然后发送给所有 slave。流程如下图所示：图 2.3 redis 主从数据复制流程Redis 复制机制的缺陷从上面的流程可以看出，Slave 从库在连接 Master 主库时，Master 会进行内存快照，然后把整个快照文件发给 Slave，也就是没有象 MySQL 那样有复制位置的概念，即无
11、增量复制，这会给整个集群搭建带来非常多的问题。比如一台线上正在运行的 Master 主库配置了一台从库进行简单读写分离，这时 Slave 由于网络或者其它原因与 Master 断开了连接，那么当 Slave 进行重新连接时，需要重新获取整个 Master的内存快照，Slave 所有数据跟着全部清除，然后重新建立整个内存表，一方面 Slave 恢复的时间会非常慢，另一方面也会给主库带来压力。所以基于上述原因，如果你的 Redis 集群需要主从复制，那么最好事先配置好所有的从库，避免中途再去增加从库。redis 的 master/slave 模式下，master 提供数据读写服务，而 slave
12、只提供读服务。客服端通过 Consistent Hashing 算法选择要访问的 slave 缓存服务节点，运行图如下图所示：图 2.2 redis 运行图R 的特性 可以将缓存数据持久化到磁盘 不支持集群，但支持主从模式 value 支持数据类型： string（字符串） 、list （列表） 、sets（集合）或者是 ordered sets（被排序的集合）和hash(哈希)。 基于客服端来实现分布式(通过 Consistent Hashing 算法选择服务器节点，算法详情请参考 1.4 节) 事务支持(MULTI,EXEC 及 DISCARD 三个命令让 Redis 的使用者可以将 Re
13、dis 命令打包进行原子性的操作 ) 支持 Publish/subscribe(使用该功能可以很容易实现一个实时消息平台)R 的 Java 客户端实现redis 主页上列出的 java 客户端有 Jedis 、JRedis 和 JDBC-Redis 三种，面分别介绍三种客户端的优缺点。支持 redis 版本 性能 维护 推荐Jedis 2.0.0 release fast actively developed 推荐JRedis 1.2.n release 2.0.0 尚未 release 版本fastJDBC-Redis not good详情请参考：http:/redis.io/clients
14、(1)、jedis 实现jedis 是 Redis 官方首选的 Java 客户端开发包，推荐使用jedis，所有对 redis 操作类的结构非常明确，都通过 jedis 获取其他的类，且 jedis 支持和 spring 集成。以下是 jedis+spring 集成步骤：首先，在项目中引入 jeids 的 jar 包：其次，在 spring 配置文件中添加配置：其次，在 spring 配置文件中添加配置：最后，应用程序调用：redis.clientsjedis2.0.0ShardedJedisjedis= shardedJedisPool.getResource();jedis.get(key
15、); /从 redis 服务器获取值jedis.set(key, value); /将值保存到 redis 服务器(2)、 jredis 实现实现比较复杂，且版本比较旧，不支持 redis 的很多新特性。(3)、 jdbc-redis 实现jdbc-redis 是用于 redis 这个 NoSQL 数据库的 jdbc 驱动，也就是说你可以使用你所熟悉的 jdbc 的方法来访问 Redis 数据。但是 jdbc-redis 性能较差，不推荐使用。R 的最新版本 2.4 改进 对小数据量的 sorted sets 结构的内存使用做很大的优化 RDB 文件的持久化速度也将会大大提高 对目前的一些写操
16、作命令进行了改进，支持批量写入功能 启用新的内存分配模式 jemalloc 通过对 copy on write 机制使用的优化，数据持久化保存的子进程的内存占用将大大减少 INFO 内容更加丰富 新的 OBJECT 命令，提供对 Redis 存储 value 结构描述 新的 CLIENT 命令，提供对 Redis 客户端连接的信息描述 彻底将 Slave 对 Master 的连接改成非阻塞，之前connect(2)系统调用是会阻塞的 Redis-benchmark、Redis-cli 都进行了几个方面的改进 Make 改为彩色输出，更易读 2.0 版本中提供的 VM 机制被废弃 总的来说 2.
17、4 版本会在各方面有性能上的提升 Redis 测试框架也有非常大的提升详情请参考：http:/ 的性能：根据 Redis 官方的测试结果：在 50 个并发的情况下请求 10w次，写的速度是 110000 次/s，读的速度是 81000 次/s测试环境：1. 50 个并发，请求 100000 次2.读和写大小为 256bytes 的字符串3.Linux2.6 Xeon X3320 2.5GHz 的服务器上4.通过本机的 loopback interface 接口上执行详情请参考：http:/ 的短期发展规划Lua 脚本支持Redis 集群功能Replication 功能的改进持久化方案的改进提供
18、更精确的过期时间长数据的读写操作性能改进进行一些内部改造其它小功能详情请参考：http:/ 和 R 的比较网络 IO 模型 M 是多线程，非阻塞 IO 复用的网络模型，分为监听主线程和worker 子线程，监听线程监听网络连接，接受请求后，将连接描述字 pipe 传递给 worker 线程，进行读写 IO, 网络层使用 libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了 cache coherency 和锁的问题，比如，M 最常用的 stats 命令，实际 M 所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。网络 IO 模型图 R 使用单线程的 IO 复用模型
19、，主要实现了 Epoll、Kqueue，对于单纯只有 IO 操作来说，单线程可以将速度优势发挥到最大，但是R 也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际上会严重影响整体的吞吐量，并且在 CPU 计算过程中，整个 IO 调度都是被阻塞住的。内存管理方面M 使用预分配的内存池的方式，使用 Slab 和大小不同的 Chunk来管理内存，Item 根据大小选择合适的 Chunk 存储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数据也可能会被剔除。Redis 使用现场申请内存的
20、方式来存储数据，并且很少采取方式优化内存分配，会在一定程度上存在内存碎片，R 会根据存储命令的参数，把过期的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，进行 Swap，也不会剔除任何非临时数据，这点上 R 更适合作为存储而不是Cache。数据一致性M 提供了 CAS 命令，可以保证多个并发访问操作同一份数据的一致性问题。R 没有提供 CAS 命令，但是提供了事务功能，可以保证一串命令的原子性，中间不会被任何操作打断。存储方式及其它方面M 基本只支持简单的 Key-Value 存储，不支持枚举，不支持持久化和复制等功能。R 除 Key-Value 之外，还支持 list，set，sorted set，hash等众多数据结构。R 还同时提供了持久化和复制等功能。主从模式（Master-Slave）实现了多台缓存服务器具有相同数据副本，某缓存服务器节点 Down 机后，不影响应用服务正常访问。关于不同语言的客户端支持M 发展的时间更久一些，M 有丰富的客户端支持，并且成熟稳定。R 由于其协议本身就比 M 复杂，并且版本在不断更新，客户端的需要时刻跟进。1 M+R 和 M-R
