文章版权由作者李晓晖和博客园共有，若转载请于明显处标明出处：http://www.cnblogs.com/naaoveGIS/
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/
如果您觉得本文确实帮助了您，可以微信扫一扫，进行小额的打赏和鼓励，谢谢 ^_^
