Kafka（二）消息系统设计

文章目录

• 前言
• 整体设计
• 时序图
• • 时序图解释
• 最后

前言

当多个系统之间通过Kafka来解耦时，在系统设计初期，基本的要求都是相似的，只不过是消费消息时的业务逻辑可能不同。

本文以业务系统和邮件系统解耦作为示例。业务系统需要发送邮件时，不在自身服务器上发送邮件， 不通过RPC的方式调用邮件系统，而是通过将发送邮件需求以消息的形式发送到Kafka， 邮件系统通过从Kafka中消费消息来发送邮件。

通过这样的解耦有以下几点好处

1. 由于业务系统不直接调用邮件系统，所以不会将压力给到邮件系统，避免两个系统因大量的请求响应而出现的系统不稳定问题
2. Kafka的性能是非常出色的，所以对于业务系统的大量写入应该可以hold住。当然我司每天写入的数据量和头部互联网公司的每天的海量数据没法比
3. 邮件系统可以根据实际情况来从容的消费消息，也有利于我们可以针对邮件系统服务器进行硬件、软件、JVM等精细化的调优

整体设计

1. 业务系统向Kafka发送消息
2. 消息系统从Kafka获取消息，执行消费逻辑
3. 业务系统的消息被邮件系统消费之后还需要通知业务系统
4. 确保消息不丢失
5. 确保消息不重复消费
6. Kafka的高可用、稳定性不在本文讨论范围之内

时序图

下列时序图使用mermaid绘制

如果看不清楚，使用点此查看高清图片

时序图解释

1. 1 ~ 10步骤为核心流程
2. 11 ~ 20步骤为可选流程， 如果存在回调消息，则还要回调

最后

整体大的细节就如时序图所示，后续将在具体编码中进行更详细的说明。 下一篇博文专注于业务系统生产者端逻辑的实现。