n*T
2 楼
今天刚到，还没有买耳放，用IPOD和MACBOOK PRO直推效果也还性，只是感觉人声有点
隔了一层纱的感觉。。
有谁给推荐个便宜又好的耳放不？还是RA1就性价比最高了？
隔了一层纱的感觉。。
有谁给推荐个便宜又好的耳放不？还是RA1就性价比最高了？
e*t
3 楼
预约是9点，9点半签完。没问太多问题。要了我们的签证和I-94，虽然我们有绿卡了。
一些材料列表
邀请方:
1. 签证申请表, DS156, DS157
2. 致签证官的信
3. 大使馆致国会议员的回复
4. 国会议员致大使馆的信
5. 给国会议员的信
6. 中文邀请信
7. 邀请人护照、绿卡的复印件
8. 亲属公证
9. 工作和工资证明
10. 银行存款证明
11. 2007年税表
12. 邀请人签证、I-94复印件
受邀方：
1. 房产证
2. 退休金、存款证明
3. 家庭照片
爸爸妈妈8号上午北京1000，求祝福。包子不多，尽量发。谢谢大家。
谢谢大家的祝福。还有十几个小时爸妈就要去签证了，好紧张呀，他们之前被据过。请大家多多祝福，如果过了，一定来贡献有用签经。
一些材料列表
邀请方:
1. 签证申请表, DS156, DS157
2. 致签证官的信
3. 大使馆致国会议员的回复
4. 国会议员致大使馆的信
5. 给国会议员的信
6. 中文邀请信
7. 邀请人护照、绿卡的复印件
8. 亲属公证
9. 工作和工资证明
10. 银行存款证明
11. 2007年税表
12. 邀请人签证、I-94复印件
受邀方：
1. 房产证
2. 退休金、存款证明
3. 家庭照片
爸爸妈妈8号上午北京1000，求祝福。包子不多，尽量发。谢谢大家。
谢谢大家的祝福。还有十几个小时爸妈就要去签证了，好紧张呀，他们之前被据过。请大家多多祝福，如果过了，一定来贡献有用签经。
H*d
4 楼
【 以下文字转载自 WashingtonDC 讨论区 】
发信人: Westridge (不折腾), 信区: WashingtonDC
标 题: 学习学习国内的IT项目-12306铁道部订票网站性能分析【转载】
发信站: BBS 未名空间站 (Thu Jan 17 14:48:59 2013, 美东)
学习学习国内的IT项目-12306铁道部订票网站性能分析【转载】
业务
任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。
一，有人可能把这个东西和QQ或是网游相比。
但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据
，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就
以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。
二，有人说春节期间订火车的这个事好像网站的秒杀活动。
的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个
事，还有很多查询操作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次
，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀，直接杀就好了。
另外，关于秒杀，完全可以做成只接受前N个用户的请求（完全不操作后端的任何数据
， 仅仅只是对用户的下单操作log），这种业务，只要把各个服务器的时间精确同步了
就可以了，无需在当时操作任何数据库。可以订单数够后，停止秒杀，然后批量写数据
库。火车票这个岂止是秒杀那么简单。能不能买到票得当时告诉用户啊。
三，有人拿这个系统和奥运会的票务系统比较。
我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽
奖的方式，也就是说不存在先来先得的抢的方式，而且，是事后抽奖，事前只需要收信
息，事前不需要保证数据一致性，没有锁，很容易水平扩展。
四，订票系统应该和电子商务的订单系统很相似。
都是需要对库存进行：1）占住库存，2）支付（可选），3）扣除库存的操作。这个是
需要有一致性的检查的，也就是在并发时需要对数据加锁的。B2C的电商基本上都会把
这个事干成异步的，也就是说，你下的订单并不是马上处理的，而是延时处理的，只有
成功处理了，系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单
不成功的邮件。这就是说，数据一致性在并发下是一个瓶颈。
五，铁路的票务业务很变态。
其采用的是突然放票，而有的票又远远不够大家分，所以，大家才会有抢票这种有中国
特色的业务的做法。于是当票放出来的时候，就会有几百万人甚至上千万人杀上去，查
询，下单。几十分钟内，一个网站能接受几千万的访问量，这个是很恐怖的事情。据说
12306的高峰访问是10亿PV，集中在早8点到10点，每秒PV在高峰时上千万。
多说几句：
一、库存是B2C的恶梦，库存管理相当的复杂。
不信，你可以问问所有传统和电务零售业的企业，看看他们管理库存是多么难的一件事
。不然，就不会有那么多人在问凡客的库存问题了。（你还可以看看《乔布斯传》，你
就知道为什么Tim会接任Apple的CEO了，因为他搞定了苹果的库存问题）
二、对于一个网站来说，浏览网页的高负载很容易搞定，查询的负载有一定的难度去处
理，不过还是可以通过缓存查询结果来搞定，最难的就是下单的负载。
因为要访问库存啊，对于下单，基本上是用异步来搞定的。去年双11节，淘宝的每小时
的订单数大约在60万左右，京东一天也才能支持40万（居然比12306还差），亚马逊5年
前一小时可支持70万订单量。可见，下订单的操作并没有我们相像的那么性能高。
三、淘宝要比B2C的网站要简单得多，因为没有仓库。
所以，不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候，
B2C的 网站要去找一个仓库，又要离用户近，又要有库存，这需要很多计算。试想，你
在北京买了一本书，北京的仓库没货了，就要从周边的仓库调，那就要去看看沈阳或
是西安的仓库有没有货，如果没有，又得看看江苏的仓库，等等。淘宝的就没有那么多
事了，每个商户有自己的库存，库存分到商户头上了，反而有利于性能。
四、数据一致性才是真正的性能瓶颈。
有人说nginx可以搞定每秒10万的静态请求，我不怀疑。但这只是静态请求，理论值，
只要带宽、I/O够强，服务器计算能力够，并支持的并发连接数顶得住10万TCP链接的建
立 的话，那没有问题。但在数据一致性面前，这10万就完完全全成了一个可望不可及
的理论值了。
我说那么多，我只是想从业务上告诉大家，我们需要从业务上真正了解春运铁路订票这
样业务的变态之处。
前端性能优化技术
要解决性能的问题，有很多种常用的方法，我在下面列举一下，我相信12306这个网站
使用下面的这些技术会让其性能有质的飞跃。
一、前端负载均衡
通过DNS的负载均衡器（一般在路由器上根据路由的负载重定向）可以把用户的访问均
匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都
是短作业，所以，可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让
用户连接与其最近的服务器（CDN通常伴随着分布式存储）。（关于负载均衡更为详细
的说明见“后端的负载均衡”）
二、减少前端链接数
我看了一下12306.cn，打开主页需要建60多个HTTP连接，车票预订页面则有70多个HTTP
请求，现在的浏览器都是并发请求的。所以，只要有100万个用户，就会有6000万个链
接，太多了。一个登录查询页面就好了。把js打成一个文件，把css也打成一个文件，
把图标也打成一个文件，用css分块展示。把链接数减到最低。
三、减少网页大小增加带宽
这个世界不是哪个公司都敢做图片服务的，因为图片太耗带宽了。现在宽带时代很难有
人能体会到当拨号时代做个图页都不敢用图片的情形（现在在手机端浏览也是这个情形
）。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右，如果你访问过
了，浏览器会帮你缓存很多，只需下载10K左右的文件。但是我们可以想像一个极端一
点的案例，1百万用户同时访问，且都是第一次访问，每人下载量需要1M，如果需要在
120秒内返回，那么就需要，1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以，我
估计在当天，12306的阻塞基本上应该是网络带宽，所以，你可能看到的是没有响应。
后面随着浏览器的缓存帮助12306减少很多带宽占用，于是负载一下就到了后端，后端
的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明服务器垮
了。
四、前端页面静态化
静态化一些不常变的页面和数据，并gzip一下。还有一个并态的方法是把这些静态页面
放在/dev/shm下，这个目录就是内存，直接从内存中把文件读出来返回，这样可以减少
昂贵的磁盘I/O。
五、优化查询
很多人查询都是在查一样的，完全可以用反向代理合并这些并发的相同的查询。这样的
技术主要用查询结果缓存来实现，第一次查询走数据库获得数据，并把数据放到缓存，
后面的查询统统直接访问高速缓存。为每个查询做Hash，使用NoSQL的技术可以完成这
个优化（这个技术也可以用做静态页面）对于火车票量的查询，个人觉得不要显示数字
，就显示一个“有”或“无”就好了，这样可以大大简化系统复杂度，并提升性能。
六、缓存的问题
缓存可以用来缓存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题：
1）缓存的更新。也叫缓存和数据库的同步。有这么几种方法，一是缓存time out，让
缓存失效，重查，二是，由后端通知更新，一量后端发生变化，通知前端更新。前者实
现起来比较简单，但实时性不高，后者实现起来比较复杂 ，但实时性高。
2）缓存的换页。内存可能不够，所以，需要把一些不活跃的数据换出内存，这个和操
作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关
内容参看Wikipeida的缓存算法。
3）缓存的重建和持久化。缓存在内存，系统总要维护，所以，缓存就会丢失，如果缓
存没了，就需要重建，如果数据量很大，缓存重建的过程会很慢，这会影响生产环境，
所以，缓存的持久化也是需要考虑的。诸多强大的NoSQL都很好支持了上述三大缓存的
问题。
后端性能优化技术
前面讨论了前端性能的优化技术，于是前端可能就不是瓶颈问题了。那么性能问题就会
到后端数据上来了。下面说几个后端常见的性能优化技术。
一、数据冗余
关于数据冗余，也就是说，把我们的数据库的数据冗余处理，也就是减少表连接这样的
开销比较大的操作，但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数
据，快是快了，因为数据冗余了，但这对数据一致性有大的风险。这需要根据不同的业
务进行分析和处理。（注意：用关系型数据库很容易移植到NoSQL上，但是反过来从
NoSQL到关系型就难了）
二、数据镜像
几乎所有主流的数据库都支持镜像，也就是replication。数据库的镜像带来的好处就
是可以做负载均衡。把一台数据库的负载均分到多台上，同时又保证了数据一致性（
Oracle的SCN）。最重要的是，这样还可以有高可用性，一台废了，还有另一台在服务
。数据镜像的数据一致性可能是个复杂的问题，所以我们要在单条数据上进行数据分区
，也就是说，把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品有1万
的库存，我们可以设置10台服务器，每台服务器上有1000个库存，这就好像B2C的仓库
一样。
三、数据分区
数据镜像不能解决的一个问题就是数据表里的记录太多，导致数据库操作太慢。所以，
把数据分区。数据分区有很多种做法，一般来说有下面这几种：
1）把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分，可按各种
车型分，可以按始发站分，可以按目的地分……，反正就是把一张表拆成多张有一样的
字段但是不同种类的表，这样，这些表就可以存在不同的机器上以达到分担负载的目的。
2）把数据按字段分，也就是竖着分表。比如把一些不经常改的数据放在一个表里，经
常改的数据放在另外多个表里。把一张表变成1对1的关系，这样，你可以减少表的字段
个数，同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被放到不同的
页表里，这对于读写性能都有问题。但这样一来会有很多复杂的控制。
3）平均分表。因为第一种方法是并不一定平均分均，可能某个种类的数据还是很多。
所以，也有采用平均分配的方式，通过主键ID的范围来分表。
4）同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的
服务器上，比如有10000个库存，可以分到10台服务器上，一台上有1000个库存。然后
负载均衡。
这三种分区都有好有坏。最常用的还是第一种。数据一旦分区，你就需要有一个或是多
个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区，并放在各个省市，
会对12306这个系统有非常有意义的质的性能的提高。
四、后端系统负载均衡
前面说了数据分区，数据分区可以在一定程度上减轻负载，但是无法减轻热销商品的负
载，对于火车票来说，可以认为是大城市的某些主干线上的车票。这就需要使用数据镜
像来减轻负载。使用数据镜像，你必然要使用负载均衡，在后端，我们可能很难使用像
路由器上的负载均衡器，因为那是均衡流量的，因为流量并不代表服务器的繁忙程度。
因此，我们需要一个任务分配系统，其还能监控各个服务器的负载情况。
任务分配服务器有一些难点：
负载情况比较复杂。什么叫忙？是CPU高？还是磁盘I/O高？还是内存使用高？还是并发
高？还是内存换页率高？你可能需要全部都要考虑。这些信息要发送给那个任务分配器
上，由任务分配器挑选一台负载最轻的服务器来处理。
任务分配服务器上需要对任务队列，不能丢任务啊，所以还需要持久化。并且可以以批
量的方式把任务分配给计算服务器。
任务分配服务器死了怎么办？这里需要一些如Live-Standby或是failover等高可用性的
技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。
我看到有很多系统都用静态的方式来分配，有的用hash，有的就简单地轮流分析。这些
都不够好，一个是不能完美地负载均衡，另一个静态的方法的致命缺陷是，如果有一台
计算服务器死机了，或是我们需要加入新的服务器，对于我们的分配器来说，都需要知
道的。
还有一种方法是使用抢占式的方式进行负载均衡，由下游的计算服务器去任务服务器上
拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复
杂度，而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是，如果有一
些任务只能在某种服务器上处理，这可能会引入一些复杂度。不过总体来说，这种方法
可能是比较好的负载均衡。
五、异步、 throttle 和 批量处理
异步、throttle（节流阀） 和批量处理都需要对并发请求数做队列处理的。
异步在业务上一般来说就是收集请求，然后延时处理。在技术上就是可以把各个处理程
序做成并行的，也就可以水平扩展了。但是异步的技术问题大概有这些，a）被调用方
的结果返回，会涉及进程线程间通信的问题。b）如果程序需要回滚，回滚会有点复杂
。c）异步通常都会伴随多线程多进程，并发的控制也相对麻烦一些。d）很多异步系统
都用消息机制，消息的丢失和乱序也会是比较复杂的问题。
throttle 技术其实并不提升性能，这个技术主要是防止系统被超过自己不能处理的流
量给搞垮了，这其实是个保护机制。使用throttle技术一般来说是对于一些自己无法控
制的系统，比如，和你网站对接的银行系统。
批量处理的技术，是把一堆基本相同的请求批量处理。比如，大家同时购买同一个商品
，没有必要你买一个我就写一次数据库，完全可以收集到一定数量的请求，一次操作。
这个技术可以用作很多方面。比如节省网络带宽，我们都知道网络上的MTU（最大传输
单元），以态网是1500字节，光纤可以达到4000多个字节，如果你的一个网络包没有放
满这个MTU，那就是在浪费网络带宽，因为网卡的驱动程序只有一块一块地读效率才会
高。因此，网络发包时，我们需要收集到足够多的信息后再做网络I/O，这也是一种批
量处理的方式。批量处理的敌人是流量低，所以，批量处理的系统一般都会设置上两个
阀值，一个是作业量，另一个是timeout，只要有一个条件满足，就会开始提交处理。
所以，只要是异步，一般都会有throttle机制，一般都会有队列来排队，有队列，就会
有持久化，而系统一般都会使用批量的方式来处理。云风同学设计的“排队系统” 就
是这个技术。这和电子商务的订单系统很相似，就是说，我的系统收到了你的购票下单
请求，但是我还没有真正处理，我的系统会跟据我自己的处理能力来throttle住这些大
量的请求，并一点一点地处理。一旦处理完成，我就可以发邮件或短信告诉用户你来可
以真正购票了。
在这里，我想通过业务和用户需求方面讨论一下云风同学的这个排队系统，因为其从技
术上看似解决了这个问题，但是从业务和用户需求上来说可能还是有一些值得我们去深
入思考的地方：
1）队列的DoS攻击。首先，我们思考一下，这个队是个单纯地排队的吗？这样做还不够
好，因为这样我们不能杜绝黄牛，而且单纯的ticket_id很容易发生DoS攻击，比如，我
发起N个 ticket_id，进入购票流程后，我不买，我就耗你半个小时，很容易我就可以
让想买票的人几天都买不到票。有人说，用户应该要用身份证来排队， 这样在购买里
就必需要用这个身份证来买，但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注
册N个帐号来排队，但就是不买。黄牛这些人这个时候只需要干一个事，把网站搞得正
常人不能访问，让用户只能通过他们来买。
2）对列的一致性？对这个队列的操作是不是需要锁？只要有锁，性能一定上不去。试
想，100万个人同时要求你来分配位置号，这个队列将会成为性能瓶颈。你一定没有数
据库实现得性能好，所以，可能比现在还差
3）队列的等待时间。购票时间半小时够不够？多不多？要是那时用户正好不能上网呢
？如果时间短了，用户不够时间操作也会抱怨，如果时间长了，后面在排队的那些人也
会抱怨。这个方法可能在实际操作上会有很多问题。另外，半个小时太长了，这完全不
现实，我们用15分钟来举例：有1千万用户，每一个时刻只能放进去1万个，这1万个用
户需要15分钟完成所有操作，那么，这1千万用户全部处理完，需要1000*15m = 250小
时，10天半，火车早开了。（我并非乱说，根据铁道部专家的说明：这几天，平均一天
下单100万，所以，处理1000万的用户需要十天。这个计算可能有点简单了，我只是想
说，在这样低负载的系统下用排队可能都不能解决问题）
4）队列的分布式。这个排队系统只有一个队列好吗？还不足够好。因为，如果你放进
去的可以购票的人如果在买同一个车次的同样的类型的票（比如某动车卧铺），还是等
于在抢票，也就是说系统的负载还是会有可能集中到其中某台服务器上。因此，最好的
方法是根据用户的需求——提供出发地和目的地，来对用户进行排队。而这样一来，队
列也就可以是多个，只要是多个队列，就可以水平扩展了。
我觉得完全可以向网上购物学习。在排队（下单）的时候，收集好用户的信息和想要买
的票，并允许用户设置购票的优先级，比如，A车次卧铺买 不到就买 B车次的卧铺，如
果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地
异步处理订单。成功不成功都发短信或邮件通知用户。这样，系统不仅可以省去那半个
小时的用户交互时间，自动化加快处理，还可以合并相同购票请求的人，进行批处理（
减少数据库的操作次数）。这种方法最妙的事是可以知道这些排队用户的需求，不但可
以优化用户的队列，把用户分布到不同的队列，还可以像亚马逊的心愿单一样，让铁道
部做车次统筹安排和调整（最后，排队系统（下单系统）还是要保存在数据库里的或做
持久化，不能只放在内存中，不然机器一down，就等着被骂吧）。
小结
写了那么多，我小结一下：
0）无论你怎么设计，你的系统一定要能容易地水平扩展。也就是说，你的整个数据流
中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，“加3倍的服务
器”才不会被人讥笑。
1）上述的技术不是一朝一夕能搞定的，没有长期的积累，基本无望。我们可以看到，
无论你用哪种都会引发一些复杂性。
2）集中式的卖票很难搞定，使用上述的技术可以让订票系统能有几佰倍的性能提升。
而在各个省市建分站，分开卖票，是能让现有系统性能有质的提升的最好方法。
3）春运前夕抢票且票量供远小于求这种业务模式是相当变态的，让几千万甚至上亿的
人在某个早晨的8点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的
变态决定了无论他们怎么办干一定会被骂。
4）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也
就是铁路才干得出来这样的事了。
发信人: Westridge (不折腾), 信区: WashingtonDC
标 题: 学习学习国内的IT项目-12306铁道部订票网站性能分析【转载】
发信站: BBS 未名空间站 (Thu Jan 17 14:48:59 2013, 美东)
学习学习国内的IT项目-12306铁道部订票网站性能分析【转载】
业务
任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。
一，有人可能把这个东西和QQ或是网游相比。
但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据
，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就
以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。
二，有人说春节期间订火车的这个事好像网站的秒杀活动。
的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个
事，还有很多查询操作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次
，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀，直接杀就好了。
另外，关于秒杀，完全可以做成只接受前N个用户的请求（完全不操作后端的任何数据
， 仅仅只是对用户的下单操作log），这种业务，只要把各个服务器的时间精确同步了
就可以了，无需在当时操作任何数据库。可以订单数够后，停止秒杀，然后批量写数据
库。火车票这个岂止是秒杀那么简单。能不能买到票得当时告诉用户啊。
三，有人拿这个系统和奥运会的票务系统比较。
我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽
奖的方式，也就是说不存在先来先得的抢的方式，而且，是事后抽奖，事前只需要收信
息，事前不需要保证数据一致性，没有锁，很容易水平扩展。
四，订票系统应该和电子商务的订单系统很相似。
都是需要对库存进行：1）占住库存，2）支付（可选），3）扣除库存的操作。这个是
需要有一致性的检查的，也就是在并发时需要对数据加锁的。B2C的电商基本上都会把
这个事干成异步的，也就是说，你下的订单并不是马上处理的，而是延时处理的，只有
成功处理了，系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单
不成功的邮件。这就是说，数据一致性在并发下是一个瓶颈。
五，铁路的票务业务很变态。
其采用的是突然放票，而有的票又远远不够大家分，所以，大家才会有抢票这种有中国
特色的业务的做法。于是当票放出来的时候，就会有几百万人甚至上千万人杀上去，查
询，下单。几十分钟内，一个网站能接受几千万的访问量，这个是很恐怖的事情。据说
12306的高峰访问是10亿PV，集中在早8点到10点，每秒PV在高峰时上千万。
多说几句：
一、库存是B2C的恶梦，库存管理相当的复杂。
不信，你可以问问所有传统和电务零售业的企业，看看他们管理库存是多么难的一件事
。不然，就不会有那么多人在问凡客的库存问题了。（你还可以看看《乔布斯传》，你
就知道为什么Tim会接任Apple的CEO了，因为他搞定了苹果的库存问题）
二、对于一个网站来说，浏览网页的高负载很容易搞定，查询的负载有一定的难度去处
理，不过还是可以通过缓存查询结果来搞定，最难的就是下单的负载。
因为要访问库存啊，对于下单，基本上是用异步来搞定的。去年双11节，淘宝的每小时
的订单数大约在60万左右，京东一天也才能支持40万（居然比12306还差），亚马逊5年
前一小时可支持70万订单量。可见，下订单的操作并没有我们相像的那么性能高。
三、淘宝要比B2C的网站要简单得多，因为没有仓库。
所以，不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候，
B2C的 网站要去找一个仓库，又要离用户近，又要有库存，这需要很多计算。试想，你
在北京买了一本书，北京的仓库没货了，就要从周边的仓库调，那就要去看看沈阳或
是西安的仓库有没有货，如果没有，又得看看江苏的仓库，等等。淘宝的就没有那么多
事了，每个商户有自己的库存，库存分到商户头上了，反而有利于性能。
四、数据一致性才是真正的性能瓶颈。
有人说nginx可以搞定每秒10万的静态请求，我不怀疑。但这只是静态请求，理论值，
只要带宽、I/O够强，服务器计算能力够，并支持的并发连接数顶得住10万TCP链接的建
立 的话，那没有问题。但在数据一致性面前，这10万就完完全全成了一个可望不可及
的理论值了。
我说那么多，我只是想从业务上告诉大家，我们需要从业务上真正了解春运铁路订票这
样业务的变态之处。
前端性能优化技术
要解决性能的问题，有很多种常用的方法，我在下面列举一下，我相信12306这个网站
使用下面的这些技术会让其性能有质的飞跃。
一、前端负载均衡
通过DNS的负载均衡器（一般在路由器上根据路由的负载重定向）可以把用户的访问均
匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都
是短作业，所以，可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让
用户连接与其最近的服务器（CDN通常伴随着分布式存储）。（关于负载均衡更为详细
的说明见“后端的负载均衡”）
二、减少前端链接数
我看了一下12306.cn，打开主页需要建60多个HTTP连接，车票预订页面则有70多个HTTP
请求，现在的浏览器都是并发请求的。所以，只要有100万个用户，就会有6000万个链
接，太多了。一个登录查询页面就好了。把js打成一个文件，把css也打成一个文件，
把图标也打成一个文件，用css分块展示。把链接数减到最低。
三、减少网页大小增加带宽
这个世界不是哪个公司都敢做图片服务的，因为图片太耗带宽了。现在宽带时代很难有
人能体会到当拨号时代做个图页都不敢用图片的情形（现在在手机端浏览也是这个情形
）。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右，如果你访问过
了，浏览器会帮你缓存很多，只需下载10K左右的文件。但是我们可以想像一个极端一
点的案例，1百万用户同时访问，且都是第一次访问，每人下载量需要1M，如果需要在
120秒内返回，那么就需要，1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以，我
估计在当天，12306的阻塞基本上应该是网络带宽，所以，你可能看到的是没有响应。
后面随着浏览器的缓存帮助12306减少很多带宽占用，于是负载一下就到了后端，后端
的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明服务器垮
了。
四、前端页面静态化
静态化一些不常变的页面和数据，并gzip一下。还有一个并态的方法是把这些静态页面
放在/dev/shm下，这个目录就是内存，直接从内存中把文件读出来返回，这样可以减少
昂贵的磁盘I/O。
五、优化查询
很多人查询都是在查一样的，完全可以用反向代理合并这些并发的相同的查询。这样的
技术主要用查询结果缓存来实现，第一次查询走数据库获得数据，并把数据放到缓存，
后面的查询统统直接访问高速缓存。为每个查询做Hash，使用NoSQL的技术可以完成这
个优化（这个技术也可以用做静态页面）对于火车票量的查询，个人觉得不要显示数字
，就显示一个“有”或“无”就好了，这样可以大大简化系统复杂度，并提升性能。
六、缓存的问题
缓存可以用来缓存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题：
1）缓存的更新。也叫缓存和数据库的同步。有这么几种方法，一是缓存time out，让
缓存失效，重查，二是，由后端通知更新，一量后端发生变化，通知前端更新。前者实
现起来比较简单，但实时性不高，后者实现起来比较复杂 ，但实时性高。
2）缓存的换页。内存可能不够，所以，需要把一些不活跃的数据换出内存，这个和操
作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关
内容参看Wikipeida的缓存算法。
3）缓存的重建和持久化。缓存在内存，系统总要维护，所以，缓存就会丢失，如果缓
存没了，就需要重建，如果数据量很大，缓存重建的过程会很慢，这会影响生产环境，
所以，缓存的持久化也是需要考虑的。诸多强大的NoSQL都很好支持了上述三大缓存的
问题。
后端性能优化技术
前面讨论了前端性能的优化技术，于是前端可能就不是瓶颈问题了。那么性能问题就会
到后端数据上来了。下面说几个后端常见的性能优化技术。
一、数据冗余
关于数据冗余，也就是说，把我们的数据库的数据冗余处理，也就是减少表连接这样的
开销比较大的操作，但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数
据，快是快了，因为数据冗余了，但这对数据一致性有大的风险。这需要根据不同的业
务进行分析和处理。（注意：用关系型数据库很容易移植到NoSQL上，但是反过来从
NoSQL到关系型就难了）
二、数据镜像
几乎所有主流的数据库都支持镜像，也就是replication。数据库的镜像带来的好处就
是可以做负载均衡。把一台数据库的负载均分到多台上，同时又保证了数据一致性（
Oracle的SCN）。最重要的是，这样还可以有高可用性，一台废了，还有另一台在服务
。数据镜像的数据一致性可能是个复杂的问题，所以我们要在单条数据上进行数据分区
，也就是说，把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品有1万
的库存，我们可以设置10台服务器，每台服务器上有1000个库存，这就好像B2C的仓库
一样。
三、数据分区
数据镜像不能解决的一个问题就是数据表里的记录太多，导致数据库操作太慢。所以，
把数据分区。数据分区有很多种做法，一般来说有下面这几种：
1）把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分，可按各种
车型分，可以按始发站分，可以按目的地分……，反正就是把一张表拆成多张有一样的
字段但是不同种类的表，这样，这些表就可以存在不同的机器上以达到分担负载的目的。
2）把数据按字段分，也就是竖着分表。比如把一些不经常改的数据放在一个表里，经
常改的数据放在另外多个表里。把一张表变成1对1的关系，这样，你可以减少表的字段
个数，同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被放到不同的
页表里，这对于读写性能都有问题。但这样一来会有很多复杂的控制。
3）平均分表。因为第一种方法是并不一定平均分均，可能某个种类的数据还是很多。
所以，也有采用平均分配的方式，通过主键ID的范围来分表。
4）同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的
服务器上，比如有10000个库存，可以分到10台服务器上，一台上有1000个库存。然后
负载均衡。
这三种分区都有好有坏。最常用的还是第一种。数据一旦分区，你就需要有一个或是多
个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区，并放在各个省市，
会对12306这个系统有非常有意义的质的性能的提高。
四、后端系统负载均衡
前面说了数据分区，数据分区可以在一定程度上减轻负载，但是无法减轻热销商品的负
载，对于火车票来说，可以认为是大城市的某些主干线上的车票。这就需要使用数据镜
像来减轻负载。使用数据镜像，你必然要使用负载均衡，在后端，我们可能很难使用像
路由器上的负载均衡器，因为那是均衡流量的，因为流量并不代表服务器的繁忙程度。
因此，我们需要一个任务分配系统，其还能监控各个服务器的负载情况。
任务分配服务器有一些难点：
负载情况比较复杂。什么叫忙？是CPU高？还是磁盘I/O高？还是内存使用高？还是并发
高？还是内存换页率高？你可能需要全部都要考虑。这些信息要发送给那个任务分配器
上，由任务分配器挑选一台负载最轻的服务器来处理。
任务分配服务器上需要对任务队列，不能丢任务啊，所以还需要持久化。并且可以以批
量的方式把任务分配给计算服务器。
任务分配服务器死了怎么办？这里需要一些如Live-Standby或是failover等高可用性的
技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。
我看到有很多系统都用静态的方式来分配，有的用hash，有的就简单地轮流分析。这些
都不够好，一个是不能完美地负载均衡，另一个静态的方法的致命缺陷是，如果有一台
计算服务器死机了，或是我们需要加入新的服务器，对于我们的分配器来说，都需要知
道的。
还有一种方法是使用抢占式的方式进行负载均衡，由下游的计算服务器去任务服务器上
拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复
杂度，而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是，如果有一
些任务只能在某种服务器上处理，这可能会引入一些复杂度。不过总体来说，这种方法
可能是比较好的负载均衡。
五、异步、 throttle 和 批量处理
异步、throttle（节流阀） 和批量处理都需要对并发请求数做队列处理的。
异步在业务上一般来说就是收集请求，然后延时处理。在技术上就是可以把各个处理程
序做成并行的，也就可以水平扩展了。但是异步的技术问题大概有这些，a）被调用方
的结果返回，会涉及进程线程间通信的问题。b）如果程序需要回滚，回滚会有点复杂
。c）异步通常都会伴随多线程多进程，并发的控制也相对麻烦一些。d）很多异步系统
都用消息机制，消息的丢失和乱序也会是比较复杂的问题。
throttle 技术其实并不提升性能，这个技术主要是防止系统被超过自己不能处理的流
量给搞垮了，这其实是个保护机制。使用throttle技术一般来说是对于一些自己无法控
制的系统，比如，和你网站对接的银行系统。
批量处理的技术，是把一堆基本相同的请求批量处理。比如，大家同时购买同一个商品
，没有必要你买一个我就写一次数据库，完全可以收集到一定数量的请求，一次操作。
这个技术可以用作很多方面。比如节省网络带宽，我们都知道网络上的MTU（最大传输
单元），以态网是1500字节，光纤可以达到4000多个字节，如果你的一个网络包没有放
满这个MTU，那就是在浪费网络带宽，因为网卡的驱动程序只有一块一块地读效率才会
高。因此，网络发包时，我们需要收集到足够多的信息后再做网络I/O，这也是一种批
量处理的方式。批量处理的敌人是流量低，所以，批量处理的系统一般都会设置上两个
阀值，一个是作业量，另一个是timeout，只要有一个条件满足，就会开始提交处理。
所以，只要是异步，一般都会有throttle机制，一般都会有队列来排队，有队列，就会
有持久化，而系统一般都会使用批量的方式来处理。云风同学设计的“排队系统” 就
是这个技术。这和电子商务的订单系统很相似，就是说，我的系统收到了你的购票下单
请求，但是我还没有真正处理，我的系统会跟据我自己的处理能力来throttle住这些大
量的请求，并一点一点地处理。一旦处理完成，我就可以发邮件或短信告诉用户你来可
以真正购票了。
在这里，我想通过业务和用户需求方面讨论一下云风同学的这个排队系统，因为其从技
术上看似解决了这个问题，但是从业务和用户需求上来说可能还是有一些值得我们去深
入思考的地方：
1）队列的DoS攻击。首先，我们思考一下，这个队是个单纯地排队的吗？这样做还不够
好，因为这样我们不能杜绝黄牛，而且单纯的ticket_id很容易发生DoS攻击，比如，我
发起N个 ticket_id，进入购票流程后，我不买，我就耗你半个小时，很容易我就可以
让想买票的人几天都买不到票。有人说，用户应该要用身份证来排队， 这样在购买里
就必需要用这个身份证来买，但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注
册N个帐号来排队，但就是不买。黄牛这些人这个时候只需要干一个事，把网站搞得正
常人不能访问，让用户只能通过他们来买。
2）对列的一致性？对这个队列的操作是不是需要锁？只要有锁，性能一定上不去。试
想，100万个人同时要求你来分配位置号，这个队列将会成为性能瓶颈。你一定没有数
据库实现得性能好，所以，可能比现在还差
3）队列的等待时间。购票时间半小时够不够？多不多？要是那时用户正好不能上网呢
？如果时间短了，用户不够时间操作也会抱怨，如果时间长了，后面在排队的那些人也
会抱怨。这个方法可能在实际操作上会有很多问题。另外，半个小时太长了，这完全不
现实，我们用15分钟来举例：有1千万用户，每一个时刻只能放进去1万个，这1万个用
户需要15分钟完成所有操作，那么，这1千万用户全部处理完，需要1000*15m = 250小
时，10天半，火车早开了。（我并非乱说，根据铁道部专家的说明：这几天，平均一天
下单100万，所以，处理1000万的用户需要十天。这个计算可能有点简单了，我只是想
说，在这样低负载的系统下用排队可能都不能解决问题）
4）队列的分布式。这个排队系统只有一个队列好吗？还不足够好。因为，如果你放进
去的可以购票的人如果在买同一个车次的同样的类型的票（比如某动车卧铺），还是等
于在抢票，也就是说系统的负载还是会有可能集中到其中某台服务器上。因此，最好的
方法是根据用户的需求——提供出发地和目的地，来对用户进行排队。而这样一来，队
列也就可以是多个，只要是多个队列，就可以水平扩展了。
我觉得完全可以向网上购物学习。在排队（下单）的时候，收集好用户的信息和想要买
的票，并允许用户设置购票的优先级，比如，A车次卧铺买 不到就买 B车次的卧铺，如
果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地
异步处理订单。成功不成功都发短信或邮件通知用户。这样，系统不仅可以省去那半个
小时的用户交互时间，自动化加快处理，还可以合并相同购票请求的人，进行批处理（
减少数据库的操作次数）。这种方法最妙的事是可以知道这些排队用户的需求，不但可
以优化用户的队列，把用户分布到不同的队列，还可以像亚马逊的心愿单一样，让铁道
部做车次统筹安排和调整（最后，排队系统（下单系统）还是要保存在数据库里的或做
持久化，不能只放在内存中，不然机器一down，就等着被骂吧）。
小结
写了那么多，我小结一下：
0）无论你怎么设计，你的系统一定要能容易地水平扩展。也就是说，你的整个数据流
中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，“加3倍的服务
器”才不会被人讥笑。
1）上述的技术不是一朝一夕能搞定的，没有长期的积累，基本无望。我们可以看到，
无论你用哪种都会引发一些复杂性。
2）集中式的卖票很难搞定，使用上述的技术可以让订票系统能有几佰倍的性能提升。
而在各个省市建分站，分开卖票，是能让现有系统性能有质的提升的最好方法。
3）春运前夕抢票且票量供远小于求这种业务模式是相当变态的，让几千万甚至上亿的
人在某个早晨的8点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的
变态决定了无论他们怎么办干一定会被骂。
4）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也
就是铁路才干得出来这样的事了。
F*D
5 楼
应该不便宜
【在 c******l 的大作中提到】
: 马上回去，五一上海的宾馆会因为世博会很紧张吗？
【在 c******l 的大作中提到】
: 马上回去，五一上海的宾馆会因为世博会很紧张吗？
a*9
6 楼
rs1还是直接上ra1吧
s*m
7 楼
bless~
【在 e**********t 的大作中提到】
: 预约是9点，9点半签完。没问太多问题。要了我们的签证和I-94，虽然我们有绿卡了。
: 一些材料列表
: 邀请方:
: 1. 签证申请表, DS156, DS157
: 2. 致签证官的信
: 3. 大使馆致国会议员的回复
: 4. 国会议员致大使馆的信
: 5. 给国会议员的信
: 6. 中文邀请信
: 7. 邀请人护照、绿卡的复印件
【在 e**********t 的大作中提到】
: 预约是9点，9点半签完。没问太多问题。要了我们的签证和I-94，虽然我们有绿卡了。
: 一些材料列表
: 邀请方:
: 1. 签证申请表, DS156, DS157
: 2. 致签证官的信
: 3. 大使馆致国会议员的回复
: 4. 国会议员致大使馆的信
: 5. 给国会议员的信
: 6. 中文邀请信
: 7. 邀请人护照、绿卡的复印件
H*d
8 楼
这篇国内的分析还挺有意思的，这里的大牛们也讨论讨论吧。
C*n
9 楼
弄个仿的就行了
成本十来刀的东西，卖400
【在 a*******9 的大作中提到】
: rs1还是直接上ra1吧
成本十来刀的东西，卖400
【在 a*******9 的大作中提到】
: rs1还是直接上ra1吧
n*l
10 楼
Bless~
m*5
11 楼
全市鬼扯分析, 机票订票系统多少年了,20年了快!
就找一套一模一样的系统实施下来也不是这破样 (机票是全世界联网)
欧洲火车还不同公司联网,也没出过岔子
就找一套一模一样的系统实施下来也不是这破样 (机票是全世界联网)
欧洲火车还不同公司联网,也没出过岔子
n*T
12 楼
哪里弄得到？
【在 C********n 的大作中提到】
: 弄个仿的就行了
: 成本十来刀的东西，卖400
x*i
13 楼
bless!
x*u
14 楼
火车运力和飞机不是一个数量级的。
【在 m********5 的大作中提到】
: 全市鬼扯分析, 机票订票系统多少年了,20年了快!
: 就找一套一模一样的系统实施下来也不是这破样 (机票是全世界联网)
: 欧洲火车还不同公司联网,也没出过岔子
【在 m********5 的大作中提到】
: 全市鬼扯分析, 机票订票系统多少年了,20年了快!
: 就找一套一模一样的系统实施下来也不是这破样 (机票是全世界联网)
: 欧洲火车还不同公司联网,也没出过岔子
p*m
15 楼
eBay上找小龙的Mini-RA1。
【在 n*****T 的大作中提到】
:
: 哪里弄得到？
【在 n*****T 的大作中提到】
:
: 哪里弄得到？
c*h
16 楼
祝福
d*q
17 楼
主要是春运时 移动的人太多。其他系统不会有这种突然的压力。
n*T
18 楼
有用过的给说说效果一样否？
【在 p****m 的大作中提到】
: eBay上找小龙的Mini-RA1。
Q*B
19 楼
g*g
20 楼
最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
，批量进行。
服务器大部分时间闲置的问题，最合适的就是cloud了。
，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
，批量进行。
服务器大部分时间闲置的问题，最合适的就是cloud了。
n*T
21 楼
http://cgi.ebay.com/YULONG-Mini-Portable-Battery-RA1-Headphone-Amplifier-/250671692157?
pt=LH_DefaultDomain_0&hash=item3a5d32797d
这个吗？
【在 p****m 的大作中提到】
: eBay上找小龙的Mini-RA1。
Q*B
22 楼
bless
z*e
23 楼
是一个数量级的
民航一般是几个国家的所有航空公司出资建一个系统
所以这个星球上其实所有的机票资源都来自那么屈指可数的几个系统，n<10
另外，这几个系统实现的语言截然不同
北美是java写的，欧洲是c++写的，还有一些古老的是用fortran写的
而且机器也不一样，大部分都是特制的主机
大部分来自ibm，所以当铁道部竞标的时候
只有ibm有成熟的方案，成了铁道部除了他自己搞以外唯一的选择
但是要在一夜之前实现民航几十年的成果，那所需要的成本是十分巨大的
铁道部权衡了之后，很伟大地决定自己搞，理由是ibm的解决方案太贵
于是就华丽地挂了
【在 x****u 的大作中提到】
: 火车运力和飞机不是一个数量级的。
民航一般是几个国家的所有航空公司出资建一个系统
所以这个星球上其实所有的机票资源都来自那么屈指可数的几个系统，n<10
另外，这几个系统实现的语言截然不同
北美是java写的，欧洲是c++写的，还有一些古老的是用fortran写的
而且机器也不一样，大部分都是特制的主机
大部分来自ibm，所以当铁道部竞标的时候
只有ibm有成熟的方案，成了铁道部除了他自己搞以外唯一的选择
但是要在一夜之前实现民航几十年的成果，那所需要的成本是十分巨大的
铁道部权衡了之后，很伟大地决定自己搞，理由是ibm的解决方案太贵
于是就华丽地挂了
【在 x****u 的大作中提到】
: 火车运力和飞机不是一个数量级的。
C*n
24 楼
yes
RA1没啥技术含量
http://www.erji.net/read.php?tid=237872
看看就知道了
耳放 DAC之类的，向来是十倍以上的暴利,50倍也是很正常的
【在 n*****T 的大作中提到】
:
: http://cgi.ebay.com/YULONG-Mini-Portable-Battery-RA1-Headphone-Amplifier-/250671692157?
: pt=LH_DefaultDomain_0&hash=item3a5d32797d
: 这个吗？
RA1没啥技术含量
http://www.erji.net/read.php?tid=237872
看看就知道了
耳放 DAC之类的，向来是十倍以上的暴利,50倍也是很正常的
【在 n*****T 的大作中提到】
:
: http://cgi.ebay.com/YULONG-Mini-Portable-Battery-RA1-Headphone-Amplifier-/250671692157?
: pt=LH_DefaultDomain_0&hash=item3a5d32797d
: 这个吗？
l*6
25 楼
ｂｌｅｓｓ！！
z*e
26 楼
这也是eai的老问题了
global transaction的死结
所以关键就在于卖不卖联程票
如果卖，那恐怕不是那么简单，要上主机
如果不卖，这个分布式可以搞定
【在 g*****g 的大作中提到】
: 最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
: ，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
: ，批量进行。
: 服务器大部分时间闲置的问题，最合适的就是cloud了。
global transaction的死结
所以关键就在于卖不卖联程票
如果卖，那恐怕不是那么简单，要上主机
如果不卖，这个分布式可以搞定
【在 g*****g 的大作中提到】
: 最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
: ，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
: ，批量进行。
: 服务器大部分时间闲置的问题，最合适的就是cloud了。
e*t
27 楼
谢谢大家的祝福。还有十几个小时爸妈就要去签证了，好紧张呀，他们之前被据过。请
大家多多祝福，如果过了，一定来贡献有用签经。
大家多多祝福，如果过了，一定来贡献有用签经。
z*e
28 楼
主要问题并不在于这些技术细节
而在于铁道部一开始
在建设基建的时候
就没有把it系统配套跟上
世界上其他国家，尤其是发达国家的基建
一开始就把it系统做了配套
然后在发展的过程中逐步改善
而且大多数时候都是主动改良的
比如网络售票，这种事不用上级下命令
航空公司自己都会去推动
也就不用等到春节前后再来匆匆忙忙上马项目了
在淡季就可以解决很多负载的问题
所以it系统也是基建中很重要的一个组成部分
所以哪里都用得到it，软件更是必不可少
而这些领域里面，java几乎无处不在
所以有时候有些人说某些人没有大型项目经验
不是没有道理的，你到现在都没意识到java用在什么地方
还在大谈用其他语言尤其是c或者c++写“大型项目”
然后跑出来说自己有大型项目经验，哈，你忽悠谁呢？
有经验的人可以在一分钟之内识破你的谎言
我到现在为止，见过这么大的基建系统用非java的语言写的
只有欧洲那一个公司，那是没有办法
因为最初做那个系统时候还没有java，所以不得已，用c++实现
除此之外，都是java写的，包括前面说的那些用fortran写的
现在应该都已经转到java上去了
而在于铁道部一开始
在建设基建的时候
就没有把it系统配套跟上
世界上其他国家，尤其是发达国家的基建
一开始就把it系统做了配套
然后在发展的过程中逐步改善
而且大多数时候都是主动改良的
比如网络售票，这种事不用上级下命令
航空公司自己都会去推动
也就不用等到春节前后再来匆匆忙忙上马项目了
在淡季就可以解决很多负载的问题
所以it系统也是基建中很重要的一个组成部分
所以哪里都用得到it，软件更是必不可少
而这些领域里面，java几乎无处不在
所以有时候有些人说某些人没有大型项目经验
不是没有道理的，你到现在都没意识到java用在什么地方
还在大谈用其他语言尤其是c或者c++写“大型项目”
然后跑出来说自己有大型项目经验，哈，你忽悠谁呢？
有经验的人可以在一分钟之内识破你的谎言
我到现在为止，见过这么大的基建系统用非java的语言写的
只有欧洲那一个公司，那是没有办法
因为最初做那个系统时候还没有java，所以不得已，用c++实现
除此之外，都是java写的，包括前面说的那些用fortran写的
现在应该都已经转到java上去了
a9
29 楼
恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
只不过中标方技术太差又不舍得投钱罢了。
【在 g*****g 的大作中提到】
: 最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
: ，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
: ，批量进行。
: 服务器大部分时间闲置的问题，最合适的就是cloud了。
只不过中标方技术太差又不舍得投钱罢了。
【在 g*****g 的大作中提到】
: 最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
: ，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
: ，批量进行。
: 服务器大部分时间闲置的问题，最合适的就是cloud了。
m*x
30 楼
最大的问题是峰值太大,这是中国特色,把其他的系统拿来,也顶不住
【在 a9 的大作中提到】
: 恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
: 只不过中标方技术太差又不舍得投钱罢了。
【在 a9 的大作中提到】
: 恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
: 只不过中标方技术太差又不舍得投钱罢了。
B*g
31 楼
ding
【在 g*****g 的大作中提到】
: 最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
: ，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
: ，批量进行。
: 服务器大部分时间闲置的问题，最合适的就是cloud了。
【在 g*****g 的大作中提到】
: 最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
: ，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
: ，批量进行。
: 服务器大部分时间闲置的问题，最合适的就是cloud了。
H*d
32 楼
对，这个恐怕是国内铁路相对于其它系统的一个最大的不同。我估计就算圣诞期间，欧
美的航班系统负荷都抵不上春运的负荷。
【在 m***x 的大作中提到】
: 最大的问题是峰值太大,这是中国特色,把其他的系统拿来,也顶不住
美的航班系统负荷都抵不上春运的负荷。
【在 m***x 的大作中提到】
: 最大的问题是峰值太大,这是中国特色,把其他的系统拿来,也顶不住
S*k
33 楼
春节期间的加车是很多的，不少是跨路局的。
原理看似简单，中国的春节特色大大增加了这个系统难度。
【在 a9 的大作中提到】
: 恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
: 只不过中标方技术太差又不舍得投钱罢了。
原理看似简单，中国的春节特色大大增加了这个系统难度。
【在 a9 的大作中提到】
: 恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
: 只不过中标方技术太差又不舍得投钱罢了。
W*e
34 楼
按车次分不如按到达的目的地分。广州，武汉，北京，成都，上海这几个城市才是春运
最挤的地方。而且车次不时还需要变动。
每列车载客可能在1200-1500左右，如果同时有五倍的人员在订票，哪怕给每个人从下
单到出票平均只加锁几分钟，就算计算机系统没有任何瓶颈，大部分时间所有的票也都
是被锁住的。跟手机在9/11的logjam类似。春运期间热门车次可能都不止五倍的人员想
订票。这种业务模式很变态。想买票的人可能总等不到票，黄牛党可能把票锁住也不买
，造成最后剩票可能还得通过黄牛党买。
改变这种业务模式得改变一下提前同时放票的模式。比如提前几个月可以申请排号，号
满了还可以排在waiting list，如果前面的有人撤消了后面的队列自动前进。最后出票
直接按号出票。每个人还可以加几个候选车次，前面的车次搞定了后面其他的车次自动
取消。
【在 a9 的大作中提到】
: 恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
: 只不过中标方技术太差又不舍得投钱罢了。
最挤的地方。而且车次不时还需要变动。
每列车载客可能在1200-1500左右，如果同时有五倍的人员在订票，哪怕给每个人从下
单到出票平均只加锁几分钟，就算计算机系统没有任何瓶颈，大部分时间所有的票也都
是被锁住的。跟手机在9/11的logjam类似。春运期间热门车次可能都不止五倍的人员想
订票。这种业务模式很变态。想买票的人可能总等不到票，黄牛党可能把票锁住也不买
，造成最后剩票可能还得通过黄牛党买。
改变这种业务模式得改变一下提前同时放票的模式。比如提前几个月可以申请排号，号
满了还可以排在waiting list，如果前面的有人撤消了后面的队列自动前进。最后出票
直接按号出票。每个人还可以加几个候选车次，前面的车次搞定了后面其他的车次自动
取消。
【在 a9 的大作中提到】
: 恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
: 只不过中标方技术太差又不舍得投钱罢了。
H*d
35 楼
分散放票，提前订票，这些都是没用的吧
肯定在开放预定的那一瞬间爆服务器就爆掉
和票量没关系，大家都想着先抢到再说，等后面的放票谁能保证能买到？
【在 W*******e 的大作中提到】
: 按车次分不如按到达的目的地分。广州，武汉，北京，成都，上海这几个城市才是春运
: 最挤的地方。而且车次不时还需要变动。
: 每列车载客可能在1200-1500左右，如果同时有五倍的人员在订票，哪怕给每个人从下
: 单到出票平均只加锁几分钟，就算计算机系统没有任何瓶颈，大部分时间所有的票也都
: 是被锁住的。跟手机在9/11的logjam类似。春运期间热门车次可能都不止五倍的人员想
: 订票。这种业务模式很变态。想买票的人可能总等不到票，黄牛党可能把票锁住也不买
: ，造成最后剩票可能还得通过黄牛党买。
: 改变这种业务模式得改变一下提前同时放票的模式。比如提前几个月可以申请排号，号
: 满了还可以排在waiting list，如果前面的有人撤消了后面的队列自动前进。最后出票
: 直接按号出票。每个人还可以加几个候选车次，前面的车次搞定了后面其他的车次自动
肯定在开放预定的那一瞬间爆服务器就爆掉
和票量没关系，大家都想着先抢到再说，等后面的放票谁能保证能买到？
【在 W*******e 的大作中提到】
: 按车次分不如按到达的目的地分。广州，武汉，北京，成都，上海这几个城市才是春运
: 最挤的地方。而且车次不时还需要变动。
: 每列车载客可能在1200-1500左右，如果同时有五倍的人员在订票，哪怕给每个人从下
: 单到出票平均只加锁几分钟，就算计算机系统没有任何瓶颈，大部分时间所有的票也都
: 是被锁住的。跟手机在9/11的logjam类似。春运期间热门车次可能都不止五倍的人员想
: 订票。这种业务模式很变态。想买票的人可能总等不到票，黄牛党可能把票锁住也不买
: ，造成最后剩票可能还得通过黄牛党买。
: 改变这种业务模式得改变一下提前同时放票的模式。比如提前几个月可以申请排号，号
: 满了还可以排在waiting list，如果前面的有人撤消了后面的队列自动前进。最后出票
: 直接按号出票。每个人还可以加几个候选车次，前面的车次搞定了后面其他的车次自动
B*i
36 楼
改改业务模式就可以了。
发售之前 接受预定， 用身份证。 预收30％票价。 开售的时候如果overbook了， 就
抽签决定谁拿到票。
发售之前 接受预定， 用身份证。 预收30％票价。 开售的时候如果overbook了， 就
抽签决定谁拿到票。
W*e
37 楼
提前排号不用加锁
【在 H*******d 的大作中提到】
: 分散放票，提前订票，这些都是没用的吧
: 肯定在开放预定的那一瞬间爆服务器就爆掉
: 和票量没关系，大家都想着先抢到再说，等后面的放票谁能保证能买到？
【在 H*******d 的大作中提到】
: 分散放票，提前订票，这些都是没用的吧
: 肯定在开放预定的那一瞬间爆服务器就爆掉
: 和票量没关系，大家都想着先抢到再说，等后面的放票谁能保证能买到？
B*g
38 楼
其实，过节期间票价*10就行了
【在 W*******e 的大作中提到】
: 提前排号不用加锁
【在 W*******e 的大作中提到】
: 提前排号不用加锁
N*m
39 楼
那要被骂死
【在 B*****g 的大作中提到】
: 其实，过节期间票价*10就行了
【在 B*****g 的大作中提到】
: 其实，过节期间票价*10就行了
N*m
40 楼
肯定overbook，你这种方法其实就是抽签么
【在 B***i 的大作中提到】
: 改改业务模式就可以了。
: 发售之前 接受预定， 用身份证。 预收30％票价。 开售的时候如果overbook了， 就
: 抽签决定谁拿到票。
【在 B***i 的大作中提到】
: 改改业务模式就可以了。
: 发售之前 接受预定， 用身份证。 预收30％票价。 开售的时候如果overbook了， 就
: 抽签决定谁拿到票。
N*n
41 楼
A cloud-based solution is right for such case where infrastructure
could be allocated dynamically when the load shoots up.
【在 m***x 的大作中提到】
: 最大的问题是峰值太大,这是中国特色,把其他的系统拿来,也顶不住
c*e
42 楼
它们用的啥framework,用的java? 这玩艺其实很简单啊，每个车次，每个车里面的座位
都是固定的，唯一的难度就是可能有大量顾客同時网上买票，这样造成数据库交易瓶颈
，这个就是在西方国家也不好搞吧。中国人多，没办法。
【在 H*******d 的大作中提到】
: 分散放票，提前订票，这些都是没用的吧
: 肯定在开放预定的那一瞬间爆服务器就爆掉
: 和票量没关系，大家都想着先抢到再说，等后面的放票谁能保证能买到？
都是固定的，唯一的难度就是可能有大量顾客同時网上买票，这样造成数据库交易瓶颈
，这个就是在西方国家也不好搞吧。中国人多，没办法。
【在 H*******d 的大作中提到】
: 分散放票，提前订票，这些都是没用的吧
: 肯定在开放预定的那一瞬间爆服务器就爆掉
: 和票量没关系，大家都想着先抢到再说，等后面的放票谁能保证能买到？
W*e
43 楼
我看到有struts的痕迹。国内比较流行的是SSH框架。但整个网站有几种风格，应该是
不同公司做不同的模块。
数据量大到一定程度有时候就不是框架能解决的。比如淘宝网专门为billion数量级的
图片存储和查询优化做了类似云端的底层分级存储系统，腾讯网把通信层也做了像
Citrix之类
的改变。
【在 c*********e 的大作中提到】
: 它们用的啥framework,用的java? 这玩艺其实很简单啊，每个车次，每个车里面的座位
: 都是固定的，唯一的难度就是可能有大量顾客同時网上买票，这样造成数据库交易瓶颈
: ，这个就是在西方国家也不好搞吧。中国人多，没办法。
不同公司做不同的模块。
数据量大到一定程度有时候就不是框架能解决的。比如淘宝网专门为billion数量级的
图片存储和查询优化做了类似云端的底层分级存储系统，腾讯网把通信层也做了像
Citrix之类
的改变。
【在 c*********e 的大作中提到】
: 它们用的啥framework,用的java? 这玩艺其实很简单啊，每个车次，每个车里面的座位
: 都是固定的，唯一的难度就是可能有大量顾客同時网上买票，这样造成数据库交易瓶颈
: ，这个就是在西方国家也不好搞吧。中国人多，没办法。
c*e
44 楼
struts不是已经被spring取代了吗？spring,hibernate是王道。那个什么java beans,
尤其是stateful的，用完了到了pool里，要再用还挺麻烦的.而且一个java bean就是一
个大package,真的非常占内存，也没必要。所以有人说，尽量用stateless的beans.如
果春运卖票系统要用sateful的，那不把系统搞瘫痪不可，嘿嘿。
【在 W*******e 的大作中提到】
: 我看到有struts的痕迹。国内比较流行的是SSH框架。但整个网站有几种风格，应该是
: 不同公司做不同的模块。
: 数据量大到一定程度有时候就不是框架能解决的。比如淘宝网专门为billion数量级的
: 图片存储和查询优化做了类似云端的底层分级存储系统，腾讯网把通信层也做了像
: Citrix之类
: 的改变。
尤其是stateful的，用完了到了pool里，要再用还挺麻烦的.而且一个java bean就是一
个大package,真的非常占内存，也没必要。所以有人说，尽量用stateless的beans.如
果春运卖票系统要用sateful的，那不把系统搞瘫痪不可，嘿嘿。
【在 W*******e 的大作中提到】
: 我看到有struts的痕迹。国内比较流行的是SSH框架。但整个网站有几种风格，应该是
: 不同公司做不同的模块。
: 数据量大到一定程度有时候就不是框架能解决的。比如淘宝网专门为billion数量级的
: 图片存储和查询优化做了类似云端的底层分级存储系统，腾讯网把通信层也做了像
: Citrix之类
: 的改变。
S*e
45 楼
This is indeed a very hard problem -- we (a big Telcom) have had troubles
for each IPhone release ( I guess it is in fact much, much smaller than 春运
卖票系统)
for each IPhone release ( I guess it is in fact much, much smaller than 春运
卖票系统)
a*i
46 楼
感觉你们group太挫了
tech leader应该被开掉
【在 S*******e 的大作中提到】
: This is indeed a very hard problem -- we (a big Telcom) have had troubles
: for each IPhone release ( I guess it is in fact much, much smaller than 春运
: 卖票系统)
tech leader应该被开掉
【在 S*******e 的大作中提到】
: This is indeed a very hard problem -- we (a big Telcom) have had troubles
: for each IPhone release ( I guess it is in fact much, much smaller than 春运
: 卖票系统)
a*9
47 楼
有时候，车次会临时加挂车厢的
【在 c*********e 的大作中提到】
: 它们用的啥framework,用的java? 这玩艺其实很简单啊，每个车次，每个车里面的座位
: 都是固定的，唯一的难度就是可能有大量顾客同時网上买票，这样造成数据库交易瓶颈
: ，这个就是在西方国家也不好搞吧。中国人多，没办法。
【在 c*********e 的大作中提到】
: 它们用的啥framework,用的java? 这玩艺其实很简单啊，每个车次，每个车里面的座位
: 都是固定的，唯一的难度就是可能有大量顾客同時网上买票，这样造成数据库交易瓶颈
: ，这个就是在西方国家也不好搞吧。中国人多，没办法。
c*e
48 楼
这就是制度问题了。在美國，飞机空几个座位，也会开的。
【在 a****9 的大作中提到】
: 有时候，车次会临时加挂车厢的
【在 a****9 的大作中提到】
: 有时候，车次会临时加挂车厢的
s*0
49 楼
然。就这么定了…
【在 a****i 的大作中提到】
: 感觉你们group太挫了
: tech leader应该被开掉
【在 a****i 的大作中提到】
: 感觉你们group太挫了
: tech leader应该被开掉
c*l
50 楼
Stupid, this is not a technical problem.
B*i
51 楼
抽签有什么不好的吗？
【在 N*****m 的大作中提到】
: 肯定overbook，你这种方法其实就是抽签么
【在 N*****m 的大作中提到】
: 肯定overbook，你这种方法其实就是抽签么
z*e
52 楼
用的是struts+spring+hibernate
全套open source
然后几乎没有任何的优化措施
最直接导致挂掉的原因就是html和css分开存放
而且每一次request都需要重新访问css
瞬间导致访问量加倍
就很华丽地挂了
至于数据库什么，到不了那么深
他们在web就已经挂了
【在 c*********e 的大作中提到】
: 它们用的啥framework,用的java? 这玩艺其实很简单啊，每个车次，每个车里面的座位
: 都是固定的，唯一的难度就是可能有大量顾客同時网上买票，这样造成数据库交易瓶颈
: ，这个就是在西方国家也不好搞吧。中国人多，没办法。
全套open source
然后几乎没有任何的优化措施
最直接导致挂掉的原因就是html和css分开存放
而且每一次request都需要重新访问css
瞬间导致访问量加倍
就很华丽地挂了
至于数据库什么，到不了那么深
他们在web就已经挂了
【在 c*********e 的大作中提到】
: 它们用的啥framework,用的java? 这玩艺其实很简单啊，每个车次，每个车里面的座位
: 都是固定的，唯一的难度就是可能有大量顾客同時网上买票，这样造成数据库交易瓶颈
: ，这个就是在西方国家也不好搞吧。中国人多，没办法。
d*x
53 楼
不过车次座位也不是固定的
因为一个车上的座位可以分段卖
当然他们挂确实不是因为这个复杂度。。。
座位
瓶颈
【在 z****e 的大作中提到】
: 用的是struts+spring+hibernate
: 全套open source
: 然后几乎没有任何的优化措施
: 最直接导致挂掉的原因就是html和css分开存放
: 而且每一次request都需要重新访问css
: 瞬间导致访问量加倍
: 就很华丽地挂了
: 至于数据库什么，到不了那么深
: 他们在web就已经挂了
因为一个车上的座位可以分段卖
当然他们挂确实不是因为这个复杂度。。。
座位
瓶颈
【在 z****e 的大作中提到】
: 用的是struts+spring+hibernate
: 全套open source
: 然后几乎没有任何的优化措施
: 最直接导致挂掉的原因就是html和css分开存放
: 而且每一次request都需要重新访问css
: 瞬间导致访问量加倍
: 就很华丽地挂了
: 至于数据库什么，到不了那么深
: 他们在web就已经挂了
z*e
54 楼
这远不仅仅是复杂度的问题
是operation research的经典问题
但凡是涉及到物流库存，分段售票，联程票这些
都是operation research运筹学研究的经典问题
很多运筹学教材的封面就是一辆拉着货物的火车
只要运筹学能够给出具体的票务方案
分库就一定能搞定，分库一搞定，其他的就更容易了
j2ee就是专门干这个的
【在 d**********x 的大作中提到】
: 不过车次座位也不是固定的
: 因为一个车上的座位可以分段卖
: 当然他们挂确实不是因为这个复杂度。。。
:
: 座位
: 瓶颈
是operation research的经典问题
但凡是涉及到物流库存，分段售票，联程票这些
都是operation research运筹学研究的经典问题
很多运筹学教材的封面就是一辆拉着货物的火车
只要运筹学能够给出具体的票务方案
分库就一定能搞定，分库一搞定，其他的就更容易了
j2ee就是专门干这个的
【在 d**********x 的大作中提到】
: 不过车次座位也不是固定的
: 因为一个车上的座位可以分段卖
: 当然他们挂确实不是因为这个复杂度。。。
:
: 座位
: 瓶颈
H*d
55 楼
对，这也是一个特殊之处，火车可以从中途上车下车。
【在 d**********x 的大作中提到】
: 不过车次座位也不是固定的
: 因为一个车上的座位可以分段卖
: 当然他们挂确实不是因为这个复杂度。。。
:
: 座位
: 瓶颈
【在 d**********x 的大作中提到】
: 不过车次座位也不是固定的
: 因为一个车上的座位可以分段卖
: 当然他们挂确实不是因为这个复杂度。。。
:
: 座位
: 瓶颈
H*d
56 楼
好像服务器用的是Jboss，也是开源免费的。
【在 z****e 的大作中提到】
: 用的是struts+spring+hibernate
: 全套open source
: 然后几乎没有任何的优化措施
: 最直接导致挂掉的原因就是html和css分开存放
: 而且每一次request都需要重新访问css
: 瞬间导致访问量加倍
: 就很华丽地挂了
: 至于数据库什么，到不了那么深
: 他们在web就已经挂了
【在 z****e 的大作中提到】
: 用的是struts+spring+hibernate
: 全套open source
: 然后几乎没有任何的优化措施
: 最直接导致挂掉的原因就是html和css分开存放
: 而且每一次request都需要重新访问css
: 瞬间导致访问量加倍
: 就很华丽地挂了
: 至于数据库什么，到不了那么深
: 他们在web就已经挂了
c*e
57 楼
是个公司就想节约成本阿。可能这是asp.net红火不起来的原因。
【在 H*******d 的大作中提到】
: 好像服务器用的是Jboss，也是开源免费的。
【在 H*******d 的大作中提到】
: 好像服务器用的是Jboss，也是开源免费的。
d*x
58 楼
为啥不是拉着一堆人的车？
货物你可以选择自己合适的路线，人就要这一段的票，能一样吗？难不成人家想要某次
直达你给人家三次转车？乘客能和土豆一样运吗？物流，你能运筹，订票是顾客定死的
，你拿什么运？我这里说的复杂度不是分配算法上的复杂度，而是在顾客定了分段票之
后的同步、更新数据库问题。
这可能是个大问题也可能不是，我没有12306的统计数据。但是对于国营企业的开发，
肯定是个没法解决的问题
【在 z****e 的大作中提到】
: 这远不仅仅是复杂度的问题
: 是operation research的经典问题
: 但凡是涉及到物流库存，分段售票，联程票这些
: 都是operation research运筹学研究的经典问题
: 很多运筹学教材的封面就是一辆拉着货物的火车
: 只要运筹学能够给出具体的票务方案
: 分库就一定能搞定，分库一搞定，其他的就更容易了
: j2ee就是专门干这个的
货物你可以选择自己合适的路线，人就要这一段的票，能一样吗？难不成人家想要某次
直达你给人家三次转车？乘客能和土豆一样运吗？物流，你能运筹，订票是顾客定死的
，你拿什么运？我这里说的复杂度不是分配算法上的复杂度，而是在顾客定了分段票之
后的同步、更新数据库问题。
这可能是个大问题也可能不是，我没有12306的统计数据。但是对于国营企业的开发，
肯定是个没法解决的问题
【在 z****e 的大作中提到】
: 这远不仅仅是复杂度的问题
: 是operation research的经典问题
: 但凡是涉及到物流库存，分段售票，联程票这些
: 都是operation research运筹学研究的经典问题
: 很多运筹学教材的封面就是一辆拉着货物的火车
: 只要运筹学能够给出具体的票务方案
: 分库就一定能搞定，分库一搞定，其他的就更容易了
: j2ee就是专门干这个的
t*g
59 楼
中标的公司不是说才成立的么
估计就是太子党或者关系户临时建立的，然后中这个大标，随便找个小公司花上百分之
一的中标费用开发一个烂系统
【在 a9 的大作中提到】
: 恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
: 只不过中标方技术太差又不舍得投钱罢了。
估计就是太子党或者关系户临时建立的，然后中这个大标，随便找个小公司花上百分之
一的中标费用开发一个烂系统
【在 a9 的大作中提到】
: 恐怕没有比火车票系统更容易的分库了。车次坐位基本是固定的。
: 只不过中标方技术太差又不舍得投钱罢了。
g*g
60 楼
这些都不是原因。所谓的web 2.0公司大部分用的开源服务器。apache和tomcat用得最
多。
挂掉通常不过俩原因，性能测试不充分，架构没写好不好改。
【在 H*******d 的大作中提到】
: 好像服务器用的是Jboss，也是开源免费的。
多。
挂掉通常不过俩原因，性能测试不充分，架构没写好不好改。
【在 H*******d 的大作中提到】
: 好像服务器用的是Jboss，也是开源免费的。
j*i
61 楼
狗屁。我原来差几点就去花街做3tier。幸好没去。
我现在做的比那个东西更有意义。
订票的做的东西要比花街差远了。而且，没头脑。
我现在做的比那个东西更有意义。
订票的做的东西要比花街差远了。而且，没头脑。
z*e
62 楼
不一样
所以这是更高级的运筹学的问题
你知道什么是运筹学吗？
【在 d**********x 的大作中提到】
: 为啥不是拉着一堆人的车？
: 货物你可以选择自己合适的路线，人就要这一段的票，能一样吗？难不成人家想要某次
: 直达你给人家三次转车？乘客能和土豆一样运吗？物流，你能运筹，订票是顾客定死的
: ，你拿什么运？我这里说的复杂度不是分配算法上的复杂度，而是在顾客定了分段票之
: 后的同步、更新数据库问题。
: 这可能是个大问题也可能不是，我没有12306的统计数据。但是对于国营企业的开发，
: 肯定是个没法解决的问题
所以这是更高级的运筹学的问题
你知道什么是运筹学吗？
【在 d**********x 的大作中提到】
: 为啥不是拉着一堆人的车？
: 货物你可以选择自己合适的路线，人就要这一段的票，能一样吗？难不成人家想要某次
: 直达你给人家三次转车？乘客能和土豆一样运吗？物流，你能运筹，订票是顾客定死的
: ，你拿什么运？我这里说的复杂度不是分配算法上的复杂度，而是在顾客定了分段票之
: 后的同步、更新数据库问题。
: 这可能是个大问题也可能不是，我没有12306的统计数据。但是对于国营企业的开发，
: 肯定是个没法解决的问题
z*e
63 楼
如果用的是spring，那么用jboss和tomcat没有区别
jboss用的web server也是tomcat
而且还比较麻烦，额外消耗了跑ejb container的资源
还不如用tomcat
【在 H*******d 的大作中提到】
: 好像服务器用的是Jboss，也是开源免费的。
jboss用的web server也是tomcat
而且还比较麻烦，额外消耗了跑ejb container的资源
还不如用tomcat
【在 H*******d 的大作中提到】
: 好像服务器用的是Jboss，也是开源免费的。
z*e
64 楼
我觉得主要问题是项目匆忙上马，领导拍脑袋说，要网络售票
然后就开始搞了，这种项目能不挂才见鬼
如果从淡季开始就开始搞网络售票，很多问题都可以提前暴露
也有充分时间予以解决，指望短短一个月内就搞出这么大一个系统是不现实的
经验很重要，很多问题没有遇到过想都想不到
而且这里面还涉及到钱的交易，这是最麻烦的一块
量大＋钱，两个要求，大多数系统搞定其中一个都折腾好多年，更何况是两个一起上
【在 g*****g 的大作中提到】
: 这些都不是原因。所谓的web 2.0公司大部分用的开源服务器。apache和tomcat用得最
: 多。
: 挂掉通常不过俩原因，性能测试不充分，架构没写好不好改。
然后就开始搞了，这种项目能不挂才见鬼
如果从淡季开始就开始搞网络售票，很多问题都可以提前暴露
也有充分时间予以解决，指望短短一个月内就搞出这么大一个系统是不现实的
经验很重要，很多问题没有遇到过想都想不到
而且这里面还涉及到钱的交易，这是最麻烦的一块
量大＋钱，两个要求，大多数系统搞定其中一个都折腾好多年，更何况是两个一起上
【在 g*****g 的大作中提到】
: 这些都不是原因。所谓的web 2.0公司大部分用的开源服务器。apache和tomcat用得最
: 多。
: 挂掉通常不过俩原因，性能测试不充分，架构没写好不好改。
H*d
65 楼
这两天又看到一些所谓的内幕消息。
原来招标的时候，好像IBM投过，但一看价格，那简直是离谱，投标价格和交付价格不
一样不说，而且还有每年的维护费用也高的厉害。这东西另外还涉及到国家运输战略层
面的东西，自己人放心，于是铁道部决定自己搞，花钱啥的肯定比IBM少，而且至少肉
烂在锅里。
另外说实话，现在世界上正在运行的各种类似的系统，还没有一个在规模上能比上这个
的。
原来招标的时候，好像IBM投过，但一看价格，那简直是离谱，投标价格和交付价格不
一样不说，而且还有每年的维护费用也高的厉害。这东西另外还涉及到国家运输战略层
面的东西，自己人放心，于是铁道部决定自己搞，花钱啥的肯定比IBM少，而且至少肉
烂在锅里。
另外说实话，现在世界上正在运行的各种类似的系统，还没有一个在规模上能比上这个
的。
c*e
66 楼
恩，其实就是官僚和资本有机结合的一个小案例。
【在 z****e 的大作中提到】
: 我觉得主要问题是项目匆忙上马，领导拍脑袋说，要网络售票
: 然后就开始搞了，这种项目能不挂才见鬼
: 如果从淡季开始就开始搞网络售票，很多问题都可以提前暴露
: 也有充分时间予以解决，指望短短一个月内就搞出这么大一个系统是不现实的
: 经验很重要，很多问题没有遇到过想都想不到
: 而且这里面还涉及到钱的交易，这是最麻烦的一块
: 量大＋钱，两个要求，大多数系统搞定其中一个都折腾好多年，更何况是两个一起上
【在 z****e 的大作中提到】
: 我觉得主要问题是项目匆忙上马，领导拍脑袋说，要网络售票
: 然后就开始搞了，这种项目能不挂才见鬼
: 如果从淡季开始就开始搞网络售票，很多问题都可以提前暴露
: 也有充分时间予以解决，指望短短一个月内就搞出这么大一个系统是不现实的
: 经验很重要，很多问题没有遇到过想都想不到
: 而且这里面还涉及到钱的交易，这是最麻烦的一块
: 量大＋钱，两个要求，大多数系统搞定其中一个都折腾好多年，更何况是两个一起上
x*u
67 楼
飞机哪有硬座车运力强？
【在 z****e 的大作中提到】
: 是一个数量级的
: 民航一般是几个国家的所有航空公司出资建一个系统
: 所以这个星球上其实所有的机票资源都来自那么屈指可数的几个系统，n<10
: 另外，这几个系统实现的语言截然不同
: 北美是java写的，欧洲是c++写的，还有一些古老的是用fortran写的
: 而且机器也不一样，大部分都是特制的主机
: 大部分来自ibm，所以当铁道部竞标的时候
: 只有ibm有成熟的方案，成了铁道部除了他自己搞以外唯一的选择
: 但是要在一夜之前实现民航几十年的成果，那所需要的成本是十分巨大的
: 铁道部权衡了之后，很伟大地决定自己搞，理由是ibm的解决方案太贵
【在 z****e 的大作中提到】
: 是一个数量级的
: 民航一般是几个国家的所有航空公司出资建一个系统
: 所以这个星球上其实所有的机票资源都来自那么屈指可数的几个系统，n<10
: 另外，这几个系统实现的语言截然不同
: 北美是java写的，欧洲是c++写的，还有一些古老的是用fortran写的
: 而且机器也不一样，大部分都是特制的主机
: 大部分来自ibm，所以当铁道部竞标的时候
: 只有ibm有成熟的方案，成了铁道部除了他自己搞以外唯一的选择
: 但是要在一夜之前实现民航几十年的成果，那所需要的成本是十分巨大的
: 铁道部权衡了之后，很伟大地决定自己搞，理由是ibm的解决方案太贵
i*c
68 楼
IBM一样挂。当年著名案例就是xx电信的一套系统，IBM的销售牛B轰轰的号称自家系统
最合适，电信不缺钱，就给他们宰。
上线一个月，瘫痪10几次。
【在 H*******d 的大作中提到】
: 这两天又看到一些所谓的内幕消息。
: 原来招标的时候，好像IBM投过，但一看价格，那简直是离谱，投标价格和交付价格不
: 一样不说，而且还有每年的维护费用也高的厉害。这东西另外还涉及到国家运输战略层
: 面的东西，自己人放心，于是铁道部决定自己搞，花钱啥的肯定比IBM少，而且至少肉
: 烂在锅里。
: 另外说实话，现在世界上正在运行的各种类似的系统，还没有一个在规模上能比上这个
: 的。
最合适，电信不缺钱，就给他们宰。
上线一个月，瘫痪10几次。
【在 H*******d 的大作中提到】
: 这两天又看到一些所谓的内幕消息。
: 原来招标的时候，好像IBM投过，但一看价格，那简直是离谱，投标价格和交付价格不
: 一样不说，而且还有每年的维护费用也高的厉害。这东西另外还涉及到国家运输战略层
: 面的东西，自己人放心，于是铁道部决定自己搞，花钱啥的肯定比IBM少，而且至少肉
: 烂在锅里。
: 另外说实话，现在世界上正在运行的各种类似的系统，还没有一个在规模上能比上这个
: 的。
S*g
69 楼
欧洲火车票不热门啊
有热门东西的是，amazon也好，apple也好照样被秒杀，服务器被搞死
【在 m********5 的大作中提到】
: 全市鬼扯分析, 机票订票系统多少年了,20年了快!
: 就找一套一模一样的系统实施下来也不是这破样 (机票是全世界联网)
: 欧洲火车还不同公司联网,也没出过岔子
有热门东西的是，amazon也好，apple也好照样被秒杀，服务器被搞死
【在 m********5 的大作中提到】
: 全市鬼扯分析, 机票订票系统多少年了,20年了快!
: 就找一套一模一样的系统实施下来也不是这破样 (机票是全世界联网)
: 欧洲火车还不同公司联网,也没出过岔子
u*a
70 楼
临时多配置几个VM.
【在 m***x 的大作中提到】
: 最大的问题是峰值太大,这是中国特色,把其他的系统拿来,也顶不住
【在 m***x 的大作中提到】
: 最大的问题是峰值太大,这是中国特色,把其他的系统拿来,也顶不住
h*3
71 楼
呵呵，是左耳朵耗子兄写的。
【在 H*******d 的大作中提到】
: 这两天又看到一些所谓的内幕消息。
: 原来招标的时候，好像IBM投过，但一看价格，那简直是离谱，投标价格和交付价格不
: 一样不说，而且还有每年的维护费用也高的厉害。这东西另外还涉及到国家运输战略层
: 面的东西，自己人放心，于是铁道部决定自己搞，花钱啥的肯定比IBM少，而且至少肉
: 烂在锅里。
: 另外说实话，现在世界上正在运行的各种类似的系统，还没有一个在规模上能比上这个
: 的。
【在 H*******d 的大作中提到】
: 这两天又看到一些所谓的内幕消息。
: 原来招标的时候，好像IBM投过，但一看价格，那简直是离谱，投标价格和交付价格不
: 一样不说，而且还有每年的维护费用也高的厉害。这东西另外还涉及到国家运输战略层
: 面的东西，自己人放心，于是铁道部决定自己搞，花钱啥的肯定比IBM少，而且至少肉
: 烂在锅里。
: 另外说实话，现在世界上正在运行的各种类似的系统，还没有一个在规模上能比上这个
: 的。
h*3
72 楼
赞同！大型并发系统，最后瓶颈就是数据库。关键在于减少写锁的粒度。
应该考虑怎么用数据库。
1)使用内存数据库。拿几百万来买几百个G的内存条和UPS。
2)按列车班次划分数据库。每个数据库只放几个车的班次。而查询某个车班次所在的数
据库的meta数据库，是只读的，同时可以做镜像数据库，比较容易。
3)车座位的数据表，每个座位的数据记录预先写进去，身份证号预先设置为NULL。这样
每次买票的时候，只用update相应row的一个field，而不执行表的insert。这样就不用
锁整个表，而只锁这个row的，锁的粒度小很多了。
【在 g*****g 的大作中提到】
: 最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
: ，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
: ，批量进行。
: 服务器大部分时间闲置的问题，最合适的就是cloud了。
应该考虑怎么用数据库。
1)使用内存数据库。拿几百万来买几百个G的内存条和UPS。
2)按列车班次划分数据库。每个数据库只放几个车的班次。而查询某个车班次所在的数
据库的meta数据库，是只读的，同时可以做镜像数据库，比较容易。
3)车座位的数据表，每个座位的数据记录预先写进去，身份证号预先设置为NULL。这样
每次买票的时候，只用update相应row的一个field，而不执行表的insert。这样就不用
锁整个表，而只锁这个row的，锁的粒度小很多了。
【在 g*****g 的大作中提到】
: 最核心的地方，就是数据库瓶颈。解决的方案就是sharding。按车次划分数据库服务器
: ，仅此一项就可以让瓶颈减少几十到几百倍，上点好的机器就够了。还不行，缓冲交易
: ，批量进行。
: 服务器大部分时间闲置的问题，最合适的就是cloud了。
c*e
73 楼
en,现在内存数据库是个热门。有搞这方面的老兄说说，服务器突然crash了，内存数据
库怎么保存数据？
【在 h********3 的大作中提到】
: 赞同！大型并发系统，最后瓶颈就是数据库。关键在于减少写锁的粒度。
: 应该考虑怎么用数据库。
: 1)使用内存数据库。拿几百万来买几百个G的内存条和UPS。
: 2)按列车班次划分数据库。每个数据库只放几个车的班次。而查询某个车班次所在的数
: 据库的meta数据库，是只读的，同时可以做镜像数据库，比较容易。
: 3)车座位的数据表，每个座位的数据记录预先写进去，身份证号预先设置为NULL。这样
: 每次买票的时候，只用update相应row的一个field，而不执行表的insert。这样就不用
: 锁整个表，而只锁这个row的，锁的粒度小很多了。
库怎么保存数据？
【在 h********3 的大作中提到】
: 赞同！大型并发系统，最后瓶颈就是数据库。关键在于减少写锁的粒度。
: 应该考虑怎么用数据库。
: 1)使用内存数据库。拿几百万来买几百个G的内存条和UPS。
: 2)按列车班次划分数据库。每个数据库只放几个车的班次。而查询某个车班次所在的数
: 据库的meta数据库，是只读的，同时可以做镜像数据库，比较容易。
: 3)车座位的数据表，每个座位的数据记录预先写进去，身份证号预先设置为NULL。这样
: 每次买票的时候，只用update相应row的一个field，而不执行表的insert。这样就不用
: 锁整个表，而只锁这个row的，锁的粒度小很多了。
h*3
74 楼
不知道。。。买几个UPS至少保证不被断电。
【在 c*********e 的大作中提到】
: en,现在内存数据库是个热门。有搞这方面的老兄说说，服务器突然crash了，内存数据
: 库怎么保存数据？
【在 c*********e 的大作中提到】
: en,现在内存数据库是个热门。有搞这方面的老兄说说，服务器突然crash了，内存数据
: 库怎么保存数据？
c*e
75 楼
断电都是小事，如果server是别的原因crash了，那内存数据库里的数据怎么备份呢？
oracle的数据库，在内存的buffer cache 每15分钟写入硬盘一次;buffer log每3秒写
入硬盘一
次。
【在 h********3 的大作中提到】
: 不知道。。。买几个UPS至少保证不被断电。
oracle的数据库，在内存的buffer cache 每15分钟写入硬盘一次;buffer log每3秒写
入硬盘一
次。
【在 h********3 的大作中提到】
: 不知道。。。买几个UPS至少保证不被断电。
d*8
76 楼
是这样的，原有的售票系统是PB（全国联网售票），写的。所有的业务逻辑，写在存储
过程里面。现在的web售票，有个通道连过去。通道是瓶颈。无法弄。Web死了。PB的还
能跑。领导想死的快就改PB的系统。
过程里面。现在的web售票，有个通道连过去。通道是瓶颈。无法弄。Web死了。PB的还
能跑。领导想死的快就改PB的系统。
c*e
77 楼
用的stored procedure？ 那应该很方便啊。
【在 d****8 的大作中提到】
: 是这样的，原有的售票系统是PB（全国联网售票），写的。所有的业务逻辑，写在存储
: 过程里面。现在的web售票，有个通道连过去。通道是瓶颈。无法弄。Web死了。PB的还
: 能跑。领导想死的快就改PB的系统。
【在 d****8 的大作中提到】
: 是这样的，原有的售票系统是PB（全国联网售票），写的。所有的业务逻辑，写在存储
: 过程里面。现在的web售票，有个通道连过去。通道是瓶颈。无法弄。Web死了。PB的还
: 能跑。领导想死的快就改PB的系统。
d*8
78 楼
通道是瓶颈，压力太大。PB搞死了，全国车站无法买票了。政治事故。WEB无法直接访
问核心售票系统的数据库。系统间，有隔离。PB是铁科院，计算所搞得。快10年了。PB
的系统的
机器去年IBM升级成最高配置的小机了。不改PB系统，WEB买票无解。PB这样的24×7系
统的升级，除了原来的作者，估计谁也无法搞。Code估计改了很多，10多年文档不全。
谁都不好弄。
问核心售票系统的数据库。系统间，有隔离。PB是铁科院，计算所搞得。快10年了。PB
的系统的
机器去年IBM升级成最高配置的小机了。不改PB系统，WEB买票无解。PB这样的24×7系
统的升级，除了原来的作者，估计谁也无法搞。Code估计改了很多，10多年文档不全。
谁都不好弄。
c*e
79 楼
没必要每个买车票的网上交易都去一趟数据库啊。就象超市卖东西一样，没必要把仓库
的所有货物都拿出来堆在货架上。但是也不能每种货物只拿一件商品出来到货架上。
每个车次，每次从数据库里预先包下5００张票，等卖完了再包下另外5００张。
PB
【在 d****8 的大作中提到】
: 通道是瓶颈，压力太大。PB搞死了，全国车站无法买票了。政治事故。WEB无法直接访
: 问核心售票系统的数据库。系统间，有隔离。PB是铁科院，计算所搞得。快10年了。PB
: 的系统的
: 机器去年IBM升级成最高配置的小机了。不改PB系统，WEB买票无解。PB这样的24×7系
: 统的升级，除了原来的作者，估计谁也无法搞。Code估计改了很多，10多年文档不全。
: 谁都不好弄。
的所有货物都拿出来堆在货架上。但是也不能每种货物只拿一件商品出来到货架上。
每个车次，每次从数据库里预先包下5００张票，等卖完了再包下另外5００张。
PB
【在 d****8 的大作中提到】
: 通道是瓶颈，压力太大。PB搞死了，全国车站无法买票了。政治事故。WEB无法直接访
: 问核心售票系统的数据库。系统间，有隔离。PB是铁科院，计算所搞得。快10年了。PB
: 的系统的
: 机器去年IBM升级成最高配置的小机了。不改PB系统，WEB买票无解。PB这样的24×7系
: 统的升级，除了原来的作者，估计谁也无法搞。Code估计改了很多，10多年文档不全。
: 谁都不好弄。
c*e
80 楼
第3个，insert一个row的数据的时候，只有这个row是被lock的，其他的row还是可以进
行dml的。
【在 h********3 的大作中提到】
: 赞同！大型并发系统，最后瓶颈就是数据库。关键在于减少写锁的粒度。
: 应该考虑怎么用数据库。
: 1)使用内存数据库。拿几百万来买几百个G的内存条和UPS。
: 2)按列车班次划分数据库。每个数据库只放几个车的班次。而查询某个车班次所在的数
: 据库的meta数据库，是只读的，同时可以做镜像数据库，比较容易。
: 3)车座位的数据表，每个座位的数据记录预先写进去，身份证号预先设置为NULL。这样
: 每次买票的时候，只用update相应row的一个field，而不执行表的insert。这样就不用
: 锁整个表，而只锁这个row的，锁的粒度小很多了。
行dml的。
【在 h********3 的大作中提到】
: 赞同！大型并发系统，最后瓶颈就是数据库。关键在于减少写锁的粒度。
: 应该考虑怎么用数据库。
: 1)使用内存数据库。拿几百万来买几百个G的内存条和UPS。
: 2)按列车班次划分数据库。每个数据库只放几个车的班次。而查询某个车班次所在的数
: 据库的meta数据库，是只读的，同时可以做镜像数据库，比较容易。
: 3)车座位的数据表，每个座位的数据记录预先写进去，身份证号预先设置为NULL。这样
: 每次买票的时候，只用update相应row的一个field，而不执行表的insert。这样就不用
: 锁整个表，而只锁这个row的，锁的粒度小很多了。
d*8
81 楼
这个的改PB写的系统。风险太高！
【在 c*********e 的大作中提到】
: 没必要每个买车票的网上交易都去一趟数据库啊。就象超市卖东西一样，没必要把仓库
: 的所有货物都拿出来堆在货架上。但是也不能每种货物只拿一件商品出来到货架上。
: 每个车次，每次从数据库里预先包下5００张票，等卖完了再包下另外5００张。
:
: PB
c*e
82 楼
“杜绝黄牛排队或是号贩子。因为他们可以注册N个帐号来排队，但就是不买。”
这个可以通过设置倒计时 来实现。比如屏幕上出现，如果5分钟內不下单，就自动log
out.根据计算机的ip地址，如果同一个ip地址多次出现超过5分钟不下单，列入黑名单。
【在 H*******d 的大作中提到】
: 这两天又看到一些所谓的内幕消息。
: 原来招标的时候，好像IBM投过，但一看价格，那简直是离谱，投标价格和交付价格不
: 一样不说，而且还有每年的维护费用也高的厉害。这东西另外还涉及到国家运输战略层
: 面的东西，自己人放心，于是铁道部决定自己搞，花钱啥的肯定比IBM少，而且至少肉
: 烂在锅里。
: 另外说实话，现在世界上正在运行的各种类似的系统，还没有一个在规模上能比上这个
: 的。
这个可以通过设置倒计时 来实现。比如屏幕上出现，如果5分钟內不下单，就自动log
out.根据计算机的ip地址，如果同一个ip地址多次出现超过5分钟不下单，列入黑名单。
【在 H*******d 的大作中提到】
: 这两天又看到一些所谓的内幕消息。
: 原来招标的时候，好像IBM投过，但一看价格，那简直是离谱，投标价格和交付价格不
: 一样不说，而且还有每年的维护费用也高的厉害。这东西另外还涉及到国家运输战略层
: 面的东西，自己人放心，于是铁道部决定自己搞，花钱啥的肯定比IBM少，而且至少肉
: 烂在锅里。
: 另外说实话，现在世界上正在运行的各种类似的系统，还没有一个在规模上能比上这个
: 的。
c*e
83 楼
不用改写啊，一次从数据库里提前预定5００张票而已。数据库里只需记录票卖出去没
有，用一个column,data type是boolean,存true, false就行。至于交易细节，客户身
份证等，都可以存在当前电脑的临时数据库里，如果中心数据库要查交易细节，就到临
时数据库来查。
中心数据库关心的是卖出去票没有，至于卖给谁，几点交易的，没那么重要。这些信息
可以等卖票高峰期过了之后，再慢慢从各个临时数据库来收集，其实也没必要。
【在 d****8 的大作中提到】
:
: 这个的改PB写的系统。风险太高！
有，用一个column,data type是boolean,存true, false就行。至于交易细节，客户身
份证等，都可以存在当前电脑的临时数据库里，如果中心数据库要查交易细节，就到临
时数据库来查。
中心数据库关心的是卖出去票没有，至于卖给谁，几点交易的，没那么重要。这些信息
可以等卖票高峰期过了之后，再慢慢从各个临时数据库来收集，其实也没必要。
【在 d****8 的大作中提到】
:
: 这个的改PB写的系统。风险太高！
u*a
84 楼
应该先做个load test,拿到90 percentile的performance benchmark再考虑
performance tuning。
performance tuning。
W*e
85 楼
ORACLE躺中
"12306网站遭遇的危机，连日来引起专业人士的关注。据他们分析，问题出在12306网
站所使用的技术，并非是成熟的解决方案。
12306网站在线售票功能，其实就是个海量事务高速处理系统，这样一个系统，并不能
简单地使用通用方案进行设计，但听说12306网站采用了Oracle通用数据库进行搭建”
，CTO俱乐部成员、互联网产品设计专家胡争辉评价说，“使用通用系统进行设计也不
是不可以，但在面对春运前夕的瞬间海量网络购票需求时，这个系统会变得极为脆弱。
"
"12306网站遭遇的危机，连日来引起专业人士的关注。据他们分析，问题出在12306网
站所使用的技术，并非是成熟的解决方案。
12306网站在线售票功能，其实就是个海量事务高速处理系统，这样一个系统，并不能
简单地使用通用方案进行设计，但听说12306网站采用了Oracle通用数据库进行搭建”
，CTO俱乐部成员、互联网产品设计专家胡争辉评价说，“使用通用系统进行设计也不
是不可以，但在面对春运前夕的瞬间海量网络购票需求时，这个系统会变得极为脆弱。
"
i*o
86 楼
群狼战术。
★ 发自iPhone App: ChineseWeb 7.8
【在 c*********e 的大作中提到】
: en,现在内存数据库是个热门。有搞这方面的老兄说说，服务器突然crash了，内存数据
: 库怎么保存数据？
★ 发自iPhone App: ChineseWeb 7.8
【在 c*********e 的大作中提到】
: en,现在内存数据库是个热门。有搞这方面的老兄说说，服务器突然crash了，内存数据
: 库怎么保存数据？
g*r
87 楼
民航的订座系统主机是Unisys的，离港和货运才是IBM主机。
【在 z****e 的大作中提到】
: 是一个数量级的
: 民航一般是几个国家的所有航空公司出资建一个系统
: 所以这个星球上其实所有的机票资源都来自那么屈指可数的几个系统，n<10
: 另外，这几个系统实现的语言截然不同
: 北美是java写的，欧洲是c++写的，还有一些古老的是用fortran写的
: 而且机器也不一样，大部分都是特制的主机
: 大部分来自ibm，所以当铁道部竞标的时候
: 只有ibm有成熟的方案，成了铁道部除了他自己搞以外唯一的选择
: 但是要在一夜之前实现民航几十年的成果，那所需要的成本是十分巨大的
: 铁道部权衡了之后，很伟大地决定自己搞，理由是ibm的解决方案太贵
【在 z****e 的大作中提到】
: 是一个数量级的
: 民航一般是几个国家的所有航空公司出资建一个系统
: 所以这个星球上其实所有的机票资源都来自那么屈指可数的几个系统，n<10
: 另外，这几个系统实现的语言截然不同
: 北美是java写的，欧洲是c++写的，还有一些古老的是用fortran写的
: 而且机器也不一样，大部分都是特制的主机
: 大部分来自ibm，所以当铁道部竞标的时候
: 只有ibm有成熟的方案，成了铁道部除了他自己搞以外唯一的选择
: 但是要在一夜之前实现民航几十年的成果，那所需要的成本是十分巨大的
: 铁道部权衡了之后，很伟大地决定自己搞，理由是ibm的解决方案太贵
相关阅读