也说说12306

看到网上很多关于12306的讨论的文章，大家都提出了自己的看法和改进意见，我也来凑凑热闹，说一下自己的一些想法。

媒体归咎于两个投标公司，但从目前看了他们不是问题的关键点。很多技术大牛将问题集中在采用了通用型数据库，没有数据缓存机制，或者没用采用异步IO等等，这些都很重要，也很有借鉴的意义，但我认为这些都是次要的，性能优化本身的空间在大牛们面前仍旧有很多的优化空间，但是现在来看系统不在于性能而在于可用不可用，至少通过合理的事务在低性能条件下使系统是可用的。

个人认为12306的问题存在于以下几个方面：

一、数据吞吐量大，被单一系统所承载

二、系统本身设计（物理和系统设计）处理能力有限（很多大牛都提到了）

三、用户行为不可控

四、事务本身的互斥性强

这里边大家都提了自己的一些看法，并且都是很成熟的，我看了心里比较痒，我也胡乱的来表述一下自己的一些想法。

一、排队

1、现有的系统拥有一个队列系统，但是这个队列的利用效果并不是很好，产生的效果是不在队列中的用户狂刷，在队列中的用户不能完成个业务及时退出。

2、结合分布式设计，排队也是分布式的，有多个队列，不同分布式服务器有自己的队列，对互斥资源又有自己的队列，即对用户的事务操作进行合理的导引。

3、因为车票对应的资源是唯一的，但是对应票池中的资源却不是唯一的，当订单确认时将资源锁定是完全可行的，将互斥资源的生命周期尽量缩短。

二、分布负载

1、前几天看到铁道部的“云计算”的提法感到很失望，即使采用小型机或者更强大的服务器也避免不了分布式部署，一个专业性的系统对外提这样忽悠人的概念，难道又是在忽悠我们。

2、查询、订票、付款相分离，查询服务并不需要十分精确，现有火车站大屏所提示的信息也是一小时左右的延时，有几分钟左右的差异完全可以接受，这样核心业务将会减少因查询次数过多而带来的压力;用户可以直接使用订单号在指定的平台上付款，而不需要一直维持在系统中，甚至因为无法付款而造成频繁登录刷新造成系统不必要的负载。

3、增加负载服务，针对于不同事务阶段增加不同的负载机制，特别是用户开始事务前，特别应当通过负载来增加用户进入系统的容量，甚至于当让用户从登录起就是可被管理的，我相信国人的ddos能力是很强悍的。

三、用户行为控制

1、用户刷新页面，从队列中删除，直接加入到队尾，防止用户刷新带来不必要的负载;

2、用户登录时提示所在队列序列，并在队列变化是提示，避免用户重复登录操作;

3、队列自动提示，不需要用户自己操作;

4、提交订单自动加入队列等候不能够立刻处理时，提示用户等待（可能是长时间等待），在可以处理时自动返回给用户结果，避免重复提交;

5、以上这些都应该建立在一个可控的会话机制基础之上，系统能够维持庞大的会话数，在核心业务之前有大量排队和负载服务来负责管理这些会话，只有在事务处理服务可以处理时进入事务队列。

6、完成事务后立刻将用户从核心事务队列中删除，避免对核心事务带来不必要压力。让每个用户会话在系统逻辑中所占时间尽量短。

7、官方可以推出订票客户端，直接将繁琐的步骤简单化和傻瓜化，避免第三方客户端采用频刷或持续会话的方式对系统带来的附加负载。

和很多的大师们比起来，我的这些想法和思路也许很不成熟，但是权且记下，以后自己也好反思。