Redis的数据类型String、Hash、List、Set、ZSet、HyperLogLogs、Bitmaps、StreamsRedis的使用及相关应用场景一、数据结构的特点1.HyperLogLogs基数统计统计访问次数我做过从订单出发统计某一商品的购买人数相同的userid只能算一次要是通过数据库做就只能保存一个json内容是全部的userid之后在去重放回去就慢而且长度会很长。2.hash结构业务上用的最频繁相当于一个带hash索引的对象数组购物车的设计。3.bitmap位统计某些用户的登录每日行为一年365个比特位有那几天是登录的。4.stream基于redis的消息队列可用作发布订阅。二、原子性的特点1.全局唯一自增id在分库分表的场景可以使用基因法去耦合关联主键比如关联后四位。上家公司的商品的sku的id的后四位就是spu的后四位也是分类的后四位这样未来考虑分库分表的时候三个维度的数据可以落在一块前面的位数就用redis的自增一批次的去获取。2.写lua脚本把一系列命令封装为原子性执行去实现具体的业务场景秒杀业务逻辑。3.分布式锁redisson的实现。三、时效性特点1.记录token、验证码做权限会话控制。2. 限流设定时间窗口防至多次调用针对下单接口可以指定userid在2秒钟之内只能调用一次。四、内存高效读取特点1.缓存针对业务场景持久缓存字典表、同步缓存订单数据、同步续期缓存热点商品、异步缓存数据量极大情况。2.redis search 分词类似es的基于redis的分词。数据持久化、过期和淘汰策略数据持久化一、RDB全量的二进制数据保存为一个.rdb的文件触发条件为 在一定的时间段内达到写操作的阈值数据恢复的时候快速二、AOF每秒钟都记录写命令至.aof文件达到文件阈值大小的时候会进行结果的重写把多条写命令合并在恢复的时候由于是一条条命令重放会比rdb慢很多。同时开启aof和rdb的话优先使用aof策略。持久化策略的最佳实践是使用删除rdb那三个阈值 不开启rdbaof-use-rdb-preamble yes采用混合持久化aof重写的时候采用rdb二进制的方式存储新的命令通过记录redis命令执行这样既能保证数据的可靠性又能保证恢复的速度。还有就是redis需要像数据库一样做备份把文件scp到其他服务器。redis的过期策略惰性删除get的时候过期了再去删除。定期删除默认为每秒10次抽一部分key进行过期排查若到期的key的占80%以上会继续进行二次删除排查这就导致局部时间吃cpu所以redis的key的过期时间不要全部相同需要随机。淘汰策略当redis内存快满的时候会进行key的淘汰。allkey-lru从所有的key中选择最近最少使用的key进行淘汰。常用配置volatile-lru设置了过期时间的key进行淘汰。不推荐因为内存都满了意味着cpu繁忙不能再去检查是否过期了lru一个队列栈淘汰栈底不断往栈顶加元素。lfu一个队列最少次数使用优先淘汰。特性LFULRU淘汰策略使用频率最低最近最少使用适合场景长期热点数据短期热点数据实现复杂度较高较低可能问题新加入项容易被淘汰频率低突发流量可能淘汰热点数据Big Key排查一、定义BigKey 是指存储在 Redis 中具有异常大尺寸的 key比如String 类型的 key其 value 是一个json对象读写都进行json序列化与反序列化操作。二、危害操作 BigKey 由于单线程Redis会导致命令阻塞慢查询数据倾斜持久化慢删除慢内存碎片的问题。三、排查 线上紧急先到的大keyredis-cli --bigkeys -i 0.1 # 每100毫秒采样一次查看key的占用redis-cli memory usage # Redis 4.0线下 rdb方式Redis-RDB-Tools 分析rdb文件不造成线上scan 的影响。四、解决方式使用unlink命令异步删除而不是delete同步方式将大对象拆成hash结构Redis 集群一、主从复制读写分离主库负责写操作从库负责读操作。缺点1.数据不一致风险异步复制可能导致从节点数据滞后。2.无自动故障转移主节点故障需要手动切换。二、哨兵模式在主从模式的基础上专门指派一个实例进行故障监控当主节点宕机以后进行自动切换。缺点资源浪费需要额外引入一个实例专门监控节点健康并且主节点负责读写。三、Redis Cluster三主三从redis分为16384个槽位组成一个hash环每个节点存放自己范围的槽位数据。满足hash一致性算法当节点不够需要扩充时也只需要局部的进行槽位移动就行。优点高扩展性Redis 集群模式支持多达 1000 个 Redis 节点可以方便地通过增加节点来扩展系统的性能。高容错性集群模式具有自动故障转移功能可以在节点故障后自动进行恢复。数据分片通过数据分片来存储数据提高了系统的存储能力和请求吞吐量。无中心架构Redis 集群采用无中心架构节点间数据共享可动态调整数据分布。缺点1.命令执行可能需要重定向一次因为第一次命令会发送至一个节点计算hash值若不是这个节点需要操作的key则需要返回客户端具体的执行节点重新发送一次操作命令客户端也会缓存。2.跨槽操作限制比如批量操作keymset和mget的时候需要确保所有的key都在同一节点上操作需要用到哈希标签把计算hash值的部分用花括号括起来强制将不同 Key 映射到同一槽。SET user:{1000}:name Alice和SET user:{1000}:age 30仅计算{1000}的哈希值确保同槽。四、缓存问题一、缓存穿透频繁查询不存在的key导致数据频繁调用。1.布隆过滤器存在不一定存在不存在一定不存在提前缓存已经存在的key2.缓存空对象即使是不存在的结果也缓存null值。3. 提前校验请求参数的合法性比如id必须符合业务规则。二、缓存击穿同一时间访问一个热点的key导致大量请求同时到达。1.提前预热热点key。2.为不同的key设置随机的过期时间防止同时失效。三、缓存雪崩同一时间大量的key过期导致大量请求数据库。1.为不同key设置随机的过期时间防止同时过期。2.多级缓存比如本地缓存EcacheRedis缓存。