跳到主要内容

为什么说购票人的功能不容小觑

购票人列表页面​

图片

com.damai.controller.TicketUserController​

@RestController
@RequestMapping("/ticket/user")
@Api(tags = "ticket-user", value = "购票人")
public class TicketUserController {
    
    @Autowired
    private TicketUserService ticketUserService;
    
    @ApiOperation(value = "查询购票人列表")
    @PostMapping(value = "/select")
    public ApiResponse<List<TicketUserVo>> select(@Valid @RequestBody TicketUserListDto ticketUserListDto){
        return ApiResponse.ok(ticketUserService.select(ticketUserListDto));
    }
    
    @ApiOperation(value = "添加购票人")
    @PostMapping(value = "/add")
    public ApiResponse<Void> add(@Valid @RequestBody TicketUserDto ticketUserDto){
        ticketUserService.add(ticketUserDto);
        return ApiResponse.ok();
    }
    
    @ApiOperation(value = "删除购票人")
    @PostMapping(value = "/delete")
    public ApiResponse<Void> delete(@Valid @RequestBody TicketUserIdDto ticketUserIdDto){
        ticketUserService.delete(ticketUserIdDto);
        return ApiResponse.ok();
    }
}

购票人功能为什么重要​

可能看到这里，有的小伙伴会有疑惑，为什么说购票人的功能重要？不就是用户下的购票人吗，顶多也就是添加修改操作。还有就是生成订单时，用户选择了购票人信息后，传入购票人信息不就可以了吗？没啥复杂的啊

小伙伴听我娓娓道来，其实真的没有这么简单。

  • 首先在生成订单时，涉及到调用购票人列表接口，给用户展示购票人列表信息
  • 在生成订单接口中，也要查询购票人列表信息，验证传入的购票人信息是否正确

注意这两次操作都是要从数据库中查询，购票人的数据库表是用的user_id作为分库分表的分片键，所以不会有读扩撒导致全路由的问题。

购票人表结构​

CREATE TABLE `d_ticket_user` (
  `id` bigint(20) NOT NULL COMMENT '主键id',
  `user_id` bigint(20) NOT NULL COMMENT '用户id',
  `rel_name` varchar(256) NOT NULL COMMENT '用户真实名字',
  `id_type` int(11) NOT NULL DEFAULT '1' COMMENT '证件类型 1:身份证 2:港澳台居民居住证 3:港澳居民来往内地通行证 4:台湾居民来往内地通行证 5:护照 6:外国人永久居住证',
  `id_number` varchar(512) NOT NULL COMMENT '证件号码',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `edit_time` datetime NOT NULL COMMENT '编辑时间',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1:正常 0:删除',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='购票人表';

但仅仅是将购票人数据进行分库分表是不够的

查询购票人信息的操作是在生成订单过程中，也就是抢票业务。抢票业务可是大麦项目的核心高并发业务，当大量的用户来抢票的话，这个购票人列表的查询可是对数据库的压力很大的，不夸张的说，当请求到达了一定量级了，数据库超时现象很快就能爆出来。

既然数据库的压力这么大，解决的最好方法还是使用缓存，并且购票人修改的概率很低，所以缓存和数据库一致性的问题也很好解决

缓存的设计​

我们确定了使用缓存，但有个问题，就是 什么时候来将购票人的信息放入缓存中？

付费内容提示

该文档的全部内容仅对「码力全开」项目实战&技术讲解 知识星球用户开放

加入星球，一次获得完整项目资料、全栈技术知识库和长期答疑服务。

100万+字全栈技术知识库深入讲解技术核心、数据库、中间件和分布式等内容
8套热门的实战项目持续更新的企业级项目覆盖高并发、微服务、数据中台 和 AI Agent 等方向
AI 技术知识大模型面试详解覆盖 AI 模型原理、Agent、RAG、MCP、Skills、Harness 等核心知识点
文档 + 视频两种讲解形式既能系统阅读，也能跟随视频理解核心业务

完整项目实战资料

每套项目均包含从 0 到 1 讲解文档核心业务讲解视频

从基础项目到复杂业务场景，项目资料会持续更新。

8 套项目
  • 01Nexus Agent AI 智能体
  • 02Nexus Agent Pro 完全版
  • 03黑马点评Plus
  • 04大麦
  • 05大麦Pro
  • 06大麦AI
  • 07流量切换
  • 08数据中台

加入后还能获得

进入星球后，即可享受上述所有服务，保证不会再有其他隐藏费用。

从学习、面试到项目启动，都可以继续获得支持。

  • 1 对 1 解答项目和技术问题都可以提问
  • 针对性补充没有讲清楚的内容会继续补充
  • 面试与简历指导梳理回答技巧和项目亮点
  • 中间件云环境项目依赖可以直接接入使用
  • 面试后复盘被问住的问题可以继续交流
  • 远程问题解决项目启动问题可协助排查
知识星球二维码

扫码进入知识星球

  1. 打开微信，扫描左侧二维码，加入「码力全开」项目实战&技术讲解 知识星球
  2. 查看星球使用指导，获取完整项目讲解资料索引
解锁全部付费内容
🎁优惠