百度是什么网站,新郑建设局网站,开互联网公司网站是自己建吗,wordpress插件如何使用这是本人学习的总结#xff0c;主要学习资料如下
马士兵教育 目录1、数据一致性的问题1.1、新增数据一致性的问题1.2、修改/删除一致性问题1.2.1、操作分析1.2.1、总结和再深入2、缓存穿透#xff0c;缓存击穿和缓存雪崩2.1、缓存穿透#xff08;查不到#xff09;2.1.1、…这是本人学习的总结主要学习资料如下
马士兵教育 目录1、数据一致性的问题1.1、新增数据一致性的问题1.2、修改/删除一致性问题1.2.1、操作分析1.2.1、总结和再深入2、缓存穿透缓存击穿和缓存雪崩2.1、缓存穿透查不到2.1.1、 解决方式2.2、缓存击穿过期没找到2.2.1、解决方法2.3、缓存雪崩2.3.1、解决方式3、数据倾斜3.1、热点key3.1.1、什么是热点key3.1.2、发现热点key3.1.3、解决热点Key3.2、bigKey3.2.1、什么是bigKey3.2.2、发现热点key3.2.3、解决bigKey1、数据一致性的问题
1.1、新增数据一致性的问题
所谓新增数据一致性的问题就是新增数据时缓存和数据库都要存数据有一方失败一方成功导致的数据不一致的问题。
这种情况一般不用担心如果真的很担心那可以在存数据前加一个消息中间件让缓存和数据库消费这个中间件。因为中间件消费失败了会多次尝试这就可以解决不一致的问题。 1.2、修改/删除一致性问题
1.2.1、操作分析
在涉及到缓存和数据库的修改和删除时根据操作先后也就分为四种情况。
先更新缓存后更新数据库。先删除缓存后更新数据库。先更新数据库后更新缓存。先更新数据库后删除缓存。
下面就逐一分析其可行性。
先更新缓存 后更新数据库。 线程A和线程B并发更新数据线程A先更新线程B后更新。按照预期因为线程B后更新那么最后结果应该以线程B的为准。 但如果线程A更新缓存后还没来得及更新数据库时线程B就把缓存和数据库更新好了之后线程A才继续更新数据库那这时候就出现缓存是最新数据而数据库是旧数据的情况缓存不一致出现。 下图是流程图左边是正常情况右边是不一致的情况。 先删除缓存 后更新数据库 线程A删除缓存后还没来得及更新数据库时线程B查询数据。 一般线程B现在缓存查数据查不到转而查数据库但这时线程A还没更新好于是线程B拿到的是旧数据。 现成B拿到旧数据后会顺便把旧数据更新到缓存中于是现在就出现数据库时新数据而缓存是旧数据的不一致。 更新数据库后更新缓存 线程A和线程B并发更新数据线程A先更新线程B后更新。按照预期因为线程B后更新那么最后结果应该以线程B的为准。 但如果线程A更新数据库后还没来得及更新缓存线程B已经更新了数据库和缓存那么现在数据库就是数据库是最新数据而缓存是旧数据的不一致情况。 先更新数据库后删除缓存 特殊情况就是在线程A更新数据库之前线程B来查数据并且缓存因为各种原因正好没数据所以B就去数据库查数据。 这里B拿到的是旧数据之后A更新数据库完成B就拿着旧数据回填到缓存中。但是A会删除缓存这样别的线程再来查数据就会因为缓存没数据去数据库拿最新的数据回填到缓存中。这样就避免了数据不一致的情况。 并且为了防止线程B拿到数据库旧数据后在线程A第二次删缓存后才将旧数据回填到缓存造成数据库是新数据缓存是旧数据的不一致线程A更新完数据库后还睡眠一段时间然后才删除缓存。这样就能保证第二次删除缓存发生在在线程B插入缓存之后。 教程里提到需要延迟双删即在这个基础上在线程A更新数据库前也删除一次缓存加上更新后的删除总共两次删除所以叫延迟双删。
不过我自己觉得第一次删除没必要似乎只有后一次删除也能避免数据不一致。 1.2.1、总结和再深入
所以面对修改/删除的一致性问题最好的方法是先更新数据库后删除缓存并且有需要的话可以延时删除缓存。
还有两种加强的方式都是在延时这里做文章。
第一种是线程A更新数据库以后将删除缓存的操作放到延迟消息队列中这样可以避免缓存删除失败的风险同时也让线程A更新完数据库后不必再睡眠可以抽身做其他的事。这种方式唯一的缺点是增加了系统的复杂度。
另一种方式是数据库插入后会更新一种叫binlog的东西我们让一个线程订阅binlog的发布然后消费发布信息删除缓存。这种方式的缺点是获取binlog会引起I/O效率不是很高。 2、缓存穿透缓存击穿和缓存雪崩
2.1、缓存穿透查不到
一般的模型当中一次查询会优先到redis中查询如果没有查询到才进行mysql查询。但如果mysql中也没有对应数据那这两次查询就无功而返。 一般情况下以上查询没什么问题。但在高并发的场景下如果有大量请求想查询同一字段而这一字段又不存在那就会在短时间内进行大量的mysql查询造成数据库崩溃这就是缓存穿透。 2.1.1、 解决方式 第一种是设空值。在redis中设空值第一次在数据库中没查到数据就设一个空值在redis。这样的相同查询就在redis中查到空值就返回结束不用麻烦数据库。 等到以后真正有了值数据库会更新到缓存中。 布隆过滤器。布隆过滤器可以快速判定一个元素不在集合中。如果在查询前加入布隆过滤器布隆过滤器里的数据和数据库同步。当查询查不存在的元素布隆过滤器直接处理不用麻烦到数据库和缓存。 2.2、缓存击穿过期没找到
redis缓存中设置的值总是有过期时间如果有一个超热点在失效的那一刻迎来了大量的请求这些请求发现redis里没有数据就会转到mysql中查询。
数据从mysql中取出重新存到redis中有个时间差在这个时间差内的所有请求都会查询mysql那mysql就有可能承受不住压力崩溃。这就是缓存击穿。
2.2.1、解决方法
缓存击穿的核心问题是查数据库返回值设到redis中有时间差这段时间对同一个值有大量查询。
那我们可以给关于这个值的查询加一个锁只要有一个线程去查询数据库就够了。伪代码如下。
public String getValue(String key) {String value redis.get(key);//为空则需要加锁查询if(value null) {// 如果返回1则成功获取锁if(redis.setnx(hash(key), 60) 1) {String value db.getValue(key);redis.set(key, value);return value;} else {// 不成功则休眠一段时间再获取值试试Thread.sleep(60);return getValue(key);}} else{return value;}
}2.3、缓存雪崩
指某一时间段内缓存集中过期或者redis宕机大量请求在redis中得到不到数据就转向数据库中查询导致数据库崩溃。
2.3.1、解决方式
第一当然是依靠集群哨兵的故障恢复一个节点挂了就需要故障恢复启用其他节点接替工作。
另外还有下面几种做法。
避免设置统一过期时间。缓存的过期时间不要太集中。功能降级。比如双十一期间一些不重要的功能可以暂停避免查询过多。 3、数据倾斜
3.1、热点key
3.1.1、什么是热点key
比如微博里经常出现一些热点事件明星结婚之类的导致微博突然崩溃。
这是因为大厂往往用redis的集群作缓存一个话题就存在一个节点中。一个话题如果过热就引起大量查询导致某一节点压力突然变大直接崩溃。
这就是热点key导致的数据倾斜。 3.1.2、发现热点key
一般有四个方法每个方法都不完美只能根据实际情况甄选。
他们分别是客户端监控monitorhotkeys和TCP抓包。
第一个是在客户端监控每一个key查询一次就1如果查询一定时间内超过一定的阈值就上报或者其他处理。
这种方式实现很简单缺点也很明显就是代码侵入性客户端的代码不得不增加不应该有的内容而且监控每一个key也是不小的负担。 第二个是用redis命令monitor输入这个指令后相当于订阅了redis的一个服务当有命令执行时就会收到命令的解析。 比如下面的示例。
127.0.0.1:6900 monitor
OK
1677459065.262425 [0 127.0.0.1:54894] set aaaa v1使用这种方法就意味着需要额外的开销去存储这些日志并解析数据量大的时候开销就很大。 在4.0.3以后reids推出了hotKeys命令专门用于统计热点。具体示例如下。
首先先大量读取某一个key多执行几次set命令即可然后执行redis-cli --hotkeys命令获取热点。
MacBook-Pro:etc user$ redis-cli --hotkeys# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).Error: ERR An LFU maxmemory policy is not selected, access frequency not tracked. Please note that when switching between policies at runtime LRU and LFU data will take some time to adjust.上面是常见的错误因为redis是基于LFU的内存淘汰策略所以要先开启策略选项才能使用hotkyes的功能。
127.0.0.1:6379 config set maxmemory-policy volatile-lfu
OK然后可以使用hotkeys命令了可以看到它统计出k1这个key短时间内有6次查询。
MacBook-Pro:etc user$ redis-cli --hotkeys# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).[00.00%] Hot key k1 found so far with counter 6-------- summary -------Sampled 3 keys in the keyspace!
hot key found with counter: 6 keyname: k1这个方法的问题是hotkeys是一个全局命令他需要扫描所有的key这同样是个不小的开销。
最后一种方法比较高级就是抓reids的TCP的包然后解析。常用的插件是ELK packetbeat这个的麻烦点是维护成本高且有丢包的风险 3.1.3、解决热点Key
使用二级缓存比如Guava-cachehcacheJVM对象内存等。将热点数据存到内存中这样就不用访问redis减轻redis的压力。key分散。我们的key可以分成很多子key当然子key不是乱命名的。这些子key需要均匀地落到集群的每一个节点这样热点数据存储压力就分散了。 3.2、bigKey
3.2.1、什么是bigKey
bigKey是指单个key车占用的存储空间过大。String类型的一般是value过大一般超过10kb就算bigKey了。
非String类型的就是集合Hash列表。他们的大体现在里面的元素过多。
他们的危害也比较明显体积过大让存取都消耗较大 无论是空间复杂度还是时间复杂度都不友好。
造成单节点内存空间使用不均匀。Redis执行命令时遇到该类型的key耗时较多。网络传输这种key容易造成拥堵。 3.2.2、发现热点key
redis自带命令我们先设一个比较大的值
127.0.0.1:6379 set k1 dfnoqihudygouvhqihbghdsuygqfhsdgoiuqgt7687uhvit6871ygh2bdyf71tuidgbhgsft7681ghb23ysdf687iu1gb2jhodgyt67879u1bjdhuog8f6712uh3bnkhguoidt78f61723hbnkgdoyv8t7982uh3nbjhulos867tfy892u3hjbjlhoua78ft2e
OK然后可以使用redis自带的命令redis-cli --bigkeys。
MacBook-Pro:etc $ redis-cli --bigkeys# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).[00.00%] Biggest string found so far k2 with 2 bytes
[00.00%] Biggest string found so far name with 3 bytes
[00.00%] Biggest string found so far k1 with 194 bytes-------- summary -------Sampled 3 keys in the keyspace!
Total key length in bytes is 8 (avg len 2.67)Biggest string found k1 has 194 bytes0 lists with 0 items (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
3 strings with 199 bytes (100.00% of keys, avg size 66.33)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)
这种方式是全局命令在有大量key的生产环境需要谨慎使用。 使用debug命令使用debug object k1可以得到k1这个单个key的信息。那么我们就可以一批一批地过一遍所有的key找到bigkey。
127.0.0.1:6379 debug object k1
Value at:0x600002554020 refcount:1 encoding:raw serializedlength:196 lru:10373635 lru_seconds_idle:6214367关于遍历这个命令遍历的操作可以使用scan命令来完成。
scan cursor [MATCH pattern] [COUNT count] 可以像分页一样地一页一页的遍历所有元素。这种遍历方式不一定能完全遍历所有的key当遍历时有新数据插入就可能遍历不到。不过能遍历到绝大部分的元素用来寻找bigKey还是很可靠的。
scan关键字。cursor下标可以理解成元素的下标访问第一页的元素时cursor0。[MATCH match]可以省略通配符匹配。[COUNT count]每页返回的元素个数。这个不能保证每页都返回这个数目只能保证尽量接近。 下面是例子 总共遍历30个元素。方法的第一个返回值是下一页元素的下标范围下一页时cursor要等于这个值。第二个返回值才是这一页的key。scan是循环遍历遍历到最后一页下一页就是第一页。
127.0.0.1:6379 scan 0 count 10
1) 26
2) 1) k192) k23) k54) k115) k136) k37) k108) k309) k2610) k24
127.0.0.1:6379 scan 26 count 10
1) 3
2) 1) k232) k203) k14) k285) k256) k97) k88) k129) k1410) k2211) k1812) k16
127.0.0.1:6379 scan 3 count 10
1) 0
2) 1) k272) k293) k44) k155) k216) k67) k178) k73.2.3、解决bigKey
拆分将bigkey拆分成多个子Key使这些子Key均匀地分布到各个子节点。
