简介
Kong集群允许用户横向扩展系统，添加更多机器来处理更多请求，因为它们指向同一个数据库，所有它们之间共享相同的配置，指向同一个数据仓库的Kong节点会成为同一个Kong集群的一部分
用户需要在Kong集群前配置负载均衡器，以便在节点之间分配流量
Kong集群可以做什么，不可以做什么
拥有一个Kong集群并不意味着客户端的流量会被自动负载均衡到各个Kong节点，用户需要在Kong节点前配置负载均衡器分配流量，Kong集群仅意味着这些节点将共享相同的配置
出于性能原因，Kong在代理请求时避免数据库连接，它将数据库的内容缓存在内存中，缓存的实体包括服务、路由、消费者、插件、凭证等等，由于这些值都存在内存中，所以通过 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秒）
当过了指定时间后，运行中的Kong节点会轮询数据库的最新数据，并对缓存中的数据进行更新，如果用户在A节点删除了服务，B节点在进行下一次数据库轮询前不会马上生效，最终Kong集群会保持一致
缓存的内容
所有的核心如服务、路由、插件、消费者、凭证等都由Kong缓存在内存中，并通过轮询机制进行更新，此外，Kong还会缓存数据库缺失的信息，这意味着如果用户配置了一个没有插件的服务，Kong也会缓存下来：
在A节点上，我们添加一个服务和一个路由：
# 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"
可以发现A、B节点都缓存了这个服务，并且都没有配置插件的记录：
# A节点
curl http://127.0.0.1:8000/example
HTTP 200 OK
# B节点
curl http://127.0.0.2:8000/example
HTTP 200 OK
现在，假设我们通过A节点的 Admin API 为此服务添加一个插件：
# 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仍然不包含插件
结论：所有的 CRUD 操作都会使之前的缓存失效
如何配置数据库缓存
用户可以在Kong的配置文件中配置三个属性，其中最重要的一个是 db_update_frequency，它可以权衡Kong节点的一致性和性能，Kong提供了一致性的默认值，以便用户在使用集群的时候不至于感到特别意外，在投入生产后，用户应该考虑调整这些值以确保性能可靠
1. db_update_frequency（默认5秒）
这个值确定了Kong节点轮询数据库的频率，值越小表示轮询作业执行得越频繁，Kong节点会尽快更新最新配置；值越大Kong节点会花较少的时间执行轮询作业，并专注于代理客户端流量
2. db_update_propagation（默认0秒）
如果用户的数据库本身最终是需要一致的（即：Cassandra）,则必须配置这个值，这是为了确保变更有时间在数据库节点间传播，当设置这个值后，Kong节点在执行轮询作业前，会延时 db_update_propagation 秒
用户应该将这个值设置为数据库集群同步数据所用时间的预估值
注意：设置此值后，更改传播到整个集群需要 db_update_frequency + db_update_propagation 秒
3. db_cache_ttl（默认0秒）
Kong会缓存数据库中的内容一段时间，当设置了TTL时，Kong会从缓存中清除该值，直到下一次从数据库读取数据
默认情况下，这个值默认值为0，这通常运行的很好，Kong节点依赖数据源的更改（Cassandra/PosgreSQL），如果用户担心Kong节点会因其他任何原因错过更新事件，则应设置TTL，否则节点可能会使用过期值运行一段时间，直到手动清除缓存或重新启动节点
4. 使用Cassandra
如果用户使用 Cassandra 作为数据源，那么必须设置 db_update_propagation 为正数，因为 Cassandra 集群各节点的数据最终会同步，这样可以保证Kong节点不会拿到一个还未来得及更新的值，如果用户没有配置这个值，Kong会显示给用户一个告警日志
此外，用户可能希望将 cassandra_consistency 配置为 QUORUM 或 LOCAL_QUORUM，以确保Kong节点缓存的值是数据库中的最新值
通过Admin API与缓存交互
有些情况下，用户希望查询缓存的值，或者手动更改缓存值，可以通过 Admin API 的 /cache 端点来操作
检查缓存的值
- 端点
GET /cache/{cache_key}
- 响应
如果key值对应的值有缓存：
HTTP 200 OK ... { ... }
如果没有缓存：
HTTP 404 Not Found
注意：Kong现在尚未提供检索每个实体哪些 cache_key 被缓存的接口，之后的版本会提供
清除缓存的值
- 端点
DELETE /cache/{cache_key}
- 响应
HTTP 204 No Content ...
清除节点的缓存
- 端点
DELETE /cache
- 响应
HTTP 204 No Content
注意：在已经运行的生产节点上慎用这条命令，如果该节点正在接收大量请求，同时清除其缓存会触发对数据库的大量请求，并可能造成缓存雪崩效应
