Kong 的集群怎么用

Kong 集群允許您通過添加更多的機器來處理更多的傳入請求來橫向擴展系統。它們將共享相同的配置，因為它們指向相同的數據庫。指向相同數據存儲的 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 已經提供了默認的配置，為了讓你權衡集群性能和數據一致性兩個方面，避免意外的結果。你可以按照下面的配置步驟，改變配置的值，從而確保性能和數據一致性能夠被接受。

1.db_update_frequency (default: 5s)

該配置決定 kong 節點從數據庫拉取更新緩存的時間間隔，同步任務執行的頻率。值越小意味著同步任務將會執行的更頻繁，Kong 節點的緩存數據將保持和數據庫更強的一致性。值越大的時候，意味著你的 Kong 節點花更少的時間去處理同步任務，從而將更多的資源用來處理請求。

Note：變更將會在 db_update_frequency 秒后在整個集群節點中生效。

2.db_update_propagation (default: 0s)

如果你的數據庫也是集群的并且最終一致性的（比如：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 接口進行管理。