如果让你设计铁道部购票网站，你怎么做

这是个人才，适合当领导，有时候有些事自己做不如给专业人士去做

12306和淘宝比？
有可比性吗？
一个一年用几天的东西，想按淘宝的规模弄。都疯了吧。

说实话，铁路系统基本都挺复杂。

有的系统可不像秒杀不到东西这么简单，弄不好就是重大事故。

小心这里面有开发这个系统的人哦~，我不是~~~

嗨，这个系统设计的确实有问题！

有很多不该出的毛病都出。

流量大造成系统繁忙可以理解，但是各种没响应，还有交了钱没订到票，这个完全可以避免的。

总之，大家看不上它，是有原因的。

少来装复杂了，这个只不过是售票系统，又不是动车的控制系统！

再复杂也比不上证券交易系统和电信计费系统，能出啥事故！！最大事故就是定不来票而已

你们有木有想过春节晚上的电话和短信流量有多大？人家移动计费系统要是瘫痪那才是重大事故！

就一个订票系统，做成这样，里面的猫腻我就懒得说了！

看了这么多帖子，总算看到一个说了正确的话的人。售票系统再复杂能复杂到哪去？

第一，虽然这个系统一年就几天高峰期，但是其重要性不言而喻，动车和高铁都投资按万亿计算，区区一个网站就舍不得投资了。更多原因是领导不懂IT，不重视，认为系统简单，随便找个小公司搞定就好。

第二，如果真要节省成本，那简单，找个B2C的电子商务网站合作，零时租用对方的服务（包括软硬件，带宽等），这样既有保障有节省。但这样可就少了拿回扣的发财机会了，领导们怎么可能答应！！

光顾着抱怨，有点跑题了。下面言归正传，让我们从系统设计角度来看看要如何设计流量如此之大的东东。

本人觉得系统架构的关键要有3大部分

1.排队等待子系统
  
  如此大的并发量不是简单的群集能承受的，因此，系统需要一个缓冲区，就好比在窗口面前排队一样，在进入订票流程前，应该有个排队处理系统，简单的页面，让电脑面前的用户知道自己的请求已经提交，系统慢，大概还需要几分钟才能受理你的订票请求。

  如果大家玩过wow，下过魔兽的副本，就知道有个副本排队系统了，这样也一样。
  此系统需要大量的HTTP前端服务器，接受用户请求，但不需要很复杂的业务逻辑。

2.订票流程处理子系统

   进入该子系统的用户开始正式的订票流程，如，填写各种表单。该子系统关键在于需要一张表，用来记录用户已经订出的票，扣除系统剩余票数，这样不至于用户交钱了票没了。只有用户取消订票时，将票退回系统。
   同时，该系统应该记录用户在订票流程的日志。


3.订票确认与分发子系统
   用户完成所有信息填写后，进入该子系统，该系统负责最终登记用户的订票信息，并正式的将票据出售，同时从用户的资金账户中扣除钱款，并在系统中锁定票号。
    用户将从这个系统中，最终确认自己的购买的票据时间，票据，出发到达等信息，即提供最终票务状态的查询。


剩下的具体设计，如，数据库集群设计，负载均衡设计，动态服务扩展设计，高可用性设计，高速缓存设计，这些议题大家平时都在讨论，这里就不多说了。

大方向设计出来了，小细节的可选方案就灵活了。我就不信这样的设计会出现钱扣了，票没出的情况...


尼玛，再次抱怨铁道部购票网站设计就是无脑的坑爹货！

不理解第2点中的回扣问题。难道B2C网站不懂得给回扣。