ACP互联网架构认证笔记-MQ消息队列服务

MQ是消息服务中间件，基于高可用分布式集群技术，是消费模式基于发布订阅模式的消息系统。支持Java，C++以及.NET，PHP，Python，为分布式应用系统提供异步解耦、削峰填谷的能力，具备海量消息堆积、高吞吐、可靠重试等特性。具有消息查询，消息回溯(不是消息撤回，也不支持消息撤回)，消息轨迹查询，堆积监控报警功能。
MQ协议支持接入方式 : TCP、HTTP(RESTful 风格)、MQTT。MQ支持公网访问，但可用性较低。
MQ应用场景 : 分布式事务，物联网应用，实时计算(将产生的数据实时流入到实时计算引擎来实现)，同步大规模缓存。
实时计算引擎一般有 : Spark / Storm / EMR / ARMS / BeamRunner。
MQ拥有管理工具 : Web控制台，Open API，mqadmin命令集。拥有微消息队列(LMQ)，RocketMQ消息队列，Kafka消息队列，跨域中继服务(CRS)等组件。
Web控制台提供消息查询、消息轨迹查询、重置消费位点、资源统计、监控报警等操作。消息查询有三种方式 :** 根据Message ID(精确查询)，Message Key(模糊查询)以及Topic查询(范围查询)，HTTP消息目前只支持Message ID和Topic两种查询方式。**
消息轨迹查询只支持TCP和HTTP协议，可追踪消息从生产者发出到消费者消费的整个链路中各个相关节点的时间地点。
重置消费位点可跳过堆积的消息，即不想消费这部分消息，或者只想消费某个时间点后的消息（这些消息不论之前是否消费过）。
资源报表可对消息发送和消息消费的数据进行统计，暂不支持HTTP消费数据的统计查询。
监控报警一般用在消息堆积数或者延迟时间超过阈值之后，对报警接收人发送短信，如果发现消息堆积很多，可检查阈值是否设置过小导致消息堆积，可调整业务代码或者对消费者进行扩容，可使用jstack查看是否消费线程阻塞。
微消息队列(LMQ)基于MQTT(Message Queuing Telemetry Transport 消息队列遥测传输)协议，标准协议端口为1883，支持加密SSL，WebSocket，Flash接入方式。协议重要部分主要分为 : MQ Core Service(负责底层的消息存储和分发)，MQ私有协议服务器以及MQTT协议网关服务器(负责对客户端提供服务和协议转换)。主要使用场景有 : 直播互动、车联网、金融支付、即时聊天等。协议相关 : QoS(Quality of Service)指代消息传输的服务质量。它包括QoS0(最多分发一次)、QoS1(至少达到一次)和QoS2(仅分发一次)三种级别。cleanSession标识客户端建立TCP连接后是否关心之前状态(true or false)。
MQTT可进行实例管理(查看消息收发TPS、同时在线连接数、订阅关系数等信息，可设置实例报警)，可申请MQTT Topic，可为Topic申请MQTT Group ID(一组逻辑功能完全一致的节点共用的组名，代表一类相同功能的设备，必须拥有Topic的读写权限)。可进行签名计算和签名生成。
MQTT可获取离线消息，可主动拉取离线消息，客户端每次拉取消息数量最多为30条，拉取请求的最大频率限制为5次/秒。离线消息优先级低，对其进行有限和最终能处理即可，要求比较实时。
MQTT可获取客户端上下线事件(上下线事件触发时，会向后端MQ推送一条上下线消息，通过订阅这条消息获取)，上下线事件类型一般放在MQ的Tag中，有三种状态 : connect(客户端上线)，disconnect(客户端主动断开连接)，tcpclean(实际的TCP连接断开)。tcpclean代表客户端网络层连接的真实断开，判断客户端下线请使用tcpclean事件。
MQTT通过Token鉴权服务向客户端提供访问权限。客户端需要采用MQTT控制报文以同步发送模式并且QoS必须为1，来上传Token。客户端应该对Token做好持久化，监听Proxy下推的Token失效的通知消息，Token失效必须重新申请。
LMQ的Topic，ClientId长度最大为64个字符，消息大小最大为64K，消息保存时间最长为3天，单个客户端订阅Topic数量最大为30个(超过该限制数量的Topic会被丢弃)，消息顺序性为上行顺序。
跨域中继服务(CRS，跨域哦，实现服务发布与订阅，实现不同网络的服务互通)提供三种MQ消息发送方式 :可靠同步发送(发出消息响应后才能发下一个消息，应用场景广，如重要通知邮件、报名短信通知、营销短信系统)，可靠异步发送(不需要等待响应即可发下一个消息，应用场景一般是耗时长，对RT响应敏感的业务，如视频上传后通知转码服务，转码后通知推送转码结果)，One Way(单向发送，不需要响应的方式，耗时超短，对可靠性要求不高的场景使用，如日志收集)。
MQ消息系统中，资源分为消息(Message)，消息生产者(Producer)，消息消费者(Consumer)，消息主题(Topic)。Producer ID(生产者ID)，Consumer ID(消费者ID)，Topic名称，都必须全局唯一。
MQ消息是消息队列中信息传递的载体，按类型分一般有四种 : 无序消息(普通消息，定时消息，事务消息)，全局顺序消息，分区顺序消息，Kafka消息。MQ在网络抖动、应用处理超时等异常情况下，无法保证消息不重复，但是能保证消息不丢失。MQ消息在服务器保存最长时间为3天，消息Body长度限制为256K，华北2地域支持4MB大消息。
MQ消息主题是消息的一级归类，消息发布者将消息发送到某个消息主题（Topic），而消息订阅者订阅该Topic来获取和消费消息(第一次订阅新的Topic有延迟，之后不会)，一个Topic只能对应一个Producer ID(一个Topic只属于一个生产者，但一个生产者可以有多个Topic，关系为N:1)，一个Topic可以对应多个Consumer ID(一个Topic可属于多个消费者，一个消费者可以订阅多个Topic，关系为N:N)。Topic不能跨域使用。即Producer ID和Topic必须在同一个域内，Consumer ID和Topic必须在同一个域内。
RocketMQ常见使用方式 : 订阅关系一致，集群消费和广播消费，消息过滤，消息重试，消费幂等。
订阅关系由Topic+Tag组成，这两者必须一致即为订阅关系一致。
集群是相同Consumer ID的订阅者(实例)属于同一个集群，同一个集群下的订阅者消费逻辑必须完全一致，订阅者在逻辑上可以认为是一个消费节点。
集群消费模式：MQ认为任意一条消息只需要被集群内的任意一个消费者处理即可。
例如某个 Topic 有 9 条消息，一个 Consumer ID 有 3 个 Consumer 实例，那么在集群消费模式下每个实例平均分摊，只消费其中的 3 条消息。
广播消费模式：MQ将每条消息推送给集群内所有注册过的客户端，保证消息至少被每台机器消费一次。但消费失败后不做重试操作。
例如某个 Topic 有 9 条消息，一个 Consumer ID 有 3 个 Consumer 实例，那么在广播消费模式下每个实例都会各自消费 9 条消息
消费细节 : 启动Consumer(消费者)时，可通过ConsumeThreadNums属性来设置消费线程数。如果Consumer ID(消费者)是第一次启动，会忽略启动之前发送的消息(忽略历史消息)，从启动之后发送的消息开始消费，如果是第二次启动，那么从上次消费的位置开始消费。如果想从特定位置开始消费，请使用重置消费位点功能(只针对Consumer ID下的特定Topic，不影响其他Consumer ID)。
消息重试 : 只针对集群消费方式生效，广播方式不提供失败重试特性。默认允许每条消息最多重试16次(可自定义)重试16次后，仍然失败，则消息丢弃。一条消息无论重试多少次，这些重试消息的Message ID不会改变。
重试方式为有三种 : 1 . 返回Action.ReconsumeLater（推荐）；2 . 返回 Null ；3 . 抛出异常。
消费幂等 : 分为发送时消息重复(Message ID不同，发送到服务端时由于网络闪断或者客户端宕机导致服务端应答给客户端失败，生产者意识到发送失败再次发送)，投递时消息重复(Message ID相同，消息已经投递到消费者，客户端给服务端应答时网络闪断，为保证消息被消费一次，服务端再次投递之前被处理的消息)。
消费者按照Tag对消息进行过滤，确保消费者最终只消费到他关心的消息类型。
RocketMQ特色消息类型 : 定时消息和延时消息，顺序消息，事务消息。几种消息是不同的消息类型，是互斥关系，不能叠加在一起使用(即消息不能是既是顺序消息，又支持定时和事务消息)。
定时消息 : 推迟到当前时间点之后的某一个时间定时投递到消费者Consumer进行消费的消息。需要明确指定时间点(必须在当前时间点之后)。
延时消息 : (从发送该延时消息的当前时间开始)延迟一定时间后投递给消费者Consumer进行消费的消息。需要指定延迟时间长度。延时消息只支持TCP接入的Java语言。
定时/延时消息，通过参数setStartDeliverTime设置当前时间戳之后的某个时刻(必须在40天以内，超过40天消息发送失败)，如果这个参数在当前时间戳之前，消息将立刻被投递。如果有消息堆积，定时、延时消息会排在堆积消息后面，不能严格按照配置的时间进行投递。设置定时/延时消息的投递时间后，依然受3天的消息保存时长限制(即投递时间点之后仍没有被消费，3天后消息被删除)。
顺序消息 : 同一个Topic内保证顺序，由顺序发布和顺序消费两部分组成。分为全局顺序，和分区顺序两种类型。顺序消息只支持可靠同步发送方式，不支持异步发送。顺序消息支持集群消费，不支持广播消费。顺序消息支持MQ所有公共云Region和金融云Region。对于HTTP协议接入的，只支持顺序消息发送，暂不支持顺序消息消费。
全局顺序消息 : 所有消息按照严格的先进先出（FIFO）的顺序进行发布和消费(性能一般)。
分区顺序消息 : 所有消息根据sharding key(顺序消息中用来区分不同分区的关键字段)进行区块分区。同一个分区内的消息按照严格的FIFO顺序进行发布和消费(性能较高)。
事务消息 : 实现类似X/Open XA的分布事务功能，达到分布式事务的最终一致。事务消息的Producer ID不能与其他类型消息的Producer ID共用。半消息 : 事务消息流程中暂不能投递的消息，发送方已经将消息成功发送到了MQ服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成"暂不能投递"状态，处于该种状态下的消息即半消息。