当前位置：首页 > 资讯 > 技术文档

超强、超详细Redis数据库入门教程

时间：2021-04-30 02:21 编辑：来源：阅读：
扫一扫，手机访问

摘要：超强、超详细Redis数据库入门教程

[b]【本教程目录】[/b] 1.redis是什么 2.redis的作者何许人也 3.谁在使用redis 4.学会安装redis 5.学会启动redis 6.使用redis客户端 7.redis数据结构 – 简介 8.redis数据结构 – strings 9.redis数据结构 – lists 10.redis数据结构 – 集合 11.redis数据结构 – 有序集合 12.redis数据结构 – 哈希 13.聊聊redis持久化 – 两种方式 14.聊聊redis持久化 – RDB 15.聊聊redis持久化 – AOF 16.聊聊redis持久化 – AOF重写 17.聊聊redis持久化 – 如何选择RDB和AOF 18.聊聊主从 – 用法 19.聊聊主从 – 同步原理 20.聊聊redis的事务处理 21.教你看懂redis配置 – 简介 22.教你看懂redis配置 -通用 23.教你看懂redis配置 – 快照 24.教你看懂redis配置 – 复制 25.教你看懂redis配置 – 安全 26.教你看懂redis配置 -限制 27.教你看懂redis配置 – 追加模式 28.教你看懂redis配置 – LUA脚本 29.教你看懂redis配置 – 慢日志 30.教你看懂redis配置 – 事件通知 31.教你看懂redis配置 – 高级配置 [b]【redis是什么】[/b] redis是一个开源的、使用C语言编写的、支持网络交互的、可基于内存也可持久化的Key-Value数据库。 redis的官网地址，非常好记，是redis.io。（特意查了一下，域名后缀io属于国家域名，是british Indian Ocean territory，即英属印度洋领地）目前，Vmware在资助着redis项目的开发和维护。 [b]【redis的作者何许人也】[/b] 开门见山，先看照片： [img]http://img.1sucai.cn/uploads/article/2018010709/20180107090136_0_99826.jpg[/img] 是不是出乎了你的意料，嗯，高手总会有些地方与众不同的。这位便是redis的作者，他叫Salvatore Sanfilippo，来自意大利的西西里岛，现在居住在卡塔尼亚。目前供职于Pivotal公司。他使用的网名是antirez，如果你有兴趣，可以去他的博客逛逛，地址是antirez.com，当然也可以去follow他的github，地址是[url=http://github.com/antirez]http://github.com/antirez[/url]。 [b]【谁在使用redis】[/b] Blizzard、digg、stackoverflow、github、flickr … [b]【学会安装redis】[/b] 从redis.io下载最新版redis-X.Y.Z.tar.gz后解压，然后进入redis-X.Y.Z文件夹后直接make即可，安装非常简单。 make成功后会在src文件夹下产生一些二进制可执行文件，包括redis-server、redis-cli等等：

[url=http://redis.io/commands#hash]查询[/url]。 [b]【聊聊redis持久化 – 两种方式】[/b] redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。 RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上； AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。 [b]【聊聊redis持久化 – RDB】[/b] RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。 redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。 [b]【聊聊redis持久化 – AOF】[/b] AOF，英文是Append Only File，即只允许追加不允许改写的文件。如前面介绍的，AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性，这点大家可以放心。 AOF方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作redis时，不小心执行了FLUSHALL，导致redis内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，然后重启redis，就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇，这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了，那就无法通过这种方法来恢复数据了。虽然优点多多，但AOF方式也同样存在缺陷，比如在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。如果你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。如果运气比较差，AOF文件出现了被写坏的情况，也不必过分担忧，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时可以通过以下步骤来修复出错的文件： 1.备份被写坏的AOF文件 2.运行redis-check-aof –fix进行修复 3.用diff -u来看下两个文件的差异，确认问题点 4.重启redis，加载修复后的AOF文件 [b]【聊聊redis持久化 – AOF重写】[/b] AOF重写的内部运行原理，我们有必要了解一下。在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。 [b]【聊聊redis持久化 – 如何选择RDB和AOF】[/b] 对于我们应该选择RDB还是AOF，官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。 [b]【聊聊主从 – 用法】[/b] 像MySQL一样，redis是支持主从同步的，而且也支持一主多从以及多级从结构。主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的SORT就可以由从服务器来承担。 redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。但是从服务器仍然可以接受CONFIG等指令，所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此，那可以考虑给重要指令进行重命名，来避免命令被外人误执行。 [b]【聊聊主从 – 同步原理】[/b] 从服务器会向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存在内存中。在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。另外，要说的一点是，即使有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，然后把持久化好的RDB文件发给多个下游。在redis2.8版本之前，如果从服务器与主服务器因某些原因断开连接的话，都会进行一次主从之间的全量的数据同步；而在2.8版本之后，redis支持了效率更高的增量同步策略，这大大降低了连接断开的恢复成本。主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后，从服务器会尝试再次与主服务器连接，一旦连接成功，从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置（replication offset）”发送出去。主服务器接收到这样的同步请求后，首先会验证主服务器ID是否和自己的ID匹配，其次会检查“请求的偏移位置”是否存在于自己的缓冲区中，如果两者都满足的话，主服务器就会向从服务器发送增量内容。增量同步功能，需要服务器端支持全新的PSYNC指令。这个指令，只有在redis-2.8之后才具有。 [b]【聊聊redis的事务处理】[/b] 众所周知，事务是指“一个完整的动作，要么全部执行，要么什么也没有做”。在聊redis事务处理之前，要先和大家介绍四个redis指令，即MULTI、EXEC、DISCARD、WATCH。这四个指令构成了redis事务处理的基础。 1.MULTI用来组装一个事务； 2.EXEC用来执行一个事务； 3.DISCARD用来取消一个事务； 4.WATCH用来监视一些key，一旦这些key在事务执行之前被改变，则取消事务的执行。纸上得来终觉浅，我们来看一个MULTI和EXEC的例子：

[url=http://redis.io/topics/persistence]本文[/url]。

[url=http://antirez.com/post/redis-persistence-demystified.html]本文[/url]。

[url=http://redis.io/topics/keyspace-events]本文[/url]。 [b]【教你看懂redis配置 – 高级配置】[/b] 有关哈希数据结构的一些配置项：

[u]复制代码[/u] 代码如下:

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

有关列表数据结构的一些配置项：

[u]复制代码[/u] 代码如下:

list-max-ziplist-entries 512

list-max-ziplist-value 64

有关集合数据结构的配置项：

[u]复制代码[/u] 代码如下:

set-max-intset-entries 512

有关有序集合数据结构的配置项：

[u]复制代码[/u] 代码如下:

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

关于是否需要再哈希的配置项：

[u]复制代码[/u] 代码如下:

activerehashing yes

关于客户端输出缓冲的控制项：

[u]复制代码[/u] 代码如下:

client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60

有关频率的配置项：

[u]复制代码[/u] 代码如下:

hz 10

有关重写aof的配置项

[u]复制代码[/u] 代码如下:

aof-rewrite-incremental-fsync yes

至此，redis的入门内容就结束了，内容实在不少，但相对来说都很基础，本文没有涉及redis集群、redis工作原理、redis源码、redis相关LIB库等内容，后续会陆续奉献，大家敬请期待：）谢谢！

全部评论(0)

上一篇：win10下使用virtualbox + vagrant配置ruby开发机环境
下一篇：详解redis数据结构之压缩列表

资讯排行榜
更多>>

联系客服

客服电话：
400-000-3129

微信版

扫一扫进微信版

返回顶部