26

Android、iPhone、Second Life のクライアントにサービスを提供するゲーム用のサーバー システムを Scala + Akka で開発しています。このサーバーには、複数のマシンで実行する高可用性が必要な部分があります。これらのサーバーの 1 つが (ハードウェア障害などで) 停止した場合でも、システムは稼働し続ける必要があります。私は、Cassandra の仕組みと同様に、クライアントが接続しようとするマシンのリストを持っていることを望んでいると思います。

これまで Akka で見たマルチノードの例は、高可用性 (少なくともハードウェアに関して) ではなく、スケーラビリティの考え方に重点を置いているように思えます。マルチノードの例には、常に単一障害点があるようです。たとえば、ロード バランサーがありますが、ロード バランサーを備えたマシンの 1 つを再起動する必要がある場合、システムにダウンタイムが発生します。

Akka のこのタイプのハードウェア フォールト トレランスを示す例はありますか? または、これを実現するための良い方法について何か考えはありますか?

これまでのところ、私が思いついた最善の答えは、Erlang OTP のドキュメントを調べて熟考し、Akka で利用可能なビルディング ブロックを使用してシステムを組み立てる方法を見つけようとすることです。

しかし、リソース、例、または複数のマシン間で状態を共有して、そのうちの 1 つがダウンしても実行を継続する方法に関するアイデアがあれば、それらを高く評価します。ここの車輪。複数のノード間で共有状態を自動的に同期するマルチノード STM コンテナーがあるのではないでしょうか? あるいは、これは非常に簡単に作成できるため、ドキュメントではその方法の例をわざわざ示していないのかもしれません。あるいは、私の研究と実験がまだ十分に徹底されていないのかもしれません。どんな考えやアイデアでも大歓迎です。

4

4 に答える 4

5

AkkaSourceHA と負荷管理は、スケーラビリティの非常に重要な側面であり、商用製品の一部として利用できます。

于 2010-09-12T18:13:31.493 に答える
3

RedDwarfとそのフォークDimDwarfがどのように構築されているかを見ることができます。どちらも水平方向にスケーラブルなクラッシュ専用のゲーム アプリ サーバーであり、DimDwarf は部分的に Scala で記述されています (新しいメッセージング機能)。それらのアプローチとアーキテクチャは、ニーズに非常によく一致するはずです:)

于 2010-09-12T09:28:20.793 に答える
3

クライアントに複数の潜在的なホストを既にリストしている場合、それらは効果的にロードバランサーになる可能性があります。

ホスト提案サービスを提供し、接続先のマシンを (現在の負荷などに基づいて) クライアントに推奨すると、クライアントは接続が失敗するまでそのマシンにピン留めできます。

ホスト提案サービスが存在しない場合、クライアントは単純に内部リストからランダムなホストを選択し、接続するまでそれらを試すことができます。

理想的には、初回の起動時に、クライアントはホスト提案サービスに接続し、適切なホストに誘導されるだけでなく、他の潜在的なホストのリストも取得します。このリストは、クライアントが接続するたびに定期的に更新できます。

クライアントの最初の試行でホスト提案サービスがダウンしている場合 (可能性は低いですが...)、クライアントのインストールにホストのリストを事前にデプロイできるため、最初からランダムにホストを選択してすぐに開始できます。 .

ホストのリストは、IP ではなく、実際のホスト名であることを確認してください。これにより、長期的な柔軟性が向上します (つまり、「常に」host1.example.com、host2.example.com ... などがあります。インフラストラクチャを移動し、IP を変更します)。

于 2010-09-11T21:23:34.727 に答える