瞎扯淡 也来谈谈怎么解决 12306 的问题

zhangjinzhu · 2014年01月10日 · 最后由 pynix 回复于 2014年03月01日 · 11422 次阅读
本帖已被管理员设置为精华贴

其实我感觉 12306 还是挺好的,当然因为火车动力不足的问题导致不能所有人都买到车票, 这不是一个网站可以解决的

12306 最大的矛盾就是他丫的买不到票,然后还不停的当机,你要不停的刷,各种工具来刷,这样子最直接的负面影响就是大家都在刷,都变慢了。。。。然后还是买不到票。。。。!!!

我想了下,感觉换个技术方案应该可以搞定这个事情, 大家来讨论下:

把买票的流程调整为:

1)选择车票,提交订单,预约车票成功,以预约时间为队列排队。
2)12306 捏合订单
3)如果捏合成功:
    如果第一步已经付款,就直接出票,通知用户。
    如果第一步未付款,就通知用户付款,保留车票四小时。
    如果用户四小时内未付款,而取消该订单,把保留的车票释放
4)如果捏合失败,就继续等待

其实对于火车票来说捏合订单应该是一个难点,怎么在最大的收益的情况下拉最多的人/或者说拉最多最需要火车票的人(因为近的人还有备选方案,例如汽车,发达地区如上海到北京之间可以选择飞机)

如果 12306 可以根据当前的排队情况来自由的匹配订单,应该也可以很好的解决这些问题。

对于刷票,黄牛票,如果在第一步使用队列的话,让他们刷呗,反正对于大家来说都是平等的,他刷了也不影响以前的人的排队顺序,也不能倒卖车票,因为他退票之后,会卖给队列中的第一个人,而不是最近来网站买票的人。 在没有利益驱动的情况下,应该就不会有黄牛票了。

并且因为需要在第一步提交身份证信息,这时 12306 利用自己的优势,做个身份证校验应该不难吧,反正也不需要实时校对。

当然也可以把上面的流程给优化一下,如果用户量不大的情况完成实时出票

或者细节上做些优化,例如提供几个火车票的线路备选方案,优先买某个票之类的,约定一段时间内订单有效,超出时间买不到票自动退款,大家用起来应该也都挺爽的,12306 也挨少些骂。。。。

然后因为第一步会预收款(应该大部分人会选择这样),对铁道部来说也能赚点利息,至少通知用户的短信钱肯定赚回来了,然后大家也不刷票了,就排队等呗,请求数也会少很多,硬件也可以节省开支,网站下再加点年货广告,各种广告啥的,赚点小钱,降低下自己的负债,多好。。。

大家感觉可行性怎样?

还不如抢票,这个等于是所有票放一起来一次 constraint solving 求最佳,估计不可行。而且有的人前一张票买到了,后一张买不到也很悲剧

其实不用那么多废话,建仓库,写代码,跑起来看看到底能不能撑住不就得了

还不如抢票,这个等于是所有票放一起来一次 constraint solving 求最佳,估计不可行

这个不是一次 constraint solving,举个例子, 广州到北京有 1000 张票,中间经过杭州,济南。

因为 12306 要保留一个路段的票,例如济南到北京 200 张,而现实情况是,可能是杭州到北京的票没有那么多人买,反而杭州到济南,济南到北京的人很多。这个捏合就是为了解决这个问题。

所以这个捏合的过程就类似,我保留广州到杭州 50 张最低票,杭州到济南 50 张最低票,济南到北京 50 张最低票。其它的票都用来做捏合用。如果碰到几个人刚好满程,则捏合买出一张票。如果在领近火车要开了,则开始最大利益捏合。怎么捏合赚钱多,怎么捏合。

当然这个过程也可以考虑一些其它的因为,例如上面说的:

其实对于火车票来说捏合订单应该是一个难点,怎么在最大的收益的情况下拉最多的人/或者说拉最多最需要火车票的人(因为近的人还有备选方案,例如汽车,发达地区如上海到北京之间可以选择飞机)

不过这不过是细节了

而且有的人前一张票买到了,后一张买不到也很悲剧

可以退票啊

#3 楼 @zhangjinzhu 退票就导致不是最佳啊,前面都白搞了

其实不用那么多废话,建仓库,写代码,跑起来看看到底能不能撑住不就得了

这个明显不是一个人可以写代码解决的事情,但是这个方案应该是可以行的通的

#3 楼 @zhangjinzhu 不用捏合啊,不保留票,直接放开抢就完了,反正肯定能卖完的

#5 楼 @zhangjinzhu 明显一个人写代码就能解决的问题,要改的不就订票查票的功能

1 人 x 6 月 可以毫无压力完成

就算 2 个人也最多 24 个月可以完成

退票就导致不是最佳啊,前面都白搞了

不是所有人买票都是为了退票啊,退票也有退票率的啊.

并且可以参考上面 或者细节上做些优化,例如提供几个火车票的线路备选方案,优先买某个票之类的,约定一段时间内订单有效,超出时间买不到票自动退款,大家用起来应该也都挺爽的,12306 也挨少些骂。。。。

这个也可以解决 前一张票买到了,后一张买不到的问题

不用捏合啊,不保留票,直接放开抢就完了,反正肯定能卖完的

现在的问题是你抢不过黄牛,他们不断的抢票,退票买给其它人

#9 楼 @zhangjinzhu 现在不是已经退票后,延迟放票了么 ...

明显一个人写代码就能解决的问题,要改的不就订票查票的功能

不解决黄牛的问题,明显无解。因为大众和他们的技术水平不在同一起跑线上.

还是抢不过他们,最后找他们买票

现在不是已经退票后,延迟放票了么 ...

这个也不是最佳解决方案啊,因为黄牛有客户后,他们再用真实的身份证开抢。。。还是无解

13 楼 已删除

12306 的问题 不是技术问题,是人和利益的问题!

@bhuztez 很明显,这是不对的,黄牛更多之后,对黄牛的要求也更多了。 你可以把现在每一个买票的人都看成黄牛,结果因为有的黄牛技术高,所以能买到票,有的黄牛技术低买不到。

这样子还是不公平的。因为你可以认识的黄牛水平太低了! XD

@miclle 其实我乐观的认为 12306 还是想解决这个问题的。

16 楼 已删除

@bhuztez 然后那个高水平的黄牛也要有 VIP 收费用户了。。。 然后其它这个黄牛其实是 12306 的一个子公司么?

LZ 可以去知乎看下这个问题。 12306 外包给阿里巴巴、IBM 等大企业做是否可行? http://www.zhihu.com/question/22451397 这根本就不是 12306 能靠技术解决的问题。

19 楼 已删除

同意 已经不是技术能解决的问题了 传统文化、社会道德、区域发展

硬件问题光靠软件是解决不了的。。。。。。

@jjzxcc @ChanceDoor

运力问题不是技术能解决的,但是保证用户浪费最少的时间来买火车票,这是他们可以解决的,而不是几天全花在买车票上。

关于用户喜欢不喜欢有一定延迟但不需要再抢的订票方式,这个只有广大的订票的大众最有发言权的,当然我个人是倾向于这样子的。

当然上面也不是纯瞎扯蛋。。。

我也是看了好多有关 12306 的文章,总结的我想象中的最佳方案,欢迎更有建设性的意见。。。

#22 楼 @zhangjinzhu 这也不是运力的问题啊 就为了过年那几天提升铁路运输能力的话,平时就是浪费。还是区域经济发展不平衡的问题

方案 1: 推广 Remote Working -- Office Not Required

方案 2: 抛弃文化本位主义, 全盘西化, 一年假期定好天数你们自己定哪天放...

@ChanceDoor 肯定是动力的问题, 只是这个动力的问题有没有必要修复而已,目前来看修复的成本太高,这里也不谈论各种区域经济发展不平衡的问题,只谈 改进 12306 这个网站而已。

@luikore +12306

#25 楼 @luikore 其实就是怕你们不肯放假才全国统一放假的 ...

这是有没用用心去做的问题,连 ssl 证书都不买一张,还能指望其他的么。

#26 楼 @zhangjinzhu 网站加强实名制监督会不会好点 哪些帐号出现异常数据立马定位查水表

30 楼 已删除

#30 楼 @bhuztez 那也能解释清楚吧 总之提高以之牟利的成本,无利可图是基础,不然再怎么研究技术改进也是徒劳

#26 楼 @zhangjinzhu 火车动力不足是怎么分析出来的?我对这个更感兴趣

其实可能有更好的解决方案的,像飞机订票一样,国外的铁路订票系统都可以提前几个月买票,如果你铁定年底要回家,那提早买票,压力分散了问题不就缓解了吗?反正都是实名制,也不怕黄牛税存票。

再加上和飞机票相似的退票策略,比如提前一个月退票,拿回 70%,提前一周退票只拿回 20% 之类的,哪个黄牛会做亏本的买卖?

@shiny SSL 证书这个。。。。。 fuck

@ChanceDoor 12306 这多用访问量,估计连联网校验身份证信息都来不及。。。。如果不连网校验,黄牛还是可以用自动生成的身份证号来买票。。。

所以要想想怎么从技术上来杜绝黄牛抢票,卖票,上面的解决方案应该可以解决这个问题

@ChanceDoor 撒欢的买,看看是不是最后有人买不到票,有人买不到就是动力不足呗。。。。 动力不足应该很明显,因为春运的车上都是超级满吧!

@Peter 嗯,这个应该可以,退票扣钱,不过不知道这部分成本会不会转移到用户身上。。。应该是肯定会的。。。。

开放私营铁路,民营部分完全由市场定价,参考机票,也许就能分摊点压力了。

或者开始生产双层火车车厢...

@shiny 民营又不是傻子,其它时间亏钱的活谁干,也就和铁道部来竞争他们能赚钱的话了,铁道部又不是傻子,赚钱的话都给你了,我怎么赚钱补贴不赚钱的活。。。 毕竟铁道部还是有社会责任的,要不就所有的车票和机票一样市场化就好了,价高者得。。。 那估计铁道部被骂的更惨

双层火车车厢是个好主意。。。。。。 不过不知道隧道的高度够不够。。。

#38 楼 @zhangjinzhu 比如说区域间的铁路,或者涉及货运、矿产运输,加点客运也应该不会亏本。日本的铁道公司就分拆民营了。

#25 楼 @luikore

  1. 只有少数几种职业可以这样把。。

  2. public holiday 全世界都有,这个没解决根本问题,而根本问题大家都知道,想改变这个不是一天两天能做完的事情

其实感觉现在比以前好很多了。没有网上售票的时候除了黄牛没别的选。。 16个小时的火车站过两回……

http://news.hexun.com/2014-01-04/161148561.html 2008 年还很难进入,「10 年左右的时间就能收回铁路的所有投资成本」 应该还算不错了。现在的问题是管制太多,而不是铁路投资亏损。

或者比如特等座采用机票的方式预订,普通票维持不变。

只是里面涉及的利益关系太多了

如果出个某时间段买的票不准退的规定那么可能就没这么多的事情了

@shiny 嗯,这个民营铁路应该也是货运的,

我刚刚看了几篇日本铁路民营化的文章,上面也有偏远的路线,因为亏钱民营不想做的问题,所以民营来竞争的也就是些赚钱的事情,但如果你是铁道道的人,你会怎么做? 现在铁路部门毕竟也是个公司了,也要从公司的利益出发。

不知道靠出租部分线路建设的铁轨,会不会赚到钱。或者有其它更好的思路。。。不过这个不在我们技术人员考虑的范畴。。。。

@small_fish__ 那又要变成一个新骂点了。。。。

#47 楼 @zhangjinzhu 谁会去骂?只是特殊的这个月而已嘛。。你要买就考虑清楚在买。。

#46 楼 @zhangjinzhu 强制压低价格固然有利于民众,但是黄牛在不完全的市场经济里的出现可以说是必然的,也是市场调节的一部分,有需求就有市场。 唉,其实我们搞技术的能让民众舒舒服服抢票就不错了。

@small_fish__ 黄牛怎么混,他们会一个人骂,肯定会煽动一批不明真相的群众骂。。。做为普通用户来说,我买了票,不让我退,我不骂你。。。哪怕扣我点手续费呢。。。。。

可是扣手续费就又出来黄牛转移成本的问题了。。。

@shiny 所以我们搞技术的就是尽量给大家一个公平的环境来竞争而已,就像电商的秒杀一样,尽可能的封秒杀软件。

#50 楼 @zhangjinzhu 国外铁路和国际上的机票都是这么做的, 你要买可以退的票,可以,加钱, 如果买不可以退的票就会很便宜。

这样黄牛不可能买这种 不可以退的票 那种可以退的票再加上退票策略,基本上就应该没什么人出来跳了。

@Peter 嗯,这样子肯定是有效的,不过在一个供小于求的前提下,黄牛仍然有盈利的基础

想的太简单了呀。。。

@zeeler 欢迎指出那里不够。。。

#55 楼 @zhangjinzhu http://coolshell.cn/articles/6470.html 这是个酷壳对早期 12306 的一个简单分析,可以参考一下;另外,我们都不了解铁路的网络系统架构、数据存储方式、各地的票务份额等等很多复杂的东西就来讨论,所以我说想的太简单了。就拿预约时间来说吧,怎么算,是提交时间还是服务器接收到的时间?车票的数据处理如何做的,是有几个大节点还是集中在某个数据中心?数据如何在高速变化中保持同步?每个不同地区的人订票指令到达时间是否有不同,靠近数据中心的是否更占便宜?数据中心带宽、交换机是否扛得住 (疯狂的订票请求相当于 DDOS 攻击了)?订票后大量的支付请求各银行的支付网关是否能扛得住?可以想象一下,订票指令在开票时间几乎是同时触发的,这并发量不光是服务器能否受得了,当地带宽是否足够也是问题,有些无法访问不一定是服务器出问题了,可能是带宽的问题,运营商也不可能因为每年一两次的订票而大动干戈把带宽重新分配。。。等等吧,还有若干个问题都不是那么容易解决的;再简单的业务逻辑和流程,一旦碰到井喷式的并发量都会出问题的,不是光靠技术能解决的。比如,现在已经把不同类型车型分时段发放,本身就是分流的策略,当然还可以搞更多的分流。楼主说的第 1) 步就不好实现,这种类似网络攻击式订票请求,任何软硬件都很难说 100% 扛得住。。。

首先你要想这些类似网络攻击式订票请求为什么会来:

1)刷票软件 2)某一个时间释放预留票。 例如预留了 1000 张杭州到北京的票,结果没有人买。 所以就拆分成 1000 张杭州到济南的票,济南到北京的票来买。这个甚至没有规律,可能在不同的时间段放票。所以大家就只能一直请求来查询了。。。

如果解决了上面这两个问题,这个网络攻击式订票请求会不会少很多呢?

就拿预约时间来说吧,怎么算,是提交时间还是服务器接收到的时间?车票的数据处理如何做的,是有几个大节点还是集中在某个数据中心?数据如何在高速变化中保持同步?每个不同地区的人订票指令到达时间是否有不同,靠近数据中心的是否更占便宜?数据中心带宽、交换机是否扛得住 (疯狂的订票请求相当于 DDOS 攻击了)?订票后大量的支付请求各银行的支付网关是否能扛得住?可以想象一下,订票指令在开票时间几乎是同时触发的,这并发量不光是服务器能否受得了,当地带宽是否足够也是问题,有些无法访问不一定是服务器出问题了,可能是带宽的问题,运营商也不可能因为每年一两次的订票而大动干戈把带宽重新分配

这些是问题么? 肯定是服务器接收到的时间啊,服务器排队么,再说排队给你有点误差怎么了?你知道么?

又不是实时处理订单,所以甚至都不存在数据的一致性的问题,也不用担心超买,我保存到不同的机器上,再慢慢的同步数据,慢慢的处理就好了

各银行的支付网关是否能扛得住关我什么事,这也是 12306 的责任?

还是上面说的,完全这样子去掉黄牛的影响,让大家站在同一起跑线上买票,就是完全可以实现的,如果还有问题完全可以一个一个列出来,我也一个一个看看是不是真正的问题还是幻想中的问题。。。

关闭 12306,把票放出来让市场决定。

12306 的问题 不是技术能解决的。图样图森破。

排队还有个问题,窗口买票的兄弟怎么算?

@doun

排队还有个问题,窗口买票的兄弟怎么算?

上面有个例子讲:

所以这个捏合的过程就类似,我保留广州到杭州 50 张最低票,杭州到济南 50 张最低票,济南到北京 50 张最低票。其它的票都用来做捏合用。如果碰到几个人刚好满程,则捏合买出一张票。如果在领近火车要开了,则开始最大利益捏合。怎么捏合赚钱多,怎么捏合。

这 50 张预留票可以窗口买票,并且我看到好多类似的文章,窗口的票和网络的票本来也会分离的,应该是以一定的比例的发售的。以 12306 来说, 以某个比例配票应该也是很简单的。

@hisea

12306 的问题 不是技术能解决的。图样图森破。

我们讨论的问题是在技术能解决的范围内解决 12306 的问题,非技术因素我们不在考虑范围内。

不以事实为凭据的一句 “图样图森破”, 在别人看来就像 “靠工作买不起房子,所以就不用工作了 “一样可笑。。。

那不是技术问题,而是政治经济问题

楼主看看实际系统的部分情况介绍吧,建议你去和淘宝技术团队 pk 一下:http://moni.iteye.com/blog/2001610

@zeeler 淘宝技术团队, IBM 技术团队又不是足下生风,头顶光环。。。

这个连接火的要死,肯定是看过了,但看过之后,没有感觉到这个解决方案有什么问题。。。如果你感觉那里有问题,可以单个问题的指出来。。。

而不是好像你骂 Matz,你的 ruby 写的像屎一样, 然后他问你那里写的像屎, 你扔他一本书《48 小时学会写编程语言》,说自己看吧。。。

我和你简单说一下,为什么这个方案可以:

不是因为排队会减少刷票,黄牛现象,这个只是最表层而已,最根本上是因为延迟的捏合不需要维持 “数据一致性”,因此具有极佳的横向扩展能力,剩下只要堆硬件就够了。

#65 楼 @zhangjinzhu 你的意思是大家上午订票,订单后台 “捏合”,下午运算完后再告诉你的订单是否成功预订?

@zeeler 看运算能力,什么时候能捏合就什么捏合呗

#67 楼 @zhangjinzhu 比如 9 点放票,一下 1000 万订单,你是要等收集到某个数量级订单后去捏合,还是计算时间,比如 5 分钟后开始捏合?捏合并且去数据库分配票时,肯定需要时间,这个过程中如果又有大量订单进入,是排队等下一次捏合怎么样?那用户买票基本上是一锤子买卖了,某车次订不上,等捏合处理完后才知道没订上,再换车次时,另外的车次可能都被卖没了。

@zeeler

比如 9 点放票,一下 1000 万订单,你是要等收集到某个数量级订单后去捏合

为什么会有一个突然的放票呢? 一个放票是因为新加了一天的票, 另一个放票是因为重新分配以后预存不合用户需求的票。 经过捏合后,第二个放票可以很大程度上避免。

还是计算时间,比如 5 分钟后开始捏合?捏合并且去数据库分配票时,肯定需要时间,这个过程中如果又有大量订单进入,是排队等下一次捏合怎么样?

以这个架构,是不需要维护管数据的唯一性的,捏合和订单处理完全不需要同一台机器。你就把捏合的过程看成一个超级后台任务就行。你后面可以再搭一堆机器处理这个后台任务

订单处理就更弱智了,接收用户的请求,给保存下来就行,也完全可以堆机器。

那用户买票基本上是一锤子买卖了,某车次订不上,等捏合处理完后才知道没订上,再换车次时,另外的车次可能都被卖没了。

为什么用户想换车次,因为用户想买到某个地方的票呗,一个车次买不到,换个车次买呗。 多么简单的 ifttt 啊,捏合完成可以搞定这个问题。

#69 楼 @zhangjinzhu 不统一放票公平性何以体现?你是鼓励用户今年就订明年春节的票?总有一个开始的时间点吧,比如什么时间可以开始买 15 年春节的票;另外,每年铁路可能会增加或者变动车次,如果有变更了,但是你的订单已经提交过,就会很不爽;还有,这不是买机票,机票的用户群比较小众,火车票是所有社会层次的都会买,如果没有时间限制,大家也会很早前就开始订,但是可能到要走之前才发现需要变更行程或者退票,实际有迫切需求非常着急的人是买不到票的。不能为了简化技术门槛,而修改需求。

不统一放票公平性何以体现?你是鼓励用户今年就订明年春节的票?总有一个开始的时间点吧,比如什么时间可以开始买 15 年春节的票;

每过一天不就是多放一天的票么?需求没有变啊?

这样的话,就不是刷火车票了,就改成刷排队预约了。。

黄牛抢的是订单。。不是票。。他都不支付的。是有人找他买票了 他才自己退订单自己抢。。你如何杜绝票。就算是撮合。。黄牛那瞬间抢票的功力 他也排在前面啊 也轮不到你。

我觉得如果用类似 emberjs 这种前端 MVC 框架来写,后端再多加一些缓存,肯定情况就会好很多。。。。。。他们肯定没人愿意碰这事。

#72 楼 @cgyqqcgy #73 楼 @luliangshu 可以刷排队,但要卖出去票啊,怎么卖?

楼主说得对,关键还是运输能力,网站只是方便买票,不能解决实际问题。

刷排队预约更不靠谱,这样大部分人都去预约热门车票而又不知道最后能不能买到票,最后的结果只能是每个人都大量预约车票,预约队伍无比的长,而且大部分用户其实只需用几张车票而已。一旦有人退票的结果就是,可能很多用户已经有其他选择而不会选择退票,而且你通知用户有退票总要给人一个小时以上的买票时间吧,而且你还不能半夜通知用户。这样你这排队一天能前进 12 就不错。最后肯定得浪费一大堆票。

不按照队列来做,而是限定时间之前提交的订单都平等处理,避免出现峰值; 买票只选出发和目的地,不能选车次,或者给出所有可能路线,让用户选择优先顺序,尽可能保证到达; 最后系统统一计算出一个最优解,放票之后再进行通知。 好处是尽可能利用运力,不浪费时间,杜绝黄牛,缺点是不透明,没人信。

#78 楼 @code4craft 如果可以严格的时间订票的话,八点开的车,七天前的八点订,下午两点的车,下午两点订。都不应该出现峰值

@zhangjinzhu 这样的话可以是可以,但是不方便,比如我要买两个车次,就得分开两个时间订,唯一方便的估计是黄牛吧

这不是方便了黄牛么,有 4 小时不要钱的 session,直接把所有的坑都占完了就行了,不停的刷。有客户买就给票付钱,不要就 expire 无所谓,继续刷

@code4craft 上面有说 ifttt,可以按这样子来做订票

@Yujing_Z 估计你还没有懂这个流程。。。

有个最最核心的问题,铁道部根本不放出其业务具体逻辑。。 我们自己再这里瞎折腾没太大意义。。。因为业务逻辑不知道,你怎么开发系统?

当然,也许我们可以自己提出一个业务逻辑模型。

那么也许我们可以一起再 github 上开发个开源的动车售票系统 https://github.com/lymanlai/WWTS 刚刚弄上去的。。

目前网络对 12306 已经不是难题了,难还是难在最传统东西,事务处理时效 + 数据库 IO。 由于网络订票系统需要接入已经运行多年的线下实时票务系统,这一部分我觉得在短时间内(一两年)是达不到的,再多钱技术再先进也不行,这时候的顶板是人。

运力和人数之间差距才是主要矛盾,技术解决不了问题。。。。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号