畅聊12306，赢精美礼品——已结束

又到一年春运时，抢票成为近期最热的话题，一时间，网站、新闻、报纸上都是关于春运火车票的各种报道，各种抢票插件更是层出不穷，当然网上也少不了关于12306的各种抱怨。你是否也参加了此次的“抢票大战”呢？作为程序员，关于12306你怎么看？在春运抢票大潮即将收尾之际，ITeye特此推出“畅聊12306，赢精美礼品”活动！

活动时间：

2013.2.1-2013.2.18

参与方式：

根据给出的备选话题任选一个或多个话题进行发言，并将发言直接回复在本活动贴的下方即可。

活动备选话题:

• 您是否在12306买过票，结合您的购票体验，来谈谈该系统的用户体验！您认为哪些地方需要改进？
• 12306在去年国庆之前进行了改版，加入了排队系统，您认为排队系统的增加目的是什么？
• 12306在系统、业务设计上，还存在哪些问题与挑战？
• 通过12306的现状您认为高性能并发系统架构应该如何设计？关键是什么？
• 高性能并发系统技术实现的关键是什么？
• 有人提议12306采用NoSQL存储，您认为是否可行？
• 从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？
• 其他您想说的话！

评奖方式：

活动结束后由ITeye资深编辑评选出精彩回复，精彩回复及作者将放到精华频道“12306专家访谈”中进行集中展示。

同时在精彩回复抽取五名作为本期获奖者，可获得ITeye提供的精美CD版台历一份+《程序员》杂志。

注意事项:

•回复必须为原创，字数30字以上，抄袭或是转载视为无效。
•每位用户回复次数不限制，但不可重复获奖

活动结束后，将在本贴的1楼回复区公布获奖名单。

本活动最终解释权归ITeye管理员所有。如有问题请给管理员站短或发邮件至webmaster@iteye.com

经过春节前后两周时间对12306看法的征集，在论坛回帖和资讯回帖中涌现出不少观点回复。回复中大家的看法各有千秋，都很不错。针对本次活动的主题我们的社区编辑已经评选出一些优秀的回复并展示在了社区专家访谈12306中，同时在这里做下集中展示。

下面是从ITeye编辑评选出的精彩回复中抽取的五名幸运用户名单：

runfriends    achun    wangshu3000    clxy    czwlucky

以上用户将获得ITeye提供的精美CD版台历一份+《程序员》杂志

温馨提示：请各位获奖用户尽快将自己的ID+姓名+电话+邮寄地址与2013年2月28日之前通过站短形式发送给ITeye管理或通过邮件发送到webmaster@iteye.com。，逾期将视为自动放弃奖品哦。

==========================================================================================
本期活动精彩回复展示

由于本次活动的回复都比较长，这里就采用简介加链接的形式为大家展示，您可以通过点击右侧的更多详情进入回复楼层进行查看。

用户runfriends

您是否在12306买过票，结合您的购票体验，来谈谈该系统的用户体验！您认为哪些地方需要改进？
我知道它很难用，所以我从来没用它买过票。去年国庆节查询个票，慢的要命.... 更多详情


用户achun

1.运量
引用网络信息
2013年春运从1月26日开始至3月6日结束，为期40天。发改委初步预测，铁路春运期间全国旅客发送量约2.25亿人次。发改委既然预测了，那铁路部门必须完成运送额也就是指标了。2.25亿的一半1.125亿，要在15天里面运送完毕...更多详情


用户wangshu3000

问题瓶颈(Front to Backgroud)
1.Web端，每天请求上亿，压力很大，包括html js css img等，需要占用大量带宽
2.身份证认证，可能会用到第三方的认证，或者铁道部协议，获取到身份证信息，这个查询量也很大...更多详情


用户clxy

一些个人看法
◆ 关于排队系统
  我个人觉得排队系统还是比较合理的，可以分离主干系统的压力。
  当然不应该是现在这个样子的。下列功能应该需要在排队系统中提供...更多详情


用户czwlucky

•12306在去年国庆之前进行了改版，加入了排队系统，您认为排队系统的增加目的是什么？

我认为增加这个功能的意义在于，当你不能立即买上票时，不用再不停的反复刷新提交了，相当于银行里发给你一个“号码”，等叫你时你过来买票就是了，不用站那儿傻等。　一方面增强了用户体验感，另一方面也能节约反复请求带来的压力...更多详情


用户charles751

这里只简单谈谈技术上的问题，当然任何系统也不是完全由技术说了算，尤其像12306这种已经投入了很大资金的大型系统，任何大的改动都不是一句话的事...更多详情


用户bingyingao

今年我在12306买票了，想买2月1号左右东莞到襄阳的票，但是一直买到3号都没有成功，我没有用任何抢票插件或者浏览器（因为去年我就是徒手买到的，哪想今年登陆是没问题了，但抢票却更难了，也许确实是大家都用抢票软件了），基本上每一次我都能排紧队，但是最终都提升余票不足，出票失败...更多详情


用户nwangwei

1. 12306的业务性能要求比淘宝的双11还要高！
2. 12306加入了排队系统，其实只要针对抢票即可，比如淘宝针对秒杀做排队系统...更多详情


用户helin

本座认为12306本年的表现还不错的。
本来想发一贴，讨论关于15亿pv的实现方式的...更多详情


用户javamonkey

高性能并发系统技术实现的关键是什么？
这个可以仿照电信的计费系统，采用商用的内存数据库
有人提议12306采用NoSQL存储，您认为是否可行...更多详情

一些精彩回复已经被采纳并展示到社区专家访谈12306中 详情参阅http://www.iteye.com/magazines/110

本活动最终解释权归ITeye所有。

就其12306这个软件来说, 真的很差劲.

UI体验差, 流程不合理.

唯一的一点建议就是, 招点好点程序员, 不要再用实习生了..

坐等高评...

说实在的，12306做的这一步已经相当不错了。

我想12306应该用到mq,cache,nosql都应该有，不同的问题，用不同的技术解决，不能指望nosql就能解决所有问题。尽量减少直接去访问数据库。

    今年我在12306买票了，想买2月1号左右东莞到襄阳的票，但是一直买到3号都没有成功，我没有用任何抢票插件或者浏览器（因为去年我就是徒手买到的，哪想今年登陆是没问题了，但抢票却更难了，也许确实是大家都用抢票软件了），基本上每一次我都能排紧队，但是最终都提升余票不足，出票失败。
    而排进队的规则是：余票数大于排队数，按这个理来说假如余座票500张（据说网上票和电话订票是分开的，因此应该不存在另一个入口、另一个队列来同时消费剩余的500张票），我是第300个排进队列去的，那么按照队列先进先出，我应该是能够买到票的，但是为什么反复几次都不能成功呢，这不合情理啊。
   我的推测是，由于去减库存的并发量比较大，所以减库存失败比率很大，虽然排进队，但是减库存却不一定能成功，虽然我是第300个，但是轮到我的那个请求去减库存时抛了类似超时的异常，就提示我失败了。这样的说的话抢票不仅仅是要速度快，而且真还要有运气。
   我觉得迫切需要改善的，是提高并发减库存的能力，保证排进队的人买到票，而看看今年的情况，骂声最多的也就是这里了，排进队等了几分钟却被告知出票失败，再去想别的办法，花都谢了！

硬卧，直接从“*”，变成“无”，这样的站，有必要给建议吗？

300万外包给淘宝的开发团队做比较现实，有政治参与的开发都是JB扯蛋

您是否在12306买过票，结合您的购票体验，来谈谈该系统的用户体验！您认为哪些地方需要改进？
我知道它很难用，所以我从来没用它买过票。去年国庆节查询个票，慢的要命。
从sql的拼写到页面优化，从程序架构到服务器架构都需要全面重构。
完全是一群业余选手的习作。
居然不是参数化查询sql，而是查询参数拼到sql里的。
应该采用js、css、图片、html都应该启用gzip压缩，所有css应减少到一个，js文件该合并的合并，能重用的重用，页面背景图应尽量合并成一个文件。尽量减少http请求数。
12306在去年国庆之前进行了改版，加入了排队系统，您认为排队系统的增加目的是什么？
12306在系统、业务设计上，还存在哪些问题与挑战？
通过12306的现状您认为高性能并发系统架构应该如何设计？关键是什么？
高性能并发系统技术实现的关键是什么？
这四个问题一块回答。
刚开始的时候看到网上很多人说它有一个巨大的事务。后来又加入了排队系统。
至于为什么个人猜测可能是为了降低数据库压力。
而实际上，用户并发量并没有变化，排队导致大量访问不能尽快返回，占用了大量系统资源。实际上这样做降低了系统吞吐量。数据库压力有没有降低先不说，系统吞吐量肯定会降低。
铁道部应该对每节车厢、每个车次要卖出多少站票、软座、硬座、卧铺有一个规划。
购买同一车次和票种的人不会造成太高的并发。
因此关键在于查询和买票服务器集群的设计和实现。
设计一个票池系统，按照车次、线路、区域划分票池，按照车次、站、软、硬、卧分类不同票种，将每个票种分配到票池集群的某台服务器上。买票时肯定已经确定了票种，通过一致性哈希准确定位指定票种所在的服务器。
票池系统完全采用内存储存预售票票种、票量信息。
查询、购买分开不同的集群，两个集群之间实现余票量同步。
保证每个操作迅速返回，不必保证查询和购买实时同步，也不必保证查到的票在购买的时候一定能买到。

有人提议12306采用NoSQL存储，您认为是否可行？
事务的粒度应做到购买行为是原子性的，即保证两个人不会买到相同的票即可。
每个票种的优先级是一样的，应不同的查询条件保证能尽快的返回。
实际上每天出售的票种总和远达不到海量的程度。但是每年有几个时段并发量特别大。如果使用大量nosql数据库集群，票量一致性恐怕难以保证；如果使用单台nosql，恐怕吞吐量和实时响应也会像mysql一样难以做到。
不论什么数据库，都难以完成这么少的数据量却要完成这么大并发量的情况。
个人认为还是把不同票种分散在不同票池服务器中，完全由程序操作内存完成查询和购买更合适一些，虽然数据结构可能要复杂很多。
最后根据每个票种的余票量要限制每个票种的查询和购买并发量。超过的就拒绝访问，以节省资源。早死早超生，而不是所有人都耗在买票这个事上。
从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？
前面都已经说过了。

其他您想说的话！
第一：专业的事就应该找专家来做。不论招标也好，还是私下里寻找合作伙伴也好，都应该挑选有高并发、高吞吐量这方面的专家完成。而这样的人只存在于大型电商公司。铁道部花了那么多钱却没去找正确的人来做这件事。
第二：关键在于目的是什么。目的是花钱，还是为了方便买票，还是其它目的？
第三：关于抢票插件的问题。如果网站本身响应迅速，抢票插件也没什么市场了。关键在于要去考虑怎么改善用户体验，而不是要去禁抢票插件。上头意识从来都没有做正确的事。
最后还要说一句。
酷壳博主说，就为了一年那么几次，十几天的高访问量，花那么多钱开发一个购票网站，也就铁道部能做的出来了。
个人觉的，更好的做法是。铁道部应该可以把购票api开放出来。让所有人都可以通过这些api开发购票网站。让这些网站之间形成竞争。
这样访问压力分散到了不同公司的服务器，而铁道部就是做了一个平台。这样做的效果更好。就像现在很多类似携程这样的网站都可以在上面订飞机票一样。
另外，通过云计算将根据一年中不同时段的压力弹性改变计算资源，也可以节省成本。

票都预留了，网站做得再好，您还是买不到票，亲。

潜规则的东西不在我们的讨论范围内。我们只从技术方面考虑可行性。
至于其它的，我们得逐步逐渐的改变不是。
关键在于我们得相信，这个世界会变的更好，而且我们能把它变的更好，而且我们要为了世界变的更好而努力。
如果什么都不做，这个世界只会越来越坏。
只有我们不断努力，才有希望。
一个人能做的事有限，但是经年累月，无数人不懈努力，一定会有成效。

人活着就是要相信！！！