單機是最好的架構之三鎖

自己原文公眾號： https://mp.weixin.qq.com/s/WB83b6o_FoUtb-KJFBhoqQ

有時候發現開發其實分不清鎖和死鎖、以及怎麼會造成這種。為了防止鎖把架構變得複雜，但是其實沒什麼用。比如我賬戶有10元錢，我需要買一個5元的東西還要買一個6元的東西。結果是我最多隻能買一樣。這是數學問題而不是資料庫問題。不少時候開發同學怕鎖，結果設計了非同步或者快取再或者你想不到的操作。比如拿到了請求，怕對資料庫造成鎖，進而導致壓力，就走訊息佇列。（然並卵）其實不管你走十八般武藝的技術，最終11>10註定了你有一個失敗。如果成功了，那就是呵呵了。其實鎖不可怕，鎖是防止你資料錯亂、資料不一致。我們應該感謝鎖的存在。

     剛才說的是一個減法，如果是一個變更呢？資料庫叫做A，有一個人想把一個商品的價格B改成2，同時另外一個人想把這個商品的價格B改成3.這就是鎖了。一定是後面的覆蓋了前面一個。如果前面的非同步解決不了（註定是解決不了的），這個時候繼續腦洞開啟，說單體資料庫太差了。我們上分散式資料庫吧。這個時候資料庫有A 變成了A1 A2 A3.結果就是在A1上的B是2 在A2上的B是3. （我們這裡先不談衝突檢測）。那這個結果是預期想要的嗎？顯然不是。分散式資料庫是怎麼解決的了？那就是所有的寫要先進行排隊確定先後順序，然後比如A2 A3上的請求先到A1上集中，都在A1上集中完了，在導A2 A3上去重放。（也許不是全部的分散式資料庫都這樣，但是至少有的分散式資料庫是這樣）所以最終只要是要求一致性還是逃不過的。除非你不要一致性。

    在一致性的要求前，如果單機還弄明白鎖和效能壓力這些問題，那遇到分散式的檢測，就更加複雜了。就像初中數學都不幾個的話，高中的也一樣不及格。當你有一塊手錶時候你知道幾點，當有幾塊手錶時候你不知道幾點。