最近在研究网站的异步消息队列模型，渐渐有了一些心得，下面就说说我我的对于消息队列的理解。redis
所谓消息队列，就是一个以队列数据结构为基础的一个实体，这个实体是真实存在的，好比程序中的数组，数据库中的表，或者redis等等，均可以。数据库
个人理解是，那些实时性要求不高，且比较耗时的任务，是队列的最佳应用场景。好比说我在某网站注册一个帐号，当个人信息入库注册成功后，网站须要发送一封激活邮件，让我激活帐号，而这个发邮件的操做并非须要实时响应的，没有必要卡在那个注册界面，等待邮件发送成功，再说发送邮件原本就是一个耗时的操做（须要调用第三方smtp服务器），此时，选择消息队列去处理。注册完成，我只要向队列投递一个消息，消息的内容中包含我要发送邮件的一些设置，以及发送时间，重试次数等消息属性。这里的投递操做（能够是入库，写入缓存等）是要消息进入一个实体的队列。其中应该有一进程（消费者）一直在后台运行，他不断的去轮训队列中的消息（按照时间正序，队列是先进先出），看有没有达到执行条件的，若是有就取出一条，根据消息配置，执行任务，若是成功，则销毁这条消息，继续轮训，若是失败，则重试，知道达到重试次数。这时用户已经收到注册成功的提示，可是已经去作其余事了，邮件也来了，用户点击邮件，注册成功。这就是消息队列的一个典型应用。
再说一个场景，点赞，这个在高并发的状况下，很容易形成数据库链接数占满，到时整个网站响应缓慢，才是就是想到要解决数据库的压力问题，通常就是两种方案，一是提升数据库自己的能力（如增长链接数，读写分离等），可是数据库老是有极限的，到达了极限是没有办法在提高了的，此时就要考虑第二种方案，释放数据库的压力，将压力转移到缓存里面。就拿实际的点赞来讲吧，用户的点赞请求到来，我只是将点赞请求投递到消息队列里面，后续的点赞请求能够将消息合并，即只更新点赞数，不产生新的任务，此时有个进行再不断的轮训消息队列，将点赞消息消耗，并将值更新到数据库里面，这样就有效的下降了数据库的压力，由于在缓存层将数个数据库更新请求合并成一个，大大提升了效率，下降了负载。数组