1.问题
任何平台随着用户规模的扩大、功能不断的添加，持久化数据库层承受的读写压力会越来越大，一旦数据库承压过大会导致读写性能陡然下降，严重时会导致大量的业务请求超时，进而发生“雪崩”引发严重的故障。
2.解决方案
在业务层和数据库持久层之间引入一层内存缓存层，对于复杂且业务逻辑上不会变化的查询结果进行缓存，业务请求再次发起时，每次都先从缓存层中查询，从而大大减少对数据库的查询，减小对数据库的压力。
3.分布式内存缓存、本地单点缓存、应用层缓存对比
| 类型 | 稳定性 | 扩展性 | 通用性 | 对代码的侵入性 |
|---|---|---|---|---|
| 应用层缓存 | 应用会频繁重启更新，缓存易丢失，稳定性不佳 | 差，受限于进程的资源限制 | 差，不同应用难以复用 | 代码侵入性小，无网络操作，只需要操作应用进程内存 |
| 本地单点缓存 | 独立的缓存应用（redis、memcached等），不会频繁重启，稳定性一般，但有单点故障问题 | 一般，受限于单服务器资源限制 | 一般，业务应用和缓存应用有强耦合 | 代码侵入性一般，需要引入对应的api通常有网络操作 |
| 分布式内存缓存 | 分布式系统，具备故障自动恢复功能，无单点故障问题，稳定性佳 | 好，支持水平扩展 | 好，对业务层提供通用接口，后端具体的缓存应用对业务透明 | 代码侵入性一般，需要引入通用的api通常有网络操作 |
4.分布式内存缓存系统设计
4.1总体架构图
总体架构图.jpg4.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原理：
- 一致性hash实现：
- redis通讯协议规范：