集群允许您水平地扩展系统，通过增加更多的机器来处理更多的传入请求。它们将共享相同的配置，因为它们指向同一个数据库。指向相同数据存储的Kong节点将是同一个集群的一部分。
您需要在您的Kong集群前面放一个负载平衡器来分配流到不同的可用节点。
Kong集群可以做什么，不能做什么？
使用Kong集群并不意味着您的客户端流量能马上均衡负载到您的Kong节点。在Kong节点前面，您仍然需要一个负载平衡器来分配您的流量。一个集群意味着这些节点将共享相同的配置。
出于性能方面的原因，在代理请求时，Kong避免频繁数据库连接，会在本地缓存配置数据。缓存的实体包括服务、路由、消费者、插件、凭证等。因为这些值都在内存中，所以通过一个节点的管理API所做的任何更改都需要传播到其他节点。
这个文档描述了那些缓存的实体是如何失效的，以及如何平衡性能和一致性。
单节点Kong集群
创建一个链接到数据库（Cassandra或者PostgreSQL）的单节点Kong集群。通过该节点的管理API应用的任何更改都会立即生效。
多节点Kong集群
在多节点Kong集群中，节点A做了修改。连接到同一数据库的其他节点不会立即被通知修改。虽然，服务在数据库中修改，但它仍然存在其他节点的内存中。
所有节点都会执行一个定时任务，与其他节点触发的更改同步，从而保持最终一致性。这项工作的频率可以通过以下方式进行配置：
- db_update_frequency (默认: 5秒)
什么会被缓存？
所有的核心实体，如服务、路由、插件、消费者、凭证都被存储在内存中，并通过轮询机制来更新它们的有效性。
如何配置数据库缓存？
您可以在Kong配置文件中配置3个属性，其中最重要的是db_update_frequency，它决定了你的Kong节点在性能和一致性间的平衡。
1. db_update_frequency (default: 5s)
2. db_update_propagation (default: 0s)
3. db_cache_ttl (default: 3600s)
这三个参数的详解可以参考：配置详解 - 玩转Kong网关
4. 当使用Cassandra
如果您使用Cassandra作为Kong的数据库，那必须设置db_update_propagation的值。因为Cassandra天生的最终一致性，这将确保Kong节点不会为了获取一个没更新的实体过早地清理缓存。如果不设置，Kong会给出警告提示。
另外，最好配置cassandra_consistency的值为QUORUM或者LOCAL_QUORUM，确保Kong节点缓存的值是来自数据库的最新值。
通过管理API与缓存交互
可以通过管理API /cache 来管理Kongd的缓存。
检索缓存值
请求地址：/cache/:cache_key
请求方法：GET
清理缓存值
请求地址：/cache/:cache_key
请求方法：DELETE
清理节点的缓存
请求地址：/cache
请求方法：DELETE
温馨提示
缓存API只支持上面三种操作，如果要使用上面带cache_key的操作，那么首先需要知道cache_key的值。一般在调试环境下，直接使用清理换不缓存即可。而生产环境，当然是禁止使用的，交由kong的定时任务来处理。
