kafka快的原因：
1、partition順序讀寫，會先寫入頁快取，再寫入磁碟，充分利用磁碟特性，這是基礎；
2、producer生產的資料持久化到broker，採用mmap檔案對映，實現順序的快速寫入；
3、頁快取技術在讀取時可以實現零拷貝，減少io，加快socket傳輸速度
4、customer從broker讀取資料，向broke提供topic、partition、offset，找到分割槽index和log檔案，通過二分查詢定位資料，採用sendfile，將磁碟檔案讀到os核心緩衝區後，直接轉到socket buffer進行網路傳送。
kafka配置需求：
磁碟 > jvm記憶體
jvm一般5g左右足夠了
consumer_group提交記錄定位：
kafka 預設topic __consumer_offsets下的分割槽對應的是math.abs("$".hashcode()) % 50
記錄著你這個消費組的offset
看到__consumer_offsets topic的每一日誌項的格式都是：[group, topic, partition]::[offsetmetadata[offset, metadata], committime, expirationtime]
kafka安全的&高可靠配置：
參考：kafka各場景測試總結：
- 當acks=-1時，kafka傳送端的tps受限於topic的副本數量（isr中），副本越多tps越低；
- acks=0時，tps最高，其次為1，最差為-1，即tps：acks_0 > acks_1 > ack_-1；
- min.insync.replicas引數不影響tps；
- partition的不同會影響tps，隨著partition的個數的增長tps會有所增長，但並不是一直成正比關係，到達一定臨界值時，partition數量的增加反而會使tps略微降低；
- retries不為0時，在broker發生異常後，可能會存在訊息重複落盤的情況
其他文獻：
專案實踐經驗總結 （1）
media screen and min width 768px media screen and min width 992px media screen and min width 1200 注意下順序，如果你把 media min width 768px 寫在了下面那麼很悲劇，media sc...
WTL實踐經驗總結 不斷更新
一.wtl的使用 二.wtl的結構 三.wtl的剖析 四.wtl的資源 五.wtl的專案 我自己寫的哦 選擇wtl很大部分原因都是因為對模板的迷戀，不知為啥，c 的魅力盡然在模板！好，開始我們的征程吧。一 wtl的使用 1.安裝 網上已經很多這樣的文章了，看這裡，這裡 2.幫助外掛程式 visual...
快速排序實踐經驗總結 弄透其邏輯
快速排序的思想其實比較好理解，但是實際碼 的時候，會遇到一些問題，並不是想象的那麼簡單。在網上看了一下，感覺大多數的部落格介紹其排序原理的時候說得很生動形象，但給出的實現 其實邏輯說得不是很清晰，甚至是錯誤的。這裡我自己寫了一下快速排序，過程中也遇到了一些問題，但總算是解決了。這裡給出來，並詳細說一...