0

次の単純なフローを実装することに興味があります。
クライアントは、サーバーが保存する単純なメッセージをサーバープロセスに送信します。メッセージには階層構造の IMO がないため、最適な方法は、rdb ではなくファイルに保存することです。
しかし、私が見ているように、2つの選択肢があるので、これを最適化する方法を理解したいと思っています:

  1. サーバーは 200 OK をクライアントに送信し、クライアントが遅延に気付かないようにメッセージを保存します。
  2. サーバーはメッセージを保存してから 200OKを送信しますが、クライアントはファイル I/O のオーバーヘッドに気付きます。

私は (1) のパフォーマンスを好みますが、実際にはメッセージが保存されなかった場合 (さまざまなエラーの場合) に、クライアントがすべて問題ないと考える可能性があります。
それで、nio とメモリ マップされたファイルを使用できるかどうかを考えていました。
しかし、これは mem-mapped ファイルを使用するのに適しているのでしょうか? メモリマップファイルを使用すると、たとえばプロセスがクラッシュした場合にメッセージが保存されることが保証されますか?
私の考えでは、フローは多くのファイルを作成/開いたり閉じたりするので、これはメモリマッピングファイルの良い候補ですか?

4

1 に答える 1

2

サーバーはメッセージを保存してから 200OK を送信しますが、クライアントはファイル I/O のオーバーヘッドに気付きます。

これをテストすることをお勧めします。人間が 10 ミリ秒の遅延に気付くとは思えませんが、小さなメッセージの場合はこれよりも良くなるはずです。

それで、nio とメモリ マップされたファイルを使用できるかどうかを考えていました。

書き込みあたりのオーバーヘッドを最大 5 マイクロ秒削減できるメモリ マッピングを使用します。これはあなたにとって重要ですか？そうでない場合は、最も単純なアプローチに固執します。

メモリマップファイルを使用すると、たとえばプロセスがクラッシュした場合にメッセージが保存されることが保証されますか?

OS がクラッシュしない限り、はい。

私の考えでは、フローは多くのファイルを作成/開いて閉じるので、これはメモリマッピングファイルの良い候補ですか?

ファイルの開閉は、データの書き込みよりも高速でコストがかかる可能性があります。（桁違いに）そのような操作を最小限に抑えることをお勧めします。

私のこのライブラリは面白いと思うかもしれません。https://github.com/peter-lawrey/Java-Chronicle テキストの場合は 1 桁のマイクロ秒単位、小さなバイナリ メッセージの場合はサブマイクロ秒単位でメッセージを永続化できます。

于 2013-09-08T14:14:30.463 に答える