Kong（V1.0.2） Clustering Reference

介紹

Kong集羣容許您經過添加更多的機器來處理更多的傳入請求來水平擴展系統。它們將共享相同的配置，由於它們指向相同的數據庫。指向相同數據存儲的Kong節點將是相同Kong集羣的一部分。

您須要在Kong集羣前面有一個負載均衡器，以便跨可用Kong節點分發流量。

一個Kong集羣能作什麼，不能作什麼

擁有一個Kong集羣並不意味着您的客戶端流量將當即在您的Kong節點之間進行負載均衡。在Kong節點前面仍然須要一個負載均衡器來分配流量。相反，Kong集羣意味着這些節點將共享相同的配置。

出於性能緣由，Kong在代理請求時避免數據庫鏈接，並在內存中緩存數據庫的內容。緩存的實體包括Services, Routes, Consumers, Plugins, Credentials等等……由於這些值在內存中，因此經過其中一個節點的Admin API所作的任何更改都須要傳播到其餘節點。

這個文檔描述了這些緩存的實體是如何失效的，以及如何爲您的用例配置Kong節點，這是介於性能和一致性之間的。

Single node Kong clusters

鏈接到數據庫的單個Kong節點(Cassandra或PostgreSQL)建立一個節點的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

Multiple nodes Kong clusters 多節點Kong集羣

在一個由多個Kong節點組成的集羣中，鏈接到同一數據庫的其餘節點不會當即收到節點A刪除該服務的通知。雖然該服務已不在數據庫中(已被節點A刪除)，但它仍然在節點B的內存中。

全部節點都執行一個週期性的後臺做業，以與其餘節點可能觸發的更改同步。此做業的頻率可經過如下方式配置:

• db_update_frequency (default: 5 seconds)

每一個db_update_frequency秒，全部運行的Kong節點都將輪詢數據庫以獲取任何更新，並在必要時從緩存中清除相關實體。

若是咱們從節點A中刪除一個服務，這個更改在節點B中不會有效，直到節點B進行下一次數據庫輪詢，該輪詢將在數秒後(儘管可能更早)發生db_update_frequency。

這使得Kong集羣最終保持一致。

What is being cached?  緩存的是什麼?

全部的核心實體，如Services, Routes, Plugins, Consumers, Credentials等，都被Kong緩存在內存中，並依賴於經過輪詢機制更新它們的有效性。

此外，Kong還可能cache database丟失。這意味着若是您配置一個沒有插件的服務，Kong將緩存此信息。例子:

在節點A上，咱們添加了一個服務和一個路由:

# node 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" 

(注意，咱們使用/services/example-service/routes做爲快捷方式:咱們原本可使用/routes端點，可是咱們須要將service_id做爲參數傳遞，使用新服務的UUID)。

對節點A和節點B代理端口的請求將緩存此服務，且沒有在其上配置插件:

# node A 

curl http://127.0.0.1:8000/example
HTTP 200 OK
...

# node B 

curl http://127.0.0.2:8000/example
HTTP 200 OK
...

如今，假設咱們經過節點A的管理API向該服務添加一個插件:

# node A 

curl -X POST http://127.0.0.1:8001/services/example-service/plugins \ --data "name=example-plugin" 

因爲此請求是經過節點A的管理API發出的，所以節點A將在本地使其緩存失效，而且在隨後的請求中，它將檢測此API是否配置了插件。

可是，節點B尚未運行數據庫輪詢，而且仍然緩存這個API沒有插件能夠運行的數據。在節點B運行其數據庫輪詢做業以前，狀況將一直如此。

結論:全部CRUD操做都會觸發緩存失效。建立(POST, PUT)將使緩存的數據庫丟失失效，而更新/刪除(PATCH, DELETE)將使緩存的數據庫命中失效。

How to configure database caching?如何配置數據庫緩存?

您能夠在Kong配置文件中配置3個屬性，其中最重要的一個是db_update_frequency，它決定了您的Kong節點在性能和一致性之間的權衡位置。

Kong提供了針對一致性進行調優的默認值，以便讓您在試驗其集羣功能的同時避免「意外」。在準備生產設置時，應該考慮對這些值進行調優，以確保性能約束獲得尊重。

1. db_update_frequency(默認值:5 s)

此值肯定Kong節點輪詢數據庫以查找無效事件的頻率。較低的值意味着輪詢做業將更頻繁地執行，可是您的Kong節點將跟上您所應用的更改。較高的值將意味着Kong節點運行輪詢做業的時間將減小，並將重點放在代理流量上。

注意:意味着對Kong的配置更改在集羣中傳播的時間最長爲db_update_frequency秒。

2. db_update_propagation(默認值:0)

若是數據庫自己最終是一致的(即:Cassandra)，則必須配置此值。這是爲了確保更改有時間在數據庫節點之間傳播。設置好後，從輪詢做業接收無效事件的Kong節點將延遲緩存的清除，以得到db_update_propagation秒。

若是鏈接到最終一致的數據庫的Kong節點沒有延遲事件處理，那麼它能夠清除其緩存，只緩存未更新的值(由於更改尚未在數據庫中傳播)!

您應該將此值設置爲數據庫集羣傳播更改所需時間的估計值。

注意:設置此值時，對Kong的配置更改在集羣中傳播的時間最長爲db_update_frequency + db_update_propagation秒。

3. db_cache_ttl (default: 0s)

Kong緩存數據庫實體(命中和未命中)的時間(以秒爲單位)。這個Time-To-Live值在Kong節點錯過失效事件時起保護做用，以免它在過時數據上運行太長時間。當到達TTL時，將從其緩存中清除該值，並再次緩存下一個數據庫結果。

默認狀況下，沒有數據基於這個TTL無效(默認值是0)，這一般很好:Kong節點依賴於失效事件，這些事件在數據庫存儲級別(Cassandra/PosgreSQL)進行處理。若是您擔憂Kong節點可能由於任何緣由錯過無效事件，您應該設置TTL。不然，節點可能會在緩存中使用過時值運行一段未定義的時間，直到手動清除緩存或從新啓動節點。

4. When using Cassandra

若是使用Cassandra做爲Kong數據庫，則必須將db_update_propagation設置爲非零值。因爲Cassandra的本質最終是一致的，這將確保Kong節點不會過早地使其緩存失效，而只是再次獲取和捕獲一個不最新的實體。若是您在使用Cassandra時沒有配置此值，Kong將顯示一個警告日誌。

此外，您可能但願將cassandra_consistency配置爲QUORUM或LOCAL_QUORUM這樣的值，以確保Kong節點緩存的值是來自數據庫的最新值。

Interacting with the cache via the Admin API（經過管理API與緩存進行交互）

若是出於某種緣由，您但願研究緩存的值，或者手動使Kong緩存的值無效(緩存命中或未命中)，那麼能夠經過管理API /cache端點來實現。

Inspect a cached value

Endpoint

GET /cache/{cache_key}

Response

If a value with that key is cached:

HTTP 200 OK
...
{
    ...
}

Else:

HTTP 404 Not Found

Note: retrieving the cache_key for each entity being cached by Kong is currently an undocumented process. Future versions of the Admin API will make this process easier.

Purge a cached value

Endpoint

DELETE /cache/{cache_key}

Response

HTTP 204 No Content
...

Note: retrieving the cache_key for each entity being cached by Kong is currently an undocumented process. Future versions of the Admin API will make this process easier.

Purge a node’s cache

Endpoint

DELETE /cache

Response

HTTP 204 No Content

Note: be wary of using this endpoint on a warm, production running node. If the node is receiving a lot of traffic, purging its cache at the same time will trigger many requests to your database, and could cause a dog-pile effect.