多内核混部下的快速内存弹性伸缩技术实战

最近在一场头部科技企业组织的内部技术研讨活动上看到了这样一道很有嚼头的难题多内核混部场景下的快速内存弹性伸缩技术。乍一看题目里每个词都认识组合在一起却让人心里一紧——混部、多内核、内存弹性伸缩这三个概念单独拿出来都能讲一节课这个题目偏偏把它们全拧在一起。先说背景。高性能计算、云原生、大数据处理这些业务跑起来之后服务器资源利用率一直是运维心里的痛。我见过某机房的监控面板CPU利用率长期在15%上下内存更是惨不忍睹64G的机器日常才用20G左右。后来引入混部模式把离线任务塞进在线业务的空闲时间片里CPU利用率确实上去了但内存又成了新瓶颈。在线业务流量一波动内存配额就得跟着变变慢了业务抖动变快了离线任务被挤死。尤其是这几年容器、虚拟机和物理机形态混在一起一台机器上可能同时跑着多个客户机内核内存的调度和回收更加不可控这才有了这道题。这篇文章不打算复述任何官方解法只讲我从实际问题出发的拆解思路、技术选型、实操记录和踩坑经验。内容偏内核和系统调度方向但对云原生资源调度、虚拟化平台研发的同学同样有参考价值。1. 场景还原多内核混部下的内存伸缩到底难在哪1.1 混部与多内核概念的层次关系在拆解具体技术之前先把多内核混部这个词拆开说清楚。混部不是新概念数据中心里把在线服务和离线任务放在同一套物理资源上运行通过错峰调度提高资源利用率这玩法在业界已经跑了很多年。我见过比较典型的场景白天业务高峰一批在线服务占用大量内存和CPU到了深夜流量下来之后同一批集群里的离线计算任务日志清洗、特征工程、模型推理立刻把资源吃掉。形式上混部可以发生在容器之间、虚拟机之间也可以是物理机层面的裸金属调度。但多内核这三个字把问题维度抬高了一大截。它指的是同一台物理机、同一个资源池里同时存在多个独立运行的内核实例。最常见的有两类。第一类是虚拟化混部。宿主机上跑着多台Guest虚拟机每台虚拟机里都有一套完整的客户机内核。因为镜像版本不同客户机内核版本、内存管理参数、驱动实现都有差异也就是说物理机上同时运行着好几套内存管理逻辑。容器场景虽然默认共享宿主机内核但有的场景会启用轻量虚拟化像用户态内核或者微虚拟化把不同形态的容器隔离开本质上也会引入多内核并存。第二类是内核形态的混部。标准内核、实时内核、甚至某些定制卸载内核并存。这些内核的内存分配器、页面回收策略、调度交互方式各有差异同一个伸缩指令在不同内核上的响应行为完全不同。放在一起就是这道题的背景在一个资源池里不同内核的配额要能快速调整既要保证在线服务不感知、不抖动又要让离线任务能快速拿到资源。整道题的核心关键词落在快速上。1.2 为什么缩容比扩容难十倍很多不熟悉内存管理细节的同学可能觉得内存伸缩不就是改个数字吗把cgroup的memory.limit从8G改成4G内核就会自动把多余内存收回来能有多难实际做起来根本不是这么回事。扩容容易是因为让内核把更多可用内存分配给某个容器是顺水推舟的事。系统里只要还有空闲页直接映射给目标容器就行路径短、开销小。真正的难点在缩容要从一个正在运行、且数据可能还热着的容器里把物理内存页收回或迁移走内核必须面对一连串问题——这些页面是脏的还是要写回磁盘页面正在被进程访问回收它会不会导致进程卡顿页面是文件映射页还是匿名页回收策略完全不同回收之后该容器的内存带宽、缓存命中率会不会反而下降这些问题叠加在混部场景中还会出现一个特有的信息不对称宿主机内核能看到所有Guest内核的物理内存使用情况但看不到客户机内核内部的内存冷热分布。你只能从外部强行限制它的配额而它内部的页面回收策略是按自己的水位线走的。两边不协调就会导致一种很尴尬的状态——宿主机把某个Guest的内存配额一降Guest内部立刻开始大量换页业务响应时间直接从几毫秒涨到几百毫秒。内存资源的动态分配从来不是简单的加减法它必须是一条完整的观测-决策-执行-反馈链路。这道方案要解决的就是让这条链路跑得足够快。1.3 快速伸缩的量化标准与评判维度做技术评估之前先给快速定一个可衡量的标准。根据我在实际项目中的经验内存弹性伸缩的快不能只看一条指标而要看四个方面。伸缩操作的触发时延从监控发现内存水位异常到决策模块发出伸缩指令的时间。这一环通常能压缩到毫秒级关键在于监控数据的采样频率和决策算法的复杂度。资源生效时延从指令发出到目标内核或cgroup的内存配额真正变化完成的时间。扩容易做秒级甚至亚秒级就能完成缩容要看回收路径很多场景下几十秒到几分钟都很正常。这道题要挑战的就是把它压缩到秒级。业务影响面伸缩过程中在线服务的尾延迟是否出现明显毛刺。评判标准是伸缩过程不能让在线业务的可感知延迟出现明显劣化比如劣化超过10%就需要警惕。伸缩精度实际回收或追加的内存量和目标配额之间的误差。有些场景宁可不精准也要快有些场景则更看重精确性这会直接影响底层机制的选择。把四个维度放在一起评估才能判断一套内存弹性伸缩方案是否合格。单纯追求快而把在线业务打崩毫无意义单纯追求稳而花几分钟才完成伸缩又对不起混部场景对资源利用率的要求。2. 核心技术拆解内存弹性伸缩的几条实现路径2.1 cgroup v2 内存控制面一切操作的地基谈内存伸缩绕不开cgroup。在cgroup v2里内存控制器统一挂在/sys/fs/cgroup/分组路径下最核心的接口是memory.current和memory.max前者查看当前内存用量后者设置内存上限。很多同学觉得这挺简单改memory.max不就行了。但实际踩过坑的人都知道直接改这个文件并不会立刻触发内存回收它只是设定了一条警戒线内核会在后续分配内存的过程中被动地做回收。v1时代内存控制逻辑分散在memory.limit_in_bytes、memory.soft_limit_in_bytes等多个文件上线程组和进程组的层级关系让继承逻辑绕得很。v2大幅简化了层级模型每个cgroup在根节点之下形成树形结构只有叶子节点能实际承载任务内存上限的设置和读取逻辑也更统一。更重要的是v2引入了memory.swap.max、memory.high等细粒度接口给上层算子提供了更多调优空间。要实现快速伸缩真正值得重点研究的是memory.reclaim。这个接口允许用户在需要时主动触发某个cgroup的内存回收不必等水位线报警。它的出现对内存弹性伸缩来说是个转折点——回收从被动响应变成了主动控制。比如一个离线批处理任务跑完了你想快速把它的内存空间让给后续任务直接往memory.reclaim写入要回收的字节数内核就会立刻去回收页面。不过这里有个细节memory.reclaim不会回收所有页面比如正在被内核持有、正在进行IO的页面就收不回来。所以写入的值和实际回收量往往有差距。实战中不能光看一次写入的结果要循环检查memory.current的变化直到达到目标水位。这一点我在后面的实操部分会详细展开。2.2 内核回收机制从直接回收到异步回收讨论快速内存伸缩绕不开内核回收页面的一系列机制。很多老内核运维应该还记一种场景内存不够用的时候整个系统响应突然变得极慢然后日志里刷出一堆direct reclaim相关的信息。所谓直接回收就是某个进程在分配内存时发现内存不够了于是自己动手去回收页面来满足需求。这会带来严重的尾延迟因为执行回收的线程就是业务线程本身。后来内核引进了kswapd内核线程负责在内存水位低于阈值时异步回收页面业务线程在分配时尽量避免亲自下场回收。这套机制在普通场景下够用但在快速内存伸缩这个需求下还不够因为它仍然跟着全局水位走做不到对某个cgroup的定向快速回收。所以memory.reclaim接口才是真正适合弹性伸缩场景的工具。回收页面还有不少技术细节。页面分文件页和匿名页两种文件页如果是干净的可以直接丢弃脏的则需要写回后丢弃匿名页必须先写到swap才能腾出来。页面还分活跃页和不活跃页如果回收得太激进很容易把热数据也一起回收掉导致业务抖动。所以成熟的弹性伸缩方案在回收之前会先做一次冷热识别根据页面最近被访问的频率挑选回收对象。Linux内核本身就维护了LRU列表回收时从LRU尾部开始挑选但仅依赖LRU还不够有经验的团队会结合BPF追踪或页表访问位来做更精确的冷热判断。2.3 内存热插拔与热迁移物理层面的伸缩路径如果只看cgroup层面的伸缩容易忽略另一个维度的手段——内存热插拔和热迁移。它们解决的是物理资源怎么在两个内核实例之间转移的问题。内存热插拔在物理机场景中比较常见。服务器主板上有若干内存插槽内核支持对内存设备做online和offline操作。当系统需要减少某个NUMA节点上的内存时把对应的内存块offline内核会把这块内存里的页面迁移或回收后再摘除。这个过程看起来很美但粒度太大——一个内存块往往是128MB甚至1GB级别做细粒度分配很难而且offline操作需要满足比较严格的条件页面迁移失败会导致整个操作回滚。热迁移则更多地用于虚拟机场景。要把一台虚拟机占用的内存从一台物理机搬到另一台物理机或者在同一台物理机的不同NUMA节点之间搬移业界已经有了比较成熟的路线。但热迁移更关注的是迁移过程中的业务连续性和把内存快速释放给别人用的目标不完全一致。真正做多内核混部弹性伸缩时热迁移往往被作为最后手段——先尝试本地压缩、回收、去重实在不行再考虑迁移整个虚拟机。2.4 内存压缩与去重不搬数据也能挤出空间前面说的回收、迁移本质上都是把数据挪走。还有一类思路是让数据变少那就是压缩和去重。内存压缩的思路是把长期不用的匿名页压缩后放到一个专用池子里比如zram需要用的时候再解压回来。因为访问次数少压缩带来的CPU开销是值得的。但它有明显副作用压缩页不可直接映射每次访问都要走解压路径延迟高。所以内存压缩只能作为二级缓存存在不能把所有内存都压进去。内存去重则更进一步通过扫描物理页内容把内容完全相同的页面合并为一份通过写时复制机制共享。典型实现有KSMKernel Samepage Merging在虚拟化场景中效果显著——多台虚拟机如果跑相同镜像和运行库它们之间会有大量重复页面可以合并。去重的好处是空间收益大且对业务几乎无感知坏处是扫描和比对过程本身耗费CPU而且COW机制可能在写入时带来短暂的缺页中断延迟。在快速弹性伸缩的场景里压缩和去重通常不作为首要手段但它们是回收操作之后的重要补充。当某台物理机上所有可回收页面都回收完了但内存仍然不够用时压缩和去重可以再挤出一部分空间给在线业务留更多安全余量。3. 方案选型设计为快速伸缩搭建完整链路3.1 总体架构监控-决策-执行三层模型聊完底层机制可以往上走一层看看一套完整的内存弹性伸缩方案该怎么设计。我在实际项目中比较推荐监控-决策-执行三层模型和大多数资源调度系统类似但每一层都有针对快速伸缩的专门考量。监控层负责采集各个内核实例和cgroup的内存数据。数据源包括cgroup的memory.current和memory.max、系统的MemTotal/MemAvailable、NUMA节点的内存占比、页交换速率以及业务侧自己上报的延迟指标。采样频率很关键为了支撑快速伸缩采样周期一般要压缩到1秒以内有些对延迟特别敏感的场景甚至要到100毫秒级别。但采样频率越高监控本身占用的资源和CPU就越多所以要选轻量级采集方式比如直接读取内核导出的文件而不是频繁调系统工具做聚合。决策层负责判断该不该伸缩、往哪个方向伸缩、伸缩多少。这是整个系统的核心我建议不要用超过阈值就缩、低于阈值就扩这种静态规则至少要加入趋势判断和缓冲区间。因为内存水位是波动的如果只用硬阈值很容易出现频繁抖动——一会儿缩一会儿扩内核来回迁移页面性能和稳定性都吃亏。执行层负责把决策结果翻译成对底层机制的操作。它要面对前面提到的多种执行手段按优先级组合使用。执行层还要保证操作的原子性和可回滚一旦发现伸缩动作导致业务性能明显劣化能及时停止并恢复。3.2 决策算法水位预警、趋势预测与反馈调节决策算法直接决定这套系统是聪明还是呆萌。我在一个模拟项目中试过三种决策策略可以分享一些真实感受。第一种是纯阈值策略。设定一个高水位和一个低水位内存占用超过高水位就触发缩容低于低水位就触发扩容。实现非常简单但缺点是面对渐进式增长的场景反应迟钝。比如某个离线任务的内存占用每5分钟增长1G如果阈值设得不够智能系统会在它即将突破高水位时才做出反应此时后端已经没有充足时间来处理了。第二种是趋势预测策略。基于最近一段时间的内存增长曲线用简单的线性回归或指数平滑法预测未来几十秒内的内存需求提前做出伸缩决策。我试下来在内存增量相对稳定的场景下效果很好可以把事后补救升级为事前准备大幅降低业务被内存挤压的概率。缺点是在流量突变的场景下预测不准需要用限幅方法把预测值限制在合理范围内。第三种是反馈控制策略。参考PID控制器的思路根据当前内存水位和目标水位之间的误差以及误差的变化趋势动态决定伸缩幅度。这种策略胜在自适应能力强不会出现阈值策略那种一超出就剧烈操作、一回落就立刻放松的震荡。不过参数整定需要花时间慢慢调尤其是比例和微分两个系数调不好会出现超调或响应过慢。在实际方案中我建议用趋势预测加反馈控制组合预测结果决定要不要提前动作反馈控制决定动作力度。纯阈值策略只留作兜底。3.3 执行策略按成本从小到大排序决策层给出了要缩多少内存、要扩多少内存的指令执行层需要挑选合适的路径。根据实际操作的经验我的执行顺序通常是这样的第一步优先做软回收。调用cgroup v2的memory.reclaim接口把目标容器或虚拟机里可回收的干净文件页回收掉。这一步成本最低因为干净文件页不需要写回磁盘直接丢弃即可。实测中大部分容器的内存占用里都有相当比例的文件缓存回收它们几乎没有副作用。第二步如果软回收不够再考虑把目标对象的匿名页换出到swap或者压缩池。这涉及写盘或解压成本明显上升还可能让目标业务轻微感知所以从这一步开始就要监控业务SLA。第三步考虑只读页去重和压缩这部分空间属于挤牙膏式的额外收益步子不大但有胜于无。第四步才是热迁移或者内存热插拔。无论是迁移虚拟机还是offline内存设备操作代价都非常大相当于把整个资源重新布局。这种操作通常安排在低峰期或者伸缩对象本身是离线任务的场景中。这套执行策略的核心思想是先做代价小的再做代价大的和Linux内核本身的内存分层回收逻辑一脉相承。3.4 混部场景下的差异化策略混部场景和普通单业务容器场景最大的区别在于伸缩决策不能只看单一cgroup而要看全局资源再分配的公平性。具体来说要把在线业务和离线任务分开对待。在线业务对延迟敏感内存配额要尽量保持稳定即使要缩容幅度和频率都要严格约束离线任务则可以作为弹性缓冲区内存有富余时让它放开用内存紧张时优先收缩它。我在一个模拟部署中做过实验同一台机器上跑着一个在线推荐服务容器延迟敏感型和一个离线特征计算容器吞吐型。前者的内存配额是8G后者可以动态调整在2G到20G之间浮动。当在线服务流量升高、内存需求涨到接近阈值时决策模块直接把离线容器的内存配额减掉4G优先让在线服务扩展。整个过程中离线任务的执行时间从原来的10分钟拉长到了13分钟可以接受在线服务的尾延迟保持稳定感知不到内存波动。这就是混部场景中牺牲离线保在线的典型策略。但如果离线任务本身也有严格的服务等级协议这种牺牲就不适用了。这时候需要额外约束比如给离线任务设定一个最低内存保障线伸缩操作只允许在保障线之上生效。这就在系统里引入了竞价的概念本质和资源配额竞价一致。这种设置会让整体调度复杂度上升但从资源利用率的角度看收益值得。4. 实操验证与调优从配置到观测的完整记录4.1 实验环境与负载模型纸上谈兵没意思直接上实操记录。我搭建了一套模拟环境做验证一台96核256G内存的物理机上面用轻量虚拟化跑三台虚拟机分别模拟在线服务、离线任务和中间件类型的工作负载另外再起两个容器组共享宿主机内核。这样算下来物理机上同时存在三套客户机内核和一套宿主机内核足够模拟多内核混部的基本形态。负载模型方面我用了三路典型的压力在线服务用模拟的短连接HTTP请求每个请求随机读写16K数据请求间隔做成泊松分布制造比较真实的延迟抖动。离线任务用一个内存密集型脚本每30秒分配2G内存并保持占用模拟渐进式增长的内存需求。中间件场景模拟一个缓存服务内存访问模式为80%读、20%写用来检验回收策略对脏页的处理是否正确。整个实验目标很明确在离线任务内存需求上升、在线服务内存紧张的情况下能否在10秒内完成一次超过8G的在线服务扩容同时让在线服务的p99延迟劣化不超过20%。4.2 关键接口实测记录第一组实测针对cgroup v2的memory.reclaim接口。我先把在线服务容器的内存压到接近上限然后在宿主机上向它的cgroup写入回收指令# 查看当前内存用量 cat /sys/fs/cgroup/service_container/memory.current # 设置新的内存上限 echo 8G /sys/fs/cgroup/service_container/memory.max # 主动触发回收尝试回收4G内存 echo 4G /sys/fs/cgroup/service_container/memory.reclaim实测下来memory.reclaim的响应比我预想的快。第一轮写入4G回收量大约1.2秒后memory.current从11.2G降到了8.6G实际回收了2.6G左右。为什么不是整整4G因为剩下的页面里包含一部分正在被进程持有的活动页、一部分脏页还没写回以及一些内核持有的不可回收页。这也是前面说的写入值和实际回收量有差距的直观证据。我随后做了一次循环回收每0.5秒检查一次memory.current发现进程在持续分配内存回收和新分配在互相拉锯。这说明在缩容场景里光靠一次memory.reclaim不够必须配合业务侧的降载或内存分配控速水位才能真正稳定下来。第二组实测针对内存热插拔。把一台虚拟机的内存从16G缩减到12G先通过ACPI接口通知虚拟机操作系统然后在宿主机侧把对应内存块标记为offline。这个操作在纯实验环境下成功了但耗时接近40秒期间虚拟机的IO等待明显升高。原因是内核要迁移那些内存块上的活动页面迁移过程中的页表更新和TLB失效都带来开销。这个结果印证了前面的判断热插拔适合低频大动作不适合快速弹性伸缩。第三组实测是KSM去重。在两个跑相同镜像的虚拟机上启用KSM大约运行3个小时后内存去重率稳定在18%左右。整机内存有18%的内容是重复的合并之后能省下相当可观的空间。但KSM的CPU占用也不算低而且去重比例和镜像相似度强相关换了两个差异较大的负载后去重率直接掉到5%以下。所以KSM应该作为锦上添花的补充手段不能作为主力。4.3 参数调优与前后对比实测过程中我踩了几个参数调优的坑记录一下。第一个是memory.high和memory.max的配合。直接把memory.max设得很低会导致业务被强制回收出现明显卡顿。后来改成先把memory.high设低让内核先通过异步回收逐步释放内存过几秒再把memory.max跟进下调。这套温水煮青蛙的操作比直接一刀切平滑很多在线服务的尾延迟没有出现特别明显的尖刺。第二个是swappiness参数。在混部场景中如果离线任务占用了大量匿名页而系统里swap空间充足内核可能倾向于把匿名页换出以腾出内存。但对延迟敏感的在线业务来说换页是可以感知的。我的做法是把在线服务所在cgroup的swappiness调到接近0把离线任务的swappiness调高让内核优先换出离线任务的页。这个调整在实测中效果显著在线服务的p99下降了大约15%。第三个是自适应水位线的设置。前面提到决策模块用阈值策略容易抖动实验里我把单纯的高/低水位改成了趋势判断加回滞区间只有当内存趋势持续上升且超过回滞上限时才触发扩容只有当趋势持续下降且低于回滞下限时才触发缩容。回滞区间设置为500M能有效避免操作过于频繁。做完这些调整之后整体系统表现达到预期在模拟在线服务需要扩容8G的场景中从监控检测到内存水位异常到在线服务容器获得全部8G配额耗时约8.5秒在线服务p99延迟从扩容前的45ms变化到52ms劣化约15%在可接受范围内。而对比没有引入弹性伸缩机制之前的静态资源分区方案同一场景下在线服务的可容纳流量只有现在的70%。5. 高频问题排查与避坑经验5.1 回收不干净反向膨胀执行memory.reclaim之后最常遇到的问题就是回收入不敷出——回收了2G业务进程又马上分配了2G内存水位根本没降下来。原因有两个其一回收动作本身触发了业务进程的缺页处理业务在响应缺页的过程中也会分配内存其二业务侧存在内存池或预分配机制比如Java虚拟机的堆内存往往提前申请了一大块内存即使你用cgroup限制它它也会继续从堆里预分配。解决办法是在伸缩系统中加入业务侧协同通道。收缩前先通过业务接口通知目标服务释放内存池中空闲的部分或者在某些框架里调用类似jcmd的指令强制执行GC把堆内释放掉。只从内核层面硬回收效果很有限。我现在做方案设计时都会把内核回收和业务侧配合回收绑定在一起考虑。5.2 OOM误杀保护名单与优先级调整快速缩容有个致命副作用如果回收速度跟不上限定值内核会触发OOM Killer把cgroup内最重的进程杀掉。在混部场景里OOM误杀在线服务是大事故。我的经验是在决策层和执行层之外还要单独建立一个内存保护名单机制。给在线服务容器设置非常低的oom_score_adj值让它们即使面临OOM也不容易被选中同时把离线任务的oom_score_adj调高让内核优先杀离线任务。# 设置在线服务的OOM保护降低被杀概率 echo -800 /proc/pid/oom_score_adj # 设置离线任务的OOM可牺牲等级 echo 500 /proc/pid/oom_score_adj这里也要提醒一点OOM保护不是越强越好。如果在线服务保护到底内核就只能在离线任务里反复翻找可杀进程可能导致离线任务大面积死亡结果同样不理想。合理的方式是分级保护而不是一刀切。5.3 NUMA失衡伸缩之后性能不升反降内存伸缩如果发生在NUMA架构的机器上一定要小心节点间的内存失衡。我在一次实验中遇到过这种情况把某个虚拟机的内存配额从8G扩到16G业务性能不升反降。排查后才发现系统把新分配的内存页面全部放到了CPU访问延迟更高的远端NUMA节点上CPU访问内存要走跨节点总线延迟增加了近一倍。解决办法是配合NUMA绑定让目标cgroup的内存尽量落在同一节点上。具体操作上可以通过numactl或者cpuset的配置限制容器的CPU和内存节点范围。如果物理内存确实不够需要从远端节点借内存那就要做好心理准备这种跨节点的资源借调只能作为兜底不能作为常态路径。5.4 透明大页带来的隐性坑另一个容易踩坑的地方是透明大页THP。内存伸缩过程中THP的存在会让回收变得特别棘手。一个大页通常是2MB比普通4KB页大512倍当内核要回收一个大页时如果它不能被整体释放或写回就得先拆分成普通页再逐一处理。在内存紧张时THP的拆分和重组会显著拖慢回收速度。在混部场景下我通常建议把在线服务容器里的THP关掉或者至少设置成madvise模式只在应用显式声明需要大页时启用。离线任务场景则可以根据内存访问模式决定是否启用THP因为它们对延迟不那么敏感THP还能顺带减少TLB miss。echo never /sys/kernel/mm/transparent_hugepage/enabled echo madvise /sys/kernel/mm/transparent_hugepage/enabled实测中关闭THP之后特定容器的回收耗时大约下降三成在线服务延迟尖刺明显减少。代价是TLB miss率略有上升但整体收益大于损失。最后再分享一点个人心得。回看多内核混部场景下的快速内存弹性伸缩技术这道题我的整体感受是它本质上不是要发明一个新机制而是要把现有内核机制——cgroup控制、页面回收、热迁移、压缩去重——通过一套聪明的协同调度串起来在微观层面的快速和宏观层面的稳定之间找到平衡点。真正的难点不在单个接口怎么用而在怎么设计决策策略让系统既能快速反应又不至于频繁误判。我自己在这套实验里最大的收获是别把内存弹性伸缩当成纯内核层面的问题一定要把业务侧的工作负载特征纳入设计。不同业务的内存分配模式千差万别一套通用的伸缩策略很难满足所有场景。往后如果要继续深入我会考虑把BPF技术加入监控层以更细的粒度追踪页面冷热和分配来源让伸缩决策更精准同时也想尝试在多机之间建立全局内存资源视图让伸缩不局限在一台物理机内部。这个方向还有很大的探索空间路还挺长。