flink ha zk集羣遷移實踐

flink爲了保證線上做業的可用性，提供了ha機制，若是發現線上做業失敗，則經過ha中存儲的信息來實現做業的從新拉起。

咱們在flink的線上環境使用了zk爲flink的ha提供服務，但在初期，因爲資源緊張，只是對zk進行了standalone的部署，可是在後期的使用中，發現單節點的集羣很難提供很高的可用性，

因此就嘗試將目前的standalone的zk服務擴展爲cluster的zk服務，這其中，也踩了很多坑。

第一次嘗試，將standalone的zk擴展爲cluster

擴展爲cluster很簡單，找了兩臺集羣，部署了zk服務，而後將三臺節點的zk的zoo.cfg同步了下，而後重啓每一個zk服務。

結果失敗了，線上的做業都死掉了。

這裏的坑在於重啓以後，zk的信息都丟掉了，成了一個空集羣，已經在線上跑的做業拿不到相應的信息，就死掉了。

第二次嘗試，將standalone的zk擴展爲cluster

第一次之因此信息都丟了，是由於最初的那個standalone的機器，並無一開始就重啓，反而是放到最後重啓了，致使他從別人往本身同步信息，本身的信息都丟了。

因此此次，前面仍是同樣的套路，可是zoo.cfg同步以後，先重啓以前standalone的節點，以後重啓其餘兩個節點。

完美，此次信息沒有發生丟失，相應的數據都在。

結果做業仍是掛了，爲啥？由於重啓zk的節奏太慢，信息雖然都在，可是zk不可用的時間太長。

而後又試了一次，此次加快節奏，別拖泥帶水。

信息沒有丟失，做業沒有失敗，可是做業重啓了，由於雖然重啓各個zk很快，但也要20s左右的時間，這個時間以及超過zk與客戶端維護心跳的時間了。但萬幸做業沒有掛掉。

可是商量以後以爲，線上那麼多做業，若是都restart一次，仍是不太好。因此最終決定仍是搭新集羣，之前的做業走老集羣，新提的做業走新集羣，維護兩個集羣，直到沒有人使用老集羣，麻煩，可是對用戶友好。

第三次嘗試，組建徹底新的zk集羣

這個就很好弄了，先搭了個5個節點的zk集羣，而後測試了下做業提交，沒有問題，完美。

結果沒幾分鐘就被打臉，用戶反映以前的做業無法下線。

好吧，這個場景沒考慮到。由於用戶下線做業的時候，其實也須要到zk中去獲取線上dispatcher的地址，可是新集羣是不包含以前應用的信息啊。

沒辦法，只能同步zk信息了，好在在github上找到一個zkMove的項目，測了下，能夠用，就趕忙同步了下相應的信息。

教訓，其實能夠在一開始就經過離線同步zk信息的方式來組建新的zk集羣，這樣就不會發生相似的事情了。

第四次嘗試，複用yarn的zk集羣

由於資源限制，上面搭的集羣都在yarn的zk集羣上，可是啓用了2183端口。運維同窗不幹了，他們監控zk只監控2183接口。

因此最終仍是複用yarn的zk集羣，那麼就又得找個夜深人靜的時候去同步zk信息了。

 

其實最大的教訓在於，一開始就應該將zk搞成cluster模式，哪怕是僞集羣，即在一個節點上的集羣，這樣後期要擴容或者縮容，都會方便不少。