使用使用Redis作为消息队列服务场景应用案例作为消息队列服务场景应用案例
一、消息队列场景简介
“消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。
消息被发送到队列中，“消息队列”是在消息的传输过程中保存消息的容器。
在目前广泛的Web应用中，都会出现一种场景：在某一个时刻，网站会迎来一个用户请求的高峰期（比如：淘宝的双十一购
物狂欢节，12306的春运抢票节等），一般的设计中，用户的请求都会被直接写入数据库或文件中，在高并发的情形下会对数
据库服务器或文件服务器造成巨大的压力，同时呢，也使响应延迟加剧。这也说明了，为什么我们当时那么地抱怨和吐槽这些
网站的响应速度了。当时2011年的京东图书促销，曾一直出现在购物车中点击“购买”按钮后一直是“Service is too busy”，其实
就是因为当时的并发访问量过大，超过了系统的最大负载能力。当然，后边，刘强东临时购买了不少服务器进行扩展以求增强
处理并发请求的能力，还请了信息部的人员“喝茶”，现在京东已经是超大型的网上商城了，我也有同学在京东成都研究院工作
了。
从京东当年的“Service is too busy”不难看出，高并发的用户请求是网站成长过程中必不可少的过程，也是一个必须要解决的
难题。在众多的实践当中，除了增加服务器数量配置服务器集群实现伸缩性架构设计之外，异步操作也被广泛采用。而异步操
作中最核心的就是使用消息队列，通过消息队列，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发
事务，改善网站系统的性能。在京东之类的电子商务网站促销活动中，合理地使用消息队列，可以有效地抵御促销活动刚开始
就开始大量涌入的订单对系统造成的冲击。
记得我在实习期间，成都市XXXX局的一个价格信息采集发布系统项目中有一个采集任务发布的模块，其中每个任务都是一个
事务，这个事务中需要向数据库中不断地插入行，每个任务发布时都要往表中插入几百行甚至几千行的任务数据（比如价格采
集日报，往往需要发布2-3年的任务数据，每一天都是一个任务，所以大约有2,3千行任务期号数据，还要发给很多个区县的监
测中心，因此数据库写操作量很大，更别说同时发布的并发操作），由于业务逻辑的处理比较复杂和往数据库的写操作量交
大，所以在没有采用消息队列时点击“发布”按钮后往往需要等待1分钟左右的时间才提示“发布成功”，用户体验极不友好。
资源评论
