kafka product新舊對比，新版本的優勢
1.划分到兩個不同的線程：用戶主線程和Sender I/O線程，邏輯更容易把握。
2.完全是異步發送消息，並提供回調機制用於判斷發送成功與否。
3.分批次，每批次中包含多個發送請求，提升整體吞吐量。
4.更加合理的分區策略：對於沒有指定key的消息而言，舊版本producer分區政策是默認在一段時間內將消息發送到固定分區，這樣容易造成數據傾斜；
新版本采用輪詢的方式，消息發送將更加均勻化。
5.底層統一使用基於java Selector的網絡客戶端，結合java的Future實現更加健壯和優雅的生命周期管理。
kafka consumer 新舊版本對比
1.單線程設計--單個consumer線程可以管理對個分區的消費Socker連接，極大地簡化了實現。0.10.1.0版本額外引入一個后台心跳線程，不過雙線程設計依然比舊版本consumer的
多線程設計要簡單的多。
2.位移提交與保存由kafka來處理，不在保存在zookeeper中，而是單獨保存在Kafka的一個內部topic中，避免了zookeeper頻繁讀寫的性能瓶頸，
同時也依托Kafka的備份機制天然實現位移的高可用管理。
3.消費者組的集中式管理，原來由zookeeper來管理位移，還要負責管理整個消費者組成員。新版本改進了設計，實現了一個集中式協調者的角色。現在都交給該角色管理，
對於group的管理更加可控。
kafka在window和linux的區別
1.kafka新版本clients在設計底層網絡庫采用java的Selector機制，而在linux上的實現機制就是epoll；但是在windows平台商，java NIO的Selector
底層使用select模型而非IOCP實現的，只有javaNIO2才是使用IOCP實現的。因此在linux上部署kafka要比在windows上部署能夠得到更高效的I/O處理性能。
2.linux網絡傳輸優勢。底層采用sendfile系統調用，即linux提供的零拷貝技術。windows提供函數TransmitFile來支持零拷貝，在java 8u60版本才
支持FileChannel的transferTO方法調用該函數。
3.epoll比select模型高級。epoll取消輪訓機制，使用的是回調機制。當底層連接socket較多時，可以避免很多無意義的CPU時間浪費。IOCP模型是異步I/O模型，
但由於其系統局限性，並沒有廣泛應用。
