数据平台缓存技术方案Memcached-Redis.docxVIP

数据平台前端缓存技术方案（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内存结构图和分配实例图。Slab内存结构图Slab内存分配实例图Slab计算占用内存图Item数据存储格式图M的架构设计M的设计遵从原则是，首次访问从RDBMS中取得数据，按一定规则保存到M后，第二次访问从M中取得数据显示到浏览器页面中。M架构层次图M的服务端并没有分布式功能，各个服务器之间没有互相通信以共享信息。M的分布式完全取决于客户端的实现，如下图所示。M使用说明图如需要在M中保存键名为“tokyo”的数据时，通过客户端应用程序的算法，根据Key来决定选择哪个服务器节点进行存储。服务器选定之后，命令其保存键名“tokyo”和键值“data”。Set实例图如需要在M中获取键名为“tokyo”的数据时。把键名“tokyo”传给客户端函数库，通过和数据保存相同的算法，根据Key选择服务器节点。只要算法一致，就能选对服务器，发送命令取得键值“data”。Get实例图M的客户端算法余数分散根据服务器台数的余数进行分散，求得Key的整数Hash值H，除以服务器的台数N，由余数指向选中服务器，即H%N。算法的数据分散性比较优秀，但不足的是当添加/移除服务器时（包括服务器Down机事件），缓存重组的代价相当大。因为添加/移除服务器后，余数必定发生改变，客户端在获取数据时，就无法通过算法获取和保存时相同的服务器，严重影响了缓存的命中率。大部分负载会在事件发生的同时，增大数据库的压力。一致性哈希一致性哈希算法，Consistent Hashing是一种分布式算法，常用于负载均衡。M 客户端选择这种算法，解决将Key-Value均匀分配到众多M 服务器上的问题。它可以取代传统的取模操作，解决了上述取模操作无法应对增删M 服务器所遇到的问题。一致性哈希算法图一致性哈希算法增加节点图普通一致性哈希算法有个潜在的问题是：节点Hash后会不均匀地分布在环上，这样大量的Key在寻找节点时，会存在命中各个节点的概率差别较大，无法实现有效的负载均衡。如有三个节点Node1,Node2,Node3，分布在环上时三个节点挨的很近，落在环上的key寻找节点时，大量key顺时针总是分配给Node2，而其它两个节点被找到的概率都会很小。这种问题的解决方案有: 改善Hash算法，均匀分配各节点到环上；使用虚拟节点的思想，为每个物理服务器节点在圆上分配100～200个点。这样就能抑制分布不均匀，最大限度地减小服务器增减时的缓存重新分布。用户数据映射在虚拟节点上，就表示用户数据真正存储位置是在该虚拟节点对应的实际物理服务器上。M的Java客户端实现（集群）Google的Memcached实现官方推荐的Java客户端之一Whalin开源实现基础上做再次封装的产物。增加实现了缓存服务接口化，使用配置文件代替代码初始化客户端，集群的实现，LocalCache客户端本地缓存的使用。旧SocketIO代码里面有太多的Synchronized（同步），多多少少会影响性能，改造SocketIO部分，优化Synchronized，添置了读入缓存页。接口类图集群、客户端的初始化通过配置文件生成，配置内容如下：集群中多节点软负载均衡，当前采用简单的Hash算法加取余来分发数据，数据在多节点上进行异步冗余存储，防止数据丢失，数据在分发到某一失败节点时可以转向到其他可用节点，节点恢复可用后数据Lazy复制，例如，当A,B两台机器作为集群的时候，如果A出现了问题，系统会去B获取数据，当A正常以后，如果应用在A中没有拿到数据可以去B获取数据，并且复制到A上。Spring+XMemcached实现M的Java客户端中，XMemcached支持所有的文本协议和二进制协议。支持动态添加和删除M节点。支持客户端统计。支持节点的权重设置,支持nio的连接池，网路实现层是长连接形式，无需重复创建多个Client对象，在高负载环境下提高吞吐量。利用Spring框架可以直接配置客户端集群，按照规定算法（Ketama等），自动Build出客户端对象，具体如下图。集群服务配置图客户端对象配置图缓存Redis（R）R的简介redis是一个key-value存储系统。和Memcach