2

以前は、ここにあるクラスを使用して、userIDをランダムな文字列に変換していました。

彼のブログから：

ランニング：

alphaID(9007199254740989);

'PpQXn7COf'を返します。

alphaID('PpQXn7COf', true);

'9007199254740989'を返します

つまり、ユーザーはwww.mysite.com/user/PpQXn7COfを実行でき、それを通常の整数に変換してmysqlで実行できるようにするという考えでした。

"Select * from Users where userID=".alphaID('PpQXn7COf', true)

今、私はカサンドラと仕事を始めたばかりで、いくつかの代替品を探しています。

  1. www.mysite.com/user/username1ではなくwww.mysite.com/user/PpQXn7COfのようなURLが必要です
  2. 「PpQXn7COf」uuidはできるだけ短くする必要があります。

ここで説明されているTwissandraの例：http ：//www.rackspace.com/cloud/blog/2010/05/12/cassandra-by-example/

それらはいくつかの長いuuidを作成します（それはほぼ100％確実にランダムであるため、非常に長いと思います）。

mysqlでは、自動増加機能を備えたuserID列があったため、alphaID（）関数を使用すると、常に非常に短いランダムな文字列が取得されました。

これを可能な限りクリーンに解決する方法を考えている人はいますか？

編集：

ソーシャルメディアサイトで使用されるため、永続的である必要があります。それはまた私がURLでユーザー名/実名を使用したくない理由です、彼らが必要な場合、ユーザーはグーグルで検出されないままにすることはできません。

簡単なアイデアが浮かびましたが、それがどれほどスケーラブルかわかりません。

<?php
//createUUID() makes +- 14 char string with A-Z a-z 1-0 based on micro/milli/nanoseconds
while(get_count(createUUID()) > 0){//uuid  is unique
  //insert username pass, uuid etc into cassandra
  if($result == "1"){
      header('Location: http://www.mysite.com/usercenter');
  }else{
      echo "error";
  }
}
?>

これがのサイズになったら、twitter/facebookとしましょう。

  1. 許容時間内に実行されますか？
  2. それでも十分な速度で一意のuuidを生成するので、10000ユーザー/秒が登録している場合は混乱しませんか？
4

1 に答える 1

4

自動インクリメントは、堅牢な分散システムには適していません。システム内のすべてのノードが使用可能な場合にのみ一意のIDを割り当てて、一意であることを確認できます。

もちろん、独自の一意のIDジェネレーターを発明することもできますが、インフラストラクチャ内のどこにでも一意のIDが生成されることを確認する必要があります。

たとえば、各ノードは、（適切なロックなどを使用して）インクリメントするだけのファイルを持つことができますが、たとえば、生成アルゴリズムにサーバーIDを含めることによって、ノードが衝突しないようにする必要もあります。

これは運用上重要な場合があります。運用エンジニアは、インフラストラクチャ内のすべてのサーバーが、同じIDを生成しないように設定された独自のIDジェネレーターで正しく構成されていることを確認する必要があります。ただし、それは可能です。

UUIDは間違いなく一意であるため、妥当な代替手段です。

UUIDは128ビットです。1文字あたり6ビット（つまりbase64）を格納すると、22文字が必要になります。これは非常に長いURIです。短くしたい場合は、別の方法で一意のIDを生成する必要があります。

さらに、それはすべて、実際にIDが必要な「一意性」に依存します。IDを数か月後に安全に再利用できる場合は、おそらく60ビット未満で再利用できます（インフラストラクチャ内のサーバーの数と、IDを生成する必要がある頻度によっても異なります）。

を使用しております

  • サーバーID
  • 時間（粒度= 2秒）、ただし数か月後に終了
  • サーバーごとのカウンター（頻繁にラップしますが、2秒以内にはラップしません）

そして、すべてのビットを一緒に貼り付けます。これにより、64ビット未満の長さのIDが生成されますが、必要な期間（この場合は数か月のみ）は一意であることが保証されます。

次の場合、アルゴリズムが誤動作し、重複するIDが生成されます。

  • ノードの1つのシステムクロックは、カウンターがラップするのと同じ時間だけ逆方向に進みます。
  • 当社の運用エンジニアは間違いを犯し、同じサーバーIDを2台のサーバーに割り当てます。
  • 最終的には、約9か月後。
于 2011-04-16T14:03:47.530 に答える