Why you need it?

针对TYPE_SEATA_MERGE的消息，应该独立一个线程池，首先它的消息都是来源于客户端的合并消息，目前针对merge的消息，server侧会独立一个并行的forkjoin commonpool线程池进行处理，forkjoin的线程池的线程十分有限，特别是针对io相关占比较大的存储模式，比如redis，db可能无法很好的提供高吞吐的保障。所以我的想法是将TYPE_SEATA_MERGE的消息独立出一个线程池，然后针对merge的消息，实际上是合并的多个消息，这个处理的线程池从forkjoin线程池改为messageExecutor。
1.如果并行处理merge消息的线程单独划分线程池，那么用户需要关心的配置太多了
2.merge的消息最终的处理跟非merge的逻辑是一致的，不应该独立线程池，应该跟目前我们的工作线程池messageExecutor放在一起
3.之所以TYPE_SEATA_MERGE的消息要独立线程池，是因为如果读取merge消息和处理merge消息的线程池同为一个，将会互相抢占，最终导致类似死锁一样无法释放线程资源的局面
所以我建议将TYPE_SEATA_MERGE 消息独立一个固定大小的线程池,然后将其内部消息解析出来后,共用目前的业务线程池(默认50个线程数的那个线程池)进行处理,因为这个线程池本身就是用来处理非merge消息的,如果对拆解出来的消息又用新的线程池感觉没有必要
For TYPE_SEATA_MERGE messages, there should be an independent thread pool. First of all, its messages are all merged messages from the client. At present, for the merged messages, the server side will independently process a parallel forkjoin commonpool thread pool. The thread of the forkjoin thread pool is very limited, especially for the storage mode that is relatively large in iOS, such as redis, db may not be able to provide high throughput protection. So my idea is to separate TYPE_SEATA_MERGE messages from a thread pool, and then for the merged messages, which are actually merged messages, the thread pool for this processing is changed from the forkjoin thread pool to the messageExecutor.

1. If the thread that processes the merge message in parallel divides the thread pool separately, then the user needs to care about too much configuration
2. The final processing of the merged message is the same as the non-merged logic. It should not be an independent thread pool, but should be placed together with our current working thread pool messageExecutor.
3. The reason why the TYPE_SEATA_MERGE message should be independent of the thread pool is because if the thread pool that reads the merge message and handles the merge message is the same, it will preempt each other, and eventually lead to a situation similar to a deadlock that cannot release thread resources

So I suggest TYPE_SEATA_MERGE message independent of a fixed-size thread pool, and then parse out its internal messages, share the current business thread pool (the default thread pool of 50 threads) for processing, because this thread pool itself is used to process non-merge messages, if the disassembled messages and use a new thread pool feel unnecessary

How it could be?

A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.

Other related information

Add any other context or screenshots about the feature request here.