云巴:基于 MQTT 协议的实时通信编程模型
概要
有人常问,云巴实时通信系统到底提供了一种怎样的服务,与其他提供推送或 IM 服务的厂商有何本质区别。其实,从技术角度分析,云巴与其它同类厂商都是面向开发者的通信服务,宏观的编程模型都是大同小异,真正差异则聚焦于产品定位,业务模式,基础技术水平等诸多细节上。本文暂不讨论具体产品形态上的差异,着重从技术角度浅谈实时通信的编程模型。
什么是实时通信
「实时」(realtime) 一词在语义层面上隐含着对时间的约束(real-time constraint),在工程上,我们习惯对「需要在一定时间内」 完成的操作称为「实时操作」。通常,实时可细分为 「软实时」(soft realtime),「准实时」(firm realtime)和 「硬实时」(hard realtime)。它们之间的差异,简单来说,就是对无法在指定时间区间内(deadline)完成事务的容忍程度。维基百科上对这三者有如下解释:
- Hard – missing a deadline is a total system failure.
- Firm – infrequent deadline misses are tolerable, but may degrade -the system’s quality of service. The usefulness of a result is zero after its deadline.
- Soft – the usefulness of a result degrades after its deadline, thereby degrading the system’s quality of service.
假如我们把无法按时完成任务(missing a deadline)称为异常事件,那么硬实时系统无法容忍异常事件;准实时系统则可容忍极少量的异常事件,但超过一定数量后系统可用性为 0;软实时系统可容忍异常事件,但是每发生一次异常事件,系统可用性降低。
综上所述,我们可以举例:
火星上的无人探测器是硬实时系统,因为一次异常事件就极有可能导致探测器不可用,同理可类推核电站的监控系统,军用无人机系统,远程导弹的导航系统等一系列军工产品&#