Redis从微观到宏观的认识

Redis是一个开源的、基于内存的数据结构存储器，可以用作数据库、缓存和消息中间件。

假设让你在程序中实现一个缓存，我们大都会想到用Map来实现，那用什么Map呢？HashMap、TreeMap这些都线程不安全，那就用HashTable或者ConcurrentHashMap好了。不管用什么Map，它背后都是key-value的Hash表结构，Redis也是这样实现的，另一个常用的缓存框架Memcached也是。

一个简单的Hash表数据结构图

简单说，Hash表就是一个数组，而这个数组的元素，是一个链表。

为什么元素是链表？理论上，如果我们的数组可以做成无限大，那么每来一个key，我们都可以把它放到一个新的位置。但是这样很明显不可行，数组越大，占用的内存就越大。

所以我们需要限制数组的大小，假设是16，那么计算出key的hash值后，对16取模，得出一个0~15的数，然后放到数组对应的位置上去。

好，现在key1放到index为2的位置，突然又来了一个key9，刚好他也要放到index为2的位置，那咋办，总不能把人家key1给踢掉吧？所以key1的信息必须存储在一个链表结构里面，这样key9来了之后，只需要把key1所在的链表节点的next，指向key9的链表节点即可。

很明显，链表越长，Hash表的查询、插入、删除等操作的性能都会下降，极端情况下，如果全部元素都放到了一个链表里头，复杂度就会降为O(n)，也就和顺序查找算法无异了。（正因如此，Java8里头的HashMap在元素增长到一定程度时会从链表转成一颗红黑树，来减缓查找性能的下降）,redis是通过rehash解决这个问题的，有兴趣的自行了解。

redis的C/S架构：

作为Redis用户，我们要怎样把数据放到上面提到的Hash表里呢？

我们可以通过Redis的命令行，当然也可以通过各种语言的Redis API，在代码里面对Hash表进行操作，这些都是Redis客户端（Client），而Hash表所在的是Redis服务端（Server），也就是说Redis其实是一个C/S架构。

Redis 的 客户端与服务端可以再一个服务器上，也可以再不同服务器上

Redis的Server是单线程服务器，基于Event-Loop模式来处理Client的请求，使用单线程的好处包括：

• 不必考虑线程安全问题。很多操作都不必加锁，既简化了开发，又提高了性能；

• 减少线程切换损耗的时间。线程一多，CPU在线程之间切来切去是非常耗时的，单线程服务器则没有了这个烦恼；

• Redis内存不足：随着使用Redis的客户端越来越多，Redis上的缓存数据也越来越大，而一台机器的内存毕竟是有限的，放不了那么多数据；

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

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

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

• 扩大缓存容量；

• 提升吞吐量；

主从复制：

集群的缺点：

• 数据可用性差：如果其中一台Redis挂了，那么上面全部的缓存数据都会丢失，导致原来可以从缓存中获取的请求，都去访问数据库了，数据库压力陡增。

• 数据查询缓慢：监测发现，每天有一段时间，Redis 1的访问量非常高，而且大多数请求都是去查一个相同的缓存数据，导致Redis 1非常忙碌，吞吐量不足以支撑这个高的查询负载。

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

通过主从复制我们实现了

• 数据高可用：Master负责接收客户端的写入请求，将数据写到Master后，同步给Slave，实现数据备份。一旦Master挂了，可以将Slave提拔为Master；

• 提高查询效率：一旦Master发现自己忙不过来了，可以把一些查询请求，转发给Slave去处理，也就是Master负责读写或者只负责写，Slave负责读；

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

一个Master可以有多个Slave，Slave又可以有多个自己的Slave，这就实现了redis集群的高可用。