简介：文章中的很多知识点，都是通过云原生编程挑战赛学到的，在一些问题在表述形式、甚至了解上都可能存在一些问题，甚至会有一些谬论；敢于尝试就会犯错，有犯错才会有成长，欢送各位大佬不舍赐教，多多斧正，让咱们一起变得更强！
作者：Ninety Percent
悸动
32 岁，码农的倒数第二个本命年，平铺直叙的生存总感觉短少了点什么。
想要去守业，却胆怯家庭承受不住再次失败的挫折，想要生二胎，带娃的压力让我想着还不如去守业；所以我只好在生活中寻找一些小打动，去看一些老掉牙的电影，而后把本人打动得稀里哗啦，去翻一些泛黄的书籍，在回顾里寻找一丝丝已经的深情满满；去学习一些冷门的常识，最初把本人搞得昏头昏脑，去加入一些有意思的较量，捡起那 10 年走来，早已被刻在基因里的悸动。
那是去年夏末的一个黄昏，我和共事正闲聊着西湖的美妙，他们说看到了阿里云公布云原生编程挑战赛，问我要不要试试。我说我只有九成的把握，另外一成得找我媳妇儿要；那一天，咱们绕着西湖走了良久，最初终于达成统一，Ninety Percent 战队应运而生，云原生 MQ 的赛道上，又多了一个艰巨却刚强的选手。
人到中年，依然会做出一些激动的决定，那种屁股决定脑袋的做法，像极了领导们的睿智和 18 岁时我朝三暮四的日子；冬季的 ADB 较量，曾经让我和女儿有些疏远，让老婆对我有些偏见；此次参赛，必然是要暗度陈仓，发愤图强，不到关键时刻，不能让家里人晓得我又在卖肝。
动工
你还别说，或者是人类的本色使然，这种背着老婆偷偷干坏事情的感觉还真不错，从上路到上分，一路顺风逆水，极速狂奔；断断续续花了大略两天的工夫，胜利地在 A 榜拿下了 first blood；再一次把第一名和最初一名同时纳入囊中；快男总是不会让大家悲观了，800 秒的问题，成为了较量的 base line。
第一个版本并没有做什么设计，基本上就是拍脑门的计划，目标就是把流程跑通，尽快出分，而后在保障正确性的前提下，逐渐去优化计划，防止一开始就适度设计，导致迟迟不能出分，影响士气。
整体设计
先回顾下赛题：Apache RocketMQ 作为一款分布式的消息中间件，历年双十一承载了万亿级的音讯流转，其中，实时读取写入数据和读取历史数据都是业务常见的存储拜访场景，针对这个混合读写场景进行优化，能够极大的晋升存储系统的稳定性。
image.gif
1.png
基本思路是：当 append 办法被调用时，会将传入的相干参数包装成一个 Request 对象，put 到申请队列中，而后以后线程进入期待状态。
聚合线程会循环从申请队列外面生产 Request 对象，放入一个列表中，当列表长度达到肯定数量时，就将该列表放入到聚合队列中。这样在后续的刷盘线程中，列表中的多个申请，就能进行一次性刷盘了，增大刷盘的数据块的大小，晋升刷盘速度；当刷盘线程解决完一个申请列表的长久化逻辑之后，会顺次对列表中个各个申请进行唤醒操作，使期待的测评线程进行返回。
2.png
image.gif
内存级别的元数据结构设计
image.gif3.png
<![endif]–> 首先用一个二维数组来存储各个 topicId+queueId 对应的 DataMeta 对象，DataMeta 对象外面有一个 MetaItem 的列表，每一个 MetaItem 代表的一条音讯，外面蕴含了音讯所在的文件下标、文件地位、数据长度、以及缓存地位。
SSD 上数据的存储构造
4.png
总共应用了 15 个 byte 来存储音讯的元数据，音讯的理论数据和元数据放在一起，这种混合存储的形式尽管看起来不太优雅，但比起独立存储，能够缩小一半的 force 操作。
数据恢复
顺次遍历读取各个数据文件，依照上述的数据存储协定生成内存级别的元数据信息，供后续查问时应用。
数据生产
数据生产时，通过 topic+queueId 从二维数组中定位到对应的 DataMeta 对象，而后依据 offset 和 fetchNum，从 MetaItem 列表中找到对应的 MetaItem 对象，通过 MetaItem 中所记录的文件存储信息，进行文件加载。
总的来说，第一个版本在大方向上没有太大的问题，应用 queue 进行异步聚合和刷盘，让整个程序更加灵便，为后续的一些性能扩大打下了很好的根底。
缓存
60 个 G 的 AEP，我垂涎已久，国庆七天，没有出远门的打算，肯定要好好卷一卷 llpl。下载了 llpl 的源码，一顿看，发现比我设想的要简略得多，实质上和用 unsafe 拜访一般内存是截然不同的。卷完 llpl，缓存设计方案跃然纸上。
缓存分级
缓存的写入用了队列进行异步化，防止对主线程造成阻塞（到较量前期才发现云 SSD 的神秘，就算同步写也不会影响整体的速度，前面我会讲起因）；程序能够用作缓存的存储介质有 AEP 和 Dram，两者在访问速度上有肯定的差别，赛题所形容的场景中，会有大量的热读，因而我对缓存进行了分级，分为了 AEP 缓存和 Dram 缓存，Dram 缓存又分为了堆内缓存、堆外缓存、MMAP 缓存(前期退出)，在申请缓存时，优先应用 Dram 缓存，晋升高性能缓存的应用频度。
Dram 缓存最初申请了 7G，AEP 申请了 61G，Dram 的容量占比为 10%；本次较量总共会读取（61+7）/2+50=84G 的数据，依据日志统计，整个测评过程中，有 30G 的数据应用了 Dram 缓存，占比 35%；因为前 75G 的数据不会有读取操作，没有缓存开释与复用动作，所以严格意义上来讲，在写入与查问混合操作阶段，总共应用了 50G 的缓存，其中滚动应用了 30-7/2=26.5G 的 Dram 缓存，占比 53%。10% 的容量占比，却滚动提供了 53% 的缓存服务，阐明热读景象十分重大，阐明缓存分级十分有必要。
然而，事实总是残暴的，这些看似无懈可击的优化点在测评中作用并不大，毕竟这种优化只能晋升查问速度，在读写混合阶段，读缓存总耗时是 10 秒或者是 20 秒，对最初的问题其实没有任何影响！很神奇吧，前面我会讲起因。
缓存构造
5.png
当获取到一个缓存申请后，会依据 topic+queueId 从二维数组中获取到对应的缓存上下文对象；该对象中保护了一个缓存块列表、以及最初一个缓存块的写入指针地位；如果最初一个缓存块的余量足够放下以后的数据，则间接将数据写入缓存块；如果放不下，则申请一个新的缓存块，放在缓存块列表的最初，同时将写不下的数据放到新缓存块中；若申请不到新的缓存块，则间接按缓存写入失败进行解决。
在写完缓存后，须要将缓存的地位信息回写到内存中的 Meta 中；比方本条数据是从第三个缓存块中的 123B 开始写入的，则回写的缓存地位为：（3-1）* 每个缓存块的大小 +123。在读取缓存数据时，依照 meta 数据中的缓存地位新，定位到对应的缓存块、以及块内地位，进行数据读取(须要思考跨块的逻辑)。
因为缓存的写入是单线程实现的，对于一个 queueId，后面的缓存块的音讯肯定早于前面的缓存块，所以当读取完缓存数据后，就能够将以后缓存块之前的所有缓存都开释掉(放入缓存资源池)，这样 75G 中被跳过的那 37.5G 的数据也能疾速地被开释掉。
缓存性能加上去后，问题来到了 520 秒左右，程序的主体构造也根本实现了，接下来就是简装了。
优化
缓存准入策略
一个 32k 的缓存块，是放 2 个 16k 的数据适合，还是放 16 个 2k 的数据适合？毫无疑问是后者，将小数据块尽量都放到缓存中，能够使得最初只有较大的块才会查 ssd，缩小查问时 ssd 的 io 次数。
那么阈值为多少时，能够保障小于该阈值的数据块放入缓存，可能使得缓存刚好被填满呢？（若不填满，缓存利用率就低了，若放不下，就会有小块的数据无奈放缓存，读取时必须走 ssd，io 次数就下来了）。
一般来说，通过屡次参数调整和测评尝试，就能找到这个阈值，然而这种形式不具备通用性，如果总的可用的缓存大小呈现变动，就又须要进行尝试了，不具备生产价值。
这个时候，中学时代的数学知识就派上用处了，如下图：
6.png
因为音讯的大小理论是以 100B 开始的，为了简化，间接依照从 0B 进行了计算，这样会导致算进去的阈值偏大，也就是最初会呈现缓存存不下从而小块走 ssd 查问的状况，所以我在算进去的阈值上减去了 100B*0.75（因为影响不大，根本是凭直觉拍脑门的）。如果要严格计算真正精确的阈值，须要将上图中的三角形面积问题，转换成梯形面积问题，然而感觉意义不大，因为 100B 原本就只有 17K 的 1/170，比例十分小，所以影响也十分的小。
梯形面积和三角形面积的比为：(17K+100)(17K-100)/(17k17K)=0.999965，齐全在数据稳定的范畴之内。
在程序运行时，依据动静计算出来的阈值，大于该阈值的就间接跳过缓存的写入逻辑，最初不论缓存配置为多大，都能保障小于该阈值的数据块全副写入了缓存，且缓存最初的利用率达到 99.5% 以上。
共享缓存
在刚开始的时候，依照算进去的阈值进行缓存布局，依然会呈现缓存容量有余的状况，理论用到的缓存的大小总是比总缓存块的大小小一些，通过各种排查，才豁然开朗，每个 queueId 所领有的最初一个缓存块大概率是不会被写满的，宏观上来说，均匀只会被写一半。一个缓存块是 32k，queueId 的数量大略是 20w，那么就会有 20w*32k/2=3G 的缓存没有被用到；3G/2=1.5G(前 75G 之后随机读一半，所以要除以 2)，就算是程序读大块，1.5G 也会带来 5 秒左右的耗时，更别说随机读了，所以不论有多简单，这部分缓存肯定要用起来。
既然本人用不完，那就共享进去吧，整体计划如下：image.gif
7.png
在缓存块用尽时，对所有的 queueId 的最初一个缓存块进行自增编号，而后放入到一个一维数组中，缓存块的编号，即为该块在认为数字中的下标；而后依据缓存块的余量大小，放到对应的余量汇合中，余量大于等于 2k 小于 3k 的缓存块，放到 2k 的汇合中，以此类推，余量大于最大音讯体大小 (赛题中为 17K) 的块，对立放在 maxLen 的汇合中。
当某一次缓存申请获取不到公有的缓存块时，将依据以后音讯体的大小，从共享缓存汇合中获取共享缓存进行写入。比方以后音讯体大小为 3.5K，将会从 4K 的汇合中获取缓存块，若获取不到，则持续从 5k 的汇合中获取，顺次类推，直到获取到共享缓存块，或者没有满足任何满足条件的缓存块为止。
往共享缓存块写入缓存数据后，该缓存块的余量将发生变化，须要将该缓存块从之前的汇合中移除，而后放入新的余量汇合中（若余量级别未发生变化，则不须要执行该动作）。
访问共享缓存时，会依据 Meta 中记录的共享缓存编号，从索引数组中获取到对应的共享块，进行数据的读取。
在缓存的开释逻辑里，会间接疏忽共享缓存块(实践上能够通过一个计数器来管制何时该开释一个共享缓存块，但实现起来比较复杂，因为要思考到有些音讯不会被生产的状况，且收益也不会太大（因为二阶段缓存是齐全够用的，所以就没做尝试)。
MMAP 缓存
测评程序的 jvm 参数不容许选手本人管制，这是拦在选手背后的一道阻碍，因为老年代和年老代之间的比例为 2 比 1，那意味着如果我应用 3G 来作为堆内缓存，加上内存中的 Meta 等对象，老年代根本要用 4G 左右，那就会有 2G 的新生代，这齐全是节约，因为该赛题对新生代要求并不高。
所以为了避免浪费，肯定要缩小老年代的大小，那也就意味着不能应用太多的堆内缓存；因为堆外内存也被限定在了 2G，如果减小堆内的使用量，那空余的缓存就只能给零碎做 pageCache，但赛题的背景下，pageCache 的命中率并不高，所以这条路也是走不通的。
有没有什么内存既不是堆内，申请时又不受堆外参数的限度？自然而然想到了 unsafe，当然也想到官网导师说的那句：用 unsafe 申请内存间接勾销问题。。。这条路只好作罢。
花了一个下午的工夫，通读了 nio 相干的代码，意外发现 MappedByteBuffer 是不受堆外参数的限度的，这就意味着能够应用 MappedByteBuffer 来代替堆内缓存；因为缓存都会频繁地被进行写与读，如果应用 Write_read 模式，会导致刷盘动作，就得失相当了，自然而然就想到了 PRIVATE 模式(copy on write)，在该模式下，会在某个 4k 区首次写入数据时，和 pageCache 解耦，生成一个独享的内存正本；所以只有在程序初始化的时候，将 mmap 写一遍，就能失去一块独享的，和磁盘无关的内存了。
所以我将堆内缓存的大小配置成了 32M(因为该性能曾经开发好了，所以还是要意思一下，用起来)，堆外申请了 1700M(算上测评代码的 300M，差不多 2G)、mmap 申请了 5G；总共有 7G 的 Dram 作为了缓存（不应用 mmap 的话，大略只能用到 5G），内存中的 Meta 大略有 700M 左右，所以堆内的内存差不多在 1G 左右，2G+5G+1G=8G，操作系统给 200M 左右根本就够了，所以还剩 800M 没用，这 800M 其实是能够用来作为 mmap 缓存的，次要是思考到大家都只能用 8G，超过 8G 容易被挑战，所以最初最优问题外面总的内存的使用量并没有超过 8G。
基于开端填补的 4K 对齐
因为 ssd 的写入是以 4K 为最小单位的，但每次聚合的音讯的总大小又不是 4k 的整数倍，所以这会导致每次写入都会有额定的开销。
比拟惯例的计划是进行 4k 填补，当某一批数据不是 4k 对齐时，在开端进行填充，保障写入的数据的总大小是 4k 的整数倍。听起来有些不堪设想，额定写入一些数据会导致整体效益更高？
是的，推导逻辑是这样的：“如果不填补，下次写入的时候，肯定会写这未满的 4k 区，如果填补了，下次写入的时候，只有 50% 的概率会往后多写一个 4k 区(因为后面填补，导致本次数据后移，尾部多垮了一个 4k 区)”，所以整体来说，填补后会赚 50%。或者换一个角度，填补对于以后的这次写入是没有副作用的(也就多 copy<4k 的数据)，对于下一次写入也是没有副作用的，然而如果下一次写入是这种状况，就会因为填补而少写一个 4k。
8.png
基于开端剪切的 4k 对齐
填补的计划的确能带来不错的晋升，然而最初落盘的文件大略有 128G 左右，比理论的数据量多了 3 个 G，如果能把这 3 个 G 用起来，又是一个不小的晋升。
自然而然就想到了开端剪切的计划，将尾部未 4k 对齐的数据剪切下来，放到下一批数据外面，剪切下来的数据对应的申请，也在下一批数据刷盘的时候进行唤醒。
计划如下：
image.gif
9.png
填补与剪切共存
剪切的计划诚然优良，但在一些极其的状况下，会存在一些消极的影响；比方聚合的一批数据整体大小没有操作 4k，那就须要扣留整批的申请了，在这一刻，这将变向导致刷盘线程大幅升高、申请线程大幅升高；对于这种状况，剪切对齐带来的劣势，无法弥补扣留申请带来的劣势（基于直观感触），因而须要间接应用填补的形式来保障 4k 对齐。
严格意义上来讲，应该有一个扣留线程数代价、和填补代价的量化公式，以决定何种时候须要进行填补，何种时候须要进行剪切；然而其本质太过简单，波及到非同质因子的整合(要在磁盘吞吐、磁盘 io、测评线程耗时三个概念之间做转换)；做了一些尝试，成果都不是很现实，没能跑出最高分。
当然两头还有一些边界解决，比方当 poll 上游数据超时的时候，须要将扣留的数据进行填充落盘，防止收尾阶段，最初一批扣留的数据得不到解决。
SSD 的预写
得此优化点者，得前 10，该优化点能大幅晋升写入速度(280m/s 到 320m/s)，这个优化点很多同学在一些技术贴上看到过，或者本人意外发现过，然而大部分人应该对实质的起因不甚了解；接下来我便循序渐进，依照本人的了解进行 yy 了。
假如某块磁盘上被写满了 1，而后文件都被删除了，这个时候磁盘上的物理状态必定都还是 1（因为删除文件并不会对文件区域进行格式化）。而后你又新建了一个空白文件，将文件大小设置成了 1G（比方通过 RandomAccessFile.position(1G)）；这个时候这 1G 的区域对应的磁盘空间上依然还是 1，因为在生产空白文件的时候也并不会对对应的区域进行格式化。
然而，当咱们此时对这个文件进行拜访的时候，读取到的会全是 0；这阐明文件系统外面记录了，对于一个文件，哪些地方是被写过的，哪些地方是没有被写过的(以 4k 为单位)，没被写过的中央会间接返回 0；这些信息被记录在一个叫做 inode 的货色上，inode 当然也是须要落盘进行长久化的。
所以如果咱们不预写文件，inode 会在文件的某个 4k 区首次被写入时产生性变更，这将造成额定的逻辑开销以及磁盘开销。因而，在构造方法外面一顿 for 循环，依照预估的总文件大小，先写一遍数据，后续写入时就能腾飞了。
大音讯体的优化策略
因为磁盘的读写都是以 4k 为单位，这就意味着读取一个 16k+2B 的数据，极其状况下会产生 16k+2*4k=24k 的磁盘 io，会多加载将近 8k 的数据。
显然如果可能在读取的时候都按 4k 对齐进行读取，且加载进去的数据都是有意义的（后续可能被用到），就能解决而上述的问题；我顺次做了以下优化(有些优化点在前面被废除掉了，因为它和一些其余更好的优化点抵触了)。
1、大块置顶
<![endif]–> 因为每一批聚合的音讯都是 4k 对齐的落盘的（剪切扣留计划之前），所以我将每批数据中最大的那条音讯放在了头部(基于缓存布局策略，大音讯大概率是不会进缓存的，生产时会从 ssd 读取)，这样这条音讯至多有一端是 4k 对齐的，读取的时候能缓解 50% 的对齐问题，该种形式在剪切扣留计划之前的确带来了 3 秒左右的晋升。
2、音讯程序重组
通过算法，让大块数据尽量少地呈现两端不对齐的状况，缩小读取时额定的数据加载量；比方针对上面的例子：
10.png
在整顿之前，加载三个大块总共会波及到 8 个 4k 区，整顿之后，就变成了 6 个。
因为本人在算法这一块儿切实太弱了，加上这是一个 NP 问题，折腾了几个小时，成果总是差强人意，最初只好放弃。
3、基于内存的 pageCache
在数据读取阶段，每次加载数据时，若加载的数据两端不是 4k 对齐的，就被动向前后延长打到 4k 对齐的中央；而后将首尾两个 4k 区放到内存外面，这样当后续要拜访这些 4k 区的时候，就能够间接从内存外面获取了。
该计划最初的成果和预估的一样差，一点惊喜都没有。因为只会有大量的数据会走 ssd，首尾两个 4k 外面大概率都是那些不须要走 ssd 的音讯，所以被复用的概率极小。
4、局部缓存
既然本人没能力对音讯的存储程序进行调整优化，那就把那些两端不对齐的数据剪下来放到缓存外面吧：
11.png
image.gif
某条音讯在落盘的时候，若某一端 (也有可能是两端) 没有 4k 对齐，且在未对齐的 4k 区的数据量很少，就将其剪切下来寄存到缓存里，这样查问的时候，就不会因为这大量的数据，去读取一个额定的 4k 区了。
剪切的阈值设置成了 1k，因为数据大小是随机的，所以从宏观上来看，剪切下来的数据片的均匀大小为 0.5k，这意味着只须要应用 0.5k 的缓存，就能缩小 4k 的 io，是惯例缓存效益的 8 倍，加上缓存局部的余量分级策略，会导致有很多碎片化的小内存用不到，该计划刚好能够把这些碎片内存利用起来。
测评线程的聚合策略
每次聚合多少条音讯进行刷盘适合？是按音讯条数进行聚合，还是依照音讯的大小进行聚合？
刚开始的时候并没有想那么多，通过日志得悉总共有 40 个线程，所以就写死了一次聚合 10 条，而后四个线程进行刷盘；但这会带来两个问题，一个是若线程数发生变化，性能会大幅降落；第二是在收尾阶段，会有一些跑得慢的线程还有不少数据未写入的状况，导致收尾工夫较长，特地是退出了尾部剪切与扣留逻辑后，该景象尤为重大。
为了解决收尾耗时长的问题，我尝试了同步聚合的计划，在第一次写入之后的 500ms，对写入线程数进行统计，而后分组，后续就按组进行聚合；这种形式能够完满解决收尾的问题，因为同一个组外面的所有线程都是同时实现写入工作的，大略是因为每个线程的写入次数是固定的吧；然而应用这种形式，尾部剪切 + 扣留的逻辑就十分难交融进来了；加上在程序一开始就固定线程数，看起来也有那么一些不优雅；所以我就引入了“线程控制器”的概念。image.gif
12.png
聚合策略迭代 - 针对剪切扣的留计划的定向优化
假如以后动静计算出来的聚合数量是 10，对于聚合进去的 10 条音讯，如果本批次被扣留了 2 条，下次聚合时应该聚合多少条？
在之前的策略外面，还是会聚合 10 条，这就意味着一旦呈现了音讯扣留，聚合逻辑就会产生抖动，会呈现某个线程聚合不到指定的音讯数据量的状况（这种状况会有 poll 超时形式进行兜底，然而整体速度就慢了）。
所以聚合参数不能是一个单纯的、统一化的值，得针对不同的刷盘线程的扣留数，进行调整，假如聚合数为 n，某个刷盘线程的上批次扣留数量为 m，那针对这个刷盘线程的下批次的聚合数量就应该是 n-m。
那么问题就来了，聚合线程 (生产者) 只有一个，刷盘线程（消费者）有好几个，都是抢占式地进行生产，没方法将聚合到的特定数量的音讯，给到指定的刷盘线程；所以聚合音讯队列须要拆分，拆分成以刷盘线程为维度。
因为改变比拟大，为了保留以前的逻辑，就引入了聚合数量的“严格模式”的概念，通过参数进行管制，如果是“严格模式”，就应用上述的逻辑，若不是，则应用之前的逻辑；
设计图如下：image.gif
13.png
将聚合队列换成了聚合队列数组，在非严格模式下，数组外面的原始指向的是同一个队列对象，这样很多代码逻辑就能对立。
聚合线程须要先从扣留信息队列外面获取一个对象，而后依据扣留数和最新的聚合参数，决定要聚合多少条音讯，聚合好消息后，放到扣留信息所形容的队列中。
完满的收尾策略，一行代码带来 5s 的晋升
引入了线程控制器后，收尾工夫被升高到了 2 秒多，两次收尾，也就是 5 秒左右(这些信息来源于最初一个早晨对 A 榜时的日志的剖析)，在赛点地位上，这 5 秒的重要性显而易见。
较量完结前的最初一晚，分数彷徨在了 423 秒左右，后面的大佬在很多天前就从 430 一次性优化到了 420，而后分数就没有太大变动了；我过后抱着幸运的态度，判定应该是 hack 了，直到那天早晨在钉钉群里和他聊了几句，直觉通知我，420 的问题是无效的。过后是有些慌的，毕竟较量第二天早上 10 点就完结了。
我开始陷入深深的反思，我都卷到极致了，从 432 到 423 破费了大量的精力，为何大神可能一击致命？不对，肯定是我疏忽了什么。
我开始回看历史提交记录，而后对照剖析每次提交后的测评得分（因为历史问题都有肯定的抖动，所以这个工作十分的上头）；破费了大略两个小时，总算发现了一个异样点，在 432 秒左近的时候，我从同步聚合切换成了异步聚合，而后交融了剪切扣留 +4k 填补的计划，按理说这个优化能缩小 3G 多的落盘数据量，问题应该是能够晋升 10 秒左右的，然而过后问题只晋升了 5 秒多，因为过后还有不少没有落地的优化点，所以就没有太在意。
扣留策略会会将尾部的申请扣留下来，尾部的申请原本就是慢一拍 (对应的测评线程慢) 的申请（队列是程序生产），这一扣留，进度就更慢了！！！
聚合到一批音讯后，依照音讯对应的线程被扣留的次数，从大到小排个序，让那些慢的、扣留多的线程，尽可能不被扣留，让那些快的、扣留少的申请，尽可能被扣留；最初所有的线程简直都是同时实现（基于假想）。
连忙提交代码、开始测评，抖了两把就破 420 了，最好问题达到了 418，比优化前高出 5 秒左右，十分合乎预期。
查问优化
多线程读 ssd
因为只有大量的数据会读 ssd，这使得在读写混合阶段，sdd 查问的并发量并不大，所以在加载数据时进行了判断，如果须要从 ssd 加载的数量大于一定量时，则进行多线程加载，充分利用 ssd 并发随机读的能力。
为什么要大于肯定的量才多线程加载，如果只须要加载两条数据，用两个线程来加载会有晋升吗？当存储介质够快、加载的数据量够小时，多线程加载数据带来的 io 工夫的晋升，还不足以补救多线程执行自身带来的程序开销。
缓存的批量 copy
若某次查问时须要加载的数据，在缓存上是间断的，则不须要一条一条从缓存进行复制，能够以缓存块的大小为最小粒度，进行复制，晋升缓存读取的效益。
14.png
image.gif
下面的例子中，应用批量 copy 的形式，能够将 copy 的次数从 5 次降到 2 次。
这样做的前提是：用于返回的各条音讯对应的 byteBuffer，在内存上须要是间断的（通过反射实现，给每个 byteBuffer 都注入同一个 bytes 对象）；批量复制结束后，依据各条音讯的大小，动静设置各自 byteBuffer 的 position 和 limit，以保障 retain 区域刚好指向本人所对应的内存区间。
该性能始终有偶现的 bug，本地又复现不了，A 榜的时候没太在意，B 榜的时候又不能看日志，始终没失去解决；怕因为代码品质影响最初的代码分，所以起初就正文掉了。
遗失的美妙
在较量开始的时候，看了金融通的赛题解析，外面提到了一个对数据进行迁徙的点；10 月中旬的时候进行了尝试，在开始读取数据时，陆续把那些缓存中没有的数据读取到缓存中（因为一旦开始读取，就会有大量的缓存被释放出来，缓存容量齐全够用），总共进行了两个计划的尝试：
1、基于程序读的异步迁徙计划
在第一阶段，当缓存用尽时，记录以后存储文件的地位，而后迁徙的时候，从该地位开始进行程序读取，将后续的所有数据都读取到缓存中；这样做的益处是大幅升高查问阶段的随机读次数；然而也有有余，因为前 75G 数据中有个别的数据是不会被生产的，这意味着迁徙到缓存中的数据，有 50% 都是没有意义的，过后测下来该计划根本没有晋升（因为问题有肯定的抖动，具体是有一部分晋升、没晋升、还是负优化，也不得而知）；起初引入了缓存准入策略后，该计划就彻底被废除了，因为须要从 ssd 中读取的数据会齐全散列在存储文件中。
2、基于懒加载的异步迁徙计划
下面有讲到，因为一阶段的数据中有一半都不会被生产到，想要不做无用功，就必须要在保障迁徙的数据都是会被生产的数据。
所以加了一个逻辑，当某个 queueId 第一次被生产的时候，就异步将该 queueId 中不存在缓存中的音讯，从 ssd 中加载到缓存中；因为过后感觉就算是异步迁徙，也是要随机读的，读的次数并不会缩小，一段时间内磁盘的压力也并不会缩小；所以对该计划就没怎么器重，齐全是抱着写着玩的态度；并且在迁徙的准入逻辑上加了一个判断：“当本次查问的音讯中蕴含有从磁盘中加载的数据时，才异步对该 queueId 中剩下的 ssd 中的数据进行迁徙”；至今我都没相透过后本人为什么要加上这个一个判断。也就是因为这个判断，导致迁徙成果依然不现实(会导致迁徙不够集中、并且很多 queueId 在某次查问的时候读了 ssd，后续就没有须要从 ssd 上读取的数据了)，对问题没有显著的晋升；在一次版本回退中，彻底将迁徙的计划给抹掉了（置信打较量的小伙伴对版本回退深有感触，特地是对于这种有较大问题抖动的较量）。
较量完结后我在想，如果过后在迁徙逻辑上没有加上那个神奇的逻辑判断，我的问题能到多少？或者能到 410，或者冲破不了 420；正式因为错过了那个大的优化点，才让我在其余点上做到了极致；那些错过的美妙，会让大家在将来的日子里更加致力地奔跑。
接下来咱们讲一下为什么异步迁徙会快。
ssd 的多线程随机读是很快的，然而我下面有讲到，如果查问的数据量比拟小，多线程分批查问成果并不一定就好，因为每一批的数据量切实太小了；所以想要在查问阶段开很多的线程来晋升整体的查问速度并不能取的很好的成果。异步迁徙可能完满地解决这个问题，并且在 io 次数肯定的状况下，集中进行 ssd 的随机读，比散列进行随机读，pageCache 命中率更高，且对写入速度造成的整体影响更小（这个观点纯属集体感悟，只保障 Ninety Percent 的正确率）。
SSD 云盘的神秘
我也是个小白，以下内容很多都是猜想，大家看一看就能够了。
1、云 ssd 的运作机制
SSD 云盘和传统的 ssd 盘领有着雷同的个性，然而却是不同的货色；能够了解成 SSD 云盘，是传统 ssd 盘的一个放大版。image.gif
15.png
SSD 云盘的底层存储介质是多个一般的物理硬盘，这些物理硬盘就相似于传统 ssd 中的存储颗粒，在进行写入或读取的时候，会将任务分配到多个物理设施上并行进行解决。同时，在云 ssd 中，对数据的更新采纳了 append 的形式，即在进行更新时，是程序追加写一块数据，而后将地位的援用从原有的数据块指向新的数据块（咱们拜访的文件的 position 和硬盘的物理地址之间有一层映射，所以就算硬盘上有很多的碎片，咱们也依然能获取到一个“间断”的大文件）。
阿里云官网上有云 ssd 的 iops 和吞吐的计算公式：
iops = min{1800+50 容量, 50000}; 吞吐 = min{120+0.5 容量, 350}
咱们看到无论是 iops 和吞吐，都和容量呈正相干的关系，并且都有一个下限。这是因为，容量越大，底层的物理设施就会越多，并发解决的能力就越强，所以速度就越快；然而当物理设施多到肯定的数量时，文件系统的“总控“就会成为瓶颈；这个总控必定也是须要存储能力的（比方存储地位映射、历史数据的 compact 等等），所以当给总控配置不同性能的存储介质时，就失去了 PL0、PL1 等不同性能的云盘（当然，除此之外，网络带宽、运算能力也是云 ssd 速度的影响因子）。
2、云 ssd 的 buffer 景象
在过程中发现了一个乏味的景象，就算是 force 落盘，在刚开始写入时，速度也是远大于 320m/s 的（能达到 400+），几秒之后，会降下来，稳固在 320 左右（像极了不 force 时，pageCache 带来的 buffer 景象）。
针对这种奇怪的景象，我进行了进一步的摸索，每写 2 秒的数据，就 sleep 2 秒，后果是：在写入的这两秒工夫里，速度能达到 400+，整体平均速度也远超过了 160m/s；起初我又做了很多试验，包含在每次写完数据之后间接进行短暂的 sleep，然而这基本不会影响到 320m/s 的整体速度。测试代码中，尽管是 4 线程写入，然而总会有那么一些时刻，大部分甚至所有线程都处于 sleep 状态，这必然会使得在这个工夫点上，应用程序到硬盘的写入速度是极低的；然而工夫拉长了看，这个速度又是能恒定在 320m/s 的。这阐明云 ssd 上有一层 buffer，相似操作系统的 pageCache，只是这个“pageCache”是牢靠存储的，应用程序到这个 buffer 之间的速度是能够超过 320 的，320 的阈值，是上游所导致的（比方 buffer 到硬盘阵列）。
对于这个“pageCache”有几种猜想：
1、物理设施自身就有 buffer 效应，因为物理设施的存储状态实质上是通过电刺激，扭转存储介质的化学状态或者物理状态的实现的，驱动这种变动的工业实质，产生了这种 buffer 景象‘；
2、云 ssd 外面有一块较小的高性能存介质作为缓冲区，以提供更好的突击写的性能；
3、逻辑限速，哈哈，这个纯属开玩笑了。
因为有了这个 buffer 效应，程序层面就能够随心所欲了，比方写缓存的动作，整体会破费几十秒，然而就算是在只有 4 个写入线程的状况下，不论是异步写还是同步写，都不会影响整体的落盘速度，因为在同步写缓存的时候，云 ssd 可能进行短暂的停歇，在接下来的写入时，速度会短暂地超过 320m/s；查问的时候也相似，非 io 以外的工夫开销，无论长短，都不会影响整体的速度，这也就是我之前提到的，批量复制缓存，实践上有不小晋升，然而实际上却没多大晋升的起因。
当然，这个 buffer 景象其实是能够利用起来的，咱们能够在写数据的时候多花一些工夫来做一些其余的事件，反正这样的工夫开销并不会影响整体的速度；比方我之前提到的 NP 问题，能够 for 循环暴力破解
参赛总结
这次较量的体验十分好，赛题有挑战、导师们也十分激情。较量周期也适中，让我既有工夫冲刺，也防止了频繁熬夜导致的家庭矛盾，媳妇儿是在最初一周看到了天池的页面，才发现我在打较量。
2021 年加入了两次阿里云的较量，都获得了不错的问题，这再一次证实了我适宜做技术，不适宜做治理；往年工作的体验很不好，大略也是因为代码写少了吧。
很多问题或者不须要答案，一路向前，有人陪伴，上坡下坡，都有高兴。这就是我加入大赛之后感触很粗浅的一点。
文章中的很多知识点，都是通过云原生编程挑战赛学到的，在一些问题在表述形式、甚至了解上都可能存在一些问题，甚至会有一些谬论；敢于尝试就会犯错，有犯错才会有成长，欢送各位大佬不舍赐教，多多斧正，让咱们一起变得更强！
源码地址：https://code.aliyun.com/27605…
明天，第三届云原生编程挑战赛正式启动了！作为上一届大赛冠军，我期待越来越多的敌人退出大赛、感触大赛，从大赛里实在地获取对本人有价值的货色，毕竟每一次成长都是须要本人怯懦的迈出第一步的。大家共勉！
16.png
点击此处报名参赛！
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。