我觉得 12306 这样的业务场景，非常适合使用 CQRS 架构;因为首先它是一个查多写少、但是写的业务逻辑非常复杂的系统。所以，非常适合做架构层面的读写分离，即采用 CQRS 架构。而且应该使用数据存储也分离的 CQRS。这样 CQ 两端才可以完全不需要顾及对方的问题，各自优化自己的问题即可。我们可以在 C 端使用 DDD 领域模型的思路，用良好设计的领域模型实现复杂的业务规则和业务逻辑。而 Q 端则使用分布式缓存方案，实现可伸缩的查询能力。

　　1、订票的实现思路

　　同时借助像 ENode 这样的框架，我们可以实现 in-memory + Event Sourcing 的架构。Event Sourcing 技术，可以让领域模型的所有状态修改的持久化统一起来，本来要用 ORM 的方式保存聚合根最新状态的，现在只需要简单的通用的方式保存一个事件即可(一次订票只涉及一个车次聚合根的修改，修改只产生一个事件，只需要持久化一个事件(一个 JSON 串)即可，保证了高性能，无须依赖事务，而且通过 ENode 可以解决并发问题)。

　　我们只要保存了聚合根每次变化的事件(事件的结构怎么设计，本文不做多的介绍了，大家可以思考下)，就相当于保存了聚合根的最新状态。而正是由于 Event Sourcing 技术的引入，让我们的模型可以一直存活在内存中，即可以使用 in-memory 技术。不要小看 in-memory 技术，in-memory 技术在某些方面对提高命令的处理性能非常有帮助。

　　比如就以我们车次聚合根处理出票的逻辑，假设某个车次有大量的命令发送到分布式消息队列，然后有一台机器订阅了这个队列的消息，然后这台机器处理这个车次的订票命令时，由于这个车次聚合根一直在内存，所以就省去了每次要去数据库取出聚合根的步骤，相当于少了一次数据库 IO。

　　这样的好处是，因为一个车次能够真正出售的票是有限的，因为座位就那么几个，比如就 1000 个座位，估计一般正常情况也就出个 2000 个左右的票吧(具体能出多少张票要取决于区间的相交程度，上面分析过)。也就是说，这个聚合根只会产生 2000 个事件，也就是说只会有 2000 个订票命令的处理是会产生事件，并持久化事件;而其余的大量命令，因为车次在内存计算后发现没有余票了，就不会做任何修改，也不会产生领域事件，这样就可以直接处理下一个订票命令了。这样就可以大大提高处理订票命令的性能。

　　另外一个问题我觉得还需要提一下，因为用户订票成功后，还需要付款。但用户有可能不去付款或者没有在规定的时间内完成付款。那这种情况下，系统会自动释放该用户之前订购的票。所以基于这样的需求，我们在业务上需要支持业务级别的 2pc。即先预扣库存，也就是先占住这张票一定时间(比如 15 分钟)，然后付款成功后再真实给你这张票，系统做真正的库存修改。

　　通过这样的预扣处理，可以保证不会出现超卖的情况。这个思路其实和传统电商比如淘宝这样的系统类似，我就不多展开了，我之前写的 Conference 案例也是这样的思路，大家有兴趣的可以去看一下我之前录制的视频。

　　2、查询余票的实现思路

　　我觉得余票的查询的实现相对简单。虽然对于 12306 来说，查询的请求占了 80%，提交订单的请求只占 20%。但查询由于对数据没有修改，所以我们完全可以使用分布式缓存来实现。我们只需要精心设计好缓存的 key 即可;缓存 key 的多少要看成本，如果所有可能的查询都设计对应的 key，那时间复杂度为 1，查询性能自然高;但代价也大，因为 key 多了。如果想 key 少一点，那查询的复杂度自然要上去一点。所以缓存设计无非就是空间换时间的思路。然后，缓存的更新无非就是：自动失效、定时更新、主动通知 3 种。通过 CQRS 架构，由于 CQ 两端是事件驱动的，当 C 端有任何状态变化，都会产生对应的事件去通知 Q 端，所以我们几乎可以做到 Q 端的准实时更新。

　　同时由于 CQ 两端的完全解耦，Q 端我们可以设计多种存储，如数据库和缓存(Redis 等);数据库用于线下维护关系型数据，缓存用户实时查询。数据库和缓存的更新速度相互不受影响，因为是并行的。对同一个事件，可以 10 台机器负责更新缓存，100 台机器负责更新数据库。即便数据库的更新很慢，也不会影响缓存的更新进度。这就是 CQRS 架构的好处，CQ 的架构完全不同，且我们随时可以重建一种新的 Q 端存储。不知道大家体会到了没有?