《智能家居产品 从设计到运营》——2.4 智能设备的数据同步

本节书摘来异步社区《智能家居产品 从设计到运营》一书中的第2章,第2.4节,作者:邢袖迪,更多章节内容可以访问云栖社区“异步社区”公众号查看

2.4 智能设备的数据同步

在信息时代,人们不再受空间的限制,可以*地进行信息的交换和共享,这便造成了数据同步的问题。对于基于网络的服务来说,数据同步始终是一项重要的工作,而且在物联网时代,数据同步将面临更大的挑战。

在人们熟悉的互联网服务和移动互联网服务中,离不开数据同步的问题。例如,在线购票时,如何确保剩余票数的实时展示,如何应对交易流程中出现的异常。再如,和好友聊天时,“对方正在输入”这种实时的提示是如何实现的。当然,随着网络技术的发展,这些问题都有了很好的解决方案。

《智能家居产品 从设计到运营》——2.4 智能设备的数据同步

但在物联网时代,随着连网能力的普及,设备之间的数据同步面临着更加复杂的环境。不像智能手机有着一套较为完整的体系,智能产品从形态到技术都有较大的差异,更有可能使用着不同的网络通信协议。此外,还需要考虑到某些设备的低功耗特性。下面对数据同步的实例和协议的介绍,将有助于理解同步问题的难点。

a.经典实例:两军问题
提到数据同步的问题,两军问题(Two Generals' Problem)是计算机网络中一个经典的例子。如图2-9所示,红方A1和A2两个军团分别驻扎在两个山头上,而山谷之间是蓝方的B军团。如果A1或者A2单独进攻B军团,将会失败,但如果同时进攻,就会胜利。所以红方两个军团对进攻时间的掌控,就变得至关
重要。

《智能家居产品 从设计到运营》——2.4 智能设备的数据同步

为了达成协议,A1派出了通信兵,且在通过山谷的时候没有被B军抓获,成功地把消息送给了A2:明早9点向B军发起进攻。虽然此时A2知道了进攻的消息,但此时A1不确定这个消息已经顺利地通知到了A2,所以通信兵需要再赶回A1。于是,他又一次成功地通过了山谷,把通知到A2的消息告诉了A1。但此时,A2并不确定通信兵已经顺利地回到了A1。于是,A1和A2两军陷入了不断确认的死循环中,无法做到百分之百的确定。这个故事主要说明了在一个不可靠的网络中进行通信的缺点,也证明了世界上并不存在绝对可靠的通信
协议。

b.三次握手协议
就像上面例子中的A1和A2的通信,设备间在传输数据前,需要通信双方先达成一个协议,也就是握手技术。其中,最为著名的是三次握手协议(Three times handshake),如图2-10所示,设备A和设备B通过三次握手,达成了传输数据的协议。

第一次握手
建立连接时,设备A向设备B发送SYN包(Synchronize Sequence Numbers,即同步序列编号),其中seq=x,并进入SYN_SENT状态,等待设备B确认。

第二次握手
设备B收到SYN包,给出确认ACK=x+1;并发送自己的SYN包(seq=y),同时进入SYN_RECV状态。

《智能家居产品 从设计到运营》——2.4 智能设备的数据同步

第三次握手
设备A收到SYN包,给出确认ACK=y+1;然后两个设备都进入ESTABLISHED状态,表示连接成功。

完成三次握手后,设备A和设备B便成功建立了连接,并开始传输数据。当然这也不能做到理论上的绝对可靠,但却是一种普遍使用的协议。

对于智能家居来讲,数据同步问题体现在很多方面,如设备状态的查看、产品之间的联动、手机对设备的控制等。而同时需要考虑的因素有:产品的功耗问题、网络通信协议的传输速率、数据的准确率等。通常,需要在多种因素中做出取舍,以保证产品整体体验上的最优。例如,如果想更准确地知道某设备的状态,则需要与其进行更频繁的通信,但这也将影响到该设备的功耗,特别是不通电的无线设备。这时,便需要在准确度和功耗之间做出权衡。

上一篇:python设计模式(十三):解释器模式


下一篇:SmartNews:基于 Flink 加速 Hive 日表生产的实践