metaq的基本概念術語

概念和術語 Meta的概念和術語介紹

消息生產者 也稱爲Message Producer，通常簡稱爲producer，負責產生消息併發送消息到meta服務器。

消息消費者 也稱爲Message Consumer，通常簡稱爲consumer，負責消息的消費，meta採用pull模型，由消費者主動從meta服務器拉取數據並解析成消息並消費。

Topic 消息的主題，由用戶定義並在服務端配置。producer發送消息到某個topic下，consumer從某個topic下消費消息。

分區(partition) 同一個topic下面還分爲多個分區，如meta-test這個topic咱們能夠分爲10個分區，分別有兩臺服務器提供，那麼可能每臺服務器提供5個分區，假設服務器id分別爲0和1，則全部分區爲0-0、0-一、0-二、0-三、0-四、1-0、1-一、1-二、1-三、1-4。

分區跟消費者的負載均衡機制有很大關係，具體見集羣和負載均衡。

Message 消息，負載用戶數據並在生產者、服務端和消費者之間傳輸。

Broker 就是meta的服務端或者說服務器，在消息中間件中也一般稱爲broker。

消費者分組(Group) 消費者能夠是多個消費者共同消費一個topic下的消息，每一個消費者消費部分消息。這些消費者就組成一個分組，擁有同一個分組名稱,一般也稱爲消費者集羣

Offset 消息在broker上的每一個分區都是組織成一個文件列表，消費者拉取數據須要知道數據在文件中的偏移量，這個偏移量就是所謂offset。Offset是絕對偏移量，服務器會將offset轉化爲具體文件的相對偏移量。詳細內容參見#消息的存儲結構

同組和不一樣組：是指10個consumer是否同一個分組，若是是同一個分組則共同分擔消費同一個topic;不然，每一個consumer完整消費該topic。通俗地說，同組就是一條消息只會被分組內一個consumer消費，不一樣組，則一條消息會被每一個consumer消費。

數據可靠性參數 Meta保證消息可靠性是創建在磁盤可靠性的基礎上，發送的每一條消息都保證是在「寫入磁盤」的狀況下才返回給客戶端應答。這裏有兩個關鍵參數能夠控制：

數據刪除策略配置 默認狀況下，meta是會保存不斷添加的消息，而後按期對「過時」的數據進行刪除或者歸檔處理，這都是經過下列參數控制的： deleteWhen: 什麼時候執行刪除策略的cron表達式，默認是0 0 6,18 * * ?，也就是天天的遲早6點執行處理策略。 deletePolicy: 數據刪除策略，默認超過7天即刪除,這裏的168是小時，10s表示10秒，10m表示10分鐘，10h表示10小時，不明確指定單位默認爲小時。delete是指刪除，超過指定時間的數據文件將被完全從磁盤刪除。也能夠選擇archive策略，即不對過時的數據文件作刪除而是歸檔，當使用archive策略的時候能夠選擇是否壓縮數據文件，如167,archive,true即選擇將更改時間超過7天的數據文件歸檔並壓縮爲zip文件，若是不選擇壓縮，則重命名爲擴展名爲arc的文件。 上述兩個參數均可以被topic單獨配置所覆蓋，也就是每一個topic能夠指定本身獨特的刪除策略。一般來講，對於不重要的topic能夠將更早地將他們刪除來節省磁盤空間。

zookeeper配置 meta服務端會將自身id,topic信息和socket地址發送到zookeeper上，讓客戶端能夠發現並鏈接服務器。Zookeeper相關的配置放在[zookeeper]模塊下面: zk.zkEnable: 是否啓用zookeeper，也就是是否將信息註冊到zookeeper上。默認爲true。對於同步複製的slave來講，本參數會被強制設置爲false。 zk.zkConnect: zookeeper服務器列表，例如localhost:1281這樣的字符串。默認也是localhost:2181。請設置你的zk集羣地址列表。 zk.zkSessionTimeoutMs: zookeeper的session timeout，默認爲30秒。單位毫秒。 zk.zkConnectionTimeoutMs： zookeeper的鏈接超時時間，默認一樣爲30秒，單位毫秒。 zk.zkSyncTimeMs: 預期的zk集羣間數據同步延遲，默認爲5秒，這個參數對服務器無心義。

新增Topic熱部署 在新增或者刪除topic並保存server.ini以後，能夠經過下列命令熱加載新的配置文件並生效： bin/metaServer.sh reload

Meta相比於kafka的一個重要特性就是消息高可用方案的實現，咱們稱之爲HA方案。消息在發送到broker以後當即寫入磁盤才返回客戶端告訴消息生產者消息發送成功，經過unflushThreshold和unflushInterval兩個參數的控制，能夠保證單機消息數據的安全性，只要機器的磁盤沒有永久損壞，消息總能夠在重啓後恢復並正常投遞給消費者們。可是，若是遇到了磁盤永久損壞或者數據文件永久損壞的狀況，那麼該broker上的消息數據將可能永久丟失。爲了防止這種狀況的發生，一個可行的方案就是將消息數據複製到多臺機器，相似mysql的主從複製功能。

採用pull模型，消息的實時性有保證嗎？ Metamorphosis在消費端採用pull的模型，consumer主動去broker拉取數據，而不是相似大多數MQ那樣由broker主動push數據給消費者。可能不少人擔憂採用pull模型後，會不會消息的實時性下降了，從發送到消費的整個時間週期拉長了。 實際上，meta中消息的實時性受不少因素影響，不能簡單地說實時性必定會下降，主要影響因素以下 broker上配置的批量force消息的閾值，默認是1000條force一次。這個值越大，則實時性越低。 消費者每次抓取的數據大小，這個值越大，則實時性越低，可是吞吐量越高。 Topic的分區數目對實時性也有較大影響，分區數目越多，則磁盤壓力越大，致使消息投遞的實時性下降。 消費者重試抓取的時間間隔，越長則延遲越嚴重。 消費者抓取數據的線程數 可見，消息實時性在meta裏受到不少因素的影響，meta可讓用戶本身決定如何在響應性和吞吐量之間作平衡，經過配置來合理設置參數，達到應用方須要的實時性，實際測試，消息消費的延遲能夠在幾毫秒到幾秒之間。