消息队列应用

MQ 简介

异步。用在消费者与发送者需要解耦的场景。比如生产非常多的数据提供给多个下游服务使用,并不关心他们怎么用。电商中的应用比如:订单系统下单成功后,写入消息队列,库存系统从订阅中获取订单信息进行后续操作,调整完库存后才能付款等。秒杀由于用户太多可以用MQ对用户进行排队

优点:

  1. 平台统一调用方式

缺点:

  1. 需要增加MQ组件
  2. 消息调用路径变长,增加延时
  3. 消息不丢不重难保证

异步,解耦,消峰,MQ的三大主要应用场景。
上游关注和依赖下游的响应,宜用RPC;上游不关注不依赖下游的响应,宜用MQ。
还可以使用MQ来实现RPC,比如RabbitMQ中有Direct reply-to

MQ使用场景举例

数据驱动的任务依赖:比如统计任务,task2需要task1的结果,可以用MQ来编排
上游不关心执行结果:比如用户发布帖子,之后的加积分,统计分析等都可以通过MQ来解耦
上游关注执行结果,但执行时间很长:比如微信支付,一般用“回调网关+MQ”解耦
当调用方需要关心消息执行结果时,通常使用MQ,而使用RPC调用。比如登录,登录要根据登录接口结果给出成功失败,跳转,错误等各种状态提升

MQ具体实现方案

MQTT双向通信场景

  1. 上行TOPIC可以统一使用一个
  2. 下行TOPIC每个设备单独一个
  3. TOPIC数量支持很多
  4. 使用通配符TOPIC和类URI的topic命名风格(dev/infotech.vip/subscript,dev/infotech.vip/mac1/subscript,dev/infotech.vip/mac1/publish)
  5. 心跳监测

kafka

简介

一个TOPIC可以有多个partition分区,生产者在向kafka集群发送消息的时候,可以通过指定分区来发送到指定的分区中,通过Replication(副本集)设置每个分区的副本数量,一个Broker可以存储一个或者多个partition分区,每个broker通常会扮演两个角色:在一个partition中扮演leader,在其它的partition中扮演followers。
在消费者消费消息时,kafka使用offset来记录当前消费的位置。可以有多个不同的group来同时消费同一个topic下的消息,他们的的消费的记录位置offset各不相同,不互相干扰。对于一个group而言,消费者的数量不应该多余分区的数量,也就是一个消费者可以消费多个分区,一个分区只能给一个消费者消费
在同一个Partition中消息是顺序写入的且始终保持有序性;但是不同Partition之间不能保证消息的有序性(高吞吐量的保障),在需要严格保证消息的消费顺序的场景下,需要将partition数目设为1
Topic中的每一条消息可以被多个consumer group消费,然而每个consumer group内只能有一个consumer来消费该消息。consumer group才是topic在逻辑上的订阅者。
最好使用3个broker可以使用zookeeper管理
对于同一个partition,它所在任何一个broker,都有可能扮演两种角色:leader、follower中的一个。

Kafka流程图

参考