缓存实践case内部公众号消息推送限流技术栈java8spring 4.xredis技术架构封装了一个jar包实现了公众号消息推送逻辑包括限流标识key的拼接、限流校验、限流标识上传、调用消息推送接口。任何有需要的系统均可以直接运行这套逻辑异常原因推送接口定义了2个枚举通过这两个枚举叉乘组合缓存的key。有人不按约定胡乱传参与我们组内部的参数冲突导致key相同他那里触发的限流直接影响我们这边发消息排查路径虽然能确认redis缓存被乱写但是不能确认是谁乱写的基建部门反馈不支持by key的操作日志最终通过公司内人工询问才确定问题点保底解决方案新增一个我们组单独的枚举我们用新的枚举当参数调接口避免与外部冲突心得通过约定来限制动作不靠谱总有人会违反规则引发问题目录一、双写一致性1、常见的双写方案2、延迟双删3、Read/Write Through4、Write Behind二、清理机制1、时效清理2、数目阈值清理3、实战三、缓存风险1、缓存穿透2、缓存击穿3、缓存雪崩4、缓存预热四、缓存的位置1、客户端缓存2、CDN 静态缓存3、服务端 数据库缓存一、双写一致性1、常见的双写方案更新缓存再更新数据库无锁。不推荐更容易造成数据不一致更新数据库再更新缓存无锁。不推荐仅适合数据一致性要求低的场景删除缓存更新数据库cache aside 更新数据库删除缓存2、延迟双删延迟双删删除缓存更新数据库等待50ms删除缓存延迟双删重试机制增强缓存可用性比如异步线程、MQ实现延迟删除缓存canal订阅binlog直接监听数据库变更情况异步删除缓存3、Read/Write Through直接将结果写入缓存然后再从缓存将数据写入数据库由缓存保证数据一致性TCC4、Write Behind在上面做了升级将数据异步写入到数据库没必要保证缓存 数据库的强一致性可以加入消息队列保证最终一致性。二、清理机制以提高缓存命中率为目标。如果空间充足则缓存覆盖面越大越好否则要清理数据腾出空间。延长热点key寿命哪些数据是热点key一般认为过去访问多的未来访问也多最近被更新的未来访问将会很多1、时效清理轮询时效清理额外开启一个程序定期扫描所有数据的寿命到期干掉自动时效清理cookie到期自动失效2、数目阈值清理FIFO最早的缓存最先被淘汰LRU近期最少使用有序树数据被访问时置于树的头部并记录被访问次数删除尾部数据如果缓存中的数据很久没被访问那么它很可能很少被继续访问。java模拟实现MapKey, SoftReferenceT借助GC对软引用的特性实现当内存空间不足时回收软应用的对象3、实战混合清理机制时效 数据阈值。保证缓存存活一段时间就失效同时不超过目标阈值LRU 软引用空间不足时把使用频率最低的数据清理同时用软引用包装借助GC自动回收空间PS不建议仅使用软引用否则缓存数据的存活与否不能被业务控制。三、缓存风险1、缓存穿透缓存中没有目标数据数据库也没有目标数据这些无效请求每次都打到数据库缓存没生效。解决方案在缓存中放个空值存储个value null的数据2、缓存击穿几个热点缓存数据失效后请求直接打到数据库由数据库兜底这种情况叫击穿解决方案LRU处理缓存数据高频访问的数据不易被清理3、缓存雪崩大量缓存同时失效大量请求倾泻到数据库数据库压力骤增解决方案时效式清理随机过期时间错开缓存失效时间固定时长 随机时长热点key自动续期对于经常访问的缓存key可以适当延长其存活时间数据阈值清理使缓存容量达到设定的阈值才使缓存数据失效防止大量缓存失效软引用清理依赖垃圾回收机制单纯的软引用无法解决缓存雪崩。可以配合LRU对热点数据改造成强引用4、缓存预热系统冷启动时缓存中无数据所有请求都到数据库查数据才会逐渐把数据带到缓存中那么系统启动初期查询性能势必不太好。可以在系统启动时可以提前加载一些数据对缓存预热提高缓存的命中率。如果缓存的清理机制是时效式清理的话会存在缓存重复预热的风险。四、缓存的位置1、客户端缓存客户端也能存储缓存数据只和客户有关的数据放在用户的设备上分散计算压力比如游戏的素材浏览器缓存cookie一般特别轻量级的数据使用cookie做缓存cache storage存储请求和响应避免相同的请求又打到了后端application storage缓存页面app客户端sqlite - 安卓端数据库存储规则类的数据或者开机图片、引导页等数据2、CDN 静态缓存静态资源包括页面、图片等数据*与用户个体无关有通用性的数据比如行政区划、网站公告等3、服务端 数据库缓存服务端缓存代表redis、localcache数据库缓存服务与数据库磁盘中的数据交互需要通过io此时做缓存有正向收益。降低数据的实时一致性比如用户的广告账户虽然投放一次广告扣一次钱但是不会立即更新用户的余额而是在第二天凌晨计算昨天的消费金额统一做余额扣减整合多笔小钱只做一次扣减。又比如把商品数据存储到订单表通过快照的形式减少关联查询。五、写缓存架构思想不着急的事情可以放到后面统一处理尽量减少交互把低峰期的算力利用起来。写缓存存在于调用方和处理方之间目的是减少固定时间内调用写操作接口的次数让流量尽量平稳一些简单理解就是削峰实践就是用MQ、redis 发布订阅。收益从用户体验来看程序响应迅速。程序整体效率提升太耗时的操作留到后台慢慢处理也不会对处理方造成太大的压力。1、平峰正常处理超过预设阈值写缓存如何设计大厂常见方案系统平滑过渡当短时间请求过多时可以将请求分发到带写缓存的数据中灰度发布灰度规则中根据阈值的不同选择不同的远程服务发放请求如果还扛不住就只能限流 互联网三高架构 二 - 缓存设计
缓存实践case内部公众号消息推送限流技术栈java8spring 4.xredis技术架构封装了一个jar包实现了公众号消息推送逻辑包括限流标识key的拼接、限流校验、限流标识上传、调用消息推送接口。任何有需要的系统均可以直接运行这套逻辑异常原因推送接口定义了2个枚举通过这两个枚举叉乘组合缓存的key。有人不按约定胡乱传参与我们组内部的参数冲突导致key相同他那里触发的限流直接影响我们这边发消息排查路径虽然能确认redis缓存被乱写但是不能确认是谁乱写的基建部门反馈不支持by key的操作日志最终通过公司内人工询问才确定问题点保底解决方案新增一个我们组单独的枚举我们用新的枚举当参数调接口避免与外部冲突心得通过约定来限制动作不靠谱总有人会违反规则引发问题目录一、双写一致性1、常见的双写方案2、延迟双删3、Read/Write Through4、Write Behind二、清理机制1、时效清理2、数目阈值清理3、实战三、缓存风险1、缓存穿透2、缓存击穿3、缓存雪崩4、缓存预热四、缓存的位置1、客户端缓存2、CDN 静态缓存3、服务端 数据库缓存一、双写一致性1、常见的双写方案更新缓存再更新数据库无锁。不推荐更容易造成数据不一致更新数据库再更新缓存无锁。不推荐仅适合数据一致性要求低的场景删除缓存更新数据库cache aside 更新数据库删除缓存2、延迟双删延迟双删删除缓存更新数据库等待50ms删除缓存延迟双删重试机制增强缓存可用性比如异步线程、MQ实现延迟删除缓存canal订阅binlog直接监听数据库变更情况异步删除缓存3、Read/Write Through直接将结果写入缓存然后再从缓存将数据写入数据库由缓存保证数据一致性TCC4、Write Behind在上面做了升级将数据异步写入到数据库没必要保证缓存 数据库的强一致性可以加入消息队列保证最终一致性。二、清理机制以提高缓存命中率为目标。如果空间充足则缓存覆盖面越大越好否则要清理数据腾出空间。延长热点key寿命哪些数据是热点key一般认为过去访问多的未来访问也多最近被更新的未来访问将会很多1、时效清理轮询时效清理额外开启一个程序定期扫描所有数据的寿命到期干掉自动时效清理cookie到期自动失效2、数目阈值清理FIFO最早的缓存最先被淘汰LRU近期最少使用有序树数据被访问时置于树的头部并记录被访问次数删除尾部数据如果缓存中的数据很久没被访问那么它很可能很少被继续访问。java模拟实现MapKey, SoftReferenceT借助GC对软引用的特性实现当内存空间不足时回收软应用的对象3、实战混合清理机制时效 数据阈值。保证缓存存活一段时间就失效同时不超过目标阈值LRU 软引用空间不足时把使用频率最低的数据清理同时用软引用包装借助GC自动回收空间PS不建议仅使用软引用否则缓存数据的存活与否不能被业务控制。三、缓存风险1、缓存穿透缓存中没有目标数据数据库也没有目标数据这些无效请求每次都打到数据库缓存没生效。解决方案在缓存中放个空值存储个value null的数据2、缓存击穿几个热点缓存数据失效后请求直接打到数据库由数据库兜底这种情况叫击穿解决方案LRU处理缓存数据高频访问的数据不易被清理3、缓存雪崩大量缓存同时失效大量请求倾泻到数据库数据库压力骤增解决方案时效式清理随机过期时间错开缓存失效时间固定时长 随机时长热点key自动续期对于经常访问的缓存key可以适当延长其存活时间数据阈值清理使缓存容量达到设定的阈值才使缓存数据失效防止大量缓存失效软引用清理依赖垃圾回收机制单纯的软引用无法解决缓存雪崩。可以配合LRU对热点数据改造成强引用4、缓存预热系统冷启动时缓存中无数据所有请求都到数据库查数据才会逐渐把数据带到缓存中那么系统启动初期查询性能势必不太好。可以在系统启动时可以提前加载一些数据对缓存预热提高缓存的命中率。如果缓存的清理机制是时效式清理的话会存在缓存重复预热的风险。四、缓存的位置1、客户端缓存客户端也能存储缓存数据只和客户有关的数据放在用户的设备上分散计算压力比如游戏的素材浏览器缓存cookie一般特别轻量级的数据使用cookie做缓存cache storage存储请求和响应避免相同的请求又打到了后端application storage缓存页面app客户端sqlite - 安卓端数据库存储规则类的数据或者开机图片、引导页等数据2、CDN 静态缓存静态资源包括页面、图片等数据*与用户个体无关有通用性的数据比如行政区划、网站公告等3、服务端 数据库缓存服务端缓存代表redis、localcache数据库缓存服务与数据库磁盘中的数据交互需要通过io此时做缓存有正向收益。降低数据的实时一致性比如用户的广告账户虽然投放一次广告扣一次钱但是不会立即更新用户的余额而是在第二天凌晨计算昨天的消费金额统一做余额扣减整合多笔小钱只做一次扣减。又比如把商品数据存储到订单表通过快照的形式减少关联查询。五、写缓存架构思想不着急的事情可以放到后面统一处理尽量减少交互把低峰期的算力利用起来。写缓存存在于调用方和处理方之间目的是减少固定时间内调用写操作接口的次数让流量尽量平稳一些简单理解就是削峰实践就是用MQ、redis 发布订阅。收益从用户体验来看程序响应迅速。程序整体效率提升太耗时的操作留到后台慢慢处理也不会对处理方造成太大的压力。1、平峰正常处理超过预设阈值写缓存如何设计大厂常见方案系统平滑过渡当短时间请求过多时可以将请求分发到带写缓存的数据中灰度发布灰度规则中根据阈值的不同选择不同的远程服务发放请求如果还扛不住就只能限流