跳到主要内容

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

购票人列表页面​

图片

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='购票人表';

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

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

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

缓存的设计

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

付费内容提示

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

加入星球后，你可以获得：

  • 超级八股文：100万+字的全栈技术知识库，涵盖技术核心、数据库、中间件、分布式等深度剖析的讲解
  • 讲解文档：黑马点评Plus、大麦、大麦pro、大麦AI、流量切换、数据中台的从0到1的550+详细文档
  • 讲解视频：黑马点评Plus、大麦、大麦pro、大麦AI、流量切换、数据中台的核心业务详细讲解
  • 1 对 1 解答：可以对我进行1对1的问题提问，而不仅仅只限于项目
  • 针对性服务：有没理解的地方，文档或者视频还没有讲到可以提出，本人会补充
  • 面试与简历指导：提供面试回答技巧，项目怎样写才能在简历中具有独特的亮点
  • 中间件环境：对于项目中需要使用的中间件，可直接替换成我提供的云环境
  • 面试后复盘：小伙伴去面试后，如果哪里被面试官问住了，可以再找我解答
  • 远程的解决：如果在启动项目遇到问题，本人可以帮你远程解决
进入星球后，即可享受上述所有服务，保证不会再有其他隐藏费用。
知识星球二维码

1. 打开微信 -> 扫描左侧二维码 -> 加入「JavaUp项目实战&技术讲解」知识星球

2. 查看星球使用指导，获取完整项目讲解资料索引

👉 点击解锁全部付费内容
🎁优惠