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

“就是和现实窗口一样的模型，计算机处理订单的速度比在窗口喊话快不知多少倍！ ”

前半句对的，后半句无助于网站售票。
做成现实模型容易，但是无论什么模型最终都会和窗口人员使用的下单系统共用API，整个系统处理订单的速度瓶颈就在这里了，网站别的方面再快，也无助于实际出票效果，还是要斟酌网站控制多少并发以免压垮那个核心系统

窗口买票要喊话的，去哪里，哪个车，多少钱……其实时间都浪费在这里，导致后面排队的人等很久。平均多少时间来一个人，和平均处理一个人购票的时间是多少，这里就构成临界点，处理时间大，就会造成队伍堆积，处理时间少，来多少人都不会堆积。

就算是撤掉一个人工窗口，换成电子数据包交换，效率都不知道高多少倍！
因为计算机对计算机的通信太快了，以至于不撤掉人工窗口，也能利用人工窗口换人转身的瞬间处理很多个请求。

所以，以前排几十小时队，现在半个小时都没票了，都散了。

所以你担心的问题不存在。

但是，从选票开始就锁定临界资源，那么和窗口排队就真的一样了，核心资源都被浪费在选票上。

还有，排队是必须的，核心系统不能超负荷运行，必须稳定。核心系统跨了，谁也买不到票。


我的假设就是网站与窗口共用同一套api，同一个通道的，但是用法不一样，效果就不一样。饭店吃饭时，排队多了会有服务员来提前点菜，就是这个道理。（排除他们为了牵制客户的动机不说，应该是他们厨房够大，但是桌子不够用，不能让你上了桌子再等太久。）

楼主的思路充分说明楼主对计算机建模的无知，本质上很多文件操作都是序列化的，你以为oracle数据写磁盘的时候就是并发的！？

序列化就是排队，这个可以追溯到CPU的指令队列，还唧唧歪歪说了一堆歪理论，建议你改行了得了！
如果你是明知原理，只是为了反对而反对，我表示无语。。

查询用缓存就行了呀，本来12306的信息就不是实时的，延时好长时间呢。

如果嫌前面的用户操作太慢了，那也只能怪自己排队都后面，总现在的破东西强。

排队又没说要一个个放，只要每个批次人数在服务器可接受的范围内就行。

票少人多，怎么都是死结

你是大牛，你的序列化和CPU指令队列天下无敌，世上无并发好了吧？
我完全看不懂你在回复和我的主题思想有什么关系，您是高手，这里水浅，免回

光从排队上将我说一下自己的观点,对于第一种方法可不可以这样修改,在挂号的时候顺便给相应的票数上做标记,比如说显示总数时减掉已经排上队人数或同时显示这个票的总数及为这个票已经在排队的人数.

查询用缓存的意义确实是有限的，一方面，因为能查，抑制不了用户不断刷新的欲望，连接数依然居高不下。另一方面，查出来不准确，最后按查的结果下不了单，无形中增加了用户的操作时间，导致队伍等待时间更长，以及招致黑幕、查着有票卖着无票这样的骂名。
现在的东西的确破，我没说他不破，我只是说，很多人所想的一个队列就解决的思想是不对的，我原文已经说了排队的两个问题。
不是一个个放，按批次放人，这不和现在的12306一个思想吗？一批放多了，继续响应不了，放少了，你可能现在排队，明天都未必到你。
能达到火车站售票窗口的队伍前进速度恐怕也是这网站最好情况了。在队伍规则严格按车站窗口执行的前提下可以达到

实现恐怕不太容易，因为现在的座位是可以复用的，并不是一个座位一张票，比如ABCDE五个站，你选B到D，你在排队过程中可能受到前面买票的人买A到C A到D A到E B到C等各种情况影响，那这个总数是算不出来的了，因为你不能预计到A到E是只卖一张还是拆成几张卖，网站只能告诉你还有票还是没有了。那就是变成实时查询了，因为ABCED上任一张票锁定，都可能会让你排的票情况有变。
而且第一种排队法主要面临的是重排问题，如果要算小票除掉排在你前面的人，还能不能买到，那买票抢夺环节转移到抢小票上了，如果不算，填好就排，就会面临排完了没票，重排。

排队论者先解决这个问题吧.
假如我需要买的票的15:00才开卖,我得几点去排队?
别告诉我该早晨6点去排队,然后每分钟点次查询,防止session过期