01 youtube視頻下載器教程docker安裝kafka(kafka是否適合在docker中使用？單機集群是否有意義)

Kafka集群部署（Docker容器的方式）

文章主要介紹以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" 異常）

kafka是否適合在docker中使用？單機集群是否有意義

可部署性先說明下，這里探討的是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都是非常優秀的調度框架，各有其優缺點，彈性調度，統一的資源管理是未來平臺的一個趨勢，類似的這種資源管理調度框架必定會大行其道

一些常見的誤解脫胎于Hadoop，繼承了他的光環和生態，然而這也會給其帶來一定的困惑，首先就是光環一直被Hadoop給蓋住了，而且由于固有的慣性，大家會理所當然的認為Yarn只是Hadoop里的一個組件，有人會想過把Yarn拿出來單獨用么？然而，就像我在之前的一篇課程里，反復強調，Hadoop是一個軟件集合，包含分布式存儲，資源管理調度，計算框架三個部分

他們之間沒有必然的關系，是可以獨立開來的

而Yarn就是一個資源管理調度引擎，其一開始的設計目標就是為了通用，不僅僅是跑MR

現在基于Yarn之上的服務已經非常多，典型的比如Spark

這里還有另外一個誤區，MR目前基本算是離線批量的代名詞，這回讓人誤以為Yarn也只是適合批量離線任務的調度

其實不然，我在上面已經給出了分析，Yarn是完全可以保證長任務的穩定可靠的運行的

如何基于Yarn開發分布式程序本文不會具體教你如何使用Yarn的API，不過如果你想知道Yarn的API，但是又覺得官方文檔太過簡略，我這里倒是可以給出兩個建議：代碼使用范例可以參看SparkYarn相關的代碼

算的上是一個非常精簡的Yarn的adaptor

買本Yarn相關的書，了解其體系結構也有助于你了解其API的設計

接下來的內容會探討以下兩個主題：基于Yarn開發分布式程序需要做的一些準備工作基于Yarn開發容器調度系統的一些基本思路基于Yarn開發分布式程序需要做的一些準備工作肯定不能擼起袖子就開始干

開始動手前，我們需要知道哪些事情呢？Yarn原生的API太底層，太復雜了如果你想愉快的開發Yarn的應用，那么對Yarn的API進行一次封裝，是很有必要的

Yarn為了靈活，或者為了能夠滿足開發者大部分的需求，底層交互的API就顯得比較原始了

自然造成開發難度很大

這個也不是我一個人覺得，現在Apache的Twill，以及Hulu他們開發的時候Adaptor那一層，其實都是為了解決這個問題

那為什么我沒有用Twill呢，第一是文檔實在太少，第二是有點復雜，我不需要這么復雜的東西

我覺得，Twill與其開發這么多功能，真的不如好好寫寫文檔

最好是能開發一個解決一類問題的FrameworkYarn只是一個底層的資源管理和調度引擎

一般你需要基于之上開發一套解決特定問題的Framework

以Spark為例，他是解決分布式計算相關的一些問題

而以我開發的容器調度程序，其實是為了解決動態部署Web應用的

在他們之上，才是你的應用

比如你要統計日志，你只要在Spark上開發一個Application

比如你想要提供一個推薦系統，那么你只要用容器包裝下，就能被容器調度程序調度部署

所以通常而言，基于Yarn的分布式應用應該符合這么一個層次：Yarn->Adapter->Framework->ApplicationAdapter就是我第一條說的，你自個封裝了Yarn的API

Framework就是解決一類問題的編程框架，Application才是你真正要解決業務的系統

通過這種解耦，各個層次只要關注自己的核心功能點即可

保證你上層的Framework/Application可以移植Spark是個典型，他可以跑在Mesos上，也可以跑在Yarn上，還可以跑在自己上面（Standalone），實時上，泡在Yarn上的，以及跑Standalone模式的，都挺多的

這得益于Spark本身不依賴于底層的資源管理調度引擎

這其實也是我上面說的兩條帶來的好處，因為有了Adaptor，上層的Framework可以不用綁死在某個資源調度引擎上

而Framework則可以讓Applicaiton無需關注底層調度的事情，只要關注業務即可

另外，你費盡心機開發的Framework上，你自然是希望它能跑在的平臺上，已滿足的人的需求，對吧

基于Yarn開發容器調度系統的一些基本思路首先我們需要了解兩個概念：啞應用

所謂啞應用指的是無法和分布式系統直接進行交互，分布式系統也僅僅透過容器能進行生命周期的控制，比如關閉或者開啟的應用

典型的比如MySQL、Nginx等這些基礎應用

他們一般有自己特有的交互方式，譬如命令行或者socket協議或者HTTP協議

伴生組件

因為有了啞應用的存在，分布式系統為了能夠和

很赞哦!（8）