---
title: 计算机系统中的控制
url: https://doc.liz6.com/theory/02-control-theory/09-control-in-computing-systems
locale: zh
area: theory
tags:
- 控制理论
- 基础理论
date: 2026-09-10
modified: 2026-09-10
description: 服务流量上升后，扩容决策可能已经发出，而新实例仍在启动。若控制器把“已经请求的容量”当成“已经可用的容量”，或反过来忽略待生效动作，就容易产生错误判断。本篇用简化模型连接采样与延迟、约束与鲁棒性。
---
# 计算机系统中的控制
服务流量上升后，扩容决策可能已经发出，而新实例仍在启动。若控制器把“已经请求的容量”当成“已经可用的容量”，或反过来忽略待生效动作，就容易产生错误判断。本篇用简化模型连接[采样与延迟](07-sampling-and-delay.md)、[约束与鲁棒性](08-constraints-and-robustness.md)。
## 先选对状态与单位
令 $q_k$ 为时刻 $k$ 的等待请求数，$\lambda_k$ 为到达率（请求/s），单实例处理能力为 $\mu$（请求/s），$n_k$ 为实际可用实例数，步长 $\Delta t$ 为秒。一个流体近似是
$$q_{k+1}=\max\{0,q_k+\Delta t(\lambda_k-\mu n_k)\}.$$
它把工作量当作可连续分割、实例同质、服务能力固定；没有逐请求的服务时间、在途任务、重试、失败或负载均衡细节。因此可以解释积压变化，不能直接输出真实 p99 延迟。
取 $\mu=10$、$n=4$、$\lambda=70$，每秒增加30个等待请求。若新容量20 s后才生效，期间就可能积压600个请求。最终扩到7个实例只做到到达与处理相等，已有积压不会自动下降；还需要额外容量或流量回落。
## 决策、命令与生效是三个时间点
一个简化容量建议可以写成
$$n_k^*=\left\lceil\frac{\hat\lambda_k+q_k/T_{\mathrm{clear}}}{\mu}\right\rceil.$$
$\hat\lambda_k$ 是估计到达率，$T_{\mathrm{clear}}>0$ 是希望清理积压的时间。前一项匹配新流量，后一项安排消化旧积压。取到达70、积压600、$T_{\mathrm{clear}}=30$，需要 $(70+20)/10=9$ 个实例，而不是7个。
这是一条教学策略，不是 Kubernetes HPA 的实现，也没有对任意延迟的稳定保证。实际命令还会受到最小/最大实例数、每次变化上限、启动延迟与缩容约束影响。若每次建议9个都错误地“再增加9个”，就连控制量的绝对值与增量也混淆了。
**计算机系统中的控制 · 实验**
每10 s决策，20–100 s到达率20→70请求/s，单实例10请求/s，上限12个；确定性流体模型、无重试。命令按延迟顺序生效，窗口取近期建议最大值；不实现完整HPA或p99预测。
流量在20–100 s从20增至70请求/s，然后回到20；每10 s决策一次，每实例10请求/s，最多12个实例。控制器使用当前流量与积压，命令在指定延迟后按顺序生效。分别显示建议数、命令数和可用数；缩容窗口在历史建议中取最大值。这个对称生效延迟是教学简化，真实扩容和缩容不一定具有相同动态。
## 平滑策略付出了什么？
容差忽略小幅指标变化，稳定窗口利用近期建议避免立即反向调整，速率限制约束一次或一段时间内的容量变化。这些措施可能减少抖动，也会推迟响应或增加空闲成本。窗口不是平均滤波的同义词：取历史最大值和取均值是不同策略。
Kubernetes HPA 按周期读取指标并调整期望副本数，其基础比例关系为
$$n_{\mathrm{desired}}=\left\lceil n_{\mathrm{current}}\frac{m_{\mathrm{current}}}{m_{\mathrm{target}}}\right\rceil.$$
官方算法还处理容差、缺失指标、尚未就绪的 Pod、多指标选择以及扩缩行为。缩容稳定窗口参考窗口内的最高建议，并不是简单要求“连续若干次都低于目标”。具体字段与默认值需按部署版本核对。[HPA 官方机制](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/)
## 积压、利用率和延迟不能互换
低CPU利用率可能来自I/O等待，高CPU利用率也不必然等于请求排队。平均延迟与尾延迟取决于服务时间分布、调度与负载等因素。没有合适模型时，用一种指标直接换算另一种会把测量误差引入反馈。
在适当的稳定、长期平均条件下，Little 定律联系系统内平均数量、有效通过率与平均逗留时间。它不能用来把一次瞬时队列长度除以瞬时流量就称为p99。后续排队论将讨论这些条件；这里的状态更新只做工作量收支。
## 如何迁移到 TCP 与硬件？
TCP以ACK、丢包、RTT或ECN等信号调整发送行为，反馈存在网络往返延迟；不同拥塞算法的状态与控制律并不相同。把所有TCP写成PID，会丢掉协议细节。回看[TCP](../../networking/03-l4-transport-layer/01-tcp.md)时，可以标出观测、状态和动作，保留原算法。
[电源电路](../../hardware/04-analog-circuits/03-power-supply-circuits.md)则通过电压/电流测量调整功率级，能量储存和补偿网络形成动态。跨领域迁移的是建模与分析方法，不是同一组增益。
## 自检
70请求/s到达，单实例10请求/s，积压600个。扩到7个实例后会在多久清空？
参考思路
在这个恒定流量模型中不会清空，因为净处理余量为零。9个实例有20请求/s余量，在容量立即生效且无额外变化时需要30 s。
参考思路
可能减少反复启动，但保留更多空闲容量并增加成本。应在同一流量轨迹下比较积压、动作次数和实例秒数，同时检查新的上升流量能否及时处理。