isr（in-sync replica） 就是 kafka 為某個分割槽維護的一組同步集合，即每個分割槽都有自己的乙個 isr 集合，處於 isr 集合中的副本，意味著 follower 副本與 leader 副本保持同步狀態，只有處於 isr 集合中的副本才有資格被選舉為 leader。一條 kafka 訊息，只有被 isr 中的副本都接收到，才被視為「已同步」狀態。這跟 zk 的同步機制不一樣，zk 只需要超過半數節點寫入，就可被視為已寫入成功。
follwer 副本與 leader 副本之間的資料同步流程如下：
這也就意味著，leader 副本永遠領先 follower 副本，且各個 follower 副本之間的訊息最新位移也不盡相同，kafka 必須要定義乙個落後 leader 副本位移的範圍，使得處於這個範圍之內的 follower 副本被認為與 leader 副本是處於同步狀態的，即處於 isr 集合中。
（1）0.9.0.0 版本之前的設計
0.9.0.0 版本之前判斷副本之間是否同步，主要是靠引數 replica.lag.max.messages 決定的，即允許 follower 副本落後 leader 副本的訊息數量，超過這個數量後，follower 會被踢出 isr。
replica.lag.max.messages 也很難在生產上給出乙個合理值，如果給的小，會導致 follower 頻繁被踢出 isr，如果給的大，broker 發生宕機導致 leader 變更時，肯能會發生日誌截斷，導致訊息嚴重丟失的問題。
可能你會問，給個適中的值不就行了嗎？關鍵在這裡，怎樣才是適中？如何界定？
假設現在某個 kafka 集群追求高吞吐量，那生產者的 batch.size 就會設定得很大，每次傳送包含的訊息量很多，使訊息傳送的吞吐量大大提高，如果此時 min.insync.replicas=1，從上圖可看出，生產者傳送訊息儲存到 leader 副本後就會響應成功，表示許諾使用者儲存到至少乙個副本的要求已經達到，訊息已經成功傳送。那問題來了，由於 follower 副本同步 leader 副本的訊息是不斷地傳送 fetch 請求，此時如果 leader 一下子接收到很多訊息，就會導致 leader 副本與 follower 副本的訊息數量相差很大，如果此時這個差數大於 replica.lag.max.messages 的值，follower 副本就會被踢出 isr，因此，該集群需要把 replica.lag.max.messages 的值設定成很大才能夠避免 follower 副本頻繁被踢出 isr。
所以說，replica.lag.max.messages 的設計是有缺陷的，當生產者傳送訊息量很大時，該值也需要相應調大，但就會造成訊息嚴重丟失的風險。
有沒有更好的解決方案？
（2）0.9.0.0 版本之後的設計
在 0.9.0.0 版本之後，kafka 給出了乙個更好的解決方案，去除了 replica.lag.max.messages，，用 replica.lag.time.max.ms 引數來代替，該引數的意思指的是允許 follower 副本不同步訊息的最大時間值，即只要在 replica.lag.time.max.ms 時間內 follower 有同步訊息，即認為該 follower 處於 isr 中，這就很好地避免了在某個瞬間生產者一下子傳送大量訊息到 leader 副本導致該分割槽 isr 頻繁收縮與擴張的問題了。
近期熱文
Kafka副本同步機制
kafka中topic的每個partition有乙個預寫式日誌檔案，每個partition都由一系列有序的 不可變的訊息組成，這些訊息被連續的追加到partition中，partition中的每個訊息都有乙個連續的序列號叫做offset，確定他在partition中的唯一位置。kafka每個topi...
Kafka副本同步機制
引用自 kafka中主題的每個partition有乙個預寫式日誌檔案，每個partition都由一系列有序的 不可變的訊息組成，這些訊息被連續的追加到partition中，partition中的每個訊息都有乙個連續的序列號叫做offset,確定它在分割槽日誌中唯一的位置 kafka的每個topic的...
linux同步機制
一.併發控制 1 自旋鎖 得不到資源，會原地打轉，直到獲得資源為止 定義自旋鎖 spinlock t spin 初始化自旋鎖 spin lock init lock 獲得自旋鎖 spin lock lock 獲得自旋鎖，如果能立即獲得，則馬上返回，否則自旋在那裡，直到該自旋鎖的保持者釋放 spin ...