消息队列Rocket的特性和特点和功能

(1) 订阅与发布
消息的发布是指某个生产者向某个topic发送消息；消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息。

(2) 消息顺序
消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。RocketMQ可以严格的保证消息有序。

(3) 消息过滤
费者可以根据Tag进行消息过滤，也支持自定义属性过滤。消息过滤目前是在Broker端实现的，优点是减少了对于Consumer无用消息的网络传输，缺点是增加了Broker的负担、而且实现相对复杂。

(4) 消息可靠性
RocketMQ支持消息的高可靠，影响消息可靠性的几种情况：
1)Broker非正常关闭
2)Broker异常Crash
3)OS(操作系统) Crash
4)机器掉电，但是能立即恢复供电情况
5)机器无法开机(可能是cpu/主板/内存等关键设备损坏)
6)磁盘设备损坏

  前四种情况属于硬件资源可立即恢复情况，RocketMQ在这四种情况下能保证消息不丢，或者丢失少量数据(依赖刷盘方式是同步还是异步)。5和6属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，如与Money相关的应用。注：RocketMQ从3版本开始支持同步双写。

(5) 至少一次
至少一次(At least Once)指每个消息必须投递一次。Consumer先Pull消息到本地，消费完后，才向服务器返回ack，如果没有消费一定不会ack消息，所以RocketMQ可以很好的支持此特性。

(6) 回溯消费
指Consumer已经消费成功的消息，由于业务上需求需要重新消费，要支持此功能，Broker在向Consumer投递成功消息后，消息仍然需要保留。并重新消费一般是按照时间维度，如由于Consumer系统故障，恢复后需要重新消费1小时前的数据，那么Broker要提供一种机制，可以按照时间维度来回退消费进度。RocketMQ支持按照时间回溯消费，时间维度精确到毫秒。

(7) 事务消息
RocketMQ事务消息(Transactional Message)是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致性。

(8) 定时消息
定时消息(延迟队列)是指消息发送到broker后，不会立即被消费，等待特定时间投递给真正的topic。
broker配置项messageDelayLevel，默认值1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h，18个level。
messageDelayLevel是broker的属性，不属于某个topic。发消息时，设置delayLevel等级msg.setDelayLevel(level)。
level有三种情况：level == 0，消息为非延迟消息
1<=level<=maxLevel，消息延迟特定时间，如level1，延迟1
slevel > maxLevel，则level maxLevel，如level==20，延迟2h
定时消息会暂存在名为SCHEDULE_TOPIC_XXXX的topic中，并根据delayTimeLevel存入特定的queue，queueId = delayTimeLevel – 1，即一个queue只存相同延迟的消息，保证具有相同发送延迟的消息能够顺序消费。broker会调度地消费SCHEDULE_TOPIC_XXXX，将消息写入真实的topic。
定时消息会在第一次写入和调度写入真实topic时都会计数，因此发送数量、tps都会变高。

(9) 消息重试
Consumer消费消息失败后，要提供一种重试机制，令消息再消费一次。Consumer消费消息失败通常可以认为有以下几种情况：
1)由于消息本身的原因，如反序列化失败，消息数据本身无法处理(例如话费充值，当前消息的手机号被注销，无法充值)等。这种错误通常需要跳过这条消息，再消费其它消息，而这条失败的消息即使立刻重试消费，99%也不成功，所以最好提供一种定时重试机制，即过10秒后再重试。
2)由于依赖的下游应用服务不可用，例如db连接不可用，外系统网络不可达等。遇到这种错误，即使跳过当前失败的消息，消费其他消息同样也会报错。这种情况建议应用sleep 30s，再消费下一条消息，这样可以减轻Broker重试消息的压力。

(10)消息重投
生产者在发送消息时：
同步消息失败会重投
异步消息有重试
oneway没有任何保证。

   消息重投保证消息尽可能发送成功、不丢失，但可能会造成消息重复，消息重复在RocketMQ中是无法避免的问题。消息重复在一般情况下不会发生，当出现消息量大、网络抖动，消息重复就会是大概率事件。另外，生产者主动重发、consumer负载变化也会导致重复消息。
   如下方法可以设置消息重试策略：
      1)retryTimesWhenSendFailed：同步发送失败重投次数，默认为2，因此生产者会最多尝试发送retryTimesWhenSendFailed+ 1次。不会选择上次失败的broker，尝试向其他broker发送，最大程度保证消息不丢失。超过重投次数，抛异常，由客户端保证消息不丢失。当出现RemotingException、MQClientException和部分MQBrokerException时会重投。      
      2)retryTimesWhenSendAsyncFailed：异步发送失败重试次数，异步重试不会选择其他broker，仅在同一个broker上做重试，不保证消息不丢。
      3)retryAnotherBrokerWhenNotStoreOK：消息刷盘(主或备)超时或slave不可用(返回状态非SEND_OK），是否尝试发送到其他broker，默认false。十分重要消息可以开启。

(11) 流量控制

 1) 生产者流控，broker处理能力达到瓶颈
       commitLog文件被锁时间超过osPageCacheBusyTimeOutMills时，参数默认为1000ms，发生流控。
      若开启transientStorePoolEnable=true，且broker为异步刷盘，且transientStorePool资源不足，拒绝send请求，发生流控。
      broker每隔10ms检查send请求队列头部请求的等待时间，如果超过waitTimeMillsInSendQueue，默认200ms，拒绝当前send请求，发生流控。broker通过拒绝send 请求方式实现流量控制。注意，生产者流控，不会尝试消息重投。
2) 消费者流控：消费能力达到瓶颈
      消费者本地缓存消息数超过pullThresholdForQueue时，默认1000。
      消费者本地缓存消息大小超过pullThresholdSizeForQueue时，默认100MB。
      消费者本地缓存消息跨度超过consumeConcurrentlyMaxSpan时，默认2000。
     消费者流控的结果是降低拉取频率。

12 死信队列
死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，消息队列不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。RocketMQ将这种正常情况下无法被消费的消息称为死信消息(Dead-Letter Message)，将存储死信消息的特殊队列称为死信队列(Dead-Letter Queue)。在RocketMQ中，可以通过使用console控制台对死信队列中的消息进行重发来使得消费者实例再次进行消费。