企业建设网站 入账,科技软件下载,办公用品网站建设可行性分析,快速建站代理存储架构RMQ存储架构上图即为RocketMQ的消息存储整体架构#xff0c;RocketMQ采用的是混合型的存储结构#xff0c;即为Broker单个实例下所有的队列共用一个日志数据文件(即为CommitLog#xff0c;1G)来存储。Consume Queue相当于kafka中的partition#xff0c;是一个逻辑队…存储架构RMQ存储架构上图即为RocketMQ的消息存储整体架构RocketMQ采用的是混合型的存储结构即为Broker单个实例下所有的队列共用一个日志数据文件(即为CommitLog1G)来存储。Consume Queue相当于kafka中的partition是一个逻辑队列存储了这个Queue在CommiLog中的 起始offsetlog大小和MessageTag的hashCode。每次读取消息队列先读取consumerQueue,然后再通过consumerQueue去commitLog中拿到消息主体。Kafka存储架构rocketMQ的设计理念很大程度借鉴了kafka所以有必要介绍下kafka的存储结构设计:存储特点 和RocketMQ类似每个Topic有多个partition(queue),kafka的每个partition都是一个独立的物理文件消息直接从里面读写。根据之前阿里中间件团队的测试一旦kafka中Topic的partitoin数量过多队列文件会过多会给磁盘的IO读写造成很大的压力造成tps迅速下降。所以RocketMQ进行了上述这样设计consumerQueue中只存储很少的数据消息主体都是通过CommitLog来进行读写。ps上一行加粗理解consumerQueue存储少量数据即使数量很多但是数据量不大文件可以控制得非常小绝大部分的访问还是Page Cache的访问而不是磁盘访问。正式部署也可以将CommitLog和consumerQueue放在不同的物理SSD避免多类文件进行IO竞争。RMQ存储设计优缺点优点队列轻量化单个队列数据量非常少。对磁盘的访问串行化避免磁盘竟争不会因为队列增加导致IOWAIT增高。缺点写虽然完全是顺序写但是读却变成了完全的随机读。读一条消息会先读ConsumeQueue再读CommitLog增加了开销。要保证CommitLog与ConsumeQueue完全的一致增加了编程的复杂度。缺点克服随机读尽可能让读命中page cache减少IO读操作所以内存越大越好。如果系统中堆积的消息过多读数据要访问磁盘会不会由于随机读导致系统性能急剧下降答案是否定的。访问page cache 时即使只访问1k的消息系统也会提前预读出更多数据在下次读时就可能命中内存。随机访问Commit Log磁盘数据系统IO调度算法设置为NOOP方式会在一定程度上将完全的随机读变成顺序跳跃方式而顺序跳跃方式读较完全的随机读性能会高5倍以上。另外4k的消息在完全随机访问情况下仍然可以达到8K次每秒以上的读性能。由于Consume Queue存储数据量极少而且是顺序读在PAGECACHE预读作用下Consume Queue的读性能几乎与内存一致即使堆积情况下。所以可认为Consume Queue完全不会阻碍读性能。Commit Log中存储了所有的元信息包含消息体类似于Mysql、Oracle的redolog所以只要有Commit Log在Consume Queue即使数据丢失仍然可以恢复出来。RMQ存储底层实现MappedByteBufferRocketMQ中的文件读写主要就是通过MappedByteBuffer进行操作来进行文件映射。利用了nio中的FileChannel模型可以直接将物理文件映射到缓冲区提高读写速度。这种Mmap的方式减少了传统IO将磁盘文件数据在操作系统内核地址空间的缓冲区和用户应用程序地址空间的缓冲区之间来回进行拷贝的性能开销。这里需要注意的是采用MappedByteBuffer这种内存映射的方式有几个限制其中之一是一次只能映射1.5~2G 的文件至用户态的虚拟内存这也是为何RocketMQ默认设置单个CommitLog日志数据文件为1G的原因了。page cache刚刚提到的缓冲区也就是之前说到的page cache。通俗的说pageCache是系统读写磁盘时为了提高性能将部分文件缓存到内存中下面是详细解释page cache:这里所提及到的page cache在我看来是linux中vfs虚拟文件系统层的cache层一般pageCache默认是4K大小它被操作系统的内存管理模块所管理文件被映射到内存一般都是被mmap()函数映射上去的。mmap()函数会返回一个指针指向逻辑地址空间中的逻辑地址逻辑地址通过MMU映射到page cache上。上图中整个OS有3.7G的物理内存用掉了2.7G应当还剩下1G空闲的内存但OS给出的却是175M。因为OS发现系统的物理内存有大量剩余时为了提高IO的性能就会使用多余的内存当做文件缓存也就是图上的buff / cache广义我们说的Page Cache就是这些内存的子集。pageCache缺点内核把可用的内存分配给Page Cache后free的内存相对就会变少如果程序有新的内存分配需求或者缺页中断恰好free的内存不够内核还需要花费一点时间将热度低的Page Cache的内存回收掉对性能非常苛刻的系统会产生毛刺。RMQ发送、消费逻辑发送逻辑发送时Producer不直接与Consume Queue打交道。上文提到过RMQ所有的消息都会存放在Commit Log中为了使消息存储不发生混乱对Commit Log进行写之前就会上锁。消息持久被锁串行化后对Commit Log就是顺序写也就是常说的Append操作。配合上Page CacheRMQ在写Commit Log时效率会非常高。Broker端的后台服务线程—ReputMessageService不停地分发请求并异步构建ConsumeQueue(逻辑消费队列)和IndexFile(索引文件)数据不停的轮询将当前的consumeQueue中的offSet和commitLog中的offSet进行对比将多出来的offSet进行解析然后put到consumeQueue中的MapedFile中。ConsumeQueue(逻辑消费队列)作为消费消息的索引保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset消息大小size和消息Tag的HashCode值。而IndexFile(索引文件)则只是为了消息查询提供了一种通过key或时间区间来查询消息的方法(ps这种通过IndexFile来查找消息的方法不影响发送与消费消息的主流程)。消费逻辑消费时Consumer不直接与Commit Log打交道而是从Consume Queue中去拉取数据。拉取的顺序从旧到新在文件表示每一个Consume Queue都是顺序读充分利用了Page Cache。光拉取Consume Queue是没有数据的里面只有一个对Commit Log的引用所以再次拉取Commit Log。但整个RMQ只有一个Commit Log虽然是随机读但整体还是有序地读只要那整块区域还在Page Cache的范围内还是可以充分利用Page Cache。(dstat命令)对于CommitLog消息存储的日志数据文件来说读取消息内容时候会产生较多的随机访问读取严重影响性能。如果选择合适的系统IO调度算法比如设置调度算法为“Noop”(此时块存储采用SSD的话)随机读的性能也会有所提升。刷盘方式同步刷盘在消息真正落盘后才返回成功给Producer只要磁盘没有损坏消息就不会丢。一般只用于金融场景。异步刷盘读写文件充分利用了Page Cache即写入Page Cache就返回成功给ProducerRMQ中有两种方式进行异步刷盘整体原理是一样的。RMQ文件存储模型层RocketMQ文件存储模型层次结构如上图所示根据类别和作用从概念模型上大致可以划分为5层下面将从各个层次分别进行分析和阐述(1)RocketMQ业务处理器层Broker端对消息进行读取和写入的业务逻辑入口这一层主要包含了业务逻辑相关处理操作(根据解析RemotingCommand中的RequestCode来区分具体的业务操作类型进而执行不同的业务处理流程)比如前置的检查和校验步骤、构造MessageExtBrokerInner对象、decode反序列化、构造Response返回对象等。(2)RocketMQ数据存储组件层该层主要是RocketMQ的存储核心类—DefaultMessageStore其为RocketMQ消息数据文件的访问入口通过该类的“putMessage()”和“getMessage()”方法完成对CommitLog消息存储的日志数据文件进行读写操作(具体的读写访问操作还是依赖下一层中CommitLog对象模型提供的方法)另外在该组件初始化时候还会启动很多存储相关的后台服务线程包括AllocateMappedFileService(MappedFile预分配服务线程)、ReputMessageService(回放存储消息服务线程)、HAService(Broker主从同步高可用服务线程)、StoreStatsService(消息存储统计服务线程)、IndexService(索引文件服务线程)等。(3)RocketMQ存储逻辑对象层该层主要包含了RocketMQ数据文件存储直接相关的三个模型类IndexFile、ConsumerQueue和CommitLog。IndexFile为索引数据文件提供访问服务ConsumerQueue为逻辑消息队列提供访问服务CommitLog则为消息存储的日志数据文件提供访问服务。这三个模型类也是构成了RocketMQ存储层的整体结构(对于这三个模型类的深入分析将放在后续篇幅中)。(4)封装的文件内存映射层RocketMQ主要采用JDK NIO中的MappedByteBuffer和FileChannel两种方式完成数据文件的读写。其中采用MappedByteBuffer这种内存映射磁盘文件的方式完成对大文件的读写在RocketMQ中将该类封装成MappedFile类。这里限制的问题在上面已经讲过对于每类大文件(IndexFile/ConsumerQueue/CommitLog)在存储时分隔成多个固定大小的文件(单个IndexFile文件大小约为400M、单个ConsumerQueue文件大小约5.72M、单个CommitLog文件大小为1G)其中每个分隔文件的文件名为前面所有文件的字节大小数1即为文件的起始偏移量从而实现了整个大文件的串联。这里每一种类的单个文件均由MappedFile类提供读写操作服务(其中MappedFile类提供了顺序写/随机读、内存数据刷盘、内存清理等和文件相关的服务)。(5)磁盘存储层主要指的是部署RocketMQ服务器所用的磁盘。这里需要考虑不同磁盘类型(如SSD或者普通的HDD)特性以及磁盘的性能参数(如IOPS、吞吐量和访问时延等指标)对顺序写/随机读操作带来的影响。
