对于网上购票系统12306，如果你是架构师，你会怎么办？

画了个图，如下

这个可能是和网银之间的接口问题吧。

扣钱是在网银这里扣除的。银行这里成功支付扣钱之后，扣钱的事务可能就提交了。然后返回消息给铁道部系统，让他显示出票。这个时候票应该还是锁着的。但是如果铁道部系统这里一直灭有收到银行支付的返回信息，超时之后就做回滚操作了。然后是解锁。在这个过程中是否能够让银行的支付扣钱事务也进行回滚，就看银行这边的事务了。说不定是银行这边的问题。╮(╯▽╰)╭

呵呵，我花了2个小时终于买到票了！
痛恨之余我也在考虑如何建立铁路售票系统，以下是我一些分析，见笑了！

一切系统设计从业务出发：

1、铁路售票系统极限压力极大(春节、10.1等期间)，而平时压力并不大。所以我们还是建立廉价且可插拔水平扩展的系统，这样就

不用平时也维系这样庞大的系统；

2、售票业务本身并不是很复杂，主要包括注册、登录、查询车次、查询订单、买票(预订票、确认支付并订票、发邮件短信)；

3、业务量大小依次可能是买票(系列)，查询车次，订单，登录，注册等。但春节期间瞬间访问量是几万甚至10W，所以确保处理这样

的系统，单从技术角度将是比较困难而且费用很高。

4、业务中最重要是买票(系列)业务，所以必须要保证买票中预订、支付、确认的事务性，这样不仅提高软件效率，也提高客户体验

度，否则发生一系列后续不必要的业务压力(退钱、重复购买、重复支付、重复确认，重复查询等等)！




比较理想的方案：有序、有效的排队处理所有业务。
排队系统：--春节时期启用
1、访问买票网站，填写姓名和手机后，提示用户排队，并等待手机通知。将这一信息以手机号码Hash值保存到内存缓存中(Memcache redis等)，有过期限制，不允许重复登陆，可以控制队列长度；
2、但队列处理到当前用户时，给用户手机发送授权码，用户凭此完成登录，买票等一系列操作。
3、当用户完成买票时，退出系统，并且在队列中清除该信息。
4、其实，排队系统也是一个可插拔、水平扩展的系统，能实现负载均衡、failover等功能。
买票系统：--处于一个完全可控的状态
1、由于排队系统，后端的买票系统不会出现超过容量的访问，所以对他的设计是简化了很多，游刃有余！
2、设计可水平扩展的系统，便于在分布式扩展：缓存技术和异步技术(邮件通知等)--具体参见方案二
3、确保买票(系列)业务的事务性，提高效率和客户体验度。

方案二：极致的海量数据处理方案--构建分布式、水平扩展的系统
任何系统都是妥协需求和设计的结果--我们不太可能设计出简单、功能超强、不出错、廉价且能满足任何极限情况的系统。我们要处理的技术问题是：超大访问导致的超大业务处理能力，超大访问导致的数据库处理能力跟不上。我们的技术手段有分布式集群服务、缓存、业务水平分割和异步；
1、分布式集群服务：最简单的的方式就是硬件--F5等设备(当然也可以采用LVS)，由于购票业务相对简单，可以把前台服务功能在一个Application中完成，这样扩展集群服务也相对简单--加大开启新一台服务器，不过还是可以在软件结构上做一定的改进。
2、缓存和水平分割
a、对象--12日内所有火车、时间、站点信息(要处理成数字化)，大致是5000趟火车*12天*2000座位(一列火车)和区间是否已订信息，对于Memcache也应该是不大的。
b、使用--依据站点和时间查询车次和余票情况；买票时先锁定本Memcache，进一步提交给Oracle RAC完成真实买票动作，完成后async同步所有Memcache服务器。
c、水平扩展--开启新一台Memcache，注意需要实现在线变更Memcache集群并通知LoadBalance设备。
3、异步
a、异步Memcache同步。
b、异步的买票成功通知--邮件和短信。
4、Oracle RAC--还是值得使用的，尤其是巨量访问情况下，保持稳定和安全，不过交给DBA吧。

租借淘宝的云服务，订票多的时间正好是淘宝活动和交易比较少的时候。

租借淘宝的云服务，订票多的时间正好是淘宝活动和交易比较少的时候。