前言
最近看了一些螞蟻金服的面試分享文章，裏面多次提到分佈式系統涉及的概念，比如分佈式事務、接口的冪等性，樂觀鎖、數據一致性等。筆者一時也說不清楚，後來查詢了一些資料，整理下來，以備後用。
系統衡量關鍵指標
QPS：單位時間內處理完請求次數。一個系統的qps是100，則代表一秒鐘內處理100個請求。
TPS：單位時間內處理完事務的次數。在分佈式系統中，對應的是分佈式事務。
併發量：在某一時刻，請求同時到達的數量。最大併發量，即系統能同時處理的最大請求數量。
響應時間：系統處理一次請求的平均時間。
QPS（TPS）=併發量/響應時間 或 QPS（TPS）=請求總數/總時長
舉例：
一個典型的上班簽到系統，早上8點上班。7點半到8點這30分鐘的時間裏用 戶會登錄簽到系統進行簽到。公司員工爲1000人，平均每一個員上登錄簽到系統的時長爲5分鐘。能夠用以下的方法計算。
QPS = 1000/(30*60) 事務/秒
平均響應時間爲 = 5*60 秒
併發數= QPS*平均響應時間 = 1000/(30*60) *(5*60)=166.7
CAP原則
C（consistency）：一致性。在分佈式系統中某一個節點寫入後，讀其他節點都能讀到最新寫入的數據。
A（availability）：可用性。系統保持可用，但是不保證數據是最新的。
P（partition tolerance）：分區容錯。一個分佈式系統存在多個網絡節點，當網絡節點之間由於網絡斷了，節點之間不能通信，造成分區網絡時，系統仍舊可以繼續工作。
CAP原則就是以上三種只能滿足其中的兩種。不可能同時滿足三種。
一般網絡都不可能保證100%沒問題，所以每個組合都包含P，即CA組合幾乎是不存在的。重點關注的是CP、AP組合。
本地數據庫事務ACID
A：原子性(Atomicity)，一個事務內的所有操作要不全部成功，要不全部失敗，沒有中間狀態。
C：一致性(Consistency)，事務之前之前和執行之後，數據庫狀態保持一致。
I：隔離性(Isolation)，指的是在併發環境中，當不同的事務同時操縱相同的數據時，每個事務都有各自的完整數據空間。查詢數據時，要不就是事務處理之前的狀態，要不就是事務處理之後的狀態，中間狀態看不到。
D：持久性(Durability)，指的是隻要事務成功結束，它對數據庫所做的更新就必須永久保存下來。
分佈式事務
分佈式系統就是把一個大的集成系統拆分成多個子系統，這些子系統分佈在不同的機房，處理一個請求就要經歷多個子系統。比如電商，用戶下訂單後，由訂單系統和庫存系統來處理。一個分佈式事務就包括，訂單系統扣除用戶餘額以及庫存系統減少一件商品的庫存。這兩個操作是要同時完成的，要麼都成功，要麼都失敗。分佈式事務的方案有2PC、TCC、MQ等。
BASE原則
BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫，是對 CAP 中 AP 的一個擴展。現在很多主從數據庫都滿足最終一致性，而不是強一致性。
冪等性
用戶對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因爲多次點擊而產生了副作用。舉個最簡單的例子，那就是支付，用戶購買商品使用支付，支付扣款成功，但是返回結果的時候網絡異常，此時錢已經扣了，用戶再次點擊按鈕，此時不會再扣款，並返回成功結果。採用全局唯一ID來保證冪等性。
悲觀鎖
總是假設最壞的情況，每次去拿數據的時候都認爲別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖。傳統的關係型數據庫裏邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。再比如Java裏面的同步原語synchronized關鍵字的實現也是悲觀鎖。
樂觀鎖
顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像數據庫提供的類似於write_condition機制，其實都是提供的樂觀鎖。在Java中java.util.concurrent.atomic包下面的原子變量類就是使用了樂觀鎖的一種實現方式CAS實現的。
以上介紹了分佈式中的一些常見概念，理解了這些概念就容易更好的設計出分佈式系統。如何保證分佈式系統中的數據一致性呢？自己進行思考。
