MetaQ Log4j及服務器配置管理

1、使用Log4j擴展發送消息

        Metaq還支持log4j發送消息，經過log4j寫入的任何日誌信息都將以消息的方式發送到Metaq的Broker服務器，只要經過簡單的配置就能夠。

        

若是要用到log4j擴展，你須要使用client-extenstion的包：

<dependency>
     <groupId>com.taobao.metamorphosis</groupId>
     <artifactId>metamorphosis-client-extension</artifactId>
     <version>1.4.4</version>
 </dependency>

配置log4j.properties

log4j.logger.testLog=info, testMessage
 log4j.additivity.testMessage=false
 log4j.appender.testMessage=com.taobao.metamorphosis.client.extension.log4j.StreamAppender
 log4j.appender.testMessage.topic=meta-test
 log4j.appender.testMessage.zkConnect=127.0.0.1:2181
 log4j.appender.testMessage.EncodeType=1
 log4j.appender.testMessage.BufferedIO=true
 log4j.appender.testMessage.DatePattern='.'yyyy-MM-dd_HH
 log4j.appender.testMessage.File=../../logs/test.log
 log4j.appender.testMessage.layout=org.apache.log4j.PatternLayout
 log4j.appender.testMessage.layout.ConversionPattern=%d{MM-dd HH:mm:ss} - %m%n

        最重要的三個參數就是｀appender、topic和zkConnect`，分別指定使用metaq擴展的log4j appender，設定metaq發送消息的topic以及zookeeper的服務器地址列表。其餘log4j相關的參數只是爲了提供給log4j，防止錯誤的產生，不會產生做用。

        

        在Java代碼裏使用就很簡單了：

static final Log log = LogFactory.getLog("testLog");
log.info("just a test");

默認日誌將使用Java序列化成byte[]併發送，這能夠經過EncodeType控制，0表示Java序列化,1表示hessian1序列化。

Java客戶端API文檔(JavaDoc)

http://fnil.net/docs/metaq/index.html

2、服務器配置管理

        一、 腳本配置

        MetaQ主要經過bin/env.sh或者bin/env.bat腳原本配置一些環境變量，如JVM啓動參數等，詳述以下。

        JMX端口：        

        首先，MetaQ服務端默認會暴露一個JMX端口，你能夠經過API或者jconsole這樣的工具連接上這個端口查看信息或者修改參數等，默認端口是export JMX_PORT=9123。若是你在同一臺機器部署多個Broker，須要修改此參數，防止衝突。

        設置JVM參數：

        首先是可配置JAVA_HOME:

# your java home
#optjdk

        默認咱們經過which java獲取java命令所在路徑，可是若是你取消註釋，配置了JAVA_HOME（或者你的環境變量設置了JAVA_HOME），咱們都將優先使用$JAVA_HOME/bin/java命令。

        服務器的默認JVM啓動參數是：

BROKER_JVM_ARGS="-Xmx512m -Xms512m -server -Dmeta.home=$meta_home -cp $CLASSPATH "

        你能夠修改這個參數，好比增大Xmx堆空間，增長GC參數，一個示範性的配置：

BROKER_JVM_ARGS="-Xms4096m -Xmx4096m -Xmn512m -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=50 -XX:+CMSParallelRemarkEnabled -server -Dmeta.home=$meta_home -cp $CLASSPATH "

        

        啓動HTTP接口

        MetaQ提供了一套HTTP接口，可讓客戶端直接經過HTTP接口來發送或者消費消息，默認不啓用。

啓用HTTP接口，修改env.sh裏的export enableHttp=true便可。

默認HTTP接口的端口是經過conf/jettyBroker.properties配置的：

serverPort

你能夠修改這個端口。

經過HTTP接口發送和消費消息，請看metamorphosis-http-client中的例子。

        二、Broker參數配置

            完整的參數配置示例：

;
;   Metamorphosis服務器的參數配置文件 2.0 版本
;   有疑問請聯繫我 killme2008@gmail.com（伯巖）
;
;系統屬性
[system]
;必須，服務器惟一標誌
brokerId=0
;服務器hostname，能夠爲空，默認將取本機IP
hostName=
;默認每一個topic的分區數目，默認爲1
numPartitions=1
;服務器端口，必須
serverPort=8123
;管理平臺HTTP端口，必須
dashboardHttpPort=8120
;數據文件路徑，默認在user.home/meta下
dataPath=
;日誌數據文件路徑，默認跟dataPath同樣
dataLogPath=
;是否啓用並行記載數據，當數據過多的時候，啓用此選項可加快啓動速度，
;可是會打亂啓動的日誌順序，默認不啓用。
loadMessageStoresInParallel=false
;最大容許的未flush消息數，超過此值將強制force到磁盤，默認1000
unflushThreshold=1000
;最大容許的未flush間隔時間，毫秒，默認10秒
unflushInterval=10000
;單個文件的最大大小,實際會超過此值，默認1G
maxSegmentSize=1073741824
;傳輸給客戶端每次最大的緩衝區大小，默認1M
maxTransferSize=1048576
;處理get請求的線程數,默認cpus*10
getProcessThreadCount=80
;處理put請求線程數，默認cpus*10
putProcessThreadCount=80
;數據刪除策略，默認超過7天即刪除,這裏的168是小時，10s表示10秒，10m表示10分鐘，10h表示10小時，默認爲小時
deletePolicy=delete,168
;刪除策略的執行時間，cron表達式
deleteWhen=0 0 6,18 * * ?
;事務相關配置
;最大保存事務checkpoint數目，默認爲3
maxCheckpoints=3
;事務checkpoint時間間隔，單位毫秒，默認1小時
checkpointInterval=3600000
;最大事務超時事件數，用於監控事務超時
maxTxTimeoutTimerCapacity=30000
;最大事務超時時間，單位秒
maxTxTimeoutInSeconds=60
;事務日誌的刷盤設置，0表示讓操做系統決定，1表示每次commit都刷盤，2表示每隔1秒刷盤一次
flushTxLogAtCommit=1
;是否接收消息，默認爲true，可被topic配置覆蓋
acceptPublish=true
;是否接受訂閱，默認爲true，可被topic配置覆蓋
acceptSubscribe=true
;;當消費者的offset不在Broker的數據範圍內，則強制更新消費者的offset爲當前最大offset。
;;在生產環境，請設置此選項爲false，默認爲false
;;在開發和測試環境，建議設置爲true，由於開發測試的時候，可能要常常刪除消息數據，此選項可以讓消費者自動糾正offset。
updateConsumerOffsets=false
;;是否啓用實時統計，針對每一個topic作實時的流量統計，可被topic配置覆蓋。
stat=true
;zk配置
[zookeeper]
;是否註冊到zk，默認爲true
zk.zkEnable=true
;如下爲zk配置，不能夠爲空
;zk的服務器列表
zk.zkConnect=localhost:2181
;zk心跳超時，單位毫秒，默認30秒
zk.zkSessionTimeoutMs=30000
;zk鏈接超時時間，單位毫秒，默認30秒
zk.zkConnectionTimeoutMs=30000
;zk數據同步時間，單位毫秒，默認5秒
zk.zkSyncTimeMs=5000
;topic列表
[topic=test]
;是否啓用統計，覆蓋系統配置，若是沒有配置，則使用全局的系統配置
stat=true
;這個topic指定分區數目，若是沒有設置，則使用系統設置
numPartitions=10
;topic的刪除策略，默認使用系統策略
deletePolicy=
unflushInterval=
unflushThreshold=
;刪除策略的執行時間，cron表達式
deleteWhen=0 0 6,18 * * ?

        服務端配置

        Meta服務端配置主要在服務器conf目錄下的server.ini文件，總體配置分爲三部分：系統參數、zookeeper參數以及topic配置。系統參數在system section，zookeeper參數配置在zookeeper section，而topic的配置是在topic=xxxx section。具體說明以下：

一份默認提供的參數配置在這裏。

系統參數部分

系統參數配置都放在[system]下面：

• brokerId: 服務器集羣中惟一的id，必須爲整型0-1024之間。對服務器集羣的定義是使用同一個zookeeper而且在zookeeper上的root path相同，具體參見zookeeper配置。

• hostName: 服務器hostname，默認取本機IP地址，若是你是多網卡機器，可能須要明確指定。服務器會將此hostname加上端口寫入到zookeeper提供給客戶端發現。

• serverPort:服務器端口，默認8123。PS. 選擇8123是由於這蘊含着我兒子的生日 :D。

• numPartitions:系統默認狀況下每一個topic的分區數目，默認爲1，可被topic配置覆蓋。單個服務器的總分區數目不建議超過1000，太多將致使頻繁的磁盤尋道嚴重影響IO性能。

• dataPath: 服務器數據文件路徑，默認在~home/meta下,每一個topic能夠覆蓋此配置，對於多塊磁盤的機器，可設置不一樣topic到不一樣磁盤來提高IO效率。

• dataLogPath：數據日誌文件路徑，主要存放事務日誌，默認跟dataPath一致，最好單獨設置到不一樣的磁盤或者目錄上。若是爲空，使用指定的dataPath

• getProcessThreadCount: 處理get請求的併發線程數，默認爲CPUS*10。

• putProcessThreadCount: 處理put請求的併發線程數，默認爲CPUS*10。

• maxSegmentSize: 單個數據文件的大小，默認爲1G。默認無需修改此選項。

• maxTransferSize: 傳輸給消費者的最大數據大小，默認爲1M，請根據你的最大消息大小酌情設置，若是過小，每次沒法傳輸一個完整的消息給消費者，致使消費者消費停滯。可設置成一個大數來取消限制。

1.4.3版本引入的參數：

• acceptPublish: 是否接收消息，默認爲true；若是爲false，則不會註冊發送信息到zookeeper上，客戶端固然沒法發送消息到該broker。本參數能夠被後續的topic配置覆蓋。

• acceptSubscribe: 與acceptPublish相似，默認也爲true；若是爲false，則不會註冊消費信息到zookeeper上，消費者沒法發現該broker，固然沒法從該broker消費消息。本參數能夠被後續的topic配置覆蓋。

1.4.4版本新引入參數：

• stat：全局性地控制是否開啓實時統計，可被topic配置覆蓋，默認爲false。

• loadMessageStoresInParallel: 是否啓動時並行加載數據，開啓可提高啓動速度。默認不開啓。開啓後啓動日誌順序可能紊亂。

• updateConsumerOffsets: 當消費者的offset不在Broker的數據範圍內，是否強制更新消費者的offset爲當前最大offset。默認爲false。測試開發環境建議開啓此選項，生產環境不建議。

數據可靠性參數

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

• unflushThreshold: 每隔多少條消息作一次磁盤sync，強制將更改的數據刷入磁盤。默認爲1000。也就是說在掉電狀況下，最多容許丟失1000條消息。可設置爲0，強制每次寫入都sync。在設置爲0的狀況下，服務器會自動啓用group commit技術，將多個消息合併成一次sync來提高IO性能。通過測試，group commit狀況下消息發送者的TPS沒有受到太大影響，可是服務端的負載會上升不少。

• unflushInterval: 間隔多少毫秒按期作一次磁盤sync,默認是10秒。也就是說在服務器掉電狀況下，最多丟失10秒內發送過來的消息。不可設置爲小於或者等於0。

請注意，上述兩個參數均可以被topic單獨配置說覆蓋，也就是說每一個topic能夠配置不一樣的數據可靠級別。

當某個topic開啓group commit後，將爲每一個分區配置一個線程作彙集force，所以請控制啓用group commit技術的topic數量，太多可能致使過多線程，反而效率降低。

數據刪除策略配置

默認狀況下，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能夠將更早地將他們刪除來節省磁盤空間。

事務相關配置

• maxCheckpoints: 最大保存事務checkpoint數目，默認爲3，服務器在啓動的時候會從最近一次checkpoint回訪事務日誌文件，恢復重啓前的事務狀態。不建議修改此參數。

• checkpointInterval：事務checkpoint時間間隔，單位毫秒，默認1小時。間隔時間太長，會致使啓動的時候replay事務日誌佔用了太多時間，過短則可能影響到性能。

• maxTxTimeoutTimerCapacity：最大事務超時timer的數量。服務端會爲每一個事務啓動一個定時器監控事務是否超時，定時器的數目上限經過本參數限制。限制了本參數，也變相地控制了最大可運行的事務數。默認爲30000個。

• maxTxTimeoutInSeconds：最大事務超時時間，單位爲秒，默認爲60秒。客戶端設置的事務超時時間不能超過此設定，超過將被強制限制爲此設定。

• flushTxLogAtCommit：服務端對事務日誌的sync策略，0表示讓操做系統決定，1表示每次commit都刷盤，2表示每隔1秒刷盤一次。此參數嚴重影響事務性能，可根據你須要的性能和可靠性之間權衡作出一個合理的選擇。一般建議設置爲2，表示每隔1秒刷盤一次，也就是最多丟失一秒內的運行時事務。這樣的可靠級別對大多數服務是足夠的。最安全的固然是設置爲1，可是將嚴重影響事務性能。而0的安全級別最低。安全級別上 1>=2>0，而性能則是0 >= 2 > 1。

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服務都是經過topic配置來實現的，topic配置都是在[topic=xxx]的模塊下面，其中xxx就是topic名稱，一個示範配置以下：

[topic=boyan-test]
stat=true
numPartitions=1

這裏配置了一個名爲test的topic，並針對該topic啓用實時統計，並將topic的在本服務器的分區數目設置爲1。可見，topic配置可覆蓋服務器的部分配置，包括：

• stat:是否啓用實時統計，啓用則會在服務端對該topic的請求作實時統計，能夠經過stats topic-name協議觀察到該topic運行情況，可選。

• numPartitions: 該topic在本服務器的分區總數，覆蓋系統配置，可選。

• unflushInterval：每隔多少條消息作一次磁盤sync，覆蓋系統配置，可選。

• unflushThreshold：每隔多少秒作一次磁盤sync，覆蓋系統配置，可選。

• deletePolicy：topic的刪除策略，覆蓋系統配置，可選。

• deleteWhen：刪除策略的執行時間，覆蓋系統配置，可選。

• dataPath：設置數據文件路徑，覆蓋系統配置，可選。

1.4.3新增參數：

• acceptPublish: 是否接收該topic的消息，覆蓋系統配置，可選。

• acceptSubscribe: 是否接受消費者的訂閱，覆蓋系統配置，可選。

新增Topic熱部署

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

bin/metaServer.sh reload