明天要实现的是handler模块的生产数据隔离。

austin-api接管到了申请之后，将申请发往Kafka，topicName为austin。而在austin-handler起了一个groupName名为austinGroup监听austin这个topic的数据，进而实现音讯发送。

从零碎架构来说，austin我的项目是能够发送多种类型音讯的：短信、微信小程序、邮件等等等

那如果是单个topic单个group的话，有没有想过一个问题：如果某个发送渠道接口存在异样，超时了，此时会怎么样？

没错，音讯都会堵住，因为它们生产同一个topic，用的是同一个消费者。

01、数据隔离
要破局？很简略。多topic多group就行啦。

下面这种能解决所有问题吗？并不。即使是同一个渠道，但不同类型的音讯发送个性是不一样的。比方我要发push营销音讯，有可能在某个时刻就要推送4000W的人群。

那这4000W人在短时间内齐全发送进来，不太事实。这很可能意味着会影响到告诉类的push音讯

还要破局？很简略。 毕竟咱们在设计音讯模板的时候就曾经思考到这点了。音讯模板有msgType字段来标识以后的模板属于哪种类型，那咱们能够依据不同的音讯类型再划分对应的group。

从实践上来说，咱们能够为每种渠道的每种音讯类型独自辨别一个topic和group。因为topic间的数据是隔离的，不同的group间生产也是隔离的，那咱们生产时必定是数据隔离的。

不过，我目前的做法是：单topic多group。生产是隔离的，但生产的topic是共享的。我认为这样代码会更加清晰和易懂些，前期如果存在瓶颈了咱们能够持续改。

02、生产端设计
从下面曾经定了通过单topic多group来实现数据隔离。比方，我目前定义了6个渠道(im/push/邮件/短信/小程序/微信服务号)和3种音讯类型(告诉/营销/验证码)，那相当于起了18个消费者。

从kafka获取失去音讯当前，我暂定布局是走几个步骤：音讯抛弃->去重->真正发送

从实质上看去重和发送音讯都是网络IO密集型。于是，为了进步吞吐量，我这边决定生产Kafka后存入缓存，做一层缓冲区。

做一层缓冲区可进步吞吐量，但同样会带来别的问题。如：当利用重启时，缓冲区的数据还没生产完，那是不是就会失落？

这个咱们能够前面再看看怎么把带来的问题给搞掂（继续关注，我的项目优化前面多着呢）。当初还是认为缓冲区的利大于弊，所以回到缓冲区上。

缓冲区给我的第一反馈是实现生产者消费者模式

要实现这种模式，我初想了下挺简略的：生产Kafka的音讯作为生产者，而后把数据扔进阻塞队列上，开多个线程去生产阻塞队列的数据就完事了。

起初又想了下，间接线程池不就完事了吗？线程池不就是生产者和消费者的实现吗。

于是乎，架构就变成了下图：

03、代码设计
在生产端首先看Receiver的代码，该类看起来看简略，就只有一个@KafkaListener注解润饰办法，从Kafka生产进去随后交给pending做解决

我用的是@KafkaListener注解从Kafka拉取音讯，而没有用低级的Kafka api，原因无他：在项目前期无需做到完满，等有瓶颈的时候再想方法就好了。虽说如此，但我写的时候还是给我带来了不少的麻烦。

第一个问题：@KafkaListener是一个注解，从源码正文看它的传值只可能用Spring EL表达式和读取某个配置。但要晓得的是，我的目标是想有多个group生产同一个topic。而我不可能说给每个group都定义一个生产的办法吧？（写这种破代码，我都睡不着觉）

翻了一个早晨技术博客我都没找到计划，甚至还发了个朋友圈吐槽下有没有人遇到过。第二天我认真翻了下Spring的官网文档，终于给我找到了计划。

还是官网文档切实！

有了解决办法了当前，那事件就好办了。既然我是每种音讯渠道的每种音讯类型都要隔离，那我把这给枚举进去就完事啦！

我的Receiver是多例的，那么只有我遍历这个List就好了（初始化消费者在ReceiverStart类上）。

解决了用@KafkaListener注解动静传入groupId 进而创立多个消费者了之后。

我又遇到了第二个问题：Spring有@Aysnc注解来优雅实现线程池的办法调用。我之前是没用过@Aysnc注解的，但我看了下原理和应用姿态。我感觉这样挺优雅的（优雅永不过期）。然而用@Aysnc是必定要本人创立线程池，并且我要给每个消费者都创立本人独有的线程池。而我不可能说给每个group都定义一个创立线程池的办法吧？（写这种破代码，我都睡不着觉）

这次翻了官网和各种技术博客，都没能解决掉我的问题：在Spring环境下@Async注解上动静传入线程池实例，以及创立线程池实例时可反对依据条件传参。

最初只能放弃掉@Aysnc注解了，以编程的形式去实现：

上面是TaskPendingHolder的实现（无非就是给每个消费者创立对应的线程池）：

而Task实现目前就比较简单啦，间接调用对应的Handler进而下发音讯就好：

04、总结
代码看似简略，业务看似容易了解，然而要晓得的是即使是很多小公司的生产我的项目都没有这种设计。一把梭可真的是太常见了（性能又不是不能实现，代码又不是不能跑，最次要的：人也不是不能跑）

这篇文章次要讲述了一个思路：在生产MQ的时候，多group是能够实现数据隔离的，想要进步生产的吞吐量，能够再做一层缓冲区（前提是生产是IO密集型的）

最初
如果你感觉此文对你有一丁点帮忙，点个赞。或者能够退出我的开发交换群：1025263163互相学习，咱们会有业余的技术答疑解惑

如果你感觉这篇文章对你有点用的话，麻烦请给咱们的开源我的项目点点star:http://github.crmeb.net/u/defu不胜感激 ！

PHP学习手册：https://doc.crmeb.com
技术交换论坛：https://q.crmeb.com