1. 如何生成一个唯一id在业务应用或者tc重启的时候还能记录在案，并且正常下发二阶段指令？
2. 如何确认相同资源名的类，一定不能使用？比如子类和父类的关系？
3. How to generate a unique ID that can be recorded and used even after a business application or TC restart, ensuring the ability to issue two-phase commands?
4. How to ensure that classes with the same resource name cannot be used, especially in the relationship between subclasses and parent classes?

1. 如何生成一个唯一id在业务应用或者tc重启的时候还能记录在案，并且正常下发二阶段指令？

2. 如何确认相同资源名的类，一定不能使用？比如子类和父类的关系？

3. How to generate a unique ID that can be recorded and used even after a business application or TC restart, ensuring the ability to issue two-phase commands?

4. How to ensure that classes with the same resource name cannot be used, especially in the relationship between subclasses and parent classes?

5. 通过接口名 + 方法名 + 方法参数的方式，比如io.seata.samples.tcc.springboot.dubbo.action.Test.method1(int)，资源id指定后就保持不变，本质上都是静态的，不会影响重启相关的逻辑 By means of interface name + method name + method parameters, such as io.seata.samples.tcc.springboot.dubbo.action.Test.method1(int), the resource id is specified to remain unchanged, and the change in the generation method will not affect the restart of the relevant logic

6. TCC资源有父子类的情况吗？能麻烦讲一下场景吗 Is there a parent-child class scenario for TCC resources? Can you please tell us about the scenario?

1. 如何生成一个唯一id在业务应用或者tc重启的时候还能记录在案，并且正常下发二阶段指令？

2. 如何确认相同资源名的类，一定不能使用？比如子类和父类的关系？

3. How to generate a unique ID that can be recorded and used even after a business application or TC restart, ensuring the ability to issue two-phase commands?

4. How to ensure that classes with the same resource name cannot be used, especially in the relationship between subclasses and parent classes?

5. 通过接口名 + 方法名 + 方法参数的方式，比如io.seata.samples.tcc.springboot.dubbo.action.Test.method1(int)，资源id指定后就保持不变，本质上都是静态的，不会影响重启相关的逻辑 By means of interface name + method name + method parameters, such as io.seata.samples.tcc.springboot.dubbo.action.Test.method1(int), the resource id is specified to remain unchanged, and the change in the generation method will not affect the restart of the relevant logic

6. TCC资源有父子类的情况吗？能麻烦讲一下场景吗 Is there a parent-child class scenario for TCC resources? Can you please tell us about the scenario?

1.全限定名+方法+参数确实应该是一个唯一的id Fully qualified name + method + parameter should indeed be a unique id
2.第二种我认为是有可能的情况 The second I think is a possible scenario

然后我认为存在一种兼容性问题，比如服务的更新，当旧服务的resourceid为a时，因为它进行了更新，此时他的resourceid就可能叫做b，此时如果tc进行二阶段下发就会找不到相应的rm
Then I think there is a kind of compatibility problem, for example, the update of the service, when the old service's resourceid is a, because it made an update, at this time his resourceid may be called b, at this time if tc makes a two-phase download will not be able to find the corresponding rm

然后我认为存在一种兼容性问题，比如服务的更新，当旧服务的resourceid为a时，因为它进行了更新，此时他的resourceid就可能叫做b，此时如果tc进行二阶段下发就会找不到相应的rm Then I think there is a kind of compatibility problem, for example, the update of the service, when the old service's resourceid is a, because it made an update, at this time his resourceid may be called b, at this time if tc makes a two-phase download will not be able to find the corresponding rm

由用户指定name的话，如果在他版本更新时更新了这个name，也会存在你说的问题。这块是不是可以做一个优雅下线处理，RM下线时要先断绝一切请求，这样就不会再有新的分支事务的注册了。然后等待所有在当前RM上通过branchRegister注册的分支事务所在的全局事务结束之后，对TC的ChannelManager#RM_CHANNELS进行deregister摘除当前节点的Channel，然后再进行下线。这样就可以保证TC不会请求到旧的RM，同时旧的RM在下线之前也把和RM有关的旧的全局事务都完成了
If the name is specified by the user, the problem you mentioned will also exist if the name is updated during his version update. Isn't it possible to do a graceful offline processing for this piece, where the RM goes offline by first disconnecting all requests so that no new branch transactions are registered. Then wait for all the branch transactions registered on the current RM via branchRegister to finish, then deregister the TC's ChannelManager#RM_CHANNELS to remove the current node's Channel, and then go offline again. This ensures that the TC does not request the old RM, and that the old RM completes all the old global transactions related to the RM before going offline

It is necessary to support customized resource identification, but it is not recommended to introduce additional service management costs. We cannot guarantee that every user can log off gracefully. If a user changes their fully qualified name, is there any way we can expose the risk to the user?
支持自定义的资源标识是有必要的，不是很建议引入额外的服务治理成本。我们不能保证每位用户都能做到优雅下线，如果用户更换了全限定名，我们有没有什么办法将风险暴露给用户？

It is necessary to support customized resource identification, but it is not recommended to introduce additional service management costs. We cannot guarantee that every user can log off gracefully. If a user changes their fully qualified name, is there any way we can expose the risk to the user? 支持自定义的资源标识是有必要的，不是很建议引入额外的服务治理成本。我们不能保证每位用户都能做到优雅下线，如果用户更换了全限定名，我们有没有什么办法将风险暴露给用户？

1. 正常的版本更新是可以做到优雅下线的 normal version updates can be done gracefully offline
2. 即使是现在，如果没有优雅下线，而用户在版本更新时私自修改了name注解的值，也会出现找不到资源的问题。可以通过文档/注释的方式告知用户此风险，比如“如果下线后尝试进行接口更新/修改资源名，请务必保证优雅下线“ Even now, if there is no graceful offline and the user changes the value of the name annotation privately during a version update, there will be a problem of not finding the resource. This risk can be communicated to the user via documentation/annotation, e.g. "If you try to update the interface/modify the resource name after going offline, please make sure to go offline gracefully".
3. 有关唯一性你觉得这是一个值得考虑的安全性问题吗？因为我觉得如果由用户指定的话，当用户注册了两个相同名称的资源，会出现branchCommit和branchRollback操作中获取到具有相同名称但毫无关联的TCC的资源，发生混乱。Regarding uniqueness do you think this is a security issue worth considering? Because I think if it is specified by the user, when the user registers two resources with the same name, there will be confusion when the branchCommit and branchRollback operations fetch resources with the same name but unrelated TCCs.

优雅线下是一种解决方案，弄新的resourceid格式兼容两者也是一个方案。前者有不确定性，后者的可靠性更高，但是方案更为复杂。
Elegant offline is one solution, getting a new resourceid format compatible with both is also a solution. The former has uncertainty, the latter is more reliable, but the solution is more complex.

If the user does not configure resource identification, I think it is acceptable to generate default rules; if the user configures it by himself, just ensure that different applications do not affect each other (remember that previous versions will affect each other, not sure if it is completely fixed) .
In fact, this is similar to the Mapping configuration in SpringMVC.

如果用户没有配置资源标识，给予默认规则生成我认为是可以接受的；如果用户有自行配置，保证不同应用之间互不影响即可（记得之前版本是会互相影响的，不确定是否完全fix）。
其实这个和SpringMVC中的Mapping配置类似。