Redis基础_模拟使用redis是如何缓解数据库的压力

让我们开始用Redis来缓存信息，缓解数据库的压力吧！

我们搭起了这样一个框架，一台客户端，一台Redis缓存服务器：

 

一开始风和日丽，系统运行良好。

后来，我们系统中使用Redis的客户端越来越多，变成了这样：

 

这带来了两个问题：

• Redis内存不足：随着使用Redis的客户端越来越多，Redis上的缓存数据也越来越大，而一台机器的内存毕竟是有限的，放不了那么多数据；
• Redis吞吐量低：客户端变多了，可Redis还是只有一台，而且我们已经知道，Redis是单线程的！这就好比我开了一家饭店，一开始每天只有100位客人，我雇一位服务员就可以，后来生意好了，每天有1000位客人，可我还是只雇一位服务员。一台机器的带宽和处理器都是有限的，Redis自然会忙不过来，吞吐量已经不足以支撑我们越来越庞大的系统。

分析完问题，解决思路也就再清晰不过了——集群。一台Redis不够，那就再加多几台！

 

客户端的请求会通过负载均衡算法（通常是一致性Hash），分散到各个Redis服务器上。
通过集群，我们实现了两个特性：

• 扩大缓存容量；
• 提升吞吐量；

解决了上面提到的两个问题。

主从复制

好，现在我们已经把Redis升级到了集群，真可谓效果杠杠的，可运行了一段时间后，运维又过来反馈了两个问题：

• 数据可用性差：如果其中一台Redis挂了，那么上面全部的缓存数据都会丢失，导致原来可以从缓存中获取的请求，都去访问数据库了，数据库压力陡增。
• 数据查询缓慢：监测发现，每天有一段时间，Redis 1的访问量非常高，而且大多数请求都是去查一个相同的缓存数据，导致Redis 1非常忙碌，吞吐量不足以支撑这个高的查询负载。

问题分析完，要想解决可用性问题，我们第一个想到的，就是数据库里头经常用到的Master-Slave模式，于是，我们给每一台Redis都加上了一台Slave：

 

通过Master-Slave模式，我们又实现了两个特性：

• 数据高可用：Master负责接收客户端的写入请求，将数据写到Master后，同步给Slave，实现数据备份。一旦Master挂了，可以将Slave提拔为Master；
• 提高查询效率：一旦Master发现自己忙不过来了，可以把一些查询请求，转发给Slave去处理，也就是Master负责读写或者只负责写，Slave负责读；

为了让Master-Slave模式发挥更大的威力，我们当然可以放更多的Slave，就像这样：

 

可这样又引发了另一个问题，那就是Master进行数据备份的工作量变大了，Slava每增加一个，Master就要多备份一次，于是又有了Master/slave chains的架构：

 

没错，我们让Slave也有自己的Slave，有点像古代的分封制。

这样最顶层的Master的备份压力就没那么大了，它只需要备份两次，然后让那它底下的那两台Slave再去和他们的Slave备份。