metaQ消息队列，它是rocketMQ的升级版，加上了淘宝的自主定制
一 普通消息的使用
其中生产者发送普通消息值得注意的几个点：
- ProducerGroupName需要由应用来保证唯一，发送普通的消息时，作用不大，但是发送分布式事务消息时，比较关键，因为服务器会回查这个Group下的任意一个Producer。
- 一个生产者可以发送多个topic和多个tag。
- 同步调用不抛异常就算成功。
- 消息队列的send方法会返回一个多种的成功状态，用于可靠性更高的场景。包括master成功，slave不成功等。
其中消费者订阅普通消息值得注意的几个点：
- 内部是使用长轮询Pull方式从MetaQ服务器拉消息，然后再回调用户Listener方法。
- 监听器内默认一条消息，如果是多条消息，要么都成功，要么都失败。
- 多个线程回调时，要由应用来保证它的并发安全性。
- 失败会进行重试。
二 metaQ可以保证消息的顺序性
顺序消息
消费消息的顺序要同发送消息的顺序一致，在 RocketMQ 中，主要指的是局部顺序，即一类消息为满足顺 序性，必须 Producer 单线程顺序发送，且发送到同一个队列，这样 Consumer 就可以按照 Producer 发送 的顺序去消费消息。
普通顺序消息
顺序消息的一种，正常情况下可以保证完全的顺序消息，但是一旦发生通信异常，Broker 重启，由于队列 总数发生变化，哈希取模后定位的队列会变化，产生短暂的消息顺序不一致。 如果业务能容忍在集群异常情况（如某个 Broker 宕机或者重启）下，消息短暂的乱序，使用普通顺序方 式比较合适。
严格顺序消息
顺序消息的一种，无论正常异常情况都能保证顺序，但是牺牲了分布式 Failover 特性，即 Broker 集群中只 要有一台机器不可用，则整个集群都不可用，服务可用性大大降低。 如果服务器部署为同步双写模式，此缺陷可通过备机自动切换为主避免，不过仍然会存在几分钟的服务不 可用。（依赖同步双写，主备自动切换，自动切换功能目前还未实现） 目前已知的应用只有数据库 binlog 同步强依赖严格顺序消息，其他应用绝大部分都可以容忍短暂乱序，推 荐使用普通的顺序消息
三 消费方式
- 集群消费，一条消息只会被同一个group里一个消费端消费。不同group之间相互不影响。
- 广播消费，一条消息会被同一个group里每一个消费端消费，但是广播消费代价很大，需要投送很多，另外不支持广播的重试。
四 metaQ不能保证消息的重复性
原因：生产者分布式超时的问题，消费者意外宕机，进度未及时储存。
解决：应用方收到消息后，可通过Tair、DB等去重。
五 metaQ的消息重试
- 非顺序消息消费失败重试，消费失败的消息发回服务器，应用可以指定这条失败消息下次到达Consumer的时间。消费失败重试次数有限制，通常线上为每个订阅组每条失败消息重试5次（每次消息都会定时重试，定时时间随着重试次数递增，此过程应用可干预）。超过重试次数，消息进入死信队列，并向用户报警。
- 消息重试对于服务器代价较高，如果某个应用消息量非常大，且失败率非常高，需要大量重试，则不建议使用MetaQ
- 顺序消息消费失败重试，某个队列正在消费的消息消费失败，会将当前队列挂起（挂起时间应用可通过API设置），其他队列仍然正常消费。
六 死信队列
消息一旦进入死信队列，则不再向应用投递，MetaQ监控系统会向应用报警 （报警功能开发中）
由于消息一旦进入死信队列，则不能再被订阅，建议应用在最后一次重试消费时，将失败消息保存到DB
七 消息堆积能力
MetaQ每台服务器提供大约亿级的消息堆积能力（多个业务方共用），超过堆积阀值，订阅消息吞吐量会下降。
八 实时性
MetaQ采用了长轮询方式从Broker拉消息，实时性同Push方式一致，消息的延迟时间大约几毫秒左右。
九 metaQ与rocketMq
com.taobao.metaq v3.0 = RocketMQ + 淘宝个性化需求
十 消息的优先级
对于优先级问题，可以归纳为 2 类
1) 只要达到优先级目的即可，不是严格意义上的优先级，通常将优先级划分为高、中、低，或者再多几个级 别。每个优先级可以用不同的 topic 表示，发消息时，指定不同的 topic 来表示优先级，这种方式可以解决 绝大部分的优先级问题，但是对业务的优先级精确性做了妥协。
2) 严格的优先级，优先级用整数表示，例如 0 ~ 65535，这种优先级问题一般使用不同 topic 解决就非常不合 适。如果要让 MQ 解决此问题，会对 MQ 的性能造成非常大的影响。这里要确保一点，业务上是否确实需 要这种严格的优先级，如果将优先级压缩成几个，对业务的影响有多大？（可以放入之前进行排序，优先级高的先放入队列，但这个时候又要保证顺序性）
十一 消息的过滤
Broker 端消息过滤
在 Broker 中，按照 Consumer 的要求做过滤，优点是减少了对于 Consumer 无用消息的网络传输。 缺点是增加了 Broker 的负担，实现相对复杂。
Consumer 端消息过滤
这种过滤方式可由应用完全自定义实现，但是缺点是很多无用的消息要传输到 Consumer 端。
十二 回溯消费
回溯消费是指 Consumer 已经消费成功的消息，由于业务上需求需要重新消费，要支持此功能，Broker 在向 Consumer 投递成功消息后，消息仍然需要保留。并且重新消费一般是按照时间维度，例如由于 Consumer 系统故障， 恢复后需要重新消费 1 小时前的数据，那么 Broker 要提供一种机制，可以按照时间维度来回退消费进度。
十三 分布式事务
十四 定时消息
RocketMQ 支持定时消息，但是不支持任意时间精度，支持特定的 level，例如定时 5s，10s，1m 等。
十五 组的概念
Producer Group
用来表示一个发送消息应用，一个 Producer Group 下包含多个 Producer 实例，可以是多台机器，也可以 是一台机器的多个进程，或者一个进程的多个 Producer 对象。一个 Producer Group 可以发送多个 Topic 消息，Producer Group 作用如下：
1. 标识一类 Producer
2. 可以通过运维工具查询这个发送消息应用下有多个 Producer 实例
3. 发送分布式事务消息时，如果 Producer 中途意外宕机，Broker 会主动回调 Producer Group 内的任意 一台机器来确认事务状态。
Consumer Group
用来表示一个消费消息应用，一个 Consumer Group 下包含多个 Consumer 实例，可以是多台机器，也可 以是多个进程，或者是一个进程的多个 Consumer 对象。一个 Consumer Group 下的多个 Consumer 以均摊 方式消费消息，如果设置为广播方式，那么这个 Consumer Group 下的每个实例都消费全量数据。
十六 外部角度
十七 内部角度
十八 使用
发送消息可以将内容封装在一个util工具类中，调用这个工具类就可以实现消息的发送。（其实很多中间件的实现都是分为部署和使用两步，可以在util中把它部署好了，然后封装在工具类中，那么就可以直接使用了，十分的方便，比如说缓存或者开关什么的，都可以）
接受消息的话，一般就是一个监听器，可以理解为有消息的时候就会调用这个方法。所以实现的时候，通常就是实现或者继承一个类或接口，然后实现对应的方法就可以了。