Namesrv
就是一个注册中心，存储当前集群所有Brokers信息、Topic跟Broker的对应关系。
Namesrv用于存储Topic、Broker关系信息，功能简单，稳定性高。多个Namesrv之间相互没有通信，单台Namesrv宕机不影响其他Namesrv与集群；即使整个Namesrv集群宕机，已经正常工作的Producer，Consumer，Broker仍然能正常工作，但新起的Producer, Consumer，Broker就无法工作。
Namesrv压力不会太大，平时主要开销是在维持心跳和提供Topic-Broker的关系数据。但有一点需要注意，Broker向Namesr发心跳时，会带上当前自己所负责的所有Topic信息，如果Topic个数太多（万级别），会导致一次心跳中，就Topic的数据就几十M，网络情况差的话，网络传输失败，心跳失败，导致Namesrv误认为Broker心跳失败。
nameserver是rocketmq自己实现的配置服务器，不是Zookeeper。
高性能顺序写盘
所有Topic数据同时只会写一个文件，一个文件满1G，再写新文件，真正的顺序写盘，使得发消息TPS大幅提高。
顺序写盘指的是写磁盘上的文件采用顺序写的方式，我们先了解一下磁盘操作的过程，主要分为三个动作：
- 寻道：磁头移动定位到指定磁道，时间很长，是指找到数据在哪个地方
- 旋转延迟：等待指定扇区旋转到磁头下，机械硬盘和每分钟多少转有关系，时间很短
- 数据传输：数据通过系统总线从磁盘传送到内存，时间很短
磁盘读写最慢的动作是寻道，缩短寻道时间就能在一定程度上有效提升磁盘的读写速度，最优的方式就是不用寻道，随机写会导致磁头不停的更换磁道，时间都花在寻道上了，顺序写几乎不用换磁道，或者寻道时间很短
负责存储消息数据的文件是CommitLog，所有的Topic的消息都会先存在/store/commitlog这个目录下，消息数据的写入是加锁串行追加写入的方式
RocketMQ为了保证消息的性能和吞吐量，用了一个文件存储所有的Topic消息，利用这一点来保证消息的存储是完全按照磁盘顺序写的，但是这样很明显有一定的问题，所有的消息都放在一个文件里，那必然这个文件会很大，虽然MQ默认CommitLog文件是1G，当1G完了之后会新创建一个文件继续记录消息，这样会对消息的消费造成很大的困难，这个CommitLog文件名按照文件起始的总的字节偏移量offset命令的，文件名固定长度是20位，不足20位的会在前面用0补上
第一个文件默认是20位的0：00000000000000000000
第二个文件的计算偏移量是102410241024=1073741824也就是1G=1073741724，所以文件名是000000000001073741824
这样命名规范是为了在消费消息的时候能够根据偏移量的offset快速定位到消息存储在哪一个CommitLog文件中，从而加快检索速度
版权归原作者 怎么又有bug单 所有， 如有侵权，请联系我们删除。