二级缓存根据业务情况，本地 ttl 时间短一些、或者通过 hash 路由服务集中一些，然后在最终下单或者真正操作业务场景兜底；用缓存几乎都能容忍不一致情况，做到最终一致就行
## 缓存一致性
### double-check（常用来优化并发性能）
- 步骤
- 检查
- 加锁
- 再次检查
- 例子
- 先加读锁→检查是否符合条件→执行业务/释放读锁
- 加写锁→再次检查是否符合条件→执行业务/执行另外业务→释放写锁
- 变种
- 初次检查什么锁也不用（分布式锁里常见）
- 初次检查用原子操作（高性能中间件里常见）
### 基本思路
- 不一致的根源
- 操作部分失败
- 并发操作
- 解决方案
- 使用消息队列（保证业务内有序）
- 版本号（可用更新时间取代）
- 多级缓存
- 先更新数据库→再更新本地缓存→最后更新Redis
### 亮点方案
- 一致性哈希负载均衡和缓存
- 节点内应用singleflight模式
- 节点上线时短时间只读不写缓存（等老节点处理完已接收请求）
- 分布式锁方案
- 思路一
- 步骤：执行本地事务→加分布式锁→删除缓存→释放分布式锁
- 问题：数据可能不一致
- 思路二
- 步骤：先开启本地事务→执行事务→获取分布式锁→删除缓存→提交本地事务→释放分布式锁
- 异常
- 删除缓存失败，事务会回滚
- 删除缓存成功，提交事务失败，不影响
- 缺点：事务超市（原因1：获取不到分布式锁；原因2：网络不通删除超时）
- 变种：先获取分布式锁→开启本地事务→执行事务→删除缓存→提交本地事务→释放分布式锁