• Redis 复制

    Redis 复制特点

    随着业务增长,负载增加,水平扩展是各个形式数据库必须具备的基本能力,Redis当然也是。 Redis 和 大多数据库一样,支持复制,Redis的复制具有以下特性:

    1. Redis 使用异步复制。 从 Redis 2.8 开始, 从服务器会以每秒一次的频率向主服务器报告复制流(replication stream)的处理进度。

    2. 一个主服务器可以有多个从服务器。不仅主服务器可以有从服务器, 从服务器也可以有自己的从服务器, 多个从服务器之间可以构成一个图状结构。

    3. 复制功能不会阻塞主服务器: 即使有一个或多个从服务器正在进行初次同步, 主服务器也可以继续处理命令请求。后面我们会讲到原因。

    4. 复制功能也不会阻塞从服务器: 只要在 redis.conf 文件中进行了相应的设置, 即使从服务器正在进行初次同步, 服务器也可以使用旧版本的数据集来处理命令查询。不过, 在从服务器删除旧版本数据集并载入新版本数据集的那段时间内, 连接请求会被阻塞。你还可以配置从服务器, 让它在与主服务器之间的连接断开时, 向客户端发送一个错误。

    5. 复制功能可以单纯地用于数据冗余(data redundancy), 也可以通过让多个从服务器处理只读命令请求来提升扩展性(scalability): 比如说, 繁重的 SORT 命令可以交给附属节点去运行。

    6. 可以通过复制功能来让主服务器免于执行持久化操作: 只要关闭主服务器的持久化功能, 然后由从服务器去执行持久化操作即可。

     

    Redis 复制原理

    步骤 主服务器操作 从服务器操作
    1 (等待从服务器命令) 第一次连接(或者重连接)主服务器,发送SYNC命令。
    2 开始执行BGSAVE,并使用缓冲区记录BGSAVE之后的所有写操作。 根据配置选项来决定是继续使用现有的数据(如果有的话)还是向发送请求的客户端返回错误。
    3 BGSAVE执行完毕,向从服务器发送快照文件,并在发送期间继续使用缓冲区记录被执行的写操作。 丢弃所有旧数据(如果有的话),开始载入主服务器发来的快照文件。
    4 快照文件发送完毕,开始向从服务器发送缓冲区里记录的写操作。 完成对快照文件的解释操作,像往常一样开始接受命令请求。
    5 缓冲区存储的命令发送完毕,从现在开始,每执行一个写命令,就向从服务器发送相同的写命令。 执行主服务器发来的所有存储在缓冲区里的写命令,从现在开始,接受并执行主服务器传来的写命令。

    如上表所示(摘自《redis实战》),很清晰的阐述了Redis的复制原理,但是我也发现几个不是很确定的问题:

    1. 在第二步中,执行BGSAVE时,它将新来的写请求都写入到缓冲中,如果这时候也内存本来就不怎么够用了,而且当时的写请求很大的话,那么是否会对Redis性能造成冲击?

    2. 在第三步中,从服务器是完整的接收完整个RDB文件以后再开始替换,还是一边接受一边开始替换呢 ? 因为这涉及到一个主从复制之间的配置问题,如果带宽不是很富裕,那么RDB文件的传输需要一定时间,在此期间如果网络抖动怎么办呢?

    3. 在整个2、3、4 、5 步骤过程中,从库是可用的吗 ?

    基于上面几个问题,我简单翻阅了Redis的官方文档,发现并没有特别详细的解述,于是就想到阅读源码,但一想到之前参阅MySQL源码时的痛苦,就觉得此路艰难。于是先在网上查看了一下,发现相比之下,Redis的源码没有MySQL那么庞杂,当然也是因为它的功能和实现逻辑相对MySQL来说比较简单。 并且网上有很多比较牛逼的大神已经有了阅读的经验,甚至很多都给出了中文注解,这样看起来会方便很多。

    鉴于之前尝试阅读MySQL源码的经验,我想以调试的方式入手Redis:

    终端1 执行下面步骤,准备好redis环境供调试使用:

    经过如上步骤后,我们就可以再另外起一个终端进行redis调试了,如下,我们直接新开一个终端2 ,开启我们的gdb调试之旅:

    1. 在终端2 启动gdb调试,并且设置断点到slaveofCommand函数:

    %e5%b1%8f%e5%b9%95%e5%bf%ab%e7%85%a7-2017-02-20-%e4%b8%8b%e5%8d%887-09-32

    2. 在终端1 执行slaveof命令,他会自动阻塞住:

    %e5%b1%8f%e5%b9%95%e5%bf%ab%e7%85%a7-2017-02-20-%e4%b8%8b%e5%8d%887-11-05

    3. 在终端2 用 gdb调试终端执行 continue命令,他就会自动停止到我们的目标断点函数处:

    %e5%b1%8f%e5%b9%95%e5%bf%ab%e7%85%a7-2017-02-20-%e4%b8%8b%e5%8d%887-12-59

    如上,我们的调试就停止到了我们的目标函数slaveofCommand处了,接下来就可以用 n(next)或者 s(step)进行代码浏览了。我们也可以根据提示找到对应的函数在replication.c 文件的 1776行。


    到此为止,我们就可以使用调试技术入手redis的代码了,接下来具体的代码阅读就不讲了,直接理出我梳理的结果(此部分内容结合网上资源

    Redis 复制时有一个 repl_state 变量的标识,Redis 根据此变量的状态对应的做出相应的处理步骤,我们可以在server.h 里面找到这些复制状态的定义。

    %e5%b1%8f%e5%b9%95%e5%bf%ab%e7%85%a7-2017-02-21-%e4%b8%8a%e5%8d%8810-52-23

    那么这些状态是如何进行转换的呢? 又是由哪些函数操作进行的呢 ? 我们一步一步来看(以下内容均参考自redis复制实现原理

    1. 处理 slaveof 命令,repl_state状态转换为 REPL_STATE_CONNECT

    yy

    图片摘自—— https://toutiao.io/posts/aryalv/preview



    至此,复制标识状态就为:  REPL_STATE_NONE   —>  REPL_STATE_CONNECT  。

    2. replicationCron 定时检测复制状态,当它一旦发现 repl_state 变成了REPL_STATE_CONNECT状态时,则开始连接新的Master,并发起复制请求。

    至此,复制标识状态就为REPL_STATE_CONNECT —> REPL_STATE_CONNECTING : 

    3. 上面我们也有说到,在connectWithMaster函数中将与Master连接的socket的fd注册对应的时间处理器为syncWithMaster,syncWithMaster主要实现了当前实例和master之间的握手协议,核心是赋值状态迁移,我们可以用下面一张图表示:

    yy

    图片摘自—— https://toutiao.io/posts/aryalv/preview

     

    如上,本实例会发送一个”PSYNC” command 给 master 端,然后打开一个临时文件用于接收接下来master发过来的 rdb 文件数据。再添加一个文件事件注册 readSyncBulkPayload 函数,这个就是接下来用于接收rdb文件的数据的函数,然后修改状态为 REDIS_REPL_TRANSFER。

    至此,复制标识状态就为 REPL_STATE_CONNECTING —> REPL_STATE_TRANSFER 。

    4. 我们已经知道slave是怎么同master建立连接,怎么和master进行握手的了,那么master那边是什么情况呢,master在与slave握手之后,对于psync命令处理的秘密都在syncCommand方法里面,syncCommand方法实际包括两个命令处理的实现,一个是sync(2.8版本以前),一个是psync(2.8版本以后,支持部分同步),我们来看看:

    5. 然后,master 的主线程的 serverCron 会检查这个持久化的子进程是否退出,如果bgsave子进程正常退出,会调用backgroundSaveDoneHandler函数继续复制的工作,针对不同的复制方式又分为如下两种情况:

    —— RDB disk方式:

    对于RDB disk复制方式,则注册sendBulkToSlav函数开始处理发送RDB文件给slave :

    然后RDB的文件发送由sendBulkToSlave处理器来完成,master对于RDB文件发送完毕之后会把slave的状态设置为:ONLINE。这里需要注意的是,在把slave设置为online状态之后会注册写处理器,将堆积在reply的数据发送给slave:

    这部分的内容即为RDB文件开始备份到发送给slave结束这段时间的增量数据,因此需要注册I/O事件处理器,将这段时间累积的内容发送给slave,最终保持数据一致。

    —— diskless方式:

    diskless方式的后处理不同的是当子进程结束的时候,其实RDB文件已经传输完成了,而且其中做了些事情:

    • 当slave通过接受完RDB文件之后发送一个REPLCONF ACK给master。
    • master接收到slave的REPLCONF ACK之后,开始将缓存的增量数据发送给slave。

    因此这里不会注册sendBulkToSlave处理器,只需要将slave状态设置为ONLINE即可。我们还可以发现不同的一点,对于累积部分的数据处理,RDB disk方式是由master主动发送给slave的,而对于diskless方式,master收到slave的REPLCONF ACK之后才会将累积的数据发送出去,这点有些不同。


    6. 我们回到slave,上面讲到slave将复制状态更新为 REDIS_REPL_TRANSFER , 通过readSyncBulkPayload接收rob数据,我们来具体看一看:

    如上,接收完整个rdb文件后,会清空整个数据库emptyDb()。然后就通过rdbLoad函数装载接收到的rdb文件,于是slave和master数据就一致了,然后把状态修改为REDIS_REPL_CONNECTED。 接下来就是master和slave之间增量的传递的增量数据,另外slave和master在应用层有心跳检测和超时退出。


    至此,Slave的一次slaveof命令之旅就结束了,现在我们再回过头来看当初的问题:

    问题一: 执行BGSAVE的时候会将写操作命令记入缓冲区,如果在并发很高的情况下,或者内存比较紧张的情况下是否会对Redis 性能造成较大的冲击 ?

    答: 会,如果Redis主从服务器之间的网络带宽不足,或者主服务器没有足够的内存来创建子进程和创建记录写操作的缓冲区,那么Redis处理命令就会受到影响。因此,尽管这并不是必须的,但在实际中最好还是让主服务器只使用50% — 65% 的内存,留下的用于执行BGSAVE命令和创建记录写命令的缓冲区。

    问题二: 从服务器是如何接受RDB文件的,是一边接受一边替换还是先接受后替换 ?

    答:先接受后替换,从上面源码解析的过程中,我们知道slave是将自己的状态设置为REPL_STATE_TRANSFER后,向Master发送PSYNC命令,然后等Master将RDB文件传输完后,再将自己的数据库清除掉,将新的RDB文件导入。

    问题三: 在整个开始执行slaveof命令到接收完RDB文件,slave是可提供服务器的吗 ?

    答: 不可以,由上面的源码分析可知,早在slaveofCommand函数里面它就断开了所有的客户端链接,直到接收完RDB,并应用且补齐缓存日志后,才重新开始提供服务。


    参考:

    https://toutiao.io/posts/aryalv/preview

    https://github.com/redisbook/book/blob/master/redis-replication.md

    https://github.com/huangz1990/redis-3.0-annotated/blob/unstable/src/replication.c

     

  • Redis持久化

    背景

    Redis有两种持久化的方式:快照(RDB文件)和追加式文件(AOF文件)。

    • RDB持久化方式会在一个特定的间隔保存那个时间点的一个数据快照。这个功能可以将Redis在内存中的的状态保存到硬盘中,它可以手动执行,也可以在 redis.conf 中配置,定期执行。RDB持久化产生的RDB文件是一个经过压缩的二进制文件,这个文件被保存在硬盘中,redis可以通过这个文件还原数据库当时的状态。
    • AOF持久化方式则会记录每一个服务器收到的写操作。在服务启动时,这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致,以追加的方式进行保存。

    注1 : Redis的持久化是可以禁用的,就是说你可以让数据的生命周期只存在于服务器的运行时间里。

    注2 : 两种方式的持久化是可以同时存在的,但是当Redis重启时,AOF文件会被优先用于重建数据。

     

    快照持久化数据

    Redis 可以通过创建快照来获得存储在内存里的数据再某个时间点的副本。在创建快照之后,用户可以对快照进行备份,可以将快照复制到其他机器做冷备,也可以将快照留在原地以便重启服务器时使用。

    1. RDB的创建与载入

    手动的RDB文件以通过两个命令来生成:

    • SAVE:接到SAVE命令的 Redis服务器在快照创建完毕之前将不会再响应任何其他命令。它会 阻塞redis的服务器进程,直到RDB文件被创建完毕。SAVE命令不常用,通常只有在没有足够的内存去执行BGSAVE的情况下才会使用。
    • BGSAVE:派生(fork)一个子进程来创建新的RDB文件,记录接收到BGSAVE当时的数据库状态,父进程继续处理接收到的命令,子进程完成文件的创建之后,当子进程写完新的RDB文件后,把旧的RDB文件替换掉。并且发送信号给父进程,而与此同时,父进程处理命令的同时,通过轮询来接收子进程的信号。

    自动的RDB文件的生成:

    我们也可以在redis的配置文件中以如下的方式进行自动的保存间隔,从Redis最近一次创建快照之后开始算起,只要有一个条件被满足,服务器就会执行BGSAVE命令。

    注 1: 当Redis 通过SHUTDOWN命令或者接收到标准的TERM信号时,会执行一个SAVE命令,阻塞所有客户端,不再执行客户端发送的任何命令,并在SAVE命令执行完毕后关闭Redis服务器。

    注 2: 根据配置,快照将被写入dbfilename选项指定的文件里面,并存储在dir选项指定的路径上面。如果在新的快照文件创建完毕之前,Redis、硬件、或者系统这三者之中的任意一个崩溃了,那么Redis 将丢失最近一次创建快照之后写入的所有数据。

    注3: 当一个从Redis服务器向主服务器发送SYNC命令来开始一次复制操作的时候,如果主服务器目前没有在执行BGSAVE操作,或者主服务器并非刚刚执行完BGSAVE操作,那么主服务器就会执行BGSAVE。

    当Redis 存储的数据量只有几个GB的时候,使用快照来保存数据是没有问题的。 Redis 会创建子进程并将数据保存在硬盘里,生成快照所需的时间比你读这句话的时间还短。

    但随着Redis 占用的内存越来越多,BGSAVE在创建子进程时消耗的时间也会越来越多。如果Redis的内存占用量达到数十个GB,并且剩余的内存并不多,或者Redis运行在虚拟机上,那么执行BGSAVE可能会导致系统长时间的停顿,也可能引发系统大量使用虚拟内存,从而导致Redis性能严重下降。

    执行BGSAVE而导致的停顿或对系统的冲击有多大,这取决于Redis所在系统的配置。  那么有没有个大概呢?  这个影响的因素太多,我在读到》《Redis 实战》一书的时候作者有如下举例:

    有一台拥有68GB内存的Xen虚拟机上,对一个占用50G内存的Redis服务器执行 BGSAVE 命令的话,光是创建子进程就需要花费15秒以上,而生成快照则需要15 – 20分钟; 但是用SAVE只需要3 – 5 分钟即可完成。因为应用程序只需要一天一次快照,所以可以采用在夜间程序执行SAVE并保存RDB文件的方式持久化。

    2. 快照持久化的错误

    默认情况下,如果Redis在后台生成快照的时候失败,那么就会停止接收数据,目的是让用户能知道数据没有持久化成功。但是如果你有其他的方式可以监控到Redis及其持久化的状态,那么可以把这个功能禁止掉。

    3. 快照时的数据压缩

    默认Redis会采用LZF对数据进行压缩。如果你想节省点CPU的性能,你可以把压缩功能禁用掉,但是数据集就会比没压缩的时候要打。

    4. 数据校验

    从版本5的RDB的开始,一个CRC64的校验码会放在文件的末尾。这样更能保证文件的完整性,但是在保存或者加载文件时会损失一定的性能(大概10%)。如果想追求更高的性能,可以把它禁用掉,这样文件在写入校验码时会用0替代,加载的时候看到0就会直接跳过校验。

    AOF 持久化

    对于很多应用程序来说,哪怕丢失很短时间的Redis数据都是难以接受的,在这种情况下可能快照持久化并不能很好的保证数据安全性了,我们可以使用AOF的方式就行持久化。AOF持久化的方式很简单,每当Redis接受到会修改数据集的命令时,就会把命令追加到AOF文件里,当你重启Redis时,AOF里的命令会被重新执行一次,重建数据。

    1. AOF 持久化的优点
    • 可以制定不同的写磁盘fsync策略:不进行fsync依赖操作系统自己刷新磁盘、每秒fsync一次和每次写操作进行fsync。默认是每秒fsync一次。这意味着你最多丢失一秒钟的数据。这个和MySQL数据库里面的双1参数很类似。
    • AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况,也不会出现日志的定位或者损坏问题。甚至如果因为某些原因(例如磁盘满了)命令只写了一半到日志文件里,我们也可以用redis-check-aof这个工具很简单的进行修复。
    • 当AOF文件太大时,Redis会自动在后台进行重写。重写很安全,因为重写是在一个新的文件上进行,同时Redis会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。当新文件重写完,Redis会把新旧文件进行切换,然后开始把数据写到新文件上。
    • AOF把操作命令以简单易懂的格式一条接一条的保存在文件里,很容易导出来用于恢复数据。例如我们不小心用FLUSHALL命令把所有数据刷掉了,只要文件没有被重写,我们可以把服务停掉,把最后那条命令删掉,然后重启服务,这样就能把被刷掉的数据恢复回来。
    2. AOF 持久化的缺点
    • 在相同的数据集下,AOF文件的大小一般会比RDB文件大。
    • 在某些fsync策略下,AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能,而在禁止fsync的情况下速度可以达到RDB的水平。
    3. AOF 持久化配置

    启动AOF

    AOF文件的路径和名称

    AOF 文件的刷新频率

    4. AOF 文件重写

    随着写操作的不断增加,AOF文件会越来越大。例如你递增一个计数器100次,那么最终结果就是数据集里的计数器的值为最终的递增结果,但是AOF文件里却会把这100次操作完整的记录下来。而事实上要恢复这个记录,只需要1个命令就行了,也就是说AOF文件里那100条命令其实可以精简为1条。所以Redis支持这样一个功能:在不中断服务的情况下在后台重建AOF文件。

    工作原理如下:

    • Redis调用fork(),产生一个子进程。
    • 子进程把新的AOF写到一个临时文件里。
    • 主进程持续把新的变动写到内存里的buffer,同时也会把这些新的变动写到旧的AOF里,这样即使重写失败也能保证数据的安全。
    • 当子进程完成文件的重写后,主进程会获得一个信号,然后把内存里的buffer追加到子进程生成的那个新AOF里。

    我们可以通过配置设置日志重写的条件:

    要禁用自动的日志重写功能,我们可以把百分比设置为0:

    5. AOF 文件损坏修复

    如果因为某些原因(例如服务器崩溃)AOF文件损坏了,导致Redis加载不了,可以通过以下方式进行修复:

    • 备份AOF文件。
    • 使用redis-check-aof命令修复原始的AOF文件:
    • 可以使用diff -u命令看下两个文件的差异。
    • 使用修复过的文件重启Redis服务。
    6. 从RDB持久化方式切换到 AOF
    • 备份一个最新的dump.rdb的文件,并把备份文件放在一个安全的地方。
    • 运行以下命令: $ redis-cli config set appendonly yes

    备份修复与故障处理

    无论是快照持久化还是AOF持久化,都可能遇到系统故障,需要数据恢复的时候。Redis 提供了两个命令行程序用于检查RDB文件和AOF文件的状态是否可用:

    $ ./redis-check-aof

    Usage: ./redis-check-aof [–fix] <file.aof>

    $ ./redis-check-rdb

    Usage: ./redis-check-rdb <rdb-file-name>

    如果用户在运行redis-check-aof 程序时给定–fix参数,那么程序将对AOF文件进行修复。程序修复AOF文件的方法很简单,当发现第一个出错命令的时候,就删除出错的命令及其后面的所有命令,只保留那些位于出错之前的命令,在大多数情况下,被删除的都是AOF文件末尾的不完整的写命令。

    不过RDB快照文件目前没有可以修复的方法。

     

    参考

    —— 《Redis实战》

    https://segmentfault.com/a/1190000002906345

     

  • Redis安装配置

    背景

    Redis是一个远程内存数据库,它不仅性能强劲,而且还具有复制特性以及为解决问题而生的独一无二的数据模型。Redis提供了五种不同类型的数据结构,各式各样的问题都可以很自然地映射到这些数据结构上:Redis的数据结构致力于帮助用户解决问题,而不会像其他数据库那样,要求用户扭曲问题来适应数据库。除此之外,通过复制、持久化(persistence)和客户端分片(client-side sharding)等特性,用户可以很方便地将Redis扩展成一个能够包含数百GB数据、每秒钟处理上百万次请求的系统。

    名称 类型 数据存储选项 查询类型 附加功能
    Redis 使用内存存储(in-memory) 的非关系数据库 字符串、列表、集合、散列表、有序集合 每种数据类型都有自己的专属命令, 另外还有批量操作(bulk operation)和不完全(partial)的事务支持 发布与订阅, 主从复制(master/slave replication), 持久化, 脚本(存储过程,stored procedure)
    Memcache 使用内存存储的键值缓存 键值对 创建命令、读取命令、更新命令、删除命令以及其他几个命令 为提升性能而设的多线程服务器
    MySQL 关系数据库 每个数据库可以包含多个表, 每个表可以包含多个行; 可以处理多个表的视图(view); 支持空间(spatial)和第三方扩展 SELECT 、 INSERT 、 UPDATE 、 DELETE 、函数、存储过程 支持ACID性质(需要使用InnoDB), 主从复制和主主复制 (master/master replication)
    PostgreSQL 关系数据库 每个数据库可以包含多个表, 每个表可以包含多个行; 可以处理多个表的视图; 支持空间和第三方扩展;支持可定制类型 SELECT 、 INSERT 、 UPDATE 、 DELETE 、内置函数、自定义的存储过程 支持ACID性质,主从复制, 由第三方支持的多主复制 (multi-master replication)
    MongoDB 使用硬盘存储(on-disk)的非关系文档存储 每个数据库可以包含多个表, 每个表可以包含多个无schema (schema-less)的JSON文档 创建命令、读取命令、更新命令、删除命令、条件查询命令,等等 支持map-reduce操作,主从复制,分片, 空间索引(spatial index)
    Redis与Memecache的区别

    1. 支持的数据类型和操作方式不同

    Redis相比Memcached来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在Memcached里,你需要将数据拿到客户端来进行类似的修改再set回去。 例如,有memcached使用经验的读者可能知道,用户只能用APPEND命令将数据添加到已有字符串的末尾。memcached的文档中声明,可以用APPEND命令来管理元素列表。这很好!用户可以将元素追加到一个字符串的末尾,并将那个字符串当作列表来使用。但随后如何删除这些元素呢?memcached采用的办法是采用黑名单(blacklist)来隐藏列表里面的元素,从而避免对元素执行读取、更新、写入(或者数据库请求和memcached写入)等操作。相反地,Redis的LISTSET允许用户直接添加或者删除元素。

    2. 内存使用效率差别

    使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,由于其组合式的压缩,其内存利用率会高于Memcached。

    3. 性能对比

    由于Redis只使用单核,而Memcached可以使用多核,所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起Memcached,还是稍有逊色。

    4. 持久化和集群管理差别

    Redis虽然是基于内存的存储系统,但是它本身是支持内存数据的持久化的,而且提供两种主要的持久化策略:RDB快照和AOF日志。而memcached是不支持数据持久化操作的。

    Redis虽然支持数据的持久化,但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说,机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小,就需要构建分布式集群来扩展存储能力。Memcached本身并不支持分布式,因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。

    Redis的安装

    redis的安装非常简单,可以参考官网的说明直接操作即可.

    https://redis.io/topics/quickstart

    下面提供一个可以直接使用的redis安装脚本:

    只需要修改对应的redis安装路径即可使用!

    Redis 配置参考

    Redis本身并没有像MySQL那么强大而全面的文档,各种配置参数详解,因为redis的配置项都比较直观且简单,所以在配置文件本身里面的说明基本就足够了,下面是对应的基本配置项:

    1. 全局基础配置

    2. 持久化相关配置

    3. 主从复制相关配置

    4. 安全相关配置

    5. 限制相关配置

    6. 其他

    Redis 启动密码更改

    安装完毕后,redis的启动也非常简单,只需要指定对应的配置文件即可,如下:

     

    启动完成后即可以登录使用:

    如上,如果你的配置文件中配置了requirepass参数,则需要密码验证才能操作,有如下两种方式:

    否则,你可以在登录后使用如下命令添加密码:

     

     

    参考:

    https://www.biaodianfu.com/redis-vs-memcached.html

    http://www.tuicool.com/articles/i6Rbye

    http://yijiebuyi.com/blog/bc2b3d3e010bf87ba55267f95ab3aa71.html