消息队列三大问题

消息队列三大问题

如何确保消息不丢失

如何知道有消息丢失？

• 消息检测

  • 消息生产端给每个消息指定全局唯一id
    或者附加一个连续递增的版本号，然后再消费端做对应的版本校验

• 全局唯一 ID 生成的实现方法

  • 数据库自增

    • 递增，不会重复，但是数据库宕机不可用

  • UUID

    • 无序，极低概率重复，一直可用

  • Redis

    • RDB持久化模式下，会出现重复，Redis宕机不可用

  • Snowkflake（推荐）

    • 递增，不会重复，存在时钟回拨问题

哪些环节可能丢消息？

• 消息存储阶段

  • confirm确认模式

• 消息消费阶段

  • ack确认机制

如何确保消息不丢失？

• 利用拦截器机制将消息版本号注入消息中。再通过拦截器检测版本号的连续性或消费状态，这样实现的好处是消息检测的代码不会侵入到业务代码中，可以通过单独的任务来定位丢失的消息，做进一步的排查

怎么解决消息被重复消费的问题

消费失败通过补偿的机制发送方会执行重试，重试的过程就有可能产生重复的消息换个问题就是如何解决消费端幂等性问题

最简单的实现方案，就是在数据库中建一张消息日志表 ， 这个表有两个字段：消息 ID 和消息执行状态

也可以通过 Redis 来代替数据库实现唯一约束的方案

消息积压问题

绝大部分的消息队列单节点都能达到每秒钟几万的处理能力，相对于业务逻辑来说，性能不会出现在中间件的消息存储上面。毫无疑问，出问题的肯定是消息消费阶段，那么从消费端入手

本着解决线上异常为最高优先级，增加消费端的数量，与此同时，降级一些非核心的业务。通过扩容和降级承担流量，

其次，才是排查解决异常问题，如通过监控，日志等手段分析是否消费端的业务逻辑代码出现了问题，优化消费端的业务处理逻辑。

最后，如果是消费端的处理能力不足，可以通过水平扩容来提供消费端的并发处理能力，但这里有一个考点需要特别注意 ， 那就是在扩容消费者的实例数的同时，必须同步扩容主题 Topic 的分区数量，确保消费者的实例数和分区数相等。如果消费者的实例数超过了分区数，由于分区是单线程消费，所以这样的扩容就没有效果。