策略一：讀填寫刪
缺點：如果執行順序是B1B2、A1A2、B3，那麼就出現cache和db資料不一致（即“過期寫入”）
策略二：B站策略
這樣就不會出現策略一的情況了。但是執行緒A可能出現A2執行失敗的情況，可以透過MQ任務來重試。
B站這裡透過資料庫binlog的非同步佇列來再次寫cache。
策略三：cache版本號
每次寫cache的時候有一個版本號，版本號可以用db的最後修改時間。
這樣在執行順序是B1B2、A1A2、B3時，執行B3的時候檢查cache的現有版本號，發現比它小則不寫cache。
但是同樣會有策略二的問題。
策略四：Facebook策略
在策略一的基礎上有如下規則：
- 執行緒B在cacheMiss後會得到一個lease，在步驟3寫cache的時候帶上
- 多個執行緒在對同一個key的cacheMiss，10秒內只有一個執行緒得到lease
- 只有帶lease的客戶端才能寫cache
- 同一個key在被刪除後，刪除操作之前的lease無效，重新發放lease（key並沒有真正刪除，這樣沒有得到lease的執行緒可以讀舊資料）
同樣會有策略二的問題。
本作品採用《CC 協議》，轉載必須註明作者和本文連結