多模块服务协作开发背景下,随着缓存越来越多,缓存的一致性维护难度随之提升。
多模块服务之间的缓存 key 维护容易造成遗漏,如 OP 与各服务之间的缓存交互。
单独模块多人开发甚至独立开发时,随着业务缓存的数量增多,在缓存的处理上也会有遗漏。
结论:
人工维护极易遗漏,沟通时也会出现理解偏差,造成缓存不一致,后期排查定位问题难度增加。其中的种种,带来很多的时间成本、沟通成本和开发成本。
难点其实在于 数据查询方 与 数据更新方 的沟通问题,思考:
结论:
加缓存时通知加了 什么表 的缓存,什么时候 需要刷新缓存;
数据表更新时按照缓存的 刷新时机 刷新。
首先讨论缓存的更新机制都有哪些:
解决思路:
按更新机制配置 Hash name , 命名方式为 表名 + 更新机制,下属 key 的命名可以按照模块前缀 + 自定义方式。
缓存的刷新由服务本身管理 + Syncer 统一管理的方式。服务可以自主更新缓存,并发送更新消息至 Syncer , 解析消息后刷新缓存。
消息格式:
表 + 更新机制 即上述的 Hash name,对应的更新机制消息:
交互图:
{"source":"app1","id":1...}
,其中 source 是标示发消息的应用,再带上关注的索引,一般 key 都是以重要的索引来作区分,比如 id ,userId...