2014马年伊始，对12306的批判似乎一夜倒戈，唱起了赞歌，赞扬其为英雄之作，赞其性能力压国内各大网站。各种评论，更是嘎然而止于一个观念，12306再快有什么用，即便是快到1秒钟抢光整车的票，也还是解决不了一票难求的境地，运力在那摆着呢。
是啊，运力在那摆着呢，你能咋办？各位看官莫急，咱有量子技术，听我慢慢道来。
简单来说，就是造一批量子列车，这些列车可以在用一个时刻运行在多条(数千条)线路上，一个列车运载能力可以是原来列车的数千倍，这是利用了量子态叠加原理。
有看官要说了，你就吹吧！ 看官莫急。
上面说的只是普通量子列车，还有商务量子列车，更是神奇，叫量子纠缠列车。你登上量子纠缠列车，关上车门，立即打开，然后下车，外面就是你要到的站了。量子纠缠列车极大限度的解决了线路繁忙的问题，因为它根本不需要线路。不仅省去了昂贵的线路铺设费用，而且让不可能铺设线路的两地之间通车变成了可能，比如地球到月球。是的，我们将来会在月亮之上建立火车站，让太空之旅平民化。各位看官，那还能称为火车站吗，该起个什么名字呢？
有看官要笑了，真能吹，都到月亮上了！
那就先不表量子列车，继续说说12306。采用了量子列车(各位看官勿喷，就让我再说一次吧)，运力大大提升，可以说运力到了无穷的地步，随时发车，随到随走，昼夜不断。想到这，不禁捏了把汗，我们还需要12306吗？坐车变成了如此方便，12306还能为我们做什么？真的到了这一步，估计12306真的是回天乏术了。各位看官说的对，真不能再吹刚才说的不能再说那个啥了，再吹，12306真的就没了。
说的是12306起死回生，要是把她说没了，就太不对了。当然12306本来就没死，还在那里独自或者呢，走自己的路，让别人说去吧。
有看官恍然大悟，干嘛呢干嘛呢，你到底干嘛呢，把我们引来到底干嘛呢？
说到这，就算个引子吧，引各位看官来围观的引子。
我依然说的是12306的性能问题，架构问题。但我不和淘宝比，陶宝不是我开发的，我也不说马云会怎么做，我跟马云也不熟，我只是就是论事，说说我会怎么做。
搜索最近的网帖，说12306用了gemfire技术，使用了8台x86计算机提高了余票查询能力，并提高了余票信息刷新的时间，从一个小时，提高到10分钟。这8台机器，只是提供余票查询功能，而且不是实时的，10分钟才刷新一次。
我有个方案，只用一台预算3万元的服务器，就可以达到每秒数万次的余票查询，并且是实时的，不是定期刷新的，不仅能快速查询，还能快速占票锁票，还能快速数据持久化,当然不含Web处理。
看官又说了，你这还是吹吧?!
俺要郑重回答了，这可没有吹，确实能做到！
如果大家对提高12306的性能依然感兴趣，就给顶一顶吧，您顶的越高，俺越有劲。
今天就到这里，下次继续说。
23 个解决方案
#1
#2
#3
#4
#5
绝逼是德云社的
#6
真心不懂，诚实帮顶
#7
余票查询不是实时的，指的是余票数量是从票务系统定时同步过来的，而不是说你发起一次查询，十分钟再给你结果。
为什么不是实时的，不是12306受不了，而是后台票务系统受不了
为什么不是实时的，不是12306受不了，而是后台票务系统受不了
#8
该回复于2014-05-27 17:13:14被管理员删除
#9
原帖竟然不能修改，只能跟帖了。
第一章 12306性能初探
有的看客对这3万元的机器感兴趣，我先来简单说说配置， 2*E5-2620，64G内存，3*300G SAS 10000rpm，512M或1G缓存的RAID卡，2*千兆网口。两块块硬盘做raid1,另一块做热备。有懂硬件的朋友可以帮忙算算，3万元的预算应该能拿下吧。
有看官要问了，就这么个配置，能把12306装下吗？
估计仅把10亿用户信息装在这个机器里都比较费劲。引子里说过了，这个机器是用来查询、锁定、发布车票用的，12306ng称之为票池，我们也这么称呼它吧。首先要对票池的功能做个定义：
1. 余票查询。输入出发站到达站及时间段(24小时内),查询余票信息。
2. 锁票/占票。输入出发站到达站及车次(含日期),按一定的规则锁定车票。
可指定席位和张数。
3. 释放车票。释放锁定的车票。
4. 放票。需要指定车次，日期，站次，席位等信息。还有售票规则，比如，
长途多少张，中途某段多少张等。
5. 禁止/下架车次。过了某个车次销售时间，需要禁止该车次车票发售。
6. 上面的2，3，4，5功能需要数据持久化。宕机后可恢复。
7. 可靠性。单个低廉价格的机器，很难保证可靠性了。
票池只是处理车票信息，那看看能装下吗。网上有个《春运高峰铁路发送旅客664.4万人次同比增长27.5％》的文章，可以推断，铁路单日的车票数不会超过1000万张，20天的总张数不会超过2亿张，那我们按4亿张车票容量算。每个车票在内存占64字节，需要25.6G内存，加上车次，站次等信息及通信缓存等，50G内存是足够了，留10G给系统。通常锁了票都会买下票，较少的人会放弃车票的。假定4亿张车票产生10亿个锁票释放动作，每个动作产生64个字节(我想应该足够)日志数据，那就是64G,再加上其他的操作日志，100G也是足够了。
看官要问了，64字节内存，你这是要做结构体吗？还有操作日志，你这是怎么个持久化？
是的，自定义结构体，把数据放在内存里，有20个CPU线程，你说这查询速度有多快呢？我也面试过很多学生，问他们哈希值是什么，竟然没有人回答上来，却都对高大上的ssh表示很精通。真感慨“精通”这个词，比人民币贬值还要快啊。很多人喜欢那各种框架来献策，但框架只是解决了你的工作量问题，至于性能，框架能解决，你也能解决，框架解决不了的，还得靠你来解决。从实际出发，静下心来，潜心研究，踏踏实实，按部就班才是解决问题的正道。当然并不是用自定义结构体，性能就得提高，那还是要看算法的，具体的算法以后再讨论。
磁盘的IO性能很难满足现在高事务量需求，看一下这篇文章就知道了，http://elf8848.iteye.com/blog/1731301。摘抄部分内容：
常见硬盘IOPS参考值(数据仅供参考)：
-------------------------------------------
2,5" 10.000 rpm SAS 113 IOPS
2,5" 15.000 rpm SAS 156 IOPS
3,5" 15.000 rpm SAS 146 IOPS
2,5" 5.400 rpm SATA 71 IOPS
3,5" 7.200 rpm SATA 65 IOPS
3,5" 10.000 rpm U320 104 IOPS
3,5" 15.000 rpm U320 141 IOPS
3,5" 10.000 rpm FC 125 IOPS
3,5" 15.000 rpm FC 150 IOPS
3,5" 10.000 rpm FATA 119 IOPS
如果每次IO可以处理一张票，每秒也就是处理100多张票，如果加上查找等其他操作，估计100张票也保证不了。
看官说了，现在12306是每秒能完成500张的订票，看来这个配置要完败了。
莫急，咱们有方案，放心，不是用量子技术。先看一个盗版的段子：
在银行里等了一个半小时，终于到我了，看着4个窗口就开2窗口，气就不打一处来。小二问我办什么业务，我说取钱100块，他竟然瞥了我一眼。小二麻利的办完业务，问我还有什么需要，我还说取钱100块，这下，他瞥了我两眼，我暗想，等会让你瞥我100眼。好景不长，取了还不到1000元，保安就过来了...
把取款分成100次，每次取100元，估计一个下午才能办完，如果直接告诉小二取10000元，很快就会办完业务。化零为整，批量处理，会大大提高处理的速度。虽然磁盘的IOPS很可怜，但是磁盘的顺序读写能力还是很强的，sas企业盘轻松达到100M/s的速度。我们应该尽量的利用磁盘的特长，而尽量回避其短板。持久化时，如果磁盘是完全顺序写，1秒钟能写入100多万张票，1000万张票，10秒钟就写到磁盘里了，强悍。当然这个太极端了，我们也不需要这么高的速度，其实1次IO写入1000个操作日志，加上raid卡的缓存功能，1秒钟处理10000个锁票释放处理，应该很轻松。释放车票，并不需要删除或修改原来的锁票记录，而只是增加一个释放车票的记录，我们就可尽量的保障磁盘是顺序写，也就是说顺序的记录操作日志。宕机后的恢复，就是是根据这个日志再操作内存一边。这里我们有个前提，锁了票通常会买，释放车票的操作不会太多。
有的看官就想了，怎么保证数据的完整性呢，比如说，锁了一张票，没有写入到磁盘，在等待那999张的过程中，突然宕机，那岂不数据不完整了？
其实不是攒1000张票再存盘，而是攒1000个请求后一并处理，处理完后，再给给出应答。如果有了999个请求后，好长时间（比如2分钟）再有新请求，那岂不这999个请求要等好长时间才能得到应答？加上一个定时器就可以解决了，比如20ms，基本上不会影响体验。
有的看官还是不放心，总觉得还有问题。
是的，这种化零为整的批量处理方法的确会带来一系列的问题，限于本章是初探，详细的问题我们以后再说，当然各位看官可以把您的问题跟帖提出来。
再看看网络的承载能力，12306的带宽是1.5G波特每秒，换算成字节，大约是180M字节每秒。经过gzip，一次余票查询的应答字节数是5K左右，请求数据要远少于5K，按应答计算，网络每秒可承载36000个余票查询。有的新闻说是最高1秒达24万个余票查询请求，估计有部分请求延迟应答了，有部分请求直接应答忙，有部分请求干脆就丢掉了。如果票池系统能完成10万级别的余票查询能力，就不会成为系统的瓶颈了。至于锁票请求，网络可以承载请求数会更多，毕竟通信的数据量会很小，但车票的数量有限，不会造成过多的请求，票池每秒处理5000个请求，就能满足需求了。
单从性能上来讲，那3万元的服务器应该有能力担的起票池系统。
谢谢各位看官的捧场，有什么问题也请跟帖。
先到这里，下次继续聊。
第一章 12306性能初探
有的看客对这3万元的机器感兴趣，我先来简单说说配置， 2*E5-2620，64G内存，3*300G SAS 10000rpm，512M或1G缓存的RAID卡，2*千兆网口。两块块硬盘做raid1,另一块做热备。有懂硬件的朋友可以帮忙算算，3万元的预算应该能拿下吧。
有看官要问了，就这么个配置，能把12306装下吗？
估计仅把10亿用户信息装在这个机器里都比较费劲。引子里说过了，这个机器是用来查询、锁定、发布车票用的，12306ng称之为票池，我们也这么称呼它吧。首先要对票池的功能做个定义：
1. 余票查询。输入出发站到达站及时间段(24小时内),查询余票信息。
2. 锁票/占票。输入出发站到达站及车次(含日期),按一定的规则锁定车票。
可指定席位和张数。
3. 释放车票。释放锁定的车票。
4. 放票。需要指定车次，日期，站次，席位等信息。还有售票规则，比如，
长途多少张，中途某段多少张等。
5. 禁止/下架车次。过了某个车次销售时间，需要禁止该车次车票发售。
6. 上面的2，3，4，5功能需要数据持久化。宕机后可恢复。
7. 可靠性。单个低廉价格的机器，很难保证可靠性了。
票池只是处理车票信息，那看看能装下吗。网上有个《春运高峰铁路发送旅客664.4万人次同比增长27.5％》的文章，可以推断，铁路单日的车票数不会超过1000万张，20天的总张数不会超过2亿张，那我们按4亿张车票容量算。每个车票在内存占64字节，需要25.6G内存，加上车次，站次等信息及通信缓存等，50G内存是足够了，留10G给系统。通常锁了票都会买下票，较少的人会放弃车票的。假定4亿张车票产生10亿个锁票释放动作，每个动作产生64个字节(我想应该足够)日志数据，那就是64G,再加上其他的操作日志，100G也是足够了。
看官要问了，64字节内存，你这是要做结构体吗？还有操作日志，你这是怎么个持久化？
是的，自定义结构体，把数据放在内存里，有20个CPU线程，你说这查询速度有多快呢？我也面试过很多学生，问他们哈希值是什么，竟然没有人回答上来，却都对高大上的ssh表示很精通。真感慨“精通”这个词，比人民币贬值还要快啊。很多人喜欢那各种框架来献策，但框架只是解决了你的工作量问题，至于性能，框架能解决，你也能解决，框架解决不了的，还得靠你来解决。从实际出发，静下心来，潜心研究，踏踏实实，按部就班才是解决问题的正道。当然并不是用自定义结构体，性能就得提高，那还是要看算法的，具体的算法以后再讨论。
磁盘的IO性能很难满足现在高事务量需求，看一下这篇文章就知道了，http://elf8848.iteye.com/blog/1731301。摘抄部分内容：
常见硬盘IOPS参考值(数据仅供参考)：
-------------------------------------------
2,5" 10.000 rpm SAS 113 IOPS
2,5" 15.000 rpm SAS 156 IOPS
3,5" 15.000 rpm SAS 146 IOPS
2,5" 5.400 rpm SATA 71 IOPS
3,5" 7.200 rpm SATA 65 IOPS
3,5" 10.000 rpm U320 104 IOPS
3,5" 15.000 rpm U320 141 IOPS
3,5" 10.000 rpm FC 125 IOPS
3,5" 15.000 rpm FC 150 IOPS
3,5" 10.000 rpm FATA 119 IOPS
如果每次IO可以处理一张票，每秒也就是处理100多张票，如果加上查找等其他操作，估计100张票也保证不了。
看官说了，现在12306是每秒能完成500张的订票，看来这个配置要完败了。
莫急，咱们有方案，放心，不是用量子技术。先看一个盗版的段子：
在银行里等了一个半小时，终于到我了，看着4个窗口就开2窗口，气就不打一处来。小二问我办什么业务，我说取钱100块，他竟然瞥了我一眼。小二麻利的办完业务，问我还有什么需要，我还说取钱100块，这下，他瞥了我两眼，我暗想，等会让你瞥我100眼。好景不长，取了还不到1000元，保安就过来了...
把取款分成100次，每次取100元，估计一个下午才能办完，如果直接告诉小二取10000元，很快就会办完业务。化零为整，批量处理，会大大提高处理的速度。虽然磁盘的IOPS很可怜，但是磁盘的顺序读写能力还是很强的，sas企业盘轻松达到100M/s的速度。我们应该尽量的利用磁盘的特长，而尽量回避其短板。持久化时，如果磁盘是完全顺序写，1秒钟能写入100多万张票，1000万张票，10秒钟就写到磁盘里了，强悍。当然这个太极端了，我们也不需要这么高的速度，其实1次IO写入1000个操作日志，加上raid卡的缓存功能，1秒钟处理10000个锁票释放处理，应该很轻松。释放车票，并不需要删除或修改原来的锁票记录，而只是增加一个释放车票的记录，我们就可尽量的保障磁盘是顺序写，也就是说顺序的记录操作日志。宕机后的恢复，就是是根据这个日志再操作内存一边。这里我们有个前提，锁了票通常会买，释放车票的操作不会太多。
有的看官就想了，怎么保证数据的完整性呢，比如说，锁了一张票，没有写入到磁盘，在等待那999张的过程中，突然宕机，那岂不数据不完整了？
其实不是攒1000张票再存盘，而是攒1000个请求后一并处理，处理完后，再给给出应答。如果有了999个请求后，好长时间（比如2分钟）再有新请求，那岂不这999个请求要等好长时间才能得到应答？加上一个定时器就可以解决了，比如20ms，基本上不会影响体验。
有的看官还是不放心，总觉得还有问题。
是的，这种化零为整的批量处理方法的确会带来一系列的问题，限于本章是初探，详细的问题我们以后再说，当然各位看官可以把您的问题跟帖提出来。
再看看网络的承载能力，12306的带宽是1.5G波特每秒，换算成字节，大约是180M字节每秒。经过gzip，一次余票查询的应答字节数是5K左右，请求数据要远少于5K，按应答计算，网络每秒可承载36000个余票查询。有的新闻说是最高1秒达24万个余票查询请求，估计有部分请求延迟应答了，有部分请求直接应答忙，有部分请求干脆就丢掉了。如果票池系统能完成10万级别的余票查询能力，就不会成为系统的瓶颈了。至于锁票请求，网络可以承载请求数会更多，毕竟通信的数据量会很小，但车票的数量有限，不会造成过多的请求，票池每秒处理5000个请求，就能满足需求了。
单从性能上来讲，那3万元的服务器应该有能力担的起票池系统。
谢谢各位看官的捧场，有什么问题也请跟帖。
先到这里，下次继续聊。
#10
看起来后台票务系统和12306是两个独立的系统，12306的范围要小的多了。根据一些帖子的说明，在12306网站出现之前，的确是有个票务系统的存在。可能因为某些原因，这个票务系统没有随着12306的建设进行改进，也可能改进了，我们并不知道。这个后台票务系统对大家来说太陌生了，通常，大家眼里的12306是包含这个票务系统的，我也是这么认为的。把票务系统分开谈12306，的确有许多难度，至少得让大家知道这个票务系统的接口及性能。既然是后台票务承受不了，为什么不改进呢？
另外，我说的非实时，也不是等10分钟给结果，也说的是10分钟内的查询结果都一样，不是实时数据。
最后，谢谢跟帖。
#11
#12
笑而不语
#13
赞其性能力压国内各大网站，直接看成赞其性能力。。。
#14
對那些
北+韓之類的，少支援，或者不支持
則百姓口袋可能不會那麼癟
則不會有那麼多的民工
則，沒有春運了
則百姓口袋可能不會那麼癟
則不會有那麼多的民工
則，沒有春運了
#15
#16
你这是在逗我们吧...
#17
#18
CSDN 每天500 呵呵呵呵呵呵
#19
说别的没有用，把联系方式留下，买不到票的都联系你了
#20
说了这么多，核心就是一条，请求批量化处理！！！
#21
要知道便宜没有好货
#22
好像还有1分
#23
感觉有点像是买彩票,先用户提交,然后服务器到点了决定哪些人中奖
#1
#2
#3
#4
#5
绝逼是德云社的
#6
真心不懂，诚实帮顶
#7
余票查询不是实时的，指的是余票数量是从票务系统定时同步过来的，而不是说你发起一次查询，十分钟再给你结果。
为什么不是实时的，不是12306受不了，而是后台票务系统受不了
为什么不是实时的，不是12306受不了，而是后台票务系统受不了
#8
该回复于2014-05-27 17:13:14被管理员删除
#9
原帖竟然不能修改，只能跟帖了。
第一章 12306性能初探
有的看客对这3万元的机器感兴趣，我先来简单说说配置， 2*E5-2620，64G内存，3*300G SAS 10000rpm，512M或1G缓存的RAID卡，2*千兆网口。两块块硬盘做raid1,另一块做热备。有懂硬件的朋友可以帮忙算算，3万元的预算应该能拿下吧。
有看官要问了，就这么个配置，能把12306装下吗？
估计仅把10亿用户信息装在这个机器里都比较费劲。引子里说过了，这个机器是用来查询、锁定、发布车票用的，12306ng称之为票池，我们也这么称呼它吧。首先要对票池的功能做个定义：
1. 余票查询。输入出发站到达站及时间段(24小时内),查询余票信息。
2. 锁票/占票。输入出发站到达站及车次(含日期),按一定的规则锁定车票。
可指定席位和张数。
3. 释放车票。释放锁定的车票。
4. 放票。需要指定车次，日期，站次，席位等信息。还有售票规则，比如，
长途多少张，中途某段多少张等。
5. 禁止/下架车次。过了某个车次销售时间，需要禁止该车次车票发售。
6. 上面的2，3，4，5功能需要数据持久化。宕机后可恢复。
7. 可靠性。单个低廉价格的机器，很难保证可靠性了。
票池只是处理车票信息，那看看能装下吗。网上有个《春运高峰铁路发送旅客664.4万人次同比增长27.5％》的文章，可以推断，铁路单日的车票数不会超过1000万张，20天的总张数不会超过2亿张，那我们按4亿张车票容量算。每个车票在内存占64字节，需要25.6G内存，加上车次，站次等信息及通信缓存等，50G内存是足够了，留10G给系统。通常锁了票都会买下票，较少的人会放弃车票的。假定4亿张车票产生10亿个锁票释放动作，每个动作产生64个字节(我想应该足够)日志数据，那就是64G,再加上其他的操作日志，100G也是足够了。
看官要问了，64字节内存，你这是要做结构体吗？还有操作日志，你这是怎么个持久化？
是的，自定义结构体，把数据放在内存里，有20个CPU线程，你说这查询速度有多快呢？我也面试过很多学生，问他们哈希值是什么，竟然没有人回答上来，却都对高大上的ssh表示很精通。真感慨“精通”这个词，比人民币贬值还要快啊。很多人喜欢那各种框架来献策，但框架只是解决了你的工作量问题，至于性能，框架能解决，你也能解决，框架解决不了的，还得靠你来解决。从实际出发，静下心来，潜心研究，踏踏实实，按部就班才是解决问题的正道。当然并不是用自定义结构体，性能就得提高，那还是要看算法的，具体的算法以后再讨论。
磁盘的IO性能很难满足现在高事务量需求，看一下这篇文章就知道了，http://elf8848.iteye.com/blog/1731301。摘抄部分内容：
常见硬盘IOPS参考值(数据仅供参考)：
-------------------------------------------
2,5" 10.000 rpm SAS 113 IOPS
2,5" 15.000 rpm SAS 156 IOPS
3,5" 15.000 rpm SAS 146 IOPS
2,5" 5.400 rpm SATA 71 IOPS
3,5" 7.200 rpm SATA 65 IOPS
3,5" 10.000 rpm U320 104 IOPS
3,5" 15.000 rpm U320 141 IOPS
3,5" 10.000 rpm FC 125 IOPS
3,5" 15.000 rpm FC 150 IOPS
3,5" 10.000 rpm FATA 119 IOPS
如果每次IO可以处理一张票，每秒也就是处理100多张票，如果加上查找等其他操作，估计100张票也保证不了。
看官说了，现在12306是每秒能完成500张的订票，看来这个配置要完败了。
莫急，咱们有方案，放心，不是用量子技术。先看一个盗版的段子：
在银行里等了一个半小时，终于到我了，看着4个窗口就开2窗口，气就不打一处来。小二问我办什么业务，我说取钱100块，他竟然瞥了我一眼。小二麻利的办完业务，问我还有什么需要，我还说取钱100块，这下，他瞥了我两眼，我暗想，等会让你瞥我100眼。好景不长，取了还不到1000元，保安就过来了...
把取款分成100次，每次取100元，估计一个下午才能办完，如果直接告诉小二取10000元，很快就会办完业务。化零为整，批量处理，会大大提高处理的速度。虽然磁盘的IOPS很可怜，但是磁盘的顺序读写能力还是很强的，sas企业盘轻松达到100M/s的速度。我们应该尽量的利用磁盘的特长，而尽量回避其短板。持久化时，如果磁盘是完全顺序写，1秒钟能写入100多万张票，1000万张票，10秒钟就写到磁盘里了，强悍。当然这个太极端了，我们也不需要这么高的速度，其实1次IO写入1000个操作日志，加上raid卡的缓存功能，1秒钟处理10000个锁票释放处理，应该很轻松。释放车票，并不需要删除或修改原来的锁票记录，而只是增加一个释放车票的记录，我们就可尽量的保障磁盘是顺序写，也就是说顺序的记录操作日志。宕机后的恢复，就是是根据这个日志再操作内存一边。这里我们有个前提，锁了票通常会买，释放车票的操作不会太多。
有的看官就想了，怎么保证数据的完整性呢，比如说，锁了一张票，没有写入到磁盘，在等待那999张的过程中，突然宕机，那岂不数据不完整了？
其实不是攒1000张票再存盘，而是攒1000个请求后一并处理，处理完后，再给给出应答。如果有了999个请求后，好长时间（比如2分钟）再有新请求，那岂不这999个请求要等好长时间才能得到应答？加上一个定时器就可以解决了，比如20ms，基本上不会影响体验。
有的看官还是不放心，总觉得还有问题。
是的，这种化零为整的批量处理方法的确会带来一系列的问题，限于本章是初探，详细的问题我们以后再说，当然各位看官可以把您的问题跟帖提出来。
再看看网络的承载能力，12306的带宽是1.5G波特每秒，换算成字节，大约是180M字节每秒。经过gzip，一次余票查询的应答字节数是5K左右，请求数据要远少于5K，按应答计算，网络每秒可承载36000个余票查询。有的新闻说是最高1秒达24万个余票查询请求，估计有部分请求延迟应答了，有部分请求直接应答忙，有部分请求干脆就丢掉了。如果票池系统能完成10万级别的余票查询能力，就不会成为系统的瓶颈了。至于锁票请求，网络可以承载请求数会更多，毕竟通信的数据量会很小，但车票的数量有限，不会造成过多的请求，票池每秒处理5000个请求，就能满足需求了。
单从性能上来讲，那3万元的服务器应该有能力担的起票池系统。
谢谢各位看官的捧场，有什么问题也请跟帖。
先到这里，下次继续聊。
第一章 12306性能初探
有的看客对这3万元的机器感兴趣，我先来简单说说配置， 2*E5-2620，64G内存，3*300G SAS 10000rpm，512M或1G缓存的RAID卡，2*千兆网口。两块块硬盘做raid1,另一块做热备。有懂硬件的朋友可以帮忙算算，3万元的预算应该能拿下吧。
有看官要问了，就这么个配置，能把12306装下吗？
估计仅把10亿用户信息装在这个机器里都比较费劲。引子里说过了，这个机器是用来查询、锁定、发布车票用的，12306ng称之为票池，我们也这么称呼它吧。首先要对票池的功能做个定义：
1. 余票查询。输入出发站到达站及时间段(24小时内),查询余票信息。
2. 锁票/占票。输入出发站到达站及车次(含日期),按一定的规则锁定车票。
可指定席位和张数。
3. 释放车票。释放锁定的车票。
4. 放票。需要指定车次，日期，站次，席位等信息。还有售票规则，比如，
长途多少张，中途某段多少张等。
5. 禁止/下架车次。过了某个车次销售时间，需要禁止该车次车票发售。
6. 上面的2，3，4，5功能需要数据持久化。宕机后可恢复。
7. 可靠性。单个低廉价格的机器，很难保证可靠性了。
票池只是处理车票信息，那看看能装下吗。网上有个《春运高峰铁路发送旅客664.4万人次同比增长27.5％》的文章，可以推断，铁路单日的车票数不会超过1000万张，20天的总张数不会超过2亿张，那我们按4亿张车票容量算。每个车票在内存占64字节，需要25.6G内存，加上车次，站次等信息及通信缓存等，50G内存是足够了，留10G给系统。通常锁了票都会买下票，较少的人会放弃车票的。假定4亿张车票产生10亿个锁票释放动作，每个动作产生64个字节(我想应该足够)日志数据，那就是64G,再加上其他的操作日志，100G也是足够了。
看官要问了，64字节内存，你这是要做结构体吗？还有操作日志，你这是怎么个持久化？
是的，自定义结构体，把数据放在内存里，有20个CPU线程，你说这查询速度有多快呢？我也面试过很多学生，问他们哈希值是什么，竟然没有人回答上来，却都对高大上的ssh表示很精通。真感慨“精通”这个词，比人民币贬值还要快啊。很多人喜欢那各种框架来献策，但框架只是解决了你的工作量问题，至于性能，框架能解决，你也能解决，框架解决不了的，还得靠你来解决。从实际出发，静下心来，潜心研究，踏踏实实，按部就班才是解决问题的正道。当然并不是用自定义结构体，性能就得提高，那还是要看算法的，具体的算法以后再讨论。
磁盘的IO性能很难满足现在高事务量需求，看一下这篇文章就知道了，http://elf8848.iteye.com/blog/1731301。摘抄部分内容：
常见硬盘IOPS参考值(数据仅供参考)：
-------------------------------------------
2,5" 10.000 rpm SAS 113 IOPS
2,5" 15.000 rpm SAS 156 IOPS
3,5" 15.000 rpm SAS 146 IOPS
2,5" 5.400 rpm SATA 71 IOPS
3,5" 7.200 rpm SATA 65 IOPS
3,5" 10.000 rpm U320 104 IOPS
3,5" 15.000 rpm U320 141 IOPS
3,5" 10.000 rpm FC 125 IOPS
3,5" 15.000 rpm FC 150 IOPS
3,5" 10.000 rpm FATA 119 IOPS
如果每次IO可以处理一张票，每秒也就是处理100多张票，如果加上查找等其他操作，估计100张票也保证不了。
看官说了，现在12306是每秒能完成500张的订票，看来这个配置要完败了。
莫急，咱们有方案，放心，不是用量子技术。先看一个盗版的段子：
在银行里等了一个半小时，终于到我了，看着4个窗口就开2窗口，气就不打一处来。小二问我办什么业务，我说取钱100块，他竟然瞥了我一眼。小二麻利的办完业务，问我还有什么需要，我还说取钱100块，这下，他瞥了我两眼，我暗想，等会让你瞥我100眼。好景不长，取了还不到1000元，保安就过来了...
把取款分成100次，每次取100元，估计一个下午才能办完，如果直接告诉小二取10000元，很快就会办完业务。化零为整，批量处理，会大大提高处理的速度。虽然磁盘的IOPS很可怜，但是磁盘的顺序读写能力还是很强的，sas企业盘轻松达到100M/s的速度。我们应该尽量的利用磁盘的特长，而尽量回避其短板。持久化时，如果磁盘是完全顺序写，1秒钟能写入100多万张票，1000万张票，10秒钟就写到磁盘里了，强悍。当然这个太极端了，我们也不需要这么高的速度，其实1次IO写入1000个操作日志，加上raid卡的缓存功能，1秒钟处理10000个锁票释放处理，应该很轻松。释放车票，并不需要删除或修改原来的锁票记录，而只是增加一个释放车票的记录，我们就可尽量的保障磁盘是顺序写，也就是说顺序的记录操作日志。宕机后的恢复，就是是根据这个日志再操作内存一边。这里我们有个前提，锁了票通常会买，释放车票的操作不会太多。
有的看官就想了，怎么保证数据的完整性呢，比如说，锁了一张票，没有写入到磁盘，在等待那999张的过程中，突然宕机，那岂不数据不完整了？
其实不是攒1000张票再存盘，而是攒1000个请求后一并处理，处理完后，再给给出应答。如果有了999个请求后，好长时间（比如2分钟）再有新请求，那岂不这999个请求要等好长时间才能得到应答？加上一个定时器就可以解决了，比如20ms，基本上不会影响体验。
有的看官还是不放心，总觉得还有问题。
是的，这种化零为整的批量处理方法的确会带来一系列的问题，限于本章是初探，详细的问题我们以后再说，当然各位看官可以把您的问题跟帖提出来。
再看看网络的承载能力，12306的带宽是1.5G波特每秒，换算成字节，大约是180M字节每秒。经过gzip，一次余票查询的应答字节数是5K左右，请求数据要远少于5K，按应答计算，网络每秒可承载36000个余票查询。有的新闻说是最高1秒达24万个余票查询请求，估计有部分请求延迟应答了，有部分请求直接应答忙，有部分请求干脆就丢掉了。如果票池系统能完成10万级别的余票查询能力，就不会成为系统的瓶颈了。至于锁票请求，网络可以承载请求数会更多，毕竟通信的数据量会很小，但车票的数量有限，不会造成过多的请求，票池每秒处理5000个请求，就能满足需求了。
单从性能上来讲，那3万元的服务器应该有能力担的起票池系统。
谢谢各位看官的捧场，有什么问题也请跟帖。
先到这里，下次继续聊。
#10
看起来后台票务系统和12306是两个独立的系统，12306的范围要小的多了。根据一些帖子的说明，在12306网站出现之前，的确是有个票务系统的存在。可能因为某些原因，这个票务系统没有随着12306的建设进行改进，也可能改进了，我们并不知道。这个后台票务系统对大家来说太陌生了，通常，大家眼里的12306是包含这个票务系统的，我也是这么认为的。把票务系统分开谈12306，的确有许多难度，至少得让大家知道这个票务系统的接口及性能。既然是后台票务承受不了，为什么不改进呢？
另外，我说的非实时，也不是等10分钟给结果，也说的是10分钟内的查询结果都一样，不是实时数据。
最后，谢谢跟帖。
#11
#12
笑而不语
#13
赞其性能力压国内各大网站，直接看成赞其性能力。。。
#14
對那些
北+韓之類的，少支援，或者不支持
則百姓口袋可能不會那麼癟
則不會有那麼多的民工
則，沒有春運了
則百姓口袋可能不會那麼癟
則不會有那麼多的民工
則，沒有春運了
#15
#16
你这是在逗我们吧...
#17
#18
CSDN 每天500 呵呵呵呵呵呵
#19
说别的没有用，把联系方式留下，买不到票的都联系你了
#20
说了这么多，核心就是一条，请求批量化处理！！！
#21
要知道便宜没有好货
#22
好像还有1分
#23
感觉有点像是买彩票,先用户提交,然后服务器到点了决定哪些人中奖