1

それぞれがイベントのストリームを持つ N 個のデータ ソースを考えてみましょう

Event{
    long id;
    Object data;
}

イベントは更新済み、新規などにまたがる可能性があるため、1 つのストリーム内のイベントの一部は同じ ID を持つ場合があります。したがって、次の 2 つのストリームを確認できます。

<1, 2, 3, 1, 5, 2>
<3, 3, 4, 5, 4>

これらを 1 つのストリームに結合したいと思います。各注文 ID は確実に一意になります。

簡単な方法は、長い代わりに文字列を使用してソース番号を追加し、次のような sth を生成することです。

<"1 - 1", "1 - 2", "1 - 3", "2-3", "2-3" ... >

より多くのメモリ coimpact 方法/より良いアプローチはありますか?

4

2 に答える 2

1

あなたの String ソリューションは問題なく、実際には非常に一般的です。よりコンパクトにしたい場合は、整数のタプルを使用することをお勧めします。

分散システムで使用されるもう 1 つの一般的な方法は、範囲割り当てを使用することです。中央 (シングルトン) サーバーを使用して、各クライアントがその ID に名前を付けることができる範囲を割り当てます。このようなサーバーは、たとえば、範囲 0 ～ 99 を client1 に、100 ～ 199 を client2 などに割り当てることができます。クライアントが割り当てられた範囲を使い果たすと、サーバーに再度接続して新しい範囲を割り当てます。

于 2012-11-22T15:39:37.387 に答える
0

ストリーム/イベント番号の範囲に応じて、2 つの数値を 1 つの int または long に結合して、ストリーム番号を最上位ビットに配置し、イベント番号を最下位ビットに配置することができます。例えば：

public static int getCombinedNo(int streamNo, int eventNo) {
    if (streamNo >= (1 << 16))
      throw new IllegalArgumentException("Stream no too big");
    if (eventNo >= (1 << 16))
      throw new IllegalArgumentException("Event no too big");
    return (streamNo << 16) | eventNo;
}

これは、言及したタイプの典型的な文字列の（たとえば）50バイトの順序ではなく、intごとに4バイトのみを使用します。(この場合、ストリームもイベント番号も 65535 を超えないことも想定しています。)

しかし、あなたの文字列ソリューションも素晴らしく明確です。イベントごとに余分な 50 バイトを割くことができないほどメモリが不足しているのでしょうか。

于 2012-11-22T16:26:40.040 に答える