学习笔记——Redis

1. Redis简介

        Redis是基于内存的高性能key-value数据库，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。默认有16个数据库。Redis是单进程单线程的，Redis利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销。

       Redis的日志级别有四种（redis在默认情况下，是不会生成日志文件的，所以需要配置）

1. debug：会打印出很多信息，适用于开发和测试阶段
2. verbose（冗长的）：包含很多不太有用的信息，但比debug要清爽一些
3. notice：适用于生产模式
4. warning : 警告信息

      配置文件

  maxmemory_policy：内存清除策略，Redis在占用的内存超过指定的maxmemory之后,会自动根据策略来清除内存。

1. volatile-lru(least recently used):最近最少使用算法，从设置了过期时间的键中选择空转时间最长的键值对清除掉；
2. volatile-lfu(least frequently used):最近最不经常使用算法，从设置了过期时间的键中选择某段时间之内使用频次最小的键值对清除掉；
3. volatile-ttl:从设置了过期时间的键中选择过期时间最早的键值对清除；
4. volatile-random:从设置了过期时间的键中，随机选择键进行清除；
5. allkeys-lru:最近最少使用算法，从所有的键中选择空转时间最长的键值对清除；
6. allkeys-lfu:最近最不经常使用算法，从所有的键中选择某段时间之内使用频次最少的键值对清除；
7. allkeys-random:所有的键中，随机选择键进行删除；
8. noeviction:不做任何的清理工作，在redis的内存超过限制之后，所有的写入操作都会返回错误；但是读操作都能正常的进行。

 maxclicents :设置同一时间客户端最大连接数量，设置为0表示不作限制。

   RDB（快照）

  简介

    在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里，Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

• 命令save或者是bgsave 
  SAVE：save时只管保存，其它不管，全部阻塞 
  BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave 
  命令获取最后一次成功执行快照的时间

注：执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义 

      save 900 1                            //15分钟内修改一次数据

      save 300 10                           //5分钟内修改10次数据

      save 60 10000                         //1分钟内修改10000次数据

  save这一项后面需要加上两个数字，分别代表秒数和更改数。假如设置了save m n，就代表如果在经过m秒之后发生了至少n次更改，Redis就会自动执行一次BGSAVE命令。save配置项可以同时存在多个，如果save太过频繁，会影响到Redis的性能，频率太低则会增加数据丢失的风险，所以建议根据需要对save项进行配置。如果移除所有的save配置项或者加上一项save “”，则自动保存功能会被关闭。


      stop-writes-on-bgsave-error yes       
  默认情况下，如果后台保存出错了，Redis会停止接受写操作。如果后台的保存进程重新开始工作，Redis也会自动恢复接受写操作。这是一种比较简单粗暴的解决方式，通过这种方式可以显示地提醒维护者Redis出现了故障，但也会导致在故障被修复前Redis都没办法提供完整的服务。如果设置了stop-writes-on-bgsave-error为no，则Redis出问题的时候也可以照常工作，不过这就需要更细致地监控Redis服务器的变化。

      rdbcompression yes 
  rdbcompression配置项设置是否对RDB文件进行压缩。如果将rdbcompression设置为no的话RDB文件保存的速度会快一些，但是保存下来的文件也会相应地变大，Redis使用LZF算法压缩RDB文件，但会消耗CPU性能，

      rdbchecksum yes 
  rdbchecksum配置项控制Redis是否使用循环冗余检验。如果启用循环冗余检验，可以保证文件的完整性，但是进行文件保存和加载时会损失10%左右的性能，如果追求最大性能可以考虑把这一项关闭。Redis使用的是CRC64。

      dbfilename dump.rdb   //配置RDB文件的名字。

      dir ./        //dir配置RDB文件保存的路径。AOF产生的文件也会被保存到这个路径下面。

      优势：

• 适合大规模的数据恢复，对数据完整性和一致性要求不高。
• 是对具体工程的全部造价进行估算，以满足项目建议书、可行性研究和方案设计的需要。
• 使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能。

      劣势：

• 有可能会造成数据丢失，fork的时候，内存中的数据被克隆一份，大致两倍的膨胀性要考虑一下。 
• RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候。

  总结

• RDB是一个非常紧凑的文件
• RDB在保存RDB文件时父进程唯一需要做的就是folk出一个子进程，接下来工作全部交给子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能
• 与AOF相比，在恢复大的数据时候，RDB方式更快一些
• 数据丢失风险大
• RDB需要经常fork子进程来保存数据集到磁盘，当数据集比较大额时候，fork的过程是比较耗时的，可能会导致redis在一些毫秒级不能响应客服端请求

   AOF 

      简介

  Append-only file，将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作过程。AOF相对可靠，它和mysql中bin.log、apache.log、zookeeper中txn-log简直异曲同工。AOF文件内容是字符串，非常容易阅读和解析。只要我们保存了所有可能修改 Redis 内存数据的命令（也就是写命令），那么根据这些保存的写命令，我们可以重新恢复 Redis 的内存状态。AOF 持久化正是利用这个原理来实现数据的持久化与数据的恢复的，Redis默认并没有开启aof缓存。

   特性：

    AOF的特性决定了它相对比较安全，如果你期望数据更少的丢失，那么可以采用AOF模式。如果AOF文件正在被写入时突然server失效，有可能导致文件的最后一次记录是不完整，你可以通过手工或者程序的方式去检测并修正不完整的记录，以便通过aof文件恢复能够正常；同时需要提醒，如果你的redis持久化手段中有aof，那么在server故障失效后再次启动前，需要检测aof文件的完整性。

• always：每一条aof记录都立即同步到文件，这是最安全的方式，也以为更多的磁盘操作和阻塞延迟，是IO开支较大。
• everysec：每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。如果遇到物理服务器故障，有可能导致最近一秒内aof记录丢失(可能为部分丢失)。
• no：redis并不直接调用文件同步，而是交给操作系统来处理，操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步；这是一种普通的文件操作方式。性能较好，在物理服务器故障时，数据丢失量会因OS配置有关。

     因为AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制。当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof，阙值可以按需要配置，生产时一般3G。

AOF重写机制：

   aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据 以命令的方式保存到临时文件中，最后替换原来的文件。具体过程如下：

• redis调用fork ，现在有父子两个进程
• 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
• 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
• 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
• 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

 需要注意到是重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。

  优点：

• 数据完整性高。AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
• AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof      --fix  appendonly.aof工具也很容易修正 AOF 文件。
• AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

   缺点：

• AOF文件比RDB文件大，且恢复速度慢。

 如果aof文件异常无法恢复数据，可以用redis-check-aof --fix appendonly.aof来修复aof文件

总结

   因为rewrite操作/aof记录同步/snapshot都消耗磁盘IO，redis采取了“schedule”策略：无论是“人工干预”还是系统触发，snapshot和rewrite需要逐个被执行。

 AOF rewrite过程并不阻塞客户端请求。系统会开启一个子进程来完成。

  两者都开启的建议：RDB数据不实时，同时使用两者时服务器只会找AOF文件，可不可以只使用AOF?建议不要，因为RDB更适合备份数据库(AOF在不断变化，不好备份)，快速重启，而且不会又AOF可能潜在的BUG,留作万一的手段。