批判下最近关于12306架构方案的“排队思路”

这是两种排队操作方案，既然你也说第一种方案不能加快，那我们意见一样，这样排队行不通。

第二种，你似乎不太做互联网需求，把用户想得太过理想化了，很多用户对网站操作上手之差不是我们所能想象的，很多做网站的人都会抱怨用户太傻，这么简单的事都不会操作。
你觉得现在12306上有几成用户曾预演过？他想预演时已经根本登不上去了。难道排队时还专开一个插队功能让他去“预演”？
最后就是，即使只有30%的用户不熟悉操作，你依然要为这30%的用户留下一定的操作时间，否则你的网站就违背了公平服务的原则，12306不是淘宝卖家，不能说你不会用就别来

缓存可以使用其他服务器呀，数据延时几分钟还是可以接受的。实时查询根本很难实现。

按批次发，人数是可以控制的，不是一拥而上的思想，怎么会响应不了。而且用户前半小时排不上队就会放弃的，因为基本上票半小时就卖光了。

窗口人工售票是一个用户独占一个服务，网上售票的时候一个服务器能同时给多个人服务，只有点击鼠标的时候才和服务器交互一次。我不觉得会比人工售票慢。

总之，我真没看出来排队有什么不对的。而且有秩序的排队是会比相互挤快，服务器超过负荷才更慢。

自己不做功课，你怪考试不公平？

你非要在放票时去熟悉？

普通网站操作，和关系自己订票的网站。用户心理能一样吗？

你確實無知者無畏。。。

你們說的所謂架構只是UI上不希望看到排隊過程，根本談不上什麽“架構”。

就說UI不排隊吧，UI不排隊，系統還是要排隊吧？

系統排到你了就叫號。考慮到排到你的時候你已經不看網頁了，睡覺去了，打球去了，誰來叫你？BS 不過是一張網頁，從電腦里爬出來叫你？給你發短信通知你上網選購？這個選購權給你保留多久？怎麼防止光訂票不付款的類DOS攻擊？

有人又說了，排到我了就自動成交。你票都不看願意成交嗎？給你特等座，給你凌晨 3 點到的車，你樂意？選，是購物的必須體驗。

不是排队不对，是说排队方案上的缺陷。
一个服务器同时给多个人服务的本质，相当于一个售票厅有多个售票窗口，在同时给多个人售票，依然相当于一个用户独占一个窗口，网站的“窗口”开得太多，也就变成了争夺，不是排队了，“窗口”依然是有数量限制的。
至于每个窗口是比人工快，还是比人工慢，其实我认为是差不多的，售票窗：口头告诉售票员，他帮你输入，查询。网站：你自己输。
当然售票员由于操作熟悉，所以肯定比网民的平均操作要快。整个流程下来，网络队伍的前进速度不会比售票窗口要快。
我之前回贴有得出一个结论：网络售票能达到的最优效率，恐怕就是全盘照搬售票厅的操作细节，同时前进速度也会和售票厅差不多

说的在理。

我觉得前面niko7提的方案最好，排队前先选好票，允许几种可能，选票的功能可以轻易的分摊到不同服务器，压力大了增加服务器即可，甚至可以动态租用。票的方案选好了就不能更改，在排到的时候你只能是从满足条件的票中选择一个，这个选择你要在1分钟内作出决定要还是不要。如果选择不要，则系统继续对剩余的选票方案进行查询并给出结果供选择，同样，这个选择也是1分钟内有效。

总选择设定时间为10分钟，也就是说10分钟内如果都没有你满意的票（或者你的所有预定方案都没有余票），那么强行结束服务。

这个方案的好处是大大减少核心资源的锁定时间。

排队前的选票，可以不需要提供非常精确的余票信息，用户可以根据自己的行程安排和余票信息来设定自己的选票方案与优先级。一旦排到队，用户就不会做无谓的查询，而且票可以比较快地被售出。系统可以根据所能够提供的查询能力来决定放入多少人来服务。

当然任何方案都无法解决人多票少的问题，排队能带来更好的用户体验（系统响应更及时，而不是目前的501错误；能够知道大概多久能排到，能够知道所要求的票的大概实时余票数等），以及让核心系统能够更有效的工作。

排队方案确实该批判。

系统本身的意义就是跟增加一批售票窗口一样，形式不一样而已。在实际买票前都可以先查好买什么车次。

而且时间上面逼迫用户尽早下单，耗不起，一耗可能没票了。

而且这个是可以量化的

铁道部一天大概600W张车票，分4批发放，平均每批150W。网络售票占30%左右，算50W好了。

假设用户能承受的等待时间为30分钟，那么12306每秒能出300张车票就行了。

如果保证有秩序的买票，完全没有问题

可以考虑整个随机+排队+超时。。。哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈