JeecgBoot项目集成ShardingSphere分库分表实践与问题解析

背景介绍

JeecgBoot作为一款基于SpringBoot的快速开发平台，在3.7.3版本中与SpringBoot 3.1.5集成时，开发者在尝试集成ShardingSphere分库分表功能时遇到了StackOverflowError异常。本文将深入分析该问题的原因，并提供完整的解决方案。

问题现象

在JeecgBoot 3.7.3 + SpringBoot 3.1.5环境下，配置ShardingSphere分表规则后，调用测试接口时系统抛出jakarta.servlet.ServletException: Handler dispatch failed: java.lang.StackOverflowError异常。从错误堆栈可以看出，这是一个典型的无限递归问题。

配置分析

开发者配置了基于类的分表算法，将sys_log表按照log_type字段进行水平分表，分为sys_log0和sys_log1两个表。配置中使用了CLASS_BASED类型的sharding-algorithm，并指定了自定义算法类StandardModTableShardAlgorithm。

根本原因

经过深入分析，StackOverflowError异常的产生可能有以下几个原因：

1. 版本兼容性问题：SpringBoot 3.x与ShardingSphere的自动配置可能存在兼容性问题
2. 依赖冲突：项目中可能存在多个版本的ShardingSphere相关依赖
3. 自定义算法实现问题：分表算法类可能存在递归调用逻辑

解决方案

方案一：手动管理ShardingSphere依赖

1. 排除SpringBoot自动管理的ShardingSphere依赖
2. 手动引入特定版本的ShardingSphere JDBC核心依赖
3. 确保所有ShardingSphere相关组件版本一致

方案二：检查自定义分片算法

1. 审查StandardModTableShardAlgorithm实现，确保没有递归逻辑
2. 验证分片键计算逻辑是否正确
3. 添加适当的边界条件检查

方案三：配置调整

1. 简化初始配置，先使用内置算法测试
2. 逐步添加自定义算法配置
3. 增加调试日志，定位递归点

最佳实践建议

1. 版本选择：对于SpringBoot 3.x项目，建议使用ShardingSphere 5.3.x及以上版本
2. 依赖管理：统一管理所有分库分表相关依赖
3. 测试策略：先使用简单配置验证基本功能，再逐步添加复杂规则
4. 日志监控：开启SQL显示功能，便于调试

总结

JeecgBoot项目集成ShardingSphere时遇到的StackOverflowError问题，通常与版本兼容性或算法实现有关。通过手动管理依赖版本、仔细检查算法实现，可以有效解决这类问题。在实际项目中，建议采用渐进式的集成策略，先验证基本功能再实现复杂分片逻辑，确保系统稳定性。