Redis
Redis紧张面向缓存、分布式锁、消息队列等问题。
而在缓存中常存在穿透、击穿、雪崩、双写一致、长期化、数据逾期、数据镌汰等问题。
1.缓存穿透
通过get请求查询redis，redis相应查数据库，正常环境下，若查询到数据，则正常返回数据值，get请求结束。
而缓存击穿，则是当数据库中，并不存在get请求所必要查询的值，使得redis反复查询数据库。若存在恶意攻击，反复请求数据库，数据库并发量有限，则会击垮数据库使其宕机。
一般解决方法，查询结果为空时，把空结果（null）进行缓存。但是消耗内存，不是最优解。
其他解决办法为布隆过滤器（站在布隆背面…），在redis之前设置一个布隆过滤器，存储预热数据。利用位图检索数据是否存储在一个聚集中。但存在数组太大时，存在误判问题，需设置误判率。（5%以内）。
2.缓存击穿
普通点来讲，就是本地有一家卖的很好的早餐店，吗喽们每天都会来买早餐，然后有一天这家店铺租约到期了，搬走了，但恰好这个时间点各人都来买早餐，就造成买不到早餐都站在店铺面前，给店铺挤爆了。
也就是说，正常通过redis查数据，但是key逾期了，从redis中查不到数据，最后大量请求输送给数据库，导致数据库吃不下，爆了。
解决方法就是互斥锁、逻辑逾期。
互斥锁无非就是等候其他线程完成数据提取任务以后，再继续进行。（就像早餐铺子，你列队买早餐，你得等你前面的人买完了，你才气买）。（强一致、性能不好）
而逻辑逾期，就像是你去买早餐，发现了早餐到期了、不见了，然后你另辟蹊径，去另一家早餐店买雷同的早餐。（逾期时间的设置）可用性较好。
3.缓存雪崩
雪崩，顾名思义，大范围的崩了。那就是大量的key逾期了，大概redis直接G了，导致大量的请求直接面向数据库，给数据库压垮了。
解决方法，使得逾期时间随机，制止大量的key同时逾期。或是启动集群，利用哨兵模式，使得主从结点自动替换。
4.双写一致
数据库与redis的数据进行同步。也就是数据库的数据变了，缓存内里的也要跟着变，包管数据的一致性。
数据的删除修改时，会导致脏数据。
读写时添加互斥锁，能解决一些不一致的问题。（或是共享锁（锁住，只准你读）、排它锁（当前执行，壅闭其他线程的读写操作））。
5.长期化
一般环境下利用数据备份文件or数据快照 RDB （Redis Database Backup file），将缓存的数据记录到磁盘中，若Redis出现故障、重启等问题是，可以从磁盘读取文件恢复数据，制止数据丢失。
AOF（Append Only File）追加文件。也就是redis每写入一个命令都会记录下来，像日志文件。文件很大。
6.数据逾期
惰性删除：key自动逾期以后，不会立即删除，只会在再次利用这个key时，判定逾期以后删除掉。（内存占用问题）
定期删除：定期对肯定命目的key进行检查，发现逾期就干掉。分为（slow不超过25ms、fast不低于2ms 模式）
7.数据镌汰
内存满了怎么办？缓存不是无穷大的
那么就必要公道的对redis内的数据进行公道的镌汰。
一般的方法，要么就是写死，满了就不让写进去了（noeviction），没用幸存者，全部干掉。
要么对全体key随机镌汰一部分（allkeys-random）
要么就是，通过判定key的逾期时间，快要逾期的就先干掉（volatile-ttl），或是对设置了逾期时间的key随机镌汰（volatile-random）
或是对全体key or 利用了逾期利用的key 根据利用次数，利用少的镌汰（LRU）
或是基于利用频率，利用越少的优先镌汰。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
