**問題描述：**多客戶端同時并發寫一個key，可能本來應該先到的數據后到了，導致數據版本錯了。或者是多客戶端同時獲取一個key，修改值之后再寫回去，只要順序錯了，數據就錯了。 我個人認為比較好的方案是分布式鎖+時間戳： **1.整體技術方案** 這種情況，主要是準備一個分布式鎖，大家去搶鎖，加鎖的目的實際上就是把并行讀寫改成串行讀寫的方式，從而來避免資源競爭。利用SETNX非常簡單地實現分布式鎖。 **2.時間戳** 由于key的操作需要順序執行，所以需要保存一個時間戳判斷順序。假設系統B先搶到鎖，將key1設置為{ValueB 7:05}。接下來系統A搶到鎖，發現自己的key1的時間戳早于緩存中的時間戳（7:00<=7:05），那就不做set操作了。 **3.什么是分布式鎖** 分布式鎖可以基于很多種方式實現，比如zookeeper、redis等，不管哪種方式實現，基本原理是不變的：用一個狀態值表示鎖，對鎖的占用和釋放通過狀態值來標識。 **保證緩存與數據庫雙寫時的數據一致性** 可能對大部分來說最先想到的方案就是讀請求和寫請求串行化，串到一個內存隊列里去。但是這個方案有著特別大的缺點：它也會導致系統的吞吐量大幅度降低，用比正常情況下多幾倍的機器去支撐線上的一個請求。 **最經典的緩存+數據庫讀寫的模式。** 讀的時候，先讀緩存，緩存沒有的話，就讀數據庫，然后取出數據后放入緩存，同時返回響應。 更新的時候，先更新數據庫，然后再刪除緩存。