实时地理围栏为什么会把机器压垮：Tile38 里对象类型、查询方式与回调各自吃什么资源

上线两周机器先撑不住：问题不在点位数量这一个数字上

一个车队管理平台上线才两周，机器先撑不住了。运维把监控翻了个遍，点位数量其实并不算多——几千辆车，加上若干外接的配送与外勤终端，离"海量"两个字还很远。可 CPU 长期高位，内存曲线一路向上，磁盘写入量比预期高出一大截，告警从偶发变成常态。第一反应通常是加机器，加了之后确实缓了一阵，两周后又被打回原形。

这类现场反复出现，原因往往不在点位数量这一个数字上。同样是一万个移动点位的围栏判断，有的实现跑在很普通的机器上还留有余量，有的把配置翻上去仍然吃紧。差别来自三个被忽略的乘数：这些位置对象在存储里被存成了什么几何类型，业务每次用什么方式去查询它们，以及进出围栏的通知靠服务端推送还是客户端自己来问。三个乘数各自都不起眼，叠在一起才把机器压垮。再往下还有一层——高频率位置更新下，持久化的写入与日志重整会吃掉另一块资源，很多人是在磁盘先报警的时候才意识到它存在。

本文要做的不是给出一堆可以直接抄的数字，而是把这笔资源账的算式写清楚：每一项由什么决定、在什么条件下会失控、能用什么样的设计选择换回来。具体到某个版本的实现细节与参数默认值，需要以官方文档为准，并在自己的数据上做验证。

三个乘数加一层持久化：开销是怎么被乘出来的

把实时位置服务想象成一条流水线，会更容易看清开销的结构。位置数据进入系统时被写成某种几何对象；这些对象被放进空间索引；业务侧发起查询，或者由服务端在对象跨越边界时主动通知；每一次更新同时要写进持久化日志。四个环节，每个环节都有一个可以放大或缩小代价的开关，四个开关的状态相乘，才是实际压在机器上的负载。

点位数在这条流水线里的位置，只是"第一环节的条目数量"。它决定索引里有多少条记录、日志里每秒追加多少条记录，但它决定不了单条记录有多重、单次查询走多长的路径、通知要不要服务端算。一万条轻记录和一万条重记录，压在机器上的东西完全不同；一万次廉价查询和一万次带排序带过滤的查询，也不是同一件事。

这也是为什么"点位数不多却撑不住"并不矛盾。当对象被存成复杂几何、查询每次都带排序与字段过滤、通知靠客户端高频轮询、更新频率又推着日志快速增长时，四个开关同时打开，机器上的负载是四个放大效应叠加的结果。反过来，把其中两个开关关掉，同样的点位数可能连一半资源都用不到。

乘数一：对象存成什么几何类型，决定了一条索引记录有多重

Tile38 这类地理空间数据存储里，一个"位置"并不默认就是一个经纬度点。它可以是点，也可以是边界框、多边形与多部件几何、几何集合，还可以用字符串表达的网格编码来表示一个范围。这个选择直接决定了两件事：这条记录在索引里占多少内存，以及它参与一次判断时要走多远。

点是最轻的形态。一个移动中的车辆、一个外勤人员的手机，绝大多数时候只需要一个经纬度坐标，索引里存的就是一个坐标对，判断"这个点是否落在某个围栏内"的路径也最短。把点存成多边形是常见的一种浪费：有人为了让对象"看起来更像一个区域"，给移动目标套了一个矩形或多边形外壳，结果每条记录都要带着一串顶点进索引，内存占用和判断开销同时上去，而业务上并没有因此多得到任何信息。

复杂几何在围栏侧是必要的。门店周边到店判断、园区越界告警、配送区域划分，边界本身就不是一个圆能说清的：一块形状不规则的园区，一条沿着河道走的配送分区，都可能要用几十上百个顶点去描述。顶点数越多，判断一个点是否落在其中需要走的几何计算越多，索引里维护这个对象的成本也越高。多部件几何更麻烦——一个"配送范围"由若干互不相连的片区组成，判断时必须逐个部件走一遍，代价是部件数量的函数，而不是"一个围栏"这么一句话。

几何集合把复杂度又抬一层：一个对象里同时装着点、线、面，任何一次涉及它的判断都要先分派到不同几何类型上分别处理。这类表达在"一个对象既要表达当前位置又要表达所属片区"的场景里很诱人，代价是每次查询都要多做一次分派，索引维护也更重。

网格编码（Geohash、QuadKey 这类用字符串表达范围的方式）处在另一个位置。它把一个二维范围压成一个字符串前缀问题，好处是粗筛极快——判断两个对象是否可能相关，很多时候比较字符串前缀就够了，不需要碰真正的几何数据。代价是精度被网格的层级锁死，网格边界上的对象可能被划到相邻格子，做精确判断时仍要回到几何本身。所以网格编码通常不是替代几何，而是垫在几何前面的一层筛子。

乘数二：包含、相交与最近邻不是一条计算路径，排序和过滤也要算进去

第二个乘数是查询方式。"这个点在某个范围内"、"这个对象与某个区域相交"、"按距离取最近的若干个"，听起来都是空间查询，实际走的计算路径差别很大，代价也各不一样。

包含判断是点对象最常走的路径：给定一个区域，判断点是否落在里面。计算量主要取决于区域的几何复杂度，与区域内有多少其他点关系不大——索引把候选缩到很小的范围之后，真正要做的几何判断次数是有限的。这也是为什么点加包含判断通常是最省的组合。

相交判断要贵一些。它不只判断"在不在里面"，还要判断两个几何有没有公共部分：一个多边形围栏与另一个多边形范围是否叠上，一个移动对象的活动范围是否蹭到了禁行区。候选集的筛选可以用索引做粗筛，但粗筛之后的精确判断涉及边与边的求交，代价随两个几何的顶点数上升。围栏形状简单时它和包含判断差不多，围栏复杂时差距就会拉开。

按距离取最近的若干个是第三种路径，也是最容易被低估的一种。它天然要排序：不是"是或否"的判断，而是要在候选里维护一个有序集合，把距离最近的若干个挑出来。候选越多、要取的个数越多，排序的代价越高。更关键的是，这类查询的代价与数据密度直接相关——同一个查询在城市中心与在郊区，需要比较的候选数量可以差出很多倍，这就是为什么"最近门店"这类功能在点位密集区域会突然变慢。

在这三种基本路径之上，还有两个附加项经常被漏算。一个是字段过滤：按车辆状态、按司机是否接单、按设备是否在线做过滤，过滤发生的时机很关键——能在索引筛选阶段就生效的过滤会大幅缩小候选集，只能拿到结果之后再做的过滤则白白算了一遍。另一个是返回字段的多少：只返回一个标识，和返回完整对象带一堆业务字段，序列化与网络传输的开销不是一回事，在高频查询下这部分会变得显眼。

把这两项算进去之后，常见的现象就有了解释：同样是"查一次"，一个带排序、带后过滤、返回全字段的最近邻查询，和一个只做包含判断返回标识的查询，代价可以差出一个量级。容量估算时按"每次查询"记一个平均价，往往会低估最贵的那类查询在峰值时的实际占用。

在给这类负载做服务器配置参考时，一万网络在整合自营节点与 BGP 多线资源过程中更关注的通常是内存容量与磁盘的写入模式，而不只是核数——因为空间索引常驻内存、日志持续追加，这两处的压力点比 CPU 更早出现。

乘数三：围栏通知是服务端推还是客户端拉，成本落在不同的机器上

第三个乘数是通知方式。围栏这件事的终点不是"算出来"，而是"该知道的人知道"。两种做法：由服务端在对象进出围栏时主动回调，或者由客户端定时来问。它们把成本放在了完全不同的地方。

服务端回调的做法，是把判断集中在一处。对象每次更新时，服务端顺带检查它相对围栏的状态，状态发生变化就触发一次回调通知下游。好处非常直接：没有发生进出事件的时候，不会产生任何多余查询，查询次数与事件数量挂钩，而不是与点位数和轮询频率挂钩。对于围栏事件稀疏的业务——车辆一天进出配送区几次、外勤人员进出打卡区域几次——这一项能省掉绝大部分无用功。

代价是服务端要承担推送这一侧的压力：下游接收端慢了怎么办、回调失败要不要重试、短时间内大量对象同时跨边界时推送并发会冲到多高。这些都要在容量表里单独列一行，它不再是"查询并发"，而是"推送并发"，两者的形态不同——推送往往是尖峰式的，一批车辆同时进入一个区域时，事件会在很短的窗口里挤在一起。

客户端轮询则相反。它实现简单，语义可控，客户端想问什么就问什么，服务端只负责回答，不需要维护回调地址与重试状态，出问题时降级也容易——少问几次就行。代价写在一条很直白的乘法里：单位时间内的查询次数约等于点位数量乘轮询频率。点位数翻倍或者把轮询间隔缩短一半，查询量就翻倍。而其中绝大多数查询的答案是"没变化"，这些查询消耗了完整的查询路径，却没有产出任何业务价值。

这个乘数还牵扯到业务对延迟的要求。轮询的感知延迟天然受间隔限制，想把"越界告警"做得及时，就得缩短间隔，查询量随之线性上升；要的是分钟级判断的场景，用轮询反而更省心。反过来，对延迟敏感又事件稀疏的场景，服务端回调几乎是唯一合理的选择。

第四层开销：高频更新下的日志追加、增长与重整

前三个乘数说的是计算与查询，第四层说的是写入。内存型的空间数据方案把位置对象常驻内存换取低延迟，代价是每一次更新都必须想办法落盘，否则一次重启就什么都没了。常见的做法是追加式日志：把每次更新按顺序追加到磁盘上的日志文件里，重启时重放恢复。

追加式日志的好处是写入模式简单、顺序、不需要随机寻址，但它有一个容易被忽略的性质：写入量与更新次数成正比，而不是与数据量成正比。一万辆车每秒上报一次，和一万辆车每三十秒上报一次，索引里的数据量一样，磁盘上每秒追加的量却差了几十倍。位置更新频率越高，写入与索引重建的开销越大——索引这一侧要不断调整对象在空间结构里的位置，磁盘这一侧要不断追加记录。

日志不会只增长。当它累积到一定规模，系统需要对它做重整（重写或压缩），把同一对象的多次更新合并成当前状态，让文件回到一个合理体积。这一步是高频更新场景的第二个瓶颈：重整过程要读旧日志、写新日志，在切换的瞬间可能同时存在两份文件，于是磁盘空间需要留出余量，重整期间还会有额外的 CPU 与 I/O 占用。如果磁盘容量只算了"数据量"，没算"日志增长加重整期间的峰值占用"，那么先报警的往往是磁盘而不是内存。

主从复制在这里也是一笔账。副本节点要跟上主节点的更新流，更新频率越高，复制链路上的数据量越大；网络抖动或副本落后时，还可能出现积压。把复制考虑进来之后，持久化这一层就不只是本地磁盘的问题，还包括节点之间的链路。

围栏多与点位多，撞的不是同一面墙

围栏数量与点位数量是两个独立维度，混在一起谈"规模"会看错瓶颈。它们的受力方向不同，撞的也不是同一面墙。

围栏多而点位少时，瓶颈在单次更新要判断的围栏数量。每一次位置更新，服务端都要回答"这个点相对哪些围栏的状态变了"，围栏越多，这个回答要检查的候选越多。这类系统的表现是：点位不多，索引也不大，但每次更新的处理时间偏高，更新吞吐上不去。车队平台给每家客户配了几十个自定义区域、共享设备给每台设备配了进出禁行区与运营区多套规则，都属于这一类。

点位多而围栏少时，瓶颈换到了索引内存与写入。围栏只有几个，单次判断很便宜，但大量对象要常驻内存，每条更新都要改索引、追加日志。这类系统的表现是：查询很快，但内存曲线贴着上限走，磁盘写入持续高位，日志重整频繁触发。大规模的轨迹采集、全城级别的到店判断属于这一类。

两个维度都大的情况当然存在，那时要分开算各自的账，再叠加。实际的容量估算最怕的是把两个维度乘成一个"总规模"数字，然后用一条经验曲线去套——这样既看不出瓶颈在哪一侧，也选不对优化动作。

分层围栏：先用粗粒度网格筛掉绝大多数无关点位

针对"围栏多"这一侧的降载思路，业界常见的做法是分层：先用粗粒度网格做筛选，再对通过筛选的少量对象做精确几何判断。网格可以用前面提到的字符串编码来表达，判断两个对象是否可能相关时，很多时候比较编码前缀就够了，不需要碰真正的几何数据。

这一层为什么有效？在绝大多数位置更新里，一个对象真正可能跨越的围栏只是全部围栏中极小的一部分——一辆在城东跑的车，与城西那几百个围栏毫无关系。如果每次更新都要把全部围栏过一遍，其中绝大多数判断是注定为假的。粗筛把这部分注定为假的判断用一次廉价的前缀比较就打发掉，精确判断只在少数候选上进行，单次更新的平均代价因此大幅下降。

分层不是没有代价。它多了一层结构要维护：网格层级选多粗、对象跨格时挂在哪个格上、围栏跨格时要登记到哪些格上，这些都要在写入路径上额外处理。边界情况也需要照顾——对象恰好停在网格边界附近时，如果只登记一个格子，就可能漏掉相邻格子里的围栏；常见的处理是让围栏在重叠的格子上重复登记，用一点冗余换正确性。此外，判断的精度最终仍由精确几何那一层决定，粗筛只负责"不可能相关"的快速排除，不承担精度责任。

所以在容量表里，分层是一个明确的交换：用写入路径上的一点额外复杂度和一点索引冗余，换掉每次更新时大量的无效几何判断。围栏数量越多、几何越复杂，这个交换越划算；围栏很少且形状简单时，直接判断反而更省事。

本文只讨论实时位置服务的空间查询与资源账，不涉及地图渲染与前端接入

需要说清边界：本文谈的是服务端那一侧的事——对象怎么存、查询怎么走、通知怎么发、更新怎么落盘。地图渲染与前端接入不在讨论范围内，前端用什么库、瓦片怎么加载、移动端如何采集定位，都属于另一条链路，有自己的一套资源账，不该和这里的四个乘数混在一起算。同样，本文也不涉及账单分摊与虚拟化层的资源切分，那些是同一批机器上其他层面的问题。

把三个乘数换算成资源：六步估算顺序

把算式写清楚之后，容量估算可以变成一件有步骤的事。下面六步不涉及任何具体数字，因为每一步的答案都依赖业务本身的形态，照抄别人的数字没有意义。

第一步：清点对象类型与几何规模。逐个列出要存进索引的东西：移动目标是点还是别的，围栏是多边形还是边界框，平均顶点数是多少，有没有多部件或几何集合。这一步的输出不是"有多少条对象"，而是"平均一条有多重"。

第二步：列出所有查询形态及其调用来源。包含判断、相交判断、最近邻各占多少，哪些带排序，哪些带字段过滤，过滤发生在索引阶段还是结果阶段，返回字段有多少。把最贵的那一类单独标出来，容量要按最贵的那类在峰值时的表现来留余量，而不是按平均值。

第三步：明确通知方式并分别估算两端。用服务端回调的，估算事件的发生密度与尖峰形态，以及下游接收端的处理能力；用客户端轮询的，用点位数量乘轮询频率算出查询次数，并确认这些查询里有多少是注定无变化的。混合方案要分别算两段的账。

第四步：按更新频率折算写入量。把"每秒多少次更新"换算成每秒追加多少日志，再看日志增长到多大规模会触发重整、重整期间需要多少额外磁盘、瞬时占用有多高。这一步的输出应该是一个磁盘容量下限，而它通常比按数据量算出来的大。

第五步：把围栏数与点位数分开看。判断业务落在哪一侧：围栏多而点位少，则优化单次更新的判断次数，考虑分层；点位多而围栏少，则优化索引内存与写入，考虑上报节流与数据分片。两侧都吃紧时，两笔账都要留。

第六步：用自己的数据验证，而不是套用经验值。不同版本的实现细节、索引结构、默认参数都可能不同，官方文档给出的说明与自身的实测才是依据。前面五步的作用是告诉你该测什么、该看哪条曲线，而不是替你填数字。

关于点位规模、围栏成本与持久化的七个疑问

一万个点位到底算不算多？脱离对象类型与查询方式谈数量没有意义。一万个经纬度点，做包含判断、事件驱动通知、每秒更新一次，和同样一万个点但存成复杂几何、每次都做带排序的最近邻查询、客户端高频轮询，压在机器上的负载不是同一量级。真正要回答的问题是"平均一条有多重、一次查询走多远、一次更新要判断几个围栏"。

多边形围栏为什么比简单的圆形范围贵？圆形或规则形状的范围，判断可以走很短的路径；多边形要走顶点与边的几何计算，顶点越多代价越高。如果围栏还是多部件几何，判断要逐个部件走一遍。这并不意味着不能用多边形——不规则园区和沿河的配送分区确实需要它——而是说这类围栏的代价要单独计入，并且值得考虑顶点抽稀或把大围栏拆成几个简单的小围栏。

服务端回调和客户端轮询该怎么选？看事件密度与延迟要求。围栏事件稀疏、又要求告警及时的场景，服务端回调更合适：查询量与事件量挂钩，省掉大量无谓查询，代价是要承担推送并发、失败重试与下游慢的处理。判断可以接受分钟级、点位规模不大、希望实现简单且易降级的场景，轮询更省心。两者也可以混合：回调负责告警，轮询负责兜底校准。

位置更新频率到多高才需要考虑持久化的影响？判据不是某个具体频率，而是两个比值：一是每秒追加的日志量是否已经接近磁盘的持续写入能力，二是日志从重整完成到下一次重整的间隔是否已经短到让重整变成常态。当这两个比值开始变坏，说明写入频率已经越过了当前配置的舒适区。此时的应对不一定是换机器，先看业务是否真的需要这么高的上报精度——多数轨迹判断对秒级以下的更新并不敏感。

围栏数量和点位数量，哪个会先成为瓶颈？取决于业务的形状。围栏多而点位少时，先出问题的是每次更新的判断次数，表现为更新吞吐上不去、CPU 偏高；点位多而围栏少时，先出问题的是索引内存与写入，表现为内存贴上限、磁盘写入高位、日志重整频繁。把两个维度分开看，才能知道该动哪一项。

需要保留历史轨迹时该怎么办？热数据和历史数据应该分开。空间索引里只保留当前状态，历史轨迹落到适合按时间顺序存储的地方，按时间分片、设保留期、必要时做抽稀。若把几个月的历史点全部塞进常驻内存的索引，内存与写入都会被历史数据拖住，而这些数据在实时围栏判断里根本用不上。

什么情况下不适合用内存型的空间数据方案？几种情形值得重新考虑：数据总量远超可承受的内存容量，且访问没有明显的热点集中；判断可以接受分钟级甚至小时级延迟，用批处理更划算；业务需要强事务、复杂关联查询或大量非空间字段的检索，空间存储并非为此设计；成本约束很紧而延迟要求宽松时，把位置判断放进通用数据库的扩展能力里可能更合适。这些都是取舍，不是优劣判断。

围栏之外，移动位置系统的其他环节本文没有展开

一套移动位置系统远不止围栏判断这一块。定位上报的链路与移动端电量策略、轨迹的清洗与纠偏、历史数据的存储与回放、消息通道的可靠性与顺序、账号与权限、多机房之间的容灾切换、以及指标监控与告警体系，都能单独写一篇。本文刻意把范围收在空间查询与资源账这一处，那些环节的成本结构与这里讲的四个乘数不同，套用同一套估算方法容易算错。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。在为实时位置类负载配机器时，可把索引内存、写入频率与推送并发并入服务器租用与机柜托管的配置清单一起核。

回到 Tile38：把三个乘数写进容量表

回到最初那个撑不住的车队平台：它的点位数不多，但对象可能存得比必要的重，查询可能次次带排序带全字段，通知可能靠客户端高频轮询，而上报频率又把日志推得飞快。四个开关同时打开，加机器只是把曲线往后推，没有关掉任何一个开关。

对 Tile38 这类内存型空间数据存储做容量规划，可以把它落成一张表：对象类型与平均几何复杂度、每类查询的形态与峰值调用量、通知方式与两端并发、更新频率折算出的日志写入与重整预留。四行填完，瓶颈在哪一侧通常就清楚了。这张表里的数字必须来自官方文档的说明与自己的验证，不同版本的实现细节存在差异，别人跑出来的结果不能直接搬。