看了不少关于MQ的文章，也对MQ的作用做了一些总结。通常来说MQ有三大功能：异步处理、系统解耦和流量削峰。但我觉得这些功能本质上都是围绕着异步这个核心来的，只是针对不同的业务场景做了些调整。
现在市面上常用的MQ中间件，如RabbitMQ、RocketMQ和Kafka，都是大家耳熟能详的。最近，Apache基金会推出的Pulsar也挺火的，口碑不错，只还差一些大项目实战来检验它。
如今，MQ在现在的项目里基本是标配了。这篇文章主要是梳理一下自己所在项目中是怎么用MQ的，复盘一下使用MQ的场景。
一、短信通知
1.1、场景描述
大概的业务场景就是：
系统包含多个微服务，如业务微服务、消息中心等。业务微服务完成相应的业务需要发送信息通知，一般来说第三方的短信服务发送短信是需要一定时间，所以请求过来它会先返回短信回执ID给调用方，后面调用方再通过回执ID来查询短信的发送状态。主要的问题还是在于短信服务不能同步返回短信是否发送成功。
主要要求：
- 发送短信有可能会失败，需要重试
- 发送完短信，需要从第三方查询短信状态并更新短信发送状态
1.2、项目实现
项目中的实现流程大概如下：
添加图片注释，不超过 140 字（可选）
- 业务中心把短信任务发送给消息中心MQ
- MQ中和任务被成功调用第三方接口如短信接口，后通过ACK去除掉MQ中消息
- 如果调用第三方接口失败，没有完成应答，消息会重新放回MQ原队列或死重队列进行重试
- 消息中心提供各种消息发送的功能，短信、邮件、钉钉等等
1.3、实现分解
当然一般来说业务量比较小时可以业务走完就直接顺序调用短信，或者起一个线程异步调用短信也可以。然后通过程序来处理异常与重试。
使用MQ中间件主要是考虑以后业务量大了、并发高了的情况下不解耦出来，对性能的影响。
总结一下，大概有以下的好处：
解耦服务：
MQ允许服务之间通过消息进行通信，而不是直接调用，这样可以减少服务间的依赖性，提高系统的灵活性和可维护性。
异步处理：
通过MQ，可以实现异步消息传递，使得发送者不需要等待接收者处理完消息。这样可以提高系统的响应速度和吞吐量。
可靠性保证：
MQ提供消息持久化、确认机制等功能，确保消息不会因为网络问题或服务故障而丢失。
重试机制：
MQ可以实现消息的重试机制，当消息处理失败时，可以重新发送消息，直到成功处理。
状态追踪和监控：
MQ可以配合日志和监控系统，追踪消息的状态和系统的健康状况。
二、业务日志
2.1、场景描述
大概的业务场景就是：
整个系统包含两类日志：一种是系统日志，另一种就是业务日志。
系统日志：nginx访问日志、java堆栈日志等
业务日志：谁什么时候登录、退出，谁什么时候使用了什么功能等一些用户行为日志
主要要求：
- 系统日志，由于分布式系统日志比较分散不便管理与使，需要有一个统一管理日志的地方
- 业务日志，收集并存储客户端软件及web端软件使用的用户行为日志
2.2、实现分解
项目中的实现流程大概如下：
系统日志
添加图片注释，不超过 140 字（可选）
- 通过filebeat采集系统日志
- filebeat把采集的日志输出到kafka
- logstash订阅kafka里的日志
- logstash把日志输出到elasticsearch中
- 运维和开发可以通过kibana搜索分布式节点的日志
使用MQ的作用：
Kafka 作为一个高吞吐量的分布式消息系统，可以作为 Logstash 和数据源（如 Filebeat）之间的缓冲区。这有助于解耦数据的生产者和消费者，允许它们独立扩展和运行。
当 Logstash 处理能力不足或 Elasticsearch 写入压力过大时，Kafka 可以缓冲数据，防止数据丢失，并确保系统的稳定性。
在生产中kafka可以在不同的环节插入到ELK中：
- Filebeat -> Logstash -> Elasticsearch: 适用于需要对日志数据进行复杂处理后存储的场景。
- Filebeat -> Kafka -> Logstash -> Elasticsearch: 适用于需要缓冲数据或实现数据流的实时处理的场景。
- Filebeat -> Kafka -> Elasticsearch: 适用于直接从 Kafka 消费数据并存储的场景，可能不需要 Logstash 的复杂处理。
业务日志
一般系统会记录用户的作为轨迹到数据库，用于用户作为的溯源，这种日志一般不允许丢失。
添加图片注释，不超过 140 字（可选）
业务日志使用kafka的原因基本和系统日志是一致的，系统日志落盘至elasticsearch中，而业务日志落盘到DB中。
2.3、小结：
此场景选择Kafka而非其他消息队列（MQ）解决方案，是基于对系统需求的精准匹配。Kafka作为一款专为处理大规模数据流而设计的消息系统，其卓越的性能表现在每秒能够处理数以万计的消息。这种能力使其成为处理用户行为日志和交易数据等高频次、大规模数据流的理想选择。
用户行为日志和业务数据日志往往伴随着高并发和持续的数据涌入，Kafka的高吞吐量和水平扩展性使其能够轻松应对这些挑战。其分布式架构和持久化存储机制确保了数据的可靠性和系统的稳定性，即使在数据量激增的情况下也能保持高效运行。因此，考虑到Kafka在这些方面的优势，我们决定采用它来满足项目对高吞吐量和数据处理能力的需求。
可以看到下图kafka的吞吐量是非常大的。
添加图片注释，不超过 140 字（可选）
此图来源于confluent.io
