基于Kafka,数据隔离的实现

文章讨论了在设计消息系统时如何处理单个发送接口故障导致的消息积压问题。通过引入多topic和多group,实现了不同类型消息的隔离。然而,针对不同消息子类的高并发场景,又提出了添加messagetype字段和细化消费者组的方法。最终选择采用单topic多group的架构,兼顾了扩展性和维护性。
摘要由CSDN通过智能技术生成

1.设计初时,构思单gruop(消费者组),单topic(队列)。但容易出现消息积压问题,当在某一个时间节点比如短信类型消息需要发送2000w条,然后此时短信渠道发送接口出现异常,发送超时,发送渠道就会被堵住,这时如果需要发送其他渠道消息(如邮件类),此时则无法发送。

2.那如何解决单个发送接口渠道出现异常从而导致消息积压,其他渠道的数据也无法发送?

最开始的想法很简单,之前我们把所有类型消息都存放在一个topic里面,单group消费异常,整个系统就类似于宕机了。那我们不妨开辟多个topic,多个group。不同类型的massage单独存放在各自的topic里面,本身topic之间也存在着物理隔离从而实现消息隔离,这时单个消费接口渠道出现异常并不会影响到其他信息渠道对于消息的发送。

3.好了现在问题就彻底解决了吗?答案是并没有,上述的多topic,多group分别一一对应,只实现的消息类型的大类之间的隔离,但我一个消息大类中有不同的消息小类,以邮件消息email为例,email邮件中有营销类和通知类,如果在某一时刻,营销类邮件有高达4000w条消息需要推送,这时候如果来一条通知类的消息在短时间类就无法发送,且一般通知类消息带有紧急急需发送性质,所以这时渠道堵塞,就会导致通知类消息无法发送,这明显不合理。于是我们在设计消息模板时里面添加一个字段进行判断也就是massgetype,然后再根据不同的消息类型划分不同的消费者组,当然也可以采取最初的第一种解决方法,单topic,单gruop,但问题是后期消息推送出现瓶颈,代码不清晰且不易维护。

4.最终做法

单topic多gruop

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值