2026 认证服务器租用配置手册：FreeRADIUS 并发认证与计费日志避坑干货大全

2026 认证服务器租用配置手册：FreeRADIUS 并发认证与计费日志避坑干货大全

这篇写给四类人：园区网与高校宿舍网的运维、连锁门店 Wi-Fi 的交付方、宽带接入与 ISP 的接入平台工程师、把 VPN 与远程接入统一收口的企业 IT 团队，也包括做设备入网准入与物联网卡接入认证的厂商。共同点是你们要在一台或几台租用服务器上跑 FreeRADIUS，需要在下单前判断配置该往哪个方向加。先给结论：FreeRADIUS 的容量算的是每秒认证请求数与同时在网的会话状态数，不是"能带多少万个用户"。用户总数决定的是存储与记录规模，每秒请求数决定的是 CPU 与线程池，这两件事之间不能互相换算。下面每一条判断都落到具体的协议行为与配置项上，参数细节以你实际使用的 FreeRADIUS 版本配置文件注释为准。

UDP 超时重传会把请求量自我叠加

RADIUS 的认证端口是 1812，计费端口是 1813，早期实现用过 1645 与 1646，现在遇到老型号设备仍要把这两个端口一并放行。协议跑在 UDP 之上。UDP 没有连接状态，NAS 发出一个 Access-Request 之后能做的只有一件事：启动一个定时器，到期没等到 Access-Accept 或 Access-Reject 就把同一份请求再发一遍。多数 NAS 的默认行为是三秒左右首重传、再试两到三次，有的厂商允许调整重试计数与切换备份服务器的阈值，这些参数在 NAS 侧而不在服务端。

由此得到一条很硬的推论：服务端要处理的不是"客户端发起的请求"，而是"客户端所有等待中的请求"。假设因为后端慢查询，单次认证退化到九百毫秒，看起来距离三秒的首重传还很远；可是慢查询往往是连锁反应，一次认证排队到三点二秒才出结果时，这份请求已经在 NAS 侧被重发过一次。服务端并不知道这是重传副本，它会把它当作一个新请求重新走一遍 authorize、authenticate、post-auth 全流程。请求量就这样自己叠了上去。

正反馈的形状是这样的：响应变慢导致重传变多，重传变多导致队列变长，队列变长让响应更慢。这个循环一旦启动就不会自己收敛，CPU 会长时间贴在满载位置，哪怕新用户请求已经开始回落。运维看到的现象是"业务高峰都过去半小时了服务器还卡着"，因为大部分算力正在处理没人需要的重传副本。

所以认证服务器的首要指标是时延分布，尤其是 P99，而不是吞吐。工程上取一个简单的口径：把单次认证的 P99 压在 NAS 首重传定时器的二分之一以内，比如 NAS 三秒重传，服务端就按一点五秒作为告警线，正常稳态要做到几十毫秒量级（预估）。这个目标不达标，加内存、加带宽都解决不了问题。

FreeRADIUS 侧确实有重复包识别，依据源地址、RADIUS 标识与 Request Authenticator 判断短时间内的同包并丢弃。但它的缓存窗口有限，超过窗口时限才到达的重传照样被当成新请求。这层机制能挡住毫秒级的网络抖动，挡不住秒级的队列堆积，不要把它设计成容量上的兜底。

还有一种容易忽略的叠加形态：NAS 配了备份 RADIUS 服务器。主服务端变慢，NAS 重传若干次后把请求切到备份机；如果两台共享同一个后端数据库，主服务端遭遇的慢查询会在备份机上原样重演，备份机跟着一起慢。这时候两台机器是串联受害，不是互相冗余。

EAP-TLS 一次认证是几十次往返不是一次

PAP 与 CHAP 的模型很简单：一个 Access-Request 进去，一个 Access-Accept 或 Access-Reject 出来，服务端算一次口令比对，耗时的边界非常清楚。

EAP-TLS 与 PEAP 完全是另一回事。RADIUS 在这里只承担 EAP 报文的搬运通道，EAP 消息被装进 EAP-Message 属性里，而这个属性单个实例的长度上限是 253 字节，超出就必须在 Message-Authenticator 的配合下拆成多个 RADIUS 报文分片。一次完整的 TLS 握手要来回多轮：Client Hello、Server Hello、Certificate、Server Key Exchange、Client Key Exchange、Finished，每一轮都要在终端与 FreeRADIUS 之间往返，而每一轮往返又可能因为 253 字节的限制拆成好几包。

粗略算一笔账：服务端证书加中间证书的典型大小在一千到两千字节之间（预估），按每包 253 字节有效载荷折算，一张证书链就要拆成七到十个包。再叠上握手自身的多轮往返，一个终端完成一次 EAP-TLS 入网，服务端看到的 RADIUS 请求数是几十次而不是一次。按"每用户一次认证"去做容量估算，在这类方案上会低估一到两个数量级。

CPU 开销同样不是一个量级。EAP-TLS 的服务端要做私钥一侧的运算，RSA 2048 的服务端签名或解密开销远高于对称运算；终端侧虽然也要算力，但服务端承担的是握手里更重的那一侧。把证书的 RSA 换成 ECDSA 曲线，单次握手的 CPU 消耗会明显下降（预估），这在密集入网场景是性价比最高的一步调整，前提是终端侧兼容性验证通过。

真正危险的是集中爆发。无线控制器或 AP 大面积重启、交换机上联闪断几分钟、机房做一次割接，恢复的瞬间所有在线终端同时发起重新认证。稳态每秒只有几十次请求的园区，这一瞬间可能涌出几千次请求，而且全部是几十次往返的 EAP-TLS。规划时要按"所有终端在一个握手周期内重认证完"的最坏情形给 CPU 留量，不要按平均在线数算。

取舍要写清楚：终端数量大且组织里没有证书管理能力时，强推 EAP-TLS 会把成本全部转移到运维工单上，证书过期、终端时间不同步、信任链缺失都会表现为"連不上 WiFi"。这种组织结构下用 PEAP 配合服务端证书更现实，但后端必须能提供 MS-CHAP 可用的凭据形态，选型前要与身份源的负责人对齐（以咨询为准）。TLS 会话恢复建议开启，它能让短暂断连免走完整握手，对突发有明显的削峰作用。

LDAP 与 MySQL 后端单次认证的查询次数差异

authorize 阶段是一条模块链，顺序执行，每个模块返回的结果决定后续走哪条分支。看清这条链，才知道一次认证到底触发了几次外部查询。

SQL 后端的典型查询序列是：查 radcheck 拿用户口令，查 radreply 拿下行属性，查 radusergroup 拿组归属，再查 radgroupcheck 与 radgroupreply 拿组的检查项与下发项。四次到五次查询是常态，组嵌套再展开一层次数还会往上加。这些查询是串行的，单次认证时延约等于各次查询时延之和。

文件型 users 的处理方式不同：进程启动时把文件读进内存，认证退化成内存里的匹配与正则处理，没有网络往返，也没有连接池争用。用户规模在几千以内时它是最省心的方案，代价是改一个用户要 reload 进程，并且多台机器之间不会自动一致，得靠配置分发来保证。

LDAP 后端一般是两步：先按用户名 search 找到 DN，再用这个 DN 做 bind 校验口令。两步之间的网络往返无法省略，所以 LDAP 服务的物理位置很关键。跨城部署时一次往返就是二三十毫秒（预估），两次操作再加上 TLS 握手，单次的时延预算就被吃掉一半以上。把 LDAP 的只读副本放在与 FreeRADIUS 同机房或同可用区，比调任何 FreeRADIUS 参数都有效。

SQL 后端的好处是认证与计费共用一套库，套餐、限速、VLAN 下发都能在同一处维护，业务系统集成方便。代价是每次查询要占用一个连接池连接。连接池小于工作线程数时，线程会阻塞在等待连接上，监控看到的现象是 CPU 不忙但时延很高，这类问题最难定位。取法很直接：连接池大小不小于 max_servers 的值，宁可让数据库连接数配比略高（预估），也不要让线程等连接。

索引是每次扩容前必查的项。radcheck 的 username 必须有索引，radreply 与 radusergroup 同样。缺索引时数据库走全表扫描，认证时延随用户数线性上升，一万用户和十万用户是两个完全不同的世界。慢查询日志要长期打开，它是找出这类问题最快的手段。

凭据不要缓存。为了省几次查询，在 FreeRADIUS 侧缓存用户口令或者 NT hash，后果是改密码不立即生效、锁定账号不立即生效，报上来的形状是"我明明已经改了"。省下的那点查询开销换不来这些投诉，正确的做法是优化数据库查询本身，而不是给认证结果加缓存。

max_requests 与线程池 spare 的排队因果链

FreeRADIUS 3.x 的线程池配置在 radiusd.conf 的 thread pool 段里，几个参数经常被混淆：start_servers、min_spare_servers、max_spare_servers、max_servers，以及 max_requests_per_server。

max_requests_per_server 说的是每个线程处理完多少个请求之后就退出，由父进程重新拉一个新的。它的作用是防止内存泄漏或者某种资源在长跑线程里累积，属于自保机制。把它当成并发能力去调大是完全搞错了方向，调到很大只会让泄漏累积得更久。

决定并发上限的是 max_servers，也就是同时存在的工作线程数。请求进来时如果所有线程都忙，请求就进队列，队列长度由 listen 段的 max_requests 控制，不同版本的命名与语义有差异，以你所用版本配置文件的注释为准。

因果链要完整背下来：瞬时请求数超过 max_servers，请求开始排队；排队时间计入总响应时延；总时延超过 NAS 的重传定时器，NAS 重发；服务端把重发当成新请求，队列更长；更长的队列把时延推得更高。这条链子转到第二轮之后就很难自己停下来。

所以队列长度要刻意设短。听起来反直觉，理由却很直接：RADIUS 的可靠性是靠客户端重传保证的，一个包如果在队列里排到三秒才被处理并发出去，客户端早已经重传过，也可能已经在别处得到了响应，这次处理产出的是一份没人接收的结果，纯属浪费。与其让请求慢慢排队，不如早点溢出或者干脆不响应，让 NAS 走它自己的超时与切换流程。

spare 系列参数决定空闲线程保留多少。突发场景把 min_spare_servers 调高是有意义的，线程预先站着不用到时候现建；但如果 CPU 已经打满，多备线程只会让上下文切换更频繁，时延反而更差。判断标准很简单：加线程之后时延不降反升，就说明瓶颈是 CPU 而不是线程数量，此时该加核或者降低单次请求的计算量。

给一条明确的取舍：EAP 场景下不断调大 max_servers 是最常见的错误动作。单次握手的公钥运算是实打实的 CPU 消耗，在核数固定的前提下，并发线程越多，每个握手分到的 CPU 时间越少，单个终端的握手时间越长，越容易被 NAS 判超时。正确的动作是加 CPU 核数，或者换更省算力的证书算法。

Interim-Update 间隔与 radacct 表的写放大

每个在线会话在计费侧向服务端交付三类包：Start、Interim-Update、Stop。Start 在会话建立时发一次，Stop 在会话结束时发一次，中间的 Interim-Update 按间隔持续发送。稳态下绝大多数计费包是 Interim-Update。

写放大怎么算：在线会话数除以间隔秒数，就是稳态的每秒更新条数。一万在线、间隔三百秒，每秒约三十三条；把间隔压到六十秒，每秒一百六十七条，整整五倍。还有一类突发必须提前想到：汇聚设备断电或者链路闪断时，它承载的所有会话会在同一瞬间发出 Stop，如果它带着五千个会话，那就是五千条写入在一两秒内到达。

更新语句本身也有讲究。典型的做法是先按 Acct-Session-Id 与 NAS 标识去 UPDATE，影响行数为零说明这行还没落库，再退回 INSERT。写不好的话每条 Interim-Update 就是两次 SQL。用 radacct 的唯一键配合 ON DUPLICATE KEY UPDATE 可以在数据库侧一次搞定，比在应用层判断返回行数更省。具体写法取决于你的 MySQL 或 PostgreSQL 版本与 FreeRADIUS 的 sql 模块配置（以咨询为准）。

行的数量级要提前算清楚。一万在线、日活三万用户、每人每天产生多个会话，一天落到 radacct 的行数可以到百万到两百万量级（预估），一年就是几亿到七亿行。在这个规模下，任何针对 radacct 的全表扫描都会拖垮整个实例，按用户按月的统计必须走索引与汇总表。

什么时候该降低写入频率：如果业务不是预付费的实时扣减，六百秒甚至更长的间隔完全够用。把间隔从六十秒放宽到三百秒，写压力直接降到五分之一，这是收益最大且成本几乎为零的一步。真正需要六十秒精度的只有实时余额类业务，那种场景更适合交给专业的计费中间件承担，RADIUS 的 interim 只作为会话留痕。

还有一层可以利用：多数 NAS 的 Acct-Interim-Interval 是可以从服务端下发下去的。这意味着可以给不同区域、不同套餐下发不同的更新间隔来错开写入压力，而不是全局一刀切。

计费写入是随机写加高频小事务

每一条 Interim-Update 落到 MySQL 的 InnoDB 上都是一次独立的小事务：按索引定位到行，更新列，维护索引，写 undo，写 redo，如果开了 binlog 还要再写一份。对磁盘而言这是典型的随机写加高频小事务，与顺序追加写日志的模型完全不同。

固态盘在这类负载下的差异极大。SATA 接口的消费级盘在持续混合随机写并且盘上空间占用到一定程度之后，时延能从零点几毫秒涨到毫秒级；NVMe 盘在足够队列深度下能稳住高得多的 IOPS。计费场景挑磁盘看的是稳态 4K 随机写 IOPS 与写时延的稳定性，不是标称顺序带宽。选 SATA SSD 还是 NVMe，取决于你的每秒写入条数与可接受的主从延迟。

选择云盘形态还要额外看一件事：IOPS 上限与突发额度。很多块存储给的是突发额度，短时间能跑到很高，额度耗尽后回落到基准值。而计费写入是持续负载，用它来支撑常态写入，撑不了多久就会遇到突然的写卡顿。选型口径可以按常态写入 IOPS 的一点五倍去倒推所需基准 IOPS（预估）。

radacct 的索引策略直接决定写入速度。索引越多，每次 UPDATE 要同步维护的 B+ 树越多。常规做法是给 Acct-Session-Id 与 AcctUniqueId 建唯一键，给 username、nasipaddress、acctstarttime 建组合索引满足常见查询，其余一律不放。

归档必须做，而且方法要对。按月或者按周给 radacct 做分区，历史数据用分区交换的方式整块摘出去，比 DELETE 若干亿行要好得多。大面积 DELETE 会生成海量 undo 与 binlog，把主从复制延迟拉到小时级，还会留下严重碎片。

取舍很明确：不要在业务高峰执行归档删除。把历史数据导出到独立的归档实例，业务库保留最近一到三个月，绝大多数场景足够。真要看长期趋势，应该在归档侧做汇总，而不是让主库扛着统计查询。

计费库与认证库要不要分开，取决于写压力与可用性要求。分开的直接收益是计费的 IO 抖动不会传导成认证的查询时延，并且计费库做维护时认证仍能继续。同机同实例部署只有在线会话数与写频率都很小的时候才成立。

EAP 会话缓存与 TLS 会话缓存的内存账

EAP 握手跨越几十个 RADIUS 往返，中间状态必须保留下来，包括 OpenSSL 的握手上下文、已收到的分片、待拼接的证书链。这部分内存在 worker 线程上，随着并发握手数线性增长。

量级估算：单个进行中的握手占用从几 KB 到几十 KB（预估），取决于证书链长度与 TLS 记录层缓冲。稳态有一千个并发握手时占用可能到上百 MB；前面提到的 AP 重启风暴让这个数字短时间翻几番，就是吃掉好几个 GB。

在线状态的判定要单独说清楚：RADIUS 没有可靠的"我下线了"通知机制。终端掉电之后 Stop 永远不会到达，radacct 里那条记录会一直停在最后更新时间。常见的判定是看 Acct-Update-Time 或者最后一次更新的陈旧程度，超过更新间隔的若干倍（比如三倍）仍没有新记录就标记为离线，这是一个概率性判断，不是精确状态。

主动踢线要走 CoA 与 Disconnect-Request，端口在不同实现上不一致，3799 与 1700 都常见，配置前按 NAS 厂商文档核实。这一条同样属于服务端与 NAS 之间的一致性项，防火墙策略要跟着放行，否则服务端发出的请求收不到响应，看起来像功能失效。

内存规划口径：先按在线会话数估算稳态占用，再乘以二到三倍作为突发余量，最后叠加操作系统、数据库缓冲与日志缓冲。如果目标在线会话是几万并且 EAP 突发明显，基础内存要从常见的 4GB 往上抬，具体抬到多少按上面的估算走（预估）。内存不足的后果很直接：进程被 OOM 终止，表现为整网立刻无法认证，而不是慢慢变慢。

还有一个慢性的资源项：很多部署会把 detail 文件作为可靠的计费落盘手段，再由 sql 模块重放。如果 SQL 写入卡住而 detail 持续堆积，磁盘会被慢慢吃满，最终变成写不进去。给 detail 目录单独分区并且监控它的增长速率，是低成本的保险措施。

clients.conf 共享密钥在几十个 NAS 以内的边界

clients.conf 里每一条 client 定义包含 NAS 的地址或网段、shared secret、以及一个便于识别的 shortname。服务端收到包先看源地址能否匹配到某个 client，匹配不上直接丢弃；secret 不一致则校验失败，同样丢弃。

规模在几十个 NAS 以内，文件方式完全可用。改一次 reload 一次，变更频率低的情况下维护成本可以忽略。

上百个门店或者几百台 NAS 时问题性质就变了：新增一家门店要动文件，格式写错可能导致整个进程起不来；轮换 secret 要逐条改并且与门店侧对齐时间窗；不同运维人员同时改会互相覆盖。这时候把 NAS 定义放进数据库的 nas 表由 sql 模块读取，或者交给配置管理工具统一分发，是更稳的做法。

规模变大之后，"某个门店认证不上"最常见的根因其实很朴素：两端 secret 不一致，或者 clients.conf 里的网段没有覆盖 NAS 的实际源地址。这一类问题在服务端日志里表现为丢弃而不是报错，不熟悉的人容易往网络层去找。

NAT 是这里的高发坑。门店出口做了地址转换之后，服务端看到的源地址是转换后的地址，clients.conf 里按内网地址配就永远匹配不上。反过来多个门店共用同一个出口地址时，服务端无法用地址区分它们，secret 只能共用，隔离粒度随之变差。这个约束要在组网阶段确认清楚，而不是上线后救火。

另一条：不要给所有 NAS 用同一个 secret。共享密钥一旦泄漏，受影响的是全部设备。按区域或者按门店分发不同 secret 是低成本的风险收敛手段，配合定期轮换执行。

secret 的强度也要到位：太短的字符串处在可枚举范围内，长度建议给到十六位以上并包含多种字符形态。这一条既是配置习惯问题，也是后续做规模化管理的先决条件。

主备双机与分支机构就近转发

认证属于强依赖服务，它停下来的表现不是某个功能不可用，而是整网用户上不了网。故障发生的时间点往往是最坏的时间点，所以至少两台，并且上游 NAS 侧要配好主备列表。

但两台服务器本身不构成冗余的一半。真正决定可用性的是它们后端指向的是否同一份数据：同一个用户源、同一套组与属性定义、同一份在线状态。两台各自指向不同的本地数据库又没有同步机制，表面上是双机，实际上在 A 机新注册的用户到 B 机上认证不通过。

数据库侧的可用性要一并考虑。给数据库至少配一个只读副本，SQL 后端本身可以做读写分离，写库做主备切换。选型时必须把数据库的高可用方案与 RADIUS 的双机一起排期，否则很容易做出半成品。

跨地域分支机构要单独处理。如果所有认证都跨省回到总部，一次认证要在往返时延上叠加二三十到四十毫秒（预估），PAP 场景还能接受，EAP-TLS 的几十次往返乘上去就到了秒级，用户的体感是"输完凭据要等很久"。两种解法：在分支机构本地部署认证节点、只把计费汇总回总部；或者在汇聚层用 FreeRADIUS 的 proxy 按 realm 转发，让请求落在距离最近的处理节点上。

proxy 配置里有两个容易忽略的参数：dead time 与 retry。故障节点被判定不可达之后，dead time 之内不再向它发请求。这个值设得太短，后续请求会被反复用来探测故障节点，等于自己给自己加压；设得太长，节点恢复之后缺少感知手段。建议先在测试环境把这一块的失败行为打一遍再上生产（预估）。

取舍：预算有限的情况下，两个可用区各一台中配、数据库做主从，抗风险能力远好过单个可用区里的一台高配。认证业务的可用性瓶颈从来不是单机性能不足，而是单点故障的暴露面太大。

什么规模下一台 2 核 4G 就够用

把前面的机制收拢成一份取舍清单。第一种情形：用户总数在几千、认证方式是 PAP、CHAP 或者 MAC 旁路、后端用 users 文件或本地 SQLite、计费只要粗粒度留痕。这种场景一台 2 核 4G 足够，唯一不能省的是要用 SSD 而不是机械盘来承接 radacct 的随机写。

第二种情形：在线会话稳定上万并且有实时用量诉求。数据库要独立出去，认证查询走只读副本，计费写主库。判断信号很清晰——只要出现慢查询拖慢认证、或者主库磁盘占用长期高位，就该拆了。

第三种情形：全网 EAP-TLS 且终端数万。瓶颈几乎肯定在 CPU 的公钥运算上，优先提高主频与核数，或者把证书体系迁到 ECDSA 曲线（预估）。这种情况下加内存和加线程都看不到效果。

第四种情形：瓶颈不在 RADIUS 进程本身。判据是 CPU 空闲、队列为空、但时延依然高，这时候请求大概率卡在等数据库连接或者等 LDAP 响应，加 CPU 无效，应该去查连接池大小与索引缺失。反过来，CPU 跑满而 iowait 很低，才是加核或者削减 EAP 开销的信号。

一万网络面向 FreeRADIUS 认证场景的服务器租用配置口径

一万网络深耕 19 年（成立于 2007 年），是天下数据旗下的品牌，长期为企业提供服务器租用与相关接入方案。落到 FreeRADIUS 这个具体场景上，我们把配置口径拆成三件事来讲，方便你在下单前对照自己的量级。

第一件是 CPU 与内存的分工。CPU 主要服务于每秒请求数与 EAP 握手的公钥运算，内存主要服务于在线会话状态、EAP 握手上下文与数据库缓冲。认证密集而 EAP 占比低的场景，两核到四核配 4G 到 8G 内存是常见的起步配置；EAP-TLS 占比高或者终端数量大，要优先抬 CPU。具体档位按你测算的每秒请求数与在线会话数确定（预估）。

第二件是磁盘的选择。计费写入是随机写加高频小事务，看的不是顺序带宽而是稳态随机写 IOPS 与写时延稳定性。在线会话量大、Interim-Update 间隔短的场景优先选 NVMe，量小的场景 SATA SSD 也可以，但不建议用机械盘承接 radacct。归档盘与业务盘建议分开，历史数据单独导出。

第三件是位置与冗余。分支机构分散的企业要考虑就近部署认证节点或者用 proxy 转发，避免所有认证跨省回到一处；无论规模大小，都应至少规划两台并配合数据库的高可用方案。可用地域覆盖中国香港、中国台湾、中国澳门以及海外多个区域，具体机房清单与带宽组合以实时咨询结果为准。

关于价格：这类认证服务器的配置跨度很大，从两核小规格到多核大内存都有，且不同机房、不同带宽与防护组合之间差异明显，公开渠道报价差异较大，以实时报价为准，具体方案需询价。

数据来源与核对方式：FreeRADIUS 并发与计费字段的口径清单

本文涉及的参数名称、默认值与行为描述，请以你实际部署的 FreeRADIUS 版本为准核对。核对顺序建议如下：先确认版本号，再打开 radiusd.conf 的 thread pool 段与 listen 段，把 max_servers、max_requests_per_server、队列长度这三个值的注释逐条读完；然后打开 mods-enabled 下实际启用的 sql 或 ldap 模块，确认连接池大小与查询语句；最后检查数据表的索引定义。

协议侧的口径来自 RADIUS 自身的报文行为：1812 认证端口、1813 计费端口、EAP-Message 单实例 253 字节的分片约束、Acct-Interim-Interval 可由服务端下发。CoA 与 Disconnect 的端口号在不同实现上有差异，3799 与 1700 都需要按 NAS 厂商文档核实。

本文中标注（预估）的数字，包括单次握手内存占用、radacct 日行数量级、跨城往返时延、IOPS 预留倍数等，均为基于通用工程经验的推算，不可当作承诺值直接使用。上线前建议按文中的量级算法代入自己的真实在线会话数、更新间隔与日常链路上，用压测或者灰度的方式验证一遍再定配置。

核对完成后建议留一份记录：版本号、线程池参数、连接池大小、索引清单、更新间隔、历史行数增长速率。这六项在后续扩容与故障复盘时用得上，也能避免不同批次的运维人员各自按不同口径去调参。