关于rocketmq:RocketMQ学习二Producer临时

4次阅读

共计 1319 个字符，预计需要花费 4 分钟才能阅读完成。

Namespace，顾名思义，命名空间，为音讯发送者、音讯消费者编入到一个命名空间中。在笔者的了解中，Namespace 的引入，有点相似 RocketMQ 反对多环境、多标签、全链路压测场景。
一言以蔽之，Namespace 次要为音讯发送者、音讯消费者进行分组，底层的逻辑是扭转 Topic 的名称。

音讯轨迹：反对跟踪音讯发送、音讯生产的全过程，即能跟踪音讯的发送 IP、存储服务器，什么时候被哪个消费者生产。
ACL：拜访权限管制，即能够 Topic 音讯发送、订阅进行受权，只有受权用户能力发送音讯到指定 Topic。

msgId 的生成：
https://www.cnblogs.com/allen…
https://www.cnblogs.com/linli…

音讯发送形式
RocketMQ 反对同步、异步、Oneway 三种发送形式。

同步：客户端发动一次音讯发送后会同步期待服务器的响应后果。
异步：客户端发动一下音讯发动申请后不期待服务器响应后果而是立刻返回，这样不会阻塞客户端子线程，当客户端收到服务端（Broker）的响应后果后会主动调用回调函数。
Oneway：客户端发动音讯发送申请后并不会期待服务器的响应后果，也不会调用回调函数，即不关怀音讯的最终发送后果。

队列抉择机制
RocketMQ 反对队列级别的程序生产，故咱们只须要在音讯发送的时候如果将同一个订单号的不同的音讯发送到同一个队列，这样在生产的时候，咱们就能依照程序进行解决。

SendResult send(final Message msg, final MessageQueueSelector selector, final Object arg)

    throws MQClientException, RemotingException, MQBrokerException, InterruptedException;

指定 selector

RocketMQ key 的应用场景，能够依据 key 查问音讯（控制台，接口）。还有依据音讯偏移量、音讯全局惟一 msgId 查问，这都是 kafka 所没有的

RocketMQ 能够为 Topic 设置 Tag（标签），这样生产端能够对 Topic 中的音讯基于 Tag 进行过滤，即选择性的对 Topic 中的音讯进行解决。发送音讯时能够依据事件不同流程为音讯设置不同的 Tag，而生产端进行生产时能够只生产合乎本人 Tag 的音讯，API 如下：
void subscribe(final String topic, final String subExpression) throws MQClientException;

RocketMQ msgId 与 offsetMsgId 生成规定

音讯发送高可用设计与故障躲避机制（第 5 章）
主要参数是 sendLatencyFaultEnable

第 6 章，音讯发送谬误及罕用解决方案
音讯发送超时剖析，很可能是网络超时
疾速失败导致的谬误为 system_busy，并不会触发重试
能够将超时等待时间设置短一点，这样容易触发，进而重试

System busy、Broker busy 起因及应答策略