问题一：Seata哪位有2.0安装文档呀，按照官网来，项目一直启动不成功？
Seata哪位有2.0安装文档呀，按照官网来，项目一直启动不成功？
参考回答：
Seata 2.0 是一款开源的分布式事务解决方案，提供高性能和简单易用的分布式事务服务。以下是关于Seata 2.0的安装和启动信息：
- 首先，您可以从Seata的GitHub仓库中下载最新版本的Seata。确保您选择了与您的项目兼容的版本。
- 使用Docker进行安装是一种简单的方法。您可以运行以下命令来创建并启动Seata服务器的临时容器：
docker run -itd --name seata-server -p 8091:8091 -p 7091:7091 seataio/seata-server:2.0.0
- 此命令将创建一个名为
seata-server的容器，并将主机的8091端口映射到容器的8091端口，将主机的7091端口映射到容器的7091端口。 - 在启动容器后，您需要将容器内
resources目录下的所有配置文件复制到宿主机上。这些文件包括了Seata所需的各种配置文件。请注意，如果您没有挂载Seata日志文件，日志文件默认存储在容器内的/root/logs目录下。 - 确保您的项目依赖项与Seata 2.0版本兼容。根据版本升级指南，如果您从1.8.x版本升级到2.0.x版本，可能需要修改undolog或通信编解码为fst以外的序列化方式，以便在服务器端进行升级。
- 关于Seata的不同模式，例如AT模式、TCC模式、Saga模式和XA模式，您可以根据自己的需求选择适合的模式来配置和部署。此外，了解事务管理者(TM)、资源管理者(RM)和事务协调者(TC)等概念也是重要的。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584821
问题二：Seata中AT模式下，A服务调用B服务接口，B服务抛出了异常，有没有知道是怎么回事？
Seata中AT模式下，A服务调用B服务接口，B服务抛出了异常，A服务没有感知到。A服务是多数据源(dynamic.seata=true加了)，B服务也能拿到XID,与A服务的一致。B服务是单数据源。B服务抛了异常后A服务那边正常保存了数据。有没有大佬知道是怎么回事？
参考回答：
在Seata的AT模式下，如果服务A调用服务B的接口，而服务B发生异常，并且这个异常被微服务的全局异常处理机制捕获处理了，那么Seata就无法拦截到这个异常，从而无法让分布式事务生效。这是因为在微服务场景下，如果配置了统一的全局异常处理，可能会导致Seata在AT模式下无法正常回滚。
具体到你的问题，即使B服务抛出了异常，但由于A服务是多数据源并开启了dynamic.seata=true，它可能正常保存了数据。这可能是因为A服务没有感知到B服务的异常，或者因为A服务在异常发生后仍然提交了操作。
解决这个问题的一种方式是在全局的异常处理器中关闭分布式事务。这样即使B服务抛出异常，也不会影响A服务的事务处理。另一种可能的解决方案是将全局的异常处理器修改为只捕获非业务异常，让业务异常能够继续抛出并被Seata处理。这样可以确保在出现业务异常时，Seata可以正确地回滚事务。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584820
问题三：Seata在xa模式下 插入一条数据再更新这条数据 会报错是怎么回事？
Seata在xa模式下 插入一条数据再更新这条数据 会报错是怎么回事？
参考回答：
在Seata的XA模式下，如果先插入一条数据再更新这条数据，可能会出现报错。这是因为在XA模式下，Seata会为每个分布式事务生成一个全局唯一的XID，并将其分配给每个分支事务。当执行分支事务时，Seata会根据XID来协调各个分支事务的提交和回滚。
然而，在插入一条数据后再更新这条数据的情况下，由于两个操作都在同一个全局事务中进行，Seata无法确定哪个操作是分支事务。因此，当执行更新操作时，Seata无法找到对应的XID，从而导致报错。
为了解决这个问题，你可以将插入和更新操作拆分成两个不同的全局事务，每个事务都有自己的XID。这样，Seata就可以正确地协调这两个事务的提交和回滚了。
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584819
问题四：正在用seata1.6.1，分布式事务已实现，可正常回滚。这是为什么，可能是哪方面的原因？
正在用seata1.6.1，分布式事务已实现，可正常回滚。
可是我有点不明白的是，在我的debug过程中，业务库中的undo_log表有数据，而seata库中的三张表（global_table、lock_table、branch_table）从始至终无任何数据，这是为什么，可能是哪方面的原因？
参考回答：
事务结束时会删除相关数据，debug能看到 正常运行看不到
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584818
问题五：如果在Seata中进行分布式事务时删除了大量数据，比如十几万条，出现错误是为什么？
如果在Seata中进行分布式事务时删除了大量数据，比如十几万条，出现错误是为什么？客户端会提示 RPC TIMEOUT 60000ms。我们已经将默认的30秒改成了60秒。
参考回答：
超时了，版本太早期了，升级解决npe，但实际问题还是超时，在store.mode=db，由于seata是通过jdbc的executeBatch来批量插入全局锁的，根据MySQL官网的说明，连接参数中的rewriteBatchedStatements为true时，在执行executeBatch，并且操作类型为insert时，jdbc驱动会把对应的SQL优化成insert into () values (), ()的形式来提升批量插入的性能。
根据实际的测试，该参数设置为true后，对应的批量插入性能为原来的10倍多，因此在数据源为MySQL时，建议把该参数设置为true。tc上的db连接串加一下rewriteBatchedStatements优化下性能
关于本问题的更多回答可点击原文查看：https://developer.aliyun.com/ask/584817
