3、软实时系统定义
好，咱们来聊聊软实时系统。说实话，这个概念我刚开始接触时也觉得有点模糊——到底什么叫「软」？跟硬实时差在哪？
先给个最直白的定义：软实时系统，就是允许偶尔错过截止时间的系统。错过就错过了，系统不会崩溃，功能也不会停摆。但代价是什么？性能会下降，用户体验会变差。
我习惯这么理解：硬实时是「必须赶上火车」，赶不上就出大事；软实时是「赶不上这班公交，等下一班也行」，就是多等几分钟，有点不爽，但死不了人。
错过截止时间的后果：性能下降，而非失败
这是软实时和硬实时最本质的区别。硬实时系统里，错过截止时间等于系统失败。但在软实时系统里，后果是服务质量（QoS）的退化。
举个例子你就明白了：
- 视频通话：偶尔卡顿一下，画面模糊几秒，但通话不会断
- 在线游戏：延迟突然飙到200ms，操作有点飘，但游戏还在运行
- 语音助手：你说「嘿Siri」，它反应慢了半拍，但最终还是回应了你
嗯，这里要注意：性能下降的幅度和频率，决定了用户能不能忍。我在项目中遇到过一款视频播放器，解码延迟偶尔超过50ms，画面就开始掉帧。用户反馈说「看着头晕」。你看，虽然系统没崩溃，但体验已经不行了。
核心要点：软实时系统的设计目标不是「永不超时」，而是「超时后还能优雅降级」。
典型应用场景
说白了，我们日常生活中接触到的实时系统，绝大多数都是软实时的。我挑三个最典型的说说。
1. 视频流媒体
你看B站、刷抖音，背后都是软实时系统在支撑。视频帧必须在特定时间内解码并显示，比如30fps的视频，每帧的间隔大约是33ms。
如果解码器偶尔超时了怎么办？
- 最简单的做法：丢帧。跳过这一帧，直接显示下一帧
- 高级一点：插帧。用前一帧和下一帧的数据，估算出中间帧
我记得有一次做嵌入式播放器，解码芯片的buffer设计不合理，导致每播10秒就卡一次。排查下来发现是DMA传输的优先级设低了，被其他中断抢了时间片。调整之后，卡顿问题就解决了。
避坑指南：我曾经在视频项目中犯过一个低级错误——把解码线程的优先级设得跟UI线程一样高。结果UI操作一多，解码就超时。后来我习惯把解码线程优先级调高一级，同时给UI线程留一个保底的响应时间片。
2. 在线游戏
游戏对实时性的要求，其实比视频流媒体更苛刻。你想想看，FPS游戏里，你开一枪，服务器要在几十毫秒内把结果同步给所有玩家。如果延迟超过100ms，玩家就会觉得「这游戏怎么这么飘」。
但游戏系统也是软实时的——偶尔延迟高一点，玩家骂两句，游戏不会崩溃。服务器端通常采用帧同步或状态同步两种策略：
- 帧同步：所有客户端在同一帧执行相同操作，延迟敏感，但作弊难
- 状态同步：服务器定期广播状态，客户端插值渲染，延迟容忍度高
我个人更倾向于状态同步，尤其是在移动端网络不稳定的场景下。帧同步一旦有人掉线，整个游戏都得等他，体验反而更差。
3. 语音通信
微信语音、Zoom会议、VoIP电话，这些都是软实时系统的典型代表。语音的实时性要求比视频低一些，但也不能太离谱。一般来说，端到端延迟在150ms以内，用户基本感觉不到；超过300ms，对话就开始有「对讲机效应」了。
语音系统里有个经典问题：丢包补偿。网络丢包了怎么办？
- 简单粗暴：静音。但听起来像「断断续续」
- 聪明一点：PLC（Packet Loss Concealment）。用上一帧的数据预测当前帧，填充丢失的部分
我做过一个VoIP网关的项目，刚开始用的静音策略，客户反馈「你们这产品说话像卡碟」。后来换成了G.711标准的PLC算法，效果立竿见影。说白了，软实时系统的精髓就在于——出了问题，怎么补救。
软实时系统的知识体系
下面这张图，是我自己总结的软实时系统核心逻辑。你看一眼就能明白：
你看，软实时系统的核心就三件事：定义、后果、场景。定义决定了你怎么设计，后果决定了你怎么容错，场景决定了你用什么策略。
注意：别以为软实时系统「软」就可以随便设计。我见过太多项目，一开始觉得「反正超时也没事」，结果上线后用户骂声一片。软实时系统的难点在于——你要在「性能下降」和「用户体验」之间找到平衡点。这个平衡点，往往需要大量的实测数据来校准。
好了，软实时系统的基本概念就聊到这。下一节我们会深入硬实时系统，看看那边又是另一番天地。