PHP は高い同時実行性の下で一意の識別コードを生成します
- WBOYオリジナル
- 2016-08-08 09:06:351330ブラウズ
タイトルの通り、まず最初に、回答してくださった専門家全員に感謝します。
問題について説明してください:
今の質問は次のとおりです:
リーリー返信内容:
タイトルの通り、まず最初に、回答してくださった専門家全員に感謝します。
問題について説明してください:
今の質問は次のとおりです:
リーリー
識別子の前処理という方法について説明します
事前にアルゴリズムを通じて完全に一意の識別子を生成します。このプロセス中に自分でテストできます。事前処理されているため、時間やアルゴリズムの複雑さを考慮する必要はありません。
生成された一意の識別子をデータベースに書き込みます
同時実行性の高いシナリオでは読み取り操作のみを使用してください
上記は主に、高い同時実行性の下での高速応答の問題を解決します。では、一意性を確保するにはどうすればよいでしょうか?
2 つのアイデアがあります:
Redis のポップ操作を使用するなど、読み取りにキューを使用して、すべての読み取りが固有のキューを通じて確実に完了するようにします
この時点で、別のフィールド userid が必要です。疑似コード:
update TABLE set userid = $userid where userid = 0 limit 1;を使用して、対応する識別子をクエリします。
最後に、私が主張する点は、最初から可能な限り安全になるようにコードを設計することです。セキュリティの問題は最優先で考慮する必要があることに注意してください。 実際のシナリオにおける「高い同時実行性」のシナリオとは何ですか?私が言いたいのは、何か問題が起こった場合には、やはりプログラマーが責任を負わなければならないということです。
1.永続化するために毎回新しいIDデータをランダムに生成し、ランダムに生成されたデータが生成されるたびに履歴データが繰り返されるかどうかを確認します(ただし、これは間違いなく毎回のデータの永続性の比較です) 消費パフォーマンス)
2. 生成されたものが繰り返されないように、ルール (日付と時刻のスタンプのバラバラなど) に従って蓄積しますが、繰り返しを回避する方法を検討する必要があります。高い同時実行性で。
質問したいのですが、同時状態で同じ識別コードを生成することのほうが心配ですか、それとも履歴で重複した識別コードが生成されることのほうが心配ですか?
同時実行性が心配な場合は、先ほど述べたマイクロ秒レベルの文字に一定量の乱数を追加することを検討する必要があります (各乱数は 48 ～ 122 の ASCII に従って文字に変換できます)。さらにいくつか追加するだけです。理論的には絶対的な非反復はありませんが、確率は依然として非常に小さいはずです
歴史は繰り返すと考えるなら、私が思いついたのは冒頭の2つです
ロック機構を使ってみてください。 。
1 ファイルを書き込むたびに +1
2 あなたはプロモーション システムなので、ユーザー ID を持参する限り、この固有のコードは固有のものになります
3 この種の高い同時実行性の問題を見ると、私はそう感じます非常にアイドル状態になり、インターネット全体が混乱してしまいます。 高い同時実行性を扱う企業は実際には多くありませんが、彼らは非常に多くの高い同時実行性を使用しています。今では、フレームワーク、システム、高い同時実行性、キャッシュがプログラマーの信念になっているように感じます。
データベース内の固有の ID に基づいて、対応する 62 桁の文字列を生成します。
多くの記事では、短い URL のルールを分析して 16 進数を生成していますが、理論上、ID は繰り返されず、文字列も繰り返し生成されませんが、長さは変わります。それが受け入れられるかどうかを確認してください。
実際に同時実行性の高いものはそれほど多くないため、使用頻度の高いユーザー ID を要求することも別の方法です。