MetaQ Log4j及服务器配置管理

时间  2019-12-25
标签 metaq log4j log 服务器 配置 管理 栏目 Log4j 繁體版
原文   原文链接

1、使用Log4j扩展发送消息

        Metaq还支持log4j发送消息，经过log4j写入的任何日志信息都将以消息的方式发送到Metaq的Broker服务器，只要经过简单的配置就能够。html

        

若是要用到log4j扩展，你须要使用client-extenstion的包：java

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

配置log4j.propertiesgit

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，防止错误的产生，不会产生做用。github

        

        在Java代码里使用就很简单了：web

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

默认日志将使用Java序列化成byte[]并发送，这能够经过EncodeType控制，0表示Java序列化,1表示hessian1序列化。apache


Java客户端API文档(JavaDoc)安全

http://fnil.net/docs/metaq/index.html服务器

2、服务器配置管理

        一、 脚本配置

        MetaQ主要经过bin/env.sh或者bin/env.bat脚原本配置一些环境变量，如JVM启动参数等，详述以下。session

        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
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程