wordpress下划线 代码,东莞网站关键词优化怎么做,域名网站空间,如何建设提卡网站乘车人表结构 分库分表策略 乘车人的数据严重依赖于用户数据。每个用户至少需要有一个对应的乘车人#xff0c;即自己本人。当然#xff0c;也有可能是其他人#xff0c;因为允许用户注册账号后为他人购票的情况。这种关联确保了用户和乘车人之间的正确映射#xff0c;使系…乘车人表结构 分库分表策略 乘车人的数据严重依赖于用户数据。每个用户至少需要有一个对应的乘车人即自己本人。当然也有可能是其他人因为允许用户注册账号后为他人购票的情况。这种关联确保了用户和乘车人之间的正确映射使系统能够准确地处理购票和相关信息。 根据上述前提让我们进行一些分析来看看哪些因素会影响乘车人数据量 1. 首先每个用户至少会有一个对应的乘车人信息。因此乘车人数据量至少等于用户数据量。 2. 对于情侣购票用户有两种情况一种是普通场景下只有一人购票另一种是在极端情况下双方都添加乘车人信息以便更方便地抢票。 3. 家庭购票用户可能会在一次购票中为全家人购买车票。不过也有可能其他家庭成员并没有注册 12306 账号。 4. 职场购票用户中可能会有一人代表多名员工出差购买所有人员的车票。 当然上述因素并不能穷举所有情况。因此在系统设计时我们综合考虑各种情况得出一个经验值即乘车人数据量约为用户数据量的 4 倍。虽然这个估算可能不是完全准确但我们希望能在容量规划时考虑到一定的宽裕余量。 对于分库分表容量评估我们通常会尽可能地进行全面的评估。这样做的好处是即使每张表的数据量不大也能及早发现拆分后是否存在数据问题以便及时进行调整和优化。 需要特别指出的是我们对表数据量的考虑阈值相对较小这是因为我们的系统具备良好的可扩展性能够轻松应对大量的数据增长。因此基于这样的分库分表策略即使在几百年后这个分库分表仍能处理数据且不会出现性能问题。这为我们的系统提供了稳定可靠的性能保障。 乘车人数据的查询必然会涉及到用户信息而我们的用户表是按照 username 进行分片的。鉴于这些因素我们决定将 username 作为乘车人表的分片键。 乘车人接口 /*** 根据用户名查询乘车人列表*/GetMapping(/api/user-service/passenger/query)public ResultListPassengerRespDTO listPassengerQueryByUsername() {return Results.success(passengerService.listPassengerQueryByUsername(UserContext.getUsername()));} Overridepublic ListPassengerRespDTO 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);}