关于铁道部的那点事

1.对火车购票网的登录页面的分析

http://user.qzone.qq.com/386861941/blog/1326166461

最近很多人经历了比较痛苦的网上购票，有人叹其为2012最慢的网站。为什么会这么慢？我同意很多业内人士的看法，除了管理方面的问题， 网站的设计存在一些重要的问题，
第一是购票流程可能不是很科学，从而增加了系统的复杂性和数据锁定(lock)的几率，使得很多人需要等待后台的响应
 
第二是软件设计存在问题，因为只能看到前端，所以只能谈页面代码。我这里以登陆页面http://www.12306.cn/mormhweb/kyfw/为例，列举存在的一些影响效率的问题。
 
我使用的是windows7/ IE9 /  Fiddler. 机器是新机器。
可以看到， 下载过程大约 7 秒 ，总加载时间大约13秒。 这个页面向服务器提交了53个请求。
 
问题1：向服务器发送的请求次数太多， 这样的一个简单的页面有53个请求，是不科学的。淘宝登录页面有32个请求，QQ登录页面有21个请求。Ebay18个。尽量少的请求次数是高效网页设计的第一定律。
 
问题2: iframeblocking. 这个登录页面使用了iframe,iframe里又嵌套了一个子iframe. 是否应该使用iframe姑且不谈，我们看一个影响下载效率的阻塞(blocking)问题。 一般来说，js 文件的位置如果放置不当等，会阻塞后续的下载.
请大家看附图，有两处很明显的阻塞。第一次iframe阻塞（blocking1），大约阻塞了1.2秒,理论上，如果代码写得好，iframe1的内容应该从大约0秒开始下载。第二次iFrame阻塞大约1秒。同理，如果代码写好了，应该和iframe1同时开始下载
 
问题3：js 阻塞 （图中blocking3）. 从图中看出， calander.js这个文件阻塞了下载进程约3秒。是什么东西在calendar.js里阻塞呢? 打开这个文件吓一跳， 是个eval(). 如下所示。 在javascript中避免使用eval()在业界应该是有一定共识了。 而且，关于日期的一些东西，用了好几个不同的js库文件，是否用了合适的库文件？ 类似的东西在互联网上到处都有，购票网有没有使用相对合适的日期库文件？
eval(function(p,a,c,k,e,d){e=function(c){return(c<a?"":e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--)d[e(c)]=k[c]||e(c);k=[function(e){returnd[e]}];e=function(){return'\\w+'};c=1;};while(c--)if(k[c])p=p.replace(newRegExp('\\b'+e(c)+'\\b','g'),k[c]);return p;}('o$c;k($5u){5Q.2X.7n("6G",l($){k(!$)h.25();t$});5Q.2X.7e("6w",l(){o $=h.6t;3i($.5M!=1)$=$.7g;t$});7f.2X.2I=l($,b){o A=$.1l(/6p/,"");b.5R=l($){6L.1Y=$;tb()};h.7t(A,b.5R,1m)}}。。。
 
问题4. 平行加载。严格说这个不算问题。大家看附图便知，因为我用IE9所以有8个文件可以同时下载，如果用IE6 可能只有2个文件能同时下载， 这意味着下载过程会更长， 占用更多的网络资源。
 
总之，登录页面的问题是不够简单，太多的文件，不合适的iframe设计，不合适的日期库函数，就算不做大的修改，也可以做适当的优化把下载时间降低50%左右。 我想类似的问题应该也发生在其它页面上。如果每个页面的响应时间降低50%,就不会有那么多人卡在网络上，从而释放更多网络资源，形成良性循环。
祝大家新年快乐。

2.火车票订票系统的几点优化思考

http://blog.csdn.net/kongqz/article/details/7186639

一、场景分析
1、平时访问量不高，但是春运几天会出现瞬间高峰
2、订单的事务性要求较高
3、全国开放，并且票数要精准
4、瞬间访问量大


二、调优可行性方案
1、数据层次
使用oracle，在数据稳定性以及千万级别的数据量上还是比较有保障
使用RAC来做数据库集群
将订单按照天来做日期类型的表分区存储数据
做主从库，将非关键性数据查询放到从库上
提取计算规则比较复杂的逻辑放到timesten这类内存数据库上进行处理
根据业务系统拆分数据库，尽量不要将所有业务放到一个库中


2、cache层次
使用memcache之类的分布式cache一些字典表数据，减少数据库的查询次数
做页面的cache缓存
利用memache的原子性来做各个路线的票数增减服务。和数据库的操作做异步处理
预先加载部分热点数据到cache中
3、前端处理
将css以及js和图片使用CDN进行加速，独立域名部署
减少图片加载量，以及图片的大小
减少css和js文件的数量，同一类型尽可能压缩整合到一个文件中。当然那些开源的prototype或者jquery组件就不要整合了。
将验证码调用采用触发方式，可以考虑单独部署验证码校验服务，不要和应用系统本身整合到一起


4、业务层次
按照地区拆分业务系统部署
将订单或者评论等业务拆分。达到录入和查询等业务分离
系统间的业务交互用soa的方式来做通讯，达到松耦合并行处理
如果有跨机房部署，预先分配各个机房业务资源。例如，基于各地买票量调整南北方机房系统的各自总票数
分流人群，将不同的业务调整成为不同时间执行。对于不符合条件的预订和查询，直接转到友好提示页面


5、事务处理
按照业务进行事务处理，尽量不要做成一个大的事务，在业务流程设计上，尽量做到事务精简，逻辑严密。
例如：订票流程和支付流程作为两个业务。或者支付业务拆分成给账户充值+账户扣费两个逻辑


6、部署策略
针对南北机房做互通
各个系统应用集群
各个系统部署在相同网段，并用内网ip做host指向，减少网络压力
跨机房部署考虑预先分配调整资源方式


7、网络层次
控制各个应用系统节点的压力，当部分节点的用户量达到一定限额，将用户跳到友好页


8、防抓取爬虫
防止部分爬虫自动买票。对于单个ip做分析防范。发现后立即封锁ip