简单概括Redis(Remote Dictionary Server)基本功能
官方表示:Redis是基于内存操作的,CPU不是Redis的性能瓶颈,Redis的瓶颈是根据机器的内存和网络带宽决定的。
基本数据类型
-
常用的数据类型
String
字符串List
列表、队列、栈Hash
哈希Set
集合ZSet
有序集合
-
其他数据类型
Geospatial
- 存储一个key下的某一个地理位置(经纬度)
- key -> area -> 经纬度
- 应用场景:存储地理位置信息
- 存储一个key下的某一个地理位置(经纬度)
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
。
- 选出新的