文章主要介紹以docker容器的方式部署kafka集群。
上述配置文件中的server.x，數字x對應到data/myid文件中的值。三臺機器x的值分別就是1,2,3。參數詳細說明請參考 官網文檔 。
1.--買粉絲=host: 容器與主機共享同一Network Namespace，即容器與網絡看到的是相同的網絡視圖（host模式存在一定的風險，對安全要求很高的生產環境最好不要用host模式，應考慮除此之外的其他幾種模式）
2.-v: 指定主機到容器的目錄映射關系
這樣就以容器的方式啟動了zookeeper的服務，可以通過 "docker exec -it zookeeper bash" 命令進入容器中進行一些操作，例如查看服務啟動是否正常。也可以通過查看2181端口是否被監聽判斷zookeeper的服務是否運行
詳細的參數配置說明請參考 官方文檔 ，參數不僅可以通過上述文件的方式來配置，也可以通過容器環境變量的方式來配置，這里結合兩種方式使用。
1.KAFKA_ADVERTISED_HOST_NAME、KAFKA_BROKER_ID的值要結合每臺機器自身設置
2./etc/hosts文件中最好配置ip與hostname的映射關系，否則會報出如下錯誤" Error: Exception thrown by the agent : java.買粉絲.MalformedURLException: Local host name unknown: java.買粉絲.UnknownHostException: node0: node0: System error "
3.通過-e 指定的環境變量與在server.properties中配置的選項其效果是一樣的
4.配置文件中的選項若要通過環境變量來指定，方式為：如broker.id對應KAFKA_BROKER_ID，類似的log.dirs對應KAFKA_LOG_DIRS
5.KAFKA_HEAP_OPTS="-Xmx6G -Xms6G"指java堆內存大小的設置，6G大小是kafka官網給出的數值，此數值要結合機器的內存大小給出。超過6G的內存，可以設置為6G；若機器的內存低于6G而設置6G，則會報錯。
5.啟動成功后，可以通過"docker logs kafka"命令查看日志
1.ZK_HOSTS：ZooKeeper訪問地址（需指定機器的ip，localhost:2181或127.0.0.1:2181均會報 "java.買粉絲.ConnectException: Connection refused" 異常）
生產者向broker發送消息，消費者接收消息，broker是物理概念，部署幾個kafka即幾個broker，topic是邏輯概念，往topic里發送消息會發送到設置好的幾個partion上,每個partion存儲作為不同隊列存儲不同數據，partion有leader和follower備份機制，消息發送時會輪循發送到不同broker的不同partion中，同一消費者只能消費同一分區，通過offset記錄消費位置，消費者組可以訪問一個topic的不同partion
啟動鏡像
啟動kafka可以帶上參數，這樣會自動修改kafka里的配置文件（/opt/kafka_版本/買粉絲nf/server.properties）,否則不帶參數需要自己進入進行手動修改 帶參數版啟動可參考
其中172.17.0.3需要改成自己docker的網橋連接地址
查看已啟動容器
查看所有容器
啟動未啟動的容器
進入kafka容器
創建主題
主題和分區可以理解為：topic是邏輯劃分，kafka通過topic進行區分消息，topic的數據會被存儲到日志中，如果數據量太大可以引入partion（同時提高讀寫吞吐量）來分段存儲數據。其中replication-factor作用是將任意分區復制到broker上，broker是物理概念，部署了一個kafka可認為broker數為1，我本機只有一個kafka所以這里replication-factor超過1會報錯。 綜上幾個概念可以理解為：集群中有多個broker，創建主題時可以指明topic有多個partitions(消息拆分到不同分區進行存儲，一個partion只能被一個消費者消費--partion內部保證接收數據順序)，可以為分區創建多個副本replication，不同副本在不同的broker中（作為備份使用，這里有leader和flower的區分） 。
查看topic信息
集群部署
可以通過買粉絲pose集群化部署過es，這里通過創建另一個買粉絲pose.yml文件來部署kafka，配置文件參考 docker-買粉絲pose集群部署
生產者：
消費者：
方式一：從當前主題的遷移量位置+1開始取數據
方式二：從當前主題第一條消息開始消費
生產者將消息發送broker，broker將消息保存到本地日志中，消息的保存時有序的
單播消息：
當存在一個生產者，一個消費者組的時候，一個消費者組中只有一個消費者會收到消息
多播消息：
當存在一個生產者，多個消費組，不同消費組只有一個消費者收到消息
查看消費組詳細信息：
CURRENT-OFFSET:最后被消費的偏移量
LOG-END-OFFSET：消息總量（最后一條消息的偏移量）
LAG ：積壓了多少條消息
常見問題：
1、如何防止消息丟失
生產者：使用同步消息發送；ack設置為1/all;設置同步分區數>=2
消費者：把自動提交改成手動提交
2、如何防止消息的重復消費
針對網絡抖動導致的生產者重試（發送消息），可以設置消費者加鎖解決；
3、消息積壓
消費者使用多線程異步處理接收數據；創建多個消費者組部署到其他機器上；通過業務架構設計，提升業務層面消費性能。
ps:
緩沖區：kafka默認會創建一個消息緩沖區去存放要發送的消息，大小是32M，每次本地線程會去緩沖區拉16K數據發送到broker，如果不到16K等待10ms也會將數據發送到broker
參考鏈接：
1、kafka安裝教程--推薦
2、kafka配置文件server.properties參數說明
3、創建主題分區數
4、解決docker容器啟動不了的問題
5、通過docker-買粉絲pose集群部署
6、學習視頻
可部署性先說明下，這里探討的是Yarn或者Mesos集群的部署，不涉其上的應用
Yarn除了依賴JDK，對操作系統沒有任何依賴，基本上放上去就能跑
Mesos因為是C/C++開發的，安裝部署可能會有庫依賴
這點我不知道大家是否看的重，反正我是看的相當重的
軟件就應該是下下來就可以Run
所以12年的時候我就自己開發了一套Java服務框架，開發完之后運行個main方法就行
讓應用包含容器，而不是要把應用丟到Tomcat這些容器，太復雜，不符合直覺
二次開發Yarn對Java/Scala工程師而言，只是個Jar包，類似索引開發包Lucene，你可以把它引入項目，做任何你想要的包裝
這是其一
其二，Yarn提供了非常多的擴展接口，很多實現都是可插拔
可替換的，在XML配置下，可以很方便的用你的實現替換掉原來的實現，沒有太大的侵入性，所以就算是未來Yarn升級，也不會有太大問題
相比較而言，Mesos更像是一個已經做好的產品，部署了可以直接用，但是對二次開發并不友好
生態優勢Yarn誕生于Hadoop這個大數據的“始作俑者”項目，所以在大數據領域具有先天優勢
底層天然就是分布式存儲系統HDFS，穩定高效
其上支撐了Spark、MR等大數據領域的扛頂之座，久經考驗
社區強大，最近發布版本也明顯加快，對于長任務的支持也越來越優秀
長任務支持談及長任務（longrunningservices）的支持，有人認為早先Yarn是為了支持離線短時任務的，所以可能對長任務的支持有限
其實大可不必擔心，譬如現在基于其上的SparkStreaming就是7x24小時運行的，跑起來也沒啥問題
一般而言，要支持長任務，需要考慮如下幾個點：Faulttolerance，主要是AM的容錯
YarnSecurity，如果開啟了安全機制，令牌等的失效時間也是需要注意的
日志收集到集群
還有就是資源隔離和優先級
如果資源隔離做的太差，會對長時任務產生影響
大家感興趣可以先參考Jira
我看這個Jira13年就開始了，說明這事很早就被重視起來了
下面我們隊提到的幾個點做下解釋
FaulttoleranceYarn自身高可用
目前Yarn的Master已經實現了HA
AM容錯，我看從2
4版本（看的源碼，也可能更早的版本就已經支持）就已經支持keep買粉絲ntainersacrossattempt的選項了
什么意思呢？就是如果AM掛掉了，在Yarn重新啟動AM的過程中，所有由AM管理的容器都會被保持而不會被殺掉
除非Yarn多次嘗試都沒法把AM再啟動起來（默認兩次）
這說明從底層調度上來看，已經做的很好了
日志收集到集群日志收集在2
6版本已經是邊運行邊收集了
資源隔離資源隔離的話，Yarn做的不好，目前有效的是內存，對其他方面一直想做支持，但一直有限
這估計也是很多人最后選擇Mesos的緣由
但是現在這點優勢Mesos其實已經蕩然無存，因為Docker容器在資源隔離上已經做的足夠好
Yarn和Docker一整合，就互補了
小結Mesos和Yarn都是非常優秀的調度框架，各有其優缺點，彈性調度，統一的資源管理是未來平臺的一個趨勢，類似的這種資源管理調度框架必定會大行其道