🎉🎉欢迎光临🎉🎉

🏅我是苏泽，一位对技术充满热情的探索者和分享者。🚀🚀

🌟特别推荐给大家我的最新专栏《Redis实战与进阶》

本专栏纯属为爱发电永久免费！！！

这是苏泽的个人主页可以看到我其他的内容哦👇👇

努力的苏泽http://suzee.blog.csdn.net/

我们用的是云托管的的服务 那自然是部署中间件到云服务上去了 服务是一路开通 结果到了需要调试的时候 怎么也连不上 （说是内网直连，但关键是 同事们都在线下做本地测试的呀）

直接无语了 面对这一场景 怎么办？业务还要继续 等着交货的  于是我想起了之前学过的技术栈 

目录

最近工作室的一个业务跟另一个业务合并 自然要用到MQ（消息队列Message Queue）那么很显然 就要部署个RabbitMQ到服务器上了  

Redis 也能作为消息队列的（不过用的比较少所以不大容易记起来 或者也没啥人知道） 于是一顿卡卡操作  步骤还比MQ简单  下面就来看是如何实现的

正片

Redis作为消息队列的优缺点：

使用Redis作为消息队列的选择相对于使用专门的消息队列系统（如RabbitMQ、Kafka等）有以下优点和：

缺点也很明显：

应用场景：

Redis实现消息队列系统 实现步骤：

配置Redis：

设置RedisTemplate的序列化器。在消息队列中，你可以使用默认的序列化器，即StringRedisSerializer，它会将消息以字符串的形式进行存储和传输。可以通过以下代码设置默认的序列化器：

实现消息的发布和订阅功能。

实战与改良

代码解释

我把消息处理的系统中心化处理，也就是说是这个监听系统他可以监听reserved通道的所有业务类型，我这里列举了四种wait，agree，refuse，over四种 但如果是更大的业务体系 同一个通道可能面临着更多可能性分支  那如果按照第一套的方案 需要对每一个具体业务实现一个监听者 工作量就很大（可能这样耦合会低一些吧）

但是我这样把消息集中处理 然后短信发送系统就专门只做短信发送的事情 xx系统就只做对应的工作 就能把工作上的耦合度大大降低

那么大家应该也注意到我的两个负责序列化和反序列化的方法了吧 这是因为业务需求 要把对象封装成一个类 所以这里的方案就是在信息中心处理器上 自定义一个序列化方案（如果再做得好一点其实可以把这个序列器抽理出来封装为一个抽象方法 用泛型来定义返回结果和参数 这样就能序列化所有引用的类型了）  

遇到的问题：

对了 中途遇到了这样一个错误

原因与分析：

实际业务中的测试

发布服务

订阅服务（监听服务）

测试结果

简单轻量：Redis是一个内存中的数据存储系统，具有轻量级和简单的特点。相比较专门的消息队列系统，使用Redis作为消息队列不需要引入额外的组件和依赖，可以减少系统的复杂性。

速度快：由于Redis存储在内存中，它具有非常高的读写性能。这对于需要低延迟的应用程序非常有优势。

多种数据结构支持：Redis提供了丰富的数据结构，如列表、发布/订阅、有序集合等。这使得Redis在处理不同类型的消息和任务时更加灵活。

数据持久化：Redis可以通过将数据持久化到磁盘来提供数据的持久性。这意味着即使Redis重启，之前的消息也不会丢失。

广泛的应用场景：Redis不仅可以用作消息队列，还可以用作缓存、数据库、分布式锁等多种用途。如果你的应用程序已经使用了Redis，那么使用Redis作为消息队列可以减少技术栈的复杂性。

缺少一些高级特性：相对于专门的消息队列系统，Redis在消息队列方面的功能可能相对简单。例如，它可能缺乏一些高级消息传递功能，如消息重试、消息路由、持久化消息等。

可靠性和一致性：Redis的主要设计目标是提供高性能和低延迟，而不是强一致性和高可靠性。在某些情况下，Redis可能会丢失消息，或者在出现故障时可能无法提供持久性保证。

适用于简单的中小型项目 如果功能简单，访问量并不大可以考虑 如果你的应用程序对可靠性和高级功能有严格要求，并且需要处理大量的消息和复杂的消息路由，那么使用专门的消息队列系统可能更合适。

首先，确保你已经正确地配置了Redis和Lettuce依赖项，并创建了LettuceConnectionFactory对象。

创建一个RedisTemplate对象，并将LettuceConnectionFactory设置为其连接工厂：

在上述代码中，"channel_name"是消息的通道名称，"message_payload"是要发布的消息内容。

首先，创建一个MessageListener实现类来处理接收到的消息：

创建一个LettuceMessageListenerAdapter对象，并提供MessageListener实现类：

创建一个RedisMessageListenerContainer对象，并配置它的LettuceConnectionFactory和监听适配器：

通过以上步骤，我们创建了一个LettuceConnectionFactory对象来与Redis服务器建立连接。然后，我们创建了一个MessageListener实现类来处理接收到的消息。接下来，我们创建了一个LettuceMessageListenerAdapter对象，并提供MessageListener实现类。最后，我们创建了一个RedisMessageListenerContainer对象，并配置它的LettuceConnectionFactory和监听适配器，然后启动容器以开始监听指定通道上的消息。

以上的方案 好处就是 可以很明显的知道监听者在哪个部分 监听对应通道的信息 然而 业务当中 如果每一个对应模块的业务和通道都建立一个监听者来进行监听（我们假设每一个就业务所要得到消息以后所执行的逻辑都不相同） 那这个工作量就会暴增 

于是就有了第二种写法 ：

错误信息：com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `TopOne.MessageSystem.entity.reserveMessage` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)

reserveMessage类缺少默认构造函数，这导致Jackson库无法构造该类的实例。错误消息中提到了以下内容："Cannot construct instance of TopOne.MessageSystem.entity.reserveMessage (no Creators, like default constructor, exist)"。 为了使Jackson能够正确地反序列化对象，需要在reserveMessage类中添加一个默认构造函数。默认构造函数是一个无参数的构造函数，它不需要任何参数来创建对象。 在你的reserveMessage类中

这个是改好的封装类：  

成功

这里面的打印是代替了原本业务中的短信发送 也算是成了

这一期就到这 感谢观看