将redis发布订阅模式用做消息队列和rabbitmq的区别？Redis禁用持久化功能的设置？想想为什么要使用MQ？使用了消息队列会有什么缺点?

将redis发布订阅模式用做消息队列和rabbitmq的区别：

1·、可靠性

redis ：没有相应的机制保证消息的可靠消费，如果发布者发布一条消息，而没有对应的订阅者的话，这条消息将丢失，不会存在内存中；

rabbitmq：具有消息消费确认机制，如果发布一条消息，还没有消费者消费该队列，那么这条消息将一直存放在队列中，直到有消费者消费了该条消息，以此可以保证消息的可靠消费，那么rabbitmq的消息是如何存储的呢？（后续更新）；

2、实时性

redis:实时性高，redis作为高效的缓存服务器，所有数据都存在内存中，所以它具有更高的实时性

3、消费者负载均衡：

rabbitmq队列可以被多个消费者同时监控消费，但是每一条消息只能被消费一次，由于rabbitmq的消费确认机制，因此它能够根据消费者的消费能力而调整它的负载；

redis发布订阅模式，一个队列可以被多个消费者同时订阅，当有消息到达时，会将该消息依次发送给每个订阅者，她是一种消息的广播形式，redis本身不做消费者的负载均衡，因此消费效率存在瓶颈；

4、持久性

redis：redis的持久化是针对于整个redis缓存的内容，它有RDB和AOF两种持久化方式（redis持久化方式，后续更新），可以将整个redis实例持久化到磁盘，以此来做数据备份，防止异常情况下导致数据丢失。

rabbitmq：队列，每条消息都可以选择性持久化，持久化粒度更小，更灵活；

5、队列监控

rabbitmq实现了后台监控平台，可以在该平台上看到所有创建的队列的详细情况，良好的后台管理平台可以方面我们更好的使用；

redis没有所谓的监控平台。是以订阅的方式实现消费

 

总结

redis：       轻量级，低延迟，高并发，低可靠性；

rabbitmq：重量级，高可靠，异步，不保证实时；

rabbitmq是一个专门的AMQP协议队列，他的优势就在于提供可靠的队列服务，并且可做到异步，而redis主要是用于缓存的，redis的发布订阅模块，可用于实现及时性，且可靠性低的功能。

 

Redis禁用持久化功能的设置

用过Redis的朋友都知道，这玩意有个比较强大的功能叫做持久化，就是在结束服务的时候把缓存中的内容保存到磁盘上，再启动服务的时候它自动从保存的磁盘文件中恢复服务停止之前的缓存内容，就好像服务从来没停止过一样。这个功能在生产服务器上确实挺方便的，重启也不会丢失缓存内容，但在开发环境中就不方便，每天开机启动调试环境的时候，它都自动加载前一天的缓存内容，有时候数据都改了很多，它还是旧数据。

于是想禁用这个持久化的功能，查了资料知道修改redis.conf，找到save配置，改为save "" 即可。改了之后也没多想，后来发现还是有旧数据的缓存，感觉有点奇怪，运行flushall命令就没有旧数据了，但隔天重启电脑，又显示很多旧数据，真灵异了！后来反复排查才发现redis.conf中还有个dir配置，就是持久化的磁盘文件存放的目录，打开相应的目录，删除目录中的*.rdb文件，再重启redis服务，果然再也没有旧数据了！

注意：hazelcast内存网格没有持久化功能，要实现持久化可以与mangodb集成。

 

想想为什么要使用MQ？

1.解耦，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！

2.异步，将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度

3.削峰，并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常

使用了消息队列会有什么缺点?

1.系统可用性降低:你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低

2.系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。

本文地址：https://blog.csdn.net/qq_38386438/article/details/107354090