原创 胡杰 朱明 殷磊 道路交通管理杂志社 收录于合集 #科技前沿 11个

（三）数据同步

因为手机终端的使用场景比较复杂且不可控制，所以为了保证单个设备采集数据的准确性、完整性和及时性，需要针对不同的场景，使用多种数据上传同步策略。一是启动同步，分为冷启动、热启动两种情况。冷启动的情况下，先检查本地磁盘上是否有缓存未同步的数据，如果有就立即上传；热启动也是同样的同步策略，但是检查的是内存中未同步的数据。二是定时同步，即手机终端每隔一定的时间间隔同步一次（比如每隔30秒）。三是定量同步，即客户端本地已缓存的数据超过一定条数时同步数据 （比如100条）。四是即时同步，适用于对数据及时性要求比较高的数据类型，也用于防止特殊场景造成的数据丢失等，比如应用程序进入后台时尝试同步本地已缓存的所有数据，最大限度地保证数据的完整性。除了以上四种策略外，还有其他保障机制保证数据的完整性，比如失败重传，即对于偶发单次同步上传的数据失败情况，需要增加重传机制，把数据重新加入到待传队列之中。同时，为了节约服务端资源，避免同步大量无效数据到服务端，每个终端默认不传数据，由服务端下发指令控制终端设备的数据采集是否开启，同时服务端也可以控制采集数据阈值，对于某些类型的数据，触发阈值才会被记录。

（四）时间修正

在事件模型里，时间的准确性尤为重要，因为后续的数据分析和问题回溯都依赖于时间的准确性。最简单的方案就是把用户手机设备的时间戳作为事件发生时间，但有些用户手机设备是不准确的，从而导致系统采集到的时间不准确。另一种方案是使用服务端的时间戳作为事件发生的时间，但这个方案也不准确，因为事件信息记录后，并不会立即同步给服务端（比如每隔30秒定时同步），从而导致无法及时获取服务端的时间戳。经过一段时间的探索和测试，本文最终采用的是“时间修正”策略。如图5所示，用户在手机时间戳T1时触发了一个事件，本地缓存记录该事件数据。在用户手机时间戳T2时开始同步数据，然后服务端获取到数据时间戳T2。如果T2与当前服务端的时间戳T3的误差在一定的可接受范围之内（比如30秒以内，http网络请求也需要时间），就可以认为当前用户手机的时间戳是准确的，同时也认为事件发生的时间戳T1也是准确的，服务端在接收到事件信息时直接记录事件时间为T1，无需额外处理。但如果T2与T3相差比较大（比如图4中的T2为13:00:00，T3为14:00:00），则认定当前用户手机的时间戳T2是不准确的，即比服务端的时间戳晚了一个小时，从而就可以推断事件发生时的时间戳T1也比服务端晚了一个小时，即12:00:00变为13:00:00。因此，服务端在接收到事件信息时会将T1修正为13:00:00，从而就达到了“时间修正”的效果。

原标题：《科技前沿 | 面向“交管12123”App的客户端数据采集关键技术研究（下）》