背景
線上 flink 用戶使用 ZooKeeper 做元數據中心以及集羣選主，一些版本的 flink 在 ZooKeeper 選主時，會重啓 Job，導致一些非預期的業務損失。而 ZooKeeper 在 zxid溢出時，會主動觸發一次選主，就會導致 flink Job 的非預期重啓，造成業務損失。本篇從原理和最佳實踐上分析和解決由於 ZooKeeper zxid 溢出導致的集羣選主問題。檢查 ZooKeeper Server 日誌出現。
zxid lower 32 bits have rolled over, forcing re-election, and therefore new epoch start
解決方法
ZooKeeper 本身提供當前處理的最大的 Zxid，通過 stat 接口可查看到當前處理的最大的 zxid 的值，通過此值可以計算當前 zxid 距離溢出值還有多少差距。MSE 提供風險管理以及集羣選主相關告警，提前預防和及時感知選主風險，避免業務損失。
通過 MSE ZooKeeper 風險管理和集羣選主時間告警，預知風險。
MSE ZooKeepr 提供風險管理的能力，風險管理會定期掃描集羣風險，通知用戶，zxid 溢出就是集羣的風險之一，當 zxid 接近溢出值之前，通過風險管理對風險的掃描，就可以看到集羣zxid溢出的風險，提前做好規避。
風險管理會每天掃描集羣的各項風險，也可以通過手動觸發 一鍵健康檢查進行集羣風險診斷。
同時通過 MSE ZooKeeper 的集羣選主時間告警，可以檢測集羣的選主時間，避免因爲集羣選主時間過長導致業務損失。通過告警管理中創建 MSE 告警規則進行集羣選主時間的告警設置。
原因分析
什麼是zxid，它是怎麼產生的？
首先我們瞭解一下什麼是 zxid，它是怎麼產生的：zxid 是 ZooKeeper 中一個事務的全局唯一 id，通過 zxid 描述各個事務之間的全序關係。客戶端對 ZooKeeper 內部數據的變更都是通過事務在 ZooKeeper 集羣內的傳播和處理完成的，因此 zxid 就是客戶端對數據進行一次變更所產生的事務在全局事務中的一個唯一 id，這個 id 描述了本次變更的事務在全局事務中的位置，並且不會有兩個不同的事務擁有相同的 zxid（全序關係）。
zxid 是一個 64bits 的數，有兩個部分組成：當前選舉週期（epoch，佔用高32bits）以及計數部分（counter，佔用低32bits），epoch 表示 leader 關係的變化，每當新的集羣產生新的leader，都會產生一個新的 epoch表示當前 leader 的選舉週期，ZooKeeper 集羣選主成功之後保證只會有一個Leader，並且此 Leader 的 epoch 是以前沒有使用過的，這就保證了只會有一個 leader 使用本次選舉過程中產生的 epoch， 在此基礎上，每當客戶端對數據進行變更的時候，leader 對產生的事務在當前 counter 的值加一產生新的事務的 zxid，並使用此 zxid 將此事務在集羣中進行同步，這樣就保證了事務的全序關係。
爲什麼 zxid 溢出需要重新選主
通過研究 zxid 的組成，可以發現，當單個 epoch 中處理的事務過多，以至於當前epoch 對應的 counter 數值超過了 32bits 計數的最大值，如果繼續計數 epoch 就會 +1 ， 如果在未來，進行了一次選舉，其他的 Server 當選了 leader，但是他產生的新 epoch 可能就會和現在 zxid 中的 epoch 重合，導致不同的事務會有相同的 zxid，破壞了事務之間的全序關係，可能導致髒數據的產生。因此 ZooKeeper 在低 32 位達到最大計數值的時候，就會主動產生一次選主，避免以上問題。
ZooKeeper 集羣選主會產生什麼影響
一般情況下使用 ZooKeeper 作爲註冊配置中心，集羣選主對於客戶端來說是無感知的，集羣選主之後客戶端會主動重連恢復，但是對於依賴於 ZooKeeper Disconnected 事件的應用，可能會受到影響，在集羣選主的時候，Server會向客戶端返回 Disconnected 事件，例如 Curator recipes 中 LeaderLatch 類型，在 ZooKeeper 集羣選主的時候，LeaderLatch 會重新分配 Leader。
作者：子葵
本文爲阿里雲原創內容，未經允許不得轉載。