与Kafka类似，RocketMQ也使用了零拷贝技术、对于分区，其也有分队列的思维在。
零拷贝技术
传统的IO读写其实就是read+write的操作，整个过程会分为如下几步
- 用户调用read()方法，开始读取数据，此时发生一次上下文从用户态到内核态的切换，也就是图示的切换1，将磁盘数据通过DMA拷贝到内核缓存区。
- 将内核缓存区的数据拷贝到用户缓冲区，这样用户，也就是我们写的的代码就能拿到文件的数据read()方法返回，此时就会从内核态切换到用户态，也就是图示的切换2
- 当我们拿到数据之后，就可以调用write()方法，此时上下文会从用户态切换到内核态，即图示切换3，CPU将用户缓冲区的数据拷贝到Socket缓冲区，将Socket缓冲区数据拷贝至网卡
- write()方法返回，上下文重新从内核态切换到用户态，即图示力换4
整个过程发生了4次上下文切换和4次数据的拷贝，这在高并发场景下肯定会严重影响读写性能故引入了零拷贝技术。
mmap
mmap(memory map)是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。
简单地说就是内核缓冲区和应用缓冲区共享,从而减少了从读缓冲区到用户缓冲区的一次CPU拷贝。基于此上述架构图可变为:
基于mmapIO读写其实就变成mmap+write的操作，也就是用mmap替代传统IO中的read操作。
- 当用户发起mmap调用的时候会发生上下文切换1，进行内存映射，然后数据被拷贝到内核缓冲区，建立文件磁盘地址的引用，返回给用户缓冲区
- mmap返回，发生上下文切换2，返回内文件磁盘地址的引用
- 随后用户调用write，发生上下文切换3，将地址传递，CPU直接将内核缓冲区的数据拷贝到Socket缓冲区，write返回，发生上下文切换4
但这种方式，仅适合数据的编辑工作，在用户缓冲区无法对数据进行读，但可以写。
sendfile
sendfile()跟 mmap()一样，也会减少一次 CPU 拷贝，但是它同时也会减少两次上下文切换。
如图，用户在发起sendfile()调用时会发生切换1，之后数据通过DMA拷贝到内核缓冲区，之后再将内核缓冲区的数据CPU拷贝到Socket缓冲区，最后拷贝到网卡，sendfile()返回，发生切换2。发生了3次拷贝和两次切换。
这种方式无法对文件有读写操作，而是直接将文件的数据传输到target目标缓冲区，也就是说，sendfile是无法知道文件的具体的数据的。
但是mmap不一样，他是可以修改内核缓冲区的数据的。假设如果需要对文件的内容进行修改之后再传输，只有mmap可以满足。
通过上面的一些介绍，结论是基于零拷贝技术，可以减少CPU的拷贝次数和上下文切换次数，从而可以实现文件高效的读写操作。
RocketMQ内部主要是使用基于mmap实现的零拷贝(其实就是是调用上述提到的api)，用来读写文件，这也是RocketMQ为什么快的一个很重要原因。
集群方式
RocketMQ有3种集群模式，分别是单Master模式、多Master模式以及多Master多Slave模式。
-
单Master集群：这是一种最简单的集群方式，只包含一个Master节点和若干个Slave节点。所有的写入操作都由Master节点负责处理，Slave节点主要用于提供读取服务。当Mastter节点宕机时，集群将无法继续工作。
-
多Master集群：这种集群方式包含多个Master节点，不部署Slave节点。这种方式的优点是配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠；消息也不会丢(异步刷盘丢失少量消息，同步刷盘一条不丢)，性能最高；缺点是单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
-
多Master多Slave集群：这种集群方式包含多个Master节点和多个Slave节点。每个Master节点都可以处理写入操作，并且有自己的一组Slave节点。当其中一个Master节点宕机时，消费者仍然可以从Slave消费。优点是数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务务可用性与数据可用性都非常高；缺点是性能比异步复制模式略低(大约低10%左右)，发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。
