順序消息
kafka想要保證消息順序，是需要犧牲一定性能的，方法就是一個消費者，消費一個分區，可以保證消費的順序性。但也僅限於消費端消費消息的有序性，無法保證生產者發送消息有序。
比如：如果發送端配置了重試機制，kafka不會等之前那條消息完全發送成功才去發送下一條消息，這樣可能會出現，發送了1，2，3條消息，第一條超時了，后面兩條發送成功，再重試發送第1條消息，這時消息在broker端的順序就是2，3，1了。發送端消息發送已經亂序，到了消費端消費時，自然無法保證順序！
如果一定要保證生產-消費全鏈路消息有序，發送端需要同步發送，ack回調不能設置為0。且只能有一個分區，一個消費者進行消費，但這樣明顯有悖於kafka的高性能理論！
問題：如何在多個分區中保證消息順序和消息處理效率呢？
首先使用多個分區，消息可以被發送端發送至多個分區，保證消息發送的效率。然后在消費端在拉消息時使用ConutdownLunch來記錄一組有序消息的個數。如果達到個數，說明已拉取到完整的一組有序消息。然后在消費端根據消息序號進行排序，消費端將排好序的消息發到內存隊列(可以搞多個)，一個內存隊列開啟一個線程順序處理消息。即可最大程度上既保證順序又保證效率！
消息積壓
線上有時因為發送方發送消息速度過快，或者消費方處理消息過慢，可能會導致broker積壓大量未消費消息。
解決方案：此種情況如果積壓了上百萬未消費消息需要緊急處理，可以修改消費端程序，讓其將收到的消息快速轉發到其他topic(可以設置很多分區)，然后再啟動多個消費者同時消費新主題的不同分區。如圖所示：
由於消息數據格式變動或消費者程序有bug，導致消費者一直消費不成功，也可能導致broker積壓大量未消費消息。
解決方案：此種情況可以將這些消費不成功的消息轉發到其它隊列里去(類似死信隊列)，后面再慢慢分析死信隊列里的消息處理問題。這個死信隊列，kafka並沒有提供，需要整合第三方插件！
消息回溯
如果某段時間對已消費消息計算的結果覺得有問題，可能是由於程序bug導致的計算錯誤，當程序bug修復后，這時可能需要對之前已消費的消息重新消費，可以指定從多久之前的消息回溯消費，這種可以用consumer的offsetsForTimes、seek等方法指定從某個offset偏移的消息開始消費，完成消息的回溯消費！
kafka高性能的原因
-
分布式存儲架構
-
磁盤順序讀寫
kafka消息不能修改以及不會從文件中間刪除保證了磁盤順序讀，kafka的消息寫入文件都是追加在文件末尾，不會寫入文件中的某個位置(隨機寫)保證了磁盤順序寫。 -
讀寫數據的批量batch處理以及壓縮傳輸
-
數據傳輸的零拷貝
