• 7-rocketmq-borker配置文件


    #broker集群名称,用于划分broker
    brokerClusterName=MQCluster001
    #broker名称,用于主从配对,相同名称的broker才能做主从设置
    brokerName=mq_broker_1
    #用于标识主从关系,0为主,其他大于0的为从(不能小于0)master设置0,slave设置1。Master角色的Broker支持读和写,Slave角色的Broker仅支持读,也就是Producer只能和Master角色的Broker连接写人消息:Consumer可以连接Master角色的Broker,也可以连接Slave角色的Broker来读取消息。
    #Master节点设置
    brokerId=0
    #Slave节点设置
    #brokerId=1
    #name server服务器地址及端口,可以是多个,分号隔开
    namesrvAddr=192.168.1.100:9876
    #创建topic时,若未指定topic下的队列数,则取该默认值作为默认队列数
    defaultTopicQueueNums=8
    #是否自动创建默认topic,生产需保持关闭
    autoCreateTopicEnable=true
    #是否自动创建topic的订阅组,默认开启
    autoCreateSubscriptionGroup=true
    #broker服务监听端口
    listenPort=10911
    #未消费的持久化消息清理时间点
    deleteWhen=04
    #持久化消息保存周期(单位:小时),超过该周期将被清理
    fileReservedTime=24
    #单个commitLog文件的大小限制(单位:字节)
    mapedFileSizeCommitLog=1073741824
    #单个consumeQueue大小限制(存储的消息条数 * 每条消息的索引大小20)
    mapedFileSizeConsumeQueue=8000000
    #存储使用率阀值,当使用率超过阀值时,将拒绝发送消息请求
    diskMaxUsedSpaceRatio=88
    #持久化消息存储根路径
    storePathRootDir=/data/store
    #commitLog文件存储路径
    storePathCommitLog=/data/store/commitlog
    #最大消息大小限制(单位:字节)
    maxMessageSize=65536
    #commitLog最少刷盘page数
    flushCommitLogLeastPages=4
    #consumeQueue最少刷盘page数
    flushConsumeQueueLeastPages=2
    #commitLog刷盘间隔时间
    flushCommitLogThoroughInterval=10000
    #consumeQueue刷盘间隔时间
    flushConsumeQueueThoroughInterval=60000
    #处理消息发送线程池大小
    sendMessageThreadPoolNums=128
    #处理消息拉取线程池大小
    pullMessageThreadPoolNums=128
    #broker角色(SYNC_MASTER:同步双写Master、ASYNC_MASTER:异步复制Master、SLAVE:Slave)
    brokerRole=ASYNC_MASTER
    #Slave节点设置
    #brokerRole=SLAVE
    #刷盘方式(ASYNC_FLUSH:异步刷盘、SYNC_FLUSH:同步刷盘)
    flushDiskType=ASYNC_FLUSH
    

    刷盘方式与同步方式(以上flushDiskType配置)
    异步刷盘方式:在返回写成功状态时,消息可能只是被写人了内存的PAGECACHE ,写操作的返回快,吞吐量大;当内存里的消息量积累到一定程度时,统一触发写磁盘动作,快速写人。
    同步刷盘方式:在返回写成功状态时,消息已经被写入了磁盘。具体流程是,消息、写入内存的PAGECACHE 后,立刻通知刷盘线程刷盘,然后等待刷盘成,刷盘线程执行完成后唤醒等待的线程,返回消息写成功的状态。

    broker的同步于异步复制(以上brokerRole配置)
    同步复制:
    同步复制是等Master和Slave均成功写成功后才反馈给客户端写成功状态。
    如果Master出故障,Slave上有全部的备份数据,容易恢复,但是同步复制会增大数据写人延迟,降低系统吞吐量。
    异步复制:
    只要是Master写成功后即返回客户端写成功状态。
    系统拥有较低的延迟和较高的吞吐量,但是如果Master出了故障,有些数据因为没有被写人Slave ,有可能会丢失

    通常情况下,应该把Master和Save配置成ASYNC FLUSH的刷盘方式,主从之间配置成SYNC MASTER的复制方式,这样即使有一台机器出故障,仍然能保证数据不丢,是个不错的选择。

  • 相关阅读:
    可视化数据挖掘开源软件的比较分析
    大数据平台比较-CDH,HDP
    数据挖掘的一般过程
    httpclient介绍与请求方式详解
    30分钟带你了解阻塞队列所有内容,再也不怕面试官刁难你了!(上)
    Lock
    HashMap 源码解读
    类加载各阶段详解
    Java基础复习(八、注解)
    Java基础复习(六、反射)
  • 原文地址:https://www.cnblogs.com/zh-ch/p/14248790.html
Copyright © 2020-2023  润新知