redis
2022-05-08 17:03:11 0 举报AI智能生成
redis
作者其他创作
大纲/内容
redis为什么这么快？
C语言编写
网络IO是nio
单线程避免了多线程上下文切换造成的性能损耗
在内存中运算速度快
redis网络模型
IO多路复用（reactor）
redis利用epoll实现IO多路复用，将连接信息和事件放到队列中，依次放到
文件事件分派器，事件分派器将事件分发给事件处理器。
文件事件分派器，事件分派器将事件分发给事件处理器。
redis数据结构
string
sds
hash
dict
list
quickList+zipList
set
dict value都为null
zset
skipList+dict
redis持久化
RDB快照（snapshot）
配置# save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可
save
bgsave
AOF（append-only file）
AOF重写
bgrewriteao手动重写
Redis 4.0 混合持久化
Redis数据备份策略：
1写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48小时的备份
2每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份
3每次copy备份的时候，都把太旧的备份给删了
4每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏
2每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份
3每次copy备份的时候，都把太旧的备份给删了
4每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏
pipeline
客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低多条命令执行的网络传输开销，管道执行多条命令的网络开销实际上只相当于一次命令执行的网络开销。需要注意到是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。
pipeline中发送的每个command都会被server立即执行，如果执行失败，将会在此后的响应中得到信息；也就是pipeline并不是表达“所有command都一起成功”的语义，管道中前面命令失败，后面命令不会有影响，继续执行。
lua
1、减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器上完成。使用脚本，减少了网络往返时延。这点跟管道类似。
2、原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。管道不是原子的，不过redis的批量操作命令(类似mset)是原子的。
3、替代redis的事务功能：redis自带的事务功能很鸡肋，而redis的lua脚本几乎实现了常规的事务功能，官方推荐如果要使用redis的事务功能可以用redis lua替代。
2、原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。管道不是原子的，不过redis的批量操作命令(类似mset)是原子的。
3、替代redis的事务功能：redis自带的事务功能很鸡肋，而redis的lua脚本几乎实现了常规的事务功能，官方推荐如果要使用redis的事务功能可以用redis lua替代。
redis分布式锁
nx通过共享内存实现
redis主从架构
主从复制风暴
redis哨兵架构
sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。
redis集群
redis优化
redis配置
规约
慢日志
slowlog
操作系统配置
vm.swapiness
如果linux内核版本<3.5，那么swapiness设置为0，这样系统宁愿swap也不会oom killer（杀掉进程）
如果linux内核版本>=3.5，那么swapiness设置为1，这样系统宁愿swap也不会oom killer
如果linux内核版本>=3.5，那么swapiness设置为1，这样系统宁愿swap也不会oom killer
合理设置文件句柄数
resdis问题
缓存穿透
第一， 自身业务代码或者数据出现问题。
第二， 一些恶意攻击、 爬虫等造成大量空命中。
第二， 一些恶意攻击、 爬虫等造成大量空命中。
1、缓存空对象
2、布隆过滤器
缓存失效(击穿)
缓存雪崩
1） 保证缓存层服务高可用性，比如使用Redis Sentinel或Redis Cluster。
2） 依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。
比如服务降级，我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据（例如电商商品属性，用户信息等）时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取。
3） 提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案设定。
2） 依赖隔离组件为后端限流熔断并降级。比如使用Sentinel或Hystrix限流降级组件。
比如服务降级，我们可以针对不同的数据采取不同的处理方式。当业务应用访问的是非核心数据（例如电商商品属性，用户信息等）时，暂时停止从缓存中查询这些数据，而是直接返回预定义的默认降级信息、空值或是错误提示信息；当业务应用访问的是核心数据（例如电商商品库存）时，仍然允许查询缓存，如果缓存缺失，也可以继续通过数据库读取。
3） 提前演练。 在项目上线前， 演练缓存层宕掉后， 应用以及后端的负载情况以及可能出现的问题， 在此基础上做一些预案设定。
0 条评论
下一页
