其他中间件本身没有care数据同步这块，读写分离只根据读写的不同操作性质进行路由。我理解数据同步其实本身是数据库集群自己应该关心的事情。我也理解shardingproxy这么做的原因确实有合理性，这块应该是shardingproxy做了根据主从同步延迟来做路由或者探活是么，这块策略有什么方式可以进行替换么？
我想这是没办法替换的，因为并不是某种“策略”下进行的主从，而是 ShardingSphere 会解析执行的 SQL，并以此判断应该走主库还是从库。
例如该 SQL 是 select * from table_xx where id =1 ，就会走从库
而 SQL update table_xx set name = "xxx" 就会走主库
解析引擎会清楚的知道这是条该走主还是从的 SQL
这个点我理解。如果只是根据sql语义路由的话不应该出现 hostM2 跟 hostM1 不开启主从同步就导致压测卡住，这里应该除了这个语义路由还有其他机制的吧？
压测报错是因为配置不对，压测卡住是因为 benchmarksql 在压测的过程中，会不断的写一个 csv 文件，有的时候会因为 IO 的问题卡住。但是不影响生成 report。
你可以先看看 BenchmarkSQl 自带的 HOW-TO-RUN.txt