Redis基础篇

首先回顾一下Redis数据结构

如果想在技术道路上继续前行，往架构师方向发展，那么以上的数据结构以及高级的数据结构，一定要了解、熟悉，为以后在工作中做技术选型做准备。

使用场景

**

Redis 小总结

与传统数据库不同的是 Redis 的数据是 存在内存 中的，所以 读写速度 非常 快，因此 Redis 被广泛应用于 缓存 方向，每秒可以处理超过 10 万次读写操作，是已知性能最快的 Key-Value 数据库。另外，Redis 也经常用来做 分布式锁。
除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis 优缺点

优点
读写性能优异，Redis能读的速度是110000 次/s,写的速度是 81000 次/s
支持数据持久化，支持AOF和RDB两种持久化方案
支持事务，Redis 的所有操作都是原子性的，同时 Redis 还支持对几个操作合并后的原子性执行
数据结构丰富，除了支持 string 类型的 value 外还支持 hash、set、zset、list 等数据结构
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
缺点
Redis数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上
Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复
主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了 系统的可用性
Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费

使用 Redis or 使用缓存带来的优势

如果我们把数据放在 Redis 中，也就是直接放在内存之中，让服务端直接去读取内存中的数据，那么这样 速度 明显就会快上不少 (高性能)，并且会 极大减小数据库的压力 (特别是在高并发情况下)

总结：两个角度:1.高性能,2.高并发

使用Redis会出现什么问题

1、缓存穿透

出现的场景：

实际上就是查询一个不存在数据库中的数据，此时缓存不一定存在，所以绕过redis直接请求数据库，如果出现大量的查询，会拖垮数据库

解决思路：
使用布隆过滤器提前拦截(我的理解是用sitmap位图来实现，从节省空间，响应效率上最佳)
把不存在的空对象放到缓存中，并设置一个较短的过期时间

2、缓存雪崩

出现的场景：

解决思路：
事发前：实现Redis的高可用（主从架构+sentinel或者Redis Cluster架构）,尽量避免Redis挂掉的情况发生
事发中：万一挂掉了，可以在微服务网关设置限流（hystrix）+ 设置本地缓存，尽量避免直接访问数据库，导致数据库被干掉
事发后：Redis 持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据

3、缓存击穿

出现的场景：
缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞

4、缓存和数据库双写一致性问题

 更新策略

先更新数据库，后更新缓存
（1）线程A更新了数据库
（2）线程B更新了数据库
（3）线程B更新了缓存
（4）线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。
先删除缓存，再更新数据库

这种情况会出现脏数据
先更新数据库，再删除缓存
这种情况，也会产生数据不一致问题，但是概率比较低
（1）线程A更新数据库
（2）线程B进来
（3）线程B读取缓存
（4）线程A删除缓存（由于网络原因，导致操作缓存出现了延迟，导致线程B先执行，那线程B拿到的是脏数据了）
如果中间出现了，热点key实现，大量的请求进来，会对数据库造成一个冲击