支付系统中消息队列的使用

Page content

你们公司有个什么业务场景,这个业务场景有个什么技术挑战,如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好处。

为什么使用消息队列?

较核心的场景有 3 个:

  • 解耦 - 如 同步数据给下游,例如审计系统
  • 异步 - 如 支付成功,给用户发消息;支付异常,异步重试;异步给用户发放优惠券
  • 削峰 - 如 降低mysql写入负载

支付系统用到的MQ

  • RabbitMQ: 万级,比 RocketMQ、Kafka 低一个数量级
  • Redis: 10 万级,big key的问题
  • Kafka: 100 万级,高吞吐;不支持消息调度

消息队列有什么优缺点

  • 系统可用性降低,系统引入的外部依赖越多,越容易挂掉。如MQ挂了,给用户发消息就失败
  • 系统复杂度提高。Q: 怎么保证不重复消费,怎么防止消息丢失?
  • 一致性问题。比如 消息处理完,ack失败了,消费者中途挂了。

消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,做好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。

如何保证消息队列的高可用

RabbitMQ 镜像集群模式(高可用性)

这种模式,才是所谓的 RabbitMQ 的高可用模式。 跟普通集群模式不一样的是,在镜像集群模式下,你创建的 queue,无论是元数据还是 queue 里的消息都会存在于多个实例上,就是说,每个 RabbitMQ 节点都有这个 queue 的一个完整镜像,包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候,都会自动把消息同步到多个实例的 queue 上。

Kafka 的高可用性

Kafka 一个最基本的架构认识:由多个 broker 组成,每个 broker 是一个节点; 你创建一个 topic,这个 topic 可以划分为多个 partition,每个 partition 可以存在于不同的 broker 上,每个 partition 就放一部分数据。 这就是天然的分布式消息队列,就是说一个 topic 的数据,是分散放在多个机器上的,每个机器就放一部分数据。

怎么保证不重复消费

例如:给用户发通知不能重复。

  • redis set一个key,自动保证幂等。
  • mysql uk记录一行: 基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了,重复数据插入只会报错,不会导致数据库中出现脏数据。

怎么防止消息丢失

生产者丢数据

RabbitMQ 事务机制(同步)一搞,基本上吞吐量会下来,因为太耗性能。

Kafka设置了 acks=all ,一定不会丢,要求是,你的 leader 接收到消息,所有的 follower 都同步到了消息之后,才认为本次写成功了。

MQ自己把消息弄丢了

RabbitMQ开启持久化,性能会降低。

消费者丢消息 - 拿到消息后,中途挂了。

RabbitMQ

关闭 RabbitMQ 的自动 ack ,可以通过一个 api 来调用就行,然后每次你自己代码里确保处理完的时候,再在程序里 ack 一把。

Kafka

Kafka 会自动提交 offset,那么只要关闭自动提交 offset,在处理完之后自己手动提交 offset,就可以保证数据不会丢。 但是此时确实还是可能会有重复消费,比如你刚处理完,还没提交 offset,结果自己挂了,此时肯定会重复消费一次,自己保证幂等性就好了。

如何保证消息的顺序性?

场景:

mysql 里增删改一条数据,对应出来了增删改 3 条 binlog 日志,接着这三条 binlog 发送到 MQ 里面,再消费出来依次执行,起码得保证人家是按照顺序来的吧?

RabbitMQ

  • 拆分多个 queue,每个 queue 一个 consumer,就是多一些 queue 而已,确实是麻烦点,这样也会造成吞吐量下降,可以在消费者内部采用多线程的方式取消费。

Kafka

  • 一个 topic,一个 partition,一个 consumer,内部单线程消费,单线程吞吐量太低,一般不会用这个。
  • 写 N 个内存 queue,具有相同 key 的数据都到同一个内存 queue;然后对于 N 个线程,每个线程分别消费一个内存 queue 即可,这样就能保证顺序性。
本文由 络壳 原创或整理,转载请注明出处