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

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

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

设备多久给服务器发送一次位置信息呢？以哪些方式发送？发送后，服务器端如何接收和更新到用户端呢？

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

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

虽然我们可以依据设备的使用场景来优化这个问题的解决方案，由设备自带的振动监测器来分辨该设备是运动还是静止状态，进一步来判定设备是否须要上传位置信息。如设备已然是静止状态了，那就不须要上传位置了，由于当设备静止时侯，理论上仍然是一个点（假如没有经经度误差和定位的不精确等影响诱因），所以重复向服务器发送同一个位置是没有意义的。

这么我们接出来剖析两个主要的功能实现方法。

实时定位须要时效性。轨迹查询在于存贮。

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

想想我们之前的实现方式：服务器接受设备位置信息，储存上去。之后设备端从数据库中查询出最新的一条数据。

insert—selecttop(1)

这样的数据抒发，你们应当很清楚实现方法了吧？

这么如今换一个实现方法：

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

为何用redis呢？

由于这是一个KEY-VALUE的设计，查询速率更快，并且数据保存在显存中。显存中的查询，肯定也要比硬碟查询快。

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

hsetkeyvalue的方式来设置进去。

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

简单吧？

关于reids查看这儿

redis英文官网

redis的安装布署和使用也比较简单。推荐看这本书

学习下基本上就晓得如何操作使用了

我们做的方法是，用设备ID号生成KEY.设备的位置信息，电量信息等数据作为值。查询时侯按照ID找到KEY。之后按照KEY找到对应的通配符。

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

其实，要建立它还要考虑好多的细节问题

1.redis默认端口的更改，严禁非指定的链接，redis安全设置

2.redis数据保存在显存中。服务器开关机断电的应急处理。

3.redis集群处理。

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

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

怎样实现历史轨迹的查询？

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

由于初期数据都是直接进数据库，后期无论是查询最新的位置手机定位服务器，还是查询轨迹都是来自于数据库，所以不存在这个问题。如今根据我们的处理方法，最新位置直接步入了redis，没有储存出来，这么历史轨迹如何办？

下一篇文章中来探讨我们在处理历史轨迹时侯的解决方案，不觉得做法一定是对的，只是和你们一齐阐述。

2016年11月20日18:22:35

witch_soya