前端在基于 Google Map 的地图应用上渲染数据时一般以 tile 为单位请求数据。简单来说，屏幕上可见的地图区域是由多个 tile 拼接而成的，数据渲染以 tile 为单位，数据请求也以 tile 为单位。
这样，前端只需要绘制可见的几个 tile ，以及预绘制边缘的几个 tile，而不是一次绘制，绘制一张大图，也就是整个世界地图。既然是基于地图的应用，那么应用数据往往与地理位置相关，Google Map 的按 tile 来绘制给叠加在基础地图之上的应用数据的绘制也提供了可行的参考: 按 tile 来请求可见区域数据以及预请求少量边缘位置数据，以 tile 为单位进行数据渲染。
参考: https://medium.com/google-design/google-maps-cb0326d165f5
tile 的多少与 zoom level 相关，zoom level 可以理解为地图的缩放等级，缩放等级约高，地图被切割的 tile 数就越多，而缩放等级为 0 时，整个世界地图就为一个 tile。
我们假设基于 tile 的应用数据请求接口为 /p。通常情况下，一个屏幕显示区域内大约有 30 个 tile，边缘部分大约 20 个 tile，那么一个屏幕总的就大约有 50 ~ 60 个 tile，这意味着用户第一次打开或刷新页面时最多可能有 60 个 /p 请求，而用户使用鼠标拖拽地图时，得益于预加载机制，此时大约只有 20 ~ 30 个 /p 请求，前提是用户拖拽的幅度较小，如果幅度很大，那么请求数量也将接近 60。
从上面的介绍我们可以知道，/p 接口的用户并发未必很高，但单个用户的并发请求量是摆在眼前的， 其响应时间(RT)对用户将会非常敏感，如何不断优化该接口，降低 RT 成了我们必须克服的难题。
欢迎关注我的公众号，文章将同步进行推送，快去关注吧。
