redis笔记

1. redis是nosql数据库，数据存储在内存中，通过tcp直接存取，读写性能高，not onlysql （不仅仅是sql）；
2. 支持多种数据类型 string、list、set、zset（sorted set ）、hash等；
3. 数据可持久化保存（AOF日志模式、RDB快照模式）写入硬盘；
4. 支持灾难回复，主从赋值；主机会自动将数据同步到从机，可以进行读写分离
5. redis的优势
   a、内存数据库nosql
   b、kv键值对存储
   c、resp协议
   d、c语言编写
6. Redis的简单命令
    a、 String字符串 ：SET key value ； GET key
    b、 List列表：LPUSH name value ；在key对应list的头部添加字符串元素
                           RPUSH name value ；在key对应的list的尾部添加字符串元素
                           LREM name index ；key 对应list中删除count个value相同的主键                              LLEN key;      返回key对应list的长度
   c、  Set无序集合：SADD name value ;  添加集合
                                  SEMBERS name; 查询
   d、 Zset(sorted set)有序集合： ZADD name score(分数可以重复)，添加
                                                      ZRANG name 0 10 WITHSCORES 查询
   e、 Hash哈希：HMSET name key1  value key2 value
7. Redis 是服务端
   提供给代码连接还有redis 、redis-client、jedis 等；
8. Redis持久化方法
   a、RDB持久化：指定的时间间隔内将内存中的数据集快照写入磁盘（备份或者快照）
   b、AOF持久化：以日志的形式记录服务器所处理的每一个写、删操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录（日志）
   1. RDB工作机制和原理（自己简单理解）（fork是分叉、岔口的意思）
      一、当满足条件时，redis 需要执行rdb；
      a、redis 调用系统函数fork(),创建一个子进程；
      b、子进程将数据集写入一个临时rdb文件中；
      c、当子进程完成对临时RDB文件的写入时，redis用新的临时rdb文件 替换原来的rdb文件，并删除旧的rdb文件；
      
      新的rdb文件存储的时执行fork那一刻的内存数据；
      redis在进行快照的过程中不会修改rdb文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候rdb文件都是问政的；
      二、自动配置修改 redis配置文件redis.conf
      a、save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。

      save	900	1	表示900 秒内如果至少有 1 个 key 的值变化
      save	300	10	表示300 秒内如果至少有 10 个 key 的值变化
      save	60	10000	表示60 秒内如果至少有 10000 个 key 的值变化

      b、stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了；
      c、rdbcompression ；默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储
      d、rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能；
      e、dbfilename ：设置快照的文件名，默认是 dump.rdbRDB提供了三种机制：save、bgsave、自动化
      三、save ：是同步的 client  ---save-》 redis  ---->rdb二进制文件

      当别的客户端save 也执行命令，会阻塞的，redis 无法处理
      执行完成时候如果存在旧的rdb文件，就把新的替换旧的，如果数据过来特别大的话，这种方式不可取
      bgsave ：异步处理， redis >bgsave          --->backgroud saving started
      
      具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令 

   2. AOF工作机制和原理
      以log日志的形式存储，每收到写的命令都通过write函数追加到文件中。
      每当有一个写命令过来是，就直接保存在我们的aof文件中

   

    一、AOF提供文件重写原理：
   持久化文件越来越大，为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。

    

    重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
   二、AOF也有三种触发机制
   a、每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
   b、每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失
   c、不同no：从不同步
    

   	always	everysec	no
   优点	不丢失数据	每秒一次fsync丢1秒数据	不用管
   缺点	IO开销较大，一般sata盘只有几百TPS	丢1秒数据	不可控

9.  

   	RDB	AOF
   启动优先级	低	高
   体积	小	大
   恢复速度	快	慢
   数据安全性	丢数据	根据策略决定
   轻重	重	轻