1

私たちは現在、今後数週間で稼働する hazelcast を準備しています。まだ 1 つ大きな問題が残っています。これは、OP 部門を悩ませており、修正できない場合はショー ストッパーになる可能性があります。

高可用性の支払いアプリケーションを維持しているため、クラスターが利用できない場合に備えて生き残る必要があります。理由は次のとおりです。

  1. 誰かが hazelcast 構成を台無しにし、OOM ができるまでクラスター上のマップが増加しました (これはテスト システムにありました)。
  2. クラスターへの接続を一時的に切断するネットワーク カード/ハードウェアに問題があります。
  3. OP担当者はファイアウォールを再構成し、必要なポートを誤ってブロックしました.
  4. ことなど

既存の適切な解決策を見つけるのに時間を費やしましたが、これまでの唯一の解決策はバックアップ サーバーの数を増やすことでした。もちろん、これでは問題は解決しません。

現在のテスト中、アプリケーションは完全に動作を停止しました。これは、特定の再試行後にクライアントがクラスターから切断され、休止状態の第 2 レベルのキャッシュが機能しなくなったためです。エコシステム全体で hazelcast を使用しているため、これにより 40 の Java クライアントがほぼ瞬時に停止します。

したがって、クラスターがダウンしているときに、アプリケーションがもちろんより遅い方法で動作していることをどのように達成できるのだろうか. 私たちの現在のアプローチは、ehcache ローカル キャッシュに切り替えることですが、その問題にも hazelcast ソリューションが必要だと思いますか?

4

1 に答える 1

2

もし私があなたなら、LocalSessionFactoryBean を使用し、 Hazelcastサーバーがダウンしている場合にHazelcastまたは NoCachingRegionFactory への呼び出しを委任できる Spring Bean にcacheRegionFactoryを設定します。

Hibernate は Cache 実装が常に利用可能であると想定しているため、これは望ましいことです。そのため、実行時にキャッシュ領域のルーティングを決定できる独自の CacheRegion プロキシを提供する必要があります。

于 2015-01-09T13:57:18.407 に答える