ThinkSSL🔒 一键申购 5分钟快速签发 30天无理由退款 购买更放心 广告
从上一章,大致已经知道消息队列是什么。 而本章,讲述消息队列在实际项目中的价值,即应用场景。 > 在合适的时候,引入消息队列,能让我们的服务架构可用性更高,能力更优秀。 下面,一起来了解消息队列的应用场景。 # 数据冗余 我们可能在看到“冗余”这个词的时候,觉得他是个贬义词。 但实际上,一定程度的冗余,会让我们的数据更加安全。 比如,数据库备份,就是一种数据冗余,mysql读写分离,亦是通过日志和轮询实现数据冗余。 **这样,当我们某一份数据出现问题时,我们还有第二份数据,数据就更加安全。** 那么,消息队列如何提供冗余功能呢? > 常见的消息队列系统,会将数据保存在内存中,以提高数据读写效率。既然数据在内存中,就可能出现丢失的情况,所以,它们又提供持久化的功能,保证在队列系统崩溃后,数据仍然存在。 > 另外,消息队列内的每一条消息,都必然存在 reserved 和 deleted 两个状态,只有当消费者给队列系统发送处理成功的信号时,消息才会从队列中删除,并不会因为消息已接收,就删除消息。 可以说,消息队列,也是增对数据库层的一道输入向缓存,对数据有冗余作用。即,当有数据需要进入数据库,会先经过消息队列,再进入数据库。 # 解耦合 我们知道软件工程讲究**高内聚低耦合**,所以我们会想许多办法来控制耦合度,即解耦。 消息队列,也是一种解耦的方案。 按照普通流程,**消费代码**可能会直接跟在**生产代码**后面,那么,生产和消费就成了彼此的上下文,甚至连变量、作用域等都会有依赖,此时,你若对生产代码的某个变量进行修改,你必须仔细检查消费代码是否也使用了这个变量。 > 通过消息队列,我们将生产代码和消费代码拆分开来,它们不再互相依赖彼此的具体实现,只依赖于消息队列中**消息的结构**。只要消息结构不变,生产代码和消费代码如何修改,都不会影响到彼此。 这一点,我们可以联想到上一章《什么是消息队列?》中的下单功能辅助理解。 # 异步能力 有人说,**高性能离不开异步,异步离不开队列**。 一定意义上来说,这句话是很有道理的。 异步,它让每一个调用都能及时返回,提升响应速度。在这里,可能需要理解一下异步:[《关于异步的理解》](https://www.jianshu.com/p/1593a1d2c002) 队列,保证了异步调用的处理不会丢失。这句话中的“处理”一词,指处理工作,是个名词。 > 我们知道,异步,它先返回的是调用动作是否成功的结果,而具体调用执行的逻辑和结果,并不在这里返回,而是以通知(回调)的形式进行。队列,是确保每一个调用的处理都会被执行数据结构。 这一点,我们可以在之后消息队列的实践中,体会到。 消息队列,能够让在架构上提供异步能力(注意,是架构上,而非代码层面如函数调用的异步能力)。 关于这个异步能力,还是可以参考上一章《什么是消息队列?》中的下单功能, # 扩展性 当架构中加入消息队列,生产者和消费者就比较容易扩展。 仍然以下单功能举例,如果生产者和消费者的代码耦合在一起,互相严重依赖,当我们想对生产者产生内容进行不同的处理(消费)时,则需要在原有的源码中进行扩展,这对原有代码产生伤害,便不必说扩展性了。 > 但如果以消息队列将生产者和消费者进行解耦,则,我们只需要添加订阅消息的消费者程序即可,新的消费者对旧消费者没有任何伤害,它依旧依赖于消息队列,只需要确保它能收到消息即可。 # 顺序保证 队列本身具备“先进先出”的特性,消息队列是一种队列结构的中间件,则,消费者会根据消息进入的先后顺序,进行先后处理。 **其本身就能解决顺序问题** # 削峰填谷 在某些高并发的场景下,流量突然激增,比如秒杀。 此时,数据库的压力很大,而数据库的读写处理能力普遍低于内存式的消息队列。 此时,可以将消息临时存储于消息队列中,减少数据库的压力,然后再由消费者按数据库能够接受的频率去读取消息,进行处理,因为数据库只在秒杀那一刻压力很大,平时会清闲一些。 **这就是将山峰削掉,填补山谷**