简单概括Redis（Remote Dictionary Server）基本功能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中的内存数据，加载速度快

缺点

需要一定的时间间隔进程操作，如果Redis意外宕机了，则最后一次备份RDB文件之后的数据就丢失了。
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的频率)

缺点

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

Redis发布订阅

Redis主从复制、读写分离

数据冗余：热备份
故障恢复：当主节点宕机，从节点能够替代主节点工作，服务冗余
负载均衡：在主从复制的基础上，配合读写分离，可以让主节点提供写服务，从节点提供读服务，分担服务器负载
高可用：主从复制集群是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状态。==

Slave挂了：不影响集群正常工作。
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。

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