Amazon云产品介绍(3) - 简单无脑的队列服务 - Amazon SQS
Amazon云产品介绍(1) - Amazon EC2
Amazon云产品介绍(2) - Amazon SimpleDB
Amazon云产品介绍(3) - Amazon RDS
12306网站之所以慢，数据存储只是其中一个小的问题，而更多的改进可以存在用户使用流程之上。为了公平起见，该系统需要每个城市的用户在同一个时间点去“抢票”，而因为流量巨大，导致抢票的那个小时间段响应速度很慢。结果自然是用户着急的不停的点，发起更多的请求，带来更多的废流量。最终导致大家都在点，服务器忙死了，但是很少人成功订到票。
如果能够做到，每个人都点击自己要查询的票，然后申请订购，然后安安静静的等着就好了。这样服务器不会处理一个人发来的重复的请求，而将本来就很大的流量再扩大N倍。
在前台（或者后台）限制一个用户的查询/订购请求是很容易的事情，问题是在一个短时间内，比如说3:00整，忽然来10万的请求，应用程序会选择处理前N个，然后把剩下的都按超时返回。把所有请求都记录下来，然后按顺序的执行就成为降低服务器压力的好办法。至于前台，可以通知用户过半小时再来查询结果等等，这里不讨论~
在云体系里，分配任务是个很核心的问题：我们有10万个请求需要按时间顺序执行，我们有100台机器，但是怎么让各个机器独立工作又不会重复领到人家要做的任务。基于消息通讯的架构是云系统中解决任务分配问题的一个常见的解决方案。
Java出生的工程师应该接触过消息系统，在java里叫JMS的东西，java社区中也有不少不错的实现，比如说activeMQ等等。我用JMS年代比较早，不知道现在是不是还是这样，配置一个消息队列无比的麻烦，不止要安装服务器和java容器，还要配置各种bean和factory。其实很简单的工作：POST放入和GET取出就能完成的。Amazon按照这个简单的想法实现了这个伟大的服务，消息也不再是bean或者什么对象，只不过是string而已，至于你要放id还是json还是serialized object，这是你自己的事情。
对比自己配置安装的消息系统，amazon SQS至少有这些好处：
- 不用安装配置，几乎立马能用
- 什么语言都行，REST请求
- 没有消息上限，毕竟是云嘛 （不过，按消息条数收费的）
- （几乎）永远都不会down, 永远都不会丢失消息
用法也很简单，在amazon的console里创建一个queue，然后用api调用就可以了，从从来没有接触过到存入读出消息，大概会花费你半小时研究。注意每个国家地区的queue是分开的。
价格我认为非常可以接受，具体价格网上可以查。我们大概一个月千万级的消息量，算下来10美元的样子。
大家可以想想，“中国铁路订票系统”里，哪些业务可以或者应该改成异步队列执行的呢？
