協同編輯的三個問題是convergence, causal order and intention preservation.其中operational transformation演算法解決的主要是intention preservation的問題，但是，僅僅將ot演算法做對，還遠遠不能完成一款協同編輯產品。
多人協同編輯時，必須支援客戶端之間互相傳送和接收編輯操作的訊息。無論使用長連線還是websocket等技術，都需要考慮在通訊協議層面能否支援訊息的順序性。即，客戶端接收的訊息的順序能否保證與傳送時一致。並且，這裡需要澄清，客戶端的訊息傳遞的順序性跟後台系統的訊息中介軟體的順序性是兩件事情。訊息中介軟體的順序性是保證訊息中介軟體的消費者接收訊息的順序性，與客戶端的通訊協議的順序性是保證客戶端接收到的訊息的順序性。
考慮任意一條操作的訊息傳遞路徑如下：訊息被後台通訊服務收到後先經過ot服務轉換，再經過db服務持久化，最終作為ack經通訊服務廣播給相關的客戶端，相關的客戶端就可以看到對方協同編輯的動作。
若定義一條訊息從客戶端發出到被其他相關客戶端接收到的時間間隔為協同編輯的延遲，則協同編輯產品的可用性與延遲反相關。分析訊息的處理的全過程，ot服務是cpu-bound的，db服務是io-bound，必然瓶頸在於db服務。
以上是從單條操作的處理流程分析。對於ot演算法而言，它要求對於單個檔案的所有操作序列處理，所以後台負載的並行化最小粒度是檔案級別。大規模使用者使用產品編輯的不同檔案數目越多，併發度就會越高。同時，對於多租戶系統的角度而言，系統需要保證各個不同檔案的操作盡量隔離，避免某個檔案的操作阻塞其他檔案的操作。
那麼，能否對延遲進一步優化呢？公司的實踐如下圖：
在單條訊息的處理流程中引入bypass（紅色箭頭）。既然db服務的處理耗時，那麼可以bypass這個流程，提前將ot服務處理完成的訊息廣播出去。蕩然，最終作為ack的訊息還是會廣播出去，以應對可能出現的exception(ack可以提供訊息最終執行結果或出錯的相關資訊)。
從單條操作的角度看，實踐中引入了bypass。從訊息驅動的模型出發，這種優化方案實際上是將單條訊息流拆分成兩個非同步的流。
待ot的訊息流的throughput必然會高於待寫入的訊息流，在實踐中需要有足夠的儲存空間去buffer兩個流之間的流量差。這個結構也可以生動的體現eventually-consistency的概念，即當第二個流drained-out後，資料庫中的資料才會跟客戶端的資料一致。
同時，該優化對ot演算法，以及操作的設計提出了更高的要求。因為客戶端會在本地對收到的訊息做ot,而引入bypass後，客戶端ot的必然是bypass過來的訊息，而不是經資料庫處理後的訊息，如此，就依賴於bypass的訊息中必須包含有支援ot的所有資訊。操作設計時，一定要滿足這個條件。
關於實時協同編輯的架構思考
協同編輯是指多人同時對同乙份文件進行編輯。但是這三個問題會形成乙個不可能三角 即任意方案只能滿足其中2個點，犧牲第3個點。有的同學可能對這個三角形不是很理解。我們可以這樣類別，將協同編輯的文件模擬為分布式資料庫，編輯者類別為資料庫的讀寫服務，那麼我們的這個三角形就可以轉換為cap不可能三角 關於ca...
推薦演算法 基於物品的協同過濾演算法
itemcf itemcollaborationfilter，基於物品的協同過濾 比如，使用者a之前買過 資料探勘導論 該演算法會根據此行為給你推薦 機器學習 但是itemcf演算法並不利用物品的內容屬性計算物品之間的相似度，它主要通過分析使用者的行為記錄計算物品之間的相似度。該演算法認為，物品a和...
推薦演算法 基於物品的協同過濾演算法
itemcf itemcollaborationfilter，基於物品的協同過濾 比如，使用者a之前買過 資料探勘導論 該演算法會根據此行為給你推薦 機器學習 但是itemcf演算法並不利用物品的內容屬性計算物品之間的相似度，它主要通過分析使用者的行為記錄計算物品之間的相似度。該演算法認為，物品a和...