Mq常用的术语解释

MQ:
    作用：分布式系统中解耦、异步消息、流量削峰、IoT设备通信等场景
    
集群消费
    消息只被集群的一台服务器消费。
    一个Consumer ID中的Consumer实例平均分摊消费消息。例如某个Topic有9条消息，其中一个Consumer ID有3个实例（可能是3个进程，或者3台机器），那么每个实例只消费其中的3条消息。
    
    场景：产险出单系统将出单的保单数据发送给各保单系统，下游保单系统大多是集群部署，每条保单只需要被处理一次。
    解决方案：各保单系统采用集群消费模式接入MQS订阅产险出单系统的保单topic， 每个保单系统分别申请独立的ConsumerID订阅该topic，可实现每条消息只会被每个保单系统集群实例中其中1个实例拉取并处理。
    
广播消费
    消息被集群的所有服务器消费。常用用于配置中心的更新
    一条消息被多个Consumer消费，即使这些Consumer属于同一个Consumer ID，消息也会被Consumer ID中的每个Consumer都消费一次，广播消费中的Consumer ID概念可以认为在消息划分方面无意义。
    
顺序消费
    消费消息的顺序要同发送消息的顺序一致，在MQS中，一类消息为满足顺序性，必须Producer单线程顺序发送，且发送到同一个队列，这样Consumer就可以按照Producer发送的顺序去消费消息。
    
延时消费
    Producer将消息发送到MQS服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到Consumer进行消费，该消息即延时消息。
    
    场景一：保单交易中超时未支付关闭订单的场景，比如30分钟未支付，则会关闭订单。
    解决方案：业务系统设置消息的延时时间30分钟，在用户提交订单后，系统会发送一条消息给MQS，这条消息将会在30分钟以后投递给业务系统，业务系统收到此消息后需要判断对应的订单是否已完成支付。如支付未完成，则关闭订单，如已完成支付则忽略。
    
消息积压
    Producer 已经将消息发送到MQS服务端，但由于Consumer消费能力有限，未能在短时间内将所有消息正确消费掉，此时在MQS服务端保存着未被消费的消息，该状态即消息堆积。
    
异步解耦：
    场景一：活动大促期间，并发请求量激增，后端服务器出现性能瓶颈，扩容不能及时解决问题，用户体验也不好，如何避免在并发洪峰时降低服务器压力？
    解决方案：接入MQS，解耦前后端，前端请求发送堆积到MqsBroker，后端每个consumer每次拉取32条数据，避免出现因直接调用造成服务器压力过大的问题。且MQS支持实时ConsumerID容量在线变更，能快速重新计算分配，无缝支持业务系统后端服务器扩容以提高处理能力。