Day10_微服务_redis高级

redis常见数据结构?

• 字符串 string：普通字符串，常用
  • 应用场景
    • 缓存功能：string 最常用的就是缓存功能，会将一些更新不频繁但是查询频繁的数据缓存起来，以此来减轻 DB 的压力
    • 计数器：可以用来计数，通过 incr 操作，如统计网站的访问量、文章访问量等
• 哈希 hash：适合存储对象
  • 应用场景
    • Hash 更适合存储结构化的数据，比如 Java 中的对象；其实 Java 中的对象也可以用 string 进行存储，只需要将对象序列化成 json串就可以，但是如果这个对象的某个属性更新比较频繁的话，那么每次就需要重新将整个对象序列化存储，这样消耗开销比较大。可如果用 hash 来存储对象的每个属性，那么每次只需要更新要更新的属性就可以
    • 购物车场景：可以以用户的id为key，商品的id 为存储的field，商品数量为键值对的value，这样就构成了购物车的三个要素
• 列表 list：按照插入顺序排序，可以有重复元素
  • 应用场景
    • 消息队列：Redis 的list是有序的列表结构，可以实现阻塞队列，使用左进右出的方式。Lpush用来生产从左侧插入数据，Brpop用来消费，用来从右侧阻塞的消费数据
    • 数据的分页展示： lrange命令需要两个索引来获取数据，这个就可以用来实现分页，可以在代码中计算两个索引值，然后来redis中取数据
    • 可以用来实现粉丝列表以及最新消息排行等功能
• 集合 set：无序集合，没有重复元素
  • 应用场景
    • 标签：可以将博客网站每个人的标签用 set 集合存储，然后还按每个标签 将用户进行归并
    • 存储好友/粉丝：set 具有去重功能；还可以利用set并集功能得到共同好友之类的功能
• 有序集合 sorted set / zset：集合中每个元素关联一个分数（score），根据分数升序排序，没有重复元素
  • 应用场景
    • 排行榜：有序集合最常用的场景。如新闻网站对热点新闻排序，比如根据点击量、点赞量
    • 带权重的消息队列：重要的消息 score 大一些，普通消息 score 小一些，可以实现优先级高的任务先执行

redis在项目中的使用场景?
redis的key 的数据结构是如何选型的
redis的key的规范是如何设计的
具体业务是怎么样的
如何使用redis解决的业务
redis具体如何使用?
redis的事务机制的介绍?

• Redis事务是基于队列实现的，创建一个事务队列，然后将事务操作都放入队列中，最后依次执行

一个最简单的事务从开始到执行大概会经历以下三个阶段：

1. MULTI命令开始事务
2. 多个命令入队
3. EXEC执行事务

事务的处理机制

• 语法错误（编译）
• 执行错误（运行）

redis的持久化机制?

• Redis将数据保存在内存中。一旦服务器宕机重启，内存中的数据就会丢失。当出现这种情况后，为了能够让Redis进行数据恢复，因此Redis提供了持久化机制，将内存中的数据保存到磁盘中，避免数据意外丢失

RDB和AOF持久化的区别?

• RDB持久化是指在指定的时间间隔内将内存数据进行快照并保存在磁盘上，产生一个经过压缩的二进制文件，文件后缀名.rdb，RDB持久化触发机制分为：手动触发(Redis默认使用的是 bgsave来保存快照数据)和自动触发
• AOF会将客户端发送的所有更改数据的命令，记录到磁盘中的AOF文件当Redis重启后，通过读取AOF文件，按顺序获取到记录的数据修改命令，即可完成数据恢复。对于AOF的触发需要手动开启，修改redis.conf触发方式有三种：always、everysec、no。 默认使用everysec
• 当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复
• RDB持久化
  • 优点
    • 基于二进制文件完成数据备份，占用空间少，便于文件传输，方便持久化
    • 能够自定义规则，根据Redis繁忙状态进行数据备份
    • 容灾性好，性能最大化
    • 相对于数据集大时，比 AOF 的启动效率更高
  • 缺点
    • 无法保证数据完整性，会丢失最后一次快照后的所有数据
    • bgsave执行每次执行都会阻塞Redis服务进程创建子线程，频繁执行影响系统吞吐率
• AOF持久化
  • 优点
    • 数据安全性高
    • 内存消耗少，AOF文件达到阈值会触发重写优化
• RDB与AOF对比
  • RDB默认开启，AOF需手动开启
  • RDB性能优于AOF
  • AOF安全性优于RDB
  • AOF优先级高于RDB
  • RDB存储某个时刻的数据快照，AOF存储写命令
  • AOF丢失的数据少
• 具体使用根据应用场景
  • 如当前只追求高性能，不关注数据安全性，则关闭RDB和AOF
  • 如需较高性能且关注数据安全性，则开启RDB，并定制触发规则
  • 如更关注数据安全性，则开启AOF

redis高可用(集群策略)?

• 主从复制
  • 作用
    • 读写分离：主节点只负责写请求，从节点只负责读请求
    • 负载均衡：由slave分担master负载，并根据需求的变化，改变slave的数量
    • 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
    • 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
    • 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案
• 哨兵模式
  • 集群监控：负责监控 redis master 和 slave 进程是否正常工作
  • 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员
  • 故障转移：如果 master 挂掉了，会自动转移到 slave 上
  • 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址
• 集群节点哨兵模式
  • 哨兵至少需要 3 个，每个哨兵的配置都是一样的。
  • 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性
• redis Cluster分片集群：无中心化
  • 通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位，每份数据分片会存储在多个互为主从的多节点上，数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)。
  • 客户端如何定位数据
    • Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例，实例就会把哈希槽的分配信息发给客户端
• 总结
  • 主从复制可以实现自动切换，可用性更高，数据更大限度的防止丢失
  • 哨兵的集群保证高可用问题，减少误判率
  • redis Cluster分片集群解决了海量数据存储，高可用，高可扩

redis key的过期淘汰策略?

• 定时删除：在设置键的过期时间的同时，创建一个定时器，让定时器在键 的过期时间来临时，立即执行对键的删除操作
  • 对内存空间友好，对CPU不友好
• 惰性删除：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是 否过期，如果过期的话，就删除该键;如果没有过期，就返回该键
  • 对CPU友好，对内存空间不友好
• 定期删除：每隔一段时间程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定

redis 内存淘汰策略?

• 当大量的数据插入到redis，一些已经过期的key没有删除，会造成内存空间不足的问题
• 算法
  • LRU：Least Recently Used，它是以时间为基准，删除最近最久未被使用的key
  • LFU：Least Frequently Used，它是以频次为基准，删除最近最少未被使用的key
• 八种内存淘汰策略

• 不同策略的使用场景
  • 1、Redis只做缓存，不做DB持久化，使用allkeys。如状态性信息，经常被访问，但数据库不会修改。
  • 2、同时用于缓存和DB持久化，使用volatile。如商品详情页。
  • 3、存在冷热数据区分，则选择LRU或LFU。如热点新闻，热搜话题等。
  • 4、每个key被访问概率基本相同，选择使用random。如企业内部系统，访问量不大，删除谁对数据库也造成太大压力。
  • 5、根据超时时间长久淘汰数据，选择选用ttl。如微信过期好友请求。

redis缓存穿透的问题?
redis缓存击穿的问题?
redis缓存雪崩的问题?
redis实现分布式锁的原理?