12306网站为什么不外包给淘宝做，转知乎上一篇文章

当然了，当初首秀的时候那个系统确实做的奇葩，like ‘%%’这种语句也能写出来也不能怪人骂。

但我至今不能理解有很多人说做个系统花了3亿还嫌贵的。

数据库压力？别他妈搞笑了，我现在一个几百万点击的网站2，3台服务器就够了，通过n层的缓存技术，可以把数据库压力降到1%以下；
还有，这种所谓的访问压力和百度那种比就是屎

那你不去解决

都是帮做了几单企业站就以为自己是技术人士的。连服务器价格都算不来的。

高手在民间，从来不出现

还有缓存，搞笑，不是所有的网站都可以用cdn来解决的。搞过几单网站就自以为牛逼了

跟《养生堂》专家的区别是一个在电视上 一个在网上

几百万点击网站也好意思拿出来说话么……网站的这种mysql都能跑的东西大家都懂。
你这个几百万只是人家的瞬间并发的零头

具体怎么谈谁知道，但这种东西对外说资金管够就是吹牛。
你真觉得就12306一个网上售票系统逆天到IBM、阿里巴巴都解决不了？

什么网站？给个网址瞧瞧去

很多人买不到票就是被12306的cdn坑了。目前的情况看来，12306的各个节cdn间刷新的内容不是完全一致，有的节点的看到票的时候已经被别的节点的人买光了。
可能节点就差那么一秒半秒的，但是高峰期这一秒半秒就是有票没票的事

你以为IBM有多牛吗？看看苏林的网站那点可怜的并发量 这都能让IBM躺下了 苏林可是花重金购买的成熟解决方案哦

我不知道他们的票仓为什么压力如此之大，如果当当是数据库这块，完全可以用分布式和分离式的数据库设计去解决这种问题，文中所说的主库的压力完全是无解，我就不明白为什么他们大量大访问必须通过主库去走，完全可以针对不同的票段和其他条件去做特定的票仓，然后定时去主仓做定量增减，那样主库一天的访问不会超过10000，而压力就完全分布在其他库上，然而，这种压力完全可以堆硬件，做缓存去搞，不知道他们有没有做到这一部，不过这种思路在大数据上是非常入门

12306卡死是窝火，没票才是核心内容，这个只有让铁道部把运力大幅度增加才有可能解决。
再回到你似乎很有把握的技术方向来，”IBM的成熟解决方案“的实际例子我已经给了。至于阿里巴巴，这次双11的场景你没看到？半夜都有人在群里鬼叫付不了款

什么是不同票段

我只是举例而已，只是想说明现在通过某些软件技术，可以让服务器的功能达到最优，现在我这边就算是这种访问量，页面服务器的负载是远远没有到尽头的。

条件分库，条件分表，票段只是举例

本帖最后由 利露 于 2014-1-9 11:31 通过手机版编辑

12306上票卖出去的每一张票要和售票窗口实时一致，比秒杀抢盒子什么的难度高多了

今天报纸说12306身份证验证不和公安联网，黄牛用假身份证大量买票，这是假新闻呢还是？

不可行的 你要知道都是突发性访问 在放票前后几分钟突然拥入大量IP 你的定时访问主库行不通啊

还有当年大航海时代ol 1亿元的刀片机，就他妈是个笑话

还有各种刷票插件浏览器

如果苏宁当年找IBM的时候说钱管够的话，我承认IBM不行。。。

定访在数据层做的，完全脱离业务层以上的干预，管你上面多少亿访问

本帖最后由 利露 于 2014-1-9 11:38 通过手机版编辑

恐怕是真的……
不和公安联网应该是确定了。
然后貌似退票那块有能被黄牛利用的漏洞。因为刚才我老乡群里有人在喊着多买了票要转让。

[本帖最后由 刘泪 于 2014-1-9 11:41 编辑]

关于并发，我记得以前他那个查询系统不管有票没有票，只要用户一查就要搞一次数据库，真是很傻逼的设计，不知道改了没有

每年都讨论一遍...

为啥不把货车临时改成客车
环境简陋一点也可以嘛，便宜一点，慢一点
大家坐完以后绝壁支持高铁

我是业内，12306死就死在分布式数据库了，现有TRS开发了十几年版本一点一点升上来，开始由于起初网络通信问题很多小站代售点只有基带猫加跨局结算业务上的原因全国不可能设统一数据库，就采用的了大带小模式，在大车站建数据库，把计划的票池写入数据库，周边车站买一张数据库里消一张，后来联网售票后每个路局都建了若干信息中心整体构架还是老的模式。目前12306只有北京一个外部出口这是瓶颈，12306一开始定的调子就是不管网站如何绝不能影响原有TRS窗口终端售票，你在12306上每查一次票都要去下面的信息中心的票池去取票额，你想一下这个难度吧。

铁道部煞笔还需要洗地，别的都不说，知道放票瞬间流量会喷发，还你麻痹全国的票都放在11点钟出，搞得几亿人同一时刻上去疯狂F5，这不是煞笔是什么，就这么点事还是到这两天才解决。其余高深技术问题我不懂也不做评论，管中窥豹可见一斑。

货车怎么改客车？我想象了一下兵临城下开始瓦西里坐火车的情景……

为什么不调整思路
据我所知，这种结构应对平时状况是完全可行的，速度也不慢。
但是，当这种并发高的情况，完全不需要做单票的同步
分库的同步采用批量的增减
还有，我搞不明白为什么所有操作都可以在主库走，完全可以建多层主票仓，一层不够做两层，两层不够做三层，主库压力完全释放了

本帖最后由 利露 于 2014-1-9 11:52 通过手机版编辑

大家都是做技术的，不能说做12306的人技术就是差的吧。
恐怕要把铁道部的全部需求公布出来，大家才能了解为什么用目前这套架构。

最早的方案的各买各票，电话订票是在路局设的呼叫中心和窗口可以统一票池，12306分配自己的票池，但是会出现分配不均问题

必须同步实时更新，再多的层只是缓存而已。

对啊，很多时候就是一个客户无关痛痒的想法，完全可以有很好的替代方案，可是客户觉得不受尊重，硬要搞，做了很多傻逼无用功。
就好像我以前接手过一个电商的，要搞数据分析，又不肯接受折中方案，最后搞下来，访问数据是其他数据的10000倍以上，其实，完全是可以用其他方法去搞的

看来就是推翻重来成本太高，下不了决心。
还有人说钱管够么。。。

我都说了，这个高并发还搞实时同步就是死，然后我上面所说的什么分布式库设计完全就是多余的。
明明知道票一放出来就会卖完还搞实时同步，你12306卡谁卡

这个就牵涉到系统整合问题了，这就不是技术问题了，所以别人说都是因为国企傻逼，tgbxs，是完全正确的
然后，这篇傻逼文章扯这么多什么主库压力，并发压力，完全就是傻逼洗地文，我这样阐述没有错吧

本帖最后由 利露 于 2014-1-9 11:59 通过手机版编辑

成本不是问题，风险才是问题。
批钱部长可以不眨眼，万一出大问题要处分那才麻烦。能拍板彻底更换一套稳定运行了几十年的系统的，不是天才就是傻瓜。

系统更新换代的难题，不要说铁道部这种庞然大物，就算很多民企私企也有这种情况吧。

这种真不是成本问题.

牵涉到各方利益，不说了

你还没明白实时同步是必须的啊。就算不做这个12306，都必须保证实时同步。因为全国都在用。
其它的可以尽情喷

现在问题根结是通信，票务网为铁道部自建的通信网，基本上每个车站都采用SDH出的2M数据专线，到各局信息中心点对点连接重要节点是环网，如果设统一数据库统一票池把核心节点放在北京，不仅TRS要重做整个通信通道都要改，这个转移工作是什么难度，估计客运要停一个月，这是不可能的

新系统可以完全使用旧有的数据库，只是针对高峰时段做特殊处理，完全可以新旧系统同步走的方法做迁移，为啥要停运？

n年没坐过火车了，飞机价格也没贵多少

一个意思，成本不只是钱

这两天喷的假身份证注册问题卡在公安部不给数据，很多偏远站派出所没公安网无法制临时身份证，铁道部协调公安网连通票务网和公安部接口光会就开了几十次

那么简单？