集群允许您水平地扩展系统,通过增加更多的机器来处理更多的传入请求。它们将共享相同的配置,因为它们指向同一个数据库。指向相同数据存储的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)
这三个参数的详解可以参考:配置详解

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的定时任务来处理。