協同編輯是指多人同時對同乙份文件進行編輯。
但是這三個問題會形成乙個不可能三角
即任意方案只能滿足其中2個點，犧牲第3個點。
有的同學可能對這個三角形不是很理解。
我們可以這樣類別，將協同編輯的文件模擬為分布式資料庫，編輯者類別為資料庫的讀寫服務，那麼我們的這個三角形就可以轉換為cap不可能三角
關於cap定理，可以參見我的部落格一文看懂cap定理_黃騰霄的部落格-csdn部落格
架構抉擇第一件要做的事情是挑出哪些點是必須要滿足的，哪些點是可以妥協的。
這裡我們會選擇實時性和容錯性：
容錯性：實現分布式協同和遠端辦公的基礎，也是協同的必要條件
那為什麼一致性可以妥協呢？
首先我們要基於這乙個假設:
在實時協同編輯的場景下，衝突是小概率事件。
就是說大部分情況下，協同編輯的參與者都會在文件的不同部分進行操作，而很少會同時對同一區域進行操作。
因此我們需要處理一致性問題的情況較少。
另外，我們只是放棄強一致性，在各端同步之後，能夠較快的恢復到完全一致的狀態，實現最終一致性。
如果熟悉git的同學，就會發現diff-patch和git的版本管理基本一致。
當出現版本衝突時，會通過diff演算法計算出，兩個版本之間的差異值，然後生成乙個patch，將兩個版本的內容合併。
這樣就能讓伺服器端和本地端的文件內容重新保持一致。
但是diff-patch這種方式是基於文件內容比較的，那就意味著一旦出現對同一行的操作衝突，就需要人工介入，選擇其中乙個版本的內容。
例如git，出現合併衝突時，需要開發者對所有衝突部分進行人工處理。否則很容易出現無法執行的**。
這種方式適用於「編輯——儲存——解決衝突」的互動方式，比如kb文件。
operational transformation方法是將所有的編輯行為封裝成乙個個的操作。
各個編輯者執行單個操作後，會將操作資訊同步到各個協作端。
協作端根據操作的執行時間戳，調整文件狀態，保持各端操作順序的一致性。
注意的一點，operational transformation只是一種操作思想，具體的操作實現可以按照業務情況處理。
下面是我思考的兩種操作方式：
在實際的應用中，我們可以採用兩者結合的方式。
此時操作變更較少，衝突和補償處理也會比較輕量，對使用者感知少。
在出現較長時間斷線，或者離線編輯的情況下，可以在連線後進行一次diff-patch，確保較大部分的改動可以同步。
本文會經常更新，請閱讀個人部落格原文： ，以避免陳舊錯誤知識的誤導，同時有更好的閱讀體驗。
spark的架構思考（一）
任何架構都是由需求分析得來，而spark是由怎麼樣的需求分析而來的呢？需求 怎樣快速計算大資料 解決方案 將大量的資料分成很多塊，讓不同的計算機進行計算，然後再彙總起來，這就是簡單的mr計算模型。但是hadoop的mr計算模型，太單一，而且重度依賴io，新的需求 需求又來了，怎樣又讓它快，又讓它計算...
運維平台系列 關於DevOps平台架構思考
現在很多公司都在推行devops平台。為了能夠提公升研發運維效率。這一章節主要寫點關於偏ops層面的東西，dev層面的東西主要涉及到研發域的內容包括 管理 編譯與發布管理 研發流程專案管理及bug管理等。乙個大的產品與技術架構圖 後續會將各個子產品域的設計大圖整理出來.1.關於決策層的思考 基於運維...
關於新架構的思考
1.對request和session的深層封裝真的有實際意義嗎?2.如果request封裝的真的很厚實,那麼,我們必須要保證的,控制器在完全屏棄request以後,能夠方便獲取request中的物件.方便訪問session中的物件,這點,在分層體系架構的設計上是非常重要的.3.對於bo和持久層,以及...