Kong（V1.0.2） Clustering Reference

介绍

Kong集群容许您经过添加更多的机器来处理更多的传入请求来水平扩展系统。它们将共享相同的配置，由于它们指向相同的数据库。指向相同数据存储的Kong节点将是相同Kong集群的一部分。

您须要在Kong集群前面有一个负载均衡器，以便跨可用Kong节点分发流量。

一个Kong集群能作什么，不能作什么

拥有一个Kong集群并不意味着您的客户端流量将当即在您的Kong节点之间进行负载均衡。在Kong节点前面仍然须要一个负载均衡器来分配流量。相反，Kong集群意味着这些节点将共享相同的配置。

出于性能缘由，Kong在代理请求时避免数据库链接，并在内存中缓存数据库的内容。缓存的实体包括Services, Routes, Consumers, Plugins, Credentials等等……由于这些值在内存中，因此经过其中一个节点的Admin API所作的任何更改都须要传播到其余节点。

这个文档描述了这些缓存的实体是如何失效的，以及如何为您的用例配置Kong节点，这是介于性能和一致性之间的。

Single node Kong clusters

链接到数据库的单个Kong节点(Cassandra或PostgreSQL)建立一个节点的Kong集群。经过此节点的Admin API的任何更改都将当即生效。例子:

考虑单个Kong节点A。若是咱们删除以前注册的服务:

curl -X DELETE http://127.0.0.1:8001/services/test-service

 而后任何后续的对A的请求都会当即返回404 Not Found，由于节点将其从本地缓存中清除:

curl -i http://127.0.0.1:8000/test-service

Multiple nodes Kong clusters 多节点Kong集群

在一个由多个Kong节点组成的集群中，链接到同一数据库的其余节点不会当即收到节点A删除该服务的通知。虽然该服务已不在数据库中(已被节点A删除)，但它仍然在节点B的内存中。

全部节点都执行一个周期性的后台做业，以与其余节点可能触发的更改同步。此做业的频率可经过如下方式配置:

• db_update_frequency (default: 5 seconds)

每一个db_update_frequency秒，全部运行的Kong节点都将轮询数据库以获取任何更新，并在必要时从缓存中清除相关实体。

若是咱们从节点A中删除一个服务，这个更改在节点B中不会有效，直到节点B进行下一次数据库轮询，该轮询将在数秒后(尽管可能更早)发生db_update_frequency。

这使得Kong集群最终保持一致。

What is being cached?  缓存的是什么?

全部的核心实体，如Services, Routes, Plugins, Consumers, Credentials等，都被Kong缓存在内存中，并依赖于经过轮询机制更新它们的有效性。

此外，Kong还可能cache database丢失。这意味着若是您配置一个没有插件的服务，Kong将缓存此信息。例子:

在节点A上，咱们添加了一个服务和一个路由:

# node A

curl -X POST http://127.0.0.1:8001/services \ --data "name=example-service" \ --data "url=http://example.com" 

curl -X POST http://127.0.0.1:8001/services/example-service/routes \ --data "paths[]=/example" 

(注意，咱们使用/services/example-service/routes做为快捷方式:咱们原本可使用/routes端点，可是咱们须要将service_id做为参数传递，使用新服务的UUID)。

对节点A和节点B代理端口的请求将缓存此服务，且没有在其上配置插件:

# node A 

curl http://127.0.0.1:8000/example
HTTP 200 OK
...

# node B 

curl http://127.0.0.2:8000/example
HTTP 200 OK
...

如今，假设咱们经过节点A的管理API向该服务添加一个插件:

# node A 

curl -X POST http://127.0.0.1:8001/services/example-service/plugins \ --data "name=example-plugin" 

因为此请求是经过节点A的管理API发出的，所以节点A将在本地使其缓存失效，而且在随后的请求中，它将检测此API是否配置了插件。

可是，节点B尚未运行数据库轮询，而且仍然缓存这个API没有插件能够运行的数据。在节点B运行其数据库轮询做业以前，状况将一直如此。

结论:全部CRUD操做都会触发缓存失效。建立(POST, PUT)将使缓存的数据库丢失失效，而更新/删除(PATCH, DELETE)将使缓存的数据库命中失效。

How to configure database caching?如何配置数据库缓存?

您能够在Kong配置文件中配置3个属性，其中最重要的一个是db_update_frequency，它决定了您的Kong节点在性能和一致性之间的权衡位置。

Kong提供了针对一致性进行调优的默认值，以便让您在试验其集群功能的同时避免“意外”。在准备生产设置时，应该考虑对这些值进行调优，以确保性能约束获得尊重。

1. db_update_frequency(默认值:5 s)

此值肯定Kong节点轮询数据库以查找无效事件的频率。较低的值意味着轮询做业将更频繁地执行，可是您的Kong节点将跟上您所应用的更改。较高的值将意味着Kong节点运行轮询做业的时间将减小，并将重点放在代理流量上。

注意:意味着对Kong的配置更改在集群中传播的时间最长为db_update_frequency秒。

2. db_update_propagation(默认值:0)

若是数据库自己最终是一致的(即:Cassandra)，则必须配置此值。这是为了确保更改有时间在数据库节点之间传播。设置好后，从轮询做业接收无效事件的Kong节点将延迟缓存的清除，以得到db_update_propagation秒。

若是链接到最终一致的数据库的Kong节点没有延迟事件处理，那么它能够清除其缓存，只缓存未更新的值(由于更改尚未在数据库中传播)!

您应该将此值设置为数据库集群传播更改所需时间的估计值。

注意:设置此值时，对Kong的配置更改在集群中传播的时间最长为db_update_frequency + db_update_propagation秒。

3. db_cache_ttl (default: 0s)

Kong缓存数据库实体(命中和未命中)的时间(以秒为单位)。这个Time-To-Live值在Kong节点错过失效事件时起保护做用，以免它在过时数据上运行太长时间。当到达TTL时，将从其缓存中清除该值，并再次缓存下一个数据库结果。

默认状况下，没有数据基于这个TTL无效(默认值是0)，这一般很好:Kong节点依赖于失效事件，这些事件在数据库存储级别(Cassandra/PosgreSQL)进行处理。若是您担忧Kong节点可能由于任何缘由错过无效事件，您应该设置TTL。不然，节点可能会在缓存中使用过时值运行一段未定义的时间，直到手动清除缓存或从新启动节点。

4. When using Cassandra

若是使用Cassandra做为Kong数据库，则必须将db_update_propagation设置为非零值。因为Cassandra的本质最终是一致的，这将确保Kong节点不会过早地使其缓存失效，而只是再次获取和捕获一个不最新的实体。若是您在使用Cassandra时没有配置此值，Kong将显示一个警告日志。

此外，您可能但愿将cassandra_consistency配置为QUORUM或LOCAL_QUORUM这样的值，以确保Kong节点缓存的值是来自数据库的最新值。

Interacting with the cache via the Admin API（经过管理API与缓存进行交互）

若是出于某种缘由，您但愿研究缓存的值，或者手动使Kong缓存的值无效(缓存命中或未命中)，那么能够经过管理API /cache端点来实现。

Inspect a cached value

Endpoint

GET /cache/{cache_key}

Response

If a value with that key is cached:

HTTP 200 OK
...
{
    ...
}

Else:

HTTP 404 Not Found

Note: retrieving the cache_key for each entity being cached by Kong is currently an undocumented process. Future versions of the Admin API will make this process easier.

Purge a cached value

Endpoint

DELETE /cache/{cache_key}

Response

HTTP 204 No Content
...

Note: retrieving the cache_key for each entity being cached by Kong is currently an undocumented process. Future versions of the Admin API will make this process easier.

Purge a node’s cache

Endpoint

DELETE /cache

Response

HTTP 204 No Content

Note: be wary of using this endpoint on a warm, production running node. If the node is receiving a lot of traffic, purging its cache at the same time will trigger many requests to your database, and could cause a dog-pile effect.