购票系统设计之余票处理

标题购票系统设计之余票处理

一、前言

铁路12306，对于所有人来说是非常熟悉。早些年，经常是一到发票时间，系统就自然崩溃了，让无数人痛骂不止，最终无奈向黄牛低头。最后，阿里程序猿忍不住了，伸出了可爱的小手，无偿帮铁路12306重新优化设计系统，才有了现在的铁路12306。
作为一名程序猿，当然想试一下水，看看其中的难度有多大。很有自知之明，避开了几亿用户这一送命题，就简单做个demo，实现一下基本的买票购票功能。

二、根据现有系统推测功能

一般来说，购票流程应该是这样：
1. 选择两个站点，输入两个开始时间和结束时间，查询对应的车次信息。
2. 选择一个车次，查看对应的一等座、二等座等座位的余票信息。
3. 选择一个有余票的座位类型，随机分配座位，选择一个或多个座位。然后选择对应的用户信息，完成购票订单操作。
4. 在规定时间内，在支付订单界面，选择一个订单，选择付款或者退票，完成最后的流程。
5. 遇到特殊情况，在已支付订单界面，选择一个订单，选择退票或者改签操作。
窥一斑而知全豹，这一个购票流程已经给了我们大致的系统面貌了，那么得出大概的功能设计图：

三、分析系统

让我们在脑海中模拟一下实际的开发过程，先开发后台管理系统。用户、菜单、权限等模块暂时先跳过，毕竟这不是本次思维风暴的重点。站点、列车、车次、座位，嗯，这几个功能模块看上去都是一些简单维护操作，问题不大可以实现。
那就开始模拟用户操作：
第一步根据站点和时间范围选择合适的车次信息，没问题，接着走。
第二步，查看车次的余票情况，咦，查不出来。看来我得加一张用户的购票记录表，记录一下购票情况，才能座位数-已购票数=余票。嗯？我只有开始站点和结束站点的信息，车次会经过N个站点，又不是只有2个站点。要是这样：A站点->B站点 ->C站点 -> D站点->E站点，有人中途买了C->D的座位Z1，那现在要购票从A->D的座位，那应该显示没有余票了。不对，好像有点东西，完了，把自己绕进去了…
Two thousand years later…
唔，一个站点有票，一个站点没有票，那不就是0和1吗？ ABCDE不就代表00000，如果有人买了C->D，那不就是00110，如果又有人买了D->E，那不就是00111。根据二进制的进位原理，C->D，占据了倒数第一位和倒数第三位的位置，对应的最小值应该是00001=1=2^{1-1，最大值应该是00111=7=2}3-1，再结合实际推敲一下，值域应该是[2^3-1,21-1)，下次买票肯定必须不能在这个区间买了，只能是选择两端(+oo,2^3-1)U[21,-oo)。
那在车次表里，在加一个经过站点属性，再加一个座位购票记录表，记录每个座位的购票记录，里面有三个关键属性，A属性用来记录二进制座位情况00000，B属性用来记录当前二进制的最小值（下次买票结束站点转换的二进制值必须小于等于它），C属性用来记录当前二进制的最大值（下次买票的开始站点转换的二进制值必须大于它）。
先查出对应的车次，在根据经过站点，确定两个站点对应的二进制值V1，判断V1是否大于C属性值，V1是否小于等于B属性就可以了。这里使用sql条件查询出对应的座位出来，同一座位的记录数相加等于该座位的余票数。
第三步，选择座位购买，下订单。这一步对应的就是，根据座位id去刷新座位购票记录表的ABC，把A属性对应的0变为1。如果退票，那就是把对应座位的1改为0。
第四步，在半小时内付款，这里累了，没什么好说的了。