【详解Redis基本知识】

为什么有些概念很难理解？
例1：redis是一款远程内存数据库。
例2：熊猫是一种哺乳动物。
很显然，例2的句子比例1句子更容易理解。例1和例2是同样的语法结构–主谓宾。不同的是词语本身的含义：“哺乳动物”是常见的词语，我们都对它的含义很熟悉；而“远程内存数据库”对于初学者来说却晦涩难懂，并不常见。也就是说，句子结构并不是我们去理解概念的阻碍，而是词语本身的含义。或许在我们理解了“远程内存数据库”中的词语，概念本身就并不陌生。
所以本文对于新事物的学习思想是：对专业名词追根溯源。

【答】

1. Redis（Remote Dictionary Server远程字典服务器)，是一款高性能的分布式数据库，基于内存运行并支持持久化的NoSQL数据库。
2. 它可以储存键（key）与string、hash、list、set和sorted set五种不同类型的值（value）之间的映射。
3. 使用redis可能出现缓存雪崩、缓存击穿、缓存穿透和数据库和缓存的双写一致性问题等问题。

【详解】

1. 什么是远程字典服务器？

远程：有远程的就有本地的。本地的意思就是你自己的电脑，远程就是指别人的电脑。
字典：就像普通的字典一样，数据字典就是用来对数据进行定义和解释的。它可以用作：数据库、缓存和消息中间件。
服务器：服务器就是远程电脑，服务器可以在网络中为其它客户机提供计算或者应用服务。

2. 为什么redis是高性能的？

1）基于内存实现，完全内存计算；
2）单线程操作，避免了线程上下文切换操作；
3）多路I/O复用的线程模型，实现了一个线程监控多个IO流，及时响应请求；
4）Redis对外部的依赖比较少，属于轻量级内存数据库。

内存: 内存的访问速度是很快的，常用的DDR4内存的读写速度是机械硬盘的30倍；

单线程：避免了线程上下文切换和竞争条件。也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗

什么是线程上下文切换？
即使是单核CPU也支持多线程执行代码，CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间，因为时间片非常短，所以CPU通过不停地切换线程执行，让我们感觉多个线程时同时执行的，时间片一般是几十毫秒（ms）。CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再次加载这个任务的状态，从任务保存到再加载的过程就是一次上下文切换。
这就像我们同时读两本书，当我们在读一本英文的技术书籍时，发现某个单词不认识， 于是便打开中英文词典，但是在放下英文书籍之前，大脑必须先记住这本书读到了多少页的第多少行，等查完单词之后，能够继续读这本书。这样的切换是会影响读书效率的，同样上下文切换也会影响多线程的执行速度。

I/O多路复用技术是什么，为什么很快？
常见的IO模型有阻塞模型、非阻塞模型、IO多路复用，信号驱动IO，异步。

1. 阻塞式IO: 使用系统调用，并一直阻塞直到内核将数据准备好，之后再由内核缓冲区复制到用户态，在等待内核准备的这段时间什么也干不了。
2. 非阻塞式IO：内核在没有准备好数据的时候会返回错误码，而调用程序不会休眠，而是不断轮询询问内核数据是否准备好
3. IO多路复用：类似非阻塞，只不过轮询不是由用户线程去执行，而是由内核去轮询，内核监听程序监听到数据准备好后，调用内核函数复制数据到用户空间
4. 信号驱动IO： 应用进程使用 sigaction 系统调用，内核立即返回，应用进程可以继续执行，也就是说等待数据阶段应用进程是非阻塞的。
5. 异步IO：应用进程执行 aio_read 系统调用会立即返回，应用进程可以继续执行，不会被阻塞，内核会在所有操作完成之后向应用进程发送信号。

不好理解？举例说明:

1. 阻塞：比如某个时候你在去餐厅吃饭，又想出去逛街。但是你不知道饭菜什么时候来，只好坐在餐厅里面等。直到做好，然后吃完才离开去做逛街。这就是典型的阻塞。
2. 非阻塞忙轮询：接着上面的例子，如果用忙轮询的方法，出去我们逛一会，然后每分钟回来问一下服务员：“饭菜好了没？”
3. IO多路复用：餐厅安装了电子屏幕用来显示点餐的状态，逛街一会，回来就不用去询问服务员了，直接看电子屏幕就可以了。
4. 异步IO：不想逛街，餐厅太吵了，回家好好休息一下。于是我们叫外卖，打个电话点餐，然后我可以在家好好休息一下，饭好了送货员送到家里来。这就是典型的异步，只需要打个电话说一下，然后可以做自己的事情，饭好了就送来了。
5. 异步 I/O 与信号驱动 I/O 的区别在于，异步 I/O 的信号是通知应用进程 I/O 完成，而信号驱动 I/O 的信号是通知应用进程可以开始 I/O。

阻塞是个什么概念呢？
比如某个时候你在去餐厅吃饭，又想出去逛街。但是你不知道饭菜什么时候来，只好坐在餐厅里面等。直到做好，然后吃完才离开去做逛街。这就是典型的阻塞。

3. 分布式的含义？

把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给多个计算机进行处理，最后把这些计算结果综合起来得到最终的结果

4. 持久化的含义？

持久化 是将程序数据在持久状态和瞬时状态间转换的机制。通俗的讲，就是瞬时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据（比如持久化至数据库中，能够长久保存）。

5. NoSQL的含义？

NoSQL泛指非关系型的数据库。与之对应的是关系数据库SQL。关系数据库的查询经常会关联两个表的数据，而NoSQL不关联表。

6. 哪五种五种不同类型的值？应用场景有哪些？

1. string：redis 中字符串 value 最大可为512M。可以用来做一些计数器（也是实际工作中最常见的）。
2. hash：键值对集合，是一个字符串类型的 Key和 Value 的映射表，也就是说其存储的Value是一个键值对（Key- Value）。可以用来存放一些具有特定结构的信息。用于用户信息管理。
3. list：简单的字符串列表，按照插入顺序排序，可以添加一个元素到列表的头部（左边）或者尾部（右边），其底层实现是一个链表。可以实现一个简单消息队列功能，做基于redis的分页功能等。
4. set：是一个字符串类型的无序集合。可以用来进行全局去重等。做用户标签。
5. sorted set：是一个字符串类型的有序集合，给每一个元素一个固定的分数score来保持顺序。可以用来做排行榜应用或者进行范围查找等。

• 补充：用sorted set实现一个排行榜需要注意什么问题？
  答：并列问题。

7. 使用redis可能出现的问题

首先我们应该先明确缓存处理的流程：
前台请求，后台先从缓存中取数据，取到直接返回结果，取不到时从数据库中取，数据库取到更新缓存，并返回结果，数据库也没取到，那直接返回空结果。

1. 缓存雪崩：指缓存由于某些原因（比如 宕机、cache服务挂了或者不响应）整体失效了，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难。

• 解决办法：可以给缓存设置不同的缓存时间，更新数据使用互斥锁或者通过双缓存在避免缓存雪崩。

2. 缓存击穿：缓存击穿是指缓存中没有但数据库中有的数据。如果一些key被高并发访问，恰好在这个时间点某个key缓存过期，从而导致了大量请求达到数据库，，这就导致数据库中并发的去执行了很多不必要的查询操作，从而导致巨大冲击和压力。

• 解决办法：使用互斥锁，只让一个请求去load DB，成功之后重新写缓存，其余请求没有获取到互斥锁，可以尝试重新获取缓存中的数据。

3. 缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，导致请求都打到了数据库上，导致数据库异常。

• 解决办法：可以使用互斥锁或者无论是否取到结果都将结果存入缓存，还可以使用有效的机制（比如布隆过滤器）来拦截不合法的key值等。

4. 数据库和缓存的双写一致性问题：
   在高并发请求下很容易导致数据不一致的问题，如果你的业务需要保证数据的强一致性，那么建议不要使用缓存。在数据库中和缓存数据的删除或者写入过程中，如果有失败的情况，会导致数据的不一致。
   解决办法：
   双删延时的解决办法。可以先删除缓存数据，然后再更新数据库数据，最后再隔固定的时间再次删除缓存。
   更新数据库产生的binlog订阅（使用canal）。将有变化的key记录下来，并且尝试去不断的去删除缓存（如果上次删除缓存失败）

[拓展]缓存雪崩、缓存穿透、缓存击穿的区别记忆方法

打个比方,数据库是人,缓存是防弹衣,子弹是线程,本来防弹衣是防止子弹打到人身上的,但是当防弹衣里面没有防弹的物质时,子弹就会穿过它打到人身上。

1. 缓存雪崩（被霰弹枪打）："雪崩"对应的是大量请求。缓存某一时间失效了，然后大量请求到达后端数据库，从而导致数据库崩溃。
2. 缓存击穿（被狙击枪多次打一点）："击穿"对应的是redis某点被（key）击穿。缓存击穿是指缓存中没有但数据库中有的数据。如果一些key被高并发访问，恰好在这个时间点某个key缓存过期，从而导致了大量请求达到数据库，，这就导致数据库中并发的去执行了很多不必要的查询操作，从而导致巨大冲击和压力。
3. 缓存穿透（被巴雷特打）："穿透"最为严重，指的是缓存和数据库被穿透，都穿的透透的了。是指缓存和数据库中都没有的数据，而用户不断发起请求，导致请求都打到了数据库上，导致数据库异常。这时的用户很可能是攻击者。

<参考网站>

https://www.cnblogs.com/afeng2010/p/10048958.html
https://blog.csdn.net/u013328047/article/details/82229710
https://blog.csdn.net/seujava_er/article/details/89879933
https://blog.csdn.net/leiting_imecas/article/details/51355627
https://blog.csdn.net/tjiyu/article/details/52959418?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task
https://blog.csdn.net/weixin_36509612/article/details/99946518
https://blog.csdn.net/u011671986/article/details/79449853
https://www.cnblogs.com/kamicoder/p/6476723.html
https://blog.csdn.net/q15102780705/article/details/102539198
https://blog.csdn.net/sun_qiangwei/article/details/80388318
https://blog.csdn.net/sun_qiangwei/article/details/80388210
https://blog.csdn.net/sanyaoxu_2/article/details/79472465