如何設定partition和consumer的數量
專案中需要用到大量partition和consumer，容易導致高cpu，io，如何優化
出現consumer在commit offset失敗等導致應用不穩定的情況如何應對
這些問題都和應用的消費者相關，對於問題1，常見的消費模型是partition-consumer-thread是一對一的關係，所以partition和consumer數量理論上最好保持一致。大部分的業務其實不需要過度設計partition的數量多少，我之前的專案組中，預設給所有的topic設定4個partition，絕大多數情況都滿足要求。
對於少數業務，資料量很大，所以要增加partition和消費者執行緒數把併發度提上去，如問題2，隨之而來的問題就是，應用服務會產生大量對kafka broker的io請求，而且當資料峰值降下來的時候執行緒並不會閒置，而是不斷輪詢從kafka獲取資料，導致cpu浪費。
從原理上看，consumer需要和broker保持心跳，如果心跳斷開了，就會出現commit offset失敗等不穩定的情況時有發生。單純用kafka的client api調參是很難同時解決這些問題的，下文將從應用程式自定義的的消費者模型出發，聚焦於解決上面提到的問題。
tips:一種簡單的模型是乙個執行緒中執行乙個consumer，應用中consumer的數量和partition的數量保持一致，相信很多開發者都是這麼使用的，消費模型如下：kafka comsumer 在每次poll()函式拉取資料的時候，都會傳送一次心跳請求，具體**在consumercoordinator類的poll()函式中，會有一次pollheartbeat()的函式呼叫。
如果 consumer 長時間不poll()資料就會被broker踢出去，那麼consumer就無法commit offset了。
優勢：
缺點：如果想解決模型1的缺點，可以從partition-consumer-thread是一對一這個特點著手，consumer數量和partition數量其實可以沒有關聯的，而且consumer拉取訊息和訊息處理兩個步驟可以解耦，在不同執行緒中做。
基於上面的思路，可以得到乙個新模型，新模型中包含consumer執行緒和訊息處理執行緒池，consumer執行緒不斷輪詢拉取訊息，並向訊息處理執行緒池中提交任務。模型如下：
上述模型中，消費執行緒的數量可以設定的比partition數量少，並且由於consumer非同步提交任務，所以能夠持續保持和broker的心跳。假設應用的topic有20個partition，應用服務部署在4個物理機，每個物理機上只有乙個consumer，但是每個應用服務上都有5個執行緒處理訊息，就相當於有20個執行緒處理訊息。
優勢：
缺點：模型2解決了模型1中的不足，反而丟掉了模型1中的一些優勢，寫**就是這樣，往往不可兼得。而且引入的問題在模型2中的處理這些問題的難度明顯比模型1要變大了，但是也不是沒有辦法，下面乙個個問題處理。
缺陷1：非同步commit offset 導致訊息丟失
對於非同步commit offset的問題的處理方式，就是不要讓執行緒池中的執行緒各自去commit，而是由乙個執行緒統一commit，我們把這個執行緒稱為commit執行緒。那麼問題就變成了commit執行緒在什麼時機進行commit操作，很明顯，當所有訊息都被處理完的時候就提交一次offset，得到的模型如下：
這個模型中，序列號大的訊息被執行緒池中的執行緒處理完之後寫入到乙個佇列中，只有當序列號0,1,2…n的訊息都被處理完的時候，才將序列號為n的訊息的offset進行提交操作，保證了at most once消費。
缺陷2：同乙個partition中的訊息被處理的時候無序
消費者從某個partition消費到多條訊息的時候，直接提交給了執行緒池處理，所以無法保證訊息處理的順序，我們最先想到的方案就是：
最終形成的消費者模型如下：
一次 kafka 訊息堆積問題排查
收到某業務組的小夥伴發來的反饋，具體問題如下 專案中某 kafka 訊息組消費特別慢，有時候在 kafka manager 控制台看到有些消費者已被踢出消費組。從服務端日誌看到如下資訊 該消費組在短時間內重平衡了 600 多次。從 cat 檢視得知，每條訊息處理都會有 4 次資料庫的互動，經過一番溝...
Kafka 分布式訊息佇列的特點及應用場景
1 速度快 高吞吐量 分布式 多分割槽。2 無需停機即可擴充套件機器。3 通過將資料持久化到硬碟以及replication防止資料丟失。4 支援多消費者 重要特點 5 支援online 實時消費 和offline 離線消費，比如按天消費 的場景。6 依賴zookeeer集群，狀態資訊都寫在zooke...
從Windows訊息的角度看視窗應用程式的執行過程
乙個典型的win32視窗應用程式的框架是這樣的 程式入口點 winmain函式 註冊視窗類 呼叫registerclass函式或registerclas 函式 建立主視窗 呼叫createwindow函式或createwindowex函式 顯示主視窗 呼叫showwindow函式 更新主視窗 呼叫u...