第一章：实时系统概述

大家好，我是你们这堂课的讲师。做实时系统性能调优这行，算算也有十几年了。今天咱们先聊聊最基础的东西——到底什么是实时系统。

很多人一听「实时」，就以为是「快」。其实不然。我见过不少项目，把系统做得飞快，结果关键时刻掉链子。为什么？因为实时系统的核心不是速度，而是确定性。

1.1 什么是实时系统

实时系统，说白了就是：系统必须在规定的时间内，对外部事件做出响应。这个「规定时间」不是随便定的，而是由业务逻辑硬性要求的。

举个例子。你开车时踩刹车，从你脚踩下去到刹车片夹紧，这个时间是有上限的。如果系统说「我尽量在100毫秒内响应」，你敢开吗？不敢。因为「尽量」在实时系统里，就是不合格。

我个人习惯把实时系统比作「准时制生产」。工厂里，零件必须在指定时间到达工位，早到或晚到都会出问题。实时系统也一样，响应太早或太晚，都可能引发故障。

1.2 硬实时与软实时的区别

这里有个关键概念，大家一定要分清：硬实时和软实时。

我在项目中遇到过不少新手，把两者混为一谈。结果呢？用软实时的方案去做硬实时的需求，系统一上线就崩。嗯，这里要注意。

特性	硬实时	软实时
错过 deadline 的后果	系统崩溃、人员伤亡、财产损失	性能下降、用户体验变差
典型 deadline	微秒到毫秒级	毫秒到秒级
设计原则	最坏情况分析（WCET）	平均情况优化
调度策略	优先级抢占、时间触发	优先级调度、尽力而为
典型系统	航空电子、安全气囊、心脏起搏器	视频播放、在线游戏、语音通话

硬实时：错过 deadline 就是事故。你想想看，飞机飞控系统如果晚1毫秒响应，可能就机毁人亡。这种系统，我们做性能测试时，必须测最坏情况，而不是平均情况。

软实时：错过 deadline 还能接受，只是质量下降。比如你看视频，偶尔卡顿一下，虽然不爽，但不会死人。这种系统，我们更关注平均延迟和吞吐量。

1.3 实时系统的典型应用场景

讲完理论，咱们看看实际场景。我挑三个最典型的领域来说。

1.3.1 工业控制

工业控制是实时系统的老本行。从PLC到DCS，从机器人到数控机床，全是实时系统的天下。

我记得有一次去一个汽车焊装车间做性能评估。生产线上的机械臂，每个动作的时序都是精确到毫秒的。如果某个关节的响应慢了5毫秒，焊点位置就偏了，整台车身的强度就不达标。

工业控制的特点：

• 周期性任务为主：比如每10毫秒采集一次传感器数据
• 确定性要求极高：抖动（jitter）必须控制在微秒级
• 环境恶劣：高温、振动、电磁干扰，对硬件和OS都是考验

1.3.2 自动驾驶

自动驾驶，可以说是目前最复杂的实时系统之一。它融合了感知、决策、控制三个环节，每个环节都有严格的时序要求。

你想想看，一辆车以120km/h行驶，每秒前进33米。如果感知系统晚处理100毫秒，车就已经冲出去3.3米了。这3.3米，可能就是撞上护栏和避开障碍物的区别。

自动驾驶的实时挑战：

• 传感器融合：摄像头、激光雷达、毫米波雷达的数据必须在同一时间窗口内对齐
• 决策延迟：从感知到决策，通常要求<50ms
• 控制周期：车辆控制指令的发送周期，一般是10-20ms

我个人习惯在自动驾驶项目中，把实时性测试分成三级：传感器级、算法级、执行级。每一级都有独立的 deadline 和监控指标。这样出了问题，能快速定位是哪个环节超时。

1.3.3 金融交易

金融交易，尤其是高频交易，对实时性的追求近乎变态。我见过一个交易系统，为了节省1微秒，把整个软件栈从Linux换成了专用实时OS，网卡也换成了FPGA加速卡。

为什么这么拼？因为在金融交易里，速度就是金钱。你比竞争对手快1毫秒，就能在价格波动中抢到更好的成交价。这1毫秒，可能价值几百万美元。

金融交易系统的实时特点：

• 事件驱动：行情数据一来，必须立即处理
• 微秒级延迟：端到端延迟通常要求在10-100微秒
• 确定性优先：宁可丢单，也不能延迟

好了，第一章的内容就到这里。实时系统的概念其实不难，难的是在实际项目中，如何把「确定性」这个原则贯彻到底。下一章，我们会深入讨论实时系统的性能指标，以及如何用基准测试来量化这些指标。

记住一句话：实时系统没有「差不多」，只有「行」和「不行」。