序文
前回の記事では、エラスティック データベース接続障害の背景を紹介し、HikariCP と Druid 接続プールの検出戦略の関連内容について説明しました。この記事では、もう 1 つの一般的に使用されるオンライン接続プールである DBCP について引き続き調査し、DBCP を使用する場合のベスト プラクティスのエラスティック データベース接続プール探索戦略を実装する方法を紹介します。
DBCP
DBCP には、1.x と 2.x (DBCP2 とも呼ばれます) の 2 つのバージョンがあります。DBCP 2 は Commons Pool 2 に基づいており、1.x バージョンと比較してパフォーマンス、JMX サポート、その他多くの点が向上しています。DBCP 2.x は DBCP 1.x とバイナリ互換性がないため、2.x にアップグレードするユーザーは、Java パッケージ名と Maven 座標が変更されたことに注意する必要があります。
まず、DBCP 検出に関連するパラメーターをリストします。
| パラメータ名 | 説明する | デフォルト |
|---|---|---|
| 初期サイズ | 初期化中に確立された物理接続の数。 | 0 |
| 最小アイドル | 最小アイドル接続: 接続プール内でアイドル状態を維持できる接続の最小数。この数を下回ると、新しい接続が作成されます。0 に設定すると、新しい接続は作成されません。 | 0 |
| マックスアイドル | 最大アイドル接続: 接続プール内でアイドル状態を維持できる接続の最大数。超過したアイドル接続は解放されます。負の数に設定すると、制限はありません。 | 8 |
| maxActive/maxTotal | 最大アクティブ接続数: 接続プールが同時に割り当てることができるアクティブ接続の最大数。この値を超えるリクエストは待機キューに入ります。正以外の数値に設定した場合、制限がないことを意味します (1.x バージョン) maxActive 2.x バージョン maxTotal) | 8 |
| テストオンボロー | プールから接続を削除する前にチェックするかどうかを示します。チェックが失敗した場合は、プールから接続を削除し、別の接続の削除を試みます。 | 真実 |
| テストオンリターン | プールに戻る前に検査するかどうかを指定します。 | 間違い |
| アイドル中のテスト | アイドル接続コレクターによって接続がチェックされるかどうかを示します。検出に失敗した場合、接続はプールから削除されます。 注: true に設定した後に有効にする場合は、validationQuery パラメーターを空でない文字列に設定する必要があります。 | 間違い |
| 時間間の立ち退き実行数ミリス | スレッドが実行する接続を削除する時間間隔 (ミリ秒単位)。正以外の数値に設定すると、アイドル状態の接続コレクター スレッドは実行されません。 | -1 |
| 検証クエリ | 接続が有効かどうかを確認するために使用される SQL にはクエリ ステートメントが必要です。 | 1を選択してください |
| validationQueryTimeout | 単位: 秒、接続が有効かどうかを検出するためのタイムアウト。基礎となるメソッドは、jdbc Statement オブジェクトの void setQueryTimeout(int Seconds) メソッドを呼び出します。 | |
| minEvictableIdleTimeMills | 接続が削除されるまでに、プール内でアイドル状態が維持される最小時間。 | 30分 |
| ソフト最小エビクタブルアイドル時間ミリス | minEvictableIdleTimeMillis と比較すると、このパラメーターは minIdle によって制限されており、この値に達すると、minIdle を超える接続数のみが削除されます。 | -1 |
| エビクション実行ごとのテスト数 | アイドル接続コレクター スレッドが実行されるたびにチェックされる接続の数。 | 3 |
Druid のプローブ設定と比較すると、パラメータ名や機能の多くは似ていますが、詳細やデフォルト値に違いがあります。たとえば、testwhileIdle パラメーターは、接続を申請するときにライブ検出を有効にするかどうかを決定するために Druid で使用されます。このパラメーターは、timeBetweenEvictionRunsMillis パラメーター値より大きくなければなりません。DBCP では、このパラメータは接続の破棄時に判定され、オンになっている場合は、Druid の keepAlive パラメータと同様に直接検証されます。どちらの接続プールでも、アイドル状態の接続を削除する時間間隔は、timeBetweenEvictionRunsMillis パラメーターによって制御されます。また、testOnBorrow パラメータの機能は同じですが、デフォルト値が異なります。
さらに、DBCP はエビクション スレッドの numTestsPerEvictionRun パラメータにも影響されます。このパラメータは、エビクション スレッドが実行されるたびにエビクションされる接続の数を指します。プール内のすべての接続は一度にチェックされません。また、DBCP の minEvictableIdleTimeMillis は Druid とは異なり、タイムアウトによって排除される接続の数は minidle によって制御されません。
次の図は、DBCP1.4.0 のエビクション接続スレッドのソース コードです: org.apache.commons.pool.impl.GenericObjectPool#evict
ソース コードを見ると、削除された接続の数が getNumTests から取得されていることがわかります。getNumTests は、接続プールの既存のサイズと numTestsPerEvictionRun の最小値を返します。エビクション プロセスの最初のステップでは、まずアイドル時間が minEvictableIdleTimeMillis を超えているかどうかを判断します。超えていない場合は、softMinEvictableIdleTimeMillis がタイムアウトしたかどうか、および既存の接続が minIdle を超えているかどうかを判断します。3 番目のステップは、testwhileIdle の構成がいつ変更されるかを判断することです。 true の場合、接続は上記でリサイクルされません。4 番目のステップでは、この接続を調べます。
概要: DBCP は、さまざまなバージョンで活性状態の検出にほとんど変更がありません。一般に、接続数をエビクトするときに、testwhileIdle を使用して活性状態を検出できます。エビクション スレッドの実行間隔は、timeBetweenEvictionRunsMillis パラメータの値です。さらに、numTestsPerEvictionRunパラメータは各エビクション スレッドの値です。したがって、これら 2 つのパラメータ設定を使用して 10 分以内にプール内のすべての接続 (最大値は maxActive/maxTotal) を検出する限り、JED の接続失敗を効果的に回避できます。ゲートウェイ。
一般に、DBCP では、さまざまなバージョンのライブ探索の実装にほとんど変更がありません。通常、接続を削除するときに testwhileIdle パラメーターを使用して接続をテストできます。エビクション スレッドの実行間隔は timeBetweenEvictionRunsMillis パラメータによって制御され、numTestsPerEvictionRun パラメータによってエビクション スレッドが毎回処理できる接続数が決まります。numTestsPerEvictionRun の構成値は maxActive/maxTotal と一致し、すべての接続がアクティブであることを確認し、障害が発生したゲートウェイとの接続を取得しないようにするために、timeBetweenEvictionRunsMillis を 10 分未満に構成することをお勧めします。
さらに、アプリケーションが DBCP を使用する場合、デフォルトで testOnBorrow パラメータをオンにすると、通常、無効な接続の取得を効果的に回避できますが、Druid はデフォルトで testOnBorrow パラメータをオンにしません。アプリケーションは、testOnBorrow パラメーターを有効にするかどうかを独自に評価できます。testOnBorrow パラメータをオンにすると、各接続を取得する前に接続検証が実行され、少量のパフォーマンスが消費されますが、無効な接続は時間内に破棄され、新しい接続が再確立されるため、JED ゲートウェイ障害が発生した場合のアプリケーション エラーを効果的に回避できます。そして再起動。
JED 構成テンプレート:
DBCP1.4
<propertyname="minIdle"value="5"/>
<propertyname="maxActive"value="10"/>
<propertyname="testWhileIdle"value="true"/>
<propertyname="validationQuery"value="SELECT 1"/>
<propertyname="timeBetweenEvictionRunsMillis"value="300000"/>
<propertyname="numTestsPerEvictionRun"value="10"/>
DBCP2.2.0
<propertyname="minIdle"value="5"/>
<propertyname="maxTotal"value="10"/>
<propertyname="testWhileIdle"value="true"/>
<propertyname="validationQuery"value="SELECT 1"/>
<propertyname="timeBetweenEvictionRunsMillis"value="300000"/>
<propertyname="numTestsPerEvictionRun"value="10"/>
DBCP2.1.1
2.2.0と同じ
要約する
この記事では、JED のゲートウェイ タイムアウト エラーを背景として一般的なデータベース接続プールを調査し、接続プールの活性検出に関連するパラメーターと検出ロジックを紹介します。この記事の内容を通じて、読者はさまざまな接続プールのアクティビティ検出の内容を理解し、さまざまなパラメーターに従って接続プールを設定して、アプリケーションがゲートウェイによって接続を閉じられるのを効果的に防ぐことができます。この記事では、JED データベース内の接続プール構成テンプレートを提供します。読者は、アプリケーションのニーズに応じてこのテンプレートを調整できます。
中学生がコンパイルした Windows 12 Deepin-IDE の Web 版が正式公開 「真の独自開発」として知られる QQ が「3 端末同時アップデート」を実現、基盤となる NT アーキテクチャは Electron QQをベースにLinux、3.2.0を正式リリース 「紅蒙の父」王成陸 : 紅蒙PC版システムは来年立ち上げ ChatGPTに挑戦 国産AI大型モデル8製品 GitUI v0.24.0をリリース GitのUbuntu 23.10のデフォルト壁紙Rustで書かれた端末が 明らかに 迷路の中の「Tauren」 JetBrainsが 中国で WebStorm 2023.3ロードマップを発表Human Java Ecosystem、Solon v2.5.3リリース著者: JD Retail 王 礼新
出典: JD Cloud 開発者コミュニティによる転載。出典を明記してください