畅聊12306，赢精美礼品

资讯频道 → 非技术

2顶
0踩

2013-02-01 09:24 by 主编 ITeye管理员评论(25) 有7354人浏览

活动 iteye

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

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

活动地址：http://www.iteye.com/topic/1128946

活动时间：

2013.2.1-2013.2.18

参与方式：

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

温馨提示：回复在活动贴下方指的是论坛活动贴哦http://www.iteye.com/topic/1128946

活动备选话题:

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

评奖方式：

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

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

注意事项:

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

活动地址：http://www.iteye.com/topic/1128946

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

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

分享到：

2
顶

0
踩

评论共 25 条请登录后发表评论

25 楼 runfriends 2013-02-07 14:49

虽然如此但还是可以做的，即使没有价格的调整空间，仍然有用户体验上的差别。用户量更大的网站显然更容易获利。
调用开放平台的接口，把买票整合进自己的网站成为自身业务的一部分，应该是一种更好的方式。

nick.s.ni 写道

我的意思很简单，开放式平台的前提条件是可用资源有可选性，对于航空有多家航空公司，所以才会有竞争，价格才会有调整空间，才会有携程网等平台提供便宜机票。铁路没有这方便的资源，所以开放平台没有用，所以才说你本末倒置。

24 楼 nick.s.ni 2013-02-07 14:18

runfriends 写道

飞机票价票量也不是携程网、去哪儿网定的。它们不是一样存在了吗？既然它们能存在，为什么车票开放平台就不行？开放平台可以降低铁道部的维护成本，让我们有更多买票渠道的选择，能选择体验最好，折扣最多的买票渠道。即使买票没有折扣，至少用户体验更容易改善。
你可能会说，所有卖票网站都抬价怎么办？所以我说，谁要经营这样的网站谁就得遵守游戏规则，游戏规则限定这些东西。不遵守者出局。

23 楼 runfriends 2013-02-04 13:33

nick.s.ni 写道

本末倒置了，决定票价和有多少票的，不是网站，不是程式，开放API更是瞎扯，火车只此一家别无分号，再多的网站卖票也不会让火车票降价。除非像电信、联通那样多建几个铁路局，多几个铁路线，不然根本没有所谓竞争关系。

你会错我意。
我没说用这种方式让车票降价。
你说的开放平台会造成各种抬价，那么是谁会抬价？
至少类似票贩黄牛那种抬价的情况可以限制。而且铁道部实现这种限制比消灭真人黄牛党要容易的多。
票价和票量当然不是网站或程序决定，这些东西跟开放平台没有关系。
飞机票价票量也不是携程网、去哪儿网定的。它们不是一样存在了吗？既然它们能存在，为什么车票开放平台就不行？开放平台可以降低铁道部的维护成本，让我们有更多买票渠道的选择，能选择体验最好，折扣最多的买票渠道。即使买票没有折扣，至少用户体验更容易改善。
你可能会说，所有卖票网站都抬价怎么办？所以我说，谁要经营这样的网站谁就得遵守游戏规则，游戏规则限定这些东西。不遵守者出局。

22 楼 nick.s.ni 2013-02-04 13:16

runfriends 写道

最后还要说一句。
酷壳博主说，就为了一年那么几次，十几天的高访问量，花那么多钱开发一个购票网站，也就铁道部能做的出来了。
个人觉的，更好的做法是。铁道部应该可以把购票api开放出来。让所有人都可以通过这些api开发购票网站。让这些网站之间形成竞争。
这样访问压力分散到了不同公司的服务器，而铁道部就是做了一个平台。这样做的效果更好。就像现在很多类似携程这样的网站都可以在上面订飞机票一样。
另外，通过云计算将根据一年中不同时段的压力弹性改变计算资源，也可以节省成本。

runfriends 写道

hymagic 写道

看你就是不买票的叫你大冬天的去排队买回家的票你就不会这么说，以现在的运力火车票是无法满足需求的，开放平台会造成各种抬价，造成的各种社会问题谁买单？花这么多钱还是值得的，

我买票，但是我从来不排队买。我从来不在高峰期买票。没必要非要挤那一天走。

火车运力不足我认同。但是开放平台会抬价我不敢苟同。
如果开放平台，可以限定开发者资质。可以限制最高售价、最低售价等等，怎么可能会有社会问题。
花这么多钱真不值得，明明有性价比更高的做法。
就为了一年那么几个高峰期花那么钱就是扯淡。

历史事实多次证明，放开市场、自由竞争更容易带来良性竞争，而不是越来越恶化；可能刚一开始会有各种问题出现，但是整体趋势是越来越好。为了能有一个更良好的未来，在一定历史阶段做出一定牺牲是值得的。

21 楼 nick.s.ni 2013-02-04 13:11

nick.s.ni：
这位老兄。我只是想引用我想说的部分。自认为没有改变你发表的主题。我只是删了一部分我不想讨论的内容。
如果你觉的是冒犯，我只有抱歉了

删除没有关系，引一部分也没有关系，但

引用

標記的範圍要記得改一下。

20 楼 runfriends 2013-02-04 12:20

hymagic 写道

19 楼 hymagic 2013-02-04 11:25

runfriends 写道

18 楼 runfriends 2013-02-03 15:14

马晨辉写道

本来就不应该有强票插件，这个功能应该是铁道部官方提供这个功能最好

当然应该是这样。问题就是官方没有提供，所以才有了抢票工具。反过来官方还说抢票工具不好，而不是考虑改进自己。
插件作者自己都说了，如果官方觉的自己的插件有功能是他们想要添加的，他可以把源码提供出来。结果却没想到插件遭到了禁止。官方的思维逻辑确实不是常人能揣度的。
我自己做的东西不好，别人也不能让它变好；谁想让它变好我弄死谁。

17 楼 runfriends 2013-02-03 15:11

16 楼马晨辉 2013-02-02 15:21

本来就不应该有强票插件，这个功能应该是铁道部官方提供这个功能最好

15 楼 nick.s.ni 2013-02-02 14:12

引用归引用，请不要把我的话引用以后，同时修改里面的内容，太不道德了。

runfriends 写道

其实个人认为，抢票插件应该可以作为购票系统的一个有效补充，甚至将它的部分功能集成到网站里面。如果不用抢票工具查询和购买的效率跟用插件的效率一样甚至更高了，抢票工具就没有市场了，而且目前的技术做到这一点并不困难。

存款机制个人觉的不是很有必要。就像从携程网买飞机票，也没有存钱机制。不过如果用户觉的存钱更方便，而又是经常需要乘火车的人，存款倒是可以作为一个辅助功能。
个人认为取消排队机制，细化事务粒度更重要一些。

对于存

nick.s.ni 写道

您是否在12306买过票，结合您的购票体验，来谈谈该系统的用户体验！您认为哪些地方需要改进？

应带有存款机制，向淘宝学习，不要每次都是到网银去支付，浪费大量时间。而且缩短排队时间。

抢票工具不是网站要改善的东西。用户体验才是。
可能很多人认为本来网站效率就不高，抢票插件更是大大增加了服务器的压力。
其实插件作者如果是个聪明人，才不会不断的疯狂重试呢。那样没有什么实际意义。实际上一个优秀的抢票插件只是在模拟人的行为，将人的行为自动化。比如隔几秒钟自动刷新一次、保存查询条件、自动支付等等。这些东西才是一个优秀的插件应该有的功能，要是疯狂重试那就成了攻击了，而插件的目的是帮助网站改善用户体验，把用户机械的重复操作自动化，让用户容易买到票。
甚至网站完全可以取消注册才能购买，购买时要输入验证码这些功能，改善网站本身的效率才是关键。

从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？

浏览器自动抢票插件问题，解决方法每个页面的提交按钮换成Java Applet 或 Flash，提交在进行加密，只要不是纯HTML就不会有问题。实现也最简单。

14 楼 runfriends 2013-02-02 10:39

nick.s.ni 写道

13 楼 nick.s.ni 2013-02-02 09:00

您是否在12306买过票，结合您的购票体验，来谈谈该系统的用户体验！您认为哪些地方需要改进？

应带有存款机制，向淘宝学习，不要每次都是到网银去支付，浪费大量时间。而且缩短排队时间。

12306在系统、业务设计上，还存在哪些问题与挑战？

本身逻辑判断很复杂，除了现有的每趟车次分段购票的基本逻辑，还有各个铁路局之间、各

个站点之间预留票问题。有时候是人的问题而不是系统逻辑问题，所以需要人去沟通解决。

通过12306的现状您认为高性能并发系统架构应该如何设计？关键是什么？

首先不是软件架构，是硬件架构，假设并发是1亿，需要多大的带宽处理请求、响应的
数据，之后是交换机、服务器的硬件配置。在之后才是软件层面。使用数据库集群并进行逻辑处理，Web程式的ORM框架就不能用数据缓存，都交给数据库，其实没几张表，用ORM 实在没必要。考虑到全国的网络现况，还可以做异地數據庫同步(Oracle Stream)。 Web程式不要进行数据库相关的逻辑判断。

从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？

浏览器自动抢票插件问题，解决方法每个页面的提交按钮换成Java Applet 或 Flash，提交在进行加密，只要不是纯HTML就不会有问题。实现也最简单。

12 楼 chinaagan 2013-02-01 19:19

一个思路：采用事件驱动，函数语言来处理事件（无状态+分布式，比如erlang或者其他的scala等），按车次（日期）或者下面的区间来处理，后端批处理与数据库交互。。。读写分离、缓存、集群。。。。把订票环节拆开：订票，提醒支付，支付，订票完成，订票需要在一定时间内完成，软实时，后面的环境可以延后一些，以应付高峰期

11 楼 xisuchi 2013-02-01 17:30

10 楼 Leon.Wood 2013-02-01 15:47

这难道是我最喜爱的12306春运吐槽活动么

9 楼 loveyunwt 2013-02-01 15:32

此时无声胜有声

8 楼 runfriends 2013-02-01 15:17

7 楼 runfriends 2013-02-01 15:11

您是否在12306买过票，结合您的购票体验，来谈谈该系统的用户体验！您认为哪些地方需要改进？
动态、静态内容用不同的服务器完成。静态内容由CDN缓存。

6 楼 runfriends 2013-02-01 15:05

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

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

其他您想说的话！
第一：专业的事就应该找专家来做。不论招标也好，还是私下里寻找合作伙伴也好，都应该挑选有高并发、高吞吐量这方面的专家完成。而这样的人只存在于大型电商公司。铁道部花了那么多钱却没去找正确的人来做这件事。
第二：关键在于目的是什么。目的是花钱，还是为了方便买票，还是其它目的？
第三：关于抢票插件的问题。如果网站本身响应迅速，抢票插件也没什么市场了。关键在于要去考虑怎么改善用户体验，而不是要去禁抢票插件。上头意识从来都没有做正确的事。

发表评论

您还没有登录,请您登录后再发表评论

2顶0踩