Seaaは階段を上がってピットを踏む

Seaaは階段を上がってピットを踏む

合併異常

手動解除及びバインディングトランザクション

手動制御トランザクションフロー

seat単独機の例は公式サイトにあります。高利用可能な配置についてはここに見に行きます。家政婦のレベルはSeaa 1.2＋Nacosを配置します。
異常を併発する
Seata ATモードのドロップは、同じデータに対して同時である場合、最初に上流サービスが成功すると、下流サービスの失敗に異常が発生します。io.seata.core.exception.GlobalTransactionException:Could not found global transaction xid = 192.168.0.2:8091:2011766308, may be has finished.は一定時間後にロックする必要があります。テーブルとglobalテーブルがきれいに掃除されます。事務は転覆しますが、途中で長時間の点検が行われているかどうかなどです。自分でいくつかの考えがあります。

は、ユーザに対する制限ストリーム（ここでいう制限ストリームはsentinelやhystrixの溶断降レベルではないという制限ストリームに注意し、sentinelはサービス自体に対する制限ストリームがサービスオーバーロードを防止するためだけに使用されるサービス雪崩であり、私たちが行うべきはユーザIP＋URLに対する制限ストリームである）

上流サービスで先に金額を差し引いて在庫を差し引くなどの操作を行い、できるだけ問題がないことを保証することができます。

csrf_に加入する。tokenは再生攻撃を防ぐために使用します。tokenはcsrf攻撃を防ぐ以外に、このことにも使える。

httpヘッダrefererが正しい要求から来ているか確認する。

は、適切にclient.rm.lock.retryTimesの再試行回数を減らすことができます。デフォルトは30回のclient.rm.lock.retryIntervalです。再試行間隔のためにデフォルトで10ミリ秒、状況によって修正されます。上記の2つのパラメータから、悪意のある要求がビジネスの中で一番悪い場合は300 msであり、サービスretryの時間とは言えません。

このような分散的な事務は、商品に対して絶え間なく在庫を減らすというところに使われるのではないはずです。このような秒殺は、必ずredis＋メッセージの中間にあります。だから、主に何らかの悪意のある要求を防ぐために、例えばハッカーが同時にあるサービスを要求して、グローバル事務を判断する前の事務が完了しました。
手動で縛りとバインディングを解くRootContext.getXID()は直接XIDを取得してもいいです。事務内でのサービスは途中でキャンセルできます。

String xid = RootContext.getXID();
RootContext.unbind();//  
//            。            ，  
RootContext.bind(xid);//    

手動制御トランザクションフロー
私たちはまた、全体のプロセスをカスタマイズすることができます。以下はBegin comit rollbackだけを書いています。中にはsuspendとreumeなどの方法があります。仕事を一時停止して回復するために使われます。suspendのパラメータは、縛xidを解くかどうかを表しています。

GlobalTransaction tx = GlobalTransactionContext.getCurrentOrCreate();
//      ,     
tx.begin(30000, "user-service"); //30 
//     transactionName   global_table   ，    ，   default

try{
 //todo something
 //        
 tx.commit();
}catch (Exception ignored){
 //               
 tx.rollback();
}

上記の例は私達自身で事務の流れをコントロールします。もしAOPで自分で実現できる必要があれば、普通の状況で@Global Transationはもう十分です。