浅谈异步消息队列模型

最近在研究网站的异步消息队列模型，渐渐有了一些心得，下面就说说我个人对于消息队列的理解。

什么是消息队列？

所谓消息队列，就是一个以队列数据结构为基础的一个实体，这个实体是真实存在的，比如程序中的数组，数据库中的表，或者redis等等，都可以。

首先我们说说为什么要使用队列，什么情况下才会使用队列？

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