换个思路看12306，其核心模型设计思路到底复杂在哪里？

ABCDEFG，这是所有站点。座位总配额是 100，假设 B 站点上车，E 站下车的人比较少，那我们就可以设定 BE 这个区段最多只能出 10 张票。所以，只要是用户的订票是在这个区段内的，就最多出 10 张。再比如，一列车次，总共 100 个座位配额，希望全程票最少满足 80 张，那我们只要给 AG 这个区段设定最少 80 张。那任何订票请求，如果是子区间的，就不能超过 100-80，即 20 张。这两种条件必须同时满足，才允许出票。

但是，不管如何做配额和限额，我们总是针对某个车次进行配置，这些配置只是车次内部售票时的一些额外的判断条件（业务规则），不影响车次模型的核心地位和对外暴露的功能。所以，为了本文讨论的清楚起见，我后续的讨论都不涉及配额和限额的问题，而是认为任何区段都可以享受火车最大的物理座位数。

并且，为了讨论问题方便，我们减少一些站点来讨论。假设某个车次有 A,B,C,D 四个站点。那 001 这个人购买了 A,B 这个区间，系统会分配给 001 一个座位 x；但是因为 001 坐到 B 站点后会下车，所以相当于 x 这个座位又空出来了，也就是说，从 B 站点开始，系统又可以认为 x 这个座位是可用的。所以，我们得出结论：同一个座位，其实可以同时出售 AB,BC 这两张票。通过这个简单的分析，我们知道，一列火车虽然只有有限的座位数，比如 1000 个座位。但可以卖出的票远远不止 1000 个。

还是以 A,B,C,D 四个站点为例，假如火车总共有 1000 个座位，那 AB 可以卖 1000 张，BC 也可以卖 1000 张，同样，CD 也可以卖 1000 张。也就是说，理论上最多可以卖出 3000 张票。但是如果换一种卖法，所有人都是买 ABCD 的票，也就是说所有的票都是经过所有站点的，那就是最多只能卖出 1000 张票了。而实际的场景，一定是介于 1000 到 3000 之间。然后实际的 G71 这个车次，有 17 个站，那到底可以卖出多少个票，大家应该可以算了吧。理论上这 17 个站中的任意两个站点之间所形成的线段，都可以出售为一张票。我数学不好，算不太清楚，麻烦有数学好的人帮我算算，呵呵。

通过上面的分析，我们知道一张票的本质是某个车次的某一段区间（一条线段），这个区间包含了若干个站点。然后我们还发现，只要区间不重叠，那座位就不会发生竞争，可以被回收利用，也就是说，可以同时预先出售。

另外，经过更深入的分析，我们还发现区间有 4 种关系：

• 不重叠；
• 部分重叠；
• 完全重叠；
• 覆盖。

不重叠的情况我们已经讨论过了，而覆盖也是重叠的一种。所以我们发现如果重叠，比如有两个区间发生重叠，那重叠部分的区间（可能夸一个或多个站点）是在争抢座位的。因为假设一列火车有 100 个座位，那每个原子区间（两个相邻站点的连线），最多允许重叠 99 次。

所以，经过上面的分析，我们知道了一个车次能够出售一张车票的核心业务规则是什么？就是：这张车票所包含的每个原子区间的重叠次数加 1 都不能超过车次的总座位数，实际上重叠次数 +1 也可以理解为线段的厚度。

3、模型设计

上面我分析了一下票的本质是什么。那接下来我们再来看看怎么设计模型，来快速实现购票的需求，重点是怎么设计商品聚合以及减库存的逻辑。

传统电商的思路

如果按照普通电商的思路，把票（站点区间）设计为商品（聚合根），然后为票设计库存数量。我个人觉得是很糟糕的。因为一方面这种聚合根非常多（上面的 G71 就有 408 个）；另一方面，即便枚举出来了，一次购票也一定会影响非常多其他聚合根的库存数量（只要被部分或全部重叠的区间都受影响）。这样的一次订单处理的复杂度是难以评估的。而且这么多聚合根的更新要在一个事务里，这不是为难数据库吗？而且，这种设计必然带来大量的事务的并发冲突，很可能导致数据库死锁。

总之，我认为这种是典型的由于领域模型的设计错误，导致并发冲突高、数据持久化落地困难。或者如果要解决并发问题，只能排队单线程处理，但是仍然解决不了要在一个事务里修改大量聚合根的尴尬局面。

听说 12306 是采用了 Pivotal Gemfire 这种高大上的内存数据库，我对这个不太了解。我不可想象要是不使用内存数据库，他们要怎么实现车次内的票之间的数据强一致性（就是保证所有出售的票都是符合上面讨论的业务规则的）？所以，这种设计，我个人认为是思维定势了，把火车票看成是普通电商的商品来看待。所以，我们有时做设计又要依赖于经验，又要不能被以往经验所束缚，真的不容易，关键还是要根据具体的业务场景多多深入分析，尽量分析抽象出问题的本质出来，这样才能对症下药。那是否有其他的设计思路呢？

我的思路

1、聚合设计

通过上面的分析我们知道，其实任何一次购票都是针对某个车次的，我认为车次是负责处理订票的聚合根。我们看看一个车次包含了哪些信息？一个车次包括了：

1. 车次名称，如 G71；
2. 座位数，实际座位数会分类型，比如商务座 20 个，一等座 200 个；二等座 500 个；我们这里为了简化问题，可以暂时忽略类型，我认为这个类型不影响核心的模型的设计决策。需要格外注意的是：这里的座位数不要理解为真实的物理座位数，很有可能比真实的座位数要少。因为我们不可能把一个车次的所有座位都在网上通过 12306 来出售，而是只出售一部分，具体出售多少，要由工作人员人工指定。
3. 经过的站点信息（包括站点的 ID、站点名称等），注意：车次还会记录这些站点之间的顺序关系；
4. 出发时间；看过 GRASP 九大模式中的信息专家模式的同学应该知道，将职责分配给拥有执行该职责所需信息的类。我们这个场景，车次具有一次出票的所有信息，所以我们应该把出票的职责交给车次。另外学过 DDD 的同学应该知道，聚合设计有一个原则，就是：聚合内强一致性，聚合之间最终一致性。经过上面的分析，我们知道要产生一张票，其实要影响很多和这个票对应的线段相交的其他票的可用数量。因为所有的站点信息都在车次聚合内部，所以车次聚合内部自然可以维护所有的原子区间，以及每个原子区间的可用票数（相当于是库存数）。当一个原子区间的可用票数为 0 的时候，意味着火车针对这个区间的票已经卖完了。所以，我们完全可以让车次这个聚合根来保证出票时对所有原子区间的可用票数的更新的强一致性。对于车次聚合根来说，这很简单，因为只是几次简单的内存操作而已，耗时可以忽略。一列火车假如有 ABCD 四个站点，那原子区间就是 3 个。对于 G71，则是 16 个。

2、怎么判断是否能出票？

基于上面的聚合设计，出票时扣减库存的逻辑是：

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!