shardingsphere 集成 SpringBoot 批量更新失败

文章描述了一个在使用ShardingSphere进行数据库分库分表操作时遇到的问题,即SQL拦截器只在第一次循环时正确处理了分表规则。解决方案是通过在代码中手动计算并拼接分表规则,确保每次更新操作都指向正确的表。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言

在近期的项目中引入了 shardingSphere 分库分表,排查过后发现失败的原因是分库分表字段未匹配。

我们举个栗子,我们这边分库分表的字段为 projectId。正常来说只要有传入 projectId 作为查询条件shardingsphere 中的拦截器会自动去根据我们的分库分表规则进行拼接新的sql语句。但实际上根据测试结果所得发现只有在第一次foreach时才会根据分库分表规则进行对sql进行自动拼接。


错误如下图代码所示:

<update id="updateBatch">
        <foreach collection="updateList" item="item" index="index" separator=";">
            update
            b_bank_book_account
            set
            bank_abbreviation = #{item.bankAbbreviation},
            bank_full_name = #{item.bankFullName},
            bank_account = #{item.bankAccount},
            account_nature = #{item.accountNature},
            interest_rate = #{item.interestRate},
            <if test="updater != null">
                update_user_name = #{updater.userName},
                update_full_name = #{updater.fullName},
            </if>
            update_time = unix_timestamp(now())*1000
            where id = #{item.id} and project_id = #{item.projectId}
        </foreach>
 </update>

我们希望得到的每一次的表名都为 update b_bank_book_account_0 但实际上得到的结果只有第一次是 update b_bank_book_account_0 从第二次开始还是 update b_bank_book_account 并没有进行转换。


该如何解决这个问题呢?那就只能曲线救国了。

在接口外通过分库分表键于规则计算好之后在第二次循环时手动拼接了。下附解决代码。
${strategy} 为计算后分表规则

<update id="updateBatch">
        <foreach collection="updateList" item="item" index="index" separator=";">
            update
            <if test="index == 0">
                b_bank_book_account
            </if>
            <if test="index != 0">
                b_bank_book_account_${strategy}
            </if>
            set
            bank_abbreviation = #{item.bankAbbreviation},
            bank_full_name = #{item.bankFullName},
            bank_account = #{item.bankAccount},
            account_nature = #{item.accountNature},
            interest_rate = #{item.interestRate},
            <if test="updater != null">
                update_user_name = #{updater.userName},
                update_full_name = #{updater.fullName},
            </if>
            update_time = unix_timestamp(now())*1000
            where id = #{item.id} and project_id = #{item.projectId}
        </foreach>
</update>

本文由 SoGeek_Studio 发布,有任何问题请留言评论,欢迎指正。

<think>嗯,用户想了解如何用Spring Boot实现类似12306的功能。首先,我得想想12306主要有哪些功能模块。用户管理、车次查询、余票管理、订单处理、支付集成、高并发处理,还有分布式锁和缓存之类的技术点。这些模块都需要在Spring Boot项目中配置和集成。 首先,用户管理可能需要Spring Security或者Shiro。引用里提到Shiro可以处理身份验证和授权,所以可能需要集成Shiro。然后车次和余票管理涉及到数据库设计,可能需要分库分表,或者使用缓存如Redis来应对高并发查询。订单处理的话,状态机模式可能有用,确保订单状态正确流转。分布式锁可以用Redisson,防止超卖。支付集成可能需要对接支付宝或微信的SDK,同时处理回调。 高并发方面,Spring Boot可以用异步处理,比如@Async注解,或者消息队列如RabbitMQ来削峰。限流可以用Sentinel或者Hystrix。数据库优化可能需要读写分离,或者使用Elasticsearch加速查询。另外,前端可能要用负载均衡,比如Nginx,或者前后端分离,用Vue或React。 还需要考虑服务的监控,比如Spring Boot Actuator,以及持续集成和部署。测试方面,压力测试工具如JMeter也很重要。可能还需要分布式会话管理,用Spring Session和Redis存储会话,保持一致性。 不过用户的问题是关于最佳实践,所以需要把各个模块的技术选型和实现步骤整理清楚。比如引用中提到Shiro的集成,可能需要参考引用[2]。依赖冲突的话,引用[4]提到用Maven Helper解决。Feign客户端的使用可以参考引用[3]。这些引用可能需要适当地融入到回答里,作为支持的依据。 需要注意的点是,确保每个步骤都合理,并且技术选型符合Spring Boot的生态。比如数据库用MyBatis-Plus或JPA,缓存用Redis,消息队列用RabbitMQ或Kafka。同时,高并发场景下的应对措施,如分布式锁、限流、缓存预热都是关键点。最后,测试和监控也不能忽视,确保系统稳定。</think>### Spring Boot实现类似12306功能的最佳实践 要实现类似12306的高并发、高可用票务系统,需结合Spring Boot生态技术栈与分布式系统设计。以下是核心模块的配置与实践方法: --- #### 一、核心模块设计与技术选型 1. **用户认证与权限控制** - 使用**Spring Security + JWT**或**Apache Shiro**实现分布式会话管理[^2]。 - 集成短信/邮箱验证码服务(如阿里云SDK)。 ```java // Shiro配置示例 @Bean public ShiroFilterFactoryBean shiroFilter(SecurityManager securityManager) { ShiroFilterFactoryBean filter = new ShiroFilterFactoryBean(); filter.setSecurityManager(securityManager); filter.setLoginUrl("/login"); return filter; } ``` 2. **车次与余票管理** - **数据库设计**:采用分库分表(如ShardingSphere)存储车次信息。 - **余票缓存**:使用Redis集群存储实时余量,通过`Redisson`实现分布式锁防止超卖。 ```java // 分布式锁控制余票扣减 RLock lock = redissonClient.getLock("ticket_lock:" + ticketId); try { lock.lock(); // 查询余票 -> 扣减 -> 更新数据库和缓存 } finally { lock.unlock(); } ``` 3. **订单处理** - **状态机模式**:使用`Spring StateMachine`管理订单状态流转(如待支付→已支付→已完成)。 - **异步处理**:通过`@Async`或消息队列(如RabbitMQ)解耦订单创建与通知。 --- #### 二、高并发优化方案 1. **流量削峰** - 前端:**令牌桶限流**(如Google Guava的`RateLimiter`)。 - 后端:**排队系统**(Redis的`List`结构存储请求队列)。 ```java // Sentinel限流配置 @SentinelResource(value = "queryTickets", blockHandler = "handleBlock") public List<Ticket> queryTickets(String from, String to) { // 查询逻辑 } ``` 2. **缓存策略** - **多级缓存**:本地缓存(Caffeine) + Redis集群。 - **缓存预热**:定时任务提前加载热点车次数据。 3. **数据库优化** - **读写分离**:通过`Spring Data JPA`配置主从数据源。 - **批量操作**:使用MyBatis-Plus的`insertBatch`提升写入效率。 --- #### 三、部署与监控 1. **容器化部署** - 通过`Docker + Kubernetes`实现弹性扩缩容。 - 服务注册发现:集成`Spring Cloud Alibaba Nacos`。 2. **全链路监控** - 使用`Spring Boot Actuator`暴露健康检查接口。 - 日志收集:ELK(Elasticsearch + Logstash + Kibana)栈。 --- #### 四、关键问题解决方案 1. **重复下单问题** - 数据库唯一索引:`UNIQUE(user_id, train_id, seat_type)`。 - 客户端防重:提交时生成唯一`UUID`作为请求标识。 2. **缓存与数据库一致性** - 采用**延迟双删策略**: ```java redisTemplate.delete(key); // 第一次删除 updateDB(data); // 更新数据库 Thread.sleep(500); redisTemplate.delete(key); // 第二次删除 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值