1樓：neal ho
點一下vector clock跟其他方案的核心區別vector clock核心是講是非同步網路下的方案，而且偏重理論，並不是很好的工程化方案，其他方案（Timestamp、原子鐘）都是同步網路下的解決方案，而且比較好工程化。
真實的無約束的網路是非同步網路，我們可以新增一些約束使是變成同步網路。現在多數實踐也是這麼做的，比如機器上安裝原子鐘，上ntp校時等。
就像你中學物理學到的那些知識都是理想情況下的理論，真正到了工程實踐（蓋房，造車）還是有很多變通的。
2樓：科技大昊哥
標量邏輯時鐘就是你說的timestamp或者單調遞增的邏輯時鐘，只能保證事件在分布式系統中的半序，所以實際上它能區分有因果關聯的事件的序，但是不能確定沒有因果關係的事件間的序。
而向量邏輯時鐘是全序的。
缺點是向量邏輯時鐘訊息體量大，開銷大，沒有和本地時間的對照關係等hlc很好的解決這個問題
3樓：沈詢
沒那麼複雜。。
其實這裡有個關鍵的問題就是讀寫順序問題。
對於乙份共享的資料，我們對他能做的操作就兩個，第乙個是寫，第二個是讀。 這兩個操作有四種組合，寫寫，讀讀，讀寫，寫讀。
如何能夠在保證語義不變的前提下，讓使用者看起來是有正確的讀寫順序關係的？ 這就是所有一致性演算法要解決的共性問題。
包含vector clock . 你可以嘗試把上面的內容帶入進去看看？：）
詳細內容可以見我的部落格中的一致性專題 沈詢所有資源的索引（會不斷更新）
4樓：fleuria
vector clock 要求每次請求前先向對方拿一次版本，這個效能不大好接受；
只能幫助發現衝突，但對解衝突沒有幫助，如果併發地修改了兩個不同的字段，vector clock 只能告訴你整個紀錄有衝突，不能精確到字段；
riak 那個人工合併衝突的 siblings 機制比較殘，解衝突的速度一旦跟不上併發更新的速度（這是肯定的事），就炸了...
這樣反過來看，ntp 同步的系統時間也沒有那麼差：
多數時間裡都是好的；
足夠拿來發現衝突，不准的 last write wins 也是 last write wins；
cassandra 的併發控制以列為單位，相比以整個記錄為單位，衝突更容易合併；
對於有 linearizability 需求的場景，請一律使用 lightweight transaction 走乙個 paxos 協調做 CAS 的樂觀併發控制；
這意味著如果不用 lightweight transaction，cassandra 是不能保證 linearizability 的，也就是會丟寫，如果乙個節點的時鐘不同步，慢了幾秒，這個節點跟人衝突時就永遠寫不進東西了。
5樓：Dongdong
一般對於普通的分布式系統來說，時間戳是可用的，通過NTP等協議可以保證乙個機房內的集群時鐘是同步的，誤差在幾百個ns，這樣對於大部分應用而言定序也夠了。但對於dynamo系列的分布式資料庫而言，它最大的特點就是解決跨機房的分割槽問題，重點就是「跨機房」寫事務的高可用性，目前還沒有什麼措施來控制多機房時鐘同步誤差。利用GPS原子鐘是乙個可行的方法，Google的最新分布式儲存Spanner裡用到了。
6樓：唐小新
很簡單，既然是分布式系統，你無法保證集群中的每台機器的時間都是一樣的（有的快幾分鐘，有的慢幾分鐘），所以，如果你想通過時間戳來區分一條record的先後順序，顯然不是很精確的。
分布式資料庫，如hadoop cassandra mysql集群，主流是採用什麼儲存技術，DAS NAS還是SAN？
如果簡單的回答題主的問題，那麼答案是DAS。除了MySQL以外，其他的都是經典的分布式系統。這些分布式系統通常假定任何裝置都是不可靠的，演算法上會對資料做冗餘儲存，因此對介質本身的要求相對較低，DAS即可。MySQL相對特殊。一般而言，如果用MySQL，題主要用的是關聯式資料庫，且資料一般是比較重要...
分布式資料庫計算引擎對分布式儲存系統底座提出了哪些新的技術挑戰？
lemon wonder 我說一下HTAP情況，對於資料庫，TP主要是事務相關，一般底層儲存引擎使用行存，對於AP是分析性，對事務要求沒那麼高，一般用列存，要處理HTAP，那要做到行列混合儲存就很困難。對於儲存引擎，一種是外掛程式型，向MySQL中，SQL和儲存約定好介面，實現介面並直接使用。但是要...
分布式資料庫如何解決儲存過程？
xchliu 這是個好問題。事實上，太多的系統使用儲存過程來實現業務場景了，雖然在網際網路不多，畢竟網際網路系統沒有歷史包袱。在傳統企業系統中，儲存過程改造問題是非常艱鉅的任務。於是才有了這個問題，也就是說分布式資料支援儲存過程，改造代價就會小很多。而從分布式資料庫實現的角度，變成了乙個選擇題 要不...