1C 向けに高負荷のスケーラブルなサービスを作成した方法と理由: Enterprise: Java、PostgreSQL、Hazelcast

この記事では、開発の方法と理由について説明します。 インタラクションシステム – クライアント アプリケーションと 1C:Enterprise サーバーの間で情報を転送するメカニズム - タスクの設定からアーキテクチャと実装の詳細を検討するまで。

インタラクション システム (以下、SV と呼びます) は、配信が保証された分散型の耐障害性メッセージング システムです。 SV は、高いスケーラビリティを備えた高負荷サービスとして設計されており、オンライン サービス (1C が提供) としても、独自のサーバー施設に導入できる量産製品としても利用できます。

SV は分散ストレージを使用します ハシバミ そして検索エンジン Elasticsearch。 また、Java と PostgreSQL を水平方向にスケーリングする方法についても説明します。

問題の定式化

インタラクション システムを作成した理由を明確にするために、1C でのビジネス アプリケーションの開発がどのように行われるかについて少し説明します。

まず、私たちが何をしているのかまだ知らない人のために、私たちについて少し説明します :) 私たちは 1C:Enterprise テクノロジー プラットフォームを作成しています。 このプラットフォームには、ビジネス アプリケーション開発ツールと、ビジネス アプリケーションをクロスプラットフォーム環境で実行できるランタイムが含まれています。

クライアントサーバー開発パラダイム

1C:Enterprise で作成された業務アプリケーションは XNUMX つのレベルで動作します クライアントサーバー 「DBMS – アプリケーションサーバー – クライアント」というアーキテクチャ。 に書かれたアプリケーションコード 内蔵1C言語、アプリケーションサーバーまたはクライアントで実行できます。 データベースの読み取りと書き込みだけでなく、アプリケーション オブジェクト (ディレクトリ、ドキュメントなど) のすべての作業はサーバー上でのみ実行されます。 フォームとコマンド インターフェイスの機能もサーバー上に実装されます。 クライアントは、フォームの受信、オープン、表示、ユーザーとの「通信」（警告、質問など）、迅速な応答が必要なフォームでの小さな計算（たとえば、価格に数量を掛けるなど）、ローカル ファイルの操作を実行します。機器を使った作業。

アプリケーション コードでは、プロシージャと関数のヘッダーは、&AtClient / &AtServer ディレクティブ (英語版では &AtClient / &AtServer) を使用して、コードが実行される場所を明示的に示す必要があります。 1C 開発者は、ディレクティブは実際には次のとおりであると言って私を訂正するでしょう。 больше、しかし私たちにとって、これは今は重要ではありません。

クライアント コードからサーバー コードを呼び出すことはできますが、サーバー コードからクライアント コードを呼び出すことはできません。 これは、さまざまな理由から私たちが設けた基本的な制限です。 特に、サーバー コードは、クライアントまたはサーバーのどこから呼び出されても同じ方法で実行されるように記述する必要があるためです。 また、別のサーバー コードからサーバー コードを呼び出す場合、クライアント自体は存在しません。 また、サーバー コードの実行中に、そのコードを呼び出したクライアントが閉じてアプリケーションを終了する可能性があり、サーバーには呼び出し先が存在しなくなります。

ボタンのクリックを処理するコード: クライアントからのサーバー プロシージャの呼び出しは機能しますが、サーバーからのクライアント プロシージャの呼び出しは機能しません。

これは、サーバーからクライアント アプリケーションに何らかのメッセージを送信したい場合、たとえば、「長時間実行される」レポートの生成が完了し、レポートを表示できるようにしたい場合、そのようなメソッドがないことを意味します。 たとえば、クライアント コードからサーバーを定期的にポーリングするなどのトリックを使用する必要があります。 ただし、このアプローチではシステムに不要な呼び出しがロードされるため、一般にあまり洗練されたものとは言えません。

また、電話がかかってきたときなどにもニーズがあります。 SIP- 電話をかけるときに、これについてクライアント アプリケーションに通知します。これにより、発信者の番号を使用して相手先データベース内で番号を検索し、発信者の相手先に関するユーザー情報を表示できるようになります。 または、たとえば、注文が倉庫に到着したら、そのことを顧客のクライアント アプリケーションに通知します。 一般に、このようなメカニズムが役立つ場合は多くあります。

制作自体が

メッセージングメカニズムを作成します。 高速かつ信頼性が高く、配信が保証されており、メッセージを柔軟に検索できます。 このメカニズムに基づいて、1C アプリケーション内で実行されるメッセンジャー (メッセージ、ビデオ通話) を実装します。

水平方向に拡張できるようにシステムを設計します。 増加する負荷はノード数を増やすことでカバーする必要があります。

具現化

私たちは、SV のサーバー部分を 1C:Enterprise プラットフォームに直接統合するのではなく、別の製品として実装し、その API を 1C アプリケーション ソリューションのコードから呼び出すことができるようにすることにしました。 これにはさまざまな理由がありましたが、主な理由は、異なる 1C アプリケーション間 (たとえば、Trade Management と Accounting の間) でメッセージを交換できるようにしたいということでした。 異なる 1C アプリケーションは、異なるバージョンの 1C:Enterprise プラットフォームで実行したり、異なるサーバーに配置したりできます。 このような状況では、SV を 1C 設備の「側」に配置される別個の製品として実装することが最適なソリューションです。

そこでSVを別製品として作ることにしました。 小規模企業には、サーバーのローカル インストールと構成に関連する諸経費を回避するために、クラウド (wss://1cdialog.com) にインストールした CB サーバーを使用することをお勧めします。 大規模なクライアントは、自社の施設に独自の CB サーバーを設置することをお勧めします。 当社のクラウド SaaS 製品でも同様のアプローチを使用しました 1cフレッシュ – 量産製品としてお客様先へ設置する製品として生産され、当社のクラウドにも展開されます。 https://1cfresh.com/.

アプリケーション

負荷とフォールト トレランスを分散するために、XNUMX つの Java アプリケーションではなく、複数の Java アプリケーションをデプロイし、その前にロード バランサーを置きます。 ノードからノードへメッセージを転送する必要がある場合は、Hazelcast でパブリッシュ/サブスクライブを使用します。

クライアントとサーバー間の通信は WebSocket 経由で行われます。 リアルタイム システムに最適です。

分散キャッシュ

Redis、Hazelcast、Ehcache の中から選択しました。 2015年です。 Redis は新しいクラスターをリリースしたばかりですが (新しすぎて怖い)、多くの制限のある Sentinel があります。 Ehcache はクラスターに組み立てる方法を知りません (この機能は後で登場しました)。 Hazelcast 3.4 で試してみることにしました。
Hazelcast は、箱から出してすぐにクラスターに組み立てられます。 シングル ノード モードでは、あまり役に立たず、キャッシュとしてのみ使用できます。データをディスクにダンプする方法がわからないため、唯一のノードを失うとデータが失われます。 複数の Hazelcast をデプロイし、その間で重要なデータをバックアップします。 キャッシュはバックアップしません。気にしません。

私たちにとって、Hazelcast は次のとおりです。

• ユーザーセッションのストレージ。 毎回セッションのためにデータベースにアクセスすると時間がかかるため、すべてのセッションを Hazelcast に入れます。
• キャッシュ。 ユーザー プロファイルを探している場合は、キャッシュを確認してください。 新しいメッセージを作成しました - キャッシュに入れました。
• アプリケーション インスタンス間の通信に関するトピック。 ノードはイベントを生成し、Hazelcast トピックに配置します。 このトピックにサブスクライブしている他のアプリケーション ノードは、イベントを受信して​​処理します。
• クラスターロック。 たとえば、一意のキーを使用してディスカッションを作成します (1C データベース内のシングルトン ディスカッション)。

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

チャンネルがないことを確認しました。 私たちはロックを取得し、再度確認して、作成しました。 ロックを取得した後にロックをチェックしないと、その時点で別のスレッドもチェックされ、同じディスカッションを作成しようとする可能性がありますが、そのディスカッションはすでに存在します。 同期または通常の Java ロックを使用してロックすることはできません。 データベース経由 - 遅いのでデータベースにとっては残念ですが、Hazelcast 経由 - それが必要です。

DBMS の選択

私たちは、PostgreSQL を使用し、この DBMS の開発者と協力して成功した広範な経験を持っています。

PostgreSQL クラスターを使用するのは簡単ではありません。 XL, XC, シタス, しかし一般に、これらはすぐに拡張できる NoSQL ではありません。 私たちは NoSQL をメイン ストレージとして考慮しませんでした。これまで扱ったことのなかった Hazelcast を採用するだけで十分でした。

リレーショナル データベースを拡張する必要がある場合、それは次のことを意味します。 シャーディング。 ご存知のとおり、シャーディングではデータベースを個別の部分に分割し、それぞれを個別のサーバーに配置できるようにします。

シャーディングの最初のバージョンでは、アプリケーションの各テーブルをさまざまなサーバーにさまざまな割合で分散できることが想定されていました。 サーバー A には大量のメッセージがあります。お願いします、このテーブルの一部をサーバー B に移動しましょう。この決定は単に時期尚早な最適化を懸念するものであったため、マルチテナントのアプローチに限定することにしました。

たとえば、Web サイトでマルチテナントについて読むことができます。 Citusデータ.

SV にはアプリケーションとサブスクライバの概念があります。 アプリケーションは、ERP や会計などのビジネス アプリケーションとそのユーザーおよびビジネス データの特定のインストールです。 サブスクライバは、その代理としてアプリケーションが SV サーバーに登録される組織または個人です。 サブスクライバは複数のアプリケーションを登録でき、これらのアプリケーションは相互にメッセージを交換できます。 加入者はシステムのテナントになりました。 複数の加入者からのメッセージを XNUMX つの物理データベースに配置できます。 サブスクライバが大量のトラフィックを生成し始めていることがわかった場合、それを別の物理データベース (または別のデータベース サーバー) に移動します。

すべての加入者データベースの場所に関する情報を含むルーティング テーブルが保存されているメイン データベースがあります。

メイン データベースがボトルネックになるのを防ぐために、ルーティング テーブル (およびその他の頻繁に必要なデータ) をキャッシュに保持します。

サブスクライバのデータベースの速度が低下し始めた場合、データベースを内部のパーティションに分割します。 私たちが使用する他のプロジェクトでは pg_パスマン.

ユーザー メッセージを失うことは好ましくないため、データベースはレプリカで維持されています。 同期レプリカと非同期レプリカを組み合わせることで、メイン データベースが失われた場合に備えることができます。 メッセージ損失は、プライマリ データベースとその同期レプリカに同時に障害が発生した場合にのみ発生します。

同期レプリカが失われると、非同期レプリカが同期になります。
メイン データベースが失われると、同期レプリカがメイン データベースになり、非同期レプリカが同期レプリカになります。

検索用の Elasticsearch

とりわけ、SV はメッセンジャーでもあるため、不正確な一致を使用して、形態を考慮した、高速で便利かつ柔軟な検索が必要です。 私たちは車輪の再発明は行わず、ライブラリに基づいて作成された無料の検索エンジン Elasticsearch を使用することにしました。 ルセン。 また、アプリケーション ノードに障害が発生した場合の問題を排除するために、Elasticsearch をクラスター (マスター – データ – データ) にデプロイします。

github で見つけました ロシア語形態学プラグイン Elasticsearch 用に作成して使用します。 Elasticsearch インデックスには、単語のルート (プラグインが決定する) と N-gram が保存されます。 ユーザーが検索するテキストを入力すると、入力されたテキストが N グラムの中から検索されます。 インデックスに保存されると、単語「texts」は次の N グラムに分割されます。

[それら、テク、テックス、テキスト、テキスト、ek、ex、ext、テキスト、ks、kst、ksty、st、sty、あなた]、

そして「テキスト」という言葉の語源も保存されます。 この方法では、単語の先頭、中間、末尾を検索できます。

大局

記事の冒頭の図を繰り返しますが、説明が付いています。

• インターネット上に公開されたバランサー。 nginx がありますが、どれでも構いません。
• Java アプリケーション インスタンスは、Hazelcast を介して相互に通信します。
• 使用する Web ソケットを操作するには ネッティー.
• Java アプリケーションは Java 8 で書かれており、バンドルで構成されています。 OSGi。 計画には、Java 10 への移行とモジュールへの移行が含まれます。

開発とテスト

SV の開発とテストの過程で、私たちは使用している製品の多くの興味深い機能に気づきました。

負荷テストとメモリリーク

各 SV リリースのリリースには負荷テストが含まれます。 次の場合に成功します。

• テストは数日間機能し、サービス障害は発生しませんでした
• キー操作の応答時間は快適なしきい値を超えませんでした
• 前バージョンと比較したパフォーマンスの低下は 10% 未満

テスト データベースにデータを入力します。これを行うために、運用サーバーから最もアクティブなサブスクライバーに関する情報を受け取り、その数値を 5 (メッセージ、ディスカッション、ユーザーの数) で乗算し、その方法でテストします。

インタラクション システムの負荷テストは、次の XNUMX つの構成で実行します。

1. ストレステスト
2. 接続のみ
3. 購読者登録

ストレス テスト中、数百のスレッドが起動され、メッセージの書き込み、ディスカッションの作成、メッセージのリストの受信など、停止することなくシステムがロードされます。 通常のユーザーのアクション (未読メッセージのリストを取得する、誰かに書き込む) とソフトウェア ソリューション (異なる構成のパッケージを送信する、アラートを処理する) をシミュレートします。

たとえば、ストレス テストの一部は次のようになります。

• ユーザーのログイン
  • 未読のディスカッションをリクエストします
  • 50% の確率でメッセージを読む
  • 50% の確率でテキストメッセージを送信する
  • 次のユーザー:
    • 20% の確率で新しいディスカッションが作成される
    • ディスカッションのいずれかをランダムに選択します
    • 中に入ります
    • リクエストメッセージ、ユーザープロファイル
    • このディスカッションからランダムなユーザーに宛てた XNUMX つのメッセージを作成します
    • ディスカッションを終了します
    • 20回繰り返します
    • ログアウトし、スクリプトの先頭に戻ります

  • チャットボットがシステムに侵入します (アプリケーション コードからメッセージングをエミュレートします)
    • 50% の確率でデータ交換用の新しいチャネルを作成する (特別な議論)
    • 50% の確率で既存のチャネルのいずれかにメッセージを書き込む

「接続のみ」シナリオが登場したのには理由があります。 ユーザーがシステムに接続しているが、まだ参加していないという状況があります。 各ユーザーは朝 09 時にコンピューターの電源を入れ、サーバーへの接続を確立し、沈黙したままになります。 こいつらは危険で、たくさんいます。彼らが持っているパッケージは PING/PONG だけですが、サーバーへの接続を維持します (接続を維持することはできません。新しいメッセージがあったらどうしますか)。 このテストでは、多数のそのようなユーザーが 00 分以内にシステムにログインしようとする状況を再現します。 これはストレステストに似ていますが、その焦点はまさにこの最初の入力にあります。そのため、失敗はありません（人はシステムを使用しておらず、すでに落ちています。それより悪いことを考えるのは困難です）。

サブスクライバ登録スクリプトは、最初の起動から開始されます。 ストレステストを実施し、通信中にシステムの速度が低下しないことを確認しました。 しかし、ユーザーがやって来て、タイムアウトのために登録が失敗し始めました。 登録時に使用したのは、 / dev / random、これはシステムのエントロピーに関連します。 サーバーには十分なエントロピーを蓄積する時間がなく、新しい SecureRandom が要求されたときに数十秒間フリーズしました。 この状況から抜け出す方法はたくさんあります。たとえば、安全性の低い /dev/urandom に切り替える、エントロピーを生成する特別なボードをインストールする、事前に乱数を生成してプールに保存するなどです。 プールの問題は一時的に解決されましたが、それ以来、新規加入者を登録するための別のテストを実行しています。

ロードジェネレータとして使用します JMeterの。 WebSocket の操作方法がわからないため、プラグインが必要です。 クエリ「jmeter websocket」の最初の検索結果は次のとおりです。 BlazeMeter の記事、お勧めします Maciej Zaleski によるプラグイン.

そこから始めることにしました。

本格的なテストを開始した直後に、JMeter がメモリ リークを開始したことがわかりました。

このプラグインは別の大きな話で、スターが 176 個あり、github には 132 個のフォークがあります。 作者自身は 2015 年以降この問題にコミットしていません (2015 年に実行しましたが、その時は疑惑は生じませんでした)、メモリ リークに関するいくつかの github の問題、7 件の未完了のプル リクエストがあります。
このプラグインを使用して負荷テストを実行する場合は、次の議論に注意してください。

1. マルチスレッド環境では、通常の LinkedList が使用され、結果は次のようになりました。 NPE 実行時。 これは、ConcurrentLinkedDeque に切り替えるか、同期されたブロックによって解決できます。 私たちは最初のオプションを自分たちで選択しました (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. メモリリーク; 切断時に接続情報が削除されない (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. ストリーミング モード (WebSocket がサンプルの最後に閉じられず、計画の後半で使用される場合) では、応答パターンは機能しません (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

これは github にあるものの XNUMX つです。 我々のしたこと：

1. 取った フォークエリラン・コーガン (@elyrank) – 問題 1 と 3 を修正します
2. 解決された問題 2
3. 桟橋を 9.2.14 から 9.3.12 に更新しました
4. SimpleDateFormat を ThreadLocal にラップしました。 SimpleDateFormat はスレッドセーフではないため、実行時に NPE が発生します
5. 別のメモリ リークを修正しました (切断時に接続が正しく閉じられませんでした)

それでも、それは流れます！

記憶力はXNUMX日ではなくXNUMX日でなくなり始めた。 時間がまったく残っていなかったため、スレッドの数を減らし、エージェントを XNUMX つ立ち上げることにしました。 少なくとも一週間はこれで十分だろう。

XNUMX日が経ちました…

現在、Hazelcast のメモリが不足しています。 ログによると、数日間のテストの後、Hazelcast がメモリ不足について不平を言い始め、しばらくするとクラスターが崩壊し、ノードが XNUMX つずつ停止し続けました。 JVisualVM を hazelcast に接続すると、「ライジング ソー」が表示されました。これは定期的に GC を呼び出しましたが、メモリをクリアできませんでした。

hazelcast 3.4 では、マップ/multiMap (map.destroy()) を削除するときに、メモリが完全に解放されないことが判明しました。

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

このバグは現在 3.5 で修正されていますが、当時は問題でした。 動的な名前を持つ新しい multiMap を作成し、ロジックに従って削除しました。 コードは次のようになりました。

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

評価:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

multiMap はサブスクリプションごとに作成され、不要になった場合は削除されました。 Mapを始めることにしました、キーはサブスクリプションの名前、値はセッション識別子になります (必要に応じて、そこからユーザー識別子を取得できます)。

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

チャートが改善されました。

負荷テストについて他に何を学んだでしょうか?

1. JSR223 は Groovy で記述し、コンパイル キャッシュを含める必要があります。これははるかに高速です。 リンク.
2. Jmeter-Plugins のグラフは標準のものよりも理解しやすいです。 リンク.

Hazelcast の経験について

Hazelcast は私たちにとって新しい製品で、バージョン 3.4.1 から使い始めましたが、現在、本番サーバーはバージョン 3.9.2 を実行しています (この記事の執筆時点での Hazelcast の最新バージョンは 3.10)。

IDの生成

私たちは整数の識別子から始めました。 新しいエンティティに別の Long が必要だと想像してみましょう。 データベース内の順序が適切ではありません。テーブルがシャーディングに関与しています。DB1 にはメッセージ ID=1 があり、DB1 にはメッセージ ID=2 があることがわかります。この ID を Elasticsearch にも Hazelcast にも入れることはできません。ただし、最悪の場合は、1 つのデータベースのデータを 10 つに結合する場合です (たとえば、これらのサブスクライバーには 000 つのデータベースで十分であると判断する場合)。 いくつかの AtomicLong を Hazelcast に追加し、そこにカウンターを保持すると、新しい ID を取得するパフォーマンスは、incrementAndGet に Hazelcast へのリクエストの時間を加えたものになります。 しかし、Hazelcast にはよ​​り最適なもの、FlakeIdGenerator があります。 各クライアントに連絡するとき、最初のクライアントには 10 ～ 001、20 番目には 000 ～ XNUMX などの ID 範囲が与えられます。 これで、クライアントは、発行された範囲が終了するまで、独自に新しい識別子を発行できるようになります。 動作は高速ですが、アプリケーション (および Hazelcast クライアント) を再起動すると、新しいシーケンスが開始されるため、スキップなどが発生します。 さらに、開発者は、ID が整数であるにもかかわらず、非常に一貫性がない理由を実際には理解していません。 すべてを比較検討し、UUID に切り替えました。

ちなみに、Twitter のようになりたい人のために、Snowcast ライブラリがあります。これは Hazelcast の上に Snowflake を実装したものです。 ここで見ることができます:

github.com/noctarius/snowcast
github.com/twitter/スノーフレーク

しかし、私たちはもうそれには手を付けていません。

TransactionalMap.replace

もう XNUMX つの驚き: TransactionalMap.replace が機能しません。 これがテストです:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

getForUpdate を使用して独自の置換を作成する必要がありました。

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

通常のデータ構造だけでなく、そのトランザクション バージョンもテストします。 IMap は動作しますが、TransactionalMap は存在しません。

ダウンタイムなしで新しい JAR を挿入

まず、クラスのオブジェクトを Hazelcast に記録することにしました。 たとえば、Application クラスがあるので、それを保存して読み取りたいとします。 保存：

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

読む：

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

すべてが機能しています。 次に、Hazelcast で次の方法で検索するためのインデックスを構築することにしました。

map.addIndex("subscriberId", false);

そして、新しいエンティティを作成すると、ClassNotFoundException を受け取り始めました。 Hazelcast はインデックスに追加しようとしましたが、私たちのクラスについて何も知らなかったので、このクラスの JAR が提供されることを望んでいました。 それだけですべてうまくいきましたが、クラスターを完全に停止せずに JAR を更新するにはどうすればよいかという新たな問題が発生しました。 Hazelcast は、ノードごとの更新中に新しい JAR を取得しません。 この時点で、インデックス検索なしでも生きていけると判断しました。 結局のところ、Hazelcast を Key-Value ストアとして使用すれば、すべてが機能するのでしょうか? あまり。 ここでも、IMap と TransactionalMap の動作は異なります。 IMap が気にしない場合、TransactionalMap はエラーをスローします。

Iマップ。 5000 個のオブジェクトを書き込み、読み取ります。 すべてが期待されています。

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

ただし、トランザクションでは機能せず、ClassNotFoundException が発生します。

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

3.8 では、ユーザー クラス デプロイメント メカニズムが登場しました。 XNUMX つのマスター ノードを指定し、そのノード上で JAR ファイルを更新できます。

現在、私たちはアプローチを完全に変更しました。私たちはそれを自分たちで JSON にシリアル化し、Hazelcast に保存します。 Hazelcast はクラスの構造を知る必要がないため、ダウンタイムなしで更新できます。 ドメイン オブジェクトのバージョン管理はアプリケーションによって制御されます。 異なるバージョンのアプリケーションが同時に実行される可能性があり、新しいアプリケーションが新しいフィールドを持つオブジェクトを書き込むが、古いアプリケーションがこれらのフィールドをまだ認識していないという状況が発生する可能性があります。 同時に、新しいアプリケーションは、古いアプリケーションによって書き込まれた、新しいフィールドを持たないオブジェクトを読み取ります。 このような状況はアプリケーション内で処理しますが、簡単にするためにフィールドの変更や削除は行わず、新しいフィールドを追加してクラスを拡張するだけです。

高いパフォーマンスを保証する方法

Hazelcast への XNUMX 回の旅行 - 良い、データベースへの XNUMX 回の旅行 - 悪い

データをキャッシュに保存する方が、データベースに保存するよりも常に優れていますが、未使用のレコードを保存することも望ましくありません。 何をキャッシュするかについての決定は、開発の最終段階まで残されます。 新しい機能がコーディングされると、PostgreSQL のすべてのクエリのログ記録がオンになり (log_min_duration_statement が 0 に)、負荷テストが 20 分間実行されます。収集されたログを使用して、pgFouine や pgBadger などのユーティリティで分析レポートを作成できます。 レポートでは、主に低速で頻繁なクエリを探します。 遅いクエリの場合は、実行計画 (EXPLAIN) を構築し、そのようなクエリを高速化できるかどうかを評価します。 同じ入力データに対する頻繁なリクエストはキャッシュにうまく収まります。 クエリを「フラット」に保ち、クエリごとに XNUMX つのテーブルを保持するように努めます。

搾取

オンラインサービスとしてのSVは2017年春に稼働し、単体製品としては2017年XNUMX月にSVがリリースされました（当時はベータ版の状態）。

XNUMX 年以上の運用において、CB オンライン サービスの運用に重大な問題は発生していません。 オンライン サービスを監視するには、 ザビックスから収集してデプロイします 竹.

SV サーバーのディストリビューションは、ネイティブ パッケージ (RPM、DEB、MSI) の形式で提供されます。 さらに、Windows の場合は、サーバー、Hazelcast、および Elasticsearch を XNUMX 台のマシンにインストールする XNUMX つのインストーラーを XNUMX つの EXE 形式で提供します。 当初、このバージョンのインストールを「デモ」バージョンと呼んでいましたが、これが最も一般的な導入オプションであることが明らかになりました。

出所： habr.com