從前，有一個簡單的通道系統叫尤娜……
從前，有個女生宿舍，住著小A、小B、尤娜和我4個人。有天，小A不小心把小B的床板坐塌了。小B非常生氣，當場和小A翻臉。不論人緣最好的尤娜怎麼中間調解都不管用。一直到畢業，小A和小B再沒有說過一句話。
後來，小A、小B和尤娜都成了公司老闆，只有我一事無成。小A公司需要使用小B公司的系統，小A還記著當年的事情，沒敢直接找小B，就找尤娜商量。尤娜就找到小B訴說原委。有生意小B自然是願意做的，但是想到關係這麼僵了，還是放不下身段。尤娜嘆了口氣：「這樣吧，我們公司做一個系統，你倆都來接我吧。」
於是，尤娜成立了一個以自己名字命名的項目，看著我實在找不到工作，就讓我自學編程，給她做開發。於是尤娜初版就這樣上線了。架構是這樣的：
我還只是個菜鳥，所以我的做法只是把B的http介面包裝了一下，其他什麼也沒有做。上線之後，我發現A的調用請求一天有幾個時間調用量特別大，小B公司的老師說：「扛不住了，不要把流量直接透傳過來呀！」
我通過自己的學習調查，發現可以使用消息中間件做個緩衝。當A請求過來，我先把請求放到消息隊列里，然後再自己消費後轉發請求給B。因為消費是勻速的，就起到了削峰填谷的作用。
但是這樣，我怎麼把返回結果再返回給A呢？聰明如我怎麼會想不到辦法，我把B返回的結果記錄到資料庫中。當A的請求發送到消息中間件後就循環去資料庫里取結果，取到就返回這個結果給A。完美！
於是我跟尤娜商量了這個想法，尤娜是我的好姐妹，我的想法她馬上表示支援，讓我放手去做，資源呀什麼都不是問題。
我按照網上找到的《項目中怎樣做技術選型》的文章，結合目前的特點，優缺點比較之後，消息中間件使用kafka，資料庫使用mysql。經過自己的努力，尤娜第二版上線啦。架構是這樣的：
kafka集群的內部架構，我是參考《Kafka生產端實際項目中的使用分析》這篇文章，使用zookeeper做分散式協調。上線不久後，意想不到的事情發生了：kafka broker集群掛了。不管三七二十一先重啟再說。
重啟之後，尤娜消費端沒有恢復，每隔3ms報一個warn日誌：
Auto offset commit failed for group XXX:
Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member.
This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms,
which typically implies that the poll loop is spending too much time message processing.
我根據auto offset commit failed（自動提交offset失敗了）這個資訊在網上搜索了一下。通過之前的學習我知道：kafka的數據更新消費都是通過在zookeeper中標記一個偏移量（offset）來記錄每個分區的消費位置，所以一旦offset更新失敗，會出現重複消費數據的問題。
最終我分總結出：kafka消費者在處理消息時，在指定時間內（session.time.out）沒有處理完。kafka消費要在消息處理完之後，自己提交當前的offset給kafka集群。而這時候已經超時斷開連接了，導致自動提交offset失敗。因此就會像日誌中所說的發生rebalanced（重平衡即重新分配partition給客戶端），而之前提交的offset已經失敗了，所以重新分配的客戶端又會消費之前的數據，接著consumer重新消費，又出現了消費超時，無限循環下去。
出現這個原因是因為我客戶端使用時就是使用了spring-kafka，只用了一個@KafkaListener，沒有修改任何默認配置。而默認enable.auto.commit設置成true，可以改為false，不採用自動提交方式。所謂不自動提交實際上是消費端收到消息不先處理而是先提交offset再處理。
這種解決方案，萬一提交了offset之後消費失敗了不會再次處理。這樣次數多了向A不好交代呀。還是先不改了。我決定先修改session.time.out時間設置長一些，重啟解決問題。
目前服務已經恢復了正常，作為菜鳥新人解決了問題覺得好激動。但是實際上細想還有好多問題沒有弄明白，比如：kafka broker集群為什麼掛了？太晚了，先睡覺再說。
突然想起那時候在宿舍我們四個一起讀《飄》的情景，特別喜歡裡面那句名言：無論如何，明天又是新的一天！
後記：
