前言
Redis是一个开源的底层使用C语言编写的key-value存储数据库。可用于缓存、事件发布订阅、高速队列等场景。而且支持丰富的数据类型：string(字符串)、hash(哈希)、list(列表)、set(无序集合)、zset(sorted set：有序集合)
在单节点服务器我们通常是这样的
随着企业的发展、业务的扩展。面对海量的数据，直接使用MySql会导致性能下降，数据的读写也会非常慢。于是我们就可以搭配缓存来处理海量数据。
于是现在我们是这样的：
上图只是简述了缓存的作用，当数据继续增大我们需要利用主从复制技术来达到读写分离
数据库层直接与缓存进行交互，如果缓存中有数据直接返回客户端，如果没有才会从MySql中去查询。从而减小了数据库的压力，提升了效率。
平时发布了一款新手机，会有抢购活动。同一时间段，服务端会收到很多的下单请求。
我们需要使用redis的原子操作来实现这个“单线程”。首先我们把库存存在一个列表中，假设有10件库存，就往列表中push10个数，这个数没有实际意义，仅仅只是代表10件库存。抢购开始后，每到来一个用户，就从列表中pop一个数，表示用户抢购成功。当列表为空时，表示已经被抢光了。因为列表的pop操作是原子的，即使有很多用户同时到达，也是依次执行的
题外话：还有的抢购是直接在前端页面限制请求，这些请求直接被前端拦截，并没有到后端服务器
Redis为什么会这么快
1、Redis是纯内存操作，需要的时候需要我们手动持久化到硬盘中
2、Redis是单线程，从而避开了多线程中上下文频繁切换的操作。
3、Redis数据结构简单、对数据的操作也比较简单
4、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求
5、使用多路I/O复用模型，非阻塞I/O
多路I/O复用
I/O 多路复用技术是为了解决进程或线程阻塞到某个 I/O 系统调用而出现的技术，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪，就是这个文件描述符进行读写操作之前），能够通知程序进行相应的读写操作
数据类型
String
字符串是最常用的数据类型，他能够存储任何类型的字符串，当然也包括二进制、JSON化的对象、甚至是base64编码之后的图片。在Redis中一个字符串最大的容量为512MB，可以说是无所不能了。
Hash
常用作存储结构化数据、比如论坛系统中可以用来存储用户的Id、昵称、头像、积分等信息。如果需要修改其中的信息，只需要通过Key取出Value进行反序列化修改某一项的值，再序列化存储到Redis中，Hash结构存储，由于Hash结构会在单个Hash元素在不足一定数量时进行压缩存储，所以可以大量节约内存。这一点在String结构里是不存在的。
List
List的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis 内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。另外，可以利用 lrange 命令，做基于 Redis 的分页功能，性能极佳，用户体验好。
Set
set 对外提供的功能与 list 类似是一个列表的功能，特殊之处在于 set 是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，这个时候就可以选择使用set。
Sorted Set
可以按照某个条件的权重进行排序，比如可以通过点击数做出排行榜的数据应用。
数据的一致性
真正意义上来讲数据库的数据和缓存的数据是不可能一致的，数据分为最终一直和强一致两类。如果业务中对数据的要求必须强一直那么就不能使用缓存。缓存能做的只能保证数据的最终一致性。
我们能做的只能是尽可能的保证数据的一致性。不管是先删库再删缓存 还是 先删缓存再删库，都可能出现数据不一致的情况，因为读和写操作是并发的，我们没办法保证他们的先后顺序。具体应对策略还是要根据业务需求来定，这里就不赘述了。
Redis的过期和内存淘汰
Redis存储数据时我们可以设置他的过期时间。但是这个key是怎么删除的呢？
一开始我认为是定时删除，后来发现并不是这样，因为如果定时删除，需要一个定时器来不断的负责监控这个key，虽然内存释放了，但是非常消耗cpu资源。
Redis过期删除采用的是定期删除，默认是每100ms检测一次，遇到过期的key则进行删除，这里的检测并不是顺序检测，而是随机检测。那这样会不会有漏网之鱼？显然Redis也考虑到了这一点，当我们去读/写一个已经过期的key时，会触发Redis的惰性删除策略，直接回干掉过期的key
内存淘汰是指用户存储的一部分key是可以被Redis自动的删除，从而会出现从缓存中查不到数据的情况。加入我们的服务器内存为2G、但是随着业务的发展缓存的数据已经超过2G了。但是这并不影响我们程序的运行，因为操作系统的可见内存并不受物理内存的限制。物理内存不够用没关系，计算机会从硬盘中划出一片空间来作为虚拟内存。这就是Redis设计两种应用场景的初衷：缓存、持久存储
缓存击穿
缓存只是为了缓解数据库压力而添加的一层保护层，当从缓存中查询不到我们需要的数据就要去数据库中查询了。如果被黑客利用，频繁去访问缓存中没有的数据，那么缓存就失去了存在的意义，瞬间所有请求的压力都落在了数据库上，这样会导致数据库连接异常。
解决方案：
1、后台设置定时任务，主动的去更新缓存数据。这种方案容易理解，但是当key比较分散的时候，操作起来还是比较复杂的
2、分级缓存。比如设置两层缓存保护层，1级缓存失效时间短，2级缓存失效时间长。有请求过来优先从1级缓存中去查找，如果在1级缓存中没有找到相应数据，则对该线程进行加锁，这个线程再从数据库中取到数据，更新至1级和2级缓存。其他线程则直接从2级线程中获取
3、提供一个拦截机制，内部维护一系列合法的key值。当请求的key不合法时，直接返回。
缓存雪崩
缓存雪崩就是指缓存由于某些原因（比如 宕机、cache服务挂了或者不响应）整体crash掉了，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难，也就是上面提到的缓存击穿
如何避免雪崩：
1、给缓存加上一定区间内的随机生效时间，不同的key设置不同的失效时间，避免同一时间集体失效。
2、和缓存击穿解决方案类似，做二级缓存，原始缓存失效时从拷贝缓存中读取数据。
3、利用加锁或者队列方式避免过多请求同时对服务器进行读写操作。
这里推荐一下我的JAVA架构学习交流群：614478470 ，想要学习Java高架构、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频都有整理，送给每一位JAVA小伙伴，有想学习JAVA架构的，或是转行，还有工作中想提升自己能力的，正在学习的小伙伴欢迎加入学习。
点击：加入
