一、問題產生
時間是一個絕對量，而實體計算機的時間是相對量
1、 物理天地本身導致的時間不一致，地球自轉、閏年、閏秒
2、 現實的不能絕對一致性，A機器時間同步至B機器，網絡傳輸時間是不確定性的，AB存在絕對不一致性
如上圖，computer A在2144 Tick點執行分布式任務 create output.o，注意2144是A的絕對計算量、而此時的集群computer B也許出於2143 Tick點，即使B也運氣恰到好處的出於2144 Tick，A任務同步至B消耗的Tick是不確定的。獲取是2144也有可能是2143，倘若如上圖，ouput.c created在B小於created 2144時間點，時間戳make問題就出現了。
二、邏輯時鍾
1、Berkeley算法：分布式服務器定時輪詢所有服務器，各台服務器依據同步結果，決定本台服務器的Tick快慢同步是時間
三台服務器明顯不一致，3:00仲機器在輪詢其他機器時候，分別有2:50,3:25，那么他們是分別加10分鍾和減20分鍾來同步時間嗎？顯然不行，各台機器本身是存在事務日志的，如果本身時間進行人為修改，事務時間戳就會出現混亂。此時應該是各台服務器調慢或調快各自時間Tick已達到三台時間Tick一致。
2、 Lamport算法時鍾同步
在紅箭頭時間點，從理想主義角度而言，始終應該是一致的，但現實是明顯不一致的，兩條偏移線要向Perfect看齊
T2的時間傳播到T1，T1時間Tick慢，T4在應答時間戳上要進行同步了，解決上述問題
保證邏輯的一致性就需要計算出偏移量，偏移量用途
P1發起分布式任務到P2大於任務時間戳6，繼續傳播到P3小於時間戳40，應答回傳56，時間戳小了，如果繼續回傳P1 54，更小了，於是需要計算偏移量機型時間一致性
如：
偏移量調整時間過程示意
Perfact解決方案
不使用同步算法，導致的結果是災難性的，update1和update2的任務在1和2上的執行順序顯然不能混亂，並且需要連續性。就好比銀行是先轉賬還是先計息，也許，或者可能這是業務需要考慮的問題，ok，那么1和2能夠一致性執行update1和update2就是分布式需要解決的技術問題。
解決
1在執行update1時候進行廣播，”你們都給聽好了，我要執行update1操作”
2收到廣播“好的，你執行，我也開始執行了”
於是update1的執行保障了一致性。當2故障或者2沒有收到update1或update2，廣播應答結果就是“NO，你別執行哈，執行要出亂子的”，ok，connection refused or time out。
3、因果一致性
P0執行任務，寫入時間戳100，廣播P1、P2，P2執行相同的分布式任務，P2這是發起了分布式任務寫入時間戳110,100和110廣播到P2時候，P2執行100時候，發現時間戳有問題，告訴P2不能執行110和000, 因為100尚未執行，那么按照時間戳排序執行。
鎖的因果一致性
1執行3並取得3 locker，2需要執行3，不好意思，3已經被locker，進入隊列，當3被釋放才有2的執行權。