怎样算是理解了一套MQ中间件呢？原来一知半解的我列了几个维度：demo跑起来，理解其投递次数的语义，理解其事务的特性等等。这是一种角度，但总有种看山不是山的一知半解的感觉。再问一层，比如为什么Kafka吞吐量远胜于其他中间件，为什么说适合日志采集和流式计算的场景？就回答不上来了。学习终归是个积累的过程。

直到某一天看到阿里一篇挺常规的关于Notify和MetaQ的介绍，却突然茅塞顿开。当然了，其中不乏是做了一两个需求的缘故。故事是围绕着一下几个疑问展开的。

1.什么是消息中间件，解决了什么问题？Message Queue嘛，顾名思义就是排队。打个比方去快餐店点餐，每个人点餐可能只要10s，但如果三个人同时向服务员点餐，服务员就可能会乱了，三个顾客还可能会吵起来，这件事就没法30s内解决，那么很简单，排队点餐就好办了。所以MQ最核心的功能就是削峰蓄洪。其他特征则是围绕这一功能衍生出来的，比如如何维持排队的人不乱套（持久化和重发和事务支持），如何容纳更多的人排队（堆积能力），如果实在接待不了这么多人怎样让后来的人去其他地方安置（限流机制）等等。

2.MetaQ与Kafka的对比。名字缘由是说Metamorphosis变形记是向卡夫卡致敬。明明Kafka性能远胜于MetaQ，为什么还要造出个MetaQ呢？因为支持了tag过滤了啊，过滤的特性放在电商系统里对性能的提升比单机的吞吐量和堆积能力还更重要。也就是说，MetaQ加入的是更场景化的特性。

3.MetaQ与ActiveMQ的对比。侧重谈前者，后者遵循AMQP协议。MetaQ串行化写盘快（随机读可以做内存缓存），pull拉式订阅解放了broker的路由压力，逻辑队列只存索引信息非常轻。这里解决的问题，是性能的问题，持久化时如何写得快而准、如何读得快，消息堆积时如何能堆更多，投递时如何又灵活又快又省资源（cpu和带宽）。

4.JMS与AMQP。JMS是java接口规范。AMQP是跨越语言的MQ标准，并规划了路由到投递的分层设计。

5.共性。投递次数的语义完全是共性，基本都是至少投递一次的语义，要支持至多投递一次并不难但是场景很少，要支持准确投递一次很难且代价太大，何不让应用自己去做接口幂等。事务则是取舍，能支持事务的都会牺牲一些性能，不支持事务的一般都会更轻快。广播等其他特性，要看具体的应用场景。

所以，如何深入学习一套MQ中间件？围绕其持久化的形式（kv或串行写盘等等）、堆积的能力（队列的底层数据结构）、投递方式（push的路由规则或pull的寻址及过滤）就已经是很了解了。再加上个高可用主从模式，就几乎完全掌握了。