1樓：吳垚
說到分布式事務，不得不提兩位圖靈獎得主的合作文章Consensus on Transaction Commit.Jim Gray,Leslie Lamport.然後事務的話看一作的事務概念與事務的那本書，分布式的話看二作的個人主頁。
與其看其他的把你搞的雲裡霧裡的二手知識，不如直接看原作者的書和文章，反而邏輯清楚，容易理解。
此外，鎖是解決高併發讀寫引起的資料的一致性問題，單機和分布式只是從機器級別看的兩種不同的情況，這種提法常見於資料管理系統。
其實，作業系統本身從程序/執行緒級別也存在高併發讀寫引起的資料一致性問題，最近在看 operating system three easy pieces 這本書，感覺談的是同乙個問題，寫的也非常好。
建議拋開概念本身，著眼於要解決的問題的實質是什麼和解決發抽象方法理論，就好理解和融會貫通了。
話說回來，分布式事務確實比較難。如果看了以上文章和書籍，理解了，再看市面上的各種解釋，會有不一樣的感覺，不信你試試 :)
2樓：kanmars
分布式鎖一般用快取搶占式解決，沒什麼技術含量，不要相信樓上說的zk解決分布式鎖。
分布式事務現在已經不用了，技術路線大概落伍時代五至七年左右。現在一般用軟事務或者最終一致性解決。
你所說的這些技術，16年時還挺流行，如果彼時能學會，混個某司架構部主架構師傅還是不成問題的。只可惜2023年了，需要與時俱進一下。
3樓：
先看看計算機系科班課程中理論性比較強的幾門，看自己能不能保證每門課程都得優。如果不能，建議放棄這個領域。腦子不好使，是幹不好分布式的。
4樓：網易數帆
分布式鎖需要滿足如下特性：
互斥。這是鎖服務的基本能力，多個節點下必須確保同一時刻只有乙個節點能獲得鎖。
避免死鎖。死鎖在分布式環境下很容易出現，比如某個節點得到鎖之後，因為節點故障宕機，或者節點和鎖服務之間網路故障，都會造成鎖沒有機會釋放的情況。因為鎖未釋放，所以其他節點也就無法再獲得鎖提供正常服務，從而使得整個系統處於死鎖狀態。
分布式鎖服務要做的是從鎖本身出發，規避死鎖。一般可以通過對鎖加自動過期時間解決。
高效能。因為鎖服務是用來協調分布式系統中各節點的，所以很容易形成系統效能瓶頸和單點故障。效能也是分布式鎖服務是否適合生產環境的重要考慮因素。
可重入性。如果同乙個節點可以重複獲取乙個已經獲取到的鎖，這種鎖一般稱為可重入鎖。根據業務場景，我們可以按需求設計鎖服務是否支援重入性。
分布式鎖實現模型
如上圖是抽象的分布式鎖實現模型，共享儲存負責鎖和對應客戶端資訊的儲存。客戶端1發起acquire()呼叫後，共享儲存返回獲取鎖成功，當客戶端2再發起對同乙個鎖的acquire()呼叫時，共享儲存會返回獲取鎖失敗。
以秒殺場景為例，常見的分布式鎖服務的實現包括基於資料庫、基於Redis、基於ZooKeeper三種。每種方案都有在可靠性、可用性、易用性等方面的優缺點。如何根據業務場景選型，需要技術人員分析並驗證。
基於資料庫
利用關聯式資料庫支援資料的ACID強一致性和基於複製的高可用性，為系統中的競爭資源設計一張lock表。這張表用一列表示資源ID，表示正在嘗試分配的資源，這一列用UNIQUE KEY約束，通過資料庫保證這個資源ID不會被嘗試分配多次，以此來提供鎖能力，保證客戶端互斥執行。
優點：擁有較高的可靠性和穩定性。
缺點：效能會差些，並且會存在死鎖問題。
基於Redis快取
Redis提供SET NX EX原子操作，它的語義是：當KEY不存在時，SET NX返回成功，並且設定這個KEY的過期時間；當KEY已存在時，SET NX返回失敗。
我們可以構造乙個以包含寵物ID的KEY，當客戶端A執行SET NX EX 時，Redis返回成功。
在客戶端A釋放這個KEY之前，如果客戶端B也執行SET NX指令，那麼Redis會返回失敗。
優勢：有更高的效能和更低的延時，同時Redis原生支援的KEY過期機制，使得死鎖問題很容易規避。
缺點：相比基於資料庫的方案，Redis的高可用是非同步複製的，這會在極端情況下出現KEY資訊未及時同步宕機而導致鎖丟失的情況。
基於ZooKeeper
ZooKeeper天生就是提供分布式協調服務的，非常適合用來實現分布式鎖服務。有以下幾個原因：
ZooKeeper實現了Paxos一致性協議，從協議層面支援多節點的資料一致性問題，能容忍網路分割槽。
我們用乙個包含了寵物ID資訊的znode/path-to-lock/表示鎖。多個客戶端節點同時請求這個節點，只有乙個節點能返回成功，其餘返回失敗。如果未搶到鎖的客戶端關心鎖釋放問題，可以同時註冊乙個Watcher事件，等待ZooKeeper的通知。
賣一下我廠架構師編著的《雲原生應用架構實踐》，以上內容出自該書，有刪節。除了分布式鎖的內容，書中也包含分布式事務的幾種方案，但本身是解釋網際網路架構的綱要，即從單體架構到面向雲計算的分布式服務化架構的演進。雲計算是網際網路業務的標配，如有整體了解對應的架構演進的需求，建議閱讀。
5樓：斯圖亞特
學這個幹啥？沒用的東西。分布式鎖直接用zookeeper就好了。分布式事務太複雜，直接應用層解決就好了。
（更新：之前這裡有一句話，想想不太好，於是刪了）
在無鎖程式設計的專家講授無鎖程式設計的時候，通常第一句話是：盡量不使用。我想實現這樣核心的分布式演算法也是一樣。
即使是世界範圍技術強大的組，也不會輕易實現這些東西。因為要沒有bug太困難，需要太長時間打磨。我建議大家在問這個問題時候好好想一想，你真的需要嗎？
分布式資料庫的分布式事務？
NebulaGraph 業務系統往往是通過子系統組合的模式來完成,這些子系統很可能是不同的資料庫,甚至可能是 友商 的,互相直接無法保證事務,還是得業務自身保證。 codingfor 你說的單機事物，我的理解其實是指single threaded excution，而不是指在單台機器上做事物 暗含了...
oceanbase的分布式事務模型是哪種模型？
dennis 我問題裡的兩句話的意思是 個人理解 如果沒有全域性事務版本分配，直接2階段提交，那分割槽提交完成的時間不同就會導致部分分割槽在全域性事務完成提交前可見，出現讀未提交。如果使用全域性事務版本分配，如果乙個事務可見事務列表在開始時只分配一次，那就是快照隔離級，如果每個語句都獲取一次，那就是...
分布式事務中介軟體Fescar 全域性寫排它鎖解讀
你旅 跟你一樣，我以為就我這樣，還以為自己太過感性了，哎，回去不去，今天大學室友訂婚，另外乙個朋友結婚。大學的美好時光一去不返了，想著就難受 我就看看 畢業快十一年了，當時直到畢業還沒有智慧型手機，很多珍貴瞬間不能儲存在手機保留記憶，衹能靠記憶維持，越來越模糊了我，不過那份情結仍在，真的好想再去校園...