著者：中国石シャン
インタビューの質問
どのように冪等は、（ない重複料など）は、サービス・インターフェースの設計を分散しましたか？
心理学的分析インタビュアー
この質問から、インタビュアーは、すべての面接実際の生産に問題が入っています。
インタフェースの分散システムは、どのように冪等を確保するには？実際には、この事は、あなたが、分散システム考慮されなければならない操作を行い、本番環境での技術的な問題です。それは何を意味するのでしょうか？
あなたは、サービスが外部コールのためのインターフェイスの数を提供し、サービスは5台のマシン上で展開している場合は、インターフェイスの支払いインターフェースがあり、参照してください。そして、フロントエンドユーザのアクションの人々は、私がなぜ、短期では、順序が誤って二回支払い要求を開始され、その後、多分に分散したかわからないとき、よく、サービスの展開にオーダーの結果を別のマシンを要求二回デビット控除。
または、注文決済システム決済システムコールに、結果はネットワークのタイムアウトので、注意しないで、その後、私たちは前に見たことの注文システムの再試行メカニズムを歩いて、クリック、与えるあなたは支払いを受け取るためにも、決済システム、の一握りを再試行してくださいリクエスト二回、および負荷分散アルゴリズムは恥ずかしい、異なるマシン上に落ちるので。。。
あなたは間違いなく、この事を知っている必要がありますので、そうでなければ、ピットを埋めるために、おそらく簡単です分散システムから出てください。
フェイス質問解析
これは、これは冪等を確保するために、ビジネスと組み合わせる必要が、技術的な問題ではないが、これは普遍的な方法ではありません。
何度も開始する要求とのインターフェースである、いわゆる冪等は、このインターフェイスの結果は、これ以上の控除として、正確であることを確認する必要があり、複数のデータを挿入することができない、統計は1以上を支払うことはできません。これは冪等です。
実際には、冪等主に3つのポイントを確保するために：
- それのほとんどの支払注文IDと、確かに注文IDを含める必要があり、オーダー支払い要求：要求ごとに一意の識別子、所与の栗が存在する必要があります。
- 各要求が処理された後、処理要求を識別するレコードが存在しなければなりません。一般的な解決策は、有料の水等のお支払い前にこの順序を記録し、MySQLでどのような状態を記録することです。
- 要求を受信するたびに扱うかどうかを決定する前に、決定する必要があります。注文が支払われているが、ユニークキー制約を有効に、彼らは水を支払う必要が、リクエストが送信された場合、その後繰り返し、それが第1の入賞水に、この時に挿入され、注文IDがすでに存在している、存在した場合、エラー挿入は行っていません。そして、あなたは充電する必要はありません。
プロセスの実際の動作は、あなただけのキーとして注文IDと、例えば、でのRedisの使用をその事業を統合する必要があります。彼らは、実際のお支払い料金を実行する前にのみ成功した水の支払いを挿入。
支払指図が必要です、あなたは有料の水を入れ、ORDER_ID一意のキーを構築する必要があります unique key。あなたは有料の水を入れ、最初にオーダーのために支払う前に、ORDER_IDが入力されています。あなたは中に入るのRedisのアイデンティティを書き込むことができますset order_id payed最初のRedisを確認し、次の再送要求を介して、されている場合、対応する値をORDER_ID payed それが支払われていたことを説明し、あなたが支払っ繰り返さないでください。