redis中的消息队列-创新互联

这期内容当中的小编将会给大家带来有关redis中的消息队列介绍，以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

一、认识消息队列

1.1 消息队列概念

“消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。

消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

1.2 核心结构

由一个业务系统进行入队，把消息逐次插入到消息队列中，插入成功之后直接返回成功的结果，后续会有一个消息处理系统，这个系统会把消息系统中的记录逐次进行取出并进行处理，完成一个出队的流程。

1.3 应用场景

数据冗余：比如订单系统，后续需要严格的进行数据转换和记录，消息队列可以把这些数据持久化的存储在队列中，然后有订单，后续处理程序进行获取，后续处理完之后在把这条记录进行删除来保证每一条记录都能够处理完成。

系统解耦：使用消息系统之后，入队系统和出队系统是分开的，也就说只要一天崩溃了，不会影响另外一台系统正常运转。

流量削峰：例如秒杀和抢购，我们可以配合缓存来使用消息队列，能够有效的顶住瞬间访问量，防止服务器承受不住导致崩溃。

异步通信：消息本身使用入队之后可以直接返回。

扩展性：例如订单队列，不仅可以处理订单，还可以给其他业务使用。

排序保证：有些场景需要按照产品的顺序进行处理比如单进单出从而保证数据按照一定的顺序处理，使用消息队列是可以的。

以上都是消息队列常见的使用场景，当然消息队列只是一个中间件，可以配合其他产品进行使用。

1.4 常见队列实现优缺点

队列介质

1、数据库，例如mysql（可靠性高，易实现，速度慢）

2、缓存， 例如redis （速度快，单个消息报包过大时效率低）

3、消息系统，例如rabbitMq （专业性强，可靠，学习成本高）

消息处理触发机制

1、死循环方式读取：易实现，故障时无法及时恢复；（比较适合做秒杀，比较集中，运维集中维护）

2、定时任务：压力均分，有处理上限；目前比较流行的处理触发机制。（唯一的缺点是间隔和数据需要注意，不要等上一个任务没有完成下一个任务又开始了）

3、守护进程：类似于php-fpm 和php-cg,需要shell基础

1.5进程通信

消息队列（也叫做报文队列）能够克服早期unix通信机制的一些缺点。作为早期unix通信机制之一的信号能够传送的信息量有限，后来虽然POSIX 1003.1b在信号的实时性方面作了拓广，使得信号在传递信息量方面有了相当程度的改进，但是信号这种通信方式更像"即时"的通信方式，它要求接受信号的进程在某个时间范围内对信号做出反应，因此该信号最多在接受信号进程的生命周期内才有意义，信号所传递的信息是接近于随进程持续的概念（process-persistent）；管道及有名管道则是典型的随进程持续IPC，并且，只能传送无格式的字节流无疑会给应用程序开发带来不便，另外，它的缓冲区大小也受到限制。

消息队列就是一个消息的链表。可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。

目前主要有两种类型的消息队列：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。考虑到程序的可移植性，新开发的应用程序应尽量使用POSIX消息队列。

系统V消息队列是随内核持续的，只有在内核重起或者显式删除一个消息队列时，该消息队列才会真正被删除。因此系统中记录消息队列的数据结构（struct ipc_ids msg_ids）位于内核中，系统中的所有消息队列都可以在结构msg_ids中找到访问入口。 消息队列就是一个消息的链表。每个消息队列都有一个队列头，用结构struct msg_queue来描述。队列头中包含了该消息队列的大量信息，包括消息队列键值、用户ID、组ID、消息队列中消息数目等等，甚至记录了最近对消息队列读写进程的ID。读者可以访问这些信息，也可以设置其中的某些信息。

二、解藕案例：队列处理“订单系统”和“配送系统”

对于订单流程，我们可以设计两个系统，一个是“订单系统” 另外一个是 “配送系统”， 在网购的时候我们应该都见过，当我提交了一个订单之后，我在后台可以看到我的货物正在配送中。这个时候就要参与进来一个“配送系统”。

如果我们在做架构的时候把 “订单系统” 和 “配送系统” 设计在一起的话就会出现一些问题，首先对于订单系统来说，因为系统的压力会比较大，但是 "配送系统" 没必要为这些压力做一些即时的反应。

第二个我们也不希望在订单系统出现故障之后导致配送系统也出现故障，这个时候就会同时影响到两个系统的正常运转。所以我们希望把这两个系统进行解耦。这两系统分开之后我们可以通过一个中间的 “队列表” 进行这两个系统的沟通。

2.1 架构设计

1、首先订单系统会接收用户的订单，然后进行订单的处理。

2、然后会把这些订单信息写到队列表中，这个队列表是沟通这两个系统的关键。

3、由配送系统定时执行的一个程序来读取队列表进行处理。

4、配送系统处理之后，会把已处理的记录进行标记。

2.2 程序流程

三、流量削峰案例：Redis 的 list 类型实现秒杀

redis 基于内存，它的速度会非常快，redis 对数据库有一个非常好的补充作用因为它是可持久化的，redis会周期性的把数据写到硬盘里，所以它不用担心断电的问题，从这方面说它比另一款缓存 memcache 更有优势些，另外 redis 提供五种数据类型（字符串，双向链表，哈希，集合，有序集合）

一般情况下，做秒杀案例，抢购，瞬间高比你高发，需要排队 的案例中 redis是一个很好的选择。

3.1 redis数据类型中的 list 类型

redis 的list 是一个双向链表，可以从头部或者尾部追加数据。

* LPUSH/LPUSHX :将值插入到（/存在的）列表头部

* RPUSH/RPUSHX: 将值插入到（/存在的）列表尾部

* LPOP : 移除并获取列表的第一个元素

* RPOP: 移除并获取列表的最后一个元素

* LTRIM: 保留指定区间内的元素

* LLEN: 获取列表长度

* LSET: 通过索引设置列表元素的值

* LINDEX: 通过索引获取列表中的元素

* LRANGE: 获取列表指定范围内的元素

3.2 架构设计

一个简单结构秒杀的程序设计。

1、首先记录是哪一个用户参与了秒杀同时记录他的时间。

2、将用户的id存到redis列表中，让它排队。如果规定只有前10个用户可以参与成功，如果列表中的个数已经够了就不会让它继续追加数据。这样redis的列表长度就只会是10个

3、最后在慢慢的将redis中的数据写入到数据库中，以减少数据的压力

3.3 代码级设计

1、当用户开始秒杀时，将秒杀程序的请求写入Redis (uid, time_stamp)中。

2、假使规定只有10人可以秒杀成功，检查 Redis 已经存放数据的长度，超出上限直接丢弃说明秒杀完成。

3、最后在死循环处理存入Redis中的10条数据，然后在慢慢的取数据并存入到mysql数据库中。

在秒杀这一块对于数据库的压力特别的大，如果我们没有这样的设计，会造成mysql的写入瓶颈。我们通过Redis的一个对列list，然后把秒杀的请求放入到Redis里面， 最后通过入库程序，把数据慢慢的写入到数据库，这样的话就可以实现流量的均衡，对mysql不会造成太大的压力。　

四、RabbitMQ

这里讲解一些RabbitMQ的使用，首先我们之前讲秒杀案例的时候提到了锁的机制，防止其他程序处理同一条记录，如果我们的系统架构非常的复杂，有多个程序实时的读取一个队列，或者我有多个发送程序，同时来操作一个或多个队列，甚至我还想这些程序分布在不同的机器上，这种情况下用redis队列就有些力不从心了。这种时候怎么办呢，我们就需要来引入一些更专业的消息队列系统，这些系统可以更好的来解决问题。

4.1 RabbitMQ的架构和原理

特点：完整的实现了AMQP,集群简化，持久化，跨平台

RabbitMQS使用

1、RabbitMQ安装 （rabbitmq-server, php-amqplib）

2、生产者向消息通道发送消息

3、消费者处理消息

工作队列

思想：由生产者发送给消息系统，消息系统把任务封装成消息队列之后，然后供多个消费者使用同一个队列

这不仅解决了生产者和消费者之间的解耦，还可以实现了消费者和任务的共享，减缓了服务器的压力。

上述就是小编为大家分享的redis中的消息队列了，如果您也有类似的疑惑，不妨碍参照上述分析进行理解。如果想了解更多相关内容，请关注创新互联网站制作公司行业资讯。