本文公众号来源:柳树的絮叨叨
作者:SexyCode
Redis是啥?用Redis官方的话来说就是:
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.
Redis是一个开源的、基于内存的数据结构存储器,可以用作数据库、缓存和消息中间件。
What??? 这玩意把数据放在内存,还想当数据库使?为什么是“data structure store”,而不是“data store”?还能用作消息中间件??你这么牛,你咋不上天?
是的,Redis就是这么牛 ( ̄▽ ̄)~*
我们只需从Redis最常用的功能——缓存,开始了解,上面那些问题也就迎刃而解了。
如果你是Redis新手,或者此前从未接触过Redis,那么这篇文章不仅能帮你快速了解Redis的实现原理,还能帮你了解一些架构设计的艺术;如果你是Redis老司机,那么,希望这篇文章能带给你一些新的东西。
假设让你设计一个缓存,你会怎么做?
相信大家都会想到用Map来实现,就像这样:
String value = map.get("someKey");
if(null == value) {
value = queryValueFromDB("someKey");
}
那用什么Map呢?HashMap、TreeMap这些都线程不安全,那就用HashTable或者ConcurrentHashMap好了。
不管你用什么样的Map,它的背后都是key-value的Hash表结构,目的就是为了实现O(1)复杂度的查找算法,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在元素增长到一定程度时会从链表转成一颗红黑树,来减缓查找性能的下降)
怎么解决?rehash。
关于rehash,这里就不细讲了,大家可以先了解一下Java HashMap的resize函数,然后再通过这篇文章:A little internal on redis key value storage implementation 去了解Redis的rehash算法,你会惊讶的发现Redis里头居然是两个HashTable。
好,上面带大家从一个及其微观的角度窥视了Redis,下面几个小节,再带大家用宏观的视角去观察Redis。
作为Redis用户,我们要怎样把数据放到上面提到的Hash表里呢?
我们可以通过Redis的命令行,当然也可以通过各种语言的Redis API,在代码里面对Hash表进行操作,这些都是Redis客户端(Client),而Hash表所在的是Redis服务端(Server),也就是说Redis其实是一个C/S架构。
显然,Client和Server可以是在一台机器上的,也可以不在:
如果你想玩一下Redis,又不想自己搭建环境,可以试一下这一个非常好玩的网页:Try Redis,你可以按照上面的提示,熟悉Redis的基础命令,感受一下Redis的C/S模式。
值得一提的是,Redis的Server是单线程服务器,基于Event-Loop模式来处理Client的请求,这一点和NodeJS很相似。使用单线程的好处包括:
当然,单线程服务器最大的问题自然是无法充分利用多处理器,不过没关系,别忘了现在的机器很便宜。请继续往下看。
好,现在我们已经知道了Redis是一个C/S架构的框架,那就让我们开始用Redis来缓存信息,缓解数据库的压力吧!
我们搭起了这样一个框架,一台客户端,一台Redis缓存服务器:
一开始风和日丽,系统运行良好。
后来,我们系统中使用Redis的客户端越来越多,变成了这样:
这带来了两个问题:
分析完问题,解决思路也就再清晰不过了——集群。一台Redis不够,那就再加多几台!
客户端的请求会通过负载均衡算法(通常是一致性Hash),分散到各个Redis服务器上。 通过集群,我们实现了两个特性:
解决了上面提到的两个问题。
好,现在我们已经把Redis升级到了集群,真可谓效果杠杠的,可运行了一段时间后,运维又过来反馈了两个问题:
问题分析完,要想解决可用性问题,我们第一个想到的,就是数据库里头经常用到的Master-Slave模式,于是,我们给每一台Redis都加上了一台Slave:
通过Master-Slave模式,我们又实现了两个特性:
为了让Master-Slave模式发挥更大的威力,我们当然可以放更多的Slave,就像这样:
可这样又引发了另一个问题,那就是Master进行数据备份的工作量变大了,Slava每增加一个,Master就要多备份一次,于是又有了Master/slave chains的架构:
没错,我们让Slave也有自己的Slave,有点像古代的分封制。
这样最顶层的Master的备份压力就没那么大了,它只需要备份两次,然后让那它底下的那两台Slave再去和他们的Slave备份。
关于Master/slave chains,大家可以参考这篇文章 RedisLab Master/slave chains
这篇文章只是带大家逛一逛Redis的庄园,让大家从微观到宏观,对Redis有一个初步的了解。
事实上,Redis内部要处理的问题还有很多:
官网:
书籍(可以参考):