在做定位产品中，需要解决的一个问题有几个。位置的时效性，准确性。

要实现时效性，那么设备端上传经纬度的时间间隔不能太久，如设备1分钟上传一个经纬度信息，这一分钟内如果车辆按照以一个极快的速度，如160KM/H，早就跑出了很远，所以这个时效性就无法满足需求。那1秒上传一个位置呢？这样又会加剧一个更复杂的问题，服务器需要处理更高频次的数据包（增大同时在线并发量），服务器需要对处理的结果进行更快的存储，更快的应答。随着设备数量的增加，服务器的压力会成倍上升。

那么我们需要面临和解决的问题是这样的：

设备多久给服务器发送一次位置信息呢？以什么形式发送？发送后，服务器端怎么接收和更新到用户端呢？

我们最早的设备，采用了比较原始的方法，不管三七二十一，10秒钟发送一次位置信息到服务器。这样在早期使用中是没有什么大问题的，只是要查看最新的位置信息需要等候10s.

那这个方案存在什么隐患呢？最大的问题就是冗余信息的重复传送。

其实我们可以根据设备的使用场景来优化这个问题的解决方案，由设备自带的震动检测器来区分该设备是运动还是静止状态，进一步来判断设备是否需要上传位置信息。如设备已经是静止状态了，那就不需要上传位置了，因为当设备静止时候，理论上一直是一个点（如果没有经纬度偏差和定位的不精确等影响因素），所以重复向服务器发送同一个位置是没有意义的。

那么我们接下来分析两个主要的功能实现方式。

实时定位需要时效性。轨迹查询在于存储。

那么时效性就决定了设备必须要在运动的状态下实时不间断的更新位置到服务器。而且，这个时间间隔的越短，在用户界面上的位置就更新的越快，用户体验度就越好。而这个时效性，其实只是要求获取设备最新获取到的一个位置。而大多数用户查看这个位置的时候，不会同时去要求这个轨迹。

想想我们之前的实现方法：服务器接受设备位置信息，存储起来。然后设备端从数据库中查询出最新的一条数据。
insert — select top(1)
这样的数据表达，大家应该很清楚实现方式了吧？

那么现在换一个实现方式：

1.用户比较关心实时信息，所以实时信息要求要更新快，那么就安排设备端在运动的状态下每隔5s乃至1s钟，发送一次位置信息到服务器。服务器获取到最新位置后，将设备位置信息存储到redis中。

为什么用redis呢？

因为这是一个KEY-VALUE的设计，查询速度更快，而且数据保存在内存中。内存中的查询，肯定也要比硬盘查询快。

使用时也很方便，有数据存储的时候。通过

hset key value 的形式来设置进去。

用户界面查看位置的时候，通过hget key 来获取到指定设备的位置。

简单吧 ？

关于reids 查看这里
redis中文官网
redis的安装部署和使用也比较简单。推荐看这本书

学习下基本上就知道怎么操作使用了

我们做的方式是，用设备ID号生成KEY .设备的位置信息，电量信息等数据作为值。查询时候根据ID找到KEY。然后根据KEY找到对应的键值。

这样，一个简单的实时定位系统就完成了。

当然，要完善它还要考虑很多的细节问题

1.redis 默认端口的修改，禁止非指定的链接，redis安全设置
2.redis数据保存在内存中。服务器开关机断电的应急处理。
3.redis集群处理。

这些就是后期处理的事宜了。

接下来还有一个刚性需求没有处理到。

如何实现历史轨迹的查询？

历史轨迹查询，其实也就是历史数据的存储。

因为早期数据都是直接进数据库，后期无论是查询最新的位置，还是查询轨迹都是来自于数据库，所以不存在这个问题。现在按照我们的处理方式，最新位置直接进入了redis，没有存储下来，那么历史轨迹怎么办？

下一篇文章中来阐述我们在处理历史轨迹时候的解决方案，不认为做法一定是对的，只是和大家一同探讨。

2016年11月20日18:22:35
witch_soya