データベース接続プール Druid の使用手順

総合的なパフォーマンス、信頼性、安定性、スケーラビリティ、使いやすさなどの要素に基づいて、最適なデータベース接続プールに置き換えます。

ドルイド:druid-1.0.29

データベースMysql.5.6.17

置き換え対象: C3P0をドルイドに置き換える

交換理由:

1. パフォーマンス面では、hikariCP>druid>tomcat-jdbc>dbcp>c3p0 です。 hikariCP の高パフォーマンスは、ロック競合を最大限に回避することによって実現されます。

2. Druid は、SQL インターセプションなどの機能を含む最も包括的な機能を備えており、比較的包括的な統計データと優れたスケーラビリティを備えています。

3. 総合的なパフォーマンスとスケーラビリティの観点から、JDBC インターフェースの監視と追跡に便利な druid または hikariCP 接続プールの使用を検討できます。

4. prepareStatement キャッシュを有効にすると、パフォーマンスが約 20% 向上します。

psCache は接続専用なので、スレッド競合の問題はありません。pscache を有効にしても、競合によるパフォーマンスの低下は発生しません。

psCache のキーは prepare によって実行される SQL とカタログであり、値は prepareStatement オブジェクトに対応します。キャッシュを有効にすると、主に SQL 解析のオーバーヘッドが削減されます。

5. 3p0 は歴史が長く、コードが非常に複雑なため、メンテナンスが容易ではありません。そして、デッドロックの潜在的なリスクがあります。

6. DruidはSQLとスロークエリのログを出力できる

ドルイドパラメータ

構成パラメータ	デフォルト値	ゲームサーバー設定値	パラメータの説明
初期サイズ	0	4	接続数を初期化する
最小アイドル	0	4	アイドル接続の最小数
最大アクティブ	8	8	同時接続の最大数
最大待機時間	-1L	60000	接続を取得する際の最大待機時間（ミリ秒単位）。 maxWaitを設定した後、デフォルトでは、公平ロックが有効になっているため、同時実行の効率が低下します。必要に応じて、useUnfairLock プロパティを true に設定して不公平なロックを使用できます。
立ち退き実行間の時間（ミリ秒）	60000	60000	アイドル接続を閉じる必要があるかどうかを確認する間隔をミリ秒単位で設定します。破棄スレッドは接続間隔を検出します
最小退避可能アイドル時間ミリ秒	1800000	1800000	プール内の接続の最小生存時間をミリ秒単位で設定します
検証クエリ	ヌル	1を選択	接続が有効かどうかを検出するために使用されるSQL。クエリ文である必要があります。
借りるテスト	間違い	間違い	接続を申請する際、validationQuery を実行して接続が有効かどうかを確認します。この構成を行うとパフォーマンスが低下します。
戻り値テスト	間違い	間違い	接続を返すときに、validationQueryを実行して接続が有効かどうかを確認します。この設定を行うとパフォーマンスが低下します。
アイドル中のテスト	真実	真実	パフォーマンスに影響を与えず、セキュリティを確保するには、これを true に設定することをお勧めします。接続を申請するときに、アイドル時間が timeBetweenEvictionRunsMillis より大きい場合は、validationQuery を実行して接続が有効かどうかを確認します。
プール準備済みステートメント	間違い	真実	false preparedStatement、つまり PSCache をキャッシュするかどうか。 PSCache は、Oracle などのカーソルをサポートするデータベースのパフォーマンスを大幅に向上させます。 MySQL 5.5 未満のバージョンには PSCache 機能がないため、オフにすることをお勧めします。バージョン 5.5 以降には PSCache があり、これを有効にすることをお勧めします。
接続あたりの最大プール準備ステートメントサイズ	10	100	PSCacheを有効にするには、0より大きい値に設定する必要があります。0より大きい値にすると、 poolPreparedStatements は自動的に true への変更をトリガーします。単一の接続には独自のステートメントキャッシュがあるため、maxOpenPreparedStatements は単一の接続用となります。

仕組み:

データベース接続プールは初期化中に initialSize 個の接続を作成し、データベース操作が行われると、接続がプールから取り出されます。プール内で現在使用されている接続数が maxActive に等しい場合、他の操作が接続を解放するのを待って、しばらく待機します。待機時間が maxWait を超えると、エラーが報告されます。現在使用されている接続数が maxActive に達していない場合は、アイドル接続があるかどうかが判断されます。アイドル接続がある場合は、アイドル接続が直接使用されます。アイドル接続がない場合は、新しい接続が確立されます。接続が使用された後、その物理的な接続は閉じられるのではなく、プールに入れられ、他の操作による再利用を待機します。同時に、接続プール内には、現在の接続の合計数が miniIdle 未満であるかどうかを判断するメカニズムがあり、接続数が miniIdle になるように新しいアイドル接続が確立されます。現在の接続プール内の接続が、timeBetweenEvictionRunsMillis 時間アイドル状態になってもまだ使用されない場合は、物理的に閉じられます。一部のデータベース接続にはタイムアウト制限があり (MySQL 接続は 8 時間後に切断されます)、ネットワークの中断などの理由により接続プール接続が無効になることがあります。この場合、testWhileIdle パラメータを true に設定すると、接続プールが定期的に接続の可用性を検出するようになります。使用できない接続は破棄または再構築され、接続プールから取得された Connection オブジェクトは最良の場合に使用可能であることが保証されます。もちろん、絶対的な可用性を保証するために、testOnBorrow を true に設定することもできます (つまり、Connection オブジェクトを取得するときにその可用性をチェックします)。ただし、これによりパフォーマンスに影響が出ます。

SQL 監視を実行する場合は、次のコードを追加できます。

Log4j2Filter は、log4j2 を新しい Log4j2Filter() に変換します。 
log4j2.setResultSetLogEnabled(false); 
log4j2.setStatementSqlPrettyFormat(false); 
log4j2.setStatementExecutableSqlLogEnable(true); 
 
log4j2.setDataSourceLogEnabled(false); 
log4j2.setConnectionLogEnabled(false); 
log4j2.setStatementLogEnabled(false); 
log4j2.setResultSetLogEnabled(false); 
ret.setProxyFilters(Arrays.asList(log4j2));

アイドル検出、接続の作成、放棄された接続のクリーンアップは、これら3つのスレッドによって管理されます。

デーモンスレッド [放棄された接続のクリーンアップスレッド] 
デーモン スレッド [Druid-ConnectionPool-Create-1184124073] 
デーモン スレッド [Druid-ConnectionPool-Destroy-1184124073]

要約する

以上が、データベース接続プール Druid の使用に関するこの記事の内容のすべてです。皆様のお役に立てれば幸いです。興味のある方は、「MySQL Prepare 原則の詳細な説明」およびその他の関連トピックを参照してください。質問がある場合は、いつでもメッセージを残していただければ、編集者がすぐに返信します。

以下もご興味があるかもしれません: