MQ 简介
异步。用在消费者与发送者需要解耦的场景。比如生产非常多的数据提供给多个下游服务使用，并不关心他们怎么用。电商中的应用比如：订单系统下单成功后，写入消息队列，库存系统从订阅中获取订单信息进行后续操作，调整完库存后才能付款等。秒杀由于用户太多可以用MQ对用户进行排队
优点：
- 平台统一调用方式
缺点：
- 需要增加MQ组件
- 消息调用路径变长，增加延时
- 消息不丢不重难保证
异步，解耦，消峰，MQ的三大主要应用场景。
上游关注和依赖下游的响应，宜用RPC；上游不关注不依赖下游的响应，宜用MQ。
还可以使用MQ来实现RPC，比如RabbitMQ中有Direct reply-to
MQ使用场景举例
数据驱动的任务依赖：比如统计任务，task2需要task1的结果，可以用MQ来编排
上游不关心执行结果：比如用户发布帖子，之后的加积分，统计分析等都可以通过MQ来解耦
上游关注执行结果，但执行时间很长：比如微信支付，一般用“回调网关+MQ”解耦
当调用方需要关心消息执行结果时，通常不使用MQ，而使用RPC调用。比如登录，登录要根据登录接口结果给出成功失败，跳转，错误等各种状态提升
MQ具体实现方案
MQTT双向通信场景
- 上行TOPIC可以统一使用一个
- 下行TOPIC每个设备单独一个
- TOPIC数量支持很多
- 使用通配符TOPIC和类URI的topic命名风格(dev/infotech.vip/subscript,dev/infotech.vip/mac1/subscript,dev/infotech.vip/mac1/publish)
- 心跳监测
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中的一个。
JMS
