佛山网站建设a068,什么广告推广最有效果,wordpress改变后台地址,重庆seo怎么样Redis技术详解
Redis是一种支持key-value等多种数据结构的存储系统。可用于缓存#xff0c;事件发布或订阅#xff0c;高速队列等场景。支持网络#xff0c;提供字符串#xff0c;哈希#xff0c;列表#xff0c;队列#xff0c;集合结构直接存取#xff0c;基于内存事件发布或订阅高速队列等场景。支持网络提供字符串哈希列表队列集合结构直接存取基于内存可持久化。 首先对redis来说所有的key键都是字符串。我们在谈基础数据结构时讨论的是存储值的数据类型主要包括常见的5种数据类型分别是String、List、Set、Zset、Hash。
结构类型结构存储的值结构存储的值使用场景String字符串可以是字符串、整数或浮点数对整个字符串或字符串的一部分进行操作对整数或浮点数进行自增或自减操作经典使用场景把常用信息字符串图片或者视频等信息放到redis中redis作为缓存层mysql做持久化层降低mysql的读写压力。例如tokenList一个链表链表上的每个节点都包含一个字符串对链表的两端进行push和pop操作读取单个或多个元素根据值查找或删除元素消息队列Set包含字符串的无序集合字符串的集合包含基础的方法有看是否存在添加、获取、删除还包含计算交集、并集、差集等标签tag,给用户添加标签或者用户给消息添加标签这样有同一标签或者类似标签的可以给推荐关注的事或者关注的人。 点赞或点踩收藏等可以放到set中实现Hash散列包含键值对的无序散列表包含方法有添加、获取、删除单个元素缓存 能直观相比string更节省空间的维护缓存信息如用户信息视频信息等。Zset有序集合和散列一样用于存储键值对字符串成员与浮点数分数之间的有序映射元素的排列顺序由分数的大小决定包含方法有添加、获取、删除单个元素以及根据分值范围或成员来获取元素排行榜有序集合经典使用场景。例如小说视频等网站需要对用户上传的小说视频做排行榜榜单可以按照用户关注数更新时间字数等打分做排行
1.五种常用基本数据类型
1.1 String字符串 String是redis中最基本的数据类型一个key对应一个value。 String类型是二进制安全的意思是 redis 的 string 可以包含任何数据。如数字字符串jpg图片或者序列化的对象。
命令使用
命令简述使用GET获取存储在给定键中的值GET nameSET设置存储在给定键中的值SET name valueDEL删除存储在给定键中的值DEL nameINCR将键存储的值加1INCR keyDECR将键存储的值减1DECR keyINCRBY将键存储的值加上整数INCRBY key amountDECRBY将键存储的值减去整数DECRBY key amount
命令执行
127.0.0.1:6379 set hello world
OK
127.0.0.1:6379 get hello
world
127.0.0.1:6379 del hello
(integer) 1
127.0.0.1:6379 get hello
(nil)
127.0.0.1:6379 set counter 2
OK
127.0.0.1:6379 get counter
2
127.0.0.1:6379 incr counter
(integer) 3
127.0.0.1:6379 get counter
3
127.0.0.1:6379 incrby counter 100
(integer) 103
127.0.0.1:6379 get counter
103
127.0.0.1:6379 decr counter
(integer) 102
127.0.0.1:6379 get counter
102
1.2 List列表 Redis中的List其实就是链表Redis用双端链表实现List。 使用List结构我们可以轻松地实现最新消息排队功能比如新浪微博的TimeLine。List的另一个应用就是消息队列可以利用List的 PUSH 操作将任务存放在List中然后工作线程再用 POP 操作将任务取出进行执行。
命令使用
命令简述使用RPUSH将给定值推入到列表右端RPUSH key valueLPUSH将给定值推入到列表左端LPUSH key valueRPOP从列表的右端弹出一个值并返回被弹出的值RPOP keyLPOP从列表的左端弹出一个值并返回被弹出的值LPOP keyLRANGE获取列表在给定范围上的所有值LRANGE key 0 -1LINDEX通过索引获取列表中的元素。你也可以使用负数下标以 -1 表示列表的最后一个元素 -2 表示列表的倒数第二个元素以此类推。LINDEX key index
使用列表的技巧 lpushlpopStack(栈)lpushrpopQueue队列lpushltrimCapped Collection有限集合lpushbrpopMessage Queue消息队列 命令执行
127.0.0.1:6379 lpush mylist 1 2 ll ls mem
(integer) 5
127.0.0.1:6379 lrange mylist 0 -1
1) mem
2) ls
3) ll
4) 2
5) 1
127.0.0.1:6379 lindex mylist -1
1
127.0.0.1:6379 lindex mylist 10 # index不在 mylist 的区间范围内
(nil)
1.3 Set集合 Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的这就意味着集合中不能出现重复的数据。 Redis 中集合是通过哈希表实现的所以添加删除查找的复杂度都是 O(1)。
命令使用
命令简述使用SADD向集合添加一个或多个成员SADD key valueSCARD获取集合的成员数SCARD keySMEMBERS返回集合中的所有成员SMEMBERS key memberSISMEMBER判断 member 元素是否是集合 key 的成员SISMEMBER key member
命令执行
127.0.0.1:6379 sadd myset hao hao1 xiaohao hao
(integer) 3
127.0.0.1:6379 smembers myset
1) xiaohao
2) hao1
3) hao
127.0.0.1:6379 sismember myset hao
(integer) 11.4 Hash散列 Redis hash 是一个 string 类型的 field字段 和 value值 的映射表hash 特别适合用于存储对象。 命令使用
命令简述使用HSET添加键值对HSET hash-key sub-key1 value1HGET获取指定散列键的值HGET hash-key key1HGETALL获取散列中包含的所有键值对HGETALL hash-keyHDEL如果给定键存在于散列中那么就移除这个键HDEL hash-key sub-key1
命令执行
127.0.0.1:6379 hset user name1 hao
(integer) 1
127.0.0.1:6379 hset user email1 hao163.com
(integer) 1
127.0.0.1:6379 hgetall user
1) name1
2) hao
3) email1
4) hao163.com
127.0.0.1:6379 hget user user
(nil)
127.0.0.1:6379 hget user name1
hao
127.0.0.1:6379 hset user name2 xiaohao
(integer) 1
127.0.0.1:6379 hset user email2 xiaohao163.com
(integer) 1
127.0.0.1:6379 hgetall user
1) name1
2) hao
3) email1
4) hao163.com
5) name2
6) xiaohao
7) email2
8) xiaohao163.com
1.5 Zset有序集合 Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。 命令使用
命令简述使用ZADD将一个带有给定分值的成员添加到有序集合里面ZADD zset-key 178 member1ZRANGE根据元素在有序集合中所处的位置从有序集合中获取多个元素ZRANGE zset-key 0-1 withccoresZREM如果给定元素成员存在于有序集合中那么就移除这个元素ZREM zset-key member1
命令执行
127.0.0.1:6379 zadd myscoreset 100 hao 90 xiaohao
(integer) 2
127.0.0.1:6379 ZRANGE myscoreset 0 -1
1) xiaohao
2) hao
127.0.0.1:6379 ZSCORE myscoreset hao
100 2.三种特殊类型详解
Redis除了上文中5种基础数据类型还有三种特殊的数据类型分别是 HyperLogLogs基数统计 Bitmaps (位图) 和 geospatial 地理位置
2.1 HyperLogLogs基数统计 Redis 2.8.9 版本更新了 Hyperloglog 数据结构 什么是基数
举个例子A {1, 2, 3, 4, 5} B {3, 5, 6, 7, 9}那么基数不重复的元素 1, 2, 4, 6, 7, 9 允许容错即可以接受一定误差
HyperLogLogs 基数统计用来解决什么问题
这个结构可以非常省内存的去统计各种计数比如注册 IP 数、每日访问 IP 数、页面实时UV、在线用户数共同好友数等。
它的优势体现在哪
一个大型的网站每天 IP 比如有 100 万粗算一个 IP 消耗 15 字节那么 100 万个 IP 就是 15M。而 HyperLogLog 在 Redis 中每个键占用的内容都是 12K理论存储近似接近 2^64 个值不管存储的内容是什么它一个基于基数估算的算法只能比较准确的估算出基数可以使用少量固定的内存去存储并识别集合中的唯一元素。而且这个估算的基数并不一定准确是一个带有 0.81% 标准错误的近似值对于可以接受一定容错的业务场景比如IP数统计UV等是可以忽略不计的。
相关命令使用
127.0.0.1:6379 pfadd key1 a b c d e f g h i # 创建第一组元素
(integer) 1
127.0.0.1:6379 pfcount key1 # 统计元素的基数数量
(integer) 9
127.0.0.1:6379 pfadd key2 c j k l m e g a # 创建第二组元素
(integer) 1
127.0.0.1:6379 pfcount key2
(integer) 8
127.0.0.1:6379 pfmerge key3 key1 key2 # 合并两组key1 key2 - key3 并集
OK
127.0.0.1:6379 pfcount key3
(integer) 132.2 Bitmap 位存储 Bitmap 即位图数据结构都是操作二进制位来进行记录只有0 和 1 两个状态。 用来解决什么问题
比如统计用户信息活跃不活跃 登录未登录 打卡不打卡 两个状态的都可以使用 Bitmaps
如果存储一年的打卡状态需要多少内存呢 365 天 365 bit 1字节 8bit 46 个字节左右
相关命令使用
使用bitmap 来记录 周一到周日的打卡 周一1 周二0 周三0 周四1 …
127.0.0.1:6379 setbit sign 0 1
(integer) 0
127.0.0.1:6379 setbit sign 1 1
(integer) 0
127.0.0.1:6379 setbit sign 2 0
(integer) 0
127.0.0.1:6379 setbit sign 3 1
(integer) 0
127.0.0.1:6379 setbit sign 4 0
(integer) 0
127.0.0.1:6379 setbit sign 5 0
(integer) 0
127.0.0.1:6379 setbit sign 6 1
(integer) 0
查看某一天是否有打卡
127.0.0.1:6379 getbit sign 3
(integer) 1
127.0.0.1:6379 getbit sign 5
(integer) 0
统计操作统计 打卡的天数
127.0.0.1:6379 bitcount sign # 统计这周的打卡记录就可以看到是否有全勤
(integer) 32.3 geospatial (地理位置) Redis 的 Geo 在 Redis 3.2 版本就推出了! 这个功能可以推算地理位置的信息: 两地之间的距离, 方圆几里的人 2.3.1 geoadd 添加地理位置 127.0.0.1:6379 geoadd china:city 118.76 32.04 manjing 112.55 37.86 taiyuan 123.43 41.80 shenyang
(integer) 3
127.0.0.1:6379 geoadd china:city 144.05 22.52 shengzhen 120.16 30.24 hangzhou 108.96 34.26 xian
(integer) 3
规则
两级无法直接添加我们一般会下载城市数据(这个网址可以查询 GEO http://www.jsons.cn/lngcode)
有效的经度从-180度到180度。有效的纬度从-85.05112878度到85.05112878度。
# 当坐标位置超出上述指定范围时该命令将会返回一个错误。
127.0.0.1:6379 geoadd china:city 39.90 116.40 beijin
(error) ERR invalid longitude,latitude pair 39.900000,116.400000
2.3.2 geopos 获取指定的成员的经度和纬度 127.0.0.1:6379 geopos china:city taiyuan manjing
1) 1) 112.549999058246612551) 37.86000073876942196
2) 1) 118.759999573230743411) 32.03999960287850968
获得当前定位, 一定是一个坐标值!
2.3.3 geodist 如果不存在, 返回空 单位如下
mkmmi 英里ft 英尺
127.0.0.1:6379 geodist china:city taiyuan shenyang m
1026439.1070
127.0.0.1:6379 geodist china:city taiyuan shenyang km
1026.43912.3.4 georadius 附近的人 获得所有附近的人的地址, 定位, 通过半径来查询 获得指定数量的人
127.0.0.1:6379 georadius china:city 110 30 1000 km 以 100,30 这个坐标为中心, 寻找半径为1000km的城市
1) xian
2) hangzhou
3) manjing
4) taiyuan
127.0.0.1:6379 georadius china:city 110 30 500 km
1) xian
127.0.0.1:6379 georadius china:city 110 30 500 km withdist
1) 1) xian2) 483.8340
127.0.0.1:6379 georadius china:city 110 30 1000 km withcoord withdist count 2
1) 1) xian2) 483.83403) 1) 108.960001766681671142) 34.25999964418929977
2) 1) manjing2) 864.98163) 1) 118.759999573230743412) 32.03999960287850968
参数 key 经度 纬度 半径 单位 [显示结果的经度和纬度] [显示结果的距离] [显示的结果的数量]
2.3.5 georadiusbymember 显示与指定成员一定半径范围内的其他成员 127.0.0.1:6379 georadiusbymember china:city taiyuan 1000 km
1) manjing
2) taiyuan
3) xian
127.0.0.1:6379 georadiusbymember china:city taiyuan 1000 km withcoord withdist count 2
1) 1) taiyuan2) 0.00003) 1) 112.549999058246612552) 37.86000073876942196
2) 1) xian2) 514.22643) 1) 108.960001766681671142) 34.25999964418929977
3.Redis持久化
为什么需要持久化
Redis是个基于内存的数据库。那服务一旦宕机内存中的数据将全部丢失。通常的解决方案是从后端数据库恢复这些数据但后端数据库有性能瓶颈如果是大数据量的恢复1、会对数据库带来巨大的压力2、数据库的性能不如Redis。导致程序响应慢。所以对Redis来说实现数据的持久化避免从后端数据库中恢复数据是至关重要的。
3.1 RDB 持久化 RDB 就是 Redis DataBase 的缩写中文名为快照/内存快照RDB持久化是把当前进程数据生成快照保存到磁盘上的过程由于是某一时刻的快照那么快照中的值要早于或者等于内存中的值。 触发方式 触发rdb持久化的方式有2种分别是手动触发和自动触发。 3.1.1 手动触发 手动触发分别对应save和bgsave命令 save命令阻塞当前Redis服务器直到RDB过程完成为止对于内存 比较大的实例会造成长时间阻塞线上环境不建议使用bgsave命令Redis进程执行fork操作创建子进程RDB持久化过程由子 进程负责完成后自动结束。阻塞只发生在fork阶段一般时间很短
bgsave流程图如下所示 具体流程如下
redis客户端执行bgsave命令或者自动触发bgsave命令主进程判断当前是否已经存在正在执行的子进程如果存在那么主进程直接返回如果不存在正在执行的子进程那么就fork一个新的子进程进行持久化数据fork过程是阻塞的fork操作完成后主进程即可执行其他操作子进程先将数据写入到临时的rdb文件中待快照数据写入完成后再原子替换旧的rdb文件同时发送信号给主进程通知主进程rdb持久化完成主进程更新相关的统计信息info Persitence下的rdb_*相关选项。
3.1.2 自动触发 在以下4种情况时会自动触发 redis.conf中配置save m n即在m秒内有n次修改时自动触发bgsave生成rdb文件主从复制时从节点要从主节点进行全量复制时也会触发bgsave操作生成当时的快照发送到从节点执行debug reload命令重新加载redis时也会触发bgsave操作默认情况下执行shutdown命令时如果没有开启aof持久化那么也会触发bgsave操作
3.1.3 redis.conf中配置RDB
快照周期内存快照虽然可以通过技术人员手动执行SAVE或BGSAVE命令来进行但生产环境下多数情况都会设置其周期性执行条件。
Redis中默认的周期新设置
# 周期性执行条件的设置格式为
save seconds changes# 默认的设置为
save 900 1
save 300 10
save 60 10000# 以下设置方式为关闭RDB快照功能
save
以上三项默认信息设置代表的意义是
如果900秒内有1条Key信息发生变化则进行快照如果300秒内有10条Key信息发生变化则进行快照如果60秒内有10000条Key信息发生变化则进行快照。读者可以按照这个规则根据自己的实际请求压力进行设置调整。其它相关配置
# 文件名称
dbfilename dump.rdb# 文件保存路径
dir /home/work/app/redis/data/# 如果持久化出错主进程是否停止写入
stop-writes-on-bgsave-error yes# 是否压缩
rdbcompression yes# 导入时是否检查
rdbchecksum yes
dbfilenameRDB文件在磁盘上的名称。
dirRDB文件的存储路径。默认设置为“./”也就是Redis服务的主目录。
stop-writes-on-bgsave-error上文提到的在快照进行过程中主进程照样可以接受客户端的任何写操作的特性是指在快照操作正常的情况下。如果快照操作出现异常例如操作系统用户权限不够、磁盘空间写满等等时Redis就会禁止写操作。这个特性的主要目的是使运维人员在第一时间就发现Redis的运行错误并进行解决。一些特定的场景下您可能需要对这个特性进行配置这时就可以调整这个参数项。该参数项默认情况下值为yes如果要关闭这个特性指定即使出现快照错误Redis一样允许写操作则可以将该值更改为no。
rdbcompression该属性将在字符串类型的数据被快照到磁盘文件时启用LZF压缩算法。Redis官方的建议是请保持该选项设置为yes因为“it’s almost always a win”。
rdbchecksum从RDB快照功能的version 5 版本开始一个64位的CRC冗余校验编码会被放置在RDB文件的末尾以便对整个RDB文件的完整性进行验证。这个功能大概会多损失10%左右的性能但获得了更高的数据可靠性。所以如果您的Redis服务需要追求极致的性能就可以将这个选项设置为no。
3.1.4 RDB优缺点
优点 RDB文件是某个时间节点的快照默认使用LZF算法进行压缩压缩后的文件体积远远小于内存大小适用于备份、全量复制等场景Redis加载RDB文件恢复数据要远远快于AOF方式 缺点 RDB方式实时性不够无法做到秒级的持久化每次调用bgsave都需要fork子进程fork子进程属于重量级操作频繁执行成本较高RDB文件是二进制的没有可读性AOF文件在了解其结构的情况下可以手动修改或者补全版本兼容RDB文件问题
针对RDB不适合实时持久化的问题Redis提供了AOF持久化方式来解决
3.2 AOF 持久化
Redis是“写后”日志Redis先执行命令把数据写入内存然后才记录日志。日志里记录的是Redis收到的每一条命令这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志WAL例如MySQL通过写前日志和两阶段提交实现数据和逻辑的一致性。
而AOF日志采用写后日志即先写内存后写日志。 如何实现AOF
AOF日志记录Redis的每个写命令步骤分为命令追加append、文件写入write和文件同步sync。
命令追加 当AOF持久化功能打开了服务器在执行完一个写命令之后会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。文件写入和同步 关于何时将 aof_buf 缓冲区的内容写入AOF文件中Redis提供了三种写回策略 Always同步写回每个写命令执行完立马同步地将日志写回磁盘
Everysec每秒写回每个写命令执行完只是先把日志写到AOF文件的内存缓冲区每隔一秒把缓冲区中的内容写入磁盘
No操作系统控制的写回每个写命令执行完只是先把日志写到AOF文件的内存缓冲区由操作系统决定何时将缓冲区内容写回磁盘。
3.2.1 redis.conf中配置AOF
默认情况下Redis是没有开启AOF的可以通过配置redis.conf文件来开启AOF持久化关于AOF的配置如下
# appendonly参数开启AOF持久化
appendonly no# AOF持久化的文件名默认是appendonly.aof
appendfilename appendonly.aof# AOF文件的保存位置和RDB文件的位置相同都是通过dir参数设置的
dir ./# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no# aof重写期间是否同步
no-appendfsync-on-rewrite no# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb# 加载aof出错如何处理
aof-load-truncated yes# 文件重写策略
aof-rewrite-incremental-fsync yes
以下是Redis中关于AOF的主要配置信息
appendonly默认情况下AOF功能是关闭的将该选项改为yes以便打开Redis的AOF功能。
appendfilename这个参数项很好理解了就是AOF文件的名字。
appendfsync这个参数项是AOF功能最重要的设置项之一主要用于设置“真正执行”操作命令向AOF文件中同步的策略。
什么叫“真正执行”呢还记得Linux操作系统对磁盘设备的操作方式吗 为了保证操作系统中I/O队列的操作效率应用程序提交的I/O操作请求一般是被放置在linux Page Cache中的然后再由Linux操作系统中的策略自行决定正在写到磁盘上的时机。而Redis中有一个fsync()函数可以将Page Cache中待写的数据真正写入到物理设备上而缺点是频繁调用这个fsync()函数干预操作系统的既定策略可能导致I/O卡顿的现象频繁 。
与上节对应appendfsync参数项可以设置三个值分别是always、everysec、no默认的值为everysec。
no-appendfsync-on-rewritealways和everysec的设置会使真正的I/O操作高频度的出现甚至会出现长时间的卡顿情况这个问题出现在操作系统层面上所有靠工作在操作系统之上的Redis是没法解决的。为了尽量缓解这个情况Redis提供了这个设置项保证在完成fsync函数调用时不会将这段时间内发生的命令操作放入操作系统的Page Cache这段时间Redis还在接受客户端的各种写操作命令。
auto-aof-rewrite-percentage上文说到在生产环境下技术人员不可能随时随地使用“BGREWRITEAOF”命令去重写AOF文件。所以更多时候我们需要依靠Redis中对AOF文件的自动重写策略。Redis中对触发自动重写AOF文件的操作提供了两个设置auto-aof-rewrite-percentage表示如果当前AOF文件的大小超过了上次重写后AOF文件的百分之多少后就再次开始重写AOF文件。例如该参数值的默认设置值为100意思就是如果AOF文件的大小超过上次AOF文件重写后的1倍就启动重写操作。
auto-aof-rewrite-min-size参考auto-aof-rewrite-percentage选项的介绍auto-aof-rewrite-min-size设置项表示启动AOF文件重写操作的AOF文件最小大小。如果AOF文件大小低于这个值则不会触发重写操作。注意auto-aof-rewrite-percentage和auto-aof-rewrite-min-size只是用来控制Redis中自动对AOF文件进行重写的情况如果是技术人员手动调用“BGREWRITEAOF”命令则不受这两个限制条件左右。
3.3 RDB和AOF混合方式4.0版本)
Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说内存快照以一定的频率执行在两次快照之间使用 AOF 日志记录这期间的所有命令操作。
从持久化中恢复数据 数据的备份、持久化做完了我们如何从这些持久化文件中恢复数据呢如果一台服务器上有既有RDB文件又有AOF文件该加载谁呢 其实想要从这些文件中恢复数据只需要重新启动Redis即可。我们还是通过图来了解这个流程 redis重启时判断是否开启aof如果开启了aof那么就优先加载aof文件如果aof存在那么就去加载aof文件加载成功的话redis重启成功如果aof文件加载失败那么会打印日志表示启动失败此时可以去修复aof文件后重新启动若aof文件不存在那么redis就会转而去加载rdb文件如果rdb文件不存在redis直接启动成功如果rdb文件存在就会去加载rdb文件恢复数据如加载失败则打印日志提示启动失败如加载成功那么redis重启成功且使用rdb文件恢复数据
那么为什么会优先加载AOF呢因为AOF保存的数据更完整通过上面的分析我们知道AOF基本上最多损失1s的数据。
4.redis缓存问题一致性, 击穿, 穿透, 雪崩。
4.1 缓存穿透
问题来源
缓存穿透是指缓存和数据库中都没有的数据而用户不断发起请求。由于缓存是不命中时被动写的并且出于容错考虑如果从存储层查不到数据则不写入缓存这将导致这个不存在的数据每次请求都要到存储层去查询失去了缓存的意义。
在流量大时可能DB就挂掉了要是有人利用不存在的key频繁攻击我们的应用这就是漏洞。
如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者攻击会导致数据库压力过大。
解决方案
接口层增加校验如用户鉴权校验id做基础校验id0的直接拦截从缓存取不到的数据在数据库中也没有取到这时也可以将key-value对写为key-null缓存有效时间可以设置短点如30秒设置太长会导致正常情况也没法使用。这样可以防止攻击用户反复用同一个id暴力攻击布隆过滤器。bloomfilter就类似于一个hash set用于快速判某个元素是否存在于集合中其典型的应用场景就是快速判断一个key是否存在于某容器不存在就直接返回。布隆过滤器的关键就在于hash算法和容器大小。
4.2 缓存击穿
问题来源
缓存击穿是指缓存中没有但数据库中有的数据一般是缓存时间到期这时由于并发用户特别多同时读缓存没读到数据又同时去数据库去取数据引起数据库压力瞬间增大造成过大压力。
解决方案
1、设置热点数据永远不过期。
2、接口限流与熔断降级。重要的接口一定要做好限流策略防止用户恶意刷接口同时要降级准备当接口中的某些 服务 不可用时候进行熔断失败快速返回机制。
3、加互斥锁
4.3 缓存雪崩
问题来源
缓存雪崩是指缓存中数据大批量到过期时间而查询数据量巨大引起数据库压力过大甚至down机。和缓存击穿不同的是缓存击穿指并发查同一条数据缓存雪崩是不同数据都过期了很多数据都查不到从而查数据库。
解决方案
缓存数据的过期时间设置随机防止同一时间大量数据过期现象发生。如果缓存数据库是分布式部署将热点数据均匀分布在不同的缓存数据库中。设置热点数据永远不过期。
4.4 数据库和缓存一致性
不管是先写MySQL数据库再删除Redis缓存还是先删除缓存再写库都有可能出现数据不一致的情况。
方案一队列 重试机制 流程如下所示
更新数据库数据缓存因为种种问题删除失败将需要删除的key发送至消息队列自己消费消息获得需要删除的key继续重试删除操作直到成功
然而该方案有一个缺点对业务线代码造成大量的侵入。于是有了方案二在方案二中启动一个订阅程序去订阅数据库的binlog获得需要操作的数据。在应用程序中另起一段程序获得这个订阅程序传来的信息进行删除缓存操作。
方案二异步更新缓存(基于订阅binlog的同步机制) 技术整体思路
MySQL binlog增量订阅消费消息队列增量数据更新到redis
1读Redis热数据基本都在Redis
2写MySQL: 增删改都是操作MySQL
3更新Redis数据MySQ的数据操作binlog来更新到Redis
Redis更新
1数据操作主要分为两大块
一个是全量(将全部数据一次写入到redis)一个是增量实时更新
这里说的是增量,指的是mysql的update、insert、delate变更数据。
2读取binlog后分析 利用消息队列,推送更新各台的redis缓存数据。
这样一旦MySQL中产生了新的写入、更新、删除等操作就可以把binlog相关的消息推送至RedisRedis再根据binlog中的记录对Redis进行更新。
其实这种机制很类似MySQL的主从备份机制因为MySQL的主备也是通过binlog来实现的数据一致性。
这里可以结合使用canal(阿里的一款开源框架)通过该框架可以对MySQL的binlog进行订阅而canal正是模仿了mysql的slave数据库的备份请求使得Redis的数据更新达到了相同的效果。
当然这里的消息推送工具你也可以采用别的第三方kafka、rabbitMQ等来实现推送更新Redis。
