redis学习笔记整理

redis学习笔记01

redis的常用指令

redis-cli -p 6379

linux安装redis 完整步骤

rdb（redis database） snapshotting快照

• save ，bgsave会立即的保存快照信息

• save时只管保存，其他不管，全部阻塞

• bgsave：redis会在后头异步的进行快照操作，快照同时还可以响应客户端请求，可以通过lastsave命令获取最后一次成功执行快照的时间

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

• 如何进行恢复

  • 将备份文件（dump.rdb）移动到redis安装目录并启动服务既可以
  • config get dir获取目录

• 优势

  • 适合大规模的数据恢复
  • 对数据完整性和一致性要求不高

• 劣势

  • 在一定时间间隔做一次备份，所以如果redis以为down掉的话，就会丢失最后一次快照后的所有修改
  • fork的时候，内存中的数据被克隆了一份，大概两倍的膨胀性需要考虑

• 如何停止

  • 动态停止所有rdb保存规则的方法：redis-cli config set save “”

• stop-writes-on-bgsave-error

• rdbcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储，如果是的话，redis采用lzf算法进行压缩，如果你不想消耗cpu来进行压缩的话，可以设置关闭此功能

• rdbchecksum:在存储快照后，还可以让redis使用crc64算法来进行数据校验，但是这样做会增加大约百分之10的cpu性能消耗，如果希望获得最大 的性能提升，可以关闭此功能

• dbfilename

• config get dir

aof(append only file)

• 官网介绍

  • 以日志的形式记录每个写的操作，将redis执行过程中的所哟的写指令记录下来（读操作不记录）

    只允许追加文件但是不可以改写文件，redis启动之初会读取所有该文件重新构建数据，换言之，redis

    重启的话，就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复操作。

  • aof保存的是appendonly.aof文件 默认不开启no

    • appendonly
    • appendfilename
    • Appendfsync
      • Always:同步持久化，每次发生数据改变会被立即记录到磁盘，性能较差但是能保证数据的完整性
      • Everysec:出厂默认推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失
      • No
    • No-appendfsync-on-rewrite:重写时是否可以运用Appendsync,用默认no即可，保证数据安全
    • Auto-aof-rewrite-min-size:设置重写的基准值
    • Auto-aof-rewrite-percentage:设置重写的基准值

  • 配置位置

  • 使用redis-check-aof可以进行自动的修复

    • ./redis-check-aof appendonly.aof

  • aof启动/修复/恢复

    • 正常恢复：
      • 启动：设置yes：修改默认的appendonly no，改为yes
      • 将有数据的aof文件复制一份保存到对应的目录（config get dir）
      • 恢复：重启redis然后重新加载
    • 异常恢复
      • 启动设置yes
      • 备份被破坏的aof文件
      • 恢复：Redis-check-aof --fix 进行修复
      • 恢复：重启redis然后重新进行加载

  • rewrite

    • 是什么：aof采用文件追加的方式，文件会越来越大为避免出现此种情况，新增了重写机制，当aof

      文件的大小超过所设定的阈值是，redis就会启动aof文件的内容压缩，只保留可以修复数据的最小指令集，可以使用命令bgrewriteaof （redis会记录上次重写时的aof大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64m时进行触发）建议重写至5gb

  • 优势

    • 见上面3个aways，everySecond，no这3个特性

    • 劣势

        - 相同的数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb，
        - aof运行效率要慢于rdb，每秒同步策略较好，不同和效率和rdb相同
      

  • 总结

    • 同时开启两种持久化方式

      • 在这种情况下，当redis重启时会优先加载aof文件来恢复原始的数据

        因为通常情况下，aof文件保存的数据集要比rdb文件保存的数据集要完整，rdb的数据不实时

      ，同时使用两者时服务器重启也只会找aof文件，那要不要使用aof呢？作者建议不建议，因为rdb更适合用来备份数据库（aof在不断变化不好做数据备份）快速重启，而且不会有aof可能存在的潜在的bug，留着作为一个万一的手段

redis的事物

• 是什么
  • 可以一次执行多个命令，本质是一组命令的集合，一个事务中的所有命令都会序列化，按照顺序串行执行而不会被其他命令插入，不许加塞。
• 能干嘛
  • 一个队列中，一次性，顺序性，排他性的执行一系列的命令
• 怎么玩
  • case1 正常执行
  • case2 放弃事务
  • case3 全体连坐
  • case4冤头债主
  • case5：watch监控
  • redis事务命令
    • discard：取消事务，放弃执行事务内的所有命令
    • exec：执行所有事务块的命令
    • muti：标记一个事务的开启
    • unwatch：取消watch命令对所有key的监控
    • watch key[key …] ：监视一个或者多个key，如果在事务执行之前这个key被其他的命令所改动，那么事务将被打断
      • 悲观锁/乐观锁/cas(check and set)
      • 初始化信用卡的余额和欠额
      • 无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内
      • 有加塞篡改
      • unwatch
      • 一旦执行exec之前的监控锁都会被取消掉了，同时返回nummulti-bulk应答以通知调用者事务执行失败
      • 乐观锁策略：提交版本必须大于当前版本才能执行更新
• 3阶段
  • 开启：以multi开启一个事务
  • 入队：将多个命令入队列到事务当中，接到这些命令并不会立即执行，而是等待执行的事务队列里面
  • 执行：有exec命令触发事务
• 3特性
  • 单独的隔离级别：事务中的所有的命令都会序列化，按照顺序进行执行，事务在执行过程中，不会被其他客户端发来的命令请求所打断，
  • 没有隔离级别的概念：队列中的命令么有提交之前都不会被实际的执行，因为事务提交前任何指令都不会被实际的执行也就不存在“事务内的查询要看到事务的更新，在事务外查询不能看到”这个让人万分头痛的问题
  • 不保证原子性：redis同一个事务当中，如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

​

redis的发布和订阅

• 是什么

  • 进程中的一种消息通信模式：发送者（pub)发送消息，订阅者（sub）接收消息
  • 订阅/发布消息图

• 命令

  • psubscribe pattern[pattern …]订阅一个或者多个符合给定模式的频道

  • pubsub subcommand[argument [argument …]]查看订阅和发布系统的状态

  • publish channel message：将消息发送至指定的频道

  • punsubscribe [parttern[parttern …]]退订所有给定模式的频道

  • subscribe channel [channel …] 订阅一个或者多个频道的信息

  • unsubscribe[channel[channel…]] 退订给定的频道

• 案例

  • 先订阅发布后才能够收到消息
  • 可以一次订阅多个。subscribe c1 c2 c3
  • 消息发布：publish c2 hello-redis
  • 订阅多个，通配符 * ,pubscribe new *
  • 收取消息 ，publish new1 redis2015

redis的复制（master/slave）

• 是什么
  • 行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，master以写为主，slave以读为主
  • 官网：
• 能干嘛
• 怎么玩
  • 配从（库）不配主（库）
    • 每次与master断开之后，都需要重新的连接，除非你配置进redis.conf文件
    • Info replication 查看集群的信息
  • 从库配置：slaveof主库ip 主库端口
  • 修改配置文件中细节操作
    • 拷贝多个redis.conf文件
    • 开启daemonize yes
    • Pid文件名字
    • 指定端口
    • Log文件名字
    • Dump.rdb名字
  • 常用3招
    • 一主两仆
      • slaveof 127.0.0.1 6379
      • 读写分离 主机进行写，从机进行读
      • 主机宕机后，从机的角色仍然是slave ，主机恢复后，主机依然重新作为master
      • 从机宕机：从机单独重新作为主机，需要重新连接（除非配置进了配置文件） slaveof 127.0.0.1 6379
    • 薪火相传
      • 上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为链条中下一个的master，可以有效的减轻master的压力
      • 中途变更转向：会清除之前的数据，重新建立拷贝最新的
      • slaveof新主库ip新主库端口
    • 反客为主
      • slaveof no one 将自己从从节点变为主节点
• 复制原理
  • Slave启动成功连接到master后发送一个sync命令，master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕以后，master将传送整个数据文件到slave，以完成一次同步全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
  • 增量复制：master继续讲新的所有收集到的修改命令依次传给slave，完成同步但是只要是重新连接master，一次完全同步（全量复制）将被自动执行
• 哨兵模式（sentinel）
  • 是什么
  • 怎么玩（使用步骤）
    • 调整结构，6379,带着80,81
    • 自定义/myredis目录下新建sentine.conf文件，名字绝对不能错
    • 配置哨兵，填写内容
      • sentinel monitor 被监控数据库名字（自己起名字）127.0.0.1 6379 1
      • 上面最后一个数字1，表示主机挂掉后slave投票看让谁接替为主机，得票数多为新的master
    • 启动哨兵
      • Redis-sentinel /root/redis/redis_install/sentinel.conf
      • 上面的目录根据实际情况进行替换
    • 正常主从演示
    • 原有的master挂了
    • 投票新选
    • 重新主从继续开工，info replication查看
    • 问题：如果之前的master重启回来，会不会双master冲突
  • 一组sentine能同时监控多个master
• 复制的特点

​ - 由于所有的写操作都是先在master上进行操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟的问题会更加的严重，slave机器数量的增加也会使得这个问题更加的严重