MS RFC 110:MapCache REST缓存后端

日期

2014/04

作者

托马斯堡

联系

tbonfort@terriscope.fr

状态

草稿

版本

MAPServer 7

最后更新

2014/04/17

1。动机

除了支持的缓存后端之外,MapCache还希望能够使用get、put和delete谓词通过HTTP REST接口存储和检索数据块。虽然任何启用WebDAV的服务器都可以使用,但此改进的最终目标是能够将数据块存储到知名的云存储提供商(最初是:S3、Azure和Google)。

2。实施细节

2.2一般休息后端

添加缓存后端不影响体系结构,因为它只意味着添加缓存特定的vtable函数。其余缓存本身是相当具体的,因为通常有一个特定于每个提供者的身份验证/授权步骤,通常包括用一个附加到帐户上的密钥对给定的负载进行签名。

REST缓存配置了一个XML块:

<cache name="myrestcache" type="rest">
   <url>https://myserver/webdav/{tileset}/{grid}/{z}/{x}/{y}.{ext}</url>
   <headers>
     <Host>my-virtualhost-alias.domain.com</Host>
   </headers>
   <operation type="put">
     <headers>
       <X-my-specific-put-header>foo</X-my-specific-put-header>
     </headers>
   </operation>
   <operation type="get">
     <headers>
       <X-my-specific-get-header>foo</X-my-specific-get-header>
     </headers>
   </operation>
   <operation type="head">
     <headers>
       <X-my-specific-head-header>foo</X-my-specific-head-header>
     </headers>
   </operation>
   <operation type="delete">
     <headers>
       <X-my-specific-delete-header>foo</X-my-specific-delete-header>
     </headers>
   </operation>
</cache>
  • <url>块将模板url配置为在寻址特定磁贴时使用,并遵循定义基于模板的磁盘后端时使用的相同语法。

  • 初始<header>块包含将添加到任何发送到第三方服务器的HTTP请求的HTTP头列表。

  • 每个<operation>块还可以包含要添加到特定操作请求的特定头的<header>列表,由其“type”属性指定:

    • 从服务器请求磁贴时使用“get”

    • “head”在查询服务器是否存在磁贴时使用(仅由播种机使用)。

    • 上载新创建的图块时使用“放置”

    • 从服务器删除磁贴时使用“删除”

2.2添加对知名云服务的支持

一旦与第三方云存储提供商关联,REST缓存后端就变得非常有用,以便能够在云中存储数据块。在体系结构上,mapcache中的每个特定于供应商的实现都提供了一个钩子,可以向HTTP请求添加特定的头,以允许对请求进行签名/验证。为了允许签名,计算有效负载的shas的特定代码将添加到mapcache。

2.2.1亚马逊S3

<cache name="s3" type="s3">
  <url>https://mybucket.s3.amazonaws.com/tiles/{tileset}/{grid}/{z}/{x}/{y}.{ext}</url>
  <headers>
    <Host>mybucket.s3.amazonaws.com</Host>
  </headers>
  <id>XXXXXXXXXXXXXXX</id>
  <secret>foobaregrwq1235234532/3245234sadgfwevsd</secret>
  <region>eu-west-1</region>
  <operation type="put">
    <headers>
      <x-amz-storage-class>REDUCED_REDUNDANCY</x-amz-storage-class>
      <x-amz-acl>public-read</x-amz-acl>
    </headers>
  </operation>
</cache>

此缓存使用3个强制配置选项:<id>、<secret>和<region>。每个值都是不言而喻的,可以在S3文档中找到。在上一个示例中,我们将特定于S3的头添加到“Put”请求中,指定我们希望将公开可读的数据块存储在一个成本更低的后端中。其他x-amz-*头可以在从S3文档站点查找后添加。

2.2.2微软Azure

<cache name="azure" type="azure">
   <url>https://mytiles.blob.core.windows.net/tilestore/{tileset}/{grid}/{z}/{x}/{y}.{ext}</url>
   <headers>
     <Host>mytiles.blob.core.windows.net</Host>
   </headers>
   <id>mytiles</id>
   <secret>base64encodedsecretkey==</secret>
   <container>tilestore</container>
 </cache>

此缓存再次具有3个配置选项:<id>、<secret>和<container>。上一个示例中没有添加任何特定于Azure的头文件,因为冗余和访问权限是为容器配置的,而不是为Azure中的每个文件配置的。

2.2.3谷歌云存储

<cache name="google" type="google">
   <url>https://storage.googleapis.com/mytiles-mapcache/{tileset}/{grid}/{z}/{x}/{y}.{ext}</url>
   <access>GOOGPGDWFDG345SDFGSD</access>
   <secret>sdfgsdSDFwedfwefr2345324dfsGdsfgs</secret>
   <operation type="put">
     <headers>
       <x-amz-acl>public-read</x-amz-acl>
     </headers>
   </operation>
 </cache>

Google实现使用Google的S3兼容层(实际上与Mapcache的S3实现不同,因为它使用的是早期版本的身份验证/签名有效负载)。因此,x-amz-*头用于为给定的tile文件配置选项。

三。其他

  • rest<cache>条目可以包含一个<use_redirects>true的条目,通知mapcache单个tile请求可以作为HTTP 302重定向直接返回到tile的云URL,而不是由mapcache返回。这通常只用于完全种子化的缓存,因为在这种情况下,mapcache不会查询缓存以了解图块是否实际存在。

  • mapcache根据请求打开到云存储的HTTP连接。在实践中,这在某些提供程序中显示出潜在的缓慢性,瓶颈是DNS查找。为了缓解这种情况,您可以直接在<url>成员中使用IP地址,或者安装本地DNS缓存服务器(考虑到dnsmasq)。进一步的开发(等待资金)可以实现跨请求重用HTTP连接。

3.1向后不兼容

不需要,新功能

3.2问题跟踪ID

https://github.com/MapServer/mapcache/pull/98

3.4文件更改

  • include/mapcache.h

  • lib/cache_rest.c(已添加)

  • lib/hmac sha.c(已添加)-用于为云提供程序签名有效负载

  • 支持“重定向”模式的细微修改