Kafka和MetaQ之对比
Kafka和MetaQ存储机制
Kafka存储机制
Kafka和MetaQ一样，都是采用topic作为发布和订阅的主题，topic是个逻辑概念，而partition是物理上面的概念，每个partition对应一个log文件，该log文件中存储的就是producer生产的数据。producer生产的数据会被不断追加到log文件的末端，且每条数据都有自己的offset。
每个Partition都会有自己的副本，Kafka会尽量的使所有的分区均匀的分布到集群中的所有节点而不是集中在某些节点上，另外主从关系也尽量均衡这样每个几点都会担任一定比例的分区的leader。
每个partition以目录的形式存储在broker上，该目录底下存储着的是该partition内容被平均分配成的多个大小相等的数据文件，我们称之为segment(段)。每个segment文件分为两个部分，index file和data file，此两个文件一一对应，后缀".index"和".log"分别表示segment的索引文件和数据文件。文件的命名规则为partition全局的第一个segment为0开始，后续每个segment文件名为上一个全局partion的最大offset(偏移message数)。每个segment中存储很多条消息，消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。
segment index file采取稀疏索引存储方式，它减少索引文件大小，通过mmap可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针,先通过index文件中获取该message的一个位置范围，然后根据这个位置范围在log文件中找到该message的信息。
MetaQ存储机制
MetaQ的消息存储方式和kafka的partition存放方式类似，在MetaQ中消息的存放分为物理队列和逻辑队列。
物理队列：物理队列我们一般用commitlog来表示，在一个broker上面，所有发到broker上的信息都会按顺序写入物理队列中，物理队列又由许多文件组成，当一个文件被写满（默认大小为1G）时，则创建一个新的文件继续写入，文件以offset的方式来命名，与kafka中的partition命名类似。
逻辑队列：逻辑队列我们一般用consumequeue来表示，在消息被写入物理队列之后，如果消费端想从broker拉取消息，就需要一个索引文件，MetaQ中将每个Topic分为了几个区，每个区对应了一个消费队列，不过这些消费队列只是由一个个索引文件组成。消费端在拉取消息的时候，只要知道自己订阅的Topic从nameserver获取broker地址建立连接之后，就能根据消费队列中的索引文件，去物理队列中获取订阅的消息。
CommitLog以物理文件的方式存放，每台Broker上的CommitLog被本机器上所有的ConsumeQueue共享。在CommitLog中，一个消息的存储长度是不固定的，MetaQ中采取了一些机制，尽量往CommitLog中顺序写，但是可以支持随机读。ConsumeQueue的内容也会被写到磁盘里进行持久存储，但是ConsumeQueue的内容是通过异步刷盘的方式进行。
为什么MetaQ需要采用这种存储架构呢？
我们知道，磁盘的顺序写比随机写的速度快的很多，目前的高性能磁盘，顺序写的速度可以达到600MB/s，超过了一般的网卡的传输速度，但是磁盘的随机写的速度只有大概100KB/s，和顺序写的性能相差了6000倍，而MetaQ正是利用磁盘顺序写的优势来设计的。
上文说到，MetaQ的主要存储文件包括CommitLog、ConsumeQueue文件，在一个Broker节点上，MetaQ会将所有Topic的消息存储在同一个文件commitlog中，这样能确保producer发送的消息顺序写入commitlog中，能够尽最大的能力确保消息发送的高性能和高吞吐量，接收消息的时候，只有CommitLog是需要同步落盘的。同时使用ConsumeQueue消息队列文件来作为索引文件，每个Topic包含有多个消息消费队列，每一个消息队列就有一个ConsumeQueue消息文件，ConsumeQueue是异步保存的，不需要同步落盘，如果在没有落盘的时候，broker发生宕机，MetaQ可以根据CommitLog来恢复ConsumeQueue。
虽然说在同一个broker上面由于不同的ConsumeQueue访问同一个CommitLog，CommitLog是进行随机读的，但是根据操作系统的局部性原理，也利用操作系统的分页机制，可以批量的从磁盘中获取CommitLog的信息，然后缓存到内存中，更快的进行读取。而对于ConsumeQueue，由于其内部只保存数据的索引信息，所以一般其数据量不大，可以全部读入内存，所以我们可以认为从ConsumeQueue这个中间结构获取数据很快，可以当成从内存读取数据的速度。
在kafka中，当如果一个broker上面有多个partition，如果多个partition并发写入数据，磁盘的访问会有很大的瓶颈，多个文件之间必然会有磁盘的寻道。而MetaQ对于数据来说就只有单文件写入，性能上将优于kafka。
MetaQ为什么不像Kafka使用zk作为元数据节点，而要使用自己实现的NameServer？
我们知道，kafka使用zk作为元数据节点，起到了Broker注册、Topic注册、生产者和消费者负载均衡以及使用zk进行leader角色的选举，当leader所在的broker挂了，将会经过以下两步操作重新选举leader：第1步，先通过Zookeeper在所有机器中，选举出一个KafkaController；第2步，再由这个Controller，决定每个partition的Master是谁，Slave是谁。因为有了选举功能，所以kafka某个partition的master挂了，该partition对应的某个slave会升级为主对外提供服务。
MetaQ不具备选举，Master/Slave的角色也是固定的。当一个Master挂了之后，你可以写到其他Master上，但不能让一个Slave切换成Master。那么MetaQ是如何实现高可用的呢，其实很简单，MetaQ的所有broker节点的角色都是一样，上面分配的topic和对应的queue的数量也是一样的，MetaQ只能保证当一个broker挂了，把原本写到这个broker的请求迁移到其他broker上面，而并不是这个broker对应的slave升级为主。
引入zk的主要目的是为了选主，kafka中如果一个broker挂了，这个broker上面的主partition可以通过zk的选举机制在其他broker上面选举主partition，而对于MateQ而言，在部署的时候已经决定了这个Broker是主或者是备了（一个Master可以对接多个Slave，但是一个Slave只能对接一个Master，Master与Slave之间可以通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，不为0的表示Slave），不能再通过选举变成主（认命吧，无法上位的），所以对于MetaQ，是不需要进行选举的，为了方便集群维护，直接使用NameServer这一个轻量级工具来存储元数据信息即可。
