1 redis 常见数据结构 String hash list set zset geo ，还有一个 特殊的 bitmap
HyperLogLog 做基数统计的算法 ？ Redisson 解决了那些问题 ？ redis 单核单进程单线程，但是只是对外的网络模块是单线程，用了I/O多路复用，异步IO本来就就有一个排队的问题，所以变并发为串行，对于多个客户端的请求不是抢锁而是排队，内部依旧使用了多线程。 C语言写的 redis 内存满了怎么处理策略 6 种 redis为什么块 1 redis基于内存，大部分数操作都是基于内存的，只有内存不够才会去读磁盘 （ 缓存淘汰算法） 2 单线程，变多线程为异步IO，请求是排序的，没有线程操作数据共享，没有多线程并发，没有数据争锁。 3 redis 专门设计的数据结构 redis 为什么事 线程的 redis 基于内存，非阻塞的IO，定制的数据结构，然他CPU性能 不再是瓶颈，真正可能的瓶颈在于内存，和网络。 redis的主重复制，哨兵模式 和 分布式 区别和优缺点 主从复制: 一主多从，一写多读，多机数据备份。从数据的角度来说，有多机备份，避免了单机故障数据丢失，但是从服务高可用的角度来说，并不能持续不断的对外提供可靠的服务。 优点：多节读数据，增加了读取效率和负载。避免单机故障带来的数据丢失。 缺点: 主点故障，不会自动恢复 哨兵模式: 一主多从，一写多读，并且主节点挂了以后会自动选举。 优点:解决了主从辅助的主节点故障问题。 缺点:受到单机存储能力的制约，受到单节点写的制约。 集群模式:解决单机横向拓容问题，但是默认没有数据备份，只有数据切片。 每个节点后面架设 主从（ 是否可以架设哨兵模式）。 RDB 满足指定时间写入多少条自动触发，在正常关闭和save，bgsave 的时候回触发。 默认在写在 dump.rdb
save 10 100 开启 aop 并且 10 秒 100 次写入出发（ 可以配置多个 ， save "" 表示关闭） AOF
可以关闭，也可以选择写入频率 比如每秒 ，每次，和不同步存储。
appendonly yes 是否开启 aof
appendfilename "appendonly.aof"：AOF文件名
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的 故障问题
实现： 获取到超多一半的 锁以后就算获取成功，并且锁的时间要按照 最小的 最先过的那个时间算。
bitmap 也叫 布隆过滤 主要用户高效的判断大量数据中的一个是否存在 或者是否执行。
实际是一个String类型（ 提成是 redisObject），用 里面的位数据来表示是否有。如果 原始数据 是有序的数字，那么 直接用作 bitmap 的 偏移位置，如果不是，可以取 hash 作为偏移位置。
如果原始 数据是 数据 可以 明确的 知道 存在还是不存在
如果原始数据 去hash 作为偏移量 那么 只能明确知道不存在，返回存在的时候不一定真的存在（ hash 重复问题 ）。
redis 的 db 为啥有 16 。可以设置，redis db 算是 redis 的 命名 空间。 可以通过 配置修改。
redis 的分布式 集群的哈希槽 为啥 是 2的14 次方 ，而不是 cyc(16) 的 2^16
处于心跳通信省资源和 集群基本 不会超过1000 个中和考虑。
哈希摸运算： 哈希以除以一个值得到固定的几个数
一致性哈希算法: 一个圆环结构 每个圆环 几管理着逆时针 圆弧 上的 哈希命中点。
哈希槽算法:在哈希模运算以后不是的到节点编号，而是得到槽编号，通过 槽编号去找到节点编号。便于节点的添加和删除。
一致性哈希算法 对比 哈希槽算法 一个环形去找，一个是 去列表找。