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

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

官方表示：Redis是基于内存操作的，CPU不是Redis的性能瓶颈，Redis的瓶颈是根据机器的内存和网络带宽决定的。

基本数据类型

• 常用的数据类型

  ---

  • 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。