⭐️前言⭐️
本文主要做Redis相关背景介绍，包括核心能力、重要特性和使用场景。
🍉欢迎点赞 👍 收藏 ⭐留言评论
🍉博主将持续更新学习记录收获，友友们有任何问题可以在评论区留言
🍉博客中涉及源码及博主日常练习代码均已上传GitHub
📍内容导读📍
- 🍅背景介绍
- 🍅1.核心能力
- 🍅2.重要特性
- 🍅3.使用场景
🍅背景介绍
Redis是一个在内存中存储数据的中间件，它在分布式系统中能够大展拳脚。
以下是Redis官网中对于Redis的介绍：
in-memory data store：
内存中存储数据；Redis就是基于网络，把自己内存中的变量给别的进程，甚至别的主机的进程进行使用。
cache：
缓存；20%的热点数据，能满足80%的访问需求；在业界中Redis经常作为缓存来使用。
database：
数据库；Redis也可以作为数据库来使用，而且速度相较于MySQL而言会快很多；但是和MySQL相比最大的劣势是存储空间是有限的
streaming engine/message broker：
流式引擎（消息队列）；这个也是Redis的初心，最初就是用来作为一个“消息中间件”的（消息队列）
消息队列其实就是分布式系统下的生产者消费者模型，当前很少会直接使用Redis作为消息中间件，因为业界有更多更专业的消息中间件。
🍅1.核心能力
In-memory data structures——内存中的数据结构
MySQL是“关系型数据库”，主要是通过“表”的方式来存储组织数据的；
而Redis是“非关系型数据库”，主要是通过“键值对”的方式来存储组织数据的，key都是string，value则可以是一些数据结构。
Programmability——可编程性
针对Redis的操作，可以直接通过简单的交互式命令进行操作，也可以通过一些脚本的方式，批量执行一些操作（可以带有一些逻辑）
Extensibility——扩展性
可以在Redis原有的功能基础上再进行扩展，Redis自身已经提供了很多的数据结构和命令，通过扩展，可以让Redis支持更多的数据结构，以及支持更多的命令（本质上就是一个动态链接库）
Persistence——持久化
Redis是把数据存储在内存上的，内存的数据是“易失”的，进程退出/系统重启都有可能导致数据丢失，为了解决这个问题，Redis会把数据存储在硬盘上，内存为主，硬盘为辅
硬盘相当于对内存的数据备份了一下，如果Redis重启了，就会在重启时加载硬盘中的备份数据，使Redis的内存恢复到重启前的状态
Clustering——集群
Redis作为一个分布式系统中的中间件，能够支持集群是很关键的；
支持水平扩展，类似于“分库分表”
一个Redis能存储的数据是有限的（内存空间有限），如果想存的更多，就需要引入多个主机，部署多个Redis节点，每个Redis存储数据的一部分，构成一个集群。
High availability——高可用
高可用-》冗余/备份，Redis自身是支持“主从结构”的，从节点就相当于主节点的备份了，一个节点挂了，就由另一个节点顶上去，这样就实现了高可用
🍅2.重要特性
天下武功唯快不过，Redis最重要的特性是快，为什么快呢，有以下几个原因：
1、Redis的数据存储在内存中，就比访问硬盘的数据库，要快很多
2、Redis的核心功能都是都是比较简单的逻辑，核心功能都是比较简单的操作内存的数据结构
3、从网络角度上，Redis使用了IO多路复用的方式（使用一个线程，管理很多个socket）
4、Redis使用的是单线程模型，减少了不必要的线程之间的竞争开销
多线程提高效率的前提是CPU密集型的任务，使用多个线程可以充分利用CPU多核资源，但是Redis的核心任务，主要就是操作内存的数据结构，用不到多核CPU，如果非要使用多线程，还会产生一些列不必要的锁开销。
5、Redis是使用C语言开发的
网上这么说，但是个人不认可，因为MySQL也是C语言开发的，还是前四个理由更具说服力
我们谈到的Redis的快，是相对于MySQL这样的关系型数据库而言的，但是如果是直接和内存中的操作变量相比，就没有优势了，甚至更慢了；
现在有这样一个场景，假设有一个单机系统（短视频系统），里面只有一个应用服务器，这个应用服务器里需要存储一些数据，比如存储一下视频的用户点赞数，就需要以视频ID：点赞个数这样的键值对格式来存储，那么使用一个Redis来存，还是直接在内存中存储呢？
如果使用HashMap是直接操作内存，但如果使用Redis是先通过网络，再操作内存的；
所以我们是否要使用Redis，要结合实际的需求来确定，如果引入Redis，因为网络通信的开销很大，所以会更慢，但是有了Redis之后，就可以把数据单独存储，后续应用服务器重启，不会影响到数据内容，而且如果未来要扩展成分布式系统，使用Redis是更佳的。
🍅3.使用场景
Real-time data store——实时存储数据
这里就是把Redis作为数据库来使用，以键值对的形式来存储数据；
大多数情况下，考虑到数据存储，优先考虑的是“大”，但是仍然有一些场景，考虑的是“快”，比如像搜索引擎这样的场景，对于性能的要求是非常高的，这时候就不能用MySQL这样的数据库了，而是需要使用类似于Redis这样的内存数据库来完成，把所有需要检索的数据都存储在内存中。
Caching&session storage——缓存和会话存储
Caching：业界经常将MySQL和Redis结合来使用，全量数据存储在MySQL中，根据二八原则把热点数据拎出来，存储在Redis中，哪怕Redis的数据没了，还可以从MySQL这边再加载回来
session storage：浏览器中的cookie实现用户身份信息的保存，需要session来配合，cookie只是在浏览器这边存储了一个用户的身份标识session ID，服务器这里才真正存储了用户数据，session是存储在应用服务器上的；
如果在分布式系统中通过负载均衡将请求打到服务器上，就有可能导致同一个用户的多次请求，打到了不同的服务器上，而出现需要重新登录多次的情况；
为了解决上述问题，有以下两种解决方法：
1、想办法让负载均衡器，把同一个用户的请求始终打在同一个机器上，不能再轮询了，而是要通过user ID取余计算之类的方式来分配机器
2、把会话数据单独拎出来，放到一组独立的机器上存储（Redis），这样即使应用程序重启了，会话也不会丢失【具体实现见下图】
Streaming&mesaging——消息队列
消息队列（服务器）就是网络版本的生产者消费者模型，它的优势有解耦合和削峰填谷;
Redis的初心是作为消息队列的，但是真正用Redis作消息队列的并不多，业界也有很多知名的消息队列，比如RabbitMQ，Kafka，RocketMQ
⭐️最后的话⭐️
总结不易，希望uu们不要吝啬你们的👍哟(＾Ｕ＾)ノ~ＹＯ！！如有问题，欢迎评论区批评指正😁
