12306票务处理功能模块分析
假想完整网络订票流程图
这里实际的用户和系统的交互有4种类型。
1、车次和余额查询
2、订票
3、取消订票
4、确认订票
这里希望广大围观群众都来评估一下这个假设的订票流程及其参数是不是都合理？如果这个流程本身不合理，则我后续的分析都要重写了。不熟悉售票流程的，可以看看我之前的分析文章。
然后我们继续来细化一下
车次和余额查询
输入：起始站，终到站，日期，座位类型集合
输出：车次，对应座位类型可售余额
作用：最终用户根据查询结果选择需要出行的车次，并进一步进入订票操作。但是系统不保证显示为有票的车次在下一步操作中必然有票。
这里其实涉及到两个类型的查询
1、哪些车次符合用户的查询结果，可以通过一个基本固定不变的数据源来提供。而该数据源可以实现分布式缓存以缓解查询压力，甚至可以考虑客户端部分结果缓存。
输入：起始站，终到站，日期
输出 :车次列表，
2、特定车次，特定座位类型的可售票数量。这个数据的来源应该和第一个查询不同。
输入：起始站，终到站，车次，日期
输出：数量
订票(我喜欢称它为锁票)
输入：起始站，终到站，日期，座位类型，需要车票数量，用户ID
输出：实际到的获取车票数量
作用：最终用户通过订票操作，顺利锁定需要数量的车票。系统保证用户在规定的时间段内对这几张车票具有优先订购权利，且其他人不得购买这些车票。
目前我感觉留给用户10-15分钟时间继续后续操作，以进入支付环节（当然，这必须是在系统本身性能良好条件下。否则点个按钮就要等10分钟，那就不对了。）
同时如果超时，则系统会在后续订票操作中忽视该锁定状态。
取消订票
输入：起始站，终到站，日期，座位类型，数量，用户ID
输出：成功标志
作用：用户放弃已经获得的被锁定的售票权利，系统恢复对应的数据为可售。
确认订票（确认支付）
输入：起始站，终到站，日期，座位类型，数量，用户ID，支付相关信息
输出：成功标志/确认失败（刚好锁定超时，且被他人订走）
作用：最终确认售票，系统向第三方支付服务提交确认请求。
