PeppaO

optimize

> Please annotate the implementation class method with the annotation. 意思是不能在接口上用注解了吗， 与1.6.x有使用上的区别？同样的测试用例，测试dubbo3是没问题的

我尝试读取jar中的加载好了，但是测试的时候本地启动，tc读取的是target下classes，测试用例读取的jar，这样class注册的id顺序不一致，依然报错，我的想法还是改成手动注册class，这样顺序才能保证一致

@kamusis

@slievrly @funky-eyes @lightClouds917 @wangliang181230

整理方案： 方案一： 通过分片解决，假设有3台tc节点，每一台的tc节点对应的global table name设置为global_table01依次类推，然后将distributed-lock-table参数删除，这样就不会启用分布式锁，以tc节点和对应的global table为维度并行延迟删除。  优缺点： 优点：实现简单 缺点：宕机后不能靠其他节点恢复事务，只能等自身服务恢复或者其他手段 方案二： 通过结合raft/db/redis等能力，做到内部通信或间接通信 raft：通过raft集群搭建后，leader进行定时扫描committing和rollbacking状态的事务，已经达到2分10秒要求的xid进行任务分配到各个节点，假设有3台tc，总共3000个需要延迟删除的事务，那么久划分为每个tc1000个xid，由leader发送任务，然后每个tc进行执行延迟删除逻辑，这样就可以提升并发度 redis：通过新增一个分布式锁，选出节点间的leader，然后leader节点执行类似上述raft模式的任务，通过lpush&rpop方式发布任务多个任务，比如1000个xid为一个任务，3000个就会lpush3次，然后消费到的tc进行延迟删除，也达到了并行的效果 db：类似redis的做法，增加分布式锁，然后leader将任务发布到一个任务表中，每个节点每次只查询改任务表中第一条，查询到后执行delete，当删除成功的节点就是抢到任务执行的节点，进行任务执行。  优缺点： 优点： 1. 能做到数据的负载均衡 缺点： 1. 需要选举主leader，复杂度增加，通用性降低 3. 只有主leader筛选达到130s的xid，再进行分配任务 4. db redis 删除后失败了又怎么事务恢复呢？ 在g表插入一列podName(假设是有状态部署方式)，有几个tc节点在distribution_lock表中就有几把关于committing的锁。...

结论：1.先解决单节点的问题，使用多线程的方式 2. 先不往复杂分布式的情况考虑

Excuse me, could you please tell me how to support domain names containing underscores in Tomcat 9.0.x, since I was previously using an older version of Tomcat?