1.    方案整体描述

1.1存储

　　a.使用redis存储当天所有人员的轨迹，在当天深夜进行redis中轨迹迁移。

　　b.轨迹存储分为轨迹日志文件和历史轨迹表两部分。

　　c.日志文件的存储规则为每天以日期命名新建一个文件夹，文件夹中分别建立以人员ID命名的存放该人员当天所有轨迹的文件。

　　d.手机端每一次数据批量上传时，修改监督员状态表中的实时轨迹数据。

1.2迁移

       a.redis中的数据每晚进行同步至日志文件和轨迹表中的步骤，然后清空。

       b.轨迹日志文件定期迁移（建议三个月）。

       c.历史轨迹表定期备份迁移。

1.3采集

       手机端GPS采集上，通过对监督员运动场景分析调控GPS采集频率，减少冗余、无效GPS点，已在重庆多个项目中验证可以减少40%（或更多）的GPS数据量。  

1.4读取

       a.读取当天轨迹时，在redis中获取。

       b.读取历史轨迹时，在轨迹日志文件中获取。

2.核心性能点测试

2.1Redis缓存一天轨迹点性能测试

       假设1000个监督员，每隔10S上报一个GPS点，一天工作8小时，那么一天有2880个GPS点，这里，我们用整数2000个点来表示。那么一天所有人员将产生200W个GPS数据。

       根据真实项目中的考察，杭州一天大概是150W个GPS点，宁波一天大概是100W个GPS点。所以，我们测试的200W个GPS点是可以涵盖绝大部分项目场景的。

现在，我们测试如果存储一天的所有轨迹（200W个），轨迹信息只包含人员ID、X、Y、time，一共将占用多少内存空间。

       实验测得，一共占用了233M的内存空间。针对现在的服务器内存空间，是可以接受的。

2.2Redis数据迁移至文本中的IO测试

       这里，将Redis中的数据分别迁移至1000个人员对应的各种轨迹日志中所需的时间进行了测试：

       单线程写入1000个日志文件只耗时37S。1000个日志文件（200W个GPS点）所占用的存储空间是109M。

       针对这个测试，数据转移至文件是没有IO瓶颈的，轨迹日志文件一个月大概占用3G存储空间，三个月是9G，可以接受。

2.3实验总结

       Redis存储一天所有轨迹数据，轨迹数据写入轨迹日志，均没有明显的性能和存储瓶颈，是可以采用的。

       并且以上我们采用的是200W个轨迹点做的测试，如果将GPS采集优化利用上，GPS数据量可以减少至100W个，那么以上所有测试效果会更好。 而目前轨迹量最大的杭州项目，利用GPS采集优化，150W的轨迹量也可以减少至100W个以下。

　　　　　　　　　　　　　　　　　　　　　　　　-----欢迎转载，但保留版权，请于明显处标明出处：http://www.cnblogs.com/naaoveGIS/

                                                                      　　　　  如果您觉得本文确实帮助了您，可以微信扫一扫，进行小额的打赏和鼓励，谢谢 ^_^