http://qiita.com/daisy1754/items/98a6e6b17d8161eab081
ここにまとまっているんですが、
プチすごいのがFacebook。
一種の発想の転換ってやつだなって思いました。
一般的なのはInstagramあたりのやり方なんでしょう。
また、さらに簡単なのもあって、
phpならuniqidというメソッドを使ったあれやこれやでしょう。
ただ、せきゅりてー的にどうなんとかあり、各社独自のプログラム組んだりするわけです。
これは裏側に、
リアルタイムに独自のロジックでユニークかつランダムな文字列を生成しなければならない
という事情がありまして、負荷とかできるだけかからないように作らなければならないんです。
（これが意外とやっかいちゃん 理由は最下部で）
そこでFacebookの手法。
リリース前とかに一気に３００万件とかかぶらないID作っておけばいんじゃね？
ユーザーいねーから負荷かかってもいーじゃんね。
その発想はなかったわー。
まさにこれを実装しているんですが、
ぱぱっと作って３００万件レコードつくってみたら
ロングフリーズ発生してそのまま帰ってこなかったのはナイショ。
ちなみに、ユニークかつランダムな文字列を負荷がかからないように作るのが
なぜやっかいちゃんかというと、
123abc という文字列から3つランダムに取り出して並べる
って作業をします。
すると、 b2a という文字列が出来ます。
これをテーブルAに登録しておきます。
テーブルA：[b2a]
さて、もう一人ユーザーが増えました。
また例の文字列つくらにゃあかんですね。
さっきのロジックで作りましょう。
3ba という文字列が出来ました。
登録。
テーブルA：[b2a,3ba]
順調、順調。
またまたユーザー登場。
b2a という文字列出来た。
とうろ・・・ できねー！
かぶってますね。
これ回避するために、かぶってるチェックしなきゃあかんすね。
これは二人目のときからどげんかせんといかんやつだったのですが、
二人目が 3ba 作った時に一回テーブルAにアクセスして
3ba かぶってない？大丈夫？
って聞かないといけません。
セーフならそのままいっちゃってー
アウトならもっかいランダムで作り直すわ。
これが１００万人目とかなったら。。。
イメージできました？
大変そうです。
細かく言えばいろいろあるんですが、
ざっくりこういうことなんでやっぱFacebookの発想おもろいです。
