プログラミングでは、操作は、任意のが繰り返し同一の実行時間の影響で製造されている影響冪等な特性です。冪等関数は、同じ結果が繰り返し実行されるのと同じパラメータを使用して得ることができる機能を指します。これらの機能は、心配の繰り返しが変更にシステムの原因となりますしていない、システムステータスには影響を与えません。例えばgetIdCard（）関数とsetTrue（）関数は、冪等関数です。
べき等は、私の理解に関係なく、何回実行する操作があり、返される結果の効果は同じです。
このような電力の典型的な動作として：0にレコード5 Aフィールドセットの数は、この操作は関係なく、冪等である何回行われます。
典型的には、このような非冪等の操作：この操作のレコード5 Aフィールドの数は増加が冪等ではない明らかです。
冪等プログラム
1.クエリ：選択は自然な冪等操作です。
時間後に、クエリ照会、同じデータの場合には、クエリの結果は同じです。
2. [削除]：削除操作が冪等、削除1と数回は削除すべてのデータを削除します。
IDがデータベースに存在しない場合、対応するレコード、削除は、記録動作によって行われ、ない;アクションは一般に、削除データIDのように、向けられているので、IDがデータベース内の対応するレコードが存在する場合、レコードが削除されますそれを記録するために、実質的に削除しますが、他の副作用がありません。
あなたが存在しないデータを削除した場合でも、削除操作に戻り値がある場合は、返すことがあります。結果は、このようなレコードを削除した後、このレコードの戻り値として、異なるものになる、（既にリクエストが削除された最初の時間を削除a）は、戻り値は空です。
3.ユニークインデックス：ダーティデータを効果的にデータベーステーブル内のフィールドに新しい一意のインデックスを確立することによって防止することができます。
例えば、ビジネスは、この特別な順序テーブルの手段は、ユーザに関連付けられたレコードを持つことができ、特別な順序を作成することができ、ユーザごとに設定され、この特別注文フォームは、ユーザテーブルに関連付けられている、特別注文フォームがあります。今回私たちは、ユーザーの一意性制約がデータベースを介して挿入されているに関連付けられているテーブル内のレコードの数を制限するための特殊なために、注文フォーム上のこの特定のフィールドに関連付けられているユーザのためのユニークなインデックスを作成することができます。このように、注文テーブルに関連付けられている特定のユーザの特別な順序で記録され、データベースが与えられる挿入ロールバックされますを挿入する第2の要求を、それが冪等を確実にします。
4.Tokenはチェック機構：操作の前にトークンをチェックするために、重複した投稿ページを防ぐために。
もちろん、Redisのことによって達成することができ、原則的にセッショントークンによって達成されます。クライアントがページを要求すると、サーバーは、クライアント（通常は非表示のフォームまたはブラウザのキャッシュで設定）にトークンを送信し、セッショントークンやRedisの中に置か氏グローバルにユニークなトークン、となります。そして、クライアントが要求を提出し、次回ので、トークンは、サーバーにフォームと一緒に提出されます。最初のサーバによる認証は、彼らがセッショントークン値の更新または削除されます場合は、ユーザー再提出、判決は、第2の検証に失敗したとき、要求された操作が繰り返されることはありません。これは、トークン内のユーザーによって送信されたフォームが変更されていないが、セッショントークンのサーバ側が変更されたか、存在しないためです。
5.悲観的ロック：ロックデータの取得を取得します。
選択 * から yanggb どこのid = 「huangq 」 のための 更新。
トランザクションデータのロック時間を伴って悲観的ロックを使用すると、実際の状況を使用する必要性、非常に長くすることができたときに一般的に使用されます。
また、それに注意し、idフィールドは、そうでない場合、結果は非常に面倒になり、それらに対処するためのロックテーブルを引き起こす可能性があり、主キーまたは一意のインデックスである必要があります。
6.楽観的ロック：状態フィールドでアップデートバージョン番号やその他の制限を行います。
瞬間その長い時間のために、しかし、楽観的ロックロックテーブルの更新データでペシミスティック・ロック・ロック・テーブルとは異なり、他の回は、テーブルをロックしていません。楽観、悲観的ロックロックので、ほとんどのシナリオでは効率が高くなります。オプティミスティック・ロックは、バージョンや他のステータス条件によって、さまざまな方法を実現します。
| ID | 名 | 年齢 | バージョン |
| 1 | yanggb | 18 | 1 |
そのようなあなたが年齢のインタフェースを更新する場合の呼び出しの前に、ビジネステーブルのフィールドにバージョン番号を追加すると、あなたは、彼のバージョン番号を確認してからバージョン番号を持って、インタフェースの時間を呼び出す必要があります。
冪等のインターフェイスにインターフェイスを確保分散（SQLの条件の更新されたバージョンで追加）。
更新 ユーザ 設定年齢= 21、バージョン=バージョン+ 1 、ID = 1 とバージョン= 1。
このように、要求の複数提出、成功したバージョンは+1を有した後、次いでバージョンから後続のリクエストが対応していないため、バージョン番号（バージョン）は、同じであるため、最初に実行されないで実行するように要求されました。
7.分散ロック：別の角度でトークンチェック。
分散システムでは、その後、グローバルに一意のインデックスを構築することを決定する方法はありません、フィールドの一意性など、より難しいだろう。この時間は、サードパーティシステム（Redisのか、飼育係）を介して、前または更新データをビジネスシステムにおける挿入データを分散ロックを導入することができます、あなたは操作がロックを解除するために完了した後に、操作を行うことができます前に、分散ロックを取得する必要があります。実際には、これは複数のシーンのシステムを導入する考えをロックする単一のマルチスレッドシステムであり、アイデアは、分散システムを解決することです。
重要：処理要件を同時に行うことができない長いフローは、（ユーザID +接尾辞）処理は、フラグに従って実施する前に取得した分散ロックすることができる、ロックが失敗し取得した場合、他のプロセスの実行、流れのみ即ち同じ時間正常な実行を持つことができ、実行が完了すると、（分散ロックを提供するために、サードパーティシステムを）分散ロックを解除します。
8.select +挿入：シンプルだが愚かな方法。
いくつかの並行処理のための支持力、および実装リピートのサポートするために、取ることができる簡単な方法かどうかを決定するためにいくつかの重要なデータによれば、テーブルに最初のクエリのレコードである、高いバックエンドシステム、またはいくつかのタスクの仕事ではありません、実行されたビジネスプロセスと、それを判断します。
あなたがしたいので、コアの高並行プロセスは、（あなたはRedisの中にデータを入れたいと思う理由を考える）データ上でクエリに低すぎるパフォーマンスを、このメソッドを使用していないことに留意すべきです。
9.冪等ステート・マシン：別の角度楽観的ロック。
ビジネスやビジネス関連のタスクに関連するドキュメントの設計では、それは確かに、ステートマシン（状態変化図）を伴います。理解するのは簡単、上記、状態変化が異なる状況下で発生しますビジネス文書のフィールドの状態を持つことである、有限状態マシンは、一般的にはそこにあります。このとき、ステートマシンは、次の状態に既にある場合は、変更前の状態に、この時間は、理論的には、変更することはできませんので、その有限状態機械の電源などで確認してください。注：このよう注文などのビジネス文書のクラスは、循環の長い状態であり、我々は深く大きな助けのビジネスを改善するために、システム設計機能をステートマシンを理解する必要があります。
概要
力の概念および他の分散、高度に同時またはJavaEEの概念が関連していない、最初の性能が一貫していると操作が繰り返し生成行われたか否かについての唯一のケアに影響を与えます。
実際には、限りデザインインターフェイスから始まり、任意の非冪等の操作が可能に設計されていないとして、冪等を行います。ユーザーがクリックが同意したときに、インスタンスの需要があり、1の数が答えを支持します。チャンは、直接賞賛は明らかに冪等でない（回答ID、賞賛のポイント）ポイント数（1）ユーザポイントテーブルを変更します。このシナリオでは、変更することができます。ユーザーがクリックが一致した場合、親指をアップユーザテーブル（回答ID、ユーザID）レコードを追加し、唯一のユーザーIDフィールドに一意のインデックスを作成することによって、回答テーブルを支持していることを保証するには称賛のユーザポイントの記録は、最終的な量は、アウトカウントすることによって、テーブルと合意した統計への答えで合意しました。もちろん、システムの実際の設計はそうではないでしょうが、ここで私はより良い例を考えていませんでした。これは、ハッハッハ、簡単に見えますが、本当に難しいことをやって。
短い冪等では、システムの設計では、特に宝システム、インターネットバンキングまたは金融会社、また、両方の効率的かつに関わるすべてのお金を支払うためにお金として、第一に考慮され、遺伝子の修飾プログラマでなければなりませんデータが正確であることを保証するために、チャージバックよりも多く表示されないことができ、さらにプレイのお金やその他の問題、それは難しい扱うようになり、ユーザ体験は良いではありません。
「彼らは、私はちょうど手の届かないところには常に、明るいので、同じように、星のようなものです。」