我的架構夢：（五十九） Apache Hadoop 架構與原理

一、Hadoop的重要組成

Hadoop=HDFS(分散式檔案系統)+MapReduce(分散式計算框架)+Yarn(資源協調框架)+Common模組

1、Hadoop HDFS:(Hadoop Distribute File System )一個高可靠、高吞吐量的分散式檔案系統

比如:100T資料儲存，“分而治之”

分:拆分–》資料切割，100T資料拆分為10G一個資料塊由一個電腦節點儲存這個資料塊。

資料切割、製作副本、分散儲存

圖中涉及到幾個角色

NameNode(nn): 儲存檔案的後設資料，比如檔名、檔案目錄結構、檔案屬性(生成時間、副
本數、檔案許可權)，以及每個檔案的塊列表和塊所在的DataNode等。

SecondaryNameNode(2nn): 輔助NameNode更好的工作，用來監控HDFS狀態的輔助後臺
程式，每隔一段時間獲取HDFS後設資料快照。

DataNode(dn): 在本地檔案系統儲存檔案塊資料，以及塊資料的校驗。

注意:NN,2NN,DN這些既是角色名稱，程式名稱，代指電腦節點名稱！！！

2、Hadoop MapReduce:一個分散式的離線平行計算框架

拆解任務、分散處理、彙整結果

MapReduce計算 = Map階段 + Reduce階段

Map階段就是“分”的階段，並行處理輸入資料;

Reduce階段就是“合”的階段，對Map階段結果進行彙總;

3、Hadoop YARN:作業排程與叢集資源管理的框架

計算資源協調

Yarn中有如下幾個主要角色，同樣，既是角色名、也是程式名，也指代所在計算機節點名稱。

ResourceManager(rm): 處理客戶端請求、啟動/監控ApplicationMaster、監控
NodeManager、資源分配與排程。

NodeManager(nm): 單個節點上的資源管理、處理來自ResourceManager的命令、處理來自
ApplicationMaster的命令。

ApplicationMaster(am): 資料切分、為應用程式申請資源，並分配給內部任務、任務監控與容錯。

Container: 對任務執行環境的抽象，封裝了CPU、記憶體等多維資源以及環境變數、啟動命令等任務執行相關的資訊。

ResourceManager是老大，NodeManager是小弟，ApplicationMaster是計算任務專員。

4、Hadoop Common:支援其他模組的工具模組(Configuration、RPC、序列化機制、日誌操作)

二、HDFS分散式檔案系統

1、HDFS 簡介

HDFS (全稱:Hadoop Distribute File System，Hadoop 分散式檔案系統)是 Hadoop 核心組成，是分散式儲存服務。

分散式檔案系統橫跨多臺計算機，在大資料時代有著廣泛的應用前景，它們為儲存和處理超大規模資料提供所需的擴充套件能力。

HDFS是分散式檔案系統中的一種。

2、HDFS的重要概念

HDFS 通過統一的名稱空間目錄樹來定位檔案; 另外，它是分散式的，由很多伺服器聯合起來實現其功能，叢集中的伺服器有各自的角色(分散式本質是拆分，各司其職)。

2.1 典型的 Master/Slave 架構

• HDFS 的架構是典型的 Master/Slave 結構。
• HDFS叢集往往是一個NameNode(HA架構會有兩個NameNode,聯邦機制)+多個DataNode組成;
• NameNode是叢集的主節點，DataNode是叢集的從節點。

2.2 分塊儲存(block機制)

• HDFS 中的檔案在物理上是分塊儲存(block)的，塊的大小可以通過配置引數來規定;
• Hadoop2.x版本中預設的block大小是128M;

2.3 名稱空間(NameSpace)

• HDFS 支援傳統的層次型檔案組織結構。使用者或者應用程式可以建立目錄，然後將檔案儲存在這些目錄裡。檔案系統名字空間的層次結構和大多數現有的檔案系統類似:使用者可以建立、刪除、移動 或重新命名檔案。

• Namenode 負責維護檔案系統的名字空間，任何對檔案系統名字空間或屬性的修改都將被 Namenode 記錄下來。

• HDFS提供給客戶單一個抽象目錄樹，訪問形式:hdfs://namenode的hostname:port/test/inputhdfs://linux121:9000/test/input

2.4 NameNode後設資料管理

• 我們把目錄結構及檔案分塊位置資訊叫做後設資料。

• NameNode的後設資料記錄每一個檔案所對應的block資訊(block的id,以及所在的DataNode節點的資訊)

2.5 DataNode資料儲存

• 檔案的各個 block 的具體儲存管理由 DataNode 節點承擔。

• 一個block會有多個DataNode來儲存，DataNode會定時向NameNode來彙報自己持有的block資訊。

2.6 副本機制

• 為了容錯，檔案的所有 block 都會有副本。每個檔案的 block 大小和副本系數都是可配置的。應用程式可以指定某個檔案的副本數目。副本系數可以在檔案建立的時候指定，也可以在之後改變。 副本數量預設是3個。

2.7 一次寫入，多次讀出

• HDFS 是設計成適應一次寫入，多次讀出的場景，且不支援檔案的隨機修改。 (支援追加寫入， 不只支援隨機更新)

• 正因為如此，HDFS 適合用來做大資料分析的底層儲存服務，並不適合用來做網盤等應用(修改不方便，延遲大，網路開銷大，成本太高)

3、HDFS 架構

3.1 NameNode(nn): Hdfs叢集的管理者，Master

• 維護管理Hdfs的名稱空間(NameSpace)
• 維護副本策略
• 記錄檔案塊(Block)的對映資訊
• 負責處理客戶端讀寫請求

3.2 DataNode:NameNode下達命令，DataNode執行實際操作，Slave節點。

• 儲存實際的資料塊
• 負責資料塊的讀寫

3.3 Client:客戶端

• 上傳檔案到HDFS的時候，Client負責將檔案切分成Block,然後進行上傳
• 請求NameNode互動，獲取檔案的位置資訊
• 讀取或寫入檔案，與DataNode互動
• Client可以使用一些命令來管理HDFS或者訪問HDFS

4、HDFS讀寫解析

4.1 HDFS讀資料流程

• 客戶端通過Distributed FileSystem向NameNode請求下載檔案，NameNode通過查詢後設資料， 找到檔案塊所在的DataNode地址。
• 挑選一臺DataNode(就近原則，然後隨機)伺服器，請求讀取資料。
• DataNode開始傳輸資料給客戶端(從磁碟裡面讀取資料輸入流，以Packet為單位來做校驗)。
• 客戶端以Packet為單位接收，先在本地快取，然後寫入目標檔案。

4.2 HDFS寫資料流程

• 客戶端通過Distributed FileSystem模組向NameNode請求上傳檔案，NameNode檢查目標檔案是否已存在，父目錄是否存在。
• NameNode返回是否可以上傳。
• 客戶端請求第一個 Block上傳到哪幾個DataNode伺服器上。
• NameNode返回3個DataNode節點，分別為dn1、dn2、dn3。
• 客戶端通過FSDataOutputStream模組請求dn1上傳資料，dn1收到請求會繼續呼叫dn2，然後dn2呼叫dn3，將這個通訊管道建立完成。
• dn1、dn2、dn3逐級應答客戶端。
• 客戶端開始往dn1上傳第一個Block(先從磁碟讀取資料放到一個本地記憶體快取)，以Packet為單位，dn1收到一個Packet就會傳給dn2，dn2傳給dn3;dn1每傳一個packet會放入一個確認佇列等待確認。
• 當一個Block傳輸完成之後，客戶端再次請求NameNode上傳第二個Block的伺服器。(重複執行3-7步)。

4.3 驗證Packet程式碼

@Test
public void testUploadPacket() throws IOException {
    // 1.準備讀取本地檔案的輸入流
    final FileInputStream in = new FileInputStream(new File("d:/riemann.txt"));
    // 2.準備好寫出資料到hdfs的輸出流
    final FSDataOutputStream out = fs.create(new Path("/riemann.txt"), new Progressable() {
        public void progress() {
            // 這個progress方法就是每傳輸64KB(packet)就會執行一次，
            System.out.println("&");
        }
    });
    // 3.實現流拷貝
    IOUtils.copyBytes(in, out, configuration); // 預設關閉流選項是true，所以會自動關閉
    // 4.關流 可以再次關閉也可以不關了
}

5、HDFS後設資料管理機制

問題1:NameNode如何管理和儲存後設資料?

計算機中儲存資料兩種:記憶體或者是磁碟

後設資料儲存磁碟:儲存磁碟無法面對客戶端對後設資料資訊的任意的快速低延遲的響應，但是安全性高。

後設資料儲存記憶體:後設資料存放記憶體，可以高效的查詢以及快速響應客戶端的查詢請求，資料儲存在內 存，如果斷點，記憶體中的資料全部丟失。

解決方案:記憶體+磁碟; NameNode記憶體+FsImage的檔案(磁碟)

新問題:磁碟和記憶體中後設資料如何劃分?

兩個資料一模一樣，還是兩個資料合併到一起才是一份完整的資料呢?

一模一樣:client如果對後設資料進行增刪改操作，需要保證兩個資料的一致性。FsImage檔案操作起來 效率也不高。

兩個合併=完整資料:NameNode引入了一個edits檔案(日誌檔案:只能追加寫入)edits檔案記錄的 是client的增刪改操作，

不再選擇讓NameNode把資料dump出來形成FsImage檔案(這種操作是比較消耗資源)。

後設資料管理流程圖

5.1 第一階段:NameNode啟動

• 第一次啟動NameNode格式化後，建立Fsimage和Edits檔案。如果不是第一次啟動，直接加 載編輯日誌和映象檔案到記憶體。
• 客戶端對後設資料進行增刪改的請求。
• NameNode記錄操作日誌，更新滾動日誌。
• NameNode在記憶體中對資料進行增刪改。

5.2 第二階段:Secondary NameNode工作

• Secondary NameNode詢問NameNode是否需要CheckPoint。直接帶回NameNode是否執 行檢查點操作結果。
• Secondary NameNode請求執行CheckPoint。
• NameNode滾動正在寫的Edits日誌。
• 將滾動前的編輯日誌和映象檔案拷貝到Secondary NameNode。
• Secondary NameNode載入編輯日誌和映象檔案到記憶體，併合並。
• 生成新的映象檔案fsimage.chkpoint。
• 拷貝fsimage.chkpoint到NameNode。
• NameNode將fsimage.chkpoint重新命名成fsimage。

三、MapReduce程式設計框架

1、MapReduce思想

MapReduce思想在生活中處處可見。我們或多或少都曾接觸過這種思想。MapReduce的思想核心是分 而治之。

充分利用了並行處理的優勢。

即使是釋出過論文實現分散式計算的谷歌也只是實現了這種思想，而不是自己原創。

MapReduce任務過程是分為兩個處理階段:

• Map階段:Map階段的主要作用是“分”，即把複雜的任務分解為若干個“簡單的任務”來並行處理。 Map階段的這些任務可以平行計算，彼此間沒有依賴關係。
• Reduce階段:Reduce階段的主要作用是“合”，即對map階段的結果進行全域性彙總。

再次理解MapReduce的思想

2、MapReduce原理分析

2.1 MapTask執行機制詳解

MapTask流程

詳細步驟:

• 首先，讀取資料元件InputFormat(預設TextInputFormat)會通過getSplits方法對輸入目錄中文 件進行邏輯切片規劃得到splits，有多少個split就對應啟動多少個MapTask。split與block的對應關係預設是一對一。
• 將輸入檔案切分為splits之後，由RecordReader物件(預設LineRecordReader)進行讀取，以\n 作為分隔符，讀取一行資料，返回<key，value>。Key表示每行首字元偏移值，value表示這一行 文字內容。
• 讀取split返回<key,value>，進入使用者自己繼承的Mapper類中，執行使用者重寫的map函式。 RecordReader讀取一行這裡呼叫一次。
• map邏輯完之後，將map的每條結果通過context.write進行collect資料收集。在collect中，會先 對其進行分割槽處理，預設使用HashPartitioner。
  MapReduce提供Partitioner介面，它的作用就是根據key或value及reduce的數量來決定當前的這對 輸出資料最終應該交由哪個reduce task處理。預設對key hash後再以reduce task數量取模。預設的 取模方式只是為了平均reduce的處理能力，如果使用者自己對Partitioner有需求，可以訂製並設定到 job上。
• 接下來，會將資料寫入記憶體，記憶體中這片區域叫做環形緩衝區，緩衝區的作用是批量收集map結 果，減少磁碟IO的影響。我們的key/value對以及Partition的結果都會被寫入緩衝區。當然寫入之 前，key與value值都會被序列化成位元組陣列。
  a. 環形緩衝區其實是一個陣列，陣列中存放著key、value的序列化資料和key、value的後設資料信 息，包括partition、key的起始位置、value的起始位置以及value的長度。環形結構是一個抽象概念。
  b. 緩衝區是有大小限制，預設是100MB。當map task的輸出結果很多時，就可能會撐爆記憶體，所以 需要在一定條件下將緩衝區中的資料臨時寫入磁碟，然後重新利用這塊緩衝區。這個從記憶體往磁碟 寫資料的過程被稱為Spill，中文可譯為溢寫。這個溢寫是由單獨執行緒來完成，不影響往緩衝區寫 map結果的執行緒。溢寫執行緒啟動時不應該阻止map的結果輸出，所以整個緩衝區有個溢寫的比例 spill.percent。這個比例預設是0.8，也就是當緩衝區的資料已經達到閾值(buffer size * spill percent = 100MB * 0.8 = 80MB)，溢寫執行緒啟動，鎖定這80MB的記憶體，執行溢寫過程。Map task的輸出結果還可以往剩下的20MB記憶體中寫，互不影響。
• 當溢寫執行緒啟動後，需要對這80MB空間內的key做排序(Sort)。排序是MapReduce模型預設的行為!
  a. 如果job設定過Combiner，那麼現在就是使用Combiner的時候了。將有相同key的key/value對的 value加起來，減少溢寫到磁碟的資料量。Combiner會優化MapReduce的中間結果，所以它在整 個模型中會多次使用。
  b. 那哪些場景才能使用Combiner呢?從這裡分析，Combiner的輸出是Reducer的輸入，Combiner 絕不能改變最終的計算結果。Combiner只應該用於那種Reduce的輸入key/value與輸出key/value 型別完全一致，且不影響最終結果的場景。比如累加，最大值等。Combiner的使用一定得慎重， 如果用好，它對job執行效率有幫助，反之會影響reduce的最終結果。
• 合併溢寫檔案:每次溢寫會在磁碟上生成一個臨時檔案(寫之前判斷是否有combiner)，如果 map的輸出結果真的很大，有多次這樣的溢寫發生，磁碟上相應的就會有多個臨時檔案存在。當 整個資料處理結束之後開始對磁碟中的臨時檔案進行merge合併，因為最終的檔案只有一個，寫入 磁碟，並且為這個檔案提供了一個索引檔案，以記錄每個reduce對應資料的偏移量。

至此map整個階段結束!!

MapTask的一些配置

官方參考地址

https://hadoop.apache.org/docs/r2.9.2/hadoop-mapreduce-client/hadoop-mapreduce-client-core/mapred-default.xml

2.2 MapTask的並行度

MapTask並行度思考

MapTask的並行度決定Map階段的任務處理併發度，從而影響到整個Job的處理速度。

MapTask並行度決定機制

資料塊:Block是HDFS物理上把資料分成一塊一塊。

切片:資料切片只是在邏輯上對輸入進行分片，並不會在磁碟上將其切分成片進行儲存。

2.2.1 切片機制原始碼閱讀

預設就是128M;

MapTask並行度是不是越多越好呢?

答案不是，如果一個檔案僅僅比128M大一點點也被當成一個split來對待，而不是多個split.

MR框架在並行運算的同時也會消耗更多資源，並行度越高資源消耗也越高，假設129M檔案分為兩個分 片，一個是128M，一個是1M;

對於1M的切片的Maptask來說，太浪費資源。

129M的檔案在Hdfs儲存的時候會不會切成兩塊?

2.3 ReduceTask 工作機制

Reduce大致分為copy、sort、reduce三個階段，重點在前兩個階段。copy階段包含一個 eventFetcher來獲取已完成的map列表，由Fetcher執行緒去copy資料，在此過程中會啟動兩個merge線 程，分別為inMemoryMerger和onDiskMerger，分別將記憶體中的資料merge到磁碟和將磁碟中的資料 進行merge。待資料copy完成之後，copy階段就完成了，開始進行sort階段，sort階段主要是執行 finalMerge操作，純粹的sort階段，完成之後就是reduce階段，呼叫使用者定義的reduce函式進行處理。

詳細步驟

• Copy階段，簡單地拉取資料。Reduce程式啟動一些資料copy執行緒(Fetcher)，通過HTTP方式請求 maptask獲取屬於自己的檔案。
• Merge階段。這裡的merge如map端的merge動作，只是陣列中存放的是不同map端copy來的數 值。Copy過來的資料會先放入記憶體緩衝區中，這裡的緩衝區大小要比map端的更為靈活。merge 有三種形式:記憶體到記憶體;記憶體到磁碟;磁碟到磁碟。預設情況下第一種形式不啟用。當記憶體中的 資料量到達一定閾值，就啟動記憶體到磁碟的merge。與map 端類似，這也是溢寫的過程，這個過 程中如果你設定有Combiner，也是會啟用的，然後在磁碟中生成了眾多的溢寫檔案。第二種 merge方式一直在執行，直到沒有map端的資料時才結束，然後啟動第三種磁碟到磁碟的merge 方式生成最終的檔案。
• 合併排序。把分散的資料合併成一個大的資料後，還會再對合並後的資料排序。
• 對排序後的鍵值對呼叫reduce方法，鍵相等的鍵值對呼叫一次reduce方法，每次呼叫會產生零個 或者多個鍵值對，最後把這些輸出的鍵值對寫入到HDFS檔案中。

2.4 ReduceTask並行度

ReduceTask的並行度同樣影響整個Job的執行併發度和執行效率，但與MapTask的併發數由切片數決定
不同，ReduceTask數量的決定是可以直接手動設定:

// 預設值是1，手動設定為4 
job.setNumReduceTasks(4);

注意事項

• ReduceTask=0，表示沒有Reduce階段，輸出檔案數和MapTask數量保持一致;
• ReduceTask數量不設定預設就是一個，輸出檔案數量為1個;
• 如果資料分佈不均勻，可能在Reduce階段產生傾斜;

2.5 Shuffle機制

map階段處理的資料如何傳遞給reduce階段，是MapReduce框架中最關鍵的一個流程，這個流程就叫
shuffle。

shuffle: 洗牌、發牌——(核心機制:資料分割槽，排序，分組，combine，合併等過程)

四、YARN資源排程

1、Yarn架構

ResourceManager(rm):處理客戶端請求、啟動/監控ApplicationMaster、監控NodeManager、資 源分配與排程;

NodeManager(nm):單個節點上的資源管理、處理來自ResourceManager的命令、處理來自 ApplicationMaster的命令;

ApplicationMaster(am):資料切分、為應用程式申請資源，並分配給內部任務、任務監控與容錯。

Container:對任務執行環境的抽象，封裝了CPU、記憶體等多維資源以及環境變數、啟動命令等任務運
行相關的資訊。

2、Yarn任務提交(工作機制)

作業提交過程之YARN

• 作業提交
  第1步:Client呼叫job.waitForCompletion方法，向整個叢集提交MapReduce作業。
  第2步:Client向RM申請一個作業id。
  第3步:RM給Client返回該job資源的提交路徑和作業id。
  第4步:Client提交jar包、切片資訊和配置檔案到指定的資源提交路徑。
  第5步:Client提交完資源後，向RM申請執行MrAppMaster。
• 作業初始化
  第6步:當RM收到Client的請求後，將該job新增到容量排程器中。
  第7步:某一個空閒的NM領取到該Job。
  第8步:該NM建立Container，併產生MRAppmaster。
  第9步:下載Client提交的資源到本地。
• 任務分配
  第10步:MrAppMaster向RM申請執行多個MapTask任務資源。
  第11步:RM將執行MapTask任務分配給另外兩個NodeManager，另兩個NodeManager分 別領取任務並建立容器。
• 任務執行
  第12步:MR向兩個接收到任務的NodeManager傳送程式啟動指令碼，這兩個NodeManager 分別啟動MapTask，MapTask對資料分割槽排序。
  第13步:MrAppMaster等待所有MapTask執行完畢後，向RM申請容器，執行ReduceTask。
  第14步:ReduceTask向MapTask獲取相應分割槽的資料。
  第15步:程式執行完畢後，MR會向RM申請登出自己。
• 進度和狀態更新
  YARN中的任務將其進度和狀態返回給應用管理器, 客戶端每秒(通過 mapreduce.client.progressmonitor.pollinterval設定)嚮應用管理器請求進度更新, 展示給使用者。
• 作業完成
  除了嚮應用管理器請求作業進度外, 客戶端每5秒都會通過呼叫waitForCompletion()來檢查作 業是否完成。時間間隔可以通過mapreduce.client.completion.pollinterval來設定。作業完 成之後, 應用管理器和Container會清理工作狀態。作業的資訊會被作業歷史伺服器儲存以備 之後使用者核查。

3、 Yarn排程策略

Hadoop作業排程器主要有三種:FIFO、Capacity Scheduler和Fair Scheduler。Hadoop2.9.2預設的資源排程器是Capacity Scheduler。

3.1 FIFO(先進先出排程器)

3.2 容量排程器(Capacity Scheduler 預設的排程器)

Apache Hadoop預設使用的排程策略。Capacity 排程器允許多個組織共享整個叢集，每個組織可以獲得叢集的一部分計算能力。通過為每個組織分配專門的佇列，然後再為每個佇列分配一定的集 群資源，這樣整個叢集就可以通過設定多個佇列的方式給多個組織提供服務了。除此之外，佇列內 部又可以垂直劃分，這樣一個組織內部的多個成員就可以共享這個佇列資源了，在一個佇列內部， 資源的排程是採用的是先進先出(FIFO)策略。

3.3 Fair Scheduler(公平排程器，CDH版本的hadoop預設使用的排程器)

Fair排程器的設計目標是為所有的應用分配公平的資源(對公平的定義可以通過引數來設定)。公 平排程在也可以在多個佇列間工作。舉個例子，假設有兩個使用者A和B，他們分別擁有一個佇列。 當A啟動一個job而B沒有任務時，A會獲得全部叢集資源;當B啟動一個job後，A的job會繼續運 行，不過一會兒之後兩個任務會各自獲得一半的叢集資源。如果此時B再啟動第二個job並且其它 job還在執行，則它將會和B的第一個job共享B這個佇列的資源，也就是B的兩個job會用於四分之 一的叢集資源，而A的job仍然用於叢集一半的資源，結果就是資源最終在兩個使用者之間平等的共享。

3.4 Yarn多租戶資源隔離配置

Yarn叢集資源設定為A,B兩個佇列，

• A佇列設定佔用資源70%主要用來執行常規的定時任務，
• B佇列設定佔用資源30%主要執行臨時任務，
• 兩個佇列間可相互資源共享，假如A佇列資源佔滿，B佇列資源比較充裕，A佇列可以使用B佇列的 資源，使總體做到資源利用最大化.

3.5 選擇使用Fair Scheduler排程策略

3.5.1 yarn-site.xml

<!-- 指定我們的任務排程使用fairScheduler的排程方式 --> 
<property>
	<name>yarn.resourcemanager.scheduler.class</name>
	<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairSch eduler</value>
    <description>In case you do not want to use the default scheduler</description>
</property>

3.5.2 建立fair-scheduler.xml檔案

在Hadoop安裝目錄/etc/hadoop建立該檔案

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<allocations>
    <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
    <queue name="root" >
        <queue name="default">
            <aclAdministerApps>*</aclAdministerApps>
            <aclSubmitApps>*</aclSubmitApps>
            <maxResources>9216 mb,4 vcores</maxResources>
            <maxRunningApps>100</maxRunningApps>
            <minResources>1024 mb,1vcores</minResources>
            <minSharePreemptionTimeout>1000</minSharePreemptionTimeout>
            <schedulingPolicy>fair</schedulingPolicy>
            <weight>7</weight>
        </queue>
        <queue name="queue1">
            <aclAdministerApps>*</aclAdministerApps>
            <aclSubmitApps>*</aclSubmitApps>
            <maxResources>4096 mb,4vcores</maxResources>
            <maxRunningApps>5</maxRunningApps>
            <minResources>1024 mb, 1vcores</minResources>
            <minSharePreemptionTimeout>1000</minSharePreemptionTimeout>
            <schedulingPolicy>fair</schedulingPolicy>
            <weight>3</weight>
         </queue>
    </queue>
    <queuePlacementPolicy>
        <rule create="false" name="specified"/>
        <rule create="true" name="default"/>
    </queuePlacementPolicy>
</allocations>

3.5.3 介面驗證