网站建设报价单 下载,郑州网站建设 云极,东莞感染人数最新消息,百度移动端排名软件文章目录一、Redis为什么快#xff1f;1、纯内存访问2、单线程#xff0c;避免上下文切换3、渐进式ReHash、缓存时间戳#xff08;1#xff09;渐进式ReHash#xff1a;#xff08;2#xff09;缓存时间戳#xff1a;二、Redis合适的应用场景常用基本数据类型#xff…
文章目录一、Redis为什么快1、纯内存访问2、单线程避免上下文切换3、渐进式ReHash、缓存时间戳1渐进式ReHash2缓存时间戳二、Redis合适的应用场景常用基本数据类型5种1、字符串String1缓存2计数器3分布式会话共享Session2、哈希Hash3、列表list1消息队列2文章列表4、集合set1标签tag2随机数抽奖活动3社交图谱5、有序集合ZSET1排行榜Redis高级数据结构6、Bitmaps1布隆过滤器7、HyperLogLog1UV三、Redis为什么6.0之前不支持多线程1、Redis的瓶颈不是CPU受制于内存、网络2、提高Redis性能Pipeline命令批量3、单线程内部维护成本相对较低不需要管理多线程安全4、多线程线程切换、加锁/解锁、导致死锁问题5、惰性Rehash渐进式减少阻塞四、Redis为什么6.0之后引入多线程本质多线程任务 分摊到Redis 同步IO中读写负载。五、Redis有哪些高级功能1慢查询2Pipeline3watch命令4RedisLua语言实现限流5分布式锁锁的过期时间不好计算解决方案分布式锁加入看门狗6高并发高可用7哨兵Redis Sentinel主从复制的问题六、为什么需要使用Redis1、高性能2、高并发七、Redis的事务八、Redis的过期策略以及内存淘汰机制1、内存淘汰机制2、过期策略3、缓存淘汰算法九、什么是缓存穿透如何避免布隆过滤器的应用十、什么是缓存雪崩如何避免原因1、Redis失效、宕机故障2、Redis大量key的ttl过期十一、Redis如何设计分布式锁1、概念2、问题十二、什么是bigkey会有什么影响1、概念2、字符串类型3、非字符串类型4、危害5、解决方案value拆分十三、Redis如何解决key冲突1、业务隔离2、key的设计3、分布式锁4、时间戳十四、怎么提高换成命中率1、提前加载2、增加缓存的存储空间增加缓存的数据3、调整缓存的存储类型4、调整缓存的存储类型十五、Redis持久化方式有哪些方式有什么区别1、持久化2、RDBRedis DataBse3、AOF4、生产环境中一般采用混合两者的方式十六、为什么Redis需要把所有数据放到内存中1、内存访问与磁盘访问的差距2、Redis通过异步持久化将数据写入磁盘3、随着技术的发展硬件上来说内存也越来越便宜了4、默认情况下哪怕Redis内存不够了也不会发生宕机而是只可读不能写Noeviction策略5、通过内存淘汰策略确保整体服务正常运行十七、如何保证缓存与数据库双写一致性1、新增数据类2、更新缓存类1先更新缓存在更新DB一般不考虑2先更新DB在更新缓存一般不考虑3、删除缓存3先删除缓存后更新DB问题解决方案4先更新DB后删除缓存4、如何选择伪代码实现延迟双删十八、Redis集群方案1、分布式解决方案 Redis Cluster方案1客户端分区2代理方案2、虚拟槽分区0~163833、集群功能限制4、搭建集群十九、Redis集群方案什么情况下会导致整个集群不可用集群不可用判定二十、Redis集群会有写操作丢失吗为什么二十一、Redis常见性能问题和解决方案1、持久化 性能问题2、数据比较重要开启AOF。策略最好配置每秒同步。3、主从复制 流畅建议同一个局域网内操作负责网络开销过大4、尽量避免主库压力过大增加从库5、主从复制 尽量不要使用网状结构、线性结构二十二、热点数据和冷数据1、热数据2、冷数据二十三、什么情况下可能会导致Redis阻塞1、客户端阻塞2、BIGkey删除3、清空库4、AOF日志同步写记录AOF日志5、从库 加载RDB文件6、Redis尽量部署在独立的服务器中二十四、线上Redis响应慢处理思路一、Redis为什么快
1、纯内存访问
相比查询数据库访问磁盘要快很多
2、单线程避免上下文切换
内部执行命令为单线程避免上下文切换带来的CPU开销
3、渐进式ReHash、缓存时间戳
1渐进式ReHash
Redis使用全局哈希表来保存所有键值对
哈希表相当于一个数组数组的每个元素称为一个哈系桶每个哈系桶中保存了键值对的数据。 数据增加到一定阈值数组扩容会导致数据发生移动此时访问会发生阻塞
渐进式ReHash把一次性大量拷贝数组移动的开销分摊到多次处理请求的过程中。
Redis默认使用两种全局哈希表开始插入数据时默认使用哈希表1此时哈希表2并没有被分配空间。随着数据逐步增多开始执行ReHash。
给哈希表2分配更大的空间将哈希表1中的数据重新映射并拷贝到哈希表2中释放哈希表1的空间 2缓存时间戳
业务中需要用到时间戳时一般会使用System.currentTimeMillis()或者New Date()等方式获取系统的毫秒时间戳每一次获取都是一次系统调用需要调用操作系统中对应的函数涉及上下文切换相对比较耗时。
作为单线程的Redis承受不起因此它由一个定时任务每毫秒更新一次缓存获取时间都是从缓存中直接拿。
二、Redis合适的应用场景
常用基本数据类型5种
名称英文名作用域字符串String缓存、计数器、分布式Session哈希Hash存放对象列表list消息队列、文章列表集合set标签、随机数、社交图谱有序集合ZSET排行榜BitmapsBitmaps布隆过滤器HyperLogLogHyperLogLogUV
1、字符串String
命令的时间复杂度
字符串这些命令中除了del、mset、mget支持多个键的批量操作时间复杂度和键的个数相关为O(n)getrange的字符串长度相关也是O(n)其余的命令基本上都是O(1)的时间复杂度在速度上还是非常快的。
1缓存
具有支撑高并发的特性能起到加速读写的作用降低后端压力
2计数器
实现快速计数、查询缓存的功能同时数据可以异步落地到其他数据源
3分布式会话共享Session
问题如果一个分布式Web服务将用户的Session信息保存在各自服务器中出于负载均衡的考虑分布式服务会将用户的访问均衡到不同服务器上用户刷新一次访问可能会发现需要重新登录。
解决方案使用Redis将用户的Session进行集中管理这种情况下只要保证Redis是高可用和扩展性的每次用户更新或查询登录信息都直接从Redis集中获取。
2、哈希Hash
适用于存放对象相较于String类型存储对象时效率开发效率更高。
3、列表list
用来存储多个有序字符串
1消息队列
lpushbrpop命令组合即可实现阻塞队列生产环境客户端使用lpush从列表左侧插入元素多个消费者客户端使用brpop命令阻塞式的”抢“列表尾部的元素多个客户端保证了消费的负载均衡和高可用性。
2文章列表
每个用户有属于自己的文章列表现需要分页展示文章列表。此时可以考虑使用列表有序且支持按照索引范围获取元素。
还可实现其他数据结构 4、集合set
1标签tag
例如一个用户可能对娱乐、体育感兴趣另一个用户可能对历史、新闻感兴趣这些兴趣点就是标签。通过这些数据可以得到喜欢同一个标签的人这些数据对于用户体验以及增强用户粘度比较重要。
2随机数抽奖活动
3社交图谱
5、有序集合ZSET
1排行榜
多维度时间、浏览量、获赞数等等。
Redis高级数据结构
6、Bitmaps
可以实现对位的操作单独提供了一套命令可以想象成以位为单位的数组数组下标叫做偏移量。 1布隆过滤器 7、HyperLogLog
1UV
统计每个网页每天的UC数据HyperLogLog提供不精确的去重计数方案误差0.81% 三、Redis为什么6.0之前不支持多线程
1、Redis的瓶颈不是CPU受制于内存、网络
存储于内存快速读写网络开销大
2、提高Redis性能Pipeline命令批量
每秒100万个请求包装进Pipeline
3、单线程内部维护成本相对较低不需要管理多线程安全
命令执行顺序不确定性读写并发问题
4、多线程线程切换、加锁/解锁、导致死锁问题
5、惰性Rehash渐进式减少阻塞
一般的公司单线程Redis就够了。
四、Redis为什么6.0之后引入多线程
1、小数据包。数据-》内存 响应时间 100ns 8w-10wQPS极限
2、针对大的公司需要更大的QPSIO的多线程内部执行命令还是单线程
3、为什么不采用分布式架构—很大的缺点。
服务器数量多维护成本高。Redis命令 不适用 需要数据分区无法解决热点数据读写的问题。
数据倾斜、重新分配、扩容、缩容更加复杂。
本质多线程任务 分摊到Redis 同步IO中读写负载。
五、Redis有哪些高级功能
1慢查询
快速定位系统中的慢操作监测发生时间、耗时、命令的详细信息。
2Pipeline 3watch命令
确保事务中的key有没有被其他客户端修改过才执行事务否则不执行类似于乐观锁。
4RedisLua语言实现限流 5分布式锁
首先需要Redis有互斥的能力可以使用SETNX命令即如果key不存在才会设置它的值否则什么也不做。两个客户端进程可以执行这个命令达到互斥就可以实现一个分布式锁。
锁的过期时间不好计算 解决方案分布式锁加入看门狗
加锁时先设置一个过期时间然后开启**“守护线程”**定时检测这个锁的失效时间如果快要过期了操作共享资源还未完成则自动对锁进行续期重新设置过期时间。
6高并发高可用
主从复制:
提供了复制功能实现了相同数据的多个Redis副本。每个主节点可以对应多个从节点复制的数据流只能由主节点复制到从节点。 7哨兵Redis Sentinel
背景主从复制模式下主节点故障需要人工将从节点晋升为主节点。
2,8版本开始提供哨兵架构解决此问题。
主从复制的问题
需要手动晋升子节点同时需要修改应用方的节点地址。主节点的写能力收到单机限制主节点的存储能力收到单机的限制
六、为什么需要使用Redis
1、高性能
Mysql磁盘毫秒级
Redis内存微秒级
更新策略项目启动时全量同步热点数据
2、高并发
Mysql 并发量1000/s
Redis 并发量100000/s
集群架构 七、Redis的事务 回滚机制上Redis只能对基本语法错误进行判断。运行时错误无法回滚。
八、Redis的过期策略以及内存淘汰机制
1、内存淘汰机制 定期删除定时扫描策略 设置了过期时间的key放入独立字典Redis默认会每秒进行十次过期扫描不会遍历Key而是采用简单的贪心策略。 从过期字典中随机20个key删除其中已经过期的如果过期比例超过1/4则重复真个步骤 一定要注意过期时间如果大批量key过期雪崩需要给过期时间设置一个时间范围不能全部同一时间过期 惰性删除 客户端访问key的时候redis对key的过期时间进行检查如果过期就立即删除不会返回任何东西。
总结定期删除是集中处理惰性删除是零散处理。
2、过期策略 从库的过期策略 没有过期扫描被动执行。 主库key到期时在AOF文件里增加一条del指令同步到所有从库。
3、缓存淘汰算法
当Redis内存超出物理内存限制时内存数据开始和磁盘产生频繁的交换此时性能会急剧下降。
通过maxmemory参数设置最大使用内存。
当内存超出时Redis提供了集中策略来决定如何腾出新空间 Noeviction默认情况下不淘汰。超出maxmemory时只可读、删不准写。 volatile-lru尝试设置了过期时间的key最少使用的key先淘汰没有设置过期时间的key不会被淘汰。 volatile-ttlkey的剩余寿命ttl的值ttl越小越优先被淘汰。 volatile-random淘汰过期集合中随机的key。 allkeys-lru淘汰的key对象是全体的key集合。 allkeys-random淘汰的key对象是全体的key集合中随机的key。 LRU算法附加一个链表按照一定顺序排列。空间满时会踢掉链表尾部的元素。当链表中的某个元素被访问时它会移动到链表的表头。链表元素排列顺序相当于元素最近被访问的时间顺序。 近似LRU算法Redis使用的此算法使用LRU的原因是该链表需要消耗大量额外内存。 在现有的数据结构上使用随机采样法来淘汰元素。给每个key增加一个额外的小字段24bit最后一次访问的时间戳。 随机采样5maxmemory-sample个key淘汰最旧的重复该操作至内存低于maxmemory。
九、什么是缓存穿透如何避免
布隆过滤器的应用 十、什么是缓存雪崩如何避免
原因
1、Redis失效、宕机故障
搭建Redis集群主从架构RDB持久化、IOF持久化加入缓存组件EHCache搭建多级缓存容易高并发的数据存入加入限流组件hystrix超过一定流量后增加请求限制保护数据处理层
2、Redis大量key的ttl过期
ttl过期时间岔开增加随机值避免同一时间全部失效。 十一、Redis如何设计分布式锁
1、概念
锁同一时间只允许一个线程或者一个应用程序进入执行分布式锁必须要求Redis有【互斥】能力可以使用SETNX命令即key不存在了才会设置它的值否则什么也不做。
2、问题 如何避免死锁 场景程序处理业务逻辑异常或者进程挂了无法释放锁 避免方案给锁设置租期过期时间 锁的过期时间不好评估这么办 加入看门狗开启守护线程定期检测锁的失效时间如果快要过期了业务还没执行完则续期。
十二、什么是bigkey会有什么影响
1、概念
key对应的value所占内存空间较大
例如一个字符串类型的value最大存到512M一个列表类型的value最大可以存储2的32次方-1个元素。
2、字符串类型
体现在单个value值特别大一般认为超过10kb就是bigkey和具体OPS相关不同系统不同并发。
3、非字符串类型
哈希、列表、集合、有序集合体现在元素个数过多。
4、危害 内存空间不均匀 超时堵塞单线程操作bigkey比较耗时 网络拥塞每次获取bigkey产生的网络流量较大 例如一个bigkey为1MB每秒访问为1000则每秒产生1000MB的流量普通千兆网按照字节算是128MB/s的服务器是灭顶之灾而且服务器通常会采用单机多实例的方式来部署可能会对其他实例造成影响。
5、解决方案value拆分
十三、Redis如何解决key冲突
1、业务隔离
2、key的设计
业务模块系统名称关键id针对用户可以加入userid
3、分布式锁
场景多个客户端并发写key
客户端拿到锁才能进行操作避免多个客户端竞争该key
4、时间戳
key拼接时间戳根据时间戳保证多个客户端的业务执行顺序
十四、怎么提高换成命中率
1、提前加载
2、增加缓存的存储空间增加缓存的数据
3、调整缓存的存储类型
例对象通过Hash存储而不用String。
根据业务做适当调整。
4、调整缓存的存储类型
定时任务更新MySQL通过检测binlog将消息推送到Redis更新缓存通过Mq业务更新修改数据时通过MQ发送消息消费更新缓存
十五、Redis持久化方式有哪些方式有什么区别
1、持久化
将数据写往磁盘可以有效避免因进程退出造成的数据丢失下次重启时利用之前持久化的文件恢复数据。
2、RDBRedis DataBse
当前数据生成快照内存中的数据在某一时刻的状态记录保存到硬盘的过程。
缺点两次快照有时间间隔。
3、AOF
已独立日志的方式记录每次写命令重启时重新执行AOF文件中的命令恢复数据。
缺点性能较差。
4、生产环境中一般采用混合两者的方式
如果执行bgrewriteaof命令将内存中已有的数据以二进制格式存放在AOF文件中模拟RDB后续命令亦然采用AOF追加方式。 十六、为什么Redis需要把所有数据放到内存中
1、内存访问与磁盘访问的差距 几乎是10倍以上如果不是顺序读取而是随机读取效率会相差更大同时还有CPU上下文切换的开销
2、Redis通过异步持久化将数据写入磁盘
3、随着技术的发展硬件上来说内存也越来越便宜了
4、默认情况下哪怕Redis内存不够了也不会发生宕机而是只可读不能写Noeviction策略
5、通过内存淘汰策略确保整体服务正常运行
十七、如何保证缓存与数据库双写一致性
1、新增数据类
新增数据时数据会直接写入数据库不用对缓存做任何操作此时缓存没有新增数据而数据库中是最新值。
2、更新缓存类
1先更新缓存在更新DB一般不考虑
原因缓存更新成功更新数据库时出现异常会导致数据源与缓存数据完全不一致而且很难察觉因为缓存中的数据一直都存在。
2先更新DB在更新缓存一般不考虑
原因数据库更新成功了缓存更新失败了同样会导致数据源与缓存数据完全不一致也很难察觉。
3、删除缓存
3先删除缓存后更新DB
问题
两个请求A更新和B查询
A - 删除缓存中的数据 - 更新数据库
B - 查询缓存为空 - 查询数据库 - 补录到缓存
A - 还未更新成功/事务还未提交B - 查询到的其实是数据库旧值
解决方案
先淘汰缓存再写数据库休眠1秒再次淘汰缓存
这个休眠的时间需要评估项目的读数据业务逻辑的耗时确保请求结束时写请求可以删除读请求造成的缓存脏数据。
4先更新DB后删除缓存
查询先读缓存 - 缓存没有就读数据库 - 取出数据放入缓存 - 同时返回响应。
更新先更新数据库 - 删除缓存
4、如何选择
一般线上更多偏向于删除缓存类操作容易避免问题
原因
删除缓存比在DB中要快所以一般先更新DB后删除缓存问题只会出现在查询比删除慢的情况出现率相对最少同时延迟双删可以有效避免缓存不一致情况。 伪代码实现延迟双删
redis.deykey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)十八、Redis集群方案
1、分布式解决方案 Redis Cluster
3.0版本推出
场景单机内存、并发、流量等瓶颈
方案
1客户端分区
优点分区逻辑可控
缺点需要处理数据路由、高可用、故障转移等问题
2代理方案
优点简化客户端分布式逻辑升级维护便利
缺点加重架构部署复杂度和性能损耗
2、虚拟槽分区0~16383 主节点数量基本不可能超过1000个节点连接需要不断发送ping/pong命令消耗网络带宽
3、集群功能限制
1key批量操作支持有限mset、mget仅支持相同slot值的key。
2key事务操作支持有限仅支持在同一节点上的事务操作。
3key作为数据分区的最小颗粒度不允许大的键值对hash、list映射在不同节点。
4不支持多数据库空间。单机为0-1516个集群模式仅能使用db0。
5复制结构仅支持一层节点只能复制到主节点不支持嵌套树状复制结构。
4、搭建集群
方式:
1Redis协议手工搭建。
25.0之前有ruby语言脚本搭建。
35.0之后搭建功能合并至redis-cli。
节点数至少奇数点个官方推荐三主三从。
十九、Redis集群方案什么情况下会导致整个集群不可用
A、B、C三个节点集群B节点失败主故障且没有替代方案整个集群都是不可用的。
集群不可用判定
保护措施默认情况下当16384个槽点任何一个没有指派到节点时整个集群不可用。
主节点下线-故障发现-自动完成转移期间整个集群为不可用状态。
可用通过设置cluster-require-full-coverage配置为no主节点故障时不影响其他主节点的可用性。
二十、Redis集群会有写操作丢失吗为什么
Redis无法保证数据的强一致性
一般只能向主节点写入数据再异步同步到子节点
此时如果响应给客户端后还未异步同步成功时主节点宕机了子节点升至主节点此时就会出现写入操作丢失。
二十一、Redis常见性能问题和解决方案
1、持久化 性能问题
早期仅支持全量复制-部分复制一台机器性能开销过大
因此开始配置主从 主节点不再做持久化而是交给从节点来做
2、数据比较重要开启AOF。策略最好配置每秒同步。
3、主从复制 流畅建议同一个局域网内操作负责网络开销过大
4、尽量避免主库压力过大增加从库
5、主从复制 尽量不要使用网状结构、线性结构
二十二、热点数据和冷数据
1、热数据
访问频次较高考虑使用缓存Redis
地图信息
点赞数、收藏数、分享数不断变化同步Redis
数据更新之前至少读取2次才能放缓存
2、冷数据
访问频次少
不需要放缓存
二十三、什么情况下可能会导致Redis阻塞
1、客户端阻塞
命令执行时间过长 keys* Hgetall smembers 时间复杂度O(N)
2、BIGkey删除
需要释放大量占用内存 zset100万的元素 删除大概需要2s
3、清空库
flushdb flushall 涉及删除所有键值对
4、AOF日志同步写记录AOF日志
大量写的操作
1一个同步写磁盘操作大概耗时1~2ms
5、从库 加载RDB文件
RDB文件过大
6、Redis尽量部署在独立的服务器中
二十四、线上Redis响应慢处理思路 1、紧急处理方案扩容 2、生产环境查看Redis内存使用率分析一定时间段内key数量变化 分析是否是大量数据未设置过期时间或者是因为新版本迭代引起 3、清除bigkey优化生成bigkey的代码块调整未设置过期时间的代码块 4、根据业务场景调整淘汰策略
