kafka是平常用的比較常見的一種消息隊列。在項目中爲何使用消息隊列呢？
使用消息隊列，有很多好處。
①比如說，系統其實不是所有的操作都必須實時完成了再進行下一步的，那麼用消息隊列，就可以提高系統的負載能力，同一時間可以接受更多的訪問。
②使用消息隊列，可以降低系統的耦合性，比如發短信的事情，可以另外開發，而不需要跟其他業務做到一起。不同的功能，可以分微服務，部署到不同的機器，運維也方便。
③對用戶而言，可以得到實時的響應。比如搶購的時候，用戶一點，就顯示搶到了。（然後，用戶提交訂單的時候，有可能提示商品不夠了，哈哈，很多網站都是這麼做的，也沒什麼毛病。當然這個可能就扯遠了，要儘量讓用戶在秒殺的時候，確實是真實的搶到或者沒搶到，方式很多，但目前我還沒找到100%可靠方案。）
kafka的可靠性在以下幾個方面：
1. 消費者不重複消費
2.消費者消費消息不遺漏
3.生產者不重複發消息
4.生產者發消息不遺漏
5.生產者發消息不亂序
保證消費者不重複消費
可以根據業務指定唯一性的key, 存放到一個地方（數據庫、redis等），推薦redis或者mongodb.每次消費的時候，如果發現已經消費過，則直接跳過。
消費者消息不遺漏
關閉自動提交offset, 消息消費成功後，手動提交offset.
生產者不重複發消息
只要保證消費者不重複消費，少量的重發，其實沒什麼影響。但是如果生產者死循環了，一直髮同樣的消息，也是個麻煩。當然，這種情況，是程序邏輯問題，壓測的時候肯定過不了，也很容易修復。
生產者發消息不遺漏
這個問題比較棘手。我的處理方式是，記錄失敗的消息，然後定時任務批量處理失敗的消息。當然，有時候，失敗也不是真的失敗，也許是消息發了，但是沒有返回成功的值。不過，這個沒關係，因爲消費端已經做了處理，不會重複消費的。
保證生產者消息的順序是正確的
其實，不難發現，解決上一個問題的時候，就可能導致順序亂掉。是否需要保證順序，這個跟業務也是相關的，如果系統剛好無所謂順序，比如廣告的短信晚點發也沒關係，這種情況就不處理。
一般情況討論的亂序，是出現在消息分到不同partition，然後導致的錯亂，可以通過代碼控制，讓需要保證順序的消息發到同一個partition即可。