Kong 集群允许您通过添加更多的机器来处理更多的传入请求来横向扩展系统。它们将共享相同的配置，因为它们指向相同的数据库。指向相同数据存储的 Kong 节点将属于相同的 Kong 集群。
您需要在Kong集群前面安装一个负载平衡器，以便在可用节点之间分配流量。
拥有一个 Kong 集群并不意味着你的客户机流量将在您的 Kong 节点之间实现开箱即用的负载平衡。你仍然需要在Kong节点前安装一个负载平衡器来分配流量。相反，Kong集群意味着这些节点将共享相同的配置。
出于性能原因，Kong在代理请求时避免数据库连接，并将数据库的内容缓存到内存中。缓存的实体包括服务、路由、消费者、插件、凭证等……由于这些值都在内存中，因此通过其中一个节点的管理API所做的任何更改都需要传播到其他节点。
本文档描述了如何使这些缓存的实体失效，以及如何为用例配置Kong节点，该用例介于性能和一致性之间。
单个的 Kong 节点连到数据库创建一个单节点的 Kong 集群。通过该节点的管理 API 应用的任何更改都将立即生效。
考虑一个单独的 Kong 节点A。如果我们删除之前注册的服务:
$ curl -X DELETE http://127.0.0.1:8001/services/test-service然后，任何对节点 A 的后续请求都会立即返回 404 Not Found，因为节点将其从本地缓存中清除。
在一个集群有多个 Kong 节点的情况下，连接到同一数据库的其他节点不会立即被通知服务已被节点 A 删除。 虽然服务不在数据库中(被节点A删除)，但它仍然在节点B的内存中。
所有节点执行一个周期性的后台作业，以同步其他节点可能触发的更改。此作业的频率可通过以下方式配置:
db_update_frequency (default: 5 seconds)
每隔 db_update_frequency 秒，所有运行的 Kong 节点都将轮询数据库以获得任何更新，并在必要时从缓存中清除相关实体。
如果我们从节点 A 中删除一个服务，这个更改在节点B中不会有效，直到节点B的下一次数据库轮询，该轮询将在几秒后发生，直到 db_update_frequency (尽管可能更快)。
这使得 Kong 集群最终保持一致。
Kong 的集群在早期是通过 cluster 命令来创建和维护的，从 0.11 版本开始，变换了集群的搭建方式。参考文档 Kong 0.11 changeLog 。
从 0.11 版本之后去除了 cluster 管理功能以后，Kong 变成了完全无状态，只要是连接到同一个 Kong 数据库的节点，都认为是同一个 Kong 集群而不需要额外的通信机制，因此也不需要在 kong.conf 文件中配置 cluster 参数。
Kong 集群的搭建就是把所有的 Kong 节点都连同一个 Kong 数据库就可以了，所有结果通过轮询机制去读取数据库来保证数据的一致性。
所有的核心实体，如服务、路由、插件、消费者、凭证，都由Kong缓存在内存中，并依赖于它们通过要更新的轮询机制的失效。
此外，Kong还缓存数据库 的 misses。这意味着如果您配置一个没有插件的服务，Kong将缓存此信息。例子:
假设我们通过节点A的管理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 已经提供了默认的配置，为了让你权衡集群性能和数据一致性两个方面，避免意外的结果。你可以按照下面的配置步骤，改变配置的值，从而确保性能和数据一致性能够被接受。
该配置决定 kong 节点从数据库拉取更新缓存的时间间隔，同步任务执行的频率。值越小意味着同步任务将会执行的更频繁，Kong 节点的缓存数据将保持和数据库更强的一致性。值越大的时候，意味着你的 Kong 节点花更少的时间去处理同步任务，从而将更多的资源用来处理请求。
Note：变更将会在 db_update_frequency 秒后在整个集群节点中生效。
如果你的数据库也是集群的并且最终一致性的（比如：Cassandra），你必须配置该值。它将确保 db_update_propagation 秒后，数据库节点间的变化在整个数据库集群中所有节点生效。当配置了该值，Kong 节点从同步任务中接收无效事件，清除本地缓存将会延迟 db_update_propagation 秒。
如果一个 Kong 节点连接到最终一致性数据库上，且没有延迟事件需要处理，它可能会清除缓存，然后把没有更新的值再次缓存起来。（因为这个改变还没有传播到数据库集群的每一个节点，注释：数据库一致性还没有在数据库集群中达到一致，此时 Kong 缓存到期了，但是没有更新到变化事件，此时会把没有更新的值再次缓存起来，导致 Kong 也出现不一致，即便 Kong 执行了同步任务。）。
你应该配置该值，通过评估数据库集群发生变更后，最终达到一致性所需要的时间。（确保数据库一致之后，才去执行 Kong 同步任务处理变更事件，从而达到 Kong 数据一致性）
Note：当配置了该配置项，数据变更传播到 Kong 集群的最大时间是 db_update_frequency + db_update_propagation 秒。
3.db_cache_ttl (default: 3600s)
该配置项的时间（单位秒）是 Kong 缓存数据库实体的时间（包括缓存命中或者穿透），该存活时间是一种保护措施，以防 Kong 节点漏掉处理缓存无效事件，避免旧数据长时间没有被清理。当缓存生存时间到了，缓存值将会被清理掉，下一次将会从数据库读取数据并再次缓存起来。
4.当使用 Cassandra 数据库
如果使用 Cassandra 作为 Kong 的数据库，你必须配置 db_update_propagation 为一个非零值。由于 Cassandra 本身是最终一致性数据库，这将确保 Kong 节点不会过早地使本地缓存失效，仅仅当再次获取到一个不是最新值的时候。如果你使用了 Cassandra 但你没有配置该值时，Kong 将会输出一条警告日志。
此外，你可以配置 cassandra_consistency 的值为 QUORUM 或者 LOCAL_QUORUM，确保被 Kong 缓存的值是数据库中最新的。
本文讲解了 Kong 的集群相关的东西，如果由于某些原因，你希望通过 Kong 查看缓存的值，或者手动清理缓存（当缓存被命中或者丢失），你可以通过使用 Admin api 的 /cache 接口进行管理。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
