消息队列的基本概念.pdfVIP

消息队列的基本概念 随着消息应⽤中⼼（任务中⼼）的⼴泛应⽤，有时候我们会感受不到消息队列的存在，但这不影响消息队列在⾼可⽤、分布式、⾼并发架构 下的核⼼地位。 ⼀、消息队列的应⽤场景 1. 异步处理：例如短信通知、终端状态推送、App推送、⽤户注册等 2. 数据同步：业务数据推送同步 3. 重试补偿：记账失败重试 4. 系统解耦：通讯上下⾏、终端异常监控、分布式事件中⼼ 5. 流量消峰：秒杀场景下的下单状态 6. 发布订阅：HSF的服务状态变化通知、分布式事件中⼼ 7. ⾼并发缓冲：⽇志服务、监控上报 ⼆、消息队列的⼀些基本概念和简单原理 1. Broker Broker的概念来⾃与Apache ActiveMQ，通俗的讲就是MQ的服务器。 2. 消息的⽣产者、消费者 消息⽣产者Producer：发送消息到消息队列。 消息消费者Consumer：从消息队列接收消息。 3. 点对点消息队列模型 消息⽣产者向⼀个特定的队列发送消息，消息消费者从该队列中接收消息； 消息的⽣产者和消费者可以不同时处于运⾏状态。 每⼀个成功处理的消息都由消息消费者签收确认 （Acknowledge）。如图： 4. 发布订阅消息模型-Topic 发布订阅消息模型中，⽀持向⼀个特定的主题Topic发布消息，0个或多个订阅者接收来⾃这个消息主题的消息。在这种模型下，发布者和订 阅者彼此不知道对⽅。实际操作过程中， 发布订阅消息模型中，⽀持向⼀个特定的主题Topic发布消息，0个或多个订阅者接收来⾃这个消息主题的消息。在这种模型下，发布者和订 阅者彼此不知道对⽅。实际操作过程中， 必须先订阅，再发送消息，⽽后接收订阅的消息，这个顺序必须保证。 5. 消息的顺序性保证 基于Queue消息模型，利⽤FIFO先进先出的特性，可以保证消息的顺序性。 6. 消息的ACK确认机制 即消息的Ackownledge确认机制， 为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送⼀个ACK给消息 队列，此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭，没有发送ACK ，消息队列将认为这个消息没有被处理，会将这个消 息重新发送给其他的Consumer重新消费处理。 7. 消息的持久化 消息的持久化，对于⼀些关键的核⼼业务来说是⾮常重要的，启⽤消息持久化后，消息队列宕机重启后，消息可以从持久化存储恢复，消息 不丢失，可以继续消费处理。 8. 消息的同步和异步收发 同步：消息的收发⽀持同步收发的⽅式。 同时还有另⼀种同步⽅式：同步收发场景下，消息⽣产者和消费者双向应答模式，例如：张三写封信送到邮局中转站，然后李四从中转站获 得信，然后在写⼀份回执信，放到中转站，然后张三去取，当然张三写信的时候就得写明回信地址 消息的接收如果以同步的⽅式(Pull)进⾏接收，如果队列中为空，此时接收将处于同步阻塞状态，会⼀直等待，直到消息的到达。 异步：消息的收发同样⽀持异步⽅式：异步发送消息，不需要等待消息队列的接收确认；异步接收消息，以Push的⽅式触发消息消费者接 收消息。 9. 消息的事务⽀持 消息的收发处理⽀持事务，例如：在任务中⼼场景中，⼀次处理可能涉及多个消息的接收、处理，这处于同⼀个事务范围内，如果⼀个消息 处理失败，事务回滚，消息重新回到队列中。 三、我们对消息队列的实际使⽤ 我们使⽤了两种消息队列组件： RabbitMQ：⾼可⽤、⾼可靠消息应⽤场景，例如记账失败重试、通知服务，消息不允许丢 Kafka：⾼性能消息应⽤场景，例如⽇志、监控，消息允许丢失。 在此之上，我们封装了消息应⽤中⼼、⽇志服务等核⼼组件和服务。那么，消息应⽤中⼼和⽇志都⽤到了消息队列什么技术？⼲货来了… 1. 消息应⽤中⼼ 消息应⽤中⼼ （任务中⼼）使⽤了消息队列的异步处理、数据同步、重试补偿、系统解耦、流量消峰等特性。其中： 消息应⽤中⼼ （任务中⼼），⽀持RabbitMQ和Kafka两种消息通道，⽀持在任务元数据层⾯设置 任务：就是⼀个包含了任务执⾏上下⽂的消息，同时代表了异步处理 任务发送者 （ITaskSender）发送任务：消息的⽣产者将任务消息发送的消息队列 任务类型：消息队列名称，例如：HaKeepAcco***Queue，充电补偿记账队列 消息队列：任务的临时存储 任务中⼼：任务集中处理，消息消费者 任务处理完成：消息Ack确认 任务的多级重试：多个重试消息队列，HaSysTaskStore2Queue