* ?Redis 中某个Key设置了国企过期时间,是到了这个时间内存就会被回收吗?
* ◆ Redis 的某个Key,虽然设置了,过期时间,但是并不是到了该时间,就会马上进行内存回收,
* --这涉及到了Redis的过期删除策略和内存淘汰机制。
*
* ?为什么用Redis ,而不是使用 Map?
* ‣ 因,Map 的作用域,仅限于JVM中,受限于堆内存的大小约束,Map持久化非常耗费效率;
* ‣ Redis,可以搭建主从、集群的,独立服务,具有持久化;
*
* ?Redis 常见数据结构?
* 1、String
* -常用命令:set、get、decr、incr、mget 等;
* -String 数据结构是简单的key-value类型、value其实不仅可以是String,也可以是数字;
* -常规Key-value缓存应用;常规计数:微博数,粉丝数等.
* 2、Hash
* -常用命令:hget、hset、hgetall等;
* -Hash 是一个 string 类型的,field 和 value 的映射表;
* -hash 特别适合用于存储对象,后续操作的时候,可以直接仅仅修改这个对象中的某个字段的值。
* -比如,可以Hash数据结构来存储用户信息,商品信息等等。
* 3、List
* -常用命令:Ipush、rpush、Ipop、rpop、lrange、等
* -list 的实现为一个双向链表,所以可以支持反向查找和遍历,不过带来了部分额外的内存开销。
* -另外可以通过 lrange 命令,就是从某个元素开始读取多少个元素,可以基于list实现分页查询;
* -基于redis实现简单的高性能分页。
* 4、Set
* -常用命令:sadd,spop,smembers,sunion等;
* -set 对外提供的功能与List类似是一个列表的功能,可以存放不重复的数据;
* -set 提供了判断某个成员是否在一个 set 集合内的重要接口,这个也是list所不能提供的。
* -可以基于set轻易实现、交集、并集、差集的操作。
* 5、Sorted Set(Zset)
* -常用命令:zadd,zrange.zrem,zcard等.
* -和set相比,sorted set增加了一个权重参数score,使得集合中的元素能够按score进行有序排列.
* -举例:在直播系统中,实现排列信息包含直播间在线用户列表,各种礼物排行榜等信息。
*
* ?Redis过期时间?
* ? 如果假设你设置了一批 key 只能存储1个小时,那么接下来1小时后,redis是怎么对这批key进行删除的?
* ‣ 定期删除
* -Redis默认是每隔 100ms 就随机抽取一些而设置了过期时间的key,检查是否过期,如果过期就删除。
* ‣ 惰性删除
* -如果操作某个Key过期了,使用定期删除 没有删除成功,那么去查一下那个Key的时候,才会被Redis给删除掉。
* ‣ 内存淘汰机制
* -内存淘汰策略,通过配置文件中的 MaxMemory-policy noEviction项来配置。
* redis 提供 6种数据淘汰策略:
* ◇ Volatile-lru<推荐>
* ◇ Volatile-ttl
* ◇ Volatile-random
* ◇ allKeys-lru<推荐>
* ◇ allKeys-random
* ◇ on-eviction
*
*
* ?Redis持久化机制 ?
* ▷ RDB
* -Redis,可以通过创建快照来获得存储在内存里面的数据,在某个时间点上的副本。
* ▷ AOF
* ▸ 开启AOF持久化后,每执行一条会更改Redis中的数据的命令,Redis就会将该命令写入硬盘中的AOF文件。
* • AppEndFsync always #每次有数据修改发生时,都会写入AOF文件,这样会严重降低Redis的速度;
* • AppEndFsync everYseC #每秒钟同步一次,显示地将多个写命令同步到硬盘;
* • AppendFsync no #让操作系统决定何时进行同步;
* ‣ 为了兼容数据和写入性能,用户可以考虑 AppendFsync everYseC选项,让Redis每秒同步一次AOF文件,
* --这样即使出现系统崩溃,用户最多只会丢失一秒之内产生的数据。
*
* ?使用Redis时,遇到那些印象深刻的问题吗?
* ◇ Redis 是一个比较方便的key-Value的NoSql数据库,但是如果使用不当的话会造成很多严重的问题。
* ◇ 如缓存穿透,雪崩还有考虑缓存和数据库双写时的数据一致性问题。
* -- 缓存穿透、雪崩、双写一致性 --
*
* ?什么是缓存穿透?如何解决?
* ◇ 故意请求缓存中不存在的数据,导致所有的请求都落到数据库上,造成数据库短时间内承受大量请求而崩掉。
* 解决办法:
* ‣ 采用'步隆过滤器',将所有可能存在的数据,哈希到一个足够大的bitmap中,
* -一个一定不存在的数据会被 这个 bitmap 拦截掉,从而避免了对底层存储系统的查询压力。
* ▸ 如果一查询返回的数据为空,我们仍然 把这个空结果进行缓存,但它的过期时间会很短,最长不超过5分钟。
*
* ?雪崩?
* 如何避免雪崩现象的发生?
* ▹ 缓存同一时间大面积的失效,所以,后面的请求都会落到数据库上,
* --造成数据库短时间内承受大量请求而崩掉。
* 解决办法:
* ▹ 尽量保持整个redis 集群的高可用,发生集群宕机尽快补上.
* ▹ 本地 ehcache 缓存+hystrix限流&降级,避免Mysql崩掉。
* ▹ 利用Redis缓存机制保存的数据尽快恢复缓存。
*
* ?双写一致性??
* 缓存与数据库双存储双写,如何解决一致性问题?
* ◇如果系统不是严格要求缓存+数据库必须强一致性的话,可以采用Cache-Aside Pattern;
* ◇如果不得不做一致性,那么可以使用读请求和写请求串形化,串到一个内存队列里去;
* ◇使用队列串形化的方式会导致系统的吞吐量会大幅度的降低;
*
*
* ?主从复制和集群
* ?主从复制的好处?
* ◇ 没有单点故障,(写的少,读的多);
* ◇ 构建读写分离架构,满足读多写少的应用场景;
* ?复制的过程原理
* ◆ 当从库和主库建立MS关系后,会向主数据库发送Sync命令;
* ◆ 主库接收到Sync命令后开始在后台fork保存快照(RDB持久过程bgSave) 并将期间接收的写命令缓存起来;
* ◆ 当快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis;
* ◆ 从Redis接收到后,会载入快照文件并且执行收到的缓存的命令;
* ◆ 主Redis每当接收到写命令时就会命令发送从Redis,从而保证数据的一致。
* --单点故障--主从分离--
*
* ?描述一下哨兵机制??
* 哨兵的作用就是对Redis的系统的运行情况的监控,它是一个独立进程,它的功能有2个
* ▻ 监控主数据库和从数据是否运行正常
* ▻ 主数据出现故障后自动将从数据库转化诶主数据库;
* ❖ 哨兵的配置文件sentinel.conf (sentinel monitor e3Master 127.0.0.1 6379 1)
*
* ?既然有了主从了,为什么还需要集群呢?
* --即使有了主从复制,每个数据库都要保存整个集群中的所有数据,容易形成木桶效应,所以还需要集群。
*
* ?集群中Hash槽和Key的关系?
* ◆ Key的有部分使用CRC16算法计算粗话哈希值,在将哈希值对16384取余,得到插槽值.
* ◆ 什么是有效部分?
* ▷ 如果Key中包含了成对的大括号{}并且{}中间存在字符,那么有效部分指的是{}之间的部分.
* ▷ Key={hello} E3的有效部分是Hello.
* ▷ 如果不满足上一条的情况,整个key都是有效bufen;
* ▷ Key=hello E3的有效部分是全部。
*
* Redis集群
* ?Redis 集群是如何知其它节点是否正常呢?
* ◆集群中的每个节点都会定期的向其它节点发送ping命令,通过有没有收到回复判断目标节点是否下线。
* ➣ 集群中每一秒就睡随着选择5个节点,然后选择其中最久没有响应的节点放ping命令;
* ➣ 如果一定时间内目标节点都没有响应,那么该节点就认为目标节点疑似下线:
* ◆ 当集群中的节点超过半数任务该目标节点疑似下线,那么该节点就会被标记为下线;
* ◆ 当集群中的任何一个节点下线,就会导致插槽区有空挡,不完整,那么该集群将不可用;
* ?如何解决上述问题?
* ◆ 在Redis集群中可以使用主从模式实现某一个节点的高可用;
* ◆ 当该节点宕机后,集群会将该节点的slave转变为master继续完成集群服务。