- 12306的已知信息、数据及问题
- 需求分析（一）—— 售票系统领域知识（区间票、订票、预留票）
- 需求分析（二）—— 涉众、用户体验
- 核心业务逻辑架构分析与设计（子系统分析）
- 需求分析（三）—— 票仓
- 票仓设计（一）—— 预生成车票方案的优缺点
- 票仓设计（二）—— 区间二进制方案的优缺点
- 票仓设计（三）—— 平衡方案的优缺点
- 票务并发冲突处理原则设计（基于平衡方案）
- 缓存逻辑架构设计
- 数据库逻辑设计
- 灾难备份与恢复
常见的设计问题
网络上有不少人曾经提出可以把“车票”预先生成并缓存起来。其实这里典型是出现了线下思维和经验对线上系统设计的阻碍作用。并且是由于对于铁路区间售票的情况了解不充分造成的误解。
从传统经验上，如果某个车次是热门，那么为了加快出票速度（窗口买票速度），车站可以采用事先将一定量的车票打印完毕，从而节约一点售票环节和时间。
这里的前提是能预测并估算数一定量的“车票”。这种功能在12306系统里也是一种可选的功能，但是绝不是能立刻实现的。因为准确估计要生成哪些“车票”并不容易。或者应当有一种调节机制来发挥作用，当预估的车票与实际订票请求冲突时候的动态调节。
所以本系列会给予不生成固定车票的方式。当然，也欢迎讨论各种车票的实现方式。
最理想的设计目标，是能够在某些优化策略的指导下，尽量满足乘客的购票要求。而不是硬性将所有车票的组合事先规定
区间票
假设北京到广州是直达，并且只有一个座位，那么最多只能卖出一张票。
如果中间停武汉，则可能一个人先买了北京到武汉的票，此时从武汉到广州的运力完全支持另一个人买一张从武汉到广州的票。
我们这里可以看到“车票”和“座位”之间不是一个概念了。
以北京到广州的K598/599为例：
一共有25站，用排列组合可知理论上有24+23+22+21+… +3+2+1 = 300种不同起点和终点的“车票”可以卖。并且这仅仅是一个“座位”
如果这趟车有2000个“座位”，那么用这种最原始的“车票”对应方式，当我们打算事先缓存所有车票的时候，将面对60万行数据。
要知道这只是一个车次的一次运营。
实际上不是每个车次都有那么多站,估计平均而言10个站,那么"车票"和"座位"的比例就是45：1.
停靠站不超过64站（6245是62站，实际上超过30站的很少）
引用自 园友buzzlight
按照博文1的推算，春运期间会有大致100万运营车次。那么总体数据行数将将是
100万车次 * 2000座/车次 * 45票/座 = 900亿票。
每行“车票”如果是64Byte, 900亿行是：900亿*64Byte=57600亿B=56.25亿KB=549万MB=5364GB=5.24TB
当然，这个5TB只是比较极端的估计，精简以后可能会少很多，但是任何想事先生成并缓存“车票”的方案，要实际估算一下可能的内存使用状况。
(按照最新的数据估算，可能只有10-20万车次在整个春运期间，所以对应的内存占用可以降低到20%，暨1TB左右。)
此外，由于分段车票之间的关联性，如果某个区间的票给卖完了，其他相关的票也就自动不可能有用了。因此每张“车票”被标记为已售出的时候，同时需要标记另外很多票已经无效。这也是使用预缓存模式的一个难点。
完美支持任意区间票的发售,这个应该是一个完美系统所应该做到的需求.
不很了解目前铁路售票系统在发售区间票上面能支持到怎样的程度。
如果能有一个完美的区间票优化售票逻辑，只要能因此提升1%的客运能力，那将是多大的经济效益啊？3亿？小问题了不是？
订票/锁票
在电商网站上，当查询结果告诉你当前有货，然后等你完成支付以后却告诉你没货了。
愤怒了，有木有？！
场景1（铁路售票窗口处）：
购票者：到武昌的K598硬座有票吗？
售票窗口：有，要几张？
购票者：3张
售票窗口：462元
购票者递钱
售票窗口打印车票
即使是现在，铁路售票大厅也是联网的。从上述黄色的时间点开始，到绿色的时间点结束，是整个售票过程的关键步骤。
需要大家思考的问题是：
在购票者告知需要3张票之后到实际打印车票结束，如果此时K598次硬座真的只有最后3张票了，系统是否要保证这个购票者必须能买到票？
场景2（铁路售票窗口处）：
购票者：到武昌的K598硬座有票吗？
售票窗口：有，要几张？
购票者：3张
售票窗口：只有2张了要吗？
购票者：要（同时递钱）
售票窗口打印车票
需要大家思考的问题是：
对比第一个场景，售票窗口收钱的时候，凭什么不担心三张票被其他人抢走？
场景2的时候，售票窗口为什么也不担心查询出来的两张票不被其他人抢走？
答案是，对于售票窗口而言，查询余票量和订票是两个业务操作，一个不影响余票额，另一个却会临时锁定车票。
当购票人提供所有购票信息后，系统执行的是订票/锁票功能，对于其他窗口而言，这个区段已经不能销售了。直到该窗口释放这个区段，其他窗口才能再次销售。
因此，特定车次的余票量，可能在瞬间变成无票，但是过一阵子又是有票的。所以即使你排队在我前面，也可能我能买到而你被告知没有票了。
这个逻辑应该是合理的，否则售票大厅每天都要上演全武行的。
保留票
可能没这个专业术语，我只是用来描述有些票其实是有，但就是不卖给你。呵呵
不少人都感觉铁路售票应该就和淘宝商卖东西差不多，有多少库存放出来，然后大家先到先得。
朴素的共产主义思想……
实际情况，要么你自己到铁路售票大厅去体验一下，要么看我慢慢道来。
1、保定有牛人组团买光了所有北京到广州的票，导致某次列车出北京的时候是空车出去的。北京售票大厅里面会是啥景象？
2、北京有牛人组团买光了所有北京到广州的票，你在保定你着急不？
所以按照历史统计数据，必须让各个停靠站能有一定量本站起点的车票可卖，否则沿途城市的人民群众不答应或者始发站的百姓们要闹事。
3、由于种种原因，某个途径站出现了旅客暴增或积压（比如当地长途汽车站突然瘫痪），假设是许昌。铁道部特地临时加挂两节车厢，用于疏散这200个人。好么，票刚上网，结果许昌的售票大厅才买了10张，就被武昌的哥们刷光了。
特定时期，一些票必须在指定车站，甚至指定售票窗口销售。
目前由于不是纯网络售票，所以这个问题不着急。不过据说这次新系统就是开始有这个打算了。呵呵，太极的哥们要慎重啊。
理想中的区间票价格
如果同样的起点和终点，买一张票的价格比分段买两张要便宜。很好理解，如果第二张卖不出去，只卖第一张其实铁道部略有不爽，因为运力放空了。
我个人感觉本着提高运力使用效率角度出发，最理想情况下第二张票的价格应该是浮动的。
本质就是利用价格杠杆来引导乘客购票决定，从而提高运力使用效率。
比如有人要买K598次的票，不过只是要到石家庄。此时有票，但是如果卖给他，铁路部门要承担这个座位从石家庄以后就没人买的风险，同时可能一个潜在的要买北京到广州全程的乘客将遇到买票困难。
如果此时刚好有另一个车次，发车和到达时间接近用户的需要，其中的北京到石家庄段的座位是空闲的，而且这个座位的其他区段也是被订购过的，那么推荐这个乘客去买这张车票对铁路部门就是有意义的。
由于这个空座位已经卖出了一张加价的区间票，则第二张票可以按正常价格并扣减对应里程价格来卖。这样一来，铁道部相当于卖了一张大区间票，价格上没有损失。
如果按这种价格策略卖了几张票，最终形成整个路线上没有放空，则总体票价和应该等于正常票价。
而且进一步考虑，其实针对那些购买区间票的乘客，铁路部门需要额外增加的成本基本是0。如果能充分发挥复合售票的威力，那么最终可以降低车次或车厢数量，从而节约运营成本。因此从第二张区间票开始卖得甚至比标准票价低10%也是可以接受的。不过这个目标似乎有点需要论证，减少车次不是那么简单的事情。
因此在信息系统上花的钱，可以从运营中慢慢收回，可以让乘客获得感觉上更贴心的售票服务。
最优出票策略（算法）
上面在谈区间票价格的时候，其实已经涉及到了一个概念：如何最优化出票。
这个策略应该是12306的核心知识产权之一了。并且这应该是一个具有学习能力的系统，能通过历史积累数据挖掘出有用的数据信息提供预测。如果能够证明因为出票算法导致能提高上座率，降低运营成本，3亿？毛毛雨吧？如果真有谁能做到提高运力使用率1%？
当然，由于出票顺序不同，已经确定座位的车票无法进行优化。优化一定要在座位没有确定时候才能实施。或者在出票时至少能有一个次优的选择。
售票系统算法质量评判指标
这个是自己YY的，大家想想还有其他啥指标？其实指标想多了，算法的方向也就慢慢清晰了。
假设一共2个座位，卖了两张票，路线一共是5个区间。
座位空置率
座位空置率 = （列车座位总数*区间总数 - 对应车票区间累计总数）/列车座位总数*区间总数*100%
如果两张票区段有重叠，各自是3个区间。
空置率 = （10-6）/ 10 = 40%
如果两张票区段没重叠，各自是2个区间。
空置率 = （10-4）/ 10 = 60%
这个指标过高可能表示路线设置有问题。比如某条线的前1/3段上座率一直偏低，那么可能就是要增加后2/3的更短的线路，同时可以降低此线路的运力。
座位复用率
座位复用率 =（单次列车运行总出票数量-列车总曾经有人的座位数）/ 列车总曾经有人的座位数 *100%
如果两个人的区段不重合，则复用率应该是100%。
如果两张票各占一个位置，则复用率是0%
当空置率大于等于50%，而复用率等于0或过小，出票算法的策略就有待优化。
座位冗余度
座位冗余度 = 所有未售出的区间座位，组合而成的全程为空的座位数/列车总座位数 * 100%
其实如果所有座位都卖掉了，就是运力紧张的一个信号。
再充分保证座位复用率的前提下，合理情况应该有一定比例的座位保持全程空座。比如5%。
这个指标能成为铁路自动化调度的一个尝试。
要过节了,所以赶着把第二篇弄上来. 节日期间可能更新没那么快,虽然宅家里,不过还是有其他事情的么.
最后，再次感谢各位大大来访
谢谢。