Consistency

方案名称	核心逻辑	优点	缺点	适用场景
1. 設置緩存過期時間	MySQL更新完后，Redis不主动更新，依賴緩存到期后重新從數據庫加載。	实現簡單、無額外开開成本、管理成本低。	不一致时间较长，依賴過期時間strategy，冷數據可能導致緩存命中率低。	讀多寫少、对一致性要求不高的場景。
2. 同步双写	更新MySQL后同步更新Redis。	數據延迟较低，一致性相對较好。	双写失败风险（如Redis更新失败）；高井發時连接资源消耗较大。	对一致性要求较高，且写并發低的场景。
3. 刪除缓存後更新數據庫	先刪除Redis缓存，再更新MySQL，利用下次读取重建缓存。	避免并發寫導致緩存dirty data，簡單易用。	刪除後到數據庫更新前的間隙間，高并發讀可能重建舊數據	写操作较少，可容忍短暫不一致的場景。

| 4. 延时双刷 | 刪除cache—更新MySQL→延时（如500ms）→再次刷除缓存。 | 減少井发读導致的数据不一致概率 | 延时时间難以评估；需業務logic 配合，增加複雜度。 | 对一致性要求较高且能接受一定延时的场景。 | | 5. 异步消费者从队列 | 通过Kafka等消息队列，读取Redis更新操作异步化，保証最终一致性。 | 解耦业务与缓存操作；降低连接资源消耗| 存在延时可能问题（如消息順序有错）；需额外维护消息隊列和消费者服务。 | 高井发场景，允许短暫不一致但需可靠異步處理