rocketmqphpsdk技巧_若何实现一个简单易用的 RocketMQ SDK

文章目录 [+]

由于各个团队 RocketMQ 原生客户端配置起来千奇百怪，有的配置存在风险，各团队卖力人都须要一个简洁易用的 RocketMQ SDK 。

我立马调研干系开源的方案，当时 RocketMQ-Spring 项目并没有开源，而阿里云的 ONS SDK 是开源的，我只能讲目标转向阿里云 ONS 。

rocketmqphpsdk技巧_若何实现一个简单易用的 RocketMQ SDK

通过学习 ONS 的设计办法，我对付 RocketMQ 的客户端事理有了进一步理解，同时参考 ONS 的设计，也实现了公司内部利用的 RocketMQ SDK 。

（图片来自网络侵删）

项目地址：https://github.com/makemyownlife/platform-rocketmq

之以是说大略，便是让用户（开拓者）利用 SDK 时，减少心智包袱。

举三个例子：

1 发送顺序

利用原生代码发送时，会利用如下的代码：

SendResult sendResult = producer.send(msg, new MessageQueueSelector() {br @Overridebr public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {br Integer id = (Integer) arg;br int index = id % mqs.size();br return mqs.get(index);br }br}, orderId);

我们可以将 SDK API 简化为：

SendResult send(final ProducerMessage message, final String shardingKey);

开拓者不须要定义行列步队选择器，只须要通报分片键 orderId 即可。

2 单条消费

利用原来代码定义消费监听器时，利用如下的代码：

consumer.registerMessageListener(new MessageListenerConcurrently() {br @Overridebr public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {br System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);br // 返回消费状态，ConsumeConcurrentlyStatus.CONSUME_SUCCESS为消费成功br return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;br }br});

监听器内部，对付开拓者操作的工具是列表 msgs ，很多开拓同学想只操作一条。

于是，我们可以将 SDK API 简化为：

consumer.subscribe("mytest", new ConsumerListener() {br @Overridebr public ConsumerAction consumer(ConsumerMessage msg) {br byte[] body = msg.getBody();br System.out.println("msg:" + new String(body));br return ConsumerAction.CommitMessage;br }br});

开拓者在消费时，可以一条一条操作，代码简洁了不少。

同时，很多开拓者在利用普通消费、顺序消费时，须要返回延时消费的状态码时，两莳花费模式定义的列举也不相同。
我们将列举做了统一：

/br 消费的返回结果br /brpublic enum ConsumerAction {brbr /br 消费成功，连续消费下一条br /br CommitMessage,br br /br 消费失落败，奉告做事器稍后再投递这条，连续消费其他br /br ReconsumeLater;br}3 订阅关系同等

实际场景里，订阅关系不一致是极随意马虎发生的事情，就算是高等别的架构师也会翻车，每次翻车现场都是惨不忍睹。

精确的订阅关系见下图：

代码逻辑角度来看，每个消费者实例内订阅方法的主题、 TAG、监听逻辑都须要保持同等。

当订阅关系不一致时，在 Broker 端同一个消费组内的各个消费者客户真个订阅信息相互被覆盖，从而导致某个消费者客户端无法拉取到新的。

怎么办理呢？

我当时想起了阿里技能专家沈询的一句话：

天下上办理一个打算机问题最大略的方法：“恰好”不须要办理它！

公司内部涌现订阅关系同等99%的问题是：消费者组同等的条件下，主题相同，但 TAG 不相同。

基于此，我的设计思路就明确了：不开放订阅 TAG 的权限！

没想到吧，我便是这么粗暴。

按照这种设计思路，虽然开始有的程序员会有质疑，但你和他梳理好消费者组的定义，以及做好领域划分，对业务来讲，反而清晰了。

4 写到末了