資料輔助與failover
cap理論（它具有一致性、可用性、分割槽容忍性）
cap理論：分布式系統中，一致性、可用性、分割槽容忍性最多隻可同時滿足兩個。一般分割槽容忍性都要求有保障，因此很多時候在可用性與一致性之間做權衡。
一致性方案
1.master-sl**e
》rdbms的讀寫分離即為典型的master-sl**e方案
》同步複製可保證強一致性但會影響可用性(等master確保將資料複製給全部的sl**e，sl**e才返回結果)
》非同步複製可提供高可用性但會降低一致性
2.wnr
》主要用於去中心化（p2p）的分布式系統，dynamedb與cassandra即採用此方案
》n代表副本數，w代表每次寫操作要保證的最少寫成功的副本數，r代表每次讀至少讀取的副本數
》當w+r>n時，可保證每次讀取的資料至少有乙個副本具有最新的更新
》多個寫操作的順序難以保證，可能導致多副本間的寫操作順序不一致，dynamo通過向量時鐘保證最終一致性
3.paxos及其變種
》google的chubby，zookeeper的zab，raft等
kafka是如何權衡ca的呢？
如：當乙個patiton副本數超過broker時，就會報錯
data replication要解決的問題
1.如何propagate（擴散）訊息
2.何時commit
3.如何處理replica恢復
4.如何處理replica全部宕機
1.如何propagate（擴散）訊息
以寫入資料為例，patiton分為leader和follower，follower週期性的向leader pull資料（和consumer相似）。
在讀取資料時，與資料庫讀寫分離不一樣，follower並不參與讀取操作，讀取只和leader有關。
為了提高效能，每個follower在接收到資料後就立馬向leader傳送ack，而非等到資料寫入log中。因此，對於已經commit的訊息，kafka只能保證它被存於多個replica的記憶體中，而不能保證它們被持久化到磁碟中，也就不能完全保證異常發生後該條訊息一定能被consumer消費。但考慮到這種場景非常少見，可以認為這種方式在效能和資料持久化上做了乙個比較好的平衡。在將來的版本中，kafka會考慮提供更高的永續性。
2.何時commit
由上圖可知，leader資料傳送給follower既不是同步通訊也不是非同步通訊，而是在一致性和可用性做了動態的平衡
3.如何處理replica恢復
4.如何處理replica全部宕機
等待isr中任一replica恢復，並選它為leader
》等待時間較長，降低可用性
》或isr中的所有replica都無法恢復或者資料丟失，則該patition將永不可用
選擇第乙個恢復的replica為新的leader，無論它是否在isr中
》可能會有資料丟失
》可用性較高
kafka和zookeeper的日誌資料流分析
kafka和zookeeper的日誌資料流分析 活動流資料是所有站點在對其 使用情況做報表時要用到的資料中最常規的部分。活動資料報括頁面訪問量 page view 被檢視內容方面的資訊以及搜尋情況等內容。這種資料通常的處理方式是先把各種活動以日誌的形式寫入某種檔案，然後周期性地對這些檔案進行統計分析...
Kafka 資料遷移
當kafka 減少broker節點後，需要把資料分割槽遷移到其他節點上，以下將介紹我的一次遷移驗證過程。前3步為環境準備，實際資料操作看第4步即可 增加broker節點，也可以採用步驟4相同的方法進行重新分割槽 方案思想 使用kafka reassign partitions命令，把partitio...
Kafka 資料遷移
當kafka 減少broker節點後，需要把資料分割槽遷移到其他節點上，以下將介紹我的一次遷移驗證過程。前3步為環境準備，實際資料操作看第4步即可 增加broker節點，也可以採用步驟4相同的方法進行重新分割槽 方案思想 使用kafka reassign partitions命令，把partitio...