应用简记系列-消息系统

成熟的技术已经被卷地差不多了，google+gpt可以解决99.99%的问题，出个简记系列汇总一下各类技术及其应用。

宇宙安全声明：应用总结只限于Google可搜的公开站点的信息

消息队列知识点回顾

javaguide.cn/high-perfor…

medium.com/@cobch7/kaf…

kafka 2.x architecture, zookeeper实现元数据（broker, topic, partition and their relations）信息管理，负载均衡

QnA

Q	A
kafka是怎么保证消息的可靠性的，持久化到db吗	Kafka 通过副本机制、确认机制、日志文件存储、消息持久化、数据恢复和端到端的传输保证等多种技术手段来确保消息的可靠性，而不需要将消息持久化到外部数据库。
所有的消息一定会写到日志吗	是的，Apache Kafka 的消息持久化机制是通过将消息写入磁盘上的日志文件实现的。具体来说，Kafka 的每个分区都有一个对应的日志文件，所有消息在被生产者发送到 Kafka 后，都会被追加到这个日志文件中。
消息是怎么消费的，主动推送到消费者进程还是被动等消费者进程请求	Kafka 使用拉取模式让消费者主动请求消息。这种设计使得消费者能够灵活地控制消息消费的速率、处理逻辑和偏移量管理，同时通过消费者组实现负载均衡和容错性。
消费者的offset是存到kafka日志里的吗	消费者的 offset（偏移量）可以存储在 Kafka 自己管理的一个特殊主题中，默认是 __consumer_offsets。这个主题存储了每个消费者组的每个分区的偏移量。
expired的消息怎么处理	当消息到达其保留时间或保留大小的限制时，Kafka 会删除这些消息。这是通过后台线程周期性地检查日志文件并删除过期消息来实现的。
过期的消息列表怎么提醒或者说监控，是需要额外实现的还是kafka自带的可配置的	Kafka 本身不直接提供过期消息的提醒或监控功能。如果需要监控过期消息，你可以选择以下方案：使用 Kafka 自带的工具和 API，结合自定义脚本来实现提醒。使用 Prometheus 和 Grafana 等开源监控工具来收集和展示 Kafka 的各种指标，并配置报警规则。使用商业监控工具，如 Confluent Control Center，来获取丰富的监控和报警功能。使用 Kafka 生态系统中的其他工具，如 Kafka Manager 和 Burrow，来监控 Kafka 集群的状态。
日志是怎么更新、删除的	Kafka 使用日志段（log segment）来管理消息的存储，每个分区对应一个日志文件，该文件又被分割成多个日志段。Kafka 的消息删除机制通过定期检查日志段文件，根据设置的保留策略（时间或大小）来删除过期的日志段文件。这种机制确保了 Kafka 系统能够高效地管理存储资源，删除过期消息的整个日志段文件，而不是逐条删除消息，提高了系统的性能和稳定性。
删除一个日志段文件后，剩下的日志段文件的offset会变吗	删除一个日志段文件后：剩下的日志段文件的 offset 不会改变：因为 offset 是基于整个分区的，删除某个日志段文件不会影响其他日志段文件中的 offset。消费者的 offset 不会改变：消费者的 offset 是全局的，不受单个日志段文件删除的影响。
Spring Cloud Stream？	Spring Cloud Stream 是一个用于构建消息驱动的微服务的框架，它提供了一种统一的编程模型，能够与多种消息中间件集成。它的设计目标是简化微服务之间的异步消息通信，并提供了一致的 API 以抽象底层消息中间件的细节。Binder：Binder 是 Spring Cloud Stream 用于抽象底层消息中间件的组件。Channel：Channel 是消息传递的管道。Spring Cloud Stream 定义了 Input 和 Output 通道，用于分别接收和发送消息。Bindings：Bindings 是将应用程序中的通道绑定到消息中间件的具体配置。通过 spring.cloud.stream.bindings 配置，你可以定义输入和输出通道如何绑定到具体的消息目的地（如 Kafka 主题或 RabbitMQ 队列）。
消费者速度跟不上了会怎样	消息不会直接被丢弃，但会依据配置的保留策略在日志保留时间过期后被删除。具体处理取决于 Kafka 的配置参数，如保留时间、保留大小等。Lag 指的是消费者在消息队列中处理消息的滞后情况。具体来说，它表示生产者已经生产但消费者尚未处理的消息数量。Offset Reset 是在消费者遇到异常或首次订阅时，重置消费的偏移量，确保消费者能够继续正确地消费消息。如果消费者重置了 offset 后仍然无法跟上生产者的速度，那么随着时间的推移，最早的消息可能会因为 Kafka 的保留策略而被删除。策略：监控报警，增加消费者实例、分区、并行处理

MQ in production

Kafka vs In-house MQ

Kafka适合处理高并发、批消息，一个典型的应用场景就是日志架构，日志先pub到kafka，再由下游服务sub消费，常见的服务包括：监控平台、日志索引及搜索服务、日志存储系统、可视化系统。

In-house solution 一般是为了业务特殊需要设计维护的。比如为了延长持久性基于数据库存储，提供事务和回滚，额外的校验清点机制保证每一条消息的成功消费，灵活的配套ops可视化工具提供包括特定消息重发、长时间未处理消息的重新入队、consumer offset reset、监控报警等功能。

业务角度下的MQ集成

和MQ Infra高度解耦，主打一个透明：

1. 注册消费者服务和topic
2. 基本的lib依赖、配置项及初始化 @Input for consumer（@Output for producer）
3. @StreamListener （or @KafkaListener）写消息处理逻辑，抛出retryable or unretryable exception

特别地对于消息丢失比较敏感的topic，配置死信队列，当发生unretryable或者retry次数超限后消息进入死信队列。死信队列的处理方式一般为最后一次重试、日志、metric报警。

用户增长平台实践

有幸参与过用户增长平台，开发或维护过的消息队列案例：

1. 用户的注册涉及到的下游比较多，部分服务耗时较高影响用户体验，采用消息队列异步处理的方式可以有效控制接口耗时。消息生产者为服务本身。
2. 用户账号状态改变需要及时的消息提醒（webhook），包括重要信息变更、权限变动、合规状态变化。消息生产者为下游。
3. 事件日志与可视化工具，一些重要的消息有必要记录为事件时间线，实现账户状态改动一览，有助于我们更好地为客户排查问题提供服务。

其他：邮件短信的构建渲染发送其实都是MQ-based