仿12306校招项目业务四（乘车人模块）_h5移动端模拟12306购票添加乘车人-CSDN博客

本文链接：https://blog.csdn.net/cangshanjiang/article/details/136285623

本文分析了乘车人数据与用户数据的关系，提出乘车人数据量大约是用户数据量4倍的估算，并强调了分库分表的设计，以及如何根据username进行分片。还展示了查询乘车人列表的接口实现，显示了系统的可扩展性和稳定性。

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

乘车人表结构

分库分表策略

乘车人的数据严重依赖于用户数据。每个用户至少需要有一个对应的乘车人，即自己本人。当然，也有可能是其他人，因为允许用户注册账号后为他人购票的情况。这种关联确保了用户和乘车人之间的正确映射，使系统能够准确地处理购票和相关信息。

根据上述前提，让我们进行一些分析，来看看哪些因素会影响乘车人数据量：

1. 首先，每个用户至少会有一个对应的乘车人信息。因此，乘车人数据量至少等于用户数据量。

2. 对于情侣购票用户，有两种情况：一种是普通场景下只有一人购票，另一种是在极端情况下，双方都添加乘车人信息，以便更方便地抢票。

3. 家庭购票用户可能会在一次购票中为全家人购买车票。不过，也有可能其他家庭成员并没有注册 12306 账号。

4. 职场购票用户中，可能会有一人代表多名员工出差，购买所有人员的车票。

当然，上述因素并不能穷举所有情况。因此，在系统设计时，我们综合考虑各种情况得出一个经验值，即乘车人数据量约为用户数据量的 4 倍。虽然这个估算可能不是完全准确，但我们希望能在容量规划时考虑到一定的宽裕余量。

对于分库分表容量评估，我们通常会尽可能地进行全面的评估。这样做的好处是，即使每张表的数据量不大，也能及早发现拆分后是否存在数据问题，以便及时进行调整和优化。

需要特别指出的是，我们对表数据量的考虑阈值相对较小，这是因为我们的系统具备良好的可扩展性，能够轻松应对大量的数据增长。因此，基于这样的分库分表策略，即使在几百年后，这个分库分表仍能处理数据且不会出现性能问题。这为我们的系统提供了稳定可靠的性能保障。

乘车人数据的查询必然会涉及到用户信息，而我们的用户表是按照 username 进行分片的。鉴于这些因素，我们决定将 username 作为乘车人表的分片键。

乘车人接口

 /**
     * 根据用户名查询乘车人列表
     */
    @GetMapping("/api/user-service/passenger/query")
    public Result<List<PassengerRespDTO>> listPassengerQueryByUsername() {
        return Results.success(passengerService.listPassengerQueryByUsername(UserContext.getUsername()));
    }

@Override
    public List<PassengerRespDTO> listPassengerQueryByUsername(String username) {
        String actualUserPassengerListStr = getActualUserPassengerListStr(username);
        return Optional.ofNullable(actualUserPassengerListStr)
                .map(each -> JSON.parseArray(each, PassengerDO.class))
                .map(each -> BeanUtil.convert(each, PassengerRespDTO.class))
                .orElse(null);
    }