一、业务场景分析
基本的业务需求可分为两大部分，第一部分是手机端间隔一定时间上报一次位置信息，第二部分是后台系统可以实时看看手机设备当前所在的位置，并绘制轨迹。
总之就是用户安装了此应用，就相当于给自己装上了一个跟踪器，所到之处，都将有所记录。
我们先来保守计算一组数据，假定用户基数为10万，每隔5秒上报一次位置信息，而这5秒期间，地图SDK大概会给出2次定位数据，由此得出，一次上报的瞬时峰值大概是20万条数据，一天将会达到300多万的数据。
这样的QPS已经算是很高了，当然，绝大多数情况下是不会触顶的。
另外一方面，后台系统在查询的时候，也面临着一个巨大的挑战：如何从海量的数据中找寻符合条件的那一部分？
查询的条件无非是围绕三个维度展开的：时间、对象和区域。
类似“查询某块地理位置栅栏内的所有用户在一段时间内的位置信息”，这就是一个典型的查询业务需求，涵盖了三个维度的条件。
当然，还有一些距离的测算和排序的需求也是在所难免的。
综上所述，我们要解决两个难点：
1、上报用户的实时位置信息；
2、处理海量数据的读写请求。
以上两个难点是任何LBS应用不得不攻克的，这是支撑业务发展的关键点。
二、抽象的系统架构
我们可以将整个请求链接进行拆解，分别用对应的策略解决这部分的难题：
1、客户端收集数据。这一部分有四个基本要求：准实时，不丢数据，低功耗，高效率。
2、网关限流。主要为了避免涌入大量无效请求，消耗系统资源，拖跨服务器。
3、负载均衡。为了应对不断增长的访问量，服务实例必须支持横向扩展，多个实例之间按照一定的策略进行负载均衡。
4、异步化读写数据。需要借助中间件，起到削峰的作用，这一部分的设计会重点阐述。
5、数据存储层高可用。采集的数据不要求强一致性，依据CAP理论，满足AP两个条件即可。解决办法通常是集群化，避免单点故障，进而实现程序上的读写分离策略。
三、技术选型
接下来是针对上述五大部分在技术实现上的考量。
目前客户端是苹果机和安卓机，未来很可能会接入友商的车载OS。
在网络状况良好的时候，可以实时采集，实时上报，倘若网络状况不好，也不会丢数据，采用MMAP实现本地缓冲区。当然，为了上报效率，综合考虑还是按批次上传，过于频繁的上报也会致使耗电量攀升。
网关限流和负载均衡交给了nginx，学习和开发成本低，重要的是效果很好，并且能够达到服务横向扩展的目的。
我们使用了nginx基于ip地址的限流策略，同一个ip在1秒钟内最多允许3个请求，burst=5，为了应对突然的流量的爆发，还有一个nodelay参数，我们选择不加了，意味着请求队列和缓冲区都被塞满之后，直接返回503错误码，不再等待了。
目前，是1个master进程，5个worker子进程，此外，超时时间、最大连接数以及缓冲区的设置值得斟酌，服务器性能好的话，可以设置得高一些。负载均衡的策略不是基于权重的设置，而是使用的最少连接 (least_conn)，因为在我看来，每个服务实例都是可以被同等对待的，哪台空闲，就优先请求哪台。如果非要在此基础上设置一个weight，那就把性能高的服务器设置成较高的权重。
为了应对大量的位置上报请求，必然需要引入消息队列。因为技术团队一直在使用RabbitMQ，并且一番压测后，表现依然坚挺，所以成为了我们的不二选择。
此外，为了减轻存储层的压力，在数据落盘前有一个缓冲机制，是典型的主从双Buffer缓冲池，避免与存储层频繁交互，占用过多connection，提高了存储层的工作效率，但是缓冲池Flush的时候，会带来一次“IO尖刺”，可以调整缓冲池的Threshold，把“IO尖刺”控制在一个合理的范围内。
最后，也是最引人关注的是存储层的选型。我们面临的选择比较多，我们预研了4种有可能的方案：MySQL，Redis，PostGIS，MongoDB。
MySQL的方案有两条路可走，第一是使用纯SQL进行计算，很明显这条路子受限于数据量，随着数据量的增大，计算量剧增，系统性能急剧下降。第二是使用MySQL的Spatial Indexes，但是这类空间索引是MySQL5.7版本引入的，不巧的是，我们用的是阿里云RDS，MySQL版本是5.6.16，不得不放弃MySQL的方案。
基于Redis GeoHash的方案，在性能方面是没任何问题的，但是有一个重大的缺憾，就是非常受限于距离查询，而无法方便的匹配另外的附加属性，也就是上述三维需求（时间、对象、区域）中，只能满足区域查询的需求，若想进一步过滤，还需要借助其他的存储技术。
留下来的PostGIS和MongoDB是现在比较通用的解决方案。
PostGIS的专业性很高，是地图服务商的首选，对OGC的标准支持得非常全面，提供的函数库也十分丰富。当然，MongoDB也不赖，3.0版本引入的WiredTiger存储引擎，给MongoDB增色了不少，性能和并发控制都有了较大幅度的提升。
单就LBS应用来说，两者都可以很好的满足各方面的业务需求，性能也不是我们首要考虑的因素，因为两者的可扩展性都很强，不容易触及瓶颈。最后我们选择了MongoDB，是因为技术团队对此接受程度更高，MongoDB本来就是公司技术栈中的一员。PostGIS相对来说学习成本较高，因为Postgresql是一种关系型数据库，如果只接入普通的数据类型，其实相当于是维护了另一种MySQL，完全没必要，但是如果想用上GIS相关数据类型，现有的ORM框架支持得并不友好，开发效率低，维护成本高。
四、异步读写设计
出于对用户体验的考虑，不能因为读写速度慢让用户傻傻的等待，这类问题有一个通用的解决方案：异步化。
异步化的写请求很好实现，如前述所说，通过消息中间件来解决此问题，对于客户端的位置上报请求，不需要强一致性，能确定数据被塞入消息队列中即可。
除此之外，还在消息队列和存储层之间加入了双Buffer缓冲池，用以增加flush的效率。
上图中的Buffer-1和Buffer-2共同组成一个循环队列，每次只有一个Buffer用了缓冲数据。图中的Flush Point表示每个Buffer达到一定的阈值（Threshold）后，将会触发数据落盘，并且会在此刻切换Buffer。图中所示的阈值是50%，可以根据实际情况上下调整。
值得注意的是，在Flush Point，应该是先切换Buffer，再flush数据，也就是在flush的同时，还能接收上报的位置信息。如果要等待flush完毕再切换，将会导致流量过渡不平滑，出现一段时间的队列拥塞。
接下来要解决大量读请求，应对这种问题，有一个不二法门就是：拆。
非常类似“分表”的思想，但是在这个场景下，没有传统意义上“分表”所带来的诸多副作用。
“分表”有一个规则，比如按Hash(user_id)进行“横向分表”，按照常用字段进行“纵向分表”。受到Hadoop关于资源管理的启发，在此位置采集系统中，使用了“元数据”来代替分表规则，这里的“元数据”相当于NameNode，是管理数据的数据，将散落在不同位置的数据集中化管理。
如上图所示，按城市级别进行分库，每个城市的位置数据相对独立，体现在客户端的功能就是“切换城市”。“分表”意即分成多份Collection，以一天为最小粒度，因为一个城市的当天数据通常是“最热”的，众多查询请求都需要这份数据，分页，聚合，排序等需求都不是问题了，因此一天一个Collection是比较合理的切分。当然，如果一天的数据量过少，可以适当延长数据切分的周期。
那么，如果查询请求的时间段跨天了，该怎么办呢？
这时候，“元数据”就发挥威力了。
查询请求分为两部分，第一个是定位元数据，就是在meta data中找寻符合条件的所有Collection(s)，为了尽可能缩小查询范围，需要指定一定的时间区段，这个也是有现实意义的。所有的位置数据被分为了三种等级：Hot，Cold，Freeze，Hot等级通常是指当天的数据，读写最频繁的部分；Cold等级被界定为过去一个月内的数据，应对的各类查询和分析的需求；Freeze等级是已归档的数据，没有特殊情况不会被解冻。
通过时间区段拿到N个Collection(s)后，附加上其他的查询条件，循环N次，成功循环一次，就渲染一次获取到的数据，直到循环结束。
上述N>1的业务场景只可能出现在后台管理系统，也就是移动端不会出现跨天的业务需求，提供的API都是针对Hot级别的数据。如果一旦出现了这种情况，可以限制时间区段，比如只能获取两天内的数据。
五、总结
本文详细阐述了手机定位采集系统的设计，整个系统的复杂性集中在了数据的存储和呈现，我在此文中都给出了相应的解决方案。除此之外，整个采集系统还会有其他的功能模块，诸如日志采集与分析，实时监控等，限于篇幅，不再逐一叙述了。
以下是扩展阅读，对于理解整个系统会有所帮助，建议阅读之。
扫描下方二维码，进入原创干货，搞“技”圣地。
