1. 应用场景
适用于大存储量，顺序消息，广播和日志数据传输的场景。设计理念类似kafka，场景类似。和kafak的一些差异如下，可以考虑差异使用：
文本协议设计，透明。纯java实现，kafka是scala实现。提供事务支持，包括本地事务和XA分布式事务。Kakfa不支持分布式事务支持HA复制，包括异步复制和同步复制，保证消息的可靠性。Kafka也都支持。支持同步和异步刷盘，kakfa只支持异步多种offset存储支持，Kafka是zookeeper。需要大量的topic，kafka对多topic的性能影响比较大，而metaq相对较好。实时性要求比较高。消息局部有序，基于partition顺序消费。但如果consumer有多线程会出现乱序。
2. 产品特性
因为metaq主要实现和kafka原理相似，产品特性可以参考kafak，这里主要列出两个产品的差异点：
3. 逻辑架构
支持发布订阅模式消息类型是message
4. 存储架构
消息持久存储metaq 将消息存储在本地文件中,每个文件最大大小为 1G,如果写入新的消息时,超过当前文件大 小,则会自动新建一个文件。文件名称为起始字节大小 。即使一个 broker 为多个 topic 服务,这些 topic 的消息都存储同一个文件组中,消息顺序写入,永远 都是当前文件在写,其他文件只读broker 将消息存储到文件后,会将该消息在文件的物理位置,消息大小,消息类型封装成一个固定大 小的数据结构,暂且称这个数据结构为索引单元吧,大小固定为 16k,消息在物理文件的位置称为 offset。多个索引单元组成了一个索引文件,索引文件默认固定大小为 20M,和消息文件一样,文件名是 起始字节位置,写满后,产生一个新的文件。由于meta把kafka中一个partion一个文件夹的思路，转变成了多个partition共享一个文件，实现真正的顺序写。所以可以支持更多的topic和partition。
5. 处理流程
处理数据流程： 根据 topic 和 partition 找到逻辑队列:A 根据 offset 从 A 定位指定的索引文件:B 从 B 中读取所有的索引数据:C 遍历 C,根据索引单元的消息物理地址和消息长度,找到物理消息 D,将 D 放入集合,并计 算消息的累加长度,若大于请求里消息最大长度 maxSize,则终止遍历,返回结果。 生产者的数据直接写入磁盘。（有可能在os的缓存中）。通过同步策略刷新进磁盘。
6. 分布架构
由于异步复制导致slave数据的可能缺失。写入必须通过master，读取可以slave。也可以把slave升级为maste。当maste重启后变为salve。默认实现。7. zookeeper架构
ids /meta/brokers/ids/m1/master/meta/brokers/ids/m1/slaves1/meta/brokers/ids/m1/slaves2 topics meta/brokers/topics/hello/m1-m/meta/brokers/topics/hello/m2-m/meta/brokers/topics/hello/s1-s/meta/brokers/topics/hello/s2-spartion数据存储在节点的数据中分组信息存储 /meta/consumers/hellogroup/ids/hellogroup_c1 节点数据为“hello1,hello2”/meta/consumers/hellogroup/ids/hellogroup_c2 节点数据为"hello2,hello3"分组消费的位置存储 /meta/consumers/hellogroup/offsets/t1/b1-1数据为 1 。/meta/consumers/hellogroup/offsets/t1/b1-2数据为 2 。/meta/consumers/hellogroup/offsets/t1/b2-1数据为 3 。/meta/consumers/hellogroup/offsets/t1/b2-2数据为 4 。group 和 topic 是变量,以实际值为准。t,b分别为topic，broker，数字为位置。
8. 性能评估
Kafka单机写入TPS约在百万条/秒，消息大小10个字节。RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节。Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。
Metaq为什么没有进行合并发送：
Producer通常使用Java语言，缓存过多消息，GC是个很严重的问题Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。缓存的功能完全可以由上层业务完成。
Topic数的增加对RocketMQ无影响，长时间运行服务非常稳定。Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长。RocketMQ单机支持最高5万个队列，Load不会发生明显变化。
阿里云招聘，欢迎技术大牛加入：chris.yxd@alibaba-
