“Alphabet 以高溢价吸引投资者参与大规模债券发行”这类标题在财经新闻里屡见不鲜。抛开新闻视角真正值得技术人关注的是背后的系统链路投资者什么时候提交申购、以什么价格申报、系统如何防止重复申购、如何控制总发行额度、募集结束后怎样按规则配售。这些问题如果只靠电子表格和人工核对在单个项目规模扩大后会立刻变成灾难。本文不分析具体公司或具体交易而是以“债券发行申购平台”为技术主线从零实现一个最小可运行的 Java 后端项目。它覆盖业务链路、数据库设计、Redis 原子扣减、配售规则、并发验证和常见故障排查。学完后你能把一个金融领域常见的申购业务拆解成可落地的表结构、接口和并发方案也能为其他类似额度资源分配场景提供设计参考。1. 先看清业务链路从发起到托管交割哪个环节容易出问题1.1 债券发行的基本参与者与流程一笔债券发行涉及四类核心参与者发行人需要融资的主体例如企业、金融机构或政府。承销商或簿记管理人负责组织发行、收集投资者订单、辅助定价和配售。投资者提交申购数量、申购价格或收益率。登记托管机构负责债券份额登记和资金交收。业务主流程可以概括为九个步骤发行立项发行人确定发行总金额、期限、利率区间。路演让投资者了解发行人信用和偿债能力。申购意向收集投资者被告知发行区间后提交申购单。簿记建档承销商汇总所有订单形成待分配订单簿。定价根据订单簿中的需求和价格水平确定最终票面利率或发行价格。配售向不同投资者分配实际债券份额。缴款投资者把资金划入指定账户。登记托管债券在登记托管机构完成份额登记。上市流通债券开始二级市场交易。在技术系统里最容易故障的阶段是申购、定价和配售。因为券源总额有限大量投资者会在同一时间段提交请求系统一旦把额度超卖会产生严重资损纠纷。1.2 系统必须处理的四类核心问题债券申购场景不是简单 CRUD它同时涉及并发、幂等、资金一致性和审计追溯四个问题。业务问题技术挑战建议方案额度不能超卖并发下扣减总发行额度Redis 原子扣减 数据库唯一索引兜底重复提交用户多次点击或网络重试幂等键 唯一订单号资金扣错申购订单和资金变动不同步订单流水与资金流水同事务订单可追溯修改记录无处可查流水表 操作日志保留变更前后值这些挑战的核心在于不能只相信数据库锁。数据库行锁确实能避免超卖但在高并发时会把大量请求排队在热点行上吞吐量下降明显。更常见的做法是先用 Redis 在内存中快速扣减总量再异步落入数据库订单同时用数据库唯一索引兜底防止极端情况下出现重复数据。1.3 “高溢价”在技术系统里如何体现新闻标题中的“高溢价”在系统里不是一个简单形容词而是可以被记录的数值字段。当一只债券票面价格为 100 元时投资者报价 101.5 元意味着投资者愿意支付比票面更高的价格这种价格超过 100 的部分就是溢价。对应到数据表需要保存字段price_level投资者申报价格例如 101.5。premium_rate溢价率等于(price_level - 100) / 100。subscription_amount申购金额。subscription_status当前状态是待确认还是已配售。在簿记建档阶段系统通常会按申购价格从高到低排序。报价越高的投资者在同等条件下更容易获得配售。因此“高溢价”体现在代码里就是配售前排序规则中的第一个关键字。注意真实市场的定价和配售规则比本文示例复杂得多最终由簿记管理人结合订单簿、发行目标和监管要求决定。技术系统要做的是把订单准确记录、把规则配置化而不是写死在代码里。2. 数据模型先行债券、订单、配售记录怎么设计2.1 最小产品范围为了让项目有清晰边界本文实现一个最小闭环管理员创建债券发行计划。投资者提交债券申购订单。投资者可以查询自己的订单和配售结果。募集结束后系统按配置规则完成配售。最小接口集合如下POST /bond/issue 创建债券发行 POST /subscription 提交申购 GET /subscription/{orderNo} 查询订单 POST /allotment/run 触发配售不在本版本内实现的功能包括投资者注册登录、资金支付、中央登记系统对接、监管报送。真实生产系统必须补齐但作为学习原型先聚焦核心链路。2.2 MySQL 表结构定义第一张表是债券发行表bond_issue。CREATE TABLE bond_issue ( id bigint NOT NULL AUTO_INCREMENT, issue_code varchar(32) NOT NULL COMMENT 债券发行代码, issuer_name varchar(128) NOT NULL COMMENT 发行人名称, total_amount decimal(20,2) NOT NULL COMMENT 发行总金额, currency varchar(8) NOT NULL DEFAULT CNY COMMENT 币种, price_level decimal(10,4) NOT NULL DEFAULT 100.0000 COMMENT 票面价格, start_time datetime NOT NULL COMMENT 申购开始时间, end_time datetime NOT NULL COMMENT 申购结束时间, status tinyint NOT NULL DEFAULT 0 COMMENT 0-未开始 1-申购中 2-已结束 3-已配售, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_issue_code (issue_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT债券发行表;第二张表是申购订单表subscription_order。CREATE TABLE subscription_order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 业务订单号, issue_id bigint NOT NULL COMMENT 债券发行ID, user_id varchar(64) NOT NULL COMMENT 投资者ID, subscription_amount decimal(20,2) NOT NULL COMMENT 申购金额, price_level decimal(10,4) NOT NULL COMMENT 申购价格, premium_rate decimal(10,4) NOT NULL COMMENT 溢价率, status tinyint NOT NULL DEFAULT 0 COMMENT 0-待处理 1-申购成功 2-配售成功 3-未获配售, version int NOT NULL DEFAULT 0 COMMENT 乐观锁版本, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), UNIQUE KEY uk_issue_user (issue_id, user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT债券申购订单表;第三张表是配售结果表allotment_record。CREATE TABLE allotment_record ( id bigint NOT NULL AUTO_INCREMENT, issue_id bigint NOT NULL, order_id bigint NOT NULL, order_no varchar(64) NOT NULL, user_id varchar(64) NOT NULL, allotment_amount decimal(20,2) NOT NULL COMMENT 实际配售金额, price_level decimal(10,4) NOT NULL COMMENT 配售价格, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_issue_id (issue_id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT配售结果表;关于表设计的几个关键点uk_issue_user唯一索引直接防止同一个投资者对同一期债券重复创建申购单。uk_order_no保证订单号唯一配合幂等设计。version字段用于乐观锁更新避免多个服务实例同时覆盖状态。金额字段必须使用DECIMAL不要使用浮点数否则在资金计算中会产生精度误差。2.3 Redis 键设计与并发控制思路Redis 在本项目中有两个职责剩余额度扣减和用户幂等标记。bond:remain:{issueId} 剩余可申购额度值为 BigDecimal 或整数分 bond:order:{issueId}:{userId} 用户幂等标记值为订单号这两个键必须被同一个 Lua 脚本原子操作。只使用decrby不能防止重复请求因为第一段先判断用户是否已存在第二段再扣减这两步之间可能插入另一个请求。Lua 脚本放在 Redis 服务端执行可以保证整个过程不被其他命令打断。if redis.call(exists, KEYS[1]) 1 then return 0 end local remain tonumber(redis.call(get, KEYS[2]) or 0) local amount tonumber(ARGV[1]) if remain amount then return -1 end redis.call(decrby, KEYS[2], amount) redis.call(setex, KEYS[1], 3600, ARGV[2]) return 1KEYS[1]是幂等键KEYS[2]是剩余额度键。返回0表示重复提交返回-1表示额度不足返回1表示扣减成功。注意Redis 操作和数据库操作不在同一个本地事务里。不能先扣 Redis 再更新数据库失败后不回补这样会造成额度虚扣。必须在数据库插入失败时显式回补 Redis 并删除幂等键。3. 环境准备与项目骨架搭建3.1 技术选型组件建议版本说明JDK8 或 17如果使用 Spring Boot 2.7.xJDK 8 足够Spring Boot2.7.18相对稳定社区资料多MyBatis-Plus3.5.3.1简化单表 CRUD 操作MySQL8.0生产使用主从或高可用方案Redis6.x 或 7.x用于额度扣减和幂等控制Maven3.8依赖管理实际项目落地前需要先确认当前团队的依赖版本是否与这些组件兼容。版本号会持续更新不要只看某篇博客要结合官方文档。3.2 初始化 Spring Boot 项目在pom.xml中加入核心依赖。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency /dependencies使用 Spring Boot 父工程后spring-data-redis等依赖的版本由父工程统一管理不需要手动指定。MyBatis-Plus 和 MySQL 驱动版本单独指定因为父工程并不管理这两个坐标。3.3 application.yml 配置学习环境下直接配置本地 MySQL 和 Redis 即可。server: port: 8080 spring: application: name: bond-subscription datasource: url: jdbc:mysql://localhost:3306/bond_platform?useUnicodetruecharacterEncodingutf8serverTimezoneUTC username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted这里要注意serverTimezoneUTC。如果数据库时区是东八区而连接串用 UTC会导致日期插入和查询偏差。生产环境建议统一使用 Asia/Shanghai并在所有服务间保持一致。密码不要直接写在配置文件里提交到 Git。学习阶段可以本地启动生产环境必须从环境变量或配置中心读取。4. 核心代码创建债券、申购扣减与配售4.1 实体与 Mapper使用 MyBatis-Plus 简化单表操作。实体类对应债券发行表。Data TableName(bond_issue) public class BondIssue { TableId(type IdType.AUTO) private Long id; private String issueCode; private String issuerName; private BigDecimal totalAmount; private String currency; private BigDecimal priceLevel; private LocalDateTime startTime; private LocalDateTime endTime; private Integer status; private LocalDateTime createdAt; private LocalDateTime updatedAt; }申购订单实体Data TableName(subscription_order) public class SubscriptionOrder { TableId(type IdType.AUTO) private Long id; private String orderNo; private Long issueId; private String userId; private BigDecimal subscriptionAmount; private BigDecimal priceLevel; private BigDecimal premiumRate; private Integer status; Version private Integer version; private LocalDateTime createdAt; private LocalDateTime updatedAt; }Mapper 接口直接继承 BaseMapper。Mapper public interface SubscriptionOrderMapper extends BaseMapperSubscriptionOrder { }代码生成时可以省略大量 XML 文件但复杂统计查询依然建议写在 XML 中避免QueryWrapper过度堆叠造成可读性下降。4.2 创建债券接口创建一个 DTO 接收请求参数。Data public class BondIssueCreateRequest { NotBlank(message 发行代码不能为空) private String issueCode; NotBlank(message 发行人名称不能为空) private String issuerName; NotNull(message 发行总金额不能为空) DecimalMin(value 0.01, message 发行总金额必须大于0) private BigDecimal totalAmount; NotNull(message 票面价格不能为空) private BigDecimal priceLevel; NotNull(message 开始时间不能为空) private LocalDateTime startTime; NotNull(message 结束时间不能为空) private LocalDateTime endTime; }Controller 层RestController RequestMapping(/bond) public class BondController { Resource private BondIssueService bondIssueService; PostMapping(/issue) public ResultLong createIssue(RequestBody Validated BondIssueCreateRequest request) { return Result.success(bondIssueService.createIssue(request)); } }Service 中需要做几个基础校验结束时间必须晚于开始时间。票面价格必须大于 0。插入后初始化 Redis 剩余额度键。Redis 剩余额度初始值要与数据库总额度一致避免启动后出现额度和订单数量对不上。public Long createIssue(BondIssueCreateRequest request) { if (!request.getEndTime().isAfter(request.getStartTime())) { throw new BusinessException(结束时间必须晚于开始时间); } BondIssue issue new BondIssue(); issue.setIssueCode(request.getIssueCode()); issue.setIssuerName(request.getIssuerName()); issue.setTotalAmount(request.getTotalAmount()); issue.setCurrency(CNY); issue.setPriceLevel(request.getPriceLevel()); issue.setStartTime(request.getStartTime()); issue.setEndTime(request.getEndTime()); issue.setStatus(1); bondIssueMapper.insert(issue); stringRedisTemplate.opsForValue() .set(bond:remain: issue.getId(), String.valueOf(request.getTotalAmount().multiply(BigDecimal.valueOf(100)).longValue())); return issue.getId(); }这里把“元”转换成“分”存储避免 Redis 中浮点数计算误差。实际业务里金额单位换算必须提前约定前端展示用元后端计算用分。4.3 申购接口与 Redis Lua 扣减申购流程是系统中最核心的一段。顺序可以简单理解为先生成幂等键和订单号。再执行 Lua 脚本原子判断用户是否重复、额度是否充足并扣减。返回结果后再写入申购订单表。数据库写入失败时回补 Redis 并删除幂等键。先定义一个请求对象Data public class SubscriptionCreateRequest { NotNull private Long issueId; NotBlank private String userId; NotNull DecimalMin(value 0.01) private BigDecimal subscriptionAmount; NotNull private BigDecimal priceLevel; }Service 核心方法public String createSubscription(SubscriptionCreateRequest request) { String orderNo SUB System.currentTimeMillis() RandomUtil.randomNumbers(4); String idempotentKey bond:order: request.getIssueId() : request.getUserId(); String remainKey bond:remain: request.getIssueId(); Long result redisLuaService.tryDeduct(idempotentKey, remainKey, request.getSubscriptionAmount().multiply(BigDecimal.valueOf(100)).longValue(), orderNo); if (result 0) { return getExistingOrderNo(request.getIssueId(), request.getUserId()); } if (result -1) { throw new BusinessException(本期债券可申购额度不足); } try { SubscriptionOrder order new SubscriptionOrder(); order.setOrderNo(orderNo); order.setIssueId(request.getIssueId()); order.setUserId(request.getUserId()); order.setSubscriptionAmount(request.getSubscriptionAmount()); order.setPriceLevel(request.getPriceLevel()); order.setPremiumRate(request.getPriceLevel() .divide(BigDecimal.valueOf(100), 6, RoundingMode.HALF_UP) .subtract(BigDecimal.ONE)); order.setStatus(1); subscriptionOrderMapper.insert(order); } catch (Exception e) { stringRedisTemplate.delete(idempotentKey); stringRedisTemplate.opsForValue() .increment(remainKey, request.getSubscriptionAmount().multiply(BigDecimal.valueOf(100)).longValue()); throw new BusinessException(申购订单创建失败请联系管理员); } return orderNo; }这里有一个容易被忽略的关键点幂等键回调之后bond:remain不会回补。因为重复请求并没有真正占用额度所以不需要回补。只有数据库插入失败时才需要回补因为此时 Redis 扣减成功但订单没有落库。Redis Lua 脚本加载Component public class RedisLuaService { Resource private StringRedisTemplate stringRedisTemplate; private final DefaultRedisScriptLong subscriptionScript new DefaultRedisScript(); public RedisLuaService() { subscriptionScript.setResultType(Long.class); subscriptionScript.setScriptText( if redis.call(exists, KEYS[1]) 1 then return 0 end; local remain tonumber(redis.call(get, KEYS[2]) or 0); local amount tonumber(ARGV[1]); if remain amount then return -1 end; redis.call(decrby, KEYS[2], amount); redis.call(setex, KEYS[1], 3600, ARGV[2]); return 1; ); } public Long tryDeduct(String idempotentKey, String remainKey, Long amount, String orderNo) { return stringRedisTemplate.execute(subscriptionScript, Arrays.asList(idempotentKey, remainKey), String.valueOf(amount), orderNo); } }使用StringRedisTemplate比RedisTemplate更少出现序列化问题因为键和值都是字符串。如果使用默认的 JDK 序列化在 Redis 里看到的内容会是一段序列化乱码不利于排查。4.4 配售算法配售发生在募集结束后。本文给出一个按“申购价格优先、时间优先”的简化实现。public void runAllotment(Long issueId) { ListSubscriptionOrder orders subscriptionOrderMapper.selectList( new LambdaQueryWrapperSubscriptionOrder() .eq(SubscriptionOrder::getIssueId, issueId) .eq(SubscriptionOrder::getStatus, 1) .orderByDesc(SubscriptionOrder::getPriceLevel) .orderByAsc(SubscriptionOrder::getCreatedAt) ); BondIssue issue bondIssueMapper.selectById(issueId); BigDecimal remaining issue.getTotalAmount(); for (SubscriptionOrder order : orders) { if (remaining.compareTo(BigDecimal.ZERO) 0) { break; } BigDecimal allotmentAmount order.getSubscriptionAmount().min(remaining); AllotmentRecord record new AllotmentRecord(); record.setIssueId(issueId); record.setOrderId(order.getId()); record.setOrderNo(order.getOrderNo()); record.setUserId(order.getUserId()); record.setAllotmentAmount(allotmentAmount); record.setPriceLevel(order.getPriceLevel()); allotmentRecordMapper.insert(record); order.setStatus(2); subscriptionOrderMapper.updateById(order); remaining remaining.subtract(allotmentAmount); } }真实业务里配售并不是简单min(申购金额, 剩余额度)。有的会按比例分配有的会对单笔上限做限制有的要求机构投资者和零售投资者分开计算。本文这个实现只是为了跑通顺序和记录流程。把规则抽象成接口或配置是进入生产前必须做的事。注意配售算法必须对同一期债券的所有有效订单做快照不能在遍历过程中看到新插入的订单。需要保证配售动作在分布式环境中只被触发一次否则会产生重复配售记录。5. 运行验证用并发申购验证不超卖与幂等5.1 启动并创建测试债券先启动 MySQL 和 Redis然后启动 Spring Boot 项目。mvn spring-boot:run使用 curl 创建一笔总额为 100 万元的测试债券。curl -X POST http://localhost:8080/bond/issue \ -H Content-Type: application/json \ -d { issueCode: BOND20250101, issuerName: 示例发行人, totalAmount: 1000000.00, priceLevel: 100.0000, startTime: 2025-01-01T09:00:00, endTime: 2025-01-01T18:00:00 }响应示例{ code: 0, data: 1, message: success }返回的data是债券发行表的主键。先把issueId1记录下来后续申购请求都使用这个 ID。5.2 模拟并发提交申购写一个循环脚本模拟 200 个用户同时提交申购每个用户申购 10000 元。for i in $(seq 1 200); do curl -s -X POST http://localhost:8080/subscription \ -H Content-Type: application/json \ -d {\issueId\:1,\userId\:\user_${i}\,\subscriptionAmount\:10000,\priceLevel\:101.5} done wait由于脚本是循环发起的不同请求之间存在网络延迟差异加上并发可以制造出接近并发的请求压力。对于真实测试建议使用 Apache Bench 或 JMeter控制线程数和请求频率同时记录每个请求的响应码。不要只看最终数据库数量还要看有没有 HTTP 500 或额度负数。5.3 验证不超卖与重复申购先查申购订单表统计。SELECT issue_id, COUNT(*) AS order_count, SUM(subscription_amount) AS total_subscription, MAX(status) AS max_status FROM subscription_order GROUP BY issue_id;在总申购额为 200 万元、发行总额为 100 万元的测试场景下预期结果应该是申购成功的订单累计金额不会超过 100 万元。多余的请求返回“本期债券可申购额度不足”。同一个用户重复提交时返回同一个orderNo。再用同一用户请求一次curl -X POST http://localhost:8080/subscription \ -H Content-Type: application/json \ -d {issueId:1,userId:user_1,subscriptionAmount:10000,priceLevel:101.5}第二次请求不应该创建新订单而是返回第一次已经存在的订单号。这一行为验证了幂等设计是否生效。配售触发后再查询配售表SELECT issue_id, user_id, allotment_amount FROM allotment_record ORDER BY price_level DESC, created_at ASC;配售顺序应该严格按照价格从高到低。如果价格相同先提交的订单排前面。6. 常见问题排查链路6.1 问题现象分类问题现象常见原因检查方式处理建议申购后剩余额度变成负数Redis 扣减与数据库回补不一致redis-cli get bond:remain:{issueId}检查数据库插入异常是否打日志回补逻辑是否缺失同一用户出现多条订单幂等键写入失败或未走同一个 Lua 脚本查询subscription_order的uk_issue_user检查 Redis key 是否被删除唯一索引是否建立Redis 扣减成功但数据库无订单扣减和插入不在同一事务插入失败后没有补偿查看异常日志和回补代码在 catch 中回补额度并删除幂等键所有请求都返回额度不足创建债券时没有初始化bond:remain或初始化时串了旧键redis-cli get bond:remain:{issueId}重新初始化额度键并用redis-cli del删除旧键配售结果与预期不符排序字段错误或配售期间新增订单查看配售日志和 SQL 排序条件配售开始时锁定快照使用事务和分布式锁6.2 从日志和数据反推问题排查顺序建议固定下来不要一上来就怀疑代码逻辑。第一步看接口日志。确认请求是否进入 ControllerorderNo是什么Redis 返回值是0、1还是-1。第二步查看 Redis 当前状态。redis-cli get bond:remain:1 get bond:order:1:user_1如果bond:remain:1的值大于数据库订单累计金额说明有额度没有被落库很可能是数据库插入失败后的回补逻辑出问题。如果幂等键存在但数据库没有对应订单说明幂等键被提前写入且回滚时未删除。第三步查数据库订单表。SELECT order_no, issue_id, user_id, subscription_amount, price_level, status, version FROM subscription_order WHERE issue_id 1 ORDER BY id DESC LIMIT 20;第四步看异常栈关键字。DuplicateKeyException RedisConnectionFailureException DataIntegrityViolationException DeadlockLoserDataAccessException不同异常代表不同问题。DuplicateKeyException说明唯一索引触发属于正常幂等保护RedisConnectionFailureException说明 Redis 不可用此时应快速熔断不能继续放行申购请求。6.3 学习环境常见的五个坑第一个坑数据库金额字段使用FLOAT或DOUBLE。申购金额和价格都可能存在精度问题必须使用DECIMALJava 中对应BigDecimal。第二个坑只在 Redis 上做幂等数据库没有唯一索引。Redis 故障或 key 过期后同一用户可能重复创建订单。数据库唯一索引是最后一道防线。第三个坑在本地 JVM 中使用synchronized或Lock模拟并发控制。生产环境一定是多个服务实例单机锁在负载均衡下完全失效。第四个坑忽略时区。创建债券的开始时间和结束时间进入 MySQL 后如果应用、连接串和数据库时区不一致申购状态判断会异常。第五个坑没有为配售动作设置分布式锁。多个定时任务同时触发配售会把同一批订单生成多份配售记录。7. 生产环境落地还差什么7.1 幂等、事务、异步三个基础改造学习示例可以直接在本地跑通但不能直接复制到生产环境。生产环境首先要解决三个问题。幂等不能只依赖 Redis。Redis key 有 TTL网络抖动时 key 可能没写成功。此时数据库唯一索引uk_issue_user仍然能拦截重复订单因此两者必须同时存在。事务不能只依赖本地事务。申购动作既涉及 Redis又涉及 MySQL还可能涉及远程资金账户服务。此时需要引入本地消息表或事务消息先把“额度预占”和“订单落库”解耦再由异步任务推动后续状态流转。异步化是削峰的关键。在申购高峰期接口应快速校验并返回受理结果真正的订单写入可以通过消息队列处理。这样可以把瞬时压力转换成稳定的消费速率。7.2 对账与审计金融系统最不能缺少的是对账能力。对账的基本逻辑是债券总额度 已配售金额 剩余待分配金额 已释放金额。每日对账脚本要计算每个发行期的订单金额总和与 Redis 剩余额度、配售记录进行三方比对。审计日志需要记录操作人和变更前后值。例如把订单状态从“待处理”改为“已配售”审计表应保存order_no SUB123456 operator admin before_status 1 after_status 2 operate_time 2025-01-01 18:00:007.3 学习环境与生产环境差异对照维度学习环境生产环境部署方式单机本地启动多实例容器化部署无状态服务配置文件本地application.yml配置中心统一管理修改不重启数据库单机 MySQL主从复制、高可用、定期备份Redis单节点哨兵或集群需要降级和监控日志控制台输出集中日志平台保留链路 traceId安全不校验身份登录鉴权、接口鉴权、敏感字段加密数据一致性本地事务事务消息、对账补偿、分布式锁性能测试简单 curlJMeter 压测、全链路性能监控7.4 配置中心与发版回滚生产环境通常会使用 Nacos 或 Apollo 作为配置中心。数据库连接、Redis 地址、发行参数都在配置中心维护应用启动时读取配置修改后动态刷新。发版顺序也有讲究。先执行数据库迁移脚本再发布应用。如果业务参数要调整先改配置中心观察运行日志再决定是否需要全量重启。回滚时必须同时考虑应用和数据库。应用回滚到旧版本后如果数据库已经有新表或新字段旧代码可能无法读取。因此数据库迁移脚本要尽量向前兼容新增字段要允许为空或提供默认值。8. 从示例到生产下一步怎么练8.1 业务理解优先还是技术优先做金融业务系统业务理解和技术能力同等重要。债券的溢价、收益率、簿记建档、配售规则这些字段决定了系统设计的模型和规则。如果只把接口写出来不理解为什么要有price_level和premium_rate后续调整规则时会非常困难。建议练习路径是先能解释清楚一只债券从发行到上市经过哪些环节再对照本文的表结构去映射每个环节的数据。然后再动手改代码把某一个环节替换成自己的实现。8.2 可继续练习的方向增加投资者账户和资金冻结功能把申购金额从“仅记录”改成“真实预占”。增加消息队列申购请求先进入 MQ消费者再落库观察削峰效果。把配售规则抽象成策略模式支持价格优先、按比例配售、单用户上限等规则。增加对账任务每天定时检查订单总额、Redis 额度和实际配售金额。用Transactional和Lock分别实现数据库版本对比与 Redis Lua 方案的吞吐差异。给关键接口编写单元测试和并发测试模拟重复请求、额度不足、Redis 宕机等场景。8.3 最适合作为项目展示的沉淀这个示例项目虽然简单但可以作为一个完整的面试项目来展示。重点不是把代码背下来而是能讲清楚几个问题为什么订单表必须有唯一索引。为什么 Redis 扣减要用 Lua 脚本而不是先查再扣减。如果 Redis 和数据库状态不一致如何通过对账发现。生产环境做多实例部署时哪些原本可用的方案会失效。把这几个问题想清楚才算真正理解了这个申购场景而不只是复制了一段代码。 债券发行申购平台：基于Redis原子扣减的高并发Java后端实践
“Alphabet 以高溢价吸引投资者参与大规模债券发行”这类标题在财经新闻里屡见不鲜。抛开新闻视角真正值得技术人关注的是背后的系统链路投资者什么时候提交申购、以什么价格申报、系统如何防止重复申购、如何控制总发行额度、募集结束后怎样按规则配售。这些问题如果只靠电子表格和人工核对在单个项目规模扩大后会立刻变成灾难。本文不分析具体公司或具体交易而是以“债券发行申购平台”为技术主线从零实现一个最小可运行的 Java 后端项目。它覆盖业务链路、数据库设计、Redis 原子扣减、配售规则、并发验证和常见故障排查。学完后你能把一个金融领域常见的申购业务拆解成可落地的表结构、接口和并发方案也能为其他类似额度资源分配场景提供设计参考。1. 先看清业务链路从发起到托管交割哪个环节容易出问题1.1 债券发行的基本参与者与流程一笔债券发行涉及四类核心参与者发行人需要融资的主体例如企业、金融机构或政府。承销商或簿记管理人负责组织发行、收集投资者订单、辅助定价和配售。投资者提交申购数量、申购价格或收益率。登记托管机构负责债券份额登记和资金交收。业务主流程可以概括为九个步骤发行立项发行人确定发行总金额、期限、利率区间。路演让投资者了解发行人信用和偿债能力。申购意向收集投资者被告知发行区间后提交申购单。簿记建档承销商汇总所有订单形成待分配订单簿。定价根据订单簿中的需求和价格水平确定最终票面利率或发行价格。配售向不同投资者分配实际债券份额。缴款投资者把资金划入指定账户。登记托管债券在登记托管机构完成份额登记。上市流通债券开始二级市场交易。在技术系统里最容易故障的阶段是申购、定价和配售。因为券源总额有限大量投资者会在同一时间段提交请求系统一旦把额度超卖会产生严重资损纠纷。1.2 系统必须处理的四类核心问题债券申购场景不是简单 CRUD它同时涉及并发、幂等、资金一致性和审计追溯四个问题。业务问题技术挑战建议方案额度不能超卖并发下扣减总发行额度Redis 原子扣减 数据库唯一索引兜底重复提交用户多次点击或网络重试幂等键 唯一订单号资金扣错申购订单和资金变动不同步订单流水与资金流水同事务订单可追溯修改记录无处可查流水表 操作日志保留变更前后值这些挑战的核心在于不能只相信数据库锁。数据库行锁确实能避免超卖但在高并发时会把大量请求排队在热点行上吞吐量下降明显。更常见的做法是先用 Redis 在内存中快速扣减总量再异步落入数据库订单同时用数据库唯一索引兜底防止极端情况下出现重复数据。1.3 “高溢价”在技术系统里如何体现新闻标题中的“高溢价”在系统里不是一个简单形容词而是可以被记录的数值字段。当一只债券票面价格为 100 元时投资者报价 101.5 元意味着投资者愿意支付比票面更高的价格这种价格超过 100 的部分就是溢价。对应到数据表需要保存字段price_level投资者申报价格例如 101.5。premium_rate溢价率等于(price_level - 100) / 100。subscription_amount申购金额。subscription_status当前状态是待确认还是已配售。在簿记建档阶段系统通常会按申购价格从高到低排序。报价越高的投资者在同等条件下更容易获得配售。因此“高溢价”体现在代码里就是配售前排序规则中的第一个关键字。注意真实市场的定价和配售规则比本文示例复杂得多最终由簿记管理人结合订单簿、发行目标和监管要求决定。技术系统要做的是把订单准确记录、把规则配置化而不是写死在代码里。2. 数据模型先行债券、订单、配售记录怎么设计2.1 最小产品范围为了让项目有清晰边界本文实现一个最小闭环管理员创建债券发行计划。投资者提交债券申购订单。投资者可以查询自己的订单和配售结果。募集结束后系统按配置规则完成配售。最小接口集合如下POST /bond/issue 创建债券发行 POST /subscription 提交申购 GET /subscription/{orderNo} 查询订单 POST /allotment/run 触发配售不在本版本内实现的功能包括投资者注册登录、资金支付、中央登记系统对接、监管报送。真实生产系统必须补齐但作为学习原型先聚焦核心链路。2.2 MySQL 表结构定义第一张表是债券发行表bond_issue。CREATE TABLE bond_issue ( id bigint NOT NULL AUTO_INCREMENT, issue_code varchar(32) NOT NULL COMMENT 债券发行代码, issuer_name varchar(128) NOT NULL COMMENT 发行人名称, total_amount decimal(20,2) NOT NULL COMMENT 发行总金额, currency varchar(8) NOT NULL DEFAULT CNY COMMENT 币种, price_level decimal(10,4) NOT NULL DEFAULT 100.0000 COMMENT 票面价格, start_time datetime NOT NULL COMMENT 申购开始时间, end_time datetime NOT NULL COMMENT 申购结束时间, status tinyint NOT NULL DEFAULT 0 COMMENT 0-未开始 1-申购中 2-已结束 3-已配售, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_issue_code (issue_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT债券发行表;第二张表是申购订单表subscription_order。CREATE TABLE subscription_order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 业务订单号, issue_id bigint NOT NULL COMMENT 债券发行ID, user_id varchar(64) NOT NULL COMMENT 投资者ID, subscription_amount decimal(20,2) NOT NULL COMMENT 申购金额, price_level decimal(10,4) NOT NULL COMMENT 申购价格, premium_rate decimal(10,4) NOT NULL COMMENT 溢价率, status tinyint NOT NULL DEFAULT 0 COMMENT 0-待处理 1-申购成功 2-配售成功 3-未获配售, version int NOT NULL DEFAULT 0 COMMENT 乐观锁版本, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), UNIQUE KEY uk_issue_user (issue_id, user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT债券申购订单表;第三张表是配售结果表allotment_record。CREATE TABLE allotment_record ( id bigint NOT NULL AUTO_INCREMENT, issue_id bigint NOT NULL, order_id bigint NOT NULL, order_no varchar(64) NOT NULL, user_id varchar(64) NOT NULL, allotment_amount decimal(20,2) NOT NULL COMMENT 实际配售金额, price_level decimal(10,4) NOT NULL COMMENT 配售价格, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_issue_id (issue_id), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT配售结果表;关于表设计的几个关键点uk_issue_user唯一索引直接防止同一个投资者对同一期债券重复创建申购单。uk_order_no保证订单号唯一配合幂等设计。version字段用于乐观锁更新避免多个服务实例同时覆盖状态。金额字段必须使用DECIMAL不要使用浮点数否则在资金计算中会产生精度误差。2.3 Redis 键设计与并发控制思路Redis 在本项目中有两个职责剩余额度扣减和用户幂等标记。bond:remain:{issueId} 剩余可申购额度值为 BigDecimal 或整数分 bond:order:{issueId}:{userId} 用户幂等标记值为订单号这两个键必须被同一个 Lua 脚本原子操作。只使用decrby不能防止重复请求因为第一段先判断用户是否已存在第二段再扣减这两步之间可能插入另一个请求。Lua 脚本放在 Redis 服务端执行可以保证整个过程不被其他命令打断。if redis.call(exists, KEYS[1]) 1 then return 0 end local remain tonumber(redis.call(get, KEYS[2]) or 0) local amount tonumber(ARGV[1]) if remain amount then return -1 end redis.call(decrby, KEYS[2], amount) redis.call(setex, KEYS[1], 3600, ARGV[2]) return 1KEYS[1]是幂等键KEYS[2]是剩余额度键。返回0表示重复提交返回-1表示额度不足返回1表示扣减成功。注意Redis 操作和数据库操作不在同一个本地事务里。不能先扣 Redis 再更新数据库失败后不回补这样会造成额度虚扣。必须在数据库插入失败时显式回补 Redis 并删除幂等键。3. 环境准备与项目骨架搭建3.1 技术选型组件建议版本说明JDK8 或 17如果使用 Spring Boot 2.7.xJDK 8 足够Spring Boot2.7.18相对稳定社区资料多MyBatis-Plus3.5.3.1简化单表 CRUD 操作MySQL8.0生产使用主从或高可用方案Redis6.x 或 7.x用于额度扣减和幂等控制Maven3.8依赖管理实际项目落地前需要先确认当前团队的依赖版本是否与这些组件兼容。版本号会持续更新不要只看某篇博客要结合官方文档。3.2 初始化 Spring Boot 项目在pom.xml中加入核心依赖。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency /dependencies使用 Spring Boot 父工程后spring-data-redis等依赖的版本由父工程统一管理不需要手动指定。MyBatis-Plus 和 MySQL 驱动版本单独指定因为父工程并不管理这两个坐标。3.3 application.yml 配置学习环境下直接配置本地 MySQL 和 Redis 即可。server: port: 8080 spring: application: name: bond-subscription datasource: url: jdbc:mysql://localhost:3306/bond_platform?useUnicodetruecharacterEncodingutf8serverTimezoneUTC username: root password: root123 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted这里要注意serverTimezoneUTC。如果数据库时区是东八区而连接串用 UTC会导致日期插入和查询偏差。生产环境建议统一使用 Asia/Shanghai并在所有服务间保持一致。密码不要直接写在配置文件里提交到 Git。学习阶段可以本地启动生产环境必须从环境变量或配置中心读取。4. 核心代码创建债券、申购扣减与配售4.1 实体与 Mapper使用 MyBatis-Plus 简化单表操作。实体类对应债券发行表。Data TableName(bond_issue) public class BondIssue { TableId(type IdType.AUTO) private Long id; private String issueCode; private String issuerName; private BigDecimal totalAmount; private String currency; private BigDecimal priceLevel; private LocalDateTime startTime; private LocalDateTime endTime; private Integer status; private LocalDateTime createdAt; private LocalDateTime updatedAt; }申购订单实体Data TableName(subscription_order) public class SubscriptionOrder { TableId(type IdType.AUTO) private Long id; private String orderNo; private Long issueId; private String userId; private BigDecimal subscriptionAmount; private BigDecimal priceLevel; private BigDecimal premiumRate; private Integer status; Version private Integer version; private LocalDateTime createdAt; private LocalDateTime updatedAt; }Mapper 接口直接继承 BaseMapper。Mapper public interface SubscriptionOrderMapper extends BaseMapperSubscriptionOrder { }代码生成时可以省略大量 XML 文件但复杂统计查询依然建议写在 XML 中避免QueryWrapper过度堆叠造成可读性下降。4.2 创建债券接口创建一个 DTO 接收请求参数。Data public class BondIssueCreateRequest { NotBlank(message 发行代码不能为空) private String issueCode; NotBlank(message 发行人名称不能为空) private String issuerName; NotNull(message 发行总金额不能为空) DecimalMin(value 0.01, message 发行总金额必须大于0) private BigDecimal totalAmount; NotNull(message 票面价格不能为空) private BigDecimal priceLevel; NotNull(message 开始时间不能为空) private LocalDateTime startTime; NotNull(message 结束时间不能为空) private LocalDateTime endTime; }Controller 层RestController RequestMapping(/bond) public class BondController { Resource private BondIssueService bondIssueService; PostMapping(/issue) public ResultLong createIssue(RequestBody Validated BondIssueCreateRequest request) { return Result.success(bondIssueService.createIssue(request)); } }Service 中需要做几个基础校验结束时间必须晚于开始时间。票面价格必须大于 0。插入后初始化 Redis 剩余额度键。Redis 剩余额度初始值要与数据库总额度一致避免启动后出现额度和订单数量对不上。public Long createIssue(BondIssueCreateRequest request) { if (!request.getEndTime().isAfter(request.getStartTime())) { throw new BusinessException(结束时间必须晚于开始时间); } BondIssue issue new BondIssue(); issue.setIssueCode(request.getIssueCode()); issue.setIssuerName(request.getIssuerName()); issue.setTotalAmount(request.getTotalAmount()); issue.setCurrency(CNY); issue.setPriceLevel(request.getPriceLevel()); issue.setStartTime(request.getStartTime()); issue.setEndTime(request.getEndTime()); issue.setStatus(1); bondIssueMapper.insert(issue); stringRedisTemplate.opsForValue() .set(bond:remain: issue.getId(), String.valueOf(request.getTotalAmount().multiply(BigDecimal.valueOf(100)).longValue())); return issue.getId(); }这里把“元”转换成“分”存储避免 Redis 中浮点数计算误差。实际业务里金额单位换算必须提前约定前端展示用元后端计算用分。4.3 申购接口与 Redis Lua 扣减申购流程是系统中最核心的一段。顺序可以简单理解为先生成幂等键和订单号。再执行 Lua 脚本原子判断用户是否重复、额度是否充足并扣减。返回结果后再写入申购订单表。数据库写入失败时回补 Redis 并删除幂等键。先定义一个请求对象Data public class SubscriptionCreateRequest { NotNull private Long issueId; NotBlank private String userId; NotNull DecimalMin(value 0.01) private BigDecimal subscriptionAmount; NotNull private BigDecimal priceLevel; }Service 核心方法public String createSubscription(SubscriptionCreateRequest request) { String orderNo SUB System.currentTimeMillis() RandomUtil.randomNumbers(4); String idempotentKey bond:order: request.getIssueId() : request.getUserId(); String remainKey bond:remain: request.getIssueId(); Long result redisLuaService.tryDeduct(idempotentKey, remainKey, request.getSubscriptionAmount().multiply(BigDecimal.valueOf(100)).longValue(), orderNo); if (result 0) { return getExistingOrderNo(request.getIssueId(), request.getUserId()); } if (result -1) { throw new BusinessException(本期债券可申购额度不足); } try { SubscriptionOrder order new SubscriptionOrder(); order.setOrderNo(orderNo); order.setIssueId(request.getIssueId()); order.setUserId(request.getUserId()); order.setSubscriptionAmount(request.getSubscriptionAmount()); order.setPriceLevel(request.getPriceLevel()); order.setPremiumRate(request.getPriceLevel() .divide(BigDecimal.valueOf(100), 6, RoundingMode.HALF_UP) .subtract(BigDecimal.ONE)); order.setStatus(1); subscriptionOrderMapper.insert(order); } catch (Exception e) { stringRedisTemplate.delete(idempotentKey); stringRedisTemplate.opsForValue() .increment(remainKey, request.getSubscriptionAmount().multiply(BigDecimal.valueOf(100)).longValue()); throw new BusinessException(申购订单创建失败请联系管理员); } return orderNo; }这里有一个容易被忽略的关键点幂等键回调之后bond:remain不会回补。因为重复请求并没有真正占用额度所以不需要回补。只有数据库插入失败时才需要回补因为此时 Redis 扣减成功但订单没有落库。Redis Lua 脚本加载Component public class RedisLuaService { Resource private StringRedisTemplate stringRedisTemplate; private final DefaultRedisScriptLong subscriptionScript new DefaultRedisScript(); public RedisLuaService() { subscriptionScript.setResultType(Long.class); subscriptionScript.setScriptText( if redis.call(exists, KEYS[1]) 1 then return 0 end; local remain tonumber(redis.call(get, KEYS[2]) or 0); local amount tonumber(ARGV[1]); if remain amount then return -1 end; redis.call(decrby, KEYS[2], amount); redis.call(setex, KEYS[1], 3600, ARGV[2]); return 1; ); } public Long tryDeduct(String idempotentKey, String remainKey, Long amount, String orderNo) { return stringRedisTemplate.execute(subscriptionScript, Arrays.asList(idempotentKey, remainKey), String.valueOf(amount), orderNo); } }使用StringRedisTemplate比RedisTemplate更少出现序列化问题因为键和值都是字符串。如果使用默认的 JDK 序列化在 Redis 里看到的内容会是一段序列化乱码不利于排查。4.4 配售算法配售发生在募集结束后。本文给出一个按“申购价格优先、时间优先”的简化实现。public void runAllotment(Long issueId) { ListSubscriptionOrder orders subscriptionOrderMapper.selectList( new LambdaQueryWrapperSubscriptionOrder() .eq(SubscriptionOrder::getIssueId, issueId) .eq(SubscriptionOrder::getStatus, 1) .orderByDesc(SubscriptionOrder::getPriceLevel) .orderByAsc(SubscriptionOrder::getCreatedAt) ); BondIssue issue bondIssueMapper.selectById(issueId); BigDecimal remaining issue.getTotalAmount(); for (SubscriptionOrder order : orders) { if (remaining.compareTo(BigDecimal.ZERO) 0) { break; } BigDecimal allotmentAmount order.getSubscriptionAmount().min(remaining); AllotmentRecord record new AllotmentRecord(); record.setIssueId(issueId); record.setOrderId(order.getId()); record.setOrderNo(order.getOrderNo()); record.setUserId(order.getUserId()); record.setAllotmentAmount(allotmentAmount); record.setPriceLevel(order.getPriceLevel()); allotmentRecordMapper.insert(record); order.setStatus(2); subscriptionOrderMapper.updateById(order); remaining remaining.subtract(allotmentAmount); } }真实业务里配售并不是简单min(申购金额, 剩余额度)。有的会按比例分配有的会对单笔上限做限制有的要求机构投资者和零售投资者分开计算。本文这个实现只是为了跑通顺序和记录流程。把规则抽象成接口或配置是进入生产前必须做的事。注意配售算法必须对同一期债券的所有有效订单做快照不能在遍历过程中看到新插入的订单。需要保证配售动作在分布式环境中只被触发一次否则会产生重复配售记录。5. 运行验证用并发申购验证不超卖与幂等5.1 启动并创建测试债券先启动 MySQL 和 Redis然后启动 Spring Boot 项目。mvn spring-boot:run使用 curl 创建一笔总额为 100 万元的测试债券。curl -X POST http://localhost:8080/bond/issue \ -H Content-Type: application/json \ -d { issueCode: BOND20250101, issuerName: 示例发行人, totalAmount: 1000000.00, priceLevel: 100.0000, startTime: 2025-01-01T09:00:00, endTime: 2025-01-01T18:00:00 }响应示例{ code: 0, data: 1, message: success }返回的data是债券发行表的主键。先把issueId1记录下来后续申购请求都使用这个 ID。5.2 模拟并发提交申购写一个循环脚本模拟 200 个用户同时提交申购每个用户申购 10000 元。for i in $(seq 1 200); do curl -s -X POST http://localhost:8080/subscription \ -H Content-Type: application/json \ -d {\issueId\:1,\userId\:\user_${i}\,\subscriptionAmount\:10000,\priceLevel\:101.5} done wait由于脚本是循环发起的不同请求之间存在网络延迟差异加上并发可以制造出接近并发的请求压力。对于真实测试建议使用 Apache Bench 或 JMeter控制线程数和请求频率同时记录每个请求的响应码。不要只看最终数据库数量还要看有没有 HTTP 500 或额度负数。5.3 验证不超卖与重复申购先查申购订单表统计。SELECT issue_id, COUNT(*) AS order_count, SUM(subscription_amount) AS total_subscription, MAX(status) AS max_status FROM subscription_order GROUP BY issue_id;在总申购额为 200 万元、发行总额为 100 万元的测试场景下预期结果应该是申购成功的订单累计金额不会超过 100 万元。多余的请求返回“本期债券可申购额度不足”。同一个用户重复提交时返回同一个orderNo。再用同一用户请求一次curl -X POST http://localhost:8080/subscription \ -H Content-Type: application/json \ -d {issueId:1,userId:user_1,subscriptionAmount:10000,priceLevel:101.5}第二次请求不应该创建新订单而是返回第一次已经存在的订单号。这一行为验证了幂等设计是否生效。配售触发后再查询配售表SELECT issue_id, user_id, allotment_amount FROM allotment_record ORDER BY price_level DESC, created_at ASC;配售顺序应该严格按照价格从高到低。如果价格相同先提交的订单排前面。6. 常见问题排查链路6.1 问题现象分类问题现象常见原因检查方式处理建议申购后剩余额度变成负数Redis 扣减与数据库回补不一致redis-cli get bond:remain:{issueId}检查数据库插入异常是否打日志回补逻辑是否缺失同一用户出现多条订单幂等键写入失败或未走同一个 Lua 脚本查询subscription_order的uk_issue_user检查 Redis key 是否被删除唯一索引是否建立Redis 扣减成功但数据库无订单扣减和插入不在同一事务插入失败后没有补偿查看异常日志和回补代码在 catch 中回补额度并删除幂等键所有请求都返回额度不足创建债券时没有初始化bond:remain或初始化时串了旧键redis-cli get bond:remain:{issueId}重新初始化额度键并用redis-cli del删除旧键配售结果与预期不符排序字段错误或配售期间新增订单查看配售日志和 SQL 排序条件配售开始时锁定快照使用事务和分布式锁6.2 从日志和数据反推问题排查顺序建议固定下来不要一上来就怀疑代码逻辑。第一步看接口日志。确认请求是否进入 ControllerorderNo是什么Redis 返回值是0、1还是-1。第二步查看 Redis 当前状态。redis-cli get bond:remain:1 get bond:order:1:user_1如果bond:remain:1的值大于数据库订单累计金额说明有额度没有被落库很可能是数据库插入失败后的回补逻辑出问题。如果幂等键存在但数据库没有对应订单说明幂等键被提前写入且回滚时未删除。第三步查数据库订单表。SELECT order_no, issue_id, user_id, subscription_amount, price_level, status, version FROM subscription_order WHERE issue_id 1 ORDER BY id DESC LIMIT 20;第四步看异常栈关键字。DuplicateKeyException RedisConnectionFailureException DataIntegrityViolationException DeadlockLoserDataAccessException不同异常代表不同问题。DuplicateKeyException说明唯一索引触发属于正常幂等保护RedisConnectionFailureException说明 Redis 不可用此时应快速熔断不能继续放行申购请求。6.3 学习环境常见的五个坑第一个坑数据库金额字段使用FLOAT或DOUBLE。申购金额和价格都可能存在精度问题必须使用DECIMALJava 中对应BigDecimal。第二个坑只在 Redis 上做幂等数据库没有唯一索引。Redis 故障或 key 过期后同一用户可能重复创建订单。数据库唯一索引是最后一道防线。第三个坑在本地 JVM 中使用synchronized或Lock模拟并发控制。生产环境一定是多个服务实例单机锁在负载均衡下完全失效。第四个坑忽略时区。创建债券的开始时间和结束时间进入 MySQL 后如果应用、连接串和数据库时区不一致申购状态判断会异常。第五个坑没有为配售动作设置分布式锁。多个定时任务同时触发配售会把同一批订单生成多份配售记录。7. 生产环境落地还差什么7.1 幂等、事务、异步三个基础改造学习示例可以直接在本地跑通但不能直接复制到生产环境。生产环境首先要解决三个问题。幂等不能只依赖 Redis。Redis key 有 TTL网络抖动时 key 可能没写成功。此时数据库唯一索引uk_issue_user仍然能拦截重复订单因此两者必须同时存在。事务不能只依赖本地事务。申购动作既涉及 Redis又涉及 MySQL还可能涉及远程资金账户服务。此时需要引入本地消息表或事务消息先把“额度预占”和“订单落库”解耦再由异步任务推动后续状态流转。异步化是削峰的关键。在申购高峰期接口应快速校验并返回受理结果真正的订单写入可以通过消息队列处理。这样可以把瞬时压力转换成稳定的消费速率。7.2 对账与审计金融系统最不能缺少的是对账能力。对账的基本逻辑是债券总额度 已配售金额 剩余待分配金额 已释放金额。每日对账脚本要计算每个发行期的订单金额总和与 Redis 剩余额度、配售记录进行三方比对。审计日志需要记录操作人和变更前后值。例如把订单状态从“待处理”改为“已配售”审计表应保存order_no SUB123456 operator admin before_status 1 after_status 2 operate_time 2025-01-01 18:00:007.3 学习环境与生产环境差异对照维度学习环境生产环境部署方式单机本地启动多实例容器化部署无状态服务配置文件本地application.yml配置中心统一管理修改不重启数据库单机 MySQL主从复制、高可用、定期备份Redis单节点哨兵或集群需要降级和监控日志控制台输出集中日志平台保留链路 traceId安全不校验身份登录鉴权、接口鉴权、敏感字段加密数据一致性本地事务事务消息、对账补偿、分布式锁性能测试简单 curlJMeter 压测、全链路性能监控7.4 配置中心与发版回滚生产环境通常会使用 Nacos 或 Apollo 作为配置中心。数据库连接、Redis 地址、发行参数都在配置中心维护应用启动时读取配置修改后动态刷新。发版顺序也有讲究。先执行数据库迁移脚本再发布应用。如果业务参数要调整先改配置中心观察运行日志再决定是否需要全量重启。回滚时必须同时考虑应用和数据库。应用回滚到旧版本后如果数据库已经有新表或新字段旧代码可能无法读取。因此数据库迁移脚本要尽量向前兼容新增字段要允许为空或提供默认值。8. 从示例到生产下一步怎么练8.1 业务理解优先还是技术优先做金融业务系统业务理解和技术能力同等重要。债券的溢价、收益率、簿记建档、配售规则这些字段决定了系统设计的模型和规则。如果只把接口写出来不理解为什么要有price_level和premium_rate后续调整规则时会非常困难。建议练习路径是先能解释清楚一只债券从发行到上市经过哪些环节再对照本文的表结构去映射每个环节的数据。然后再动手改代码把某一个环节替换成自己的实现。8.2 可继续练习的方向增加投资者账户和资金冻结功能把申购金额从“仅记录”改成“真实预占”。增加消息队列申购请求先进入 MQ消费者再落库观察削峰效果。把配售规则抽象成策略模式支持价格优先、按比例配售、单用户上限等规则。增加对账任务每天定时检查订单总额、Redis 额度和实际配售金额。用Transactional和Lock分别实现数据库版本对比与 Redis Lua 方案的吞吐差异。给关键接口编写单元测试和并发测试模拟重复请求、额度不足、Redis 宕机等场景。8.3 最适合作为项目展示的沉淀这个示例项目虽然简单但可以作为一个完整的面试项目来展示。重点不是把代码背下来而是能讲清楚几个问题为什么订单表必须有唯一索引。为什么 Redis 扣减要用 Lua 脚本而不是先查再扣减。如果 Redis 和数据库状态不一致如何通过对账发现。生产环境做多实例部署时哪些原本可用的方案会失效。把这几个问题想清楚才算真正理解了这个申购场景而不只是复制了一段代码。