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集群的高可用。