瞎扯淡 也来谈谈怎么解决 12306 的问题
其实我感觉 12306 还是挺好的，当然因为火车动力不足的问题导致不能所有人都买到车票，这不是一个网站可以解决的
12306 最大的矛盾就是他丫的买不到票，然后还不停的当机，你要不停的刷，各种工具来刷，这样子最直接的负面影响就是大家都在刷，都变慢了。。。。然后还是买不到票。。。。！！！
我想了下，感觉换个技术方案应该可以搞定这个事情，大家来讨论下：
把买票的流程调整为：
1）选择车票，提交订单，预约车票成功，以预约时间为队列排队。
2）12306 捏合订单
3）如果捏合成功：
如果第一步已经付款，就直接出票，通知用户。
如果第一步未付款，就通知用户付款，保留车票四小时。
如果用户四小时内未付款，而取消该订单，把保留的车票释放
4）如果捏合失败，就继续等待
其实对于火车票来说捏合订单应该是一个难点，怎么在最大的收益的情况下拉最多的人/或者说拉最多最需要火车票的人（因为近的人还有备选方案，例如汽车，发达地区如上海到北京之间可以选择飞机）
如果 12306 可以根据当前的排队情况来自由的匹配订单，应该也可以很好的解决这些问题。
对于刷票，黄牛票，如果在第一步使用队列的话，让他们刷呗，反正对于大家来说都是平等的，他刷了也不影响以前的人的排队顺序，也不能倒卖车票，因为他退票之后，会卖给队列中的第一个人，而不是最近来网站买票的人。 在没有利益驱动的情况下，应该就不会有黄牛票了。
并且因为需要在第一步提交身份证信息，这时 12306 利用自己的优势，做个身份证校验应该不难吧，反正也不需要实时校对。
当然也可以把上面的流程给优化一下，如果用户量不大的情况完成实时出票
或者细节上做些优化，例如提供几个火车票的线路备选方案，优先买某个票之类的，约定一段时间内订单有效，超出时间买不到票自动退款，大家用起来应该也都挺爽的，12306 也挨少些骂。。。。
然后因为第一步会预收款（应该大部分人会选择这样），对铁道部来说也能赚点利息，至少通知用户的短信钱肯定赚回来了，然后大家也不刷票了，就排队等呗，请求数也会少很多，硬件也可以节省开支，网站下再加点年货广告，各种广告啥的，赚点小钱，降低下自己的负债，多好。。。
大家感觉可行性怎样？
还不如抢票，这个等于是所有票放一起来一次 constraint solving 求最佳，估计不可行
这个不是一次 constraint solving，举个例子，广州到北京有 1000 张票，中间经过杭州，济南。
因为 12306 要保留一个路段的票，例如济南到北京 200 张，而现实情况是，可能是杭州到北京的票没有那么多人买，反而杭州到济南，济南到北京的人很多。这个捏合就是为了解决这个问题。
所以这个捏合的过程就类似，我保留广州到杭州 50 张最低票，杭州到济南 50 张最低票，济南到北京 50 张最低票。其它的票都用来做捏合用。如果碰到几个人刚好满程，则捏合买出一张票。如果在领近火车要开了，则开始最大利益捏合。怎么捏合赚钱多，怎么捏合。
当然这个过程也可以考虑一些其它的因为，例如上面说的：
其实对于火车票来说捏合订单应该是一个难点，怎么在最大的收益的情况下拉最多的人/或者说拉最多最需要火车票的人（因为近的人还有备选方案，例如汽车，发达地区如上海到北京之间可以选择飞机）
不过这不过是细节了
而且有的人前一张票买到了，后一张买不到也很悲剧
可以退票啊
退票就导致不是最佳啊，前面都白搞了
不是所有人买票都是为了退票啊，退票也有退票率的啊。
并且可以参考上面 或者细节上做些优化，例如提供几个火车票的线路备选方案，优先买某个票之类的，约定一段时间内订单有效，超出时间买不到票自动退款，大家用起来应该也都挺爽的，12306 也挨少些骂。。。。
这个也可以解决 前一张票买到了，后一张买不到的问题
明显一个人写代码就能解决的问题，要改的不就订票查票的功能
不解决黄牛的问题，明显无解。因为大众和他们的技术水平不在同一起跑线上。
还是抢不过他们，最后找他们买票
LZ 可以去知乎看下这个问题。 12306 外包给阿里巴巴、IBM 等大企业做是否可行？ http://www.zhihu.com/question/22451397 这根本就不是 12306 能靠技术解决的问题。
运力问题不是技术能解决的，但是保证用户浪费最少的时间来买火车票，这是他们可以解决的，而不是几天全花在买车票上。
关于用户喜欢不喜欢有一定延迟但不需要再抢的订票方式，这个只有广大的订票的大众最有发言权的，当然我个人是倾向于这样子的。
方案 1: 推广 Remote Working -- Office Not Required
方案 2: 抛弃文化本位主义，全盘西化，一年假期定好天数你们自己定哪天放...
@ChanceDoor 肯定是动力的问题，只是这个动力的问题有没有必要修复而已，目前来看修复的成本太高，这里也不谈论各种区域经济发展不平衡的问题，只谈 改进 12306 这个网站而已。
@luikore +12306
其实可能有更好的解决方案的，像飞机订票一样，国外的铁路订票系统都可以提前几个月买票，如果你铁定年底要回家，那提早买票，压力分散了问题不就缓解了吗？反正都是实名制，也不怕黄牛税存票。
再加上和飞机票相似的退票策略，比如提前一个月退票，拿回 70%，提前一周退票只拿回 20% 之类的，哪个黄牛会做亏本的买卖？
@shiny SSL 证书这个。。。。。fuck
@ChanceDoor 12306 这多用访问量，估计连联网校验身份证信息都来不及。。。。如果不连网校验，黄牛还是可以用自动生成的身份证号来买票。。。
所以要想想怎么从技术上来杜绝黄牛抢票，卖票，上面的解决方案应该可以解决这个问题
@ChanceDoor 撒欢的买，看看是不是最后有人买不到票，有人买不到就是动力不足呗。。。。动力不足应该很明显，因为春运的车上都是超级满吧！
@Peter 嗯，这个应该可以，退票扣钱，不过不知道这部分成本会不会转移到用户身上。。。应该是肯定会的。。。。
@shiny 民营又不是傻子，其它时间亏钱的活谁干，也就和铁道部来竞争他们能赚钱的话了，铁道部又不是傻子，赚钱的话都给你了，我怎么赚钱补贴不赚钱的活。。。毕竟铁道部还是有社会责任的，要不就所有的车票和机票一样市场化就好了，价高者得。。。那估计铁道部被骂的更惨
只有少数几种职业可以这样把。。
public holiday 全世界都有，这个没解决根本问题，而根本问题大家都知道，想改变这个不是一天两天能做完的事情
其实感觉现在比以前好很多了。没有网上售票的时候除了黄牛没别的选。。16个小时的火车站过两回……
http://news.hexun.com/2014-01-04/161148561.html 2008 年还很难进入，「10 年左右的时间就能收回铁路的所有投资成本」 应该还算不错了。现在的问题是管制太多，而不是铁路投资亏损。
@shiny 嗯，这个民营铁路应该也是货运的，
我刚刚看了几篇日本铁路民营化的文章，上面也有偏远的路线，因为亏钱民营不想做的问题，所以民营来竞争的也就是些赚钱的事情，但如果你是铁道道的人，你会怎么做？现在铁路部门毕竟也是个公司了，也要从公司的利益出发。
不知道靠出租部分线路建设的铁轨，会不会赚到钱。或者有其它更好的思路。。。不过这个不在我们技术人员考虑的范畴。。。。
#46 楼 @zhangjinzhu 强制压低价格固然有利于民众，但是黄牛在不完全的市场经济里的出现可以说是必然的，也是市场调节的一部分，有需求就有市场。 唉，其实我们搞技术的能让民众舒舒服服抢票就不错了。
@small_fish__ 黄牛怎么混，他们会一个人骂，肯定会煽动一批不明真相的群众骂。。。做为普通用户来说，我买了票，不让我退，我不骂你。。。哪怕扣我点手续费呢。。。。。
可是扣手续费就又出来黄牛转移成本的问题了。。。
#50 楼 @zhangjinzhu 国外铁路和国际上的机票都是这么做的， 你要买可以退的票，可以，加钱， 如果买不可以退的票就会很便宜。
这样黄牛不可能买这种 不可以退的票
那种可以退的票再加上退票策略，基本上就应该没什么人出来跳了。
#55 楼 @zhangjinzhu http://coolshell.cn/articles/6470.html 这是个酷壳对早期 12306 的一个简单分析，可以参考一下；另外，我们都不了解铁路的网络系统架构、数据存储方式、各地的票务份额等等很多复杂的东西就来讨论，所以我说想的太简单了。就拿预约时间来说吧，怎么算，是提交时间还是服务器接收到的时间？车票的数据处理如何做的，是有几个大节点还是集中在某个数据中心？数据如何在高速变化中保持同步？每个不同地区的人订票指令到达时间是否有不同，靠近数据中心的是否更占便宜？数据中心带宽、交换机是否扛得住 (疯狂的订票请求相当于 DDOS 攻击了)？订票后大量的支付请求各银行的支付网关是否能扛得住？可以想象一下，订票指令在开票时间几乎是同时触发的，这并发量不光是服务器能否受得了，当地带宽是否足够也是问题，有些无法访问不一定是服务器出问题了，可能是带宽的问题，运营商也不可能因为每年一两次的订票而大动干戈把带宽重新分配。。。等等吧，还有若干个问题都不是那么容易解决的；再简单的业务逻辑和流程，一旦碰到井喷式的并发量都会出问题的，不是光靠技术能解决的。比如，现在已经把不同类型车型分时段发放，本身就是分流的策略，当然还可以搞更多的分流。楼主说的第 1) 步就不好实现，这种类似网络攻击式订票请求，任何软硬件都很难说 100% 扛得住。。。
首先你要想这些类似网络攻击式订票请求为什么会来：
1）刷票软件 2）某一个时间释放预留票。例如预留了 1000 张杭州到北京的票，结果没有人买。所以就拆分成 1000 张杭州到济南的票，济南到北京的票来买。这个甚至没有规律，可能在不同的时间段放票。所以大家就只能一直请求来查询了。。。
如果解决了上面这两个问题，这个网络攻击式订票请求会不会少很多呢？
就拿预约时间来说吧，怎么算，是提交时间还是服务器接收到的时间？车票的数据处理如何做的，是有几个大节点还是集中在某个数据中心？数据如何在高速变化中保持同步？每个不同地区的人订票指令到达时间是否有不同，靠近数据中心的是否更占便宜？数据中心带宽、交换机是否扛得住 (疯狂的订票请求相当于 DDOS 攻击了)？订票后大量的支付请求各银行的支付网关是否能扛得住？可以想象一下，订票指令在开票时间几乎是同时触发的，这并发量不光是服务器能否受得了，当地带宽是否足够也是问题，有些无法访问不一定是服务器出问题了，可能是带宽的问题，运营商也不可能因为每年一两次的订票而大动干戈把带宽重新分配
这些是问题么？肯定是服务器接收到的时间啊，服务器排队么，再说排队给你有点误差怎么了？你知道么？
又不是实时处理订单，所以甚至都不存在数据的一致性的问题，也不用担心超买，我保存到不同的机器上，再慢慢的同步数据，慢慢的处理就好了
各银行的支付网关是否能扛得住关我什么事，这也是 12306 的责任？
还是上面说的，完全这样子去掉黄牛的影响，让大家站在同一起跑线上买票，就是完全可以实现的，如果还有问题完全可以一个一个列出来，我也一个一个看看是不是真正的问题还是幻想中的问题。。。
排队还有个问题，窗口买票的兄弟怎么算？
上面有个例子讲：
所以这个捏合的过程就类似，我保留广州到杭州 50 张最低票，杭州到济南 50 张最低票，济南到北京 50 张最低票。其它的票都用来做捏合用。如果碰到几个人刚好满程，则捏合买出一张票。如果在领近火车要开了，则开始最大利益捏合。怎么捏合赚钱多，怎么捏合。
这 50 张预留票可以窗口买票，并且我看到好多类似的文章，窗口的票和网络的票本来也会分离的，应该是以一定的比例的发售的。以 12306 来说，以某个比例配票应该也是很简单的。
12306 的问题 不是技术能解决的。图样图森破。
我们讨论的问题是在技术能解决的范围内解决 12306 的问题，非技术因素我们不在考虑范围内。
不以事实为凭据的一句“图样图森破”，在别人看来就像“靠工作买不起房子，所以就不用工作了“一样可笑。。。
@zeeler 淘宝技术团队，IBM 技术团队又不是足下生风，头顶光环。。。
这个连接火的要死，肯定是看过了，但看过之后，没有感觉到这个解决方案有什么问题。。。如果你感觉那里有问题，可以单个问题的指出来。。。
而不是好像你骂 Matz，你的 ruby 写的像屎一样，然后他问你那里写的像屎，你扔他一本书《48 小时学会写编程语言》，说自己看吧。。。
我和你简单说一下，为什么这个方案可以：
不是因为排队会减少刷票，黄牛现象，这个只是最表层而已，最根本上是因为延迟的捏合不需要维持“数据一致性”，因此具有极佳的横向扩展能力，剩下只要堆硬件就够了。
#67 楼 @zhangjinzhu 比如 9 点放票，一下 1000 万订单，你是要等收集到某个数量级订单后去捏合，还是计算时间，比如 5 分钟后开始捏合？捏合并且去数据库分配票时，肯定需要时间，这个过程中如果又有大量订单进入，是排队等下一次捏合怎么样？那用户买票基本上是一锤子买卖了，某车次订不上，等捏合处理完后才知道没订上，再换车次时，另外的车次可能都被卖没了。
比如 9 点放票，一下 1000 万订单，你是要等收集到某个数量级订单后去捏合
为什么会有一个突然的放票呢？一个放票是因为新加了一天的票，另一个放票是因为重新分配以后预存不合用户需求的票。经过捏合后，第二个放票可以很大程度上避免。
还是计算时间，比如 5 分钟后开始捏合？捏合并且去数据库分配票时，肯定需要时间，这个过程中如果又有大量订单进入，是排队等下一次捏合怎么样？
以这个架构，是不需要维护管数据的唯一性的，捏合和订单处理完全不需要同一台机器。你就把捏合的过程看成一个超级后台任务就行。你后面可以再搭一堆机器处理这个后台任务
订单处理就更弱智了，接收用户的请求，给保存下来就行，也完全可以堆机器。
那用户买票基本上是一锤子买卖了，某车次订不上，等捏合处理完后才知道没订上，再换车次时，另外的车次可能都被卖没了。
为什么用户想换车次，因为用户想买到某个地方的票呗，一个车次买不到，换个车次买呗。多么简单的 ifttt 啊，捏合完成可以搞定这个问题。
#69 楼 @zhangjinzhu 不统一放票公平性何以体现？你是鼓励用户今年就订明年春节的票？总有一个开始的时间点吧，比如什么时间可以开始买 15 年春节的票；另外，每年铁路可能会增加或者变动车次，如果有变更了，但是你的订单已经提交过，就会很不爽；还有，这不是买机票，机票的用户群比较小众，火车票是所有社会层次的都会买，如果没有时间限制，大家也会很早前就开始订，但是可能到要走之前才发现需要变更行程或者退票，实际有迫切需求非常着急的人是买不到票的。不能为了简化技术门槛，而修改需求。
不统一放票公平性何以体现？你是鼓励用户今年就订明年春节的票？总有一个开始的时间点吧，比如什么时间可以开始买 15 年春节的票；
每过一天不就是多放一天的票么？需求没有变啊？
黄牛抢的是订单。。不是票。。他都不支付的。是有人找他买票了 他才自己退订单自己抢。。你如何杜绝票。就算是撮合。。黄牛那瞬间抢票的功力 他也排在前面啊 也轮不到你。
刷排队预约更不靠谱，这样大部分人都去预约热门车票而又不知道最后能不能买到票，最后的结果只能是每个人都大量预约车票，预约队伍无比的长，而且大部分用户其实只需用几张车票而已。一旦有人退票的结果就是，可能很多用户已经有其他选择而不会选择退票，而且你通知用户有退票总要给人一个小时以上的买票时间吧，而且你还不能半夜通知用户。这样你这排队一天能前进 12 就不错。最后肯定得浪费一大堆票。
不按照队列来做，而是限定时间之前提交的订单都平等处理，避免出现峰值； 买票只选出发和目的地，不能选车次，或者给出所有可能路线，让用户选择优先顺序，尽可能保证到达； 最后系统统一计算出一个最优解，放票之后再进行通知。 好处是尽可能利用运力，不浪费时间，杜绝黄牛，缺点是不透明，没人信。
这不是方便了黄牛么，有 4 小时不要钱的 session，直接把所有的坑都占完了就行了，不停的刷。有客户买就给票付钱，不要就 expire 无所谓，继续刷
有个最最核心的问题，铁道部根本不放出其业务具体逻辑。。 我们自己再这里瞎折腾没太大意义。。。因为业务逻辑不知道，你怎么开发系统？
当然，也许我们可以自己提出一个业务逻辑模型。
那么也许我们可以一起再 github 上开发个开源的动车售票系统 https://github.com/lymanlai/WWTS 刚刚弄上去的。。
目前网络对 12306 已经不是难题了，难还是难在最传统东西，事务处理时效 + 数据库 IO。 由于网络订票系统需要接入已经运行多年的线下实时票务系统，这一部分我觉得在短时间内（一两年）是达不到的，再多钱技术再先进也不行，这时候的顶板是人。
