新建
单条
定时任务
zset2用于刷脏
删除
key
field
score
list_4975157
160966739
time_stamp
check_20210604
4975157
1622793401
Redis（string结构）
客户端
list_{uid}
{tid}
采用一种/多种补偿同步机制进行缓存刷脏，保证最终一致性
user_template
部分没有缓存
list_4975157，list_1772758，……1、永不过期（如果内存不够可以设置过期+访问初始化）2、每次新建/更新覆盖原有数据3、用户访问时，如果不存在则初始化。
redis缓存缓存最终一致性的结果数据
保存结果
部分冷数据
......
全是热数据
是
前端触发
Redis（zset结构）
取出最近更新uid用于刷脏
已知的 BUG当前验证逻辑，经过记录昨天的redis.log日志发现已知BUG 如下1.可能某些修改模版的入口没找到，如果所有查询改用新的read流程逻辑，可能会出问题。解决办法：A：查询前台程序所有user_templaet相关性，先补上漏洞。B：跟人员校对，尽量查漏补缺。C：分阶段上线，先上write部分，然后上线测试人员id走read逻辑，等没问题再释放。
补偿机制（可列队或消息通知）
info_v1_162017026
{jsonString}
否
redis
write
mysql
单台mysql数据库
缓存模版详情数据（土豪装备）
read
列表排序
目标：1、接受uid，快速获取对应tid信息。2、接受uid、快速获取tid列表，并且排序。
是否列表
更新
info_v1_160966739，info_v1_162017026，……1、一周过期（工作台展示一周内数据，打开就用缓存，速度非常的快）（热数据）2、每次新建/更新覆盖原有数据，并且重置过期时间3、用户访问时，如果不存在则查询mysql数据库（冷数据）
value
info_v1_{tid}
{模板需要展示的数据}
处理完成
是否存在更新时间大于一周
用于单个
check_20210604，check_20210604，……1、后台脚本进行读取uid获取mysql中用户所有模版id。2、读取uid获取zset1中用户所有模版id。3、对比数量和日期：>1.如果redis中数据少，则追加少的id。>2.如果数量一致，则跳过。确保最终一致性。4、建议使用单独一台读库进行，跟线上读写库分开。5、最终结果只操作redis zset集合。
zset1用于列表
全部命中缓存
移除
消息通知
是否命中
暂时不用
check_{data}
{uid}
{time()}
