请问nacos查看数据库发现当分表的服务被调用时，没有该服务的事务数据是我哪里配置错了吗？

根据您描述的场景和使用的组件版本（Nacos 2.0.2, Seata 1.5.2, Share-JDBC 4.1.1, MyBatis-Plus 3.4.1），您遇到的事务问题可能与Seata配置或服务间的事务协调有关，而非直接与Nacos配置中心的配置错误相关。针对您提到的两个场景，以下是一些排查方向和建议：

场景分析

场景1: A调用B，A抛异常时，预期A和B的事务都应回滚。 - 正常行为: 这是分布式事务期望的行为，表明全局事务管理器(Seata)正确地捕获了异常并回滚了跨服务的事务。

场景2: B调用A，B抛异常时，仅B事务回滚，而A的事务没有回滚。 - 问题表现: 这通常意味着Seata在处理嵌套事务或者跨服务调用时的事务传播行为未按预期工作。

配置检查与优化建议

1. Seata事务模式与传播行为:

   • 确认Seata配置中事务模式(propagation)是否正确设置。对于涉及分表的服务，确保事务传播行为符合预期。例如，如果B服务内部需要参与到A服务发起的全局事务中，应确保使用了正确的事务传播属性，如PROPAGATION_REQUIRED。

2. Seata事务XID传播:

   • 在跨服务调用时，确保Seata XID能够在微服务间正确传递。这通常通过HTTP头（如TX_XID）实现。检查您的服务间调用逻辑，确认是否有丢失或错误处理XID的情况。

3. Seata配置一致性:

   • 确保所有涉及分布式事务的服务端点都在Seata Server进行了注册，并且Seata客户端配置（如registry、service.vgroupMapping等）在各服务中保持一致。

4. 数据库代理与事务隔离级别:

   • 使用Share-JDBC时，检查数据库代理（如AT模式下的Seata数据源代理）配置是否正确，以及事务隔离级别的设置是否对事务行为有影响。

5. MyBatis-Plus与Seata集成:

   • 虽然MyBatis-Plus本身不直接影响事务管理，但确保其执行的SQL操作与Seata的数据源代理兼容，特别是当涉及到分表操作时，需确认Seata能够准确识别并管理这些操作的事务边界。

实操建议

• 日志审查: 查看Seata服务端和客户端的日志，寻找关于事务开始、提交、回滚及任何异常的记录，这有助于定位问题所在。
• 事务上下文跟踪: 使用Seata提供的事务追踪功能，监控事务生命周期中的每一步，以确定事务状态何时开始偏离预期。
• 配置验证: 参考Seata官方文档，再次核对所有服务的Seata配置，尤其是事务管理相关的配置项。

结论

从您描述的问题来看，问题更倾向于Seata分布式事务管理的配置或实现细节，而不是Nacos配置中心的直接配置错误。通过上述排查步骤，应该能帮助您定位并解决事务回滚不一致的问题。

请注意，以上建议基于通用的分布式事务处理逻辑和Seata的工作原理。具体问题的解决还需结合实际应用环境和详细的配置信息进行深入分析。

参考资料： - Seata官方文档: 请自行访问Seata官网获取最新文档和配置指南。