appendfsync always: 每搞一个”写指令“就备份一次,数据最安全,系统性能最低
appendfsync everysec:每秒钟备份一次
appendfsync no:服务器不忙的时候备份,忙了 就等会。性能最高,数据不安全。
RDB的的
优点:体积小,恢复快,因为是写入频率低所以相对AOF 对性能的影响要小些。适合全量备份,网络传输。
缺点:写入写入磁盘频率低,所以可能丢失的数据比aof 高。并且高版本的RDB文件低版本的redis 不一定可以兼容。
AOF:
优点:可以做到 每秒持久化,甚至 每次持久化。不容易丢数据,兼容性强。
缺点。体积大,恢复数据慢,但是的性能的消耗比RDB高。(RDB 也不一定就高,RDB 的时候 fork 生产 RDB 文件这时候可能消耗不少内存。 )
redis 恢复 的时候优先读取的 aof来恢复,因为一般来说 AOF 里面的内容更加完整。但是 RDB 文件 恢复更加块,更加适合全量复制。
redis rdb 模式是开启的 。aof 默认是关闭的。
缓存穿透:指的不存在的key,总是会无意义的 load DB。 如果这种请求很多,或者被恶意利用,那么 可能 DB 崩溃。 简答的处理 缓存 null ,并且返回 这个缓存的 null。 或者 布隆过滤器 。
缓存击穿:在并发高的情景,缓存过期的瞬间可能大量请求都去 load db,这一瞬间DB可能被搞崩,这时候我们需要 做一个 独占锁,只有拿到这个锁的采取 load DB。
缓存雪崩:由于业务或者程序设置,导致某一时间 缓存大量过期,或者是因为服务重启 服务重启还没加载缓存,全都是 load db 。 解决办法 可以考虑 load db 的时候加一个独占锁。 并且程序尽量 避开集缓存中过期,比如在过期时间上 加一个随机数,还可以设置缓存过期标志(标志的时间可能只有缓存时间的一般,标志时间到了,直接返回缓存数据,并且提交更新缓存的申请, 更新申请也是 类似 获取独占锁 然后再load db 的写法,但是 不需要等待 load DB结束 就已经返回了请求 )。
RDS的 Bitmaps ?
redis 的删除 策略(指的缓存过期以后什么时候删除)
1 定时删除,做一个定时器,过期及时删除 最省内存
2 惰性删除 ,下次用的时候删除,不用就不删除 可能放很久也不删除 ,不会在其他无关的删除任务上花费任何cpu时间,但是可能 占用红的内存比较多。
3 定时删除 , 定时批量的清空一下所有应该删除的 数据。 占用空间小,但是可能在一次执行大量删除的时候影响系统效率。
redis 使用的 惰性删除 + 定时删除。
写缓存策略:
Cache-Aside
Read-Through
Write-Through
Write-Behind
读缓存策略:
Cache-Aside
Read-Through
redis 得到事务 不具有原子性,但是不会被别的命令插队,但是不支持回滚 ,个人觉得redis 的 事务只有 cas 的 watch 可用,也就是 只能保证 事务期间 watch 的值没有被修改 。别的基本和传统事务 完全不一样。如果只用 事务,没有 watch 那么和 管道没太多区别。
redis 的 Pipeline 管道,只是一种批处理,只是客户端的一个命令包装,不是服务器端的批处理,不是原子的,也会被别的命令插队,可能会被其他命令 插队。只是批处理,能一定程度的节约 命令执行的往返时间 和 网络IO。
有了 discard 为啥 还有要 unwatch ?
redis 的 事务 只能保证 命令执行的时候,关系的数据没有被修改, watch 的过程就是去服务器端拿到这个几个值,后面执行得到时候 和 服务器端的 这几个 值来做 check 比较。 discard 取消的是 客户端的 事务命令队列,这是后watch 的对象还是没有释放, unwatch 就是释放这些观察对象。
多节点 Redis 分布式锁 存在的意义?
意义:应对单点 redis的 故障问题
实现: 获取到超多一半的 锁以后就算获取成功,并且锁的时间要按照 最小的 最先过的那个时间算。
redis 的 db 为啥有 16 。可以设置,redis db 算是 redis 的 命名 空间。 可以通过 配置修改。
redis 的分布式 集群的哈希槽 为啥 是 2的14 次方 ,而不是 cyc(16) 的 2^16
处于心跳通信省资源和 集群基本 不会超过1000 个中和考虑。
哈希摸运算: 哈希以除以一个值得到固定的几个数
一致性哈希算法: 一个圆环结构 每个圆环 几管理着逆时针 圆弧 上的 哈希命中点。
哈希槽算法:在哈希模运算以后不是的到节点编号,而是得到槽编号,通过 槽编号去找到节点编号。便于节点的添加和删除。
一致性哈希算法 对比 哈希槽算法 一个环形去找,一个是 去列表找。