一种基于Redis和PostgreSQL的瓦片地图服务集群系统和
方法
技术领域
[0001] 本
发明涉及地图服务技术领域，尤其涉及一种瓦片地图服务集群系统以及瓦片地图
请求的处理方法。
背景技术
[0002] 瓦片地图金字塔模型是一种多
分辨率层次模型，从瓦片金字塔的底层到顶层，分辨率越来越低，但表示的地理范围不变。首先确定地图服务平台所要提供的缩放级别的数量N，把缩放级别最高、地图比例尺最大的地图图片作为金字塔的底层，即第0层，并对其进行分
块，从地图图片的左上
角开始，从左至右、从上到下进行切割，分割成相同大小(比如256×256
像素)的正方形地图瓦片，形成第0层瓦片矩阵；在第0层地图图片的
基础上，按每2×2像素合成为一个像素的方法生成第1层地图图片，并对其进行分块，分割成与下一层相同大小的正方形地图瓦片，形成第1层瓦片矩阵；采用同样的方法生成第2层瓦片矩阵。如此下去，直到第N-1层，构成整个瓦片金字塔。
[0003] PostgreSQL是一种特性非常齐全的自由
软件的对象-关系型
数据库管理系统(ORDBMS)，是以加州大学计算机系开发的POSTGRES 4.2版本为基础的对象关系型
数据库管理系统。
[0004] Redi s(Remote Dictionary Server)是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。Redis的所有数据是放在内存中的，性能极高，读的速度是110000次/s,写的速度是81000次/s。支持丰富的数据类型，如string、list、hash、set、zset。
[0005] GeoWebCache(GWC)是一个采用Java实现用于缓存WMS(Web Map Service)瓦片的开源项目。当地图客户端请求一张新地图和瓦片时，Geowebcache
服务器拦截来自客户端的请求，判断本次请求的数据是否已经被缓存。如果请求数据已被缓存，则将这些缓存图片直接
渲染至客户端；如果请求数据没有被缓存，则发送请求至WMS Server(提供网络地图服务的服务器)，由服务器处理请求数据，并返回给GeoWebCache服务器，GeoWebcCache服务器经过渲染及缓存数据图片后绘制到客户端，从而提高地图展示的速度，实现更好的用户体验。
[0006] 在
附图1中，GeoWebCache机器上的圆柱体表示瓦片存储。理想情况下，大多数请求都是在不
访问WMS服务器的情况下从这个存储中响应的。因此，指向客户机的箭头要大得多，因为GeoWebCache每秒可以响应数百或数千个请求。
[0007] 可见，业内通常使用GeoWebCache作为缓存
中间件，使用场景存在如下问题。
[0008] 1.使用文件系统做元信息存储
[0009] 松散
包装。关系映射中没有ACID(
原子性，一致性，隔离性，持久性)操作，这意味着无法保证。考虑一种情况，手动或一些黑客删除文件后，你可能不知道该文件是否存在。
[0010] 安全性低。由于文件可以保存在您应该提供写入权限的文件夹中，因此很容易出现安全问题并引发麻烦，例如黑客攻击。如果无法在安全性方面做出妥协，最好避免保存在文件系统中。
[0011] 2.使用文件系统做瓦片缓存
[0012] 服务需要与
硬盘文件进行交互来获取瓦片，I/O速度慢，响应时间长，性能比较受制约，在安全性方面也存在上述问题。
[0013] 3.使用服务内存缓存图层元数据，服务启动过程中加载全部元数据信息[0014] 使用服务的内存缓存元数据，速度的确比较快，但是当服务重启之后，缓存会全部清空，启动从问价系统加载又非常耗时，图层多的情况下需要几十分钟之久。
[0015] 在集群部署的情况下，每个实例内存中都会保存一份元数据样本，非常消耗资源，且容易造成实例间的数据不一致，存在一定隐患。
发明内容
[0016] 本发明所要解决的技术问题是：提升预览时获取瓦片的速度，当客户端请求获取一张地图的瓦片时，本系统将拦截这些调用然后返回缓存过的瓦片。如果找不到缓存再调用服务器上的瓦片，并放入缓存中，从而提高地图展示的速度，实现更好的用户体验。
[0017] 提供可靠的地图元信息与瓦片的存储与缓存：使用PostgreSQL存储地图元信息，摒弃了使用文件系统存储的缺点，更安全、更易于操作、更方便维护。
[0018] 使用Redi s作为地图元信息和瓦片的缓存，不使用服务的内存或是文件系统做缓存，消除了服务内部状态，使本系统可以满足多实例部署的条件，提升了系统对请求的处理能
力，增强了系统的
稳定性。
[0019] 为了技术上述技术问题，本发明提出了一种基于Redis和PostgreSQL的瓦片地图服务集群系统，包括：
[0020] 远程字典服务Redi s、PostgreSQL数据库服务器；
[0021] 瓦片地图服务集群系统将地图元数据存储到PostgreSQL数据库服务器中；
[0022] 使用远程字典服务Redis做地图元数据和瓦片的缓存，请求过的瓦片也都会在Redis服务中保留一份副本。
[0023] 进一步的，使用远程字典服务Redis数据库服务器进行瓦片缓存，数据都在Redi s数据库服务器内存上；当客户端请求瓦片时，Redi s数据库服务器拦截来自客户端的请求，判断本次请求的数据是否已经被缓存；如果请求数据已被缓存，则将这些缓存图片直接渲染至客户端；
[0024] 如果请求数据没有被缓存，则由瓦片地图服务系统下游处理请求数据，获取瓦片数据并缓存至Redis，之后绘制到客户端，下次再访问同一瓦片直接通过Redis获取。
[0025] 进一步的，使用Redis存储图层元数据，使多个实例之间共享同一份图层元数据，保证数据的一致性；瓦片地图服务集群系统中不再包含图层元数据，在瓦片地图服务重启时也不影响业务处理速度,节约时间和空间；在瓦片地图服务启动过程中，不再预先加载所有图层元数据，仅在第一次使用时才进行缓存的创建，减少服务启动的等待时间。
[0026] 进一步的，使用PostgreSQL数据库做地图元信息的存储，实现瓦片地图发布功能，将地图元信息存储到PostgreSQL数据库中，不直接与文件系统做交互。
[0027] 瓦片地图服务集群系统提供瓦片地图服务，且瓦片地图服务中不含有业务数据，业务数据单独存放在PostgreSQL数据库和Redi s中。
[0028] 根据本发明的另一方面，提出一种基于Redis和PostgreSQL的瓦片地图服务集群系统的地图瓦片请求处理方法，包括如下步骤：
[0029] 步骤1、瓦片地图服务接收到客户端的瓦片请求，判断Redis中是否存在该瓦片所属地图的元数据是否存在；
[0030] 步骤2、若Redis中地图元数据存在，跳至步骤6。
[0031] 步骤3、若Redis中地图元数据不存在，查询PostgreSQL数据库中的地图元数据表；
[0032] 步骤4、若PostgreSQL中地图元数据存在，将元数据缓存至Redis中；
[0033] 步骤5、若PostgreSQL中地图元数据不存在，瓦片为空，返回响应信息，请求流程结束；
[0034] 步骤6、瓦片地图服务判断Redis中是否存在请求的瓦片缓存；
[0035] 步骤7、如果Redis中瓦片数据存在，跳至步骤9；否则调至步骤8；
[0036] 步骤8、如果Redis中瓦片数据不存在，根据地图元数据和请求参数，获取瓦片数据，并将瓦片数据缓存到Redis中；
[0037] 步骤9、服务将瓦片数据返回至客户端，请求流程结束。
[0038] 有益效果：
[0039] 本发明使用Redis做地图元数据和瓦片缓存。读写性能高，去除服务中的相关状态，保证了多实例服务中数据的在缓存层面的一致性，减少了业务
风险，更好的支持集群部署，不需要额外的配置，提升了用户体验。使用PostgreSQL做地图元信息的存储。提高了数据的共享性、一致性和完整性。更优的数据加载策略。启动时不加载地图元数据，仅在初次使用时加载，减少了服务启动等待时间。
附图说明
[0040] 图1：
现有技术中GeoWebCache工作原理示意图；
[0041] 图2:现有技术中基于GeoWebCache实现的常见系统结构示意图；
[0042] 图3:本发明所述瓦片地图服务集群系统结构示意图；
[0043] 图4：本发明所述瓦片地图服务集群系统处理瓦片请求流程。
具体实施方式
[0044] 下面将结合本发明
实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅为本发明的一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域的普通技术人员在不付出创造性劳动的前提下所获得的所有其他实施例，都属于本发明的保护范围。
[0045] 下面结合附图对本发明作进一步详细说明。
[0046] 参见附图1-2所示，为现有技术中GeoWebCache的一种典型用法，可以看到GeoWebCache使用自身内存和文件系统存储地图元数据信息，使用文件系统做瓦片缓存。该方法存在如下问题：
[0047] 服务需要与硬盘文件进行交互来获取瓦片，I/O速度慢，响应时间长，性能比较受制约，在安全性方面也存在上述问题；使用瓦片地图服务内存缓存图层元数据，服务启动过程中加载全部元数据信息，使用服务的内存缓存元数据，速度的确比较快，但是当服务重启之后，缓存会全部清空，启动从文件系统加载又非常耗时，图层多的情况下需要几十分钟之久。在集群部署的情况下，每个实例内存中都会保存一份元数据样本，非常消耗资源，且容易造成实例间的数据不一致，存在一定隐患。
[0048] 参见附图3，为本发明所述的基于Redis和PostgreSQL数据库的瓦片地图服务集群系统，此系统可以将地图元数据存储到PostgreSQL数据库中，并在Redis中缓存，请求过的瓦片也都会在Redis中保留一份副本。
[0049] 对比图2的结构和图3本发明的结构，可以看出来本发明的瓦片地图服务不依赖文件系统进行数据的存储，服务器内存中也不存在元数据的副本，瓦片地图服务与数据是独立存放的，且使用的都是高性能的存储组件。
[0050] 通过采用本发明的方法，使用PostgreSQL数据库做地图元信息的存储，实现瓦片地图发布功能，将地图元信息存储到数据库中，不再直接与文件系统做交互，流程更加简洁，同时具有以下几个优点：
[0051] (1)提高了数据的共享性，使多个用户能够同时访问数据库中的数据[0052] 本发明的文件系统实现以文件为单位的数据共享，数据库系统实现以记录和字段为单位的数据共享，粒度小，共享性高。
[0053] (2)提高了数据的一致性和完整性
[0054] 使用数据库存放元数据，文件系统可以只保证元数据的一致性，数据库有不同级别的一致性；数据表本身是结构化的，可以按需求定义每个字段的约束，防止数据库中存在不符合语义规定的数据，保证了完整性。
[0055] (3)提供数据与应用程序的独立性
[0056] 瓦片地图服务中不含有业务数据，数据单独存放在PostgreSQL数据库和Redis中，减少了耦合，方便服务进行
水平扩展。
[0057] 本发明使用Redis做瓦片缓存，数据都在服务器内存上。当客户端请求瓦片时，服务器拦截来自客户端的请求，判断本次请求的数据是否已经被缓存。如果请求数据已被缓存，则将这些缓存图片直接渲染至客户端；如果请求数据没有被缓存，则由瓦片地图服务系统下游处理请求数据，获取瓦片数据并缓存至Redis，之后绘制到客户端，下次再访问同一瓦片直接通过Redis获取，减少了响应时间，提升了用户体验。
[0058] 本发明使用Redis做图层元信息缓存，并
修改加载策略，具体的，使用Redis存储图层元信息，在保证高性能读写能力的情况下，还可以更好的满足服务集群部署的需求，使多个实例之间可以共享同一份图层元数据信息，保证了一致性；服务中不再包含这些状态信息，即使服务重启也不会影响业务处理速度，节约了时间和空间成本；在服务启动过程中，不再预先加载所有图层元数据信息，仅在第一次使用时才进行缓存的创建，减少服务启动的等待时间，提升用户体验。
[0059] 具体的，参见附图4，根据本发明的一个实施例，客户端发起的瓦片请求流程，所述瓦片地图服务集群系统处理瓦片请求流程步骤如下：
[0060] 步骤1、瓦片地图存储服务接收到客户端的瓦片请求，判断Redis中是否存在该瓦片所属地图的元数据是否存在。
[0061] 步骤2、Redis中地图元数据存在，跳至步骤6。
[0062] 步骤3、Redis中地图元数据不存在，查询PostgreSQL数据库中的地图元数据表。
[0063] 步骤4、PostgreSQL中地图元数据存在，将元数据缓存至Redis中。
[0064] 步骤5、PostgreSQL中地图元数据不存在，瓦片为空，返回响应信息，请求流程结束。
[0065] 步骤6、服务判断Redis中是否存在请求的瓦片缓存。
[0066] 步骤7、如果Redis中瓦片数据存在，跳至步骤9；否则调至步骤8；
[0067] 步骤8、如果Redis中瓦片数据不存在，根据地图元数据和请求参数，获取瓦片数据，并将瓦片数据缓存到Redis中。
[0068] 步骤9、服务将瓦片数据返回至客户端，请求流程结束。
[0069] 尽管上面对本发明说明性的具体实施方式进行了描述，以便于
本技术领域的技术人员理解本发明，且应该清楚，本发明不限于具体实施方式的范围，对本技术领域的普通技术人员来讲，只要各种变化在所附的
权利要求限定和确定的本发明的精神和范围内，这些变化是显而易见的，一切利用本发明构思的发明创造均在保护之列。
