仿12306校招项目业务四（乘车人模块）

乘车人表结构

分库分表策略

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

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

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);
    }