672-Redis运行不稳定&还有哪些组件可用

Dear 丶 2022-09-15 05:47 97阅读 0赞

## 除了Redis，还有哪些组件可用 ##

**redis**：主业是一个缓存数据库（存储key-value），性能非常好，响应快，低延时。还能实现分布式锁，还能实现发布-订阅功能，我们可以订阅上几个通道channel，然后有人在这个channel上发布消息，所有订阅这个channel的订阅者都可以接收到这个消息。  
redis还提供了数据持久化的功能，因为本质上数据是在缓存上存储的，为了提高可用性，就算出问题了，数据也是可以恢复的，因为数据是可以落盘的。

**服务器中间件**：属于后端整个服务的组件之一，协助后端真真正正的业务服务器或者日志服务器来完成一些功能：异步的发布-订阅功能（MQ消息队列）  
**redis**也是专门的消息队列，对于消息的分发和消费，有高可用，可靠性，运行也很稳定，对于局域网的消息通信来说，redis的发布-订阅足够了。内存访问快，低延时。  
**kafka**也是服务器中间件，分布式的消息队列中间件，非常的稳定，高并发高可用高稳定。在分布式环境中进行日志的收集，异步的日志收集，性能高。  
**zeromq  
rabbitmq  
rocketmq**  
…  
**本质上都是服务器中间件。**  
在队列订阅了一些主题topic，当这个主题topic有消息发生的话，所有订阅这个主题的消费者都可以收到消息。

## Redis运行不稳定，挂了的话怎么办？ ##

我们为了服务可以稳定的运行，不可能给里面无限制的装数据，我们都会给这个服务配置跟这个服务可以正常运行的预值：内存的使用量，消息的使用量，消息的存储量，都会去配置预值，超过这个预值的话，我们就会直接丢弃这些处理不了的额外的消息。  
比如说，秒杀系统短时间内会产生大量大量的订单，如果所有的订单服务，我们的后端服务都要处理的话，我们秒杀的话，在后端会有一个MQ消息队列，比如说rebitmq，非常强劲，队列没有大小，只要内存够用，它就会一直往内存上放消息。秒杀系统的订单量实在是太大了，所以我们一般为了进行流量的削峰的话，一般也是会规定一个未处理订单的上限的预值，超过这个预值的话，后续来的订单就直接丢弃，不处理了。不可能说是所有过来的请求都处理，短时间，高并发的情况下，不能为了处理所有的请求而把后端的服务搞挂了，得不偿失啊！！！

redis对于它本质的键值对存储的话，是非常稳定的，而且不怕数据的丢失，配置了主从，主备服务器，然后还可以进行数据的持久化，即使主服务器挂了，还可以切换到从服务器上，等主服务器恢复了，还可以切到主服务器。  
主备服务器可以进行数据的同步。  
如果是使用redis的发布订阅功能，因为这不是它的主业，包括使用它的分布式锁功能，redis也会经常出问题，导致分布式锁无法释放，导致分布式集群环境中一个机器一直占用了分布式锁，其他机器一直获取不到这把锁。  
在之前的redis版本，对于发布-订阅来说，redis并没有发布-订阅消息的控制。如果redis的消息积累过快，而应用层消费消息过慢，导致redis的消息越攒越多，在之前的redis版本，就会导致redis积攒消息过多，直接导致整个redis服务挂掉，或者说是因为占用占用内存过多，Linux直接把进程kill掉了，导致不稳定。redis一旦挂掉，就导致跨服务器通信就没有办法聊天了。  
**因为redis的主业不是发布-订阅，所以它在消息的消费这块，也有一些问题，**  
**消息的发布**：首先，我们要往一个channel上去发布一个消息，但是如果现在没有人在这个channel上监听消息的话，在redis里面往一个channel上发布这个消息的话，这个消息相当于是丢了，因为没有人去订阅这个消息。  
**消息的消费**：不可靠。当我们在这个redis的某个channel上订阅了消息，那么由channel的发布方在这个channel上发布了消息，那发布消息以后，redis就会给订阅了消息的订阅方转发了消息，其实它只管发送，没有做消息的可靠传输，没有做消息的一发送一响应，如果是由于网络的情况，导致发送的消息最终没有到达订阅方，这个消息就丢了。

**在实际的应用中**，我们如果是处理一个普通的一些非关键非核心的业务的话，如果想用到异步的发布-订阅的功能，而且发布的消息的流量不是非常大，我们是可以使用redis的，因为它是基于内存的，低延时，消息通信快，有一定的应用场景的。  
但是，如果我们要依赖消息的发布-订阅实现核心功能，比如说，聊天消息，随着客户端的增长，流量是非常大的，我们可以采用专业级别的消息队列来作为服务器中间件实现我们的聊天软件的核心业务-消息传输。  
**kafka  
zeromq  
rabbitmq  
rocketmq**  
**这些服务器中间件，运行稳定，本身就是高并发场景下应用的，对消息的发布和消费都有可靠性的机制**，消息的发布：当你向某一个主题发送消息的话，如果没有人订阅这个主题，这个消息是会缓存到消息队列里面，而不是像redis那样直接丢掉。  
消息的消费：如果有发布者向这个主题发布了一个消息，如果说是有人订阅了这个主题，要消费这个消息，那么消息队列在这里会有一个可靠的消息机制，保证这个消息一定要被订阅者接收到，有一发送一响应这个过程。如果这个消费没有被订阅者消费的话，MQ消息队列会重新给订阅者推送消息的。  
而且，这些消息队列主业就是完成发布-订阅的消息通信，本身的稳定性，性能是非常不错的，而且这些MQ基本都是有持久化的功能，如果这个服务挂掉了的话，消息队列里面的数据还是可以从持久化的数据文件恢复出来，所以，不用担心数据的丢失。但是rabbitmq就没有提供数据的持久化。

**我们可以把用户的状态存储到redis里面，要查用户的状态就在redis查，查到了就返回，如果查不到，就去mysql查询，查到了往redis缓存一写，然后给服务层返回，继续进行业务处理。**