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-servicecurl -i http://127.0.0.1:8000/test-serviceMultiple 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
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
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
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.
