阅读 31

大规模手机定位采集系统设计

一、业务场景分析

基本的业务需求可分为两大部分,第一部分是手机端间隔一定时间上报一次位置信息,第二部分是后台系统可以实时看看手机设备当前所在的位置,并绘制轨迹。

总之就是用户安装了此应用,就相当于给自己装上了一个跟踪器,所到之处,都将有所记录。

我们先来保守计算一组数据,假定用户基数为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缓冲池示意图

上图中的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级别的数据。如果一旦出现了这种情况,可以限制时间区段,比如只能获取两天内的数据。

五、总结

本文详细阐述了手机定位采集系统的设计,整个系统的复杂性集中在了数据的存储和呈现,我在此文中都给出了相应的解决方案。除此之外,整个采集系统还会有其他的功能模块,诸如日志采集与分析,实时监控等,限于篇幅,不再逐一叙述了。

以下是扩展阅读,对于理解整个系统会有所帮助,建议阅读之。

1、细说双Buffer缓冲池

2、物联网设备网关系统架构设计

扫描下方二维码,进入原创干货,搞“技”圣地。

技术汇

关注下面的标签,发现更多相似文章
评论