ターン：http://blog.51cto.com/fulin0532/2094114
コードを見ると、雪の結晶のアルゴリズムに遭遇チェックし、ツイッターを分散ID生成アルゴリズムであることが判明し、現在見て、その後、インターネット業界の慣行のいくつかを見つけるために、分散環境でグローバルに一意なIDを生成することができますCtripの米国のプログラムグループは、いくつかのメモを行います。
背景1
複雑な分散システムでは、多くの場合、一意に識別されるデータ及びメッセージの大量を必要とします。金融、支払い、ケータリング、ホテル、猫の目の映画や他の製品、システム、データが成長し、データやニュースデータのサブライブラリーのサブテーブルの一部を識別するための固有のIDの必要性を米国のグループのレビューと同様に、IDデータベースをインクリメント明らかに需要を満たすことができない。特に、このような順序ことを、ライダーは、クーポンもユニークIDのロゴを行うために必要とされています。この時点では、グローバルに一意なIDが必要ですシステムで生成することができます。
ダウン要約、およびID番号そのための要件は何というビジネスシステム？
要件1
1、グローバルに一意な：それは基本的な要件である一意の識別子であるため、あなたは、ID番号が表示され複製することはできません。
2、トレンドがインクリメントされます。ほとんどのRDBMSのデータ構造は、インデックスBツリーのデータを格納するために使用されるので、クラスタ化インデックスで使用するためのMySQLのInnoDBエンジンは、私たちの上に選択された主キーは、注文した書き込み性能の主キーことを確保しようとする必要があります。
図3は、単調に増加する：特定のID、バージョン番号よりも大きいIDを確保する、例えば、取引の特別なニーズは、ソーティングIMメッセージをインクリメントします。
4、情報セキュリティ：IDが連続している場合は、ペンシルベニア州、悪意のあるユーザーがオーダーをダウンロードするには、直接指定したURLに基づいて、行うことは非常に簡単な仕事を取るために、注文番号は、我々が知ることができる一日のために競合し、さらに危険である場合量。そのため、いくつかのシナリオでは、それは、定期的に不規則なIDを必要としないことがあります。
123は、同じ方式が満たすことができない使用して、上記3種類のシーン、3及び4需要または相互に排他的に対応します。
また、ID番号システム生成されたビジネスの独自のID番号の要件、および可用性の要件に加えて、同時にID生成システム障害、全体の米国のグループの有料レビュー、クーポンはクーポンを発行し、他の主要ライダーがすることができない単一のアクションを送信する場合、想像非常に高く、災害をもたらすだろう、実行、。
システムは、IDの概要は、次の操作を行う必要があります生成させる：
グローバルに一意
のサポート高い同時実行は、
特定のプロパティを反映することができ
、信頼性の高い故障のフォールトトレラントシングルポイント
高いパフォーマンスを
平均遅延および遅延TP999は、可能な限り低いこと;
5つのナインの可用性、
高いQPS。
業界のシナリオ1
UUID
32桁の16進数の標準タイプの、5つのセクションに分けハイフン、8-4-4-4-12 36文字例の形態のUUID（汎用一意識別子）：550e8400-e29b-41d4-詳細な仕様は、IETF UUID汎用一意識別子（UUID）URNによって発行されたようa716-446655440000、これまで業界では、5つの方法の合計は、UUIDを生成する名前空間。
長所：
パフォーマンスは非常に高いです：ローカルなしネットワークの消費量を生成しません。
短所：
ストアには容易ではない：UUIDが長すぎる、通常の文字列36の長さとして表現さ16のバイト128は、シーンの多くは適用されません。
安全でない情報：漏洩をもたらすことができるMACアドレス生成アルゴリズムのUUIDベースのMACアドレスは、この抜け穴はメリッサ病×××位置を見つけるために使用されてきました。
IDは、次のような主キーのようになります。特定の環境におけるいくつかの問題は、DBの主キーシーン、UUID非常にNAがあるんです。
①できるだけ短く明確な提案を主キーを持つMySQLの公式は、[4]、長さはUUID 36文字が要件を満たしていないしようとします。
クラスタ化インデックス以外のすべてのインデックスがセカンダリインデックスとして知られています。InnoDB内で、セカンダリインデックスの各レコードには、行の主キー列、ならびに二次インデックスに指定された列を含んでいます。InnoDBは、クラスタ化インデックス内の行を検索するには、この主キー値を使用しています。主キーが長い場合は、セカンダリインデックスは、より多くのスペースを使用するので、短い主キーを持っていることが有利です。
MySQLへの有害な指標②：InnoDBエンジンでデータベースの主キーとして場合は、UUID障害は、位置データが頻繁に変化が真剣にパフォーマンスに影響を与える可能性があります。
クラススノーフレーク実施形態
の実施形態のこの種のは、一般に、名前空間に分割され、64ビットプログラムは、複数のセグメントに分割されているアルゴリズムIDを生成する（UUIDは、より一般的に、それは別々に分析されているためと考えることができる）分離します示すような64ビット雪片のように、機械、時間等をマークするために、それぞれ以下の図（ネットワークからの画像）を表します。
画像
時間が表すことができる41ビット（1Lは、<< 41である）/（1000L 3600 24 * 365）= 69年は、10ビットマシンは、それぞれのマシン1024表すことができます。私たちはIDC部門の必要性を持っている場合は、また、10ビットは、IDCに5ビットを分割することができ、作業に5ビットマシンを指しています。これは32 IDC、機械32を表すことができ、各IDCは、自分のニーズに応じて定義することができることができます。12増分シーケンス番号が2 ^ 12 ID、409.6ワット/秒から約理論的QPSスノーフレークスキーマを表すことができる、この割り当ては確保できる任意のID IDCのいずれか機械生成任意ミリ秒でそれは異なっています。
このアプローチの長所と短所は以下のとおりです。
長所：
シーケンスの高い、低エネルギー自給のミリ秒数、全体のIDがトレンドをインクリメントされます。
システムは、サービス展開、高い安定性と、パフォーマンスのIDが非常に高い生成、サード・パーティのデータベースに依存しません。
ビットビットは、その事業特性に応じて、非常に柔軟に割り当てることができます。
短所：
強い依存のマシンクロック、コールバックはFaが繰り返されたり、サービスが利用できない結果となる場合は、マシン上の時計。
適用例オブジェクトID Mongdb
のMongoDBのObjectID公式文書は、最終的に24の長さとして同定+ 3 4 + 3 + 2を介して、12バイトの「時間エンコーディング+ + PID + INC」によってカウント等スノーフレークすることができます進文字。
データベース生成
MySQLの例と、各時間はMySQLがID番号を取得し、次のSQLを使用して操作を読み取り、書き込み、auto_increment_offset識別auto_increment_increment及び増分を確保するためにフィールドセットを使用。
ベギン;
Tickets64 INTO REPLACE（スタブ）VALUES（ 'A'）;
LAST_INSERT_ID（）を選択。
コミット;
画像
次のようにこのアプローチの長所と短所は以下のとおりです。
長所：
既存のデータベース・システムの機能実現、小型のコスト、DBAプロのメンテナンスで動作するように非常に簡単。
ID番号は単調にインクリメントは、サービスIDのためのいくつかの特別な要件を達成することができます。
短所：
システムが使用できないときに、強い依存性DB、DB異常、それは致命的な問題です。マスターコピーから、例外的な状況でのデータの一貫性を確保することができるが、難しいの可用性を高めるように構成することができます。主な矛盾から切り替えた場合、重複Faを生じ得ます。
MySQLの読み取りおよび書き込みのパフォーマンスを、単一のパフォーマンスのボトルネックで発行されたID番号。
次のようにMySQLのパフォーマンスの問題のために、解決策が利用可能である：分散システムでは、より少数のマシンを展開することができ、各マシンが、異なる初期値とステップサイズとマシンの同じ数を設定します。例えば、2台のマシンがあります。初期設定ステップは、ステップ2、TicketServer1 1（1,3,5,7,9,11 ...）であり、2（2,4,6,8,10 ...）の初期TicketServer2値であります。これは2010年の主キーの生成方法Flickrのチームで、著者は（チケットサーバは：ユニークなプライマリキーの分散を説明する安い上）。以下に示すように、上述した実施形態を達成するために、2つの機械パラメータに対応して設けられ、1 2はTicketServer1番号の後に始まるからインクリメントされ、TicketServer2都度二つのマシンFaを、2番から始まります。
TicketServer1：
自動インクリメントインクリメント= 2
オートインクリメント・オフセット= 1
TicketServer2：
自動インクリメントINCREMENT = 2 -
自動オフセット-INCREMENT = 2
、我々はNマシンを展開すると仮定し、ステップがNに設定する必要があり、それぞれの初期値は、その後だった0,1,2 ... N-1以下に示すように、全体の構造は次のようになります。
画像
このアーキテクチャは、一見、性能のニーズを満たすことができますが、いくつかの欠点があります。
あなたがそれを行うにはどのようにマシンを追加したい場合はそれ以降、そのようなステップのかなりの数の定義と機械テーブルなど、より困難なシステムレベルの拡張？1つのマシンだけFaは機械容量が必要になる。この時、1,2,3,4,5（ステップ1）であることを今仮定します。これを行うことができます。初期値は、最初の数秒以上のマシンよりも小さく設定され、例えば14、ステップ2を設定して、（14時間を送信することは不可能最初の膨張を仮定して）、次いで、これを番号が偶数の後、マシン14によって発行されています。最初削除、予約IDの値が奇数、例えば7であり、かつ第一変形ステップサイズは2です。それは我々がセグメントを定義する標準数を満たしてみましょう、この例ではそれだけで奇妙な生産後の最初を作ることです。拡張プログラムは複雑に見えますか？我々は、オンライン100台のマシンを持っている場合は大丈夫、今どのように行うには、の拡大にこの時間を想像見えますか？それは単に悪夢です。だから、複雑なシステムの洗練のレベルを達成することは困難です。
IDが単調に増加する特性ではないが、傾向だけ増やすことができ、この欠点は、一般的なビジネスニーズを耐えることができるため、非常に重要ではありません。
圧力は依然として非常に大規模なデータベースで、IDを取得するたびにのみパフォーマンスを向上させるために、ヒープ・マシンに依存することができ、データベースを書かなければなりませんでした。
4、Redisの生成IDは、[我々はこれを使用したように見えます]
パフォーマンスは、データベースを使用する際に必要なIDを生成するのに十分でないとき、私たちは、IDを生成するためのRedisを使用しようとすることができます。Redisのに主に応じてシングルスレッドなので、グローバルに一意なIDを生成するために使用することができます。INCRアトミック動作を実現し、INCRBY Redisのことができます。
あなたは、より高いスループットを得るために、Redisのクラスタを使用することができます。クラスタは5つのRedisのを持っている場合。あなたは、それぞれ値Redisの1,2,3,4,5を初期化することができ、その後、ステップが5です。Redisのは、それぞれのIDを生成しました：
A：1,6,11,16,21
B：2,7,12,17,22
C：3,8,13,18,23
D：4,9,14,19,24
E：5,10,15,20,25
以下のためのより適切な日常0から始まる通し番号を生成するためのRedisを使用します。このような成長番号以降の注文番号=日+日など。キーは、累積INCRを使用してのRedisに毎日生成することができます。
利点：
データベース、柔軟性、および優れたパフォーマンスデータベースに依存しません。
デジタルID自然の並べ替え、改ページまたは結果が有用でソートする必要があります。
単一障害点を使用して、Redisのクラスタを防止することができます。
欠点は：
システムがRedisのを持っていない場合は、システムの複雑さを増す、新しいコンポーネントを導入する必要があります。
コーディングを必要とし、構成作業負荷が比較的大きく、マルチ環境の操作であり、メンテナンスが非常に面倒です、
ロード・インスタンスのインスタンスのRedisしたら良いのプログラムの開始時に、将来的には変更を加えることは困難です。
6。このようJingdongは淘宝網の電力供給順序番号生成などの他のプログラムがあります。サービスでの注文番号とユーザーID差なので、ビジネスとして注文番号は、より多くの冗長な情報を持っていたい、など：
そして作品：開始番号+時間+ナンバープレートの番号
淘宝網の注文：タイムスタンプ+ユーザーID
その他電気・プロバイダー：+スタンプ+シングルチャネルのユーザーIDは、オーダーIDは、いくつかの最初の商品を追加します。
ユーザーID、シンプル必要な意味は、登録されたチャンネルはできるだけ短く、含めることができます。
総括するには：
1を、注文番号を解析することによって得ることができる日程度驚くべき量のために競合します。。。
2、問題スノーフレークは、クロックが問題をロールバックです。。。