- Redis是一种基于键值对(key-value)的NoSQL数据库。
- 与很多键值对数据库不同的是,Redis中的值可以是由string(字符串)、hash(哈希)、list(列表)、set(集合)、zset(有序集合)、Bitmaps(位图)、HyperLogLog、GEO(地理信息定位)等多种数据结构和算法组成,因此Redis可以满足很多的应用场景。
- Redis会将所有数据都存放在内存中,所以它的读写性能非常惊人。Redis可以利用快照和日志将内存中的数据保存到硬盘上,这样在发生类似断电或者机器故障的时候,内存中的数据不会“丢失”。
- Redis还提供了键过期、发布订阅、事务、流水线、Lua脚本等附加功能。
1、Redis特性
1、速度快
- 正常情况下,Redis执行命令的速度非常快,官方给出的数字是读写性能可以达到10万/秒,当然这也取决于机器的性能,但这里先不讨论机器性能上的差异,只分析一下是什么造就了Redis除此之快的速度,可以大致归纳为以下四点:
- Redis的所有数据都是存放在内存中的,表1-1是谷歌公司2009年给出的各层级硬件执行速度,所以把数据放在内存中是Redis速度快的最主要原因。
- Redis是用C语言实现的,一般来说C语言实现的程序“距离”操作系统更近,执行速度相对会更快。
- Redis使用了单线程架构,预防了多线程可能产生的竞争问题。
- 作者对于Redis源代码可以说是精打细磨,曾经有人评价Redis是少有的集性能和优雅于一身的开源代码。
![](https://img2022.cnblogs.com/blog/2270526/202208/2270526-20220803203327249-1264914457.png)
2、基于键值对的数据结构服务器
- 几乎所有的编程语言都提供了类似字典的功能,例如Java里的map、Python里的dict,类似于这种组织数据的方式叫作基于键值的方式,与很多键值对数据库不同的是,Redis中的值不仅可以是字符串,而且还可以是具体的数据结构,这样不仅能便于在许多应用场景的开发,同时也能够提高开发效率。
- Redis是REmote DIctionary Server(远程字典服务器)的缩写,它以字典结构存储数据,并允许其他应用通过TCP协议读写字典中的内容。
- 到目前为止,Redis支持的五种键值数据类型如下:
- string(字符串)
- hash(哈希)
- list(列表)
- set(集合)
- zset(有序集合)
- 在字符串的基础之上演变出了Bitmaps(位图)和HyperLogLog两种神奇的“数据结构”,并且随着LBS(Location Based Service,基于位置服务)的不断发展,Redis3.2版本中加入有关GEO(地理信息定位)的功能。
3、丰富的功能
- 除了5种数据结构,Redis还提供了许多额外的功能:
- 提供了键过期功能,可以用来实现缓存。(为每个键设置生存时间(Time To Live,TTL))
- 提供了发布订阅功能,可以用来实现消息系统。
- 支持Lua脚本功能,可以利用Lua创造出新的Redis命令。
- 提供了简单的事务功能,能在一定程度上保证事务特性。
- 提供了流水线(Pipeline)功能,这样客户端能将一批命令一次性传到Redis,减少了网络的开销。
- 关于Redis和Memcached优劣的讨论一直是一个热门的话题。
- 在性能上Redis是单线程模型,而Memcached支持多线程,所以在多核服务器上后者的性能理论上相对更高一些。然而,前面已经介绍过,Redis的性能已经足够优异,在绝大部分场合下其性能都不会成为瓶颈,所以在使用时更应该关心的是二者在功能上的区别。
- 随着Redis3.0的推出,Memcached几乎所有功能都成为了Redis的子集。
- 同时,Redis对集群的支持使得Memcached原有的第三方集群工具不再成为优势。
- 因此,在新项目中使用Redis代替Memcached将会是非常好的选择。
- 作为缓存系统,Redis还可以限定数据占用的最大内存空间,在数据达到空间限制后可以按照一定的规则自动淘汰不需要的键。
- Redis的列表类型键可以用来实现队列,并且支持阻塞式读取,可以很容易地实现一个高性能的优先级队列。同时在更高层面上,Redis还支持“发布/订阅”的消息模式,可以基于此构建聊天室等系统。
4、简单稳定
- Redis的简单主要表现在三个方面:
- (1)Redis的源码很少,早期版本的代码只有2万行左右,3.0版本以后由于添加了集群特性,代码增至5万行左右,相对于很多NoSQL数据库来说代码量相对要少很多,也就意味着普通的开发和运维人员完全可以“吃透”它。
- (2)Redis使用单线程模型,这样不仅使得Redis服务端处理模型变得简单,而且也使得客户端开发变得简单。
- (3)Redis不需要依赖于操作系统中的类库(例如Memcache需要依赖libevent这样的系统类库),Redis自己实现了事件处理的相关功能。
- Redis虽然很简单,但是不代表它不稳定。以笔者维护的上千个Redis为例,没有出现过因为Redis自身bug而宕掉的情况。
5、客户端语言多
- Redis提供了简单的TCP通信协议,很多编程语言可以很方便地连接到Redis,并且由于Redis受到社区和各大公司的广泛认可,所以支持Redis的客户端语言也非常多,几乎涵盖了主流的编程语言,例如Java、PHP、Python、C、C++、Nodejs等[1]。
6、持久化
- 通常看,将数据放在内存中是不安全的,一旦发生断电或者机器故障,重要的数据可能就会丢失,因此Redis提供了两种持久化方式:RDB和AOF,即可以用两种策略将内存的数据保存到硬盘中(如图1-1所示),这样就保证了数据的可持久性。
![](https://img2022.cnblogs.com/blog/2270526/202208/2270526-20220803210102838-677949337.png)
7、主从复制
- Redis提供了复制功能,实现了多个相同数据的Redis副本(如图1-2所示),复制功能是分布式Redis的基础。
![](https://img2022.cnblogs.com/blog/2270526/202208/2270526-20220803210532957-1044796442.png)
8、高可用和分布式
- Redis从2.8版本正式提供了高可用实现Redis Sentinel,它能够保证Redis节点的故障发现和故障自动转移。
- Redis从3.0版本正式提供了分布式实现Redis Cluster,它是Redis真正的分布式实现,提供了高可用、读写和容量的扩展性。
2、Redis使用场景
2.1、Redis可以做什么
1、缓存
- 缓存机制几乎在所有的大型网站都有使用,合理地使用缓存不仅可以加快数据的访问速度,而且能够有效地降低后端数据源的压力。Redis提供了键值过期时间设置,并且也提供了灵活控制最大内存和内存溢出后的淘汰策略。可以这么说,一个合理的缓存设计能够为一个网站的稳定保驾护航。
2、排行榜系统
- 排行榜系统几乎存在于所有的网站,例如按照热度排名的排行榜,按照发布时间的排行榜,按照各种复杂维度计算出的排行榜,Redis提供了列表和有序集合数据结构,合理地使用这些数据结构可以很方便地构建各种排行榜系统。
3、计数器应用
- 计数器在网站中的作用至关重要,例如视频网站有播放数、电商网站有浏览数,为了保证数据的实时性,每一次播放和浏览都要做加1的操作,如果并发量很大对于传统关系型数据的性能是一种挑战。Redis天然支持计数功能而且计数的性能也非常好,可以说是计数器系统的重要选择。
4、社交网络
- 赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能,由于社交网站访问量通常比较大,而且传统的关系型数据不太适合保存这种类型的数据,Redis提供的数据结构可以相对比较容易地实现这些功能。
5、消息队列系统
- 消息队列系统可以说是一个大型网站的必备基础组件,因为其具有业务解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功能,虽然和专业的消息队列比还不够足够强大,但是对于一般的消息队列功能基本可以满足。
2.2、Redis不可以做什么
- 每个技术都有自己的应用场景和边界,也就是说Redis并不是万金油,有很多适合它解决的问题,但是也有很多不合适它解决的问题。
- 可以站在数据规模和数据冷热的角度来进行分析。
- 站在数据规模的角度看,数据可以分为大规模数据和小规模数据,我们知道Redis的数据是存放在内存中的,虽然现在内存已经足够便宜,但是如果数据量非常大,例如每天有几亿的用户行为数据,使用Redis来存储的话,基本上是个无底洞,经济成本相当的高。
- 站在数据冷热的角度看,数据分为热数据和冷数据,热数据通常是指需要频繁操作的数据,反之为冷数据,例如对于视频网站来说,视频基本信息基本上在各个业务线都是经常要操作的数据,而用户的观看记录不一定是经常需要访问的数据,这里暂且不讨论两者数据规模的差异,单纯站在数据冷热的角度上看,视频信息属于热数据,用户观看记录属于冷数据。如果将这些冷数据放在Redis中,基本上是对于内存的一种浪费,但是对于一些热数据可以放在Redis中加速读写,也可以减轻后端存储的负载,可以说是事半功倍。
3、对使用Redis的建议
1、切勿当作黑盒使用,开发与运维同样重要
- 很多使用Redis的开发者认为只要会用API开发相应的功能就可以,更有甚者认为Redis就是get、set、del,不需要知道Redis的原理。但是在我们实际运维和使用Redis的过程中发现,很多线上的故障和问题都是由于完全把Redis当做黑盒造成的。
- 如果不了解Redis的单线程模型,有些开发者会在有上千万个键的Redis上执行keys*操作。
- 如果不了解持久化的相关原理,会在一个写操作量很大的Redis上配置自动保存RDB。
- 而且在很多公司内只有专职的关系型数据库DBA,并没有NoSQL的相关运维人员,也就是说开发者很有可能会自己运维Redis,对于Redis的开发者来说既是好事又是坏事。
- 站在好的方面看,开发人员可以通过运维Redis真正了解Redis的一些原理,不单纯停留在开发上。
- 站在坏的方面看,Redis的开发人员不仅要支持开发,还要承担运维的责任,而且由于运维经验不足可能会造成线上故障。
- 但是从实际经验来看,运维足够规模的Redis会对用好Redis更加有帮助。
2、阅读源码
- 我们在前面提到过,Redis是开源项目,由于作者对Redis代码的极致追求,Redis的代码量相对于许多NoSQL数据库来说是非常小的,也就意味着作为普通的开发和运维人员也是可以“吃透”Redis的。
- 通过阅读优秀的源码,不仅能够加深我们对于Redis的理解,而且还能提高自身的编码水平,甚至可以对Redis做定制化,也就是说可以修改Redis的源码来满足自身的需求,例如新浪微博在Redis的早期版本上做了很多的定制化来满足自身的需求,豌豆荚也开源基于Proxy的Redis分布式实现Codis。
4、多数据库
- Redis是一个字典结构的存储服务器,而实际上一个Redis实例提供了多个用来存储数据的字典,客户端可以指定将数据存储在哪个字典中。这和关系数据库实例中可以创建多个数据库类似,所以可以将一个redis实例中的每个字典都理解成一个独立的数据库。
- 一个Redis实例默认支持16个数据库,且16个数据库的名字是从0开始递增的一个数字。可以通过配置参数databases来修改默认的数据库个数。客户端与Redis建立连接后会自动选择0号数据库,不过可以随时使用SELECT命令更换数据库,如要选择1号数据库:
10.1.1.11:6379> select 1
OK
10.1.1.11:6379[1]> get foo
(nil)
- 然而这些以数字命名的数据库又与我们理解的数据库有所区别。
- Redis不支持自定义数据库的名字,每个数据库都以编号命名,开发者必须自己记录哪些数据库存储了哪些数据。
- Redis不支持为每个数据库设置不同的访问密码,所以一个客户端要么可以访问全部数据库,要么所有的数据库都没有权限访问。
- redis的多个数据库之间并不是完全隔离的,比如FLUSHALL命令可以清空一个Redis实例中所有数据库中的数据。
- 综上所述,这些数据库更像是一种命名空间,而不适宜存储不同应用程序的数据。比如可以使用0号数据库存储某个应用生产环境中的数据,使用1号数据库存储测试环境中的数据,但不适宜使用0号数据库存储A应用的数据而使用1号数据库存储B应用的数据,不同的应用应该使用不同的Redis实例存储数据。
- 由于Redis非常轻量级,一个空Redis实例占用的内存只有1MB左右,所以不用担心多个Redis实例会额外占用很多内存。