学习目标:
掌握redis的配置和集群方案
学习内容:
redis概述
- 非关系型数据库,开源的key-value存储系统,基于内存,数据都是缓存在内存中
- 与memcached类型,memcached只支持字符串类型,不支持持久化操作,采用多线程+锁机制,而redis支持string、list(链表)、set(集合)、zset(有序集合)、和hash,支持RDB、AOF持久化操作
- redis会周期性的把更新的数据写入磁盘或者修改操作写入追加的记录文件
- 实现主从同步
- 单线程,多路I/O复用,原子性
redis键(key)
key * 查看当前库所有key
exsit key 判断某个key是否存在
type key 查看key的类型
del key 删除指定key
unlink key 根据vlaue选择非阻塞删除,异步删除
set key value 设置key的value值
get key 查看对应的键值
expire key 10 未指定的key设置过期时间10秒钟
ttl key 查看还有多少秒过期,-1代表永不过期,-2代表已过期
flushdb 清空数据库
flushall 通杀全部库
append key value 将指定的value追加到原值的末尾
strlen key 获取值的长度
redis配置文件—常用配置
bind 127.0.0.1 # 指定 redis 只接收来自于该IP地址的请求,如果不进行设置,那么将处理所有请求
protected-mode yes #是否开启保护模式,默认开启。要是配置里没有指定bind和密码。开启该参数后,redis只会本地进行访问,拒绝外部访问。要是开启了密码和bind,可以开启。否则最好关闭,设置为no
port 6379 #redis监听的端口号
timeout 0 #此参数为设置客户端空闲超过timeout,服务端会断开连接,为0则服务端不会主动断开连接,不能小于0
daemonize yes #是否在后台执行,yes:后台运行;no:不是后台运行
pidfile /var/run/redis/redis.pid #redis的进程文件
loglevel notice #指定了服务端日志的级别。级别包括:debug(很多信息,方便开发、测试),verbose(许多有用的信息,但是没有debug级别信息多),notice(适当的日志级别,适合生产环境),warn(只有非常重要的信息)
logfile /usr/local/redis/var/redis.log #指定了记录日志的文件。空字符串的话,日志会打印到标准输出设备。后台运行的redis标准输出是/dev/null
databases 16 #数据库的数量,默认使用的数据库是0。可以通过”SELECT 【数据库序号】“命令选择一个数据库,序号从0开始
dir /usr/local/redis/var #数据目录,数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
masterauth <master-password> #如果master设置了requirepass,那么slave要连上master,需要有master的密码才行。masterauth就是用来配置master的密码,这样可以在连上master后进行认证。
requirepass foobared #requirepass配置可以让用户使用AUTH命令来认证密码
maxclients 10000 # 设置能连上redis的最大客户端连接数量。默认是10000个客户端连接
maxmemory 122000000 #redis配置的最大内存容量。当内存满了,需要配合maxmemory-policy策略进行处理。
cluster-enabled yes # 集群开关,默认是不开启集群模式
cluster-config-file nodes-6379.conf #集群配置文件的名称,每个节点都有一个集群相关的配置文件,持久化保存集群的信息。这个文件并不需要手动配置,这个配置文件有Redis生成并更新,每个Redis集群节点需要一个单独的配置文件,请确保与实例运行的系统中配置文件名称不冲突
cluster-node-timeout 15000 #节点互连超时的阀值。集群节点超时毫秒数
redis持久化操作—RDB和AOF
- RDB(redis database):在指定的时间间隔内将内存中的数据集快照写入磁盘。默认开启
RDB持久化流程
redis会创建(fork)一个子进程来进行持久化,先将数据写入到一个临时文件,待持久化过程结束,再用这个临时文件替换上次持久化好的文件,写时复制技术;确保极高的性能
优势
-
适合大规模数据复制
-
对数据完整性和一致性要求不高更适合使用
-
节省磁盘空间
-
恢复速度快
劣势 -
最后一次持久化后的数据可能丢失
-
消耗性能
-
AOF(append of file):以日志的形式来记录每个写操作(增量保存),将redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件。默认不开启,
**注意:**RDB和AOF同时开启,系统默认取AOF的数据(数据不会存在丢失)
AOF持久化流程 -
客户端的请求写命令会被append追加到AOF缓冲区
-
AOF缓冲区根据AOF持久化策略(always,everysec,no)将操作sync同步到磁盘的AOF文件中
-
AOF文件大小超过重写策略或手动重写写,会对AOF文件rewrite重写,压缩AOF文件容量
-
redis重启时,会重新load加载AOF文件中的写操作达到数据恢复目的
优势 -
备份机制更稳健,丢失数据概率更低
-
可读的日志文件
劣势 -
比起RDB占用更多的磁盘空间
-
恢复备份速度要慢
-
每次读写都同步的话,有一定的压力
-
存在个别bug,造成恢复不能
redis主从复制
主机数据更新后根据配置和策略,自动同步到备机的master/slave机制,master以写为主,slave以读为主
优势
- 读写分离,性能扩展
- 容灾快速恢复
主从复制原理
- slave启动成功连接到master后会发送一个sync命令
- master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完之后,持久化到RDB文件,master将传送整个文件到slave,完成一次全量同步,主从同步完之后,后面主上操作都是主主动同步给从服务器
全量复制:slave服务器在接收到数据库文件数据后,将其存盘并加载到内存中
增量复制:master继续将新的所有收集到的修改命令依次传送到slave完成同步
redis哨兵模式
反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转化为主库
劣势
复制延时:由于所有写操作都是现在master上操作,然后同步更新到slave上,所以master同步到slave机器会有一定的延时
切换过程
- 新主登基:从下线的主服务器的所有从服务里面挑选一个从服务,将其转换成主服务
选择条件依次为:1、选择优先级靠前的 2、选择偏移量最大的 3、选择runid最小的服务 - 群仆俯首:挑选出新的主服务之后sentinel向原主服务的从服务发送slaveof新主服务的命令,复制新的master
- 旧主俯首:当已下线的服务重新上线时,sentinel会向其发送slaveof命令,让其成为新主的从
redis集群
redis集群实现对redis的水平扩容,即启动N个节点,将整个数据库分布存储在这N个节点中,每个节点存储总数据的1/N
redis集群通过分区来提供一定程度的可用性,即使集群中有一部分节点失效或无法进行通讯,集群也可以继续处理命令请求
redis应用问题
缓存穿透
过程:
- 应用服务器压力变大
- redis命中率降低
- 一直查看数据库
产生原因:
4. redis查询不到数据
5. 出现很多非正常的url访问
解决方案:
- 对空值缓存,设置空结果的过期时间较短
- 设置可访问的白名单,使用bitmaps类型定义可访问名单,访问id存在则访问,不存在则拦截
- 采用布隆过滤器
- 进行实时监控,排查访问对象和访问数据,设置黑名单限制
缓存击穿
过程:
- 数据库访问压力暴增
- redis里面未出现大量key过期
- redis正常运行
产生原因:
- redis某个key过期,大量访问使用这个key
解决方案:
- 预先设置热门数据,加大热门数据key的时长
- 实时调整
- 使用锁
缓存雪崩
过程:
- 数据库访问压力变大,服务器崩溃
产生原因:
- 在极少时间段,查询大量key的集中过期情况
解决方案:
- 构建多级缓存架构
- 使用锁或队列
- 设置过期标志更新缓存
- 将缓存失效时间分散开
173万+

被折叠的 条评论
为什么被折叠?



