5

私はJavaで金融アプリケーションに取り組んでおり、並行性を正しく取得するのは苦痛です。Erlangとアクターモデルは大規模な並行アプリケーションに適しているはずですが、Javaでそれを行う方法がわかりません。Jetlang、FunctionalJava、kilimなどのライブラリがあることは知っていますが、それらは通常、単純な例を超えるものではありません。

市場データフィード、注文/取引フィードからいくつかの数値を計算し、このデータの派生物を「出力」するなど、3つまたは4つの異なるイベントを処理する必要があるとします。ほとんどの場合、これらのイベントまたはデータストリームは順番に処理する必要があります(少なくともいくつかのキーに関しては...たとえば、特定のシンボルのすべての順序を順番に処理する必要がありますが、並行して処理する必要があります)無関係な記号に関して)

状態を変更するメソッドを使用して、通常のJavaオブジェクトを作成します。これらのメソッドに直接状態を変更させるのではなく、パラメーターを(コマンドオブジェクトに変換して)fifoキュー(erlangのメールボックス)と、そのキューを処理するreact()メソッドに配置します。このように、すべての更新は単一のキューを通過する必要があり、react()メソッドは一度に1つの更新にのみアクセスできます。理論的には、これにより、このメソッドをロックまたは同期する必要がなくなります。

ただし、このキューは基本的にプロデューサー/コンシューマーキューであり、ブロッキングキューであることを意味します。ブロッキングはスケーラビリティにとって非常に悪いです。また、単一のキューがあるということは、(異なるタイプの)すべての更新コマンドオブジェクトが(Objectのような)過度に一般的なスーパータイプでキューから出てくることを意味し、それらを正しいタイプにキャストして、react()に処理させる必要があります。

このアクター化されたオブジェクトが出力を生成し、別のそのようなオブジェクトによって消費されると、私は同じプロセスを実行します。言い換えれば、プログラミングモデルを、結果を返すメソッドを使用するオブジェクト指向から、すべてのメソッドが非同期になる悪夢を渡すある種の継続に変更しました。

これにどのようにアプローチできるかについてのアイデアはありますか?

4

6 に答える 6

5

最近では、 akkaはScalaにアクターフレームワークを提供し、Erlangに基づいています。

于 2011-06-25T10:30:45.140 に答える
3

最近登場した優れたActorsライブラリの1つを使用してください。Alex Millerは、俳優に関するJavaworldの優れた2部構成の作品を書きました。

私も個人的にはActor'sGuildがとても好きです

于 2009-04-27T08:28:35.167 に答える
2

また、Scalaのアクター(一種のJavaライブラリーと見なすことができます)を調べたい場合もあります。たとえば、次を参照してください。忙しいJava開発者向けScalaガイド:Scalaの並行性について詳しく説明します。

于 2009-04-27T08:55:21.140 に答える
0

また、 esperも確認することをお勧めします。これは、アクターフレームワークの上に構築する一般化されたイベント処理システムのように、言及されているアクターフレームワークほど低レベルではありません。非常に成熟していて完全であり、金融​​取引における複合イベント処理用に開発されたと思います。

于 2011-12-27T01:45:02.953 に答える
0

Kontraktorは、Java8用に設計された新しいアクターライブラリです。https://github.com/RuedigerMoeller/kontraktor

于 2015-07-30T23:51:41.970 に答える
0

別のオプション、つまりNettyLMAX Disruptorを検討できます。どちらも、純粋なJavaで記述されています。Nettyは、保守可能な高性能プロトコルサーバーおよびクライアントを迅速に開発するための非同期イベント駆動型ネットワークアプリケーションフレームワークです。

ここに画像の説明を入力してください

ディスラプターとは何ですか?

LMAXは、世界最速の取引プラットフォームになることを目指しています。明らかに、これを実現するには、Javaプラットフォームで非常に低レイテンシと高スループットを実現するために特別なことを行う必要がありました。パフォーマンステストでは、システムのステージ間でデータを渡すためにキューを使用すると遅延が発生することが示されたため、この領域の最適化に重点を置きました。

ディスラプターは、私たちの調査とテストの結果です。CPUレベルでのキャッシュミスと、カーネルアービトレーションを必要とするロックはどちらも非常にコストがかかることがわかったため、実行中のハードウェアに「機械的な共感」を持ち、ロックフリーのフレームワークを作成しました...

(これはhttps://lmax-exchange.github.io/disruptor/から取得)

于 2015-07-31T00:14:25.307 に答える