クラスタ詳細-Kongゲートウェイを遊ぶ

クラスタを使用すると、システムを水平に拡張し、より多くのマシンを追加することで、より多くの受信要求を処理できます.同じデータベースを指すため、同じ構成が共有されます.同じデータストレージを指すKongノードは、同じクラスタの一部になります.
Kongクラスタの前に負荷バランサを配置して、異なる使用可能なノードにストリームを割り当てる必要があります.
Kongクラスタは何ができますか?何ができませんか?
Kongクラスタを使用すると、クライアントトラフィックがKongノードにすぐに均等に負荷されるわけではありません.Kongノードの前には、トラフィックを割り当てるための負荷バランサが必要です.1つのクラスタは、これらのノードが同じ構成を共有することを意味します.
パフォーマンス上の理由から、Kongはプロキシリクエスト時に頻繁なデータベース接続を回避し、構成データをローカルにキャッシュします.キャッシュされたエンティティには、サービス、ルーティング、消費者、プラグイン、証明書などが含まれます.これらの値はすべてメモリに含まれているため、1つのノードの管理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)
この3つのパラメータの詳細は、詳細を構成する-Kongゲートウェイを遊ぶ
4.Cassandraを使用する場合
CassandraをKongのデータベースとして使用する場合は、db_update_propagationの値を設定する必要があります.Cassandraの生まれつきの最終的な一貫性のため、Kongノードは更新されていないエンティティを取得するためにキャッシュを早期にクリーンアップしないことを保証します.設定しない場合、Kongは警告メッセージを表示します.
また、cassandra_consistencyの値はQUORUMまたはLOCAL_QUORUMであり、Kongノードキャッシュの値がデータベースからの最新値であることを確認することが望ましい.
管理APIによるキャッシュとのインタラクション
Kongdのキャッシュは、API /cacheを管理することによって管理することができる.
キャッシュ値の取得
リクエストアドレス:/cache/:cache_key要求方法:GET
キャッシュ値のクリーンアップ
リクエストアドレス:/cache/:cache_key要求方法:DELETE
ノードのキャッシュのクリーンアップ
リクエストアドレス:/cacheリクエストメソッド:DELETE
お知らせ
キャッシュAPIは、上記の3つの操作のみをサポートし、上記のバンドcache_keyの操作を使用する場合は、まずcache_keyの値を知る必要があります.通常、デバッグ環境では、クリーンアップを直接使用してキャッシュしないでください.生産環境は、もちろん使用禁止で、kongのタイミングタスクに任せます.
シャトル:オープンソースAPIゲートウェイシステム(Kongチュートリアル)に精通