共计 728 个字符，预计需要花费 2 分钟才能阅读完成。
后面曾经讲了音讯是怎么发送给 broker 的，那 broker 接管到音讯后，是怎么解决的？
为了保障音讯不失落，RocketMQ 会把音讯进行长久化，也就是说，会把音讯写入 commitlog 的日志，这个目录是在 store 上面。每个日志大小为 1G，所以 commitlog 会有多个磁盘文件，每个文件名是音讯的物理偏移量。
当 broker 接管到音讯的时候，首先会进行一些判断，比方只能 master 能够写入，Topic 的长度限度为 256 个字符，音讯属性长度限度为 65536 个字符等。
等验证通过后，开始进行写数据，因为可能存在并发问题，所以每次写的时候，都须要申请锁。
申请到锁后，开始往 commitlog 里写数据，如果是刚开始写入日志文件的时候，此时 commitlog 并没有文件，所以就会创立一个大小为 1G 名字为 00000000000000000000 的日志文件。如果曾经存在多个日志文件，那间接取最初一个日志文件，因为日志文件写完才会创立一个新的日志文件，那最初一个日志文件就是以后须要写入的。
拿到日志文件后，咱们须要将音讯追加到这个文件里，此时须要晓得以后文件的写指针，如果是刚创立的文件，那写指针就是 0。
这个写指针是不能大于文件的大小，如果超过了，阐明文件已写满，那是不能往里面写数据的。
另外一个还须要判断的是，以后音讯是否够放这个文件，也就写指针 + 音讯的长度（mq 还会预留其余空间），是否会超过这个文件的大小，如果不会，就写入这个文件，如果会，那就会创立一个新的文件进行写入。
写入后，就更新下面的写指针，也就是说，最初的写指针就是以后写指针 + 音讯的大小。最初开释锁，让其余线程进行写入。
其实到了这一个步骤，音讯并没有写到磁盘上，还只是追加到内存，后续再来提刷屏的过程。
