如何对Cadence匹配服务进行数据库分片？MySQL场景相关疑问

1. Matching服务的taskList是否只会使用一张表？ #

默认情况下，如果未专门配置Matching服务的分片数，taskList数据确实会全部写入单张tasks表。但Cadence本身支持对Matching服务进行分片配置，配置后会生成多张分片表，并非强制单表存储。

2. 如何对Matching服务进行数据库分片？ #

要实现Matching服务的数据库分片，按以下步骤操作：

• 修改配置文件：在Cadence的配置中设置matching.numShards参数为你期望的分片数量（比如和History服务一致的100）。
• 创建分片表：使用Cadence官方提供的cadence-sql-tool工具执行数据库初始化/扩容操作，命令示例如下：

  cadence-sql-tool --db mysql --host <你的数据库地址> --port <端口> --user <用户名> --password <密码> --database <数据库名> create --num-shards <分片数>
  

  该命令会自动创建对应分片数的tasks_<shard-id>表（比如tasks_0到tasks_99）。
• 重启服务：重启Matching服务实例，让新的分片配置生效。

3. 单表存储所有taskList的性能是否足够？ #

这取决于你的业务负载情况：

• 低负载场景：如果每日task处理量在几十万级别以内，且并发读写压力不大，经过合理优化（比如给task_list_name、task_type等字段建立合适的索引，调整MySQL的缓存、连接数等配置）的单表完全可以满足性能需求。
• 高负载场景：当每日task量达到百万级以上，或者存在高并发的task生产/消费时，单表会逐渐出现瓶颈——比如行锁竞争加剧、索引维护开销增大、磁盘IO压力飙升，最终影响服务响应速度和稳定性。
• 长期规划建议：即使当前单表性能足够，随着业务增长，单表的数据量和并发压力会持续上升，后续扩容和维护成本会很高。因此建议提前配置与History服务一致的分片数，便于统一管理和后续扩展。

内容的提问来源于stack exchange，提问作者zheyi yi