twitter，他們使用複製日誌來解決分布式系統中存在的一系列問題。比如，他們有乙個manhattan分布式鍵值資料庫。該系統採用了一種靈活的最終一致性資料模型，允許開發者以一致性換取低延遲。寫入操作會單獨應用到資料集的所有副本，manhattan會保證各個副本的資料最終一致。但是，應用程式在查詢乙個剛剛更新過的資料集時可能會因為讀取的副本不同而獲取到不同的資料。為了防止這種不一致的情況，他們必須針對每個副本以同樣的順序應用所有更新。日誌（乙個嚴格有序的操作記錄）是實現序列化更新的一種簡單方式。在twitter，還有其它有類似情況的應用程式需要某種日誌服務基礎設施。於是，他們構建了distributedlog，乙個高效能的「複製日誌（replicated log）」服務。近日，twitter訊息團隊高階軟體工程師leigh stewart撰文分享了他們構建該服務的經驗。
他們根據自己構建分布式系統的經驗，對複製日誌服務提出了如下要求：
可靠性：穩定，而且在出現各種常見問題（網路劃分、集群拓撲變化、流量峰值等）時都能提供可以預見的效能；
高吞吐量：在高峰時段可以支援每秒數以百萬計的訊息傳遞；
低延遲：始終如一的低延遲；
工作負載隔離：在乙個以日誌為中心的分布式系統中，工作負載可以分為如下三類：寫日誌尾、讀日誌尾和「追趕讀（catch-up read）」。各類負載互不影響；
可操作性：在擴充套件時易於操作，比如可以很容易地增加或移除節點；
簡單：介面簡單，便於開發人員使用。
為了滿足上述需求，他們評估了幾種可選方案，其中包括：（一）使用類似kafka的發布/訂閱系統；（二）使用類似paxos或raft的一致性演算法構建新的服務或庫；（三）使用一種像apache bookkeeper那樣的底層日誌服務。對於kafka，他們對其i/o模型心存疑慮，並認為它缺乏強有力的穩定性保證；paxos和raft頗具吸引力，但從頭構建乙個新系統需要乙個很長的開發周期。於是，選項僅剩了apache bookkeeper。這個最初為hdfs設計的事務日誌後台唯一關注的是儲存效率和日誌段（稱為ledger）檢索。另外，不同於kafka，它並不關注發布/訂閱系統中的一些高階特性，如「分割槽歸屬（partition ownership）」、面向流的抽象等。以下是apache bookkeeper的核心優勢：
因此，他們認定，bookkeeper是乙個日誌儲存的上佳選擇。不過，它雖然滿足了上面列出的大部分關鍵需求，但是還缺少一些關鍵的特性，比如高階抽象、日誌歸屬等。為此，他們在bookkeeper之上構建了乙個服務層distributedlog，提供一種可以滿足上述需求的、端到端的服務，如下圖所示：
bookkeeper提供穩定性和高可用的日誌段儲存；distributedlog提供簡單的抽象，如命名、資料分割、保留策略等；應用程式層負責分割槽、路由、偏移量管理等高階特性。其中，distributedlog具有如下特性：
在過去的兩年裡，distributedlog解決了許多分布式系統中頗具挑戰性的問題，其本身也在發展。事實證明，基於distributedlog的一致性寫入路徑非常可靠，而且效能令人稱讚。將distributedlog引入manhattan的寫入路徑平均僅僅增加了10毫秒的寫入延遲。
如何構建高效能MySQL索引
本文的重點在於如何構建乙個高效能的mysql索引，從中你可以學到如何分析乙個索引是不是好索引，以及如何構建乙個好的索引。乙個索引的常見誤區是為每一列建立乙個索引，如下面建立的索引 create table t c1 varchar 50 default null,c2 varchar 50 defa...
如何構建高效能MySQL索引
本文的重點在於如何構建乙個高效能的mysql索引，從中你可以學到如何分析乙個索引是不是好索引，以及如何構建乙個好的索引。乙個索引的常見誤區是為每一列建立乙個索引，如下面建立的索引 t表裡有三列，並且為每列建立了乙個索引。建立索引的人為了能夠快速訪問表中的任何一列，因此為每一列新增了乙個單獨的索引。在...
如何構建高效能MySQL索引
乙個索引的常見誤區是為每一列建立乙個索引，如下面建立的索引 create table t c1 varchar 50 default null,c2 varchar 50 default null,c3 varchar 50 default null,key c1 c1 key c2 c2 key ...