3

私は、1 日あたり最大 5 億リクエストの容量を持つ HTTP サービスを設計しています (複数の独立したマシンによって処理されます)。

リクエストごとに、一意の ID を生成してユーザーに返す必要があります。ID は、10 分間のウィンドウ内で 100% 一意である必要があります。(1 日が推奨されます。グローバルに一意の ID が理想的です。) その ID を生成するためにサーバー間通信は必要ありません。

ばかげた疑似セッションの例:

クライアント: GET /foo

サーバー: コンテンツ タイプ: text/xml

        <ルート>
            <id>ab9d1972-2844-11e0-86b2-000c29544403</id>
            <その他のデータ/>
        </ルート>

この HTTP サービスの前の世代では、UUID を使用していました。

UUID には満足していますが、問題が 1 つあります。それは、長すぎることです。その数の要求では、この余分なサイズは、ログ ファイルのディスク領域の浪費に顕著に現れます。

短いが一意の識別子を作成する最良の方法は何ですか? 物事を価値のあるものにするために、アルゴリズムは UUID の長さの最大半分を生成する必要があると思いますが、1 日中一意である必要があります (10 分はさらに短くする必要があります)。

理想的には、提案されたアルゴリズムは、プレーンな C で正気で軽量な製品品質の実装を備えているでしょう。

更新: 生成された ID は、GET 要求で渡されるときに URI エンコードを必要としません。

4

2 に答える 2

5

各マシンに一意のプレフィックスを付けます。各マシンにカウンターを与えます。ID を生成するには、カウンターをインクリメントし、その値をプレフィックスに追加します。

ID を難読化する場合は、暗号化します。暗号は可逆変換であるため、一意の値に適用すると一意の値が生成されます。

于 2011-01-29T00:21:08.307 に答える
2

いくつかの考え：

  • 1 日あたり 5 億件のリクエスト。本当に？
  • UUID を使用します。
  • 必要に応じて、HTTP を使用せず (オーバーヘッドが大きいため)、UUID をバイナリ形式で転送します。
  • サーバーが本当に一意のIDを返すことを保証するには、一定のバイト数が必要です。
  • UDP を使用するのはどうですか。

とにかく、一体何をしようとしているのですか？

于 2011-01-29T00:20:58.417 に答える