**：
一、問題產生
時間是乙個絕對量，而實體計算機的時間是相對量
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，更小了，於是需要計算偏移量機型時間一致性
如：
偏移量調整時間過程示意
pe***ct解決方案
不使用同步演算法，導致的結果是災難性的，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的執行權。
分布式 集群時鐘同步配置
集群時鐘同步思路 1.分布式集群中各個伺服器節點都可以連線互聯 思路 操作 式 使 ntpdate 絡時間同步命令 ntpdate u ntp.api.bz 從 個時間伺服器同步時間 windows有計畫任務 linux也有定時任務，crond，可以使 linux的定時任務，每隔10分鐘執 次ntp...
分布式系統 向量時鐘
注意 首先我們來回顧一下 lamport 邏輯時鐘演算法，它提供了一種判斷分布式系統中事件全序關係的方法 如果 a b，那麼 c a c b 但是 c a c b 並不能說明 a b。也就是說c a c b 是 a b 的必要不充分條件，我們不能通過 lamport 時間戳對事件 a b 的因果關係...
分布式系統session同步解決方案
session的概念 當瀏覽器端第一次訪問web server時，server端會呼叫getsession 方法建立session物件，經過特殊演算法計算出sessionid，儲存在伺服器端，同時response給瀏覽器 第二次在來請求時會在request header中帶著sessionid訪問伺...