棒👍🏻

评论没法贴 ERD，老师请教一下这样理解是否正确： Topic : queue = 1 : n 一个 topic 下有多个 queue； 一条消息只会投递到这个 topic 的某一个 queue 下(具体哪一个取决于策略)。 Topic : consumer group = 1 : n 一个 topic 下可以有多个 consumer group； 每个订阅该 topic 的 consumer group 会得到该 topic 的完整消息。 例如解耦场景中: 发给订单topic 的消息会分别送到支付系统consume group、风控系统 consumer group、客服系统 consumer group..... consumer group : topic = 1:n 一个消费者组可以订阅多个 topic； queue : consumer = 1 : n 可能会有多个消费者同时在等某一个 queue 的消息，而一条消息只能给其中一个等待中的消费者（当然这些消费者同属于一个消费者组） ； 如果有消息a和消息b要保证按顺序消费，那就要投递到同一个 topic 同一个 queue 下。在同一个queue 里的消息a处理完后，消费者才能取到消息b，所以是有序的。 consumer group ：queue = 1:n 消费者组里的消费者们并行地从订阅的这个 topic 里的多个 queue 里取消息进行消费。 订阅topic的人是 consumer group 而非 consumer， 订阅的是 topic 而非 queue。 当某个 topic 下的消息堆积后，增加 queue 的数量、增加消费者组里的消费者的数量。 提高并行处理能力。

老师好，多个消费组消费同一个队列时，每个消费组都要维护一个自己的消费位置吗？

不要直接main方法看起来，感觉指出了新大陆啊

推荐阅读那个文章真是好文章，一下子把我以前了解的WAL技术与数据库日志串起来了

在消息队列的选型上更有把握点了，谢谢

案例篇太精彩了

用“醍醐灌顶，惊为天人”来形容我看到这篇文章的心情也不为过

高并发和避免gc，尽可能少的系统调用次数，让用户态的应用程序可以快速接受tcp传过来的数据（增大接收套接字的buffer缓冲区大小，可以降低用户态和内核态的内存拷贝频次，降低上下文切换开销）。 全业务处理流程考虑用指针传递，避免内存拷贝或者堆上内存开销（栈上开销os自行回收），降低被gc可回收的变量基数。 考虑业务处理线程或协程去复用一些申请的内存区域，比如go中的buffer pool，以及通过buffer reset在处理完业务时候自动释放，可以复用申请的内存区域。 通过pprof，runtime去监控和观察内存和、gc的实际情况做对照，了解应用程序实际内存的使用情况。 暂时想到这么多。

业务系统本身得具有幂等性，不管是前端来的http请求还是其他业务系统发来的rpc请求，都有可能重复发送，业务系统在处理涉及交易等重要的业务逻辑时，要通过业务主键ID、业务单状态等进行幂等处理。