分散型高同時環境でのべき乗等制御
背景
現在の大規模なインターネット・サイト・システムは、SOAまたはマイクロ・サービス・アーキテクチャに基づいて設計されており、システム間ではリモート・サービス呼び出しや非同期メッセージなどによって相互作用しています.分散システムの環境は非常に複雑で、ネットワークのジッタやサービス側システムの応答が遅いと、重複したサービス呼び出しやメッセージの再送を引き起こす可能性があり、サービス側の要求に対する応答やメッセージの処理がデータの変更に関連する場合、大きな危険をもたらす可能性があります.重複するリクエストやメッセージの結果は、支払いや帳簿などのシステムで特に深刻であり、サービス側システムを設計する際には、べき乗などの制御が必要です.
べき乗など
べき乗などの概念は数学から来ており,N回変換と1回変換の結果が同じであることを示している.我々の議論のシナリオでは、クライアントは、同期サービス呼び出しまたは非同期メッセージを介してサービス側と対話して予想される結果に達しなかった場合、複数回の対話を行う可能性があり、サービス側は複数回の繰り返し処理を避けるためにサービスリソースに悪影響を及ぼすため、同じ要求の複数回の呼び出しに対してべき乗などの制御を行う必要がある.ビジネス開発では、ネットワークの問題でリクエスト結果が受信できないためにリクエストを再開したり、サービス側システムの応答が遅い場合でも、重複コミットが頻繁に発生します.支払いや帳簿などのシステムのこのような重複提出による問題は特に明らかで、例えば、支付宝に支払い要求を開始し、ネット問題やシステムBUGの再発のため、支付宝は一度だけお金を差し引くべきだ.明らかに、べき乗などを宣言するサービスは、外部呼び出し者が複数回呼び出す場合があり、外部複数回呼び出すことによるシステムデータ状態の複数回の変化を防止するために、サービスをべき乗などに設計する.
べき乗等制御のソリューション
サービス・エンド・システムは、サービス・コールまたは非同期メッセージを処理し、データ・リソースの増加、削除、変更、検索の4つの状況について、べき乗などの制御方法を見てみましょう.
検索
クエリー・オペレーションは天然のべき乗などであり、データベースにとってデータの変更には関与しません.次の文:
削除
削除操作はデータテーブルの変動にかかわるが、場合によってはべき乗などである.例えば、次のように注文番号(支払いシステムで同じ注文番号は2回生成されず、一般的には時間+sequence方式で生成される)に基づいて注文を削除する操作:
新規作成
新規のデータの1つ以上のフィールドでこのデータを一意に識別することができる場合、データテーブルを設計するときにプライマリ・キーまたは一意インデックスまたは一意の組み合わせインデックスに設定します.例えば、アカウントはアカウント・テーブルのプライマリ・キーであり、アカウントの作成時に重複作成が発生した場合、アカウント・テーブルにデータを挿入するときにべき乗などの衝突が発生します.データベースのストレージメカニズムはべき乗などを制御します.
変更デリバリーテーブルを用いてべき乗などを制御し、例えばSOAアーキテクチャの下で支払いシステムが分散トランザクション同期呼び出しを開始すると、まずトランザクションテーブルを挿入し、トランザクション番号transactionIdはトランザクションテーブルのプライマリキーであり、その後、アカウントテーブルなどの他のデータテーブルの修正作業を行う.トランザクション番号が一意であるため、繰り返し呼び出しはトランザクションテーブルによって乗算されます. 同様に、システム間で非同期メッセージを介してインタラクションを行う場合、サブスクライバシステムの応答が遅い場合、メッセージセンターは、同じメッセージを再送する可能性が高い.この場合、サブスクライバは、メッセージの内容に基づいて業務処理を行う前に、メッセージテーブル(メッセージのメッセージIdは一意)にメッセージを挿入して、同じメッセージ(同じメッセージId)の重複処理を防止することができる. select+updateの方式べき乗など、例えば同期呼び出しやメッセージ処理を行う場合、呼び出しパラメータやメッセージ内容に基づいてdbからクエリーされたデータの時間フィールドと比較することができ、データベースからクエリーされたデータが比較され、データが一致すればべき乗などの制御を行うことができる. 楽観ロックの方式、update with condition、私达はデータテーブルの中のデータを更新する时、バージョン番号あるいはタイムスタンプのフィールド(时间の精度が十分に高い)を利用して楽観ロックをすることができます:
二.なぜべき乗等
高同時環境では、頻繁に複数回のリクエストがトリガーされます:1.フロントエンドページを複数回コミット2.ネットワーク再送、システムbug再試行、nginx再送3.1つのビジネスリクエストに1つのオーダー番号のみ対応
三.べき乗等の方法
1.select+update:update操作の前にselectクエリー操作を実行し、同時多発の少ないシーンを適用する
2.悲観的なロック:通常、トランザクションと一緒にselect*from tableName where ID=#{id}idはプライマリ・キーまたは一意のインデックスに違いありません.これはロー・ロックです.そうでなければテーブル・ロックです.
3.楽観ロック:通常、データ更新時にロックをかけ、二つの一般的な実現がある
a.バージョン番号で実現
b.条件判断による実現
4.token+redisメカニズム
5.分散ロック:一意のインデックスは分散環境では適用されません
6.外部提供のサードパーティインタフェース:source+seqIdを追加して唯一のインデックスとして実行する
まとめ
べき乗などの性は私たちにシステムを設計する時に重点的に考慮しなければならない問題をもたらして、特に重要なデータ処理に関わる時、例えば支払いあるいは帳簿システムの注文、口座はすべてデータができて、高い同時の需要を満たすだけではなくて、また正確に毎回の要求を処理して、繰り返し注文あるいは帳簿を記入する情況が現れません.
現在の大規模なインターネット・サイト・システムは、SOAまたはマイクロ・サービス・アーキテクチャに基づいて設計されており、システム間ではリモート・サービス呼び出しや非同期メッセージなどによって相互作用しています.分散システムの環境は非常に複雑で、ネットワークのジッタやサービス側システムの応答が遅いと、重複したサービス呼び出しやメッセージの再送を引き起こす可能性があり、サービス側の要求に対する応答やメッセージの処理がデータの変更に関連する場合、大きな危険をもたらす可能性があります.重複するリクエストやメッセージの結果は、支払いや帳簿などのシステムで特に深刻であり、サービス側システムを設計する際には、べき乗などの制御が必要です.
べき乗など
べき乗などの概念は数学から来ており,N回変換と1回変換の結果が同じであることを示している.我々の議論のシナリオでは、クライアントは、同期サービス呼び出しまたは非同期メッセージを介してサービス側と対話して予想される結果に達しなかった場合、複数回の対話を行う可能性があり、サービス側は複数回の繰り返し処理を避けるためにサービスリソースに悪影響を及ぼすため、同じ要求の複数回の呼び出しに対してべき乗などの制御を行う必要がある.ビジネス開発では、ネットワークの問題でリクエスト結果が受信できないためにリクエストを再開したり、サービス側システムの応答が遅い場合でも、重複コミットが頻繁に発生します.支払いや帳簿などのシステムのこのような重複提出による問題は特に明らかで、例えば、支付宝に支払い要求を開始し、ネット問題やシステムBUGの再発のため、支付宝は一度だけお金を差し引くべきだ.明らかに、べき乗などを宣言するサービスは、外部呼び出し者が複数回呼び出す場合があり、外部複数回呼び出すことによるシステムデータ状態の複数回の変化を防止するために、サービスをべき乗などに設計する.
べき乗等制御のソリューション
サービス・エンド・システムは、サービス・コールまたは非同期メッセージを処理し、データ・リソースの増加、削除、変更、検索の4つの状況について、べき乗などの制御方法を見てみましょう.
検索
クエリー・オペレーションは天然のべき乗などであり、データベースにとってデータの変更には関与しません.次の文:
select balance from account where account_no = '666666'は、何度実行してもデータ・テーブルのデータに影響を与えません.削除
削除操作はデータテーブルの変動にかかわるが、場合によってはべき乗などである.例えば、次のように注文番号(支払いシステムで同じ注文番号は2回生成されず、一般的には時間+sequence方式で生成される)に基づいて注文を削除する操作:
delete from order where order_id = '2017011312345678'は、1回実行しても複数回実行してもデータテーブルに反映される変化は同じである.(クライアントにとって戻り結果は異なるかもしれませんが、アカウントが存在する場合、最初の削除は1を返し、後の削除操作は0を返します).サービス側データモデルを設計する場合は、削除したデータの再生成(フィールドごとに同じ)を避ける必要があります.そうしないと、複数回の実行削除が不利な影響を及ぼす可能性があります(他の人が生成したばかりのデータを削除します).新規作成
新規のデータの1つ以上のフィールドでこのデータを一意に識別することができる場合、データテーブルを設計するときにプライマリ・キーまたは一意インデックスまたは一意の組み合わせインデックスに設定します.例えば、アカウントはアカウント・テーブルのプライマリ・キーであり、アカウントの作成時に重複作成が発生した場合、アカウント・テーブルにデータを挿入するときにべき乗などの衝突が発生します.データベースのストレージメカニズムはべき乗などを制御します.
変更
update order set status = 'C', version=version+1 where order_id = '2017011312345678' and version = #version#あるいはupdate accout set balance = 1000, trans_dt = #trans_dt# where account_no = '666666' and trans_dt < #trans_dt#注意しなければならないのは、楽観ロックを使って更新操作をする时、主キーあるいは唯一のインデックスで更新するほうがよくて、このように行ロックで、それ以外の場合は、更新時にロックされます.ロックされたテーブルは、同時性の高い環境では災害的です.二.なぜべき乗等
高同時環境では、頻繁に複数回のリクエストがトリガーされます:1.フロントエンドページを複数回コミット2.ネットワーク再送、システムbug再試行、nginx再送3.1つのビジネスリクエストに1つのオーダー番号のみ対応
三.べき乗等の方法
1.select+update:update操作の前にselectクエリー操作を実行し、同時多発の少ないシーンを適用する
2.悲観的なロック:通常、トランザクションと一緒にselect*from tableName where ID=#{id}idはプライマリ・キーまたは一意のインデックスに違いありません.これはロー・ロックです.そうでなければテーブル・ロックです.
3.楽観ロック:通常、データ更新時にロックをかけ、二つの一般的な実現がある
a.バージョン番号で実現
b.条件判断による実現
4.token+redisメカニズム
5.分散ロック:一意のインデックスは分散環境では適用されません
6.外部提供のサードパーティインタフェース:source+seqIdを追加して唯一のインデックスとして実行する
まとめ
べき乗などの性は私たちにシステムを設計する時に重点的に考慮しなければならない問題をもたらして、特に重要なデータ処理に関わる時、例えば支払いあるいは帳簿システムの注文、口座はすべてデータができて、高い同時の需要を満たすだけではなくて、また正確に毎回の要求を処理して、繰り返し注文あるいは帳簿を記入する情況が現れません.