开发者学堂课程【消息队列 RocketMQ 5.0 云原生架构升级课程：RocketMQ 存储弹性- -冷热数据分级存储】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1234/detail/18404
Rocket MQ 存储单性--冷热数据分级存储
主要内容：
一、储存弹性
二、Rocket MQ 分级存储
三、分级存储适用场景
本次课程为大家讲解弹性运维系列的Rocket MQ储存弹性这一节课。本次课程主要介绍阿里云中间件团队在消息系统储存弹性的探索。关于让Rocket MQ商业版的空间按需使用按量服务的一些底层设计，如何低成本的实现动态磁盘扩缩容、如何实现消息冷热分离与压缩存档的功能。
本次课程主要从以下三个方面来展开，首先第一节是储存弹性，关于目前的一些磁盘扩容以及分布式存储的介绍，第二部分是Rocket MQ的分级存储，在connector以及基于commit log重分发两种实验方式。
最后一节是分级存储的一些适用场景，包括消息归档、冷热数据分离、数据压缩以及流计算。
一、储存弹性
首先介绍储存弹性，首先讲解比较常见的几种文件系统，或多或少都有扩容或者索引的一些工具，但是扩缩容只是针对于硬盘上的多个分区来进行扩缩容。
也就是说这些常见的文件系统，它们的扩容是有上限的，上限就是当前这块硬盘的最大空间。若想合并多块磁盘的空间到同一个分区上，这就需要利用到LVM系统，LVM是对逻辑卷管理的英文缩写，它是对磁盘分区进行管理的一种机制，Lvm是建立在磁盘分区和文件系统之间的一个逻辑层，运维人员可以利用Lvm在不对硬盘重新分区的情况下动态的调整分区大小。
如上图所示，后目目录实际是既使用了物理硬盘a，也使用物理硬盘b的空间。也就是说如果我想对控后目目录，或者可以将一块新的硬盘c挂在VG1上。但是这种扩容不是没有现成的，因为不管是物理机还是云厂商提供的虚拟机，挂载硬盘的数量是有限的，所以就需要提前规划储存空间。
下面用一个例子进行说明，现在有一块硬盘disk1，其中有2TB的容量，将它挂载到store上，如果现在store已经用了80%的容量。
若再挂载一个disk2，这样的话，储存空间占用就变成了40%，此时就有60%的空间是白白浪费的。
若想要减少浪费的空间，同为这个例子，现在disk1是挂载在store上，再挂载一个1TB的disk 2，此时当前的数字空间占用率是53%，只有47%的空间是浪费掉的。
但是随着业务的增长，储存空间占用率又到了80%，此时要再挂载一个disk 3，可以看到，虽然降低了对磁盘空间的浪费，但是同时也多占用了一个官能点。也就是使用Lvm系统做动态扩容时，需要提前规划储存空间，这样既能灵活的按需扩容，也不能无限的扩容下去，不符合计算所要求的按需使用按量付费这种空间的需求，就不得不提到分布式文件系统。
分布式文件系统是指U盘的物理资源并不直接挂载到机器上，而是使用fuse用户态文件系统等技术提供兼容posix 接口。比如比较出名如HDFS、Ceph 。这些分布式文件系统是基于网络的文件系统，向上层应用暴露了一些的兼容的posix 接口，然后再将上层应用的发过来的读写请求通过网络转发到真正的文件服务器上来执行所需要的数据方面。
内分布式文件系统是最小程度，相比于之前介绍的分布式文件系统的区别是它是APP来提供服务的。同时也具有一些与众不同的特性，比如支持无限的储存空间、文件一旦写入无法修改，如果想修改就只能重新上传改源文件。以前的相比于posix 提供的API所支持的文件操作就比较有限，特别是对于一些源数据的操作，比如建立文件的能力比较差，对象存储比其他的一些存储的最大优势是在于计费是按照储存空间的使用量来计费的。对于大多数云厂商而言，这项存储的价格是最为低廉的。下面介绍阿里云的几种本地盘，然后分布式文件系统以及对象存储的性能与价格的对比。
可以看到，本地盘的储存类型为块存储，它的性能是最佳的，但是价格也是最贵的，而NAS也就是分布式文件系统，它的延迟和带宽都要相比于本地盘稍差一些，但是它的价格也是要相对便宜一些。至于OSS，可以看到它明显的价格优势，相比于本地盘，是SSD云盘的10%左右。
二、Rocket MQ 分级存储
接下来介绍Rocket MQ如何使用分布式文件系统来构建分级存储。首先讲解阿里云上的编辑消息功能是如何使用的，分级存储是一个运维视角应该关心的事情，对于业务人员只需要考虑这条消息对于业务来说应该保留多长的时间，然后在控制台上根据需要修改这个消息存储的时长即可，对于客户端来说也是透明的。有不使用编辑消息的功能，并无需更改代码，并且计费方式也是按照储存容量按需按需使用按量付费的。
接下来介绍第一种基于connector 的实现。Rocket MQ connector是独立于Rocket MQ 的一个分布式数据支撑组件。将各种系统的数据通过高效可靠的方式，比如要构建一个数据管道。此数据管道通过broker转发到connector发布到OSS分布式文件系统或是其他的分布式文件系统中实现数据集群才能分析存储增加三个组件，第一个是DB，作为一个分布式协调组件，负责connector以及节点的选址，以及储存在分析存储上面的软件界面数据管理。第二个组件是connector ，使用consumer的方式来拉取broker上的消息，并且转发到二级文件存储中。当用户消费的时候，还是向broker发起请求，但是broker发现当前请求的数据是一个能数据，是储存在二级存储上的，那么它就会将这个请求转发给history node，然后history node再将数据从二级文件存储中拉取出来并返回给客户端。同时history node也会像broker注册来做实地发现。
第二种分析存储的实验方式是基于commit log重分发。也就是为commit log新增一个dispatch，如图中的OSS。当消息发到broker上的时候会先写入到commit log 中，然后再通过dispatch机制来鉴定。此时在dispatch的时候将消息转发到OSS upload里面，然后进行消息构建成所需要的top OSS组织的方式上传到OSS中。此基于commit log重分发的文件系统存储方式，兼容了上面提到的三个组件，通过commit log dispatch机制将消息转发到OSS中，并且效率会更高一点。但是基于connector的方式具有更大的一个活性，特别是history node组件，不仅可以为group提供二级存储的服务，也可以使用其他的一些组件来读取RT存储中的消息。即若将某个集群缩容，那么就可以将某些broker设置为只读模式，然后直接带点掉。同时历史消息读取可以代理，释放group 上的CPU内存和硬盘计算和储存资源。
三、分级存储适用场景
最后介绍分级存储所适用的一些场景。需要延长交易储存时间的场景，比如消息归档和历史消息回溯等。对此采取了消息按照topic维度重新组织，用户可以根据业务需要调整业务方案，所以对于特定的topic消息可以指定不同的消息保留时间，完全可以根据业务的需要来灵活设置的。对于要求储存时间短一些消息就可以缩短它的储存时间，对于需要保留时间长一点的消息，就可以让储存时间变得更长一些。而对于流计算的场景来说，更关心的是吞吐量而不是延迟，这种按topic 维度来组织消息的储存结构对缓存与batch是更为友好的。相比于本地盘，它其实更能有助于提高预算的吞吐量。
接下来介绍比较适用分级存储的场景是压缩数据。数据压缩适用于一些储存空间比较敏感的应用，是相当于用CPU的资源来换取空间的降低，以此降低存储的成本，即尽量减少本地盘保存的消息的时间，将消息全部转移到分级存储上进行储存。同时因为根据消息存储是按topic维度来组织消息的，一般来说，相同topic 的消息具有相同的模式。这种储存结构可以更好的收藏字典，提高压缩率，进一步的降低成本。如流程图所示，当消息转发到分级存储中时，就可以变更模式来生成字典，同时根据字典对后续的消息进行压缩，当消息的模式越类似，压缩的效率就越好。
最后一个场景是冷热数据分离，在阿里云大规模运维的经验中，如果一个共享的集群上面有很多租户，其中有某一个或者几个租户期间大量访问数据，就会带来磁盘IO的冲突，就会影响其他方面热数据的应用，而冷热数据分离的数据是保存在二级存储，即图中的OSS中。热数据是在本地磁盘以及dispatch中进行使用的，这样冷热数据的访问链路就完全分离、储存介质等存储资源与线程池等计算资源也是完全隔离的，冷数据的访问不会对热数据的访问带来任何的毛刺。以上就是本次课程的全部内容，感谢大家的聆听。
