分布式内存缓存系统设计

1.问题

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

2.解决方案

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

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

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

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

4.1总体架构图

总体架构图

4.2自定义的客户端协议

  • 业务模块采用自定义应用层协议和cacheProxy交互
  • 整个cache后端采用什么协议,什么存储(redis,memcached等)对业务模块透明
  • cache后端和业务端进行了隔离,修改互不影响

4.3负载均衡与容错机制

  • 采用一致性hash算法,即使部分节点down机,也不会导致全部的缓存失效,新增节点也不会导致大量缓存失效和重建
    普通hash
    一致性hash
  • 一份缓存数据保留两份,当前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缓存
    set缓存

  • get缓存
    get缓存

5.参考资源

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值