Producer 最佳实践
- 一个应用尽可能用一个Topic,消息子类型用tags来标识,tags可以由应用自由设置
只有发送消息设置了tags,消费方在订阅消息时,才可以利用tags在broker做消息过滤
message.setTags("TagA");
- 每个消息在业务层面的唯一标识码,要设置到keys字段,方便将来定位消息丢失问题
服务器会为每个消息创建索引(哈希索引),应用可以通过topic,key来查询这条消息内容,以及消息被谁消费
由于是哈希索引,请务必保证key尽可能唯一,这样可以避免潜在的哈希冲突
//订单ID
String orderId = "1250689524981";
message.setKeys(orderId);
- 如有可靠性需要,消息发送成功或者失败,要打印消息日志(sendresult和key信息)
- 如果相同性质的消息量大,使用批量消息,可以提升性能
- 建议消息大小不超过512KB
- send(msg)会阻塞,如果有性能要求,可以使用异步的方式:send(msg,callback)
- 如果在一个JVM中,有多个生产者进行大数据处理,建议:
- 少数生产者使用异步发送方式(3~5个就够了)
- 通过setInstanceName方法,给每个生产者设置一个实例名
- send消息方法,只要不抛异常,就代表发送成功。但是发送成功会有多个状态,在sendResult里定义
SEND_OK
:消息发送成功FLUSH_DISK_TIMEOUT
:消息发送成功,但是服务器刷盘超时,消息已经进入服务器队列,只有此时服务器宕机,消息才会消失FLUSH_SLAVE_TIMEOUT
:消息发送成功,但是服务器同步到Slave时超时,消息已经进入服务器队列,只有此时服务器宕机,消息才会丢失SLAVE_NOT_AVAILABLE
:消息发送成功,但是此时slave不可用,消息已经进入服务器队列,只有此时服务器宕机,消息才会丢失- 如果状态是
FLUSH_DISK_TIMEOUT
或FLUSH_SLAVE_TIMEOUT
,并且Broker正好关闭,此时,可以丢弃这条消息,或者重发。但建议最好重发,由消费端去重 - Producer向Broker发送请求会等待响应,但如果达到最大等待时间,未得到响应,则客户端将抛出
RemotingTimeoutException
- 默认等待时间是3秒,如果使用
send(msg,timeout)
,则可以自己设定超时时间,但超时时间不能设置太小,因为Broker需要一些时间来刷新磁盘或与从属设备同步 - 如果该值超过
syncFlushTimeout
,则该值可能影响不大,因为Broker可能会在超时之前返回FLUSH_DISK_TIMEOUT
或FLUSH_SLAVE_TIMEOUT
的响应
- 对于消息不可丢失应用,务必要有消息重发机制
producer的send方法本身支持内部重试:
一、至多重试3次
二、如果发送失败,则轮转到下一个Broker
三、这个方法的总耗时时间不超过sendMsgTimeout设置的值,默认10s。所以,如果本身想broker发送消息产生超时异常,就不会再做重试
以上策略任然不能保证消息一定发送成功,为保证消息一定成功,建议将消息存储到db,由后台线程定时重试,保证消息一定到达broker
1.1、安装rocketmq可视化管理
1、直接下载https://github.com/apache/rocketmq-externals的rocketmq-console-1.0.0分支的zip包(这样快一些)
2、编译为jar(我用的是Idea的maven进行打包,打包有点儿慢)
3、启动(直接在jar包路径下执行如下命令)
# jar包在target目录下面,你可以放在一台服务器上面运行
java -jar rocketmq-console-ng-1.0.0.jar --server.port=8081 --rocketmq.config.namesrvAddr=192.168.0.32:9876
# --server.port springboot内置tomcat的端口号,默认8080;
# --rocketmq.config.namesrvAddr nameserver的地址
4、启动后访问http://127.0.0.1:8081
官网使用文档(中文):https://github.com/apache/rocketmq-externals/blob/master/rocketmq-console/doc/1_0_0/UserGuide_CN.md
最佳实践之Consumer
2.1、消费者组和订阅
不同的消费群体可以独立地消费同样的主题,并且每个消费者都有自己的消费偏移量(offsets)。
确保同一组中的每个消费者订阅相同的主题
3、消息监听器(MessageListener)
3.1、顺序(Orderly)
消费者将锁定每个MessageQueue,以确保每个消息被一个按顺序使用。这将导致性能损失。
如果关心消息的顺序时,它就很有用了。不建议抛出异常,可以返回
ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT
代替
3.2、消费状况(Consume Status)
对于MessageListenerConcurrently
,可以返回RECONSUME_LATER
告诉消费者,当前不能消费它并且希望以后重新消费。
然后可以继续使用其他消息。对于MessageListenerOrderly
,如果关心顺序,就不能跳过消息,可以返回SUSPEND_CURRENT_QUEUE_A_MOMENT
来告诉消费者等待片刻。
1、当MessageExt出现异常时,会由当前topic变为RETRY
topic(假设当前topic名称为topic_test,就会变为RETRY
topic_test)
2、retry
topic这个就是延时topic,也就是将这个非延时消息变为延时消息,延时时间就根据level从第一次第一级,不断的往上加
3.3、阻塞(Blocking)
不建议阻塞Listener,因为他会阻塞线程池,最终可能会停止消费程序。
3.4、线程数
消费者使用一个ThreadPoolExecutor来处理内部的消费,因此可以通过设置setConsumeThreadMin或setConsumeThreadMax来更改它。
3.5、从何处开始消费
1、当建立一个新的Consumer Group时,需要决定是否需要消费Broker中已经存在的历史消息。
2、CONSUME_FROM_LAST_OFFSET将忽略历史消息,并消费此后生成的任何内容。
3、CONSUME_FROM_FIRST_OFFSET将消耗Broker中存在的所有消息。还可以使用CONSUME_FROM_TIMESTAMP来消费在指定的时间戳之后生成的消息。
参考代码:手动pull【E:\meWork\study\project\subject-2\subject-2-mq\rocketmq-demo1\src\main\java\com\study\rocketmq\a151_simple\PullConsumer.java】
3.6、重复
RocketMQ无法避免消息重复,如果业务对重复消息非常敏感,务必在业务层面做去重:
1、通过记录消息唯一键进行去重
2、使用业务层面的状态机制去重
4、最佳实践之NameServer
在Apache RocketMQ中,NameServer用于协调分布式系统的每个组件,主要通过管理主题路由信息来实现协调。
管理由两部分组成:
1、Brokers定期更新保存在每个名称服务器中的元数据。
2、名称服务器是为客户端提供最新的路由信息服务的,包括生产者、消费者和命令行客户端。
因此,在启动brokers和clients之前,我们需要告诉他们如何通过给他们提供的一个名称服务器地址列表来访问名称服务器。在Apache RocketMQ中,可以用四种方式完成。
4.1 四种配置namesrvAddr的方式
1、编程方式
1. 对于brokers,我们可以在broker的配置文件中指定
namesrvAddr=name-server-ip1:port;name-server-ip2:port
2. 对于生产者和消费者,我们可以给他们提供姓名服务器地址列表如下:
DefaultMQProducer producer=new DefaultMQProducer("please_rename_unique_group_name");
producer.setNamesrvAddr("name-server-ip1:port;name-server-ip2:port");
DefaultMQPushConsumer consumer=new DefaultMQPushConsumer("please_rename_unique_group_name");
consumer.setNamesrvAddr("name-server-ip1:port;name-server-ip2:port");
-
如果从shell中使用管理命令行,也可以这样指定:
sh mqadmin command-name-n name-server-ip1:port;name-server-ip2:port -X OTHER-OPTION
-
如果将管理工具集成到自己的项目中,可以这样
DefaultMQAdminExt defaultMQAdminExt = new DefaultMQAdminExt("please_rename_unique_group_name"); defaultMQAdminExt.setNamesrvAddr("name-server-ip1:port;name-server-ip2:port");
一个简单的例子,在NameServer节点上查询集群信息:
sh mqadmin -n localhost:9876 clusterList
2. Java参数
NameServer的地址列表也可以通过java参数rocketmq.namesrv.addr
,在启动之前指定
3. 环境变量
可以设置NAMESRV_ADDR环境变量。如果设置了,Broker和clients将检查并使用其值
4. HTTP端点(HTTP Endpoint)
如果没有使用前面提到的方法指定NameServer地址列表,Apache RocketMQ将每2分钟发送一次HTTP请求,以获取和更新NameServer地址列表,初始延迟10秒。
默认情况下,访问的HTTP地址是:http://jmenv.tbsite.net:8080/rocketmq/nsaddr
通过java参数rocketmq.namesrv.domain
,可以修改jmenv.tbsite.net
通过java参数rocketmq.namesrv.domain.subgroup,
可以修改nsaddr这4中方式的优先级:
编程方式 > Java参数 > 环境变量 > HTTP方式
5.JVM与Linux内核配置
5.1. JVM配置
1、推荐使用最新发布的JDK1.8版本,使用服务器编译器和8g堆。
2、设置相同的Xms和Xmx值,以防止JVM调整堆大小以获得更好的性能。简单的JVM配置如下所示:
-server -Xms8g -Xmx8g -Xmn4g
3、如果不关心Broker的启动时间,可以预先触摸Java堆,以确保在JVM初始化期间分配页是更好的选择。
-XX:+AlwaysPreToush
4、禁用偏置锁定可能会减少JVM暂停
-XX:-UseBiasedLocking
5、对于垃圾回收,建议使用G1收集器
-XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:G1ReservePercent=25 -XX:InitiatingHeapOccupancyPercent=30
这些GC选项看起来有点激进,但事实证明它在生产环境中具有良好的性能。
-XX:MaxGCPauseMillis不要设置太小的值,否则JVM将使用一个小的新生代,这将导致非常频繁的新生代GC。
6、推荐使用滚动GC日志文件
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=30m
7、如果写入GC文件会增加代理的延迟,请将重定向GC日志文件考虑在内存文件系统中
-Xloggc:/dev/shm/mq_gc_%p.log
5.2、Linux内核配置
1、在bin目录中,有一个os.sh脚本列出了许多内核参数,只需要稍微的修改,就可以用于生产环境。
2、以下参数需要注意,详细信息请参考
https://www.kernel.org/doc/Documentation/sysctl/vm.txt