字符串#xff08;strings#xff09;#xff0c;

散列#xff08;hash…Redis

是一个开源BSD许可的内存中的数据结构存储系统它可以用作数据库、缓存和消息中间件。

字符串strings

C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库并提供多种语言的API。

redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件并且在此基础上实现了master-slave(主从)同步。

也被人们称之为结构化数据库

String是Redis中最常用的一种数据类型也是Redis中最简单的一种数据类型。

首先表面上它是字符串但其实他可以灵活的表示字符串、整数、浮点数3种值。

Redis会自动的识别这3种值。

添加、查询、追加、获取长度判断是否存在的操作自增、自减操作截取、替换字符串操作设置过期时间、不存在设置操作mset、mget操作添加获取对象、getset操作

List(列表)

lpush左插入、lrange查询集合、rpush右插入操作lpop左移除、rpop右移除操作lindex查询指定下标元素、llen获取集合长度

操作lrem根据value移除指定的值ltrim截取元素、rpoplpush移除指定集合中最后一个元素到一个新的集合中操作lset更新、linsert操作

Set(集合)

sadd添加、smembers查看所有元素、sismember判断是否存在、scard查看长度、srem移除指定元素操作srandmember抽随机操作spop随机删除元素、smove移动指定元素到新的集合中操作sdiff差集、sinter交集、sunion并集操作

Hash(哈希)

hset添加hash、hget查询、hgetall查询所有、hdel删除hash中指定的值、hlen获取hash的长度、hexists判断key是否存在操作

hkeys获取所有key、hvals获取所有value、hincrby给值加增量、hsetnx存在不添加操作

比String更加适合存对象~

zadd添加、zrange查询、zrangebyscore排序小-大、zrevrange排序大-小、zrangebyscore

withscores查询所有值包含key操作zrem移除元素、zcard查看元素个数、zcount查询指定区间内的元素个数操作

三大特殊类型

geoadd添加、geopos查看、geodist计算距离操作georadius查询附近位置操作georadiusbymember

返回经纬度的hash值、zrange、zrem使用zset命令操作geo

两极无法直接添加我们一般会下载城市数据直接通过java程序一次性导入有效的经度从-180度到180度。

有效的纬度从-85.05112878度到85.05112878度。

m

实际需求中我们可以用来查询附近的人、计算两人之间的距离等。

当然那些所需的经纬度我们肯定要结合java代码来一次导入手动查询和录入太过于浪费时间

Hyperloglog(基数)

pfadd添加数据集、pfcount统计数据集、pfmegre合并数据集-自动去重

如果在实际业务中允许一定的误差值我们可以使用基数统计来计算~效率非常高比如网站的访问量就可以利用Hyperloglog来进行计算统计

Bitmap(位存储)

实际需求中可能需要我们统计用户的登陆信息员工的打卡信息等等。

只要是事务的只有两个状态的我们都可以用Bitmap来进行操作

实现事务

正常执行事务放弃事务编译时异常代码有问题或者命令有问题所有的命令都不会被执行运行时异常除了语法错误不会被执行且抛出异常后其他的正确命令可以正常执行

总结由以上可以得出结论Redis是支持单条命令事务的但是事务并不能保证原子性

实现乐观锁

当程序中可能出现并发的情况时就需要保证在并发情况下数据的准确性以此确保当前用户和其他用户一起操作时所得到的结果和他单独操作时的结果是一样的。

没有做好并发控制就可能导致脏读、幻读和不可重复读等问题。

当程序中可能出现并发的情况时就需要保证在并发情况下数据的准确性以此确保当前用户和其他用户一起操作时所得到的结果和他单独操作时的结果是一样的。

没有做好并发控制就可能导致脏读、幻读和不可重复读等问题。

jedis

在Jedis中连接使用Redis和Redis控制台命令完全一致

Springboot整合Redis

在1.×版本的时候SpringBoot的底层还是使用Jedis来连接Redis的但是在2.×版本后就换成了Lettuce。

Jedis:

采用netty实例可以再多个线程中进行共享不存在线程不安全的情况可以减少线程数据了更像

NIO

.aof文件Redis是内存数据库如果没有持久化那么数据断电即失

SECURITY

是内存数据库如果不将内存中的数据库状态保存到磁盘那么一旦服务器进程退出服务器中的数据库状态也会消失。

所以

Redis

Database)是Redis默认采用的持久化方式它以快照的形式将进程数据持久化到硬盘中。

RDB会创建一个经过压缩的二进制文件文件以“.rdb”结尾内部存储了各个数据库的键值对数据等信息。

Redis会单独创建fork一个子进程来进行持久化会先将数据写入到一个临时文件中待持久化过程都结束了再用这个临时文件替换上次持久化好的文件。

整个过程中主进程是不进行任何IO操作的。

RDB生成紧凑压缩的二进制文件体积小使用该文件恢复数据的速度非常快

BGSAVE每次运行都要执行fork操作创建子进程属于重量级操作不宜频繁执行所以RDB持久化没办法做到实时的持久化。

触发方式

通过SAVE或BGSAVE命令触发RDB持久化操作创建“.rdb”文件

自动触发

SAVE命令执行期间Redis服务器将阻塞直到“.rdb”文件创建完毕为止。

BGSAVE

而BGSAVE命令是异步版本的SAVE命令它会使用Redis服务器进程的子进程创建“.rdb”文件。

AOF

File解决了数据持久化的实时性是目前Redis持久化的主流方式。

AOF以独立日志的方式记录了每次写入命令重启时再重新执行AOF文件中的命令来恢复数据。

(AOF以文本协议格式写入命令)

与RDB持久化可能丢失大量的数据相比AOF持久化的安全性要高很多。

通过使用everysec选项用户可以将数据丢失的时间窗口限制在1秒之内。

(文件同步机制改进)

AOF文件存储的是协议文本它的体积要比二进制格式的”.rdb”文件大很多。

AOF需要通过执行AOF文件中的命令来恢复数据库其恢复速度比RDB慢很多。

AOF在进行重写时也需要创建子进程在数据库体积较大时将占用大量资源会导致服务器的短暂阻塞。

工作流程

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

优点:

文本协议具有很好的兼容性直接采用文本协议格式可以避免二次处理的开销文本协议具有可读性方便直接修改和处理。

文件同步机制

为了提高程序的写入性能现代操作系统会把针对硬盘的多次写操作优化为一次写操作。

当程序调用write对文件写入时系统不会直接把书记写入硬盘而是先将数据写入内存的缓冲区中当达到特定的时间周期或缓冲区写满时系统才会执行flush操作将缓冲区中的数据冲洗至硬盘中

这种优化机制虽然提高了性能但也给程序的写入操作带来了不确定性,为了消除上述机制的不确定性Redis向用户提供了appendfsync选项来控制系统冲洗AOF的频率

RDB-AOF混合

Redis从4.0开始引入RDB-AOF混合持久化模式这种模式是基于AOF持久化构建而来的。

用户可以通过配置文件中的“aof-use-rdb-preamble

通过使用RDB-AOF混合持久化用户可以同时获得RDB持久化和AOF持久化的优点服务器既可以通过AOF文件包含的RDB数据来实现快速的数据恢复操作又可以通过AOF文件包含的AOF数据来将丢失数据的时间窗口限制在1s之内。

像执行BGSAVE命令一样根据数据库当前的状态生成相应的RDB数据并将其写入AOF文件中对于重写之后执行的Redis命令则以协议文本的方式追加到AOF文件的末尾即RDB数据之后。

Redis发布订阅

Redis发布订阅pub/sub是一种消息通信模式发送者pub发送消息订阅者sub接受消息。

(类似于消息队列)

Pub/Sub

从字面上理解就是发布Publish与订阅Subscribe在Redis中你可以设定对某一个key值进行消息发布及消息订阅当一个key值上进行了消息发布后所有订阅它的客户端都会收到相应的消息。

这一功能最明显的用法就是用作实时消息系统比如普通的即时聊天群聊等功能。

主从复制

是指将一台Redis服务器的数据复制到其他的Redis服务器。

前者称为主节点(master/leader)后者称为从节点(slave/follower)数据的复制是单向的只能由主节点到从节点。

Master以写为主Slave

数据冗余

当主节点出现问题时可以由从节点提供服务实现快速的故障恢复实际上是一种服务的冗余。

负载均衡

在主从复制的基础上配合读写分离可以由主节点提供写服务由从节点提供读服务即写Redis数据时应用连接主节点读Redis数据时应用连接从节点分担服务器负载尤其是在写少读多的场景下通过多个从节点分担读负载可以大大提高Redis服务器的并发量。

除了上述作用以外主从复制还是哨兵和集群能够实施的基础因此说主从复制是Redis高可用的基础。

Redis使用psync命令完成主从数据同步同步过程分为全量复制和部分复制。

全量复制一般用于初次复制的场景部分复制则用于处理因网络中断等原因造成数据丢失的场景。

psync命令参数

Sentinel哨兵是一个分布式架构它包含若干个哨兵节点和数据节点。

每个哨兵节点会对数据节点和其余的哨兵节点进行监控当发现节点不可达时会对节点做下线标识。

如果被标识的是主节点它就会与其他的哨兵节点进行协商当多数哨兵节点都认为主节点不可达时它们便会选举出一个哨兵节点来完成自动故障转移的工作同时还会将这个变化实时地通知给应用方。

整个过程是自动的不需要人工介入有效地解决了Redis的高可用问题

哨兵模式是一种特殊的模式首先Redis提供了哨兵的命令哨兵是一个独立的

作为进程它会独立运行。

其原理是哨兵通过发送命令等待Redis服务器响应从而监控运行的多个Redis实例。

哨兵集群基于主从复制模式

的集群容量一旦到达上限在线扩容就十分麻烦②实现哨兵模式的配置其实是很

哨兵节点会定期监控数据节点其他哨兵节点是否可达哨兵节点会将故障转移的结果通知给应用方哨兵节点可以将从节点晋升为主节点并维护后续正确的主从关系哨兵模式下客户端连接的是哨兵节点集合从中获取主节点信息节点的故障判断是由多个哨兵节点共同完成的可有效地防止误判哨兵节点集合是由多个哨兵节点组成的即使个别哨兵节点不可用整个集合依然是健壮的哨兵节点也是独立的Redis节点是特殊的Redis节点它们不存储数据只支持部分命令。

缓存问题

用户需要查询一个数据但是redis中没有比如说mysql中id-1的数直接去请求MySQL当很多用户同时请求并且都么有命中于是都去请求了持久层的数据库那么这样会给持久层数据库带来非常大的压力。

一般出现这样的情况都不是正常用户基本上都是恶意用户

解决方案

布隆过滤器可以用很低的代价估算出数据是否真实存在。

例如给用户推荐新闻时要去掉重复的新闻就可以利用布隆过滤器判断该新闻是否已经推荐过。

核心

一个大型的位数组若干个不一样的哈希函数每个哈希函数都能将哈希值算的比较均匀

工作原理

添加key时每个哈希函数都利用这个key计算出一个哈希值再根据哈希值计算一个位置并将位数组中这个位置的值设置为1。

询问key时每个哈希函数都利用这个key计算出一个哈希值再根据哈希值计算一个位置。

然后对比这些哈希函数在位数组中对应位置的数值

如果这几个位置中有一个位置的值是0就说明这个布隆过滤器中不存在这个key。

如果这几个位置中所有位置的值都是1就说明这个布隆过滤器中极有可能存在这个key。

之所以不是百分之百确定是因为也可能是其他的key运算导致该位置为1。

缓存空对象

当存储层查不到即使是空值我们也将其存储起来并且在Redis中设置一个过期时间之后再访问这个数据将会从Redis中访问保护了持久层的数据库

如果空值能够被缓存起来这就意味着缓存需要更多的空间存储更多的键因为这当中可能会有很多的空值的键即使对空值设置了过期时间还是会存在缓存层和存储层的数据会有一段时间窗口的不一致这对于需要保持一致性的业务会有影响。

缓存击穿

是指一个非常热点的key在不停的扛着大并发当这个key失效时一瞬间大量的请求冲到持久层的数据库中就像在一堵墙上某个点凿开了一个洞

解决方案

在查询持久层数据库时保证了只有一个线程能够进行持久层数据查询其他的线程让它睡眠几百毫秒等待第一个线程查询完会回写到Redis缓存当中剩下的线程可以正常查询Redis缓存就不存在大量请求去冲击持久层数据库了

热点Key问题

热key问题就是某个瞬间有大量的请求去访问Redis上某个固定的key导致缓存击穿请求都打到了DB上压垮了缓存服务和DB服务从而影响到应用服务可用的可用性

热点key判断

通常以Key被请求频率来判定目前没有很具体的数值来定义热keyQPS集中在特定的KeyRedis实例的总QPS每秒查询率为2W而其中一个Key的每秒访问量达到了1W以上带宽使用率集中在特定的Key对一个拥有上千个成员且总大小为1MB以上的HASH

Key每秒发送大量的HGETALL操作请求CPU使用时间占比集中在特定的Key对一个拥有数万个成员的KeyZSET类型每秒发送大量的ZRANGE操作请求

流量集中达到物理网卡上限

当某一热点Key的请求在某一节点所在的主机上超过该主机网卡流量上限时由于流量的过度集中会导致该节点的服务器中其它服务无法进行

Redis单点查询性能是有限的当热点key的查询超过Redis节点的性能阈值时请求会占用大量的CPU资源影响其他请求并导致整体性能降低严重时会导致缓存分片服务被打垮表现形式之一就是Redis节点自重启此时该节点存储的所有key的查询都是不可用状态会把影响辐射到其他业务上

集群架构下产生访问倾斜

即某个数据分片被大量访问而其他数据分片处于空闲状态可能引起该数据分片的连接数被耗尽新的连接建立请求被拒绝等问题

击穿引起业务雪崩

比如某一个整点秒杀活动活动信息的key、存放头部楼层的秒杀商品的信息的key一般就是热点key但是并不是每个热key都能被准确的预测如对于电商平台来说商家什么时候会上架相对火爆的秒杀活动就很难预测了但是可以借助对不同商家的历史活动的数据分析来做一定的参考

业务侧自行监控和收集

这个方式就是在操作redis之前加入一行代码进行数据统计异步上报行为如类似日志采集将单次redis命令的操作/结果/耗时等统计异步消息发送给采集消息队列

一般可以交给中间件加在自己包的redis二方包中如果有做的好一点的Daas平台可以在proxy层做监控业务无需感知统一在Daas平台查看redis监控

用redis自带命令

monitor命令该命令可以实时抓取出redis服务器接收到的命令然后写代码统计出热key是啥当然也有现成的分析工具可以给你使用比如redis-faina但是该命令在高并发的条件下有内存增暴增的隐患还会降低redis的性能。

hotkeys参数redis

4.0.3提供了redis-cli的热点key发现功能执行redis-cli时加上–hotkeys选项即可但是该参数在执行的时候如果key比较多执行起来比较慢参考Redis

4.0热点Key查询方法但是一般公司是不允许直接连接redis节点自己输入命令的而是直接通过Daas平台查看热点key的分析和监控

解决方案

使用本地缓存如利用ehcache、GuavaCache等甚至是一个HashMap都可以在发现热key以后把热key加载到系统的JVM中针对这种热key请求会直接从本地缓存中取而不会直接请求redis本地缓存天然的将同一个key的大量请求根据网络层的负载均衡均匀分散到了不同的机器节点上避免了对于固定key全部打到单个redis节点的情况并且减少了1次网络交互使用本地缓存不可避免的遇到的问题就是对于要求缓存强一致性的业务来说需要花费更多的精力在保证分布式缓存一致性上会增加系统的复杂度

不要让固定key老是走到同一台redis节点上我们把这个key在多个redis节点上都备份一份即可在有热key请求进来的时候我们就在有备份的redis上随机选取一台进行访问取值返回数据就能缓解redis单点热key的查询压力因为redis是根据key分配哈希槽因此在初始化时可以将key拼接上随机尾缀如下图的0-2N生成的多个备份key散落在各个redis节点上查询的时候也是随机拼接成这多个备份key中的一个进行查询从而让读写都不再集中于单个redis节点

热key拆分

因此解决热key的思路之一就是能否想办法把这个key给细化拆分让不同用户请求的key是不一样的如秒杀活动场景不同用户根据人群规则命中的活动策略ID可能是不同的因此我们可以将整个活动元信息拆分成以策略为维度把活动信息的key细化这样请求过来时根据用户人群策略只会去找该策略绑定的活动信息的key

当热点key的查询超过Redis节点的性能阈值时会导致缓存分片服务被打垮现象的产生此时当前节点上的所有业务的redis的读写都是不可用的为了防止热点key引发问题时核心业务不受影响应当提前做好核心/非核心业务的Redis的隔离至少热点key存在的redis集群应当与核心业务隔离开来

缓存雪崩

在某一个时间段缓存的key大量集中同时过期了所有的请求全部冲到持久层数据库上导致持久层数据库挂掉

双十一零点抢购这波商品比较集中的放在缓存设置了失效时间为1个小时那么到了零点这批缓存全部失效了而大量的请求过来时全部冲过了缓存冲到了持久层数据库

解决方案

搭建Redis集群既然redis有可能挂掉那我多增设几台redis这样一台挂掉之后其他的还可以继续工作其实就是搭建的集群。

异地多活

限流降级

在缓存失效后通过加锁或者队列来控制读数据库写缓存的线程数量。

比如对某个key只允许一个线程查询数据和写缓存其他线程等待。

数据预热

数据加热的含义就是在正式部署之前我先把可能的数据先预先访问一遍这样部分可能大量访问的数据就会加载到缓存中。

在即将发生大并发访问前手动触发加载缓存不同的key设置不同的过期时间让缓存失效的时间点尽量均匀