Skip to content

Latest commit

 

History

History
181 lines (119 loc) · 8.16 KB

clustering.md

File metadata and controls

181 lines (119 loc) · 8.16 KB
Raw

集群

简介

Kong群集允许您通过添加更多计算机来处理更多传入请求，从而水平的扩展系统。它们将共享相同的配置，因为它们都指向同一个数据库。指向同一数据存储区的Kong节点将成为同一Kong集群的一部分。

您需要在群集前面安装负载均衡器，以便在可用节点之间分配流量。

Kong的集群能做什么，不能做什么

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

出于性能原因，Kong在代理请求时避免数据库连接，并将数据库的内容缓存在内存中。缓存的实体包括服务(Services)，路由(Routes)，消费者(Consumers)，插件(Plugins)，证书(Credentials)等......由于这些值在内存中，因此其中一个节点的通过Admin API进行的任何更改都需要广播到其他节点。

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

单节点Kong集群

连接到数据库（Cassandra或PostgreSQL）的单个Kong节点创建一个节点的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

多节点Kong集群

在多个Kong节点的集群中，连接到同一数据库的其他节点不会立即被通知节点A删除了服务。虽然服务不再存在于数据库中（它被节点A删除），但它仍然在节点B的内存中。

所有节点执行定期后台作业以与可能已由其他节点触发的更改同步。可以通过以下方式配置此作业的频率：

  • db_update_frequency (默认值 : 5 秒)

每个db_update_frequency秒，所有正在运行的Kong节点将轮询数据库以进行任何更新，并在必要时从其缓存中清除相关实体。

如果我们从节点A删除服务，则此更改在节点B中将无效，直到节点B下一次数据库轮询，将在几秒钟之后在db_update_frequency发生（尽管可能更快发生）。

最终这使得Kong保证了集群一致性。

什么会被缓存

所有核心实体如服务(Services)，路由(Routes)，消费者(Consumers)，插件(Plugins)，证书(Credentials)都由Kong缓存在内存中，并通过轮询机制来更新他们是否失效。

此外，Kong还缓存了数据库中没有的。这意味着如果您配置一个没有插件的服务，Kong将缓存此信息。例如：

# 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的Admin API为此服务添加一个插件：

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

由于此请求是通过节点A的Admin API发出的，因此节点A将在本地使其缓存失效，并且在后续请求中，它将检测到此API已配置插件。

但是，节点B尚未运行数据库轮询，并且仍然缓存此API没有可运行的插件。直到节点B运行其数据库轮询操作才会这样。

结论：所有CRUD操作都会触发缓存失效。创建（POST，PUT）将使缓存的数据库未命中无效，并且更新/删除（PATCH，DELETE）将使缓存的数据库命中无效。

如何配置数据库缓存？

您可以在Kong配置文件中配置3个属性，其中最重要的是db_update_frequency，它确定了你的Kong节点在性能与一致性权衡方面的立场。Kong提供了一致性的默认值，以便让您在避免“意外”的同时试验其聚类功能。在准备生产环境设置时，应考虑调整这些值以确保遵守性能约束。

1.db_update_frequency (default: 5s)

此值确定Kong节点将为无效事件轮询数据库的频率。较低的值意味着轮询作业将更频繁地执行，但是您的Kong节点将会迅速跟上您应用的更改。值越高意味着您的Kong节点将花费更少的时间来运行轮询作业，并将专注于代理您的流量。

注意：更改在集群中传播的时间最多为db_update_frequency秒。

2.db_update_propagation (default: 0s)

如果数据库本身最终是一致的（即：Cassandra），则必须配置此值。这是为了确保更改有时间跨数据库节点传播。设置后，Kong节点从其轮询作业接收失效事件将延迟清除db_update_propagation秒的缓存。

如果连接到最终一致数据库的Kong节点没有延迟事件处理，它可以清除其缓存，只是再次缓存未更新的值（因为更改尚未通过数据库传播）！

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

注意：设置此值后，更改将通过群集传播到db_update_frequency + db_update_propagation秒。

3.db_cache_ttl (default: 0s)

Kong将缓存数据库实体（命中和未命中）的时间（以秒为单位）。如果Kong节点错过了无效事件，则此生存时间值可作为安全措施，以避免它在过时的数据上运行。到达TTL时间时，将从其缓存中清除该值，并再次缓存下一个数据库结果。

默认情况下，不会根据此TTL使数据无效（默认值为0）。这通常很好：Kong节点依赖于无效事件，这些事件在db存储级别处理（Cassandra/PosgreSQL）。如果您担心Kong节点可能因任何原因错过失效事件，则应设置TTL。否则，节点可能会在其缓存中以过时值运行一段未定义的时间，直到手动清除缓存或重新启动节点。

4.When using Cassandra

如果使用Cassandra作为Kong数据库，则必须将db_update_propagation设置为非零值。由于Cassandra最终本质上是一致的，这将确保Kong节点不会过早地使其缓存无效，只能再次获取并捕获不是最新的实体。如果您在使用Cassandra时未配置此值，Kong将向您显示警告日志。

此外，您可能希望将cassandra_consistency配置为QUORUM或LOCAL_QUORUM之类的值，以确保Kong节点缓存的值是数据库中的最新值。

通过Admin API与缓存交互

如果由于某种原因，您希望调查缓存的值，或者手动使Kong缓存的值无效（缓存命中或未命中），则可以通过Admin API /cache 端点执行此操作。

检查缓存的值

  • Endpoint 
    GET /cache/{cache_key}
  • 返回 如果缓存了具有该键的值： 
    HTTP 200 OK
...
{
    ...
}
    否则： 
    HTTP 404 Not Found

注意：为Kong缓存的每个实体检索cache_key目前是一个未记录的过程。管理API的未来版本将使此过程更容易。

清除缓存的值

  • Endpoint 
    DELETE /cache/{cache_key}
  • 返回 
     HTTP 204 No Content
 ...

注意：为Kong缓存的每个实体检索cache_key目前是一个未记录的过程。 管理API的未来版本将使此过程更容易。

清除节点的缓存

  • Endpoint 
    DELETE /cache
  • 返回 
     HTTP 204 No Content

注意：要小心在运行良好的生产运行节点上使用此端点。 如果节点正在接收大量流量，同时清除其缓存将触发对数据库的许多请求，并可能导致dog-pile effect。