在分布式系統(tǒng)中哮奇，服務(wù)（或組件）之間的協(xié)調(diào)是非常重要的膛腐，它構(gòu)成了分布式系統(tǒng)的基礎(chǔ)睛约。
分布式系統(tǒng)中的leader選舉、分布式鎖哲身、分布式隊(duì)列等辩涝，均需要通過(guò)協(xié)調(diào)服務(wù)（Coordination Service）實(shí)現(xiàn)。
然而勘天，由于分布式環(huán)境的復(fù)雜性怔揩，尤其是在網(wǎng)絡(luò)故障、死鎖脯丝、競(jìng)爭(zhēng)等已變?yōu)槌Ｒ?jiàn)現(xiàn)象的情況下商膊，實(shí)現(xiàn)一個(gè)魯棒（強(qiáng)壯或穩(wěn)健）的協(xié)調(diào)服務(wù)是極其困難的事情宠进。為了實(shí)現(xiàn)一個(gè)通用的分布式協(xié)調(diào)服務(wù)翘狱，避免每個(gè)分布式系統(tǒng)從頭實(shí)現(xiàn)造成不必要的工作冗余，Hadoop生態(tài)系統(tǒng)提供了ZooKeeper砰苍。
分布式協(xié)調(diào)服務(wù)ZooKeeper
分布式協(xié)調(diào)服務(wù)是分布式應(yīng)用中不可缺少的潦匈，通常擔(dān)任協(xié)調(diào)者的角色，比如leader選舉赚导、負(fù)載均衡茬缩、服務(wù)發(fā)現(xiàn)、分布式隊(duì)列和分布式鎖等吼旧，接下來(lái)以leader選舉和負(fù)載均衡為例凰锡，說(shuō)明分布式協(xié)調(diào)服務(wù)的存在意義及基本職責(zé)。
leader選舉
在分布式系統(tǒng)中圈暗，常見(jiàn)的一種軟件設(shè)計(jì)架構(gòu)為master/slave掂为，其中master負(fù)責(zé)集群管理，slave負(fù)責(zé)執(zhí)行具體的任務(wù)（比如存儲(chǔ)數(shù)據(jù)员串、處理數(shù)據(jù)）勇哗，HDFS、HBase均采用了該架構(gòu)寸齐。
這種架構(gòu)存在一個(gè)明顯缺陷：master是單點(diǎn)欲诺。
為了避免master出現(xiàn)故障導(dǎo)致整個(gè)集群不可用，常見(jiàn)的優(yōu)化方式是引入多master：
比如雙master:active master和standby master渺鹦，其中active master對(duì)外提供服務(wù)扰法，而standby master則作為備用master，一直處于“待命”狀態(tài)毅厚，一旦activemaster出現(xiàn)故障塞颁，自己則切換為active master。
引入雙master需要解決如下兩個(gè)難題：
- 如何選舉出一個(gè)master作為active master？
一種常見(jiàn)的解決思路是實(shí)現(xiàn)Paxos一致性協(xié)議祠锣，讓多個(gè)對(duì)等的服務(wù)通過(guò)某個(gè)方式達(dá)成一致性酷窥，從而選舉出一個(gè)master。 - 如何發(fā)現(xiàn)active master出現(xiàn)故障锤岸，如何讓standby master安全切換為activemaster？
該問(wèn)題的難點(diǎn)在于如何避免出現(xiàn)腦裂（split-brain）板乙，即集群中同時(shí)存在兩個(gè)active master是偷，造成數(shù)據(jù)不一致或集群出現(xiàn)混亂的現(xiàn)象。
負(fù)載均衡
- 生產(chǎn)者和消費(fèi)者如何獲知最新的消息隊(duì)列位置募逞？
- 消息隊(duì)列是分布式的蛋铆，通常由一組節(jié)點(diǎn)構(gòu)成，這些節(jié)點(diǎn)的健康狀態(tài)是動(dòng)態(tài)變化的放接，比如某個(gè)節(jié)點(diǎn)因機(jī)器故障變得對(duì)外不可用刺啦，如何讓生產(chǎn)者和消費(fèi)者動(dòng)態(tài)獲知最新的消息隊(duì)列節(jié)點(diǎn)位置是必須要解決的問(wèn)題。
- 如何讓生產(chǎn)者將數(shù)據(jù)均衡地寫(xiě)入消息隊(duì)列中各個(gè)節(jié)點(diǎn)纠脾？
- 消息隊(duì)列提供了一組可存儲(chǔ)數(shù)據(jù)的節(jié)點(diǎn)玛瘸，需讓生產(chǎn)者及時(shí)了解各個(gè)存儲(chǔ)節(jié)點(diǎn)的負(fù)載，以便智能決策將數(shù)據(jù)均衡地寫(xiě)入這些節(jié)點(diǎn)苟蹈。
- 為了解決以上兩個(gè)問(wèn)題糊渊，需要引入一個(gè)可靠的分布式協(xié)調(diào)服務(wù)，它具備簡(jiǎn)單的元信息存儲(chǔ)和動(dòng)態(tài)獲取服務(wù)狀態(tài)等基本功能慧脱。
通過(guò)leader選舉和負(fù)載均衡兩個(gè)常見(jiàn)的分布式問(wèn)題渺绒，我們可以了解到，協(xié)調(diào)服務(wù)對(duì)于一個(gè)分布式系統(tǒng)而言多重要菱鸥。為了解決服務(wù)協(xié)調(diào)這一類(lèi)通用問(wèn)題宗兼，ZooKeeper出現(xiàn)了，它將服務(wù)協(xié)調(diào)的職責(zé)從分布式系統(tǒng)中獨(dú)立出來(lái)氮采，以減少系統(tǒng)的耦合性和增強(qiáng)擴(kuò)充性殷绍。
層級(jí)命名空間
下圖是一個(gè)典型的ZooKeeper層級(jí)命名空間，整個(gè)命名方式類(lèi)似于文件系統(tǒng)鹊漠，以多叉樹(shù)形式組織在一起篡帕。
其中，每個(gè)節(jié)點(diǎn)被稱(chēng)為“znode”贸呢，它主要包含以下幾個(gè)屬性：
- data：每個(gè)znode擁有一個(gè)數(shù)據(jù)域镰烧，記錄了用戶(hù)數(shù)據(jù)，該域的數(shù)據(jù)類(lèi)1型為字節(jié)數(shù)組楞陷。ZooKeeper通過(guò)多副本方式保證數(shù)據(jù)的可靠存儲(chǔ)怔鳖。
- type：znode類(lèi)型，具體分為persistent, ephemeral, persistent_sequential和ephemeral_sequential四種基本類(lèi)似固蛾，含義如下：
- persistent：持久化節(jié)點(diǎn)结执，能夠一直可靠地保存該節(jié)點(diǎn)（除非用戶(hù)顯式刪除）度陆。
- ephemeral：臨時(shí)節(jié)點(diǎn)，該節(jié)點(diǎn)的生命周期與客戶(hù)端相關(guān)献幔，只要客戶(hù)端保持與ZooKeeper server的session不斷開(kāi)懂傀，該節(jié)點(diǎn)會(huì)一直存在，反之蜡感，一旦兩者之間連接斷開(kāi)蹬蚁，則該節(jié)點(diǎn)也將被自動(dòng)刪除。
- sequential：自動(dòng)在文件名默認(rèn)追加一個(gè)增量的唯一數(shù)字郑兴，以記錄文件創(chuàng)建順序犀斋，通常與persistent和ephemeral連用，產(chǎn)生- persistent_sequential和ephemeral_sequential兩種類(lèi)型情连。
version：znode中數(shù)據(jù)的版本號(hào)叽粹，每次數(shù)據(jù)的更新會(huì)導(dǎo)致其版本加一。
- children：znode可以包含子節(jié)點(diǎn)却舀，但由于ephemeral類(lèi)型的znode與session的生命周期是綁定的虫几，因此ZooKeeper不允許ephemeral znode有子節(jié)點(diǎn)。
- ACL：znode訪(fǎng)問(wèn)控制列表挽拔，用戶(hù)可單獨(dú)設(shè)置每個(gè)znode的可訪(fǎng)問(wèn)用戶(hù)列表持钉，以保證znode被安全訪(fǎng)問(wèn)。ZooKeeper能夠保證數(shù)據(jù)訪(fǎng)問(wèn)的原子性篱昔，即一個(gè)znode中的數(shù)據(jù)要么寫(xiě)成功每强，要么寫(xiě)失敗。
Watcher
Watcher是ZooKeeper提供的發(fā)布/訂閱機(jī)制州刽，用戶(hù)可在某個(gè)znode上注冊(cè)watcher以監(jiān)聽(tīng)它的變化空执，一旦對(duì)應(yīng)的znode被刪除或者更新（包括刪除、數(shù)據(jù)域被修改穗椅、子節(jié)點(diǎn)發(fā)生變化等）, ZooKeeper將以事件的形式將變化內(nèi)容發(fā)送給監(jiān)聽(tīng)者辨绊。需要注意的是，watcher一旦觸發(fā)后便會(huì)被刪除匹表，除非用戶(hù)再次注冊(cè)該watcher门坷。
Session
Session是Zookeeper中的一個(gè)重要概念，它是客戶(hù)端與ZooKeeper服務(wù)端之間的通信通道袍镀。同一個(gè)session中的消息是有序的。Session具有容錯(cuò)性：如果客戶(hù)端連接的ZooKeeper服務(wù)器宕機(jī)绸吸，客戶(hù)端會(huì)自動(dòng)連接到其他活著的服務(wù)器上锦茁。
leader選舉
基于ZooKeeper實(shí)現(xiàn)leader選舉的基本思想是度帮，讓各個(gè)參與競(jìng)選的實(shí)例同時(shí)在ZooKeepeer上創(chuàng)建指定的znode笨篷，比如/current/leader冕屯，誰(shuí)創(chuàng)建成功則誰(shuí)競(jìng)選成功痰洒，并將自己的信息（host丘喻、port等）寫(xiě)入該znode數(shù)據(jù)域，之后其他競(jìng)選者向該znode注冊(cè)watcher连霉，以便當(dāng)前l(fā)eader出現(xiàn)故障時(shí)跺撼，第一時(shí)間再次參與競(jìng)選歉井。
Zab協(xié)議
Zab協(xié)議 的全稱(chēng)是 Zookeeper Atomic Broadcast （Zookeeper原子廣播）哈误。Zookeeper 是通過(guò) Zab 協(xié)議來(lái)保證分布式事務(wù)的最終一致性菩貌。
Zab協(xié)議的核心：定義了事務(wù)請(qǐng)求的處理方式
- 所有的事務(wù)請(qǐng)求必須由一個(gè)全局唯一的服務(wù)器來(lái)協(xié)調(diào)處理菜谣，這樣的服務(wù)器被叫做 Leader服務(wù)器媳危。其他剩余的服務(wù)器則是 Follower服務(wù)器待笑。
- Leader服務(wù)器 負(fù)責(zé)將一個(gè)客戶(hù)端事務(wù)請(qǐng)求，轉(zhuǎn)換成一個(gè) 事務(wù)Proposal仰泻，并將該 Proposal 分發(fā)給集群中所有的 Follower 服務(wù)器滩届，也就是向所有 Follower 節(jié)點(diǎn)發(fā)送數(shù)據(jù)廣播請(qǐng)求（或數(shù)據(jù)復(fù)制）
- 分發(fā)之后Leader服務(wù)器需要等待所有Follower服務(wù)器的反饋（Ack請(qǐng)求）集侯，在Zab協(xié)議中，只要超過(guò)半數(shù)的Follower服務(wù)器進(jìn)行了正確的反饋后（也就是收到半數(shù)以上的Follower的Ack請(qǐng)求）棠枉，那么 Leader 就會(huì)再次向所有的 Follower服務(wù)器發(fā)送 Commit 消息泡挺，要求其將上一個(gè) 事務(wù)proposal 進(jìn)行提交辈讶。
Zab協(xié)議內(nèi)容
Zab 協(xié)議包括兩種基本的模式：崩潰恢復(fù) 和 消息廣播
協(xié)議過(guò)程
- 當(dāng)整個(gè)集群?jiǎn)?dòng)過(guò)程中娄猫，或者當(dāng) Leader 服務(wù)器出現(xiàn)網(wǎng)絡(luò)中弄斷贱除、崩潰退出或重啟等異常時(shí)，Zab協(xié)議就會(huì) 進(jìn)入崩潰恢復(fù)模式月幌，選舉產(chǎn)生新的Leader。
- 當(dāng)選舉產(chǎn)生了新的 Leader，同時(shí)集群中有過(guò)半的機(jī)器與該 Leader 服務(wù)器完成了狀態(tài)同步（即數(shù)據(jù)同步）之后屯阀，Zab協(xié)議就會(huì)退出崩潰恢復(fù)模式，進(jìn)入消息廣播模式盖袭。
- 這時(shí)弟塞，如果有一臺(tái)遵守Zab協(xié)議的服務(wù)器加入集群凭峡，因?yàn)榇藭r(shí)集群中已經(jīng)存在一個(gè)Leader服務(wù)器在廣播消息，那么該新加入的服務(wù)器自動(dòng)進(jìn)入恢復(fù)模式：找到Leader服務(wù)器决记，并且完成數(shù)據(jù)同步摧冀。同步完成后，作為新的Follower一起參與到消息廣播流程中系宫。
資源管理與調(diào)度系統(tǒng)YARN
YARN設(shè)計(jì)動(dòng)機(jī)
YARN作為一個(gè)通用的資源管理系統(tǒng)索昂，其目標(biāo)是將短作業(yè)和長(zhǎng)服務(wù)混合部署到一個(gè)集群中，并為它們提供統(tǒng)一的資源管理和調(diào)度功能扩借。YARN是大數(shù)據(jù)系統(tǒng)發(fā)展到一定階段的必然產(chǎn)物椒惨。
1．提高集群資源利用率
在大數(shù)據(jù)時(shí)代，為了存儲(chǔ)和處理海量數(shù)據(jù)潮罪，需要規(guī)模較大的服務(wù)器集群或者數(shù)據(jù)中心康谆，一般說(shuō)來(lái)，這些集群上運(yùn)行著數(shù)量眾多類(lèi)型紛雜的應(yīng)用程序和服務(wù)错洁，比如離線(xiàn)作業(yè)秉宿、流式作業(yè)戒突、迭代式作業(yè)屯碴、Crawler Server, Web Server等，傳統(tǒng)的做法是膊存，每種類(lèi)型的作業(yè)或者服務(wù)對(duì)應(yīng)一個(gè)單獨(dú)的集群导而，以避免相互干擾。這樣隔崎，集群被分割成數(shù)量眾多的小集群：Hadoop集群今艺、HBase集群、Storm集群爵卒，Web Server集群等虚缎，然而，由于不同類(lèi)型的作業(yè)/服務(wù)需要的資源量不同钓株，因此实牡，這些小集群的利用率通常很不均衡，有的集群滿(mǎn)負(fù)荷轴合、資源緊張创坞，而另外一些則長(zhǎng)時(shí)間閑置、資源利用率極低受葛，而由于這些集群之間資源無(wú)法共享题涨，因此造就了不同時(shí)間段不同集群資源利用率不同偎谁。為了提高資源整體利用率，一種解決方案是將這些小集群合并成一個(gè)大集群纲堵，讓它們共享這個(gè)大集群的資源巡雨，并由一個(gè)資源統(tǒng)一調(diào)度系統(tǒng)進(jìn)行資源管理和分配，這就誕生了類(lèi)似于YARN的系統(tǒng)席函。從集群共享角度看鸯隅，這類(lèi)系統(tǒng)實(shí)際上將公司的所有硬件資源抽象成一臺(tái)大型計(jì)算機(jī)，供所有用戶(hù)使用向挖。
2．服務(wù)自動(dòng)化部署
一旦將所有計(jì)算資源抽象成一個(gè)“大型計(jì)算機(jī)”后蝌以，就會(huì)產(chǎn)生了一個(gè)問(wèn)題：公司的各種服務(wù)如何進(jìn)行部署？Borg/YARN/Mesos/Torca這類(lèi)系統(tǒng)需要具備服務(wù)自動(dòng)化部署的功能何之，因此跟畅，從服務(wù)部署的角度看，這類(lèi)系統(tǒng)實(shí)際上是服務(wù)統(tǒng)一管理系統(tǒng)溶推，這類(lèi)系統(tǒng)提供服務(wù)資源申請(qǐng)徊件、服務(wù)自動(dòng)化部署、服務(wù)容錯(cuò)等功能蒜危。
YARN基本架構(gòu)
YARN總體上采用master/slave架構(gòu)虱痕，其中，ResourceManager為master,NodeManager為slave, ResourceManager負(fù)責(zé)對(duì)各個(gè)NodeManager上的資源進(jìn)行統(tǒng)一管理和調(diào)度辐赞。當(dāng)用戶(hù)提交一個(gè)應(yīng)用程序時(shí)部翘，需要提供一個(gè)用以跟蹤和管理這個(gè)程序的ApplicationMaster，它負(fù)責(zé)向ResourceManager申請(qǐng)資源响委，并要求NodeManager啟動(dòng)可以占用一定資源的任務(wù)新思，由于不同的ApplicationMaster被分布到不同的節(jié)點(diǎn)上，因此它們之間不會(huì)相互影響赘风。
1. ResourceManager（RM）
RM是一個(gè)全局的資源管理器夹囚，負(fù)責(zé)整個(gè)系統(tǒng)的資源管理和分配。它主要由兩個(gè)組件構(gòu)成：調(diào)度器（Scheduler）和應(yīng)用管理器（Applications Manager, ASM）邀窃。
? 調(diào)度器：調(diào)度器主要功能是根據(jù)資源容量荸哟，隊(duì)列等方面的限制條件（如每個(gè)隊(duì)列分配一定的資源，最多執(zhí)行一定數(shù)量的作業(yè)等）瞬捕，將系統(tǒng)中的資源分配給各個(gè)應(yīng)用程序鞍历。YARN中的調(diào)度器是一個(gè)“純調(diào)度器”，它不再?gòu)氖氯魏闻c具體應(yīng)用程序相關(guān)的工作山析，比如不負(fù)責(zé)監(jiān)控或者跟蹤應(yīng)用的執(zhí)行狀態(tài)等堰燎，也不負(fù)責(zé)重新啟動(dòng)因應(yīng)用執(zhí)行失敗或者硬件故障而產(chǎn)生的失敗任務(wù)，這些均交由應(yīng)用程序相關(guān)的ApplicationMaster完成笋轨。調(diào)度器僅根據(jù)各個(gè)應(yīng)用程序的資源需求進(jìn)行資源分配秆剪，而資源分配單位用一個(gè)抽象概念“資源容器”（Resource Container赊淑，簡(jiǎn)稱(chēng)Container）表示，Container是一個(gè)動(dòng)態(tài)資源分配單位仅讽，它將內(nèi)存陶缺、CPU、磁盤(pán)洁灵、網(wǎng)絡(luò)等資源封裝在一起饱岸，從而限定每個(gè)任務(wù)使用的資源量。在YARN中徽千，資源調(diào)度器是一個(gè)可插拔的組件苫费，用戶(hù)可根據(jù)自己的需要設(shè)計(jì)新的調(diào)度器，YARN提供了多種直接可用的調(diào)度器双抽，比如Fair Scheduler和Capacity Scheduler百框。
? 應(yīng)用程序管理器：應(yīng)用程序管理器負(fù)責(zé)管理整個(gè)系統(tǒng)中的所有應(yīng)用程序，包括應(yīng)用程序提交牍汹、與調(diào)度器協(xié)商資源以啟動(dòng)ApplicationMaster铐维、監(jiān)控ApplicationMaster運(yùn)行狀態(tài)并在失敗時(shí)重新啟動(dòng)它等。為了避免單個(gè)ResourceManager出現(xiàn)單點(diǎn)故障導(dǎo)致整個(gè)集群不可用慎菲，YARN引入主備ResourceManager實(shí)現(xiàn)了HA嫁蛇，當(dāng)Active ResourceManager出現(xiàn)故障時(shí)，StandbyResourceManager會(huì)通過(guò)ZooKeeper選舉露该，自動(dòng)提升為Active ResourceManager睬棚。
2. ApplicationMaster（AM）
用戶(hù)提交的每個(gè)應(yīng)用程序均包含一個(gè)獨(dú)立的AM，其主要功能包括：
? 與RM調(diào)度器協(xié)商以獲取資源（用Container表示）有决。
? 將得到的資源進(jìn)一步分配給內(nèi)部的任務(wù)闸拿。
? 與NM通信以啟動(dòng)/停止任務(wù)空盼。
? 監(jiān)控所有任務(wù)的運(yùn)行狀態(tài)书幕，并在任務(wù)運(yùn)行失敗時(shí)重新為任務(wù)申請(qǐng)資源以重啟任務(wù)。
3. NodeManager（NM）
NM是每個(gè)節(jié)點(diǎn)上的資源管理器揽趾，一方面台汇，它會(huì)定時(shí)地向RM匯報(bào)本節(jié)點(diǎn)上的資源使用情況和各個(gè)Container的運(yùn)行狀態(tài)篱瞎，另一方面，它接收并處理來(lái)自AM的任務(wù)啟動(dòng)/停止等各種請(qǐng)求牵素。在一個(gè)集群中笆呆，NodeManager通常存在多個(gè)赠幕，由于YARN內(nèi)置了容錯(cuò)機(jī)制榕堰，單個(gè)NodeManager的故障不會(huì)對(duì)集群中的應(yīng)用程序運(yùn)行產(chǎn)生嚴(yán)重影響逆屡。
4. Container
Container是YARN中的基本資源分配單位魏蔗，是對(duì)應(yīng)用程序運(yùn)行環(huán)境的抽象沫勿，并為應(yīng)用程序提供資源隔離環(huán)境。它封裝了多維度的資源诫惭，如內(nèi)存夕土、CPU瘟判、磁盤(pán)、網(wǎng)絡(luò)等篮撑，當(dāng)AM向RM申請(qǐng)資源時(shí)匆瓜，RM為AM返回的資源便是用Container表示的驮吱。YARN中每個(gè)任務(wù)均會(huì)對(duì)應(yīng)一個(gè)Container桐筏，且該任務(wù)只能使用該Container中描述的資源梅忌。需要注意的是铸鹰，Container不同于MRv1中的slot蹋笼，它是一個(gè)動(dòng)態(tài)資源劃分單位剖毯，是根據(jù)應(yīng)用程序的需求動(dòng)態(tài)生成的逊谋。Container最終是由ContainerExecutor啟動(dòng)和運(yùn)行的擂达，YARN提供了三種可選的ContainerExecutor：
? DefaultContainerExecutor：默認(rèn)ContainerExecutor實(shí)現(xiàn)，直接以進(jìn)程方式啟動(dòng)Container板鬓，不提供任何隔離機(jī)制和安全機(jī)制，任何應(yīng)用程序最終均是以YARN服務(wù)啟動(dòng)者的身份運(yùn)行的究恤。
? LinuxContainerExecutor：提供了安全和Cgroups隔離的ContainerExecutor，它以應(yīng)用程序提交者的身份運(yùn)行Container部宿，且使用Cgroups為Container提供CPU和內(nèi)存隔離的運(yùn)行環(huán)境抄腔。
? DockerContainerExecutor：基于Docker實(shí)現(xiàn)的ContainerExecutor理张，可直接在YARN集群中運(yùn)行Docker Container赫蛇。Docker是基于Linux Container技術(shù)構(gòu)建的非常輕量級(jí)的虛擬機(jī)，目前被廣泛應(yīng)用雾叭。
YARN高可用
YARN提供了恢復(fù)機(jī)制，這使得YARN在服務(wù)出現(xiàn)故障或人工重啟時(shí)拷况，不會(huì)對(duì)正在運(yùn)行的應(yīng)用程序產(chǎn)生任何影響赚瘦。本節(jié)將從ResourceManager HA起意、ResourceManagerRecovery和NodeManager Recovery三個(gè)方面討論YARN高可用方面的設(shè)計(jì)揽咕。
1. ResourceManager HA
ResourceManager負(fù)責(zé)集群中資源的調(diào)度和應(yīng)用程序的管理设易，是YARN最核心的組件。由于YARN采用了master/slave架構(gòu)蛹头，這使得ResourceManager成為單點(diǎn)故障顿肺。為了避免ResourceManager故障導(dǎo)致整個(gè)集群不可用，YARN引入了Active/StandbyResourceManager渣蜗，通過(guò)冗余方式解決ResourceManager單點(diǎn)故障屠尊。當(dāng)Active ResourceManager出現(xiàn)故障時(shí)，Standby ResourceManager可通過(guò)ZooKeeper選舉成為Active ResourceManager耕拷，并通過(guò)ResourceManager Recovery機(jī)制恢復(fù)狀態(tài)讼昆。
2. ResourceManager
RecoveryResourceManager內(nèi)置了重啟恢復(fù)功能，當(dāng)ResourceManager就地重啟骚烧，或發(fā)生Active/Standby切換時(shí)浸赫，不會(huì)影響正在運(yùn)行的應(yīng)用程序運(yùn)行。ResourceManagerRecovery主要流程如下：
1）保存元信息：Active ResourceManager運(yùn)行過(guò)程中赃绊，會(huì)將應(yīng)用程序的元信息掺炭，狀態(tài)信息以及安全憑證等數(shù)據(jù)持久化到狀態(tài)存儲(chǔ)系統(tǒng)（state-store）中，YARN支持三種可選的state-store凭戴，分別是：
? 基于ZooKeeper的state-store:
ZooKeeper是ResourceManager HA必選的state-store涧狮，盡管Resource Restart可選擇其他state-store，但只有ZooKeeper能防止腦裂（split-brain）現(xiàn)象么夫，即同時(shí)存在多個(gè)Active ResourceManager狀態(tài)信息的情況者冤。
? 基于FileSystem的state-store：
支持HDFS和本地文件系統(tǒng)兩種方式，但不能防止腦裂档痪。
? 基于LevelDB的state-store：
基于LevelDB的state-store比前兩種方案更加輕量級(jí)涉枫。LevelDB能更好地支持原子操作，每次更新占用更少的IO資源腐螟，生成的文件數(shù)目更少愿汰。
2）加載元信息：一旦Active ResourceManager重啟或出現(xiàn)故障，新啟動(dòng)的Resource-Manager將從存儲(chǔ)系統(tǒng)中重新加載應(yīng)用程序的相關(guān)數(shù)據(jù)乐纸，在此過(guò)程中衬廷，所有運(yùn)行在各個(gè)NodeManager的Container仍正常運(yùn)行。
3）重構(gòu)狀態(tài)信息：新的ResourceManager重啟完成后汽绢，各個(gè)NodeManager會(huì)向它重新注冊(cè)吗跋，并將所管理的Container匯報(bào)給ResourceManager，這樣ResourceManager可動(dòng)態(tài)重構(gòu)資源分配信息、各個(gè)應(yīng)用程序以及其對(duì)應(yīng)Container等關(guān)鍵數(shù)據(jù)跌宛；同時(shí)酗宋，ApplicationMaster會(huì)向ResourceManager重新發(fā)送資源請(qǐng)求，以便ResourceManager重新為其分配資源疆拘。
3. NodeManager
RecoveryNodeManager內(nèi)置了重啟恢復(fù)功能蜕猫，當(dāng)NodeManager就地重啟時(shí)，之前正在運(yùn)行的Container不會(huì)被殺掉哎迄，而是由新的NodeManager接管回右，并繼續(xù)正常運(yùn)行。以上幾種高可用機(jī)制的實(shí)現(xiàn)芬失，使得YARN成為一個(gè)通用的資源管理系統(tǒng)楣黍，這使得在一個(gè)集群中混合部署短作業(yè)和長(zhǎng)服務(wù)變得可能。
YARN工作流程
運(yùn)行在YARN上的應(yīng)用程序主要分為兩類(lèi)：短作業(yè)和長(zhǎng)服務(wù)棱烂，其中租漂，短作業(yè)是指一定時(shí)間內(nèi)（可能是秒級(jí)、分鐘級(jí)或小時(shí)級(jí)颊糜，盡管天級(jí)別或者更長(zhǎng)時(shí)間的也存在哩治，但非常少）可運(yùn)行完成并退出的應(yīng)用程序，比如MapReduce作業(yè)衬鱼、Spark作業(yè)等业筏；長(zhǎng)服務(wù)是指不出意外，永不終止運(yùn)行的應(yīng)用程序鸟赫，通常是一些在線(xiàn)服務(wù)蒜胖，比如Storm Servive（主要包括Nimbus和Supervisor兩類(lèi)服務(wù)）、HBase Service（包括Hmaster和RegionServer兩類(lèi)服務(wù)）[插圖]等抛蚤，而它們本身作為一個(gè)框架或服務(wù)提供了訪(fǎng)問(wèn)接口供用戶(hù)使用台谢。
當(dāng)用戶(hù)向YARN中提交一個(gè)應(yīng)用程序后，YARN將分兩個(gè)階段運(yùn)行該應(yīng)用程序：第一個(gè)階段是啟動(dòng)ApplicationMaster岁经；第二個(gè)階段是由ApplicationMaster創(chuàng)建應(yīng)用程序朋沮，為它申請(qǐng)資源，并監(jiān)控它的整個(gè)運(yùn)行過(guò)程缀壤，直到運(yùn)行成功樊拓。
1）提交應(yīng)用程序：用戶(hù)通過(guò)客戶(hù)端與YARN ResourceManager通信，以提交應(yīng)用程序塘慕，應(yīng)用程序中需包含ApplicationMaster可執(zhí)行代碼筋夏、啟動(dòng)命令和資源需求、應(yīng)用程序可執(zhí)行代碼和資源需求苍糠、優(yōu)先級(jí)叁丧、提交到的隊(duì)列等信息。
2）啟動(dòng)ApplicationMaster：ResourceManager為該應(yīng)用程序分配第一個(gè)Container岳瞭，并與對(duì)應(yīng)的NodeManager通信拥娄，要求它在這個(gè)Container中啟動(dòng)應(yīng)用程序的ApplicationMaster，之后ApplicationMaster的生命周期直接被ResourceManager管理瞳筏。
3）ApplicationMaster注冊(cè)：ApplicationMaster啟動(dòng)后稚瘾，首先，向ResourceManager注冊(cè)姚炕，這樣摊欠，用戶(hù)可以直接通過(guò)ResourceManage查看應(yīng)用程序的運(yùn)行狀態(tài)，然后柱宦，它將初始化應(yīng)用程序些椒，并按照一定的策略為內(nèi)部任務(wù)申請(qǐng)資源，監(jiān)控它們的運(yùn)行狀態(tài)掸刊，直到運(yùn)行結(jié)束免糕，即重復(fù)步驟4～7。
4）資源獲扔遣唷：ApplicationMaster采用輪詢(xún)的方式通過(guò)RPC協(xié)議向ResourceManager申請(qǐng)和領(lǐng)取資源石窑。
5）請(qǐng)求啟動(dòng)Container：一旦ApplicationMaster申請(qǐng)到資源后，則與對(duì)應(yīng)的NodeManager通信蚓炬，請(qǐng)求為其啟動(dòng)任務(wù)（NodeManager會(huì)將任務(wù)放到Container中）松逊。
6）啟動(dòng)Container：NodeManager為任務(wù)設(shè)置好運(yùn)行環(huán)境（包括環(huán)境變量、jar包肯夏、二進(jìn)制程序等）后经宏，將任務(wù)啟動(dòng)命令寫(xiě)到一個(gè)腳本中，并通過(guò)ContainerExecutor運(yùn)行該腳本啟動(dòng)任務(wù)驯击。
7）Container監(jiān)控：ApplicationMaster可通過(guò)兩種方式獲取各個(gè)Container的運(yùn)行狀態(tài)烁兰，以便在任務(wù)失敗時(shí)重新啟動(dòng)任務(wù)：
? ApplicationMaster與ResourceManager間維護(hù)了周期性心跳信息，每次通信可獲取自己分管的Container的運(yùn)行狀態(tài)余耽。
? 各個(gè)Container可通過(guò)某個(gè)RPC協(xié)議向ApplicationMaster匯報(bào)自己的狀態(tài)和進(jìn)度（視具體應(yīng)用程序而定缚柏，比如MapReduce和YARN均實(shí)現(xiàn)了該方式）。
8）注銷(xiāo)ApplicationMaster：應(yīng)用程序運(yùn)行完成后碟贾，ApplicationMaster向ResourceManager注銷(xiāo)币喧，并退出執(zhí)行。
