創造を続け、成長を加速させましょう！「ナゲッツデイリーニュープラン・6月アップデートチャレンジ」に参加して7日目です。クリックしてイベントの詳細をご覧ください。
前に書く
言い方をすれば、多くの場合、私たちは他の人のオープンソース服务、いくつかのオープンソースを使用しています框架。
フレームワークの最下層に深く入り込んで分析できない場合は、これらのフレームワークの最下層の実装原則のいくつかを理解してください。
問題が発生したとき、私たちはアバアバアバにしかなれません！！！これは非常に苛立たしい現実です。= _ =
そのため、いくつかの優れたオープンソースフレームワークを深く掘り下げて、その基盤となるレイヤーをさらに理解し、ソースコード分析で発生する問題に対処する必要があります。
今日はseata、分散トランザクションの使用で遭遇するいくつかの問題と、それらを解決する方法を共有します。
問題が解決しました
1.シータ例外
異常な：
io.seata.core.exception.GlobalTransactionException：グローバルトランザクションxid =192.168.2.121:8091:239779337648214016が見つかりませんでした。終了した可能性があります。
この問題、seata公式文書には解決策があります：
举例说明：
@GlobalTransactional(timeout=60000)
public void A（）{
call remoting B();//远程调用B服务 local DB operation;
}
public void B(){
}
可能原因：
1. A 执行的总体时间超过了60000ms，导致全局事务发起了全局回滚，此时A或B方法继续执行DB操作，校验全局事务状态，发现全局事务已经回滚。
2. B服务执行超出其设定的readTimeout 返回异常给A并将异常抛出导致全局事务回滚，此时B服务执行DB操作时，校验全局事务状态，发现全局事务已经回滚。
3. tc集群节点时间不一致。
影响：出现这种情况时，数据会整体回滚至A方法执行前的数据的初态，从数据一致性的视角上看，数据是整体一致的。
除了上述情况，如果引用的是`seata-spring-boot-starter`的话，产生这个错误的原因也可能是因为一个bug，目前在1.5版本进行了修复，具体可以参考[issues4020](https://github.com/seata/seata/issues/4020)，[PR4039](https://github.com/seata/seata/pull/4039)。
复制代码修正してみてください：
- 1. @GlobalTransactional（timeout = 60000）、timeout * 10は600sに設定されていますが、これはすでに非常に長いです。
しかし、最終的な結果では問題を解決できません。
githubは引き続き検索し、そのような説明があります：3438
この老人もこの問題に遭遇しました。公式の答えは、tcノード時間を同期する必要があるということです。
しかし、私は単一のノードであり、複数のノードはなくtc、サーバーの時刻とデータベースの時刻も同期されています。
それでも私の問題は解決しませんでした。
この問題があります、これは次のとおり
多次提交，总会成功那么一两次です。
これは、ビジネスコードに問題がないことを示しています。
そして、この問題は最近発生したばかりであり、以前は発生していませんでした。
- 2.ソースコードからseataソースコードを解決してデバッグしてみてください。
これは非常に面倒なプロセスであり、非常に頭を悩ませるプロセスでもありますが、それでも忍耐強く、段階的にデバッグする必要があります。
ソースコードのデバッグで問題が見つからなかったため、このプロセスはここでは無視されます。
- 3.次に、経験と実践から分析します。
1.为什么之前都好好的？
2.为什么时得时不行？
复制代码seataこれら2つの問題の分析から、環境問題が原因である可能性があるので、クリーンなサービスを復元してみましょう。
それをテストする方法は？
これを行うservice.vgroupMapping.xxxx_tx_group=defaultには、nacosに登録されているseataサービスを見つけます。
デフォルトは、そのクラスターの下でseataサービスを見つけることを意味します。
次に、この値を変更して、独自の新しいシートサービスに変更できます。
たとえばこれ
次に、マイクロサービスをllsクラスターの下のseataに接続します。次に、それをテストします。
このテストの効果も非常に強力であり、この異常は基本的に発生しません。
これで、ここでそのような結論を導き出すことができます。
シータサーバーが登録するサービスが多すぎると、シータの負荷が増大し、シータに過度のプレッシャーがかかります。
この例外も発生しました。
なぜこれほど多くのサービスにサインアップするのですか？
複数のデータソースの機能を利用しているため、各データソースもseataに登録され、seataの負荷が高くなります。
- 4.最終的な解決策
サーバーのリソースを増やし、クラスターをシータにデプロイし、単一のシータへのプレッシャーを軽減します。
さて、私は今日最初にここにいます、スキミング、スキミング！！！^ _ ^
あなたがそれが役に立つと思うならば、助けてください点赞、评论、收藏！！！