多くの実用的なシステム動作がありますが、それは同じ効果をもたらすのか、同じ結果を返す必要があります回数に関係なく行うことです。例えば：
-
遠位のみ、このデータの反応の結果に対応する背景を生成する必要があり、選択されたデータを再送信してください。
-
ネットワークの再送信または再送信システムのバグに直面し、それはお金だけ一度控除する必要がある場合にのみ、ユーザーアカウントのお金一度控除しなければならない我々は、支払い要求を開始します。
-
、それは一度だけ行われるべきメッセージを送信するには、同じメッセージがユーザーに送信され、ユーザーが叫びます。
- ビジネスの順序を作成し、1が唯一のサービスリクエストを作成することができ、それは大きな問題以上のものを作成します。
そして、非常に多くの重要な例は、ロジックは、サポート力およびその他の機能に必要な。
冪等コンセプト
冪等（冪等、冪等）は、抽象代数学における一般的な数学とコンピュータサイエンスの概念です。
冪等動作はその影響のいずれかが繰り返しプログラミングの最初の実行において同じインパクトを用いて製造されていることを特徴とします。冪等他の関数、メソッド、または電源手段は、あなたが繰り返し同じパラメータを使用して行うことができ、同じ結果機能を実現することができます。
これらの機能は、心配の繰り返しが変更にシステムの原因となりますしていない、システムステータスには影響を与えません。例えば、「getUsername（）とsetTrue（）」関数は、関数の冪等です。
そのような電力保証のようなより複雑な操作は固有のトランザクション番号（シリアル番号）を用いて達成されます。
私はそれを理解する：同じですので、消費電力動作、何度も実行するためにどのように関係なく、返された結果の影響であります
技術的な解決策
-
クエリクエリのクエリ数回に一度、同じデータの場合には、クエリ結果は同じです。自然の冪等の操作を選択
- 削除削除操作はべき等、削除、削除の一つまたはデータが削除されている何回もあります。（注は、0が返され、データが存在しない場合、削除、削除されたデータと戻り結果より多くの数の結果を返さなくてもよいです）
以下のような新しい汚れたデータを防止するため3.ユニークなインデックス：Alipayの資本勘定は、アリペイは、ユーザーアカウントで、各ユーザーは、唯一のファンドの口座を持つことができ、複数のファンドを作成するには、ユーザーを防ぐためにどのようにユーザテーブルに資本勘定に、その後、アカウントIDに加えて一意のインデックス、ユーザが成功した資本勘定のレコードを追加します
ハイライト：追加のデータダーティなデータの存在を防ぐために、一意のインデックスまたはインデックスのユニークな組み合わせ（一意のインデックステーブルがあり、新しい同時実行エラーは、その後、一度それをチェックし、データがすでに存在している必要があり、あなたは結果を返すことができます）
- 重複投稿ページを防ぐために、トークンのメカニズム
運用要件：
データ・ページをクリックして一度だけ提出することができます
原因：などを繰り返しクリックやネットワークの再送信、再送信またはnginxの、のためには、データが繰り返しに提出されることがあります
解決策：クラスタ環境：トークンプラスのRedisを使用して（並んで待つために処理し、シングルスレッドのRedisの）単一のJVM環境：トークンまたはトークンの使用プラスRedisのプラスJVMメモリ
プロセスフロー：
、JVMメモリにトークンの有効時間をデータサービス、トークンやRedisのを提出する前に、トークンを申請します
バックグラウンドチェックトークン、削除トークンの提出した後、新しいトークンリターンを生成
トークンの機能：
適用するには、効果的な後、制限することができ
注：Redisのは、トークン+選択は、トークン、並行性の問題を検証するために削除した場合、トークンは成功し、チェックに代表される、削除、お勧めできませんを決定するために、削除操作を使用します
- ペシミスティック・ロック
データロック獲得までの時間アクセス
table_xxxどこから更新のid =「XXX」*選択します。
注：idフィールドが主キーまたは一意のインデックス、またはロック・テーブルである必要があり、死んでいるだろう
トランザクションデータのロック時間と一緒に使用される一般的な使用悲観的ロックは非常に長く、実際の状況に応じて選択することができます
- オプティミスティック・ロック
データのみの表ロックの更新時点における楽観的ロックは、テーブルがロックに対してそれほど悲観的ではない他の時間、より高い効率をロックします。
オプティミスティック・ロックは、バージョンや他のステータス条件によって、さまざまな方法を実現することができます。
図1に示すように、バージョン番号によって達成されます。
update table_xxx set name=#name#,version=version+1 where version=#version#`（インターネットから）下：
2、条件
update tablexxx set avaiamount=avaiamount-#subAmount# where avaiamount-#subAmount# >= 0`要件：quality-＃subQuality＃> =は、このシナリオのバージョン番号に適合しない、更新が唯一の在庫モデル、バックル共有およびロールバック共有のためのデータセキュリティチェックのためで、より高い性能
注：楽観的ロックの更新操作、それは主キーまたは一意のインデックスを更新するのが最善である、これはラインロックで、テーブルが時にそれ以外に更新されますロックは、次の2つのより良いにトップの2つのSQL
`update tablexxx set name=#name#,version=version+1 where id=#id# and version=#version#update tablexxx set avaiamount=avaiamount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0`- 分散ロック
挿入の例としては、システムが分散されている場合、グローバルに一意なインデックスが構築することは困難である、データを取るには、例えば、フィールドには、一意性を判断することはできません
分散ロックを導入することができ、この時間は、ロックの解除後に、サードパーティシステム（またはRedisのZooKeeperの）、または更新データのデータ・トラフィック・システムにおいて、分散ロックの獲得を介して挿入し、次に操作を行うされます
実際には、このアイデアは、分散システムの必須のソリューションで複数のマルチシステムの導入、マルチスレッドにロックです。
重要：処理要件を同時に行うことができない長いフローは、（ユーザID +接尾辞）処理は、フラグに従って実施する前に取得した分散ロックすることができる、ロックが失敗し取得した場合、他のプロセスの実行、流れのみ即ち同じ時間正常な実行を持つことができ、実行が完了すると、リリース分散ロック（サードパーティシステムを提供するために、分散ロック）
- +挿入を選択
並行性の高いバックエンドシステム、またはいくつかのタスクJOB、サポート力のために、サポート繰り返しではない単純なアプローチは、最初のクエリにいくつかの重要なデータであり、ビジネス・プロセスの間に、かどうかを判断するために行われてきた、それ
注：高並行プロセスのコアは、このメソッドを使用しないでください
- ステートマシン冪等
ビジネスやミッション関連のビジネスに関連する文書の設計では、確かに（状態変化図を）ステート・マシンが参加する、上記の状態のビジネス文書を持っている、状態変化が異なる状況下で起こるであろう、有限状態一般的であり機械
ステートマシンは、次の状態に既にある場合は、変更前の状態に今回、理論的には、変更することはできませんので、確実に有限状態機械の電源など、その。
注：このよう注文などのビジネス文書のクラスは、循環の長い状態があり、深くステートマシンを理解する必要があり、システム設計能力、ビジネスを改善するためには、多くのことができます
- 外部インタフェースAPIの保証冪等を提供する方法
アクセスは、支払要求の商人を提出する必要がある場合銀聯決済インタフェースはソース源を提供する場合::来る、配列のシリアル番号
複数の支払いを防ぐために、データベースに行うには、ソース+ SEQユニークインデックス、（同時は、一つだけの要求を処理することができます）
キーは、支持冪等呼び出しインタフェースへの外部インターフェイスを提供通過しなければならない2つのフィールドが、ソース側のシリアル番号は、配列され、中の2つのフィールドが一意のインデックス関節システムプロバイダを行うためにソースの供給源である有し
サードパーティのコールは、最初に内部ローカルシステムをチェックする際に、処理するかどうか、対応する結果の処理に戻ることは、ないに対処し、それに応じて、結果を返しに対処しました。
注文冪等の友情に、このトランザクションを処理するかどうかを問い合わせるようにしてくださいという注意は、クエリを直接ビジネスシステムに、文句を言うでしょうしませんが、実際に処理されています。
概要
冪等は宝物、銀行、金融会社や他のインターネットに関わるすべてのお金、それはまた、効率的なデータに必要なシステムの設計では、それは特に賃金のようなシステムでは、第一に考慮され、遺伝子の修飾プログラマでなければなりません正確であると、それはより多くのチャージバックよりも表示されないことができ、さらにプレイのお金やその他の問題は、それが困難扱うようになり、ユーザ体験は良いではありません