今天刚和选哥讨论这个铁道部新搞的什么网上售票系统，非常之难登陆，昨天我登了一上午才挤上去买了一张票，和在火车站排队有什么区别~，无奈中国人口之多，在哪都要排队，网上也逃厄运，于是我开始抱怨铁道部设计的购票系统，偶然发现网上一篇文章志同道合，于是摘之如下：

一、场景分析

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