简单概括Redis（Remote Dictionary Server）基本功能

基本数据类型

• 常用的数据类型
  

  ---

  • String字符串
  • List列表、队列、栈
  • Hash 哈希
  • Set 集合
  • ZSet 有序集合

  ---

• 其他数据类型
  

  ---

  • Geospatial
    • 存储一个key下的某一个地理位置（经纬度）
      • key -> area -> 经纬度
    • 应用场景：存储地理位置信息
  • Hyperloglog
    • 用于基数计算 （基数：不重复的元素个数）
    • 优缺点：占用内存极小（2^64的不同元素仅占12kb内存）；有错误率 0.81%
    • 应用场景：统计UV任务（UV：用户访问数）
  • Bitmaps
    • 位图、Byte数组
    • 应用场景：适用于只有两种状态的标记、签到、未签到；打卡、未打卡（因为Byte数组中只能有0、1两种状态）

事务

Redis事务的本质：一组命令的集合。

• 一个事务中的所有命令都会被序列化执行。

==Redis的单条命令是保证原子性的，而事务不保证原子性。==

Redis事务步骤：

• 开启事务
• 命令入队
• 执行事务

Redis事务什么时候不会被执行：

• DISCARD命令，放弃事务
• Redis命令有语法错误
• 启动Redis乐观锁的情况下，Watch命令监视的对象被修改

Redis持久化

RDB (Redis DataBase)

==原理：将数据备份到文件中==

触发RDB的条件：

• 配置文件中的save的规则被满足时
• 执行flushall命令，也会触发RDB规则
• 退出Redis时

备份后自动生成dump.rdb

如何利用dump.rdb恢复数据？

• 将dump.rdb放在Redis启动目录，Redis启动时，会自动检查恢复其中的数据
• 查看Redis启动目录：CONFIG GET dir

    127.0.0.1:6379> CONFIG GET dir
    1) "dir"
    2) "/Users/eddie"  # 启动目录

优点

• 适合大规模数据的恢复
• rdb文件记录的是Redis中的内存数据，加载速度快

缺点

1、 需要一定的时间间隔进程操作，如果Redis意外宕机了，则最后一次备份RDB文件之后的数据就丢失了。
2、 Fork进程时，需要占用一定的内存空间。

AOF (Append Only File)

==原理：将Redis的写操作以日志的形式追加到文件中==

AOF操作步骤

• 开启AOF功能：redis.conf中的append only设置为yes
• redis.conf中的appendfysnc参数：
  • always：每一次写操作都会调用一次fsync
  • everysec：每秒去做一次调用一次fsync
  • no：Redis不会主动调用fsync去将AOF日志内容同步到磁盘，对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
• *.aof文件：在Redis启动时会==一步步==去执行*.aof文件，将数据加载到内存中
• *.aof文件损坏：redis-check-aof --fix appendonly.aof修复对应的文件

优点

• 数据完整性更好：每一次修改都会同步，只丢失少部分数据(取决于appendfsync的频率)

缺点

1、 相对于数据文件大小来说，aof大小远大于rdb
2、 aof是记录命令的执行过程，aof恢复数据是通过执行命令获取数据的，效率低

Redis订阅

Redis主从复制、读写分离

1、 数据冗余：热备份
2、 故障恢复：当主节点宕机，从节点能够替代主节点工作，服务冗余
3、 负载均衡：在主从复制的基础上，配合读写分离，可以让主节点提供写服务，从节点提供读服务，分担服务器负载
4、 高可用：主从复制集群是Redis高可用的基石

集群配置

• 暂时配置（通过命令行，重启失效）：在Slave从机的Redis上执行命令SLAVEOF IP PORT指定对应Master的地址IP，与端口PORT。
• 永久配置（通过配置文件）：

    replicaof <masterip> <masterport> # 配置主机的IP与Port
    masterauth <master-password> # 配置主机的Password

集群信息查看

执行命令info replication即可查看当前的角色，与主从关系

Redis集群数据复制

• 全量同步
• 增量同步

从机在第一次连接到主机时，就会触发一次全量复制，向主机发送sync请求，将主机的rdb文件发送给从机，并开始在缓冲区缓存新的命令；从机收到rdb文件后，丢弃本地的文件，加载主机rdb文件到内存中，同时主机也会将缓冲区的新命令发送过来，从机开始以增量复制的方式执行发送过来的新命令。

全量同步与增量同步的抉择？

Redis对此的做法是：无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

二者其实是互补不可分割的，在从机第一次连接到主机时，因为从机中大量数据未加载，通过增量同步执行命令的效率太过于低，全量同步是一个快速恢复数据的好的选择；而在后续的同步过程中，由于新增的数据量较小，如果每一次命令都进行全量同步就会大大减低Redis集群的效率，实时性也不够好，通过增量同步，执行新的命令是更优的选择；而在集群过程中，网络问题，机器故障也是不可避免的，Redis从机可能会出现来不及执行新命令而导致数据差别太大，这时使用全量同步的做法，效率相对更高。

Redis哨兵模式Sentinel

问题：Redis集群中，若Slave挂掉了会怎么样？若Master挂掉了会怎么样？

==进行下列动作的前提：存活下来的节点超过集群解点的半数以上，则该集群可用；否则进入集群fail状态。==

1、 Slave挂了：不影响集群正常工作。
2、 Master挂了：

 *  ==选出新的`Master`==：

     *  选举优先级条件依次为：

         *  选择优先级较高的，`slave-priority`值较大的
         *  选择偏移量最大的，偏移量最大的证明，数据最全，最新
         *  选择`run_id`最小的，`run_id`是启动时随机生成的
     *  被选中的`Slave`执行由`Sentinel`发来的命令`SLAVEOF no one`，晋升为新的`Master`
 *  ==修改`Slave`的复制目标：==当新的`Master`出现后，`Sentinel`发送命令`SLAVEOF <new_master_ip> <new_master_port>`，使得其他`Slave`“臣服”于新的`Master`。
 *  ==将旧的`Master`变成`Slave`==：将命令`SLAVEOF <new_master_ip> <new_master_port>`保存到旧的`Master`对应的实例结构中，当旧的`Master`重新上线时，就会自动发送命令给旧的`Master`，旧的`Master`变成`Slave`，“臣服”于新的`Master`。

文章永久链接：https://tech.souyunku.com/45746