分布式内存缓存系统设计

1.问题

任何平台随着用户规模的扩大、功能不断的添加，持久化数据库层承受的读写压力会愈来愈大，一旦数据库承压过大会致使读写性能陡然降低，严重时会致使大量的业务请求超时，进而发生“雪崩”引起严重的故障。

2.解决方案

在业务层和数据库持久层之间引入一层内存缓存层，对于复杂且业务逻辑上不会变化的查询结果进行缓存，业务请求再次发起时，每次都先从缓存层中查询，从而大大减小对数据库的查询，减少对数据库的压力。

3.分布式内存缓存、本地单点缓存、应用层缓存对比

类型	稳定性	扩展性	通用性	对代码的侵入性
应用层缓存	应用会频繁重启更新，缓存易丢失，稳定性不佳	差，受限于进程的资源限制	差，不一样应用难以复用	代码侵入性小，无网络操做，只须要操做应用进程内存
本地单点缓存	独立的缓存应用（redis、memcached等），不会频繁重启，稳定性通常，但有单点故障问题	通常，受限于单服务器资源限制	通常，业务应用和缓存应用有强耦合	代码侵入性通常，须要引入对应的api一般有网络操做
分布式内存缓存	分布式系统，具有故障恢复功能，无单点故障问题，稳健性佳	好，支持水平扩展	好，对业务层提供通用接口，后端具体的缓存应用对业务透明	代码侵入性通常，须要引入通用的api一般有网络操做

4.分布式内存缓存系统设计

4.1整体架构图

4.2自定义的客户端协议

• 业务模块采用自定义应用层协议和cacheProxy交互

• 整个cache后端采用什么协议，什么存储（redis，memcached等）对业务模块透明

• cache后端和业务端进行了隔离，修改互不影响

4.3负载均衡与容错机制

• 采用一致性hash算法，即便部分节点down机，也不会致使所有的缓存失效，新增节点也不会致使大量缓存失效和重建
  

• 一份缓存数据保留两份，当前hash节点和下一个真实的hash节点（超时时间只有设置的超时时间的一半），单个节点down机时，缓存也不会立刻失效
  

• cacheMan是一个弱的管理节点，负责监控，删除节点，新增节点，能够任意启停

4.4缓存维护与淘汰机制

redis原生超时机制+三层LRU缓存架构，减小最终穿透到redis实例上的请求。

• 客户端LRU缓存

• cacheProxy代理LRU缓存

• redis实例内存总量限制+LRU缓存

4.5安全机制

• redis实例都会开启auth功能

• redis实例都监听在内网ip

4.6核心流程

• 新增redis节点
  

• 删除redis节点
  

• set缓存
  

• get缓存
  

5.参考资源

• 一致性hash原理：http://blog.codinglabs.org/ar...

• 一致性hash实现：https://github.com/pzx6019171...

• redis通信协议规范：http://www.redis.cn/topics/pr...