【动力节点】Redis入门到高级教程，全网最新最全redis缓存教程，redis百科大全
1 Redis概述
1.1 Redis简介
Redis，Remote Dictionary Server，远程字典服务，是一个使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、NoSQL开源内存数据库，其提供多种语言的API。
Redis之所以称之为字典服务，是因为Redis是一个key-value存储系统。支持存储的value类型很多，包括String(字符串)、List(链表)、Set(集合)、Zset(sorted set --有序集合)和Hash（哈希类型）等。
熟练使用和运维Redis已经成为开发运维人员的一个必备技能。
1.1.1 NoSQL
NoSQL（“non-relational”， “Not Only SQL”），泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在处理web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，出现了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，特别是大数据应用难题。
1.1.1.1 键值存储数据库
就像Map一样的key-value对。典型代表就是Redis。
1.1.1.2 列存储数据库
关系型数据库是典型的行存储数据库。其存在的问题是，按行存储的数据在物理层面占用的是连续存储空间，不适合海量数据存储。而按列存储则可实现分布式存储，适合海量存储。典型代表是HBase。
1.1.1.3 文档型数据库
其是NoSQL与关系型数据的结合，最像关系型数据库的NoSQL。典型代表是MongoDB。
1.1.1.4 图形(Graph)数据库
用于存放一个节点关系的数据库，例如描述不同人间的关系。典型代表是Neo4J。
1.2 Redis的用途
Redis在生产中使用最多的场景就是做数据缓存。即客户端从DBMS中查询出的数据首先写入到Redis中，后续无论哪个客户端再需要访问该数据，直接读取Redis中的即可，不仅减小了RT，而且降低了DBMS的压力。
根据Redis缓存的数据与DBMS中数据的同步性划分，缓存一般可划分为两类：实时同步缓存，与阶段性同步缓存。
实时同步缓存是指，DBMS中数据更新后，Redis缓存中的存放的相关数据会被立即清除，以促使再有对该数据的访问请求到来时，必须先从DBMS中查询获取到最新数据，然后再写入到Redis。
阶段性同步缓存是指，Redis缓存中的数据允许在一段时间内与DBMS中的数据不完全一致。而这个时间段就是这个缓存数据的过期时间。
1.3 Redis特性
能够做缓存的技术、中间件很多，例如，MyBatis自带的二级缓存、Memched等。只所以在生产中做缓存的产品几乎无一例外的会选择Redis，是因为它有很多其它产品所不具备的特性。
-
性能极高：Redis读的速度可以达到11w次/s，写的速度可以达到8w次/s。只所以具有这么高的性能，因为以下几点原因：（1）Redis的所有操作都是在内存中发生的。（2）Redis是用C语言开发的。（3）Redis源码非常精细（集性能与优雅于一身）。
-
简单稳定：Redis源码很少。早期版本只有2w行左右。从3.0版本开始，增加了集群功能，代码变为了5w行左右。
-
持久化：Redis内存中的数据可以进行持久化，其有两种方式：RDB与AOF。
-
高可用集群：Redis提供了高可用的主从集群功能，可以确保系统的安全性。
-
丰富的数据类型：Redis是一个key-value存储系统。支持存储的value类型很多，包括String(字符串)、List(链表)、Set(集合)、Zset(sorted set --有序集合)和Hash（哈希类型）等，还有BitMap、HyperLogLog、Geospatial类型。
-
BitMap：一般用于大数据量的二值性统计。
-
HyperLogLog：其是Hyperlog Log，用于对数据量超级庞大的日志做去重统计。
-
Geospatial：地理空间，其主要用于地理位置相关的计算。
-
强大的功能：Redis提供了数据过期功能、发布/订阅功能、简单事务功能，还支持Lua脚本扩展功能。
-
客户端语言广泛：Redis提供了简单的TCP通信协议，编程语言可以方便地的接入Redis。所以，有很多的开源社区、大公司等开发出了很多语言的Redis客户端。
-
支持ACL权限控制：之前的权限控制非常笨拙。从Redis6开始引入了ACL模块，可以为不同用户定制不同的用户权限。
| ACL，Access Control List，访问控制列表，是一种细粒度的权限管理策略，可以针对任意用户与组进行权限控制。目前大多数Unix系统与Linux 2.6版本已经支持ACL了。Zookeeper早已支持ACL了。
Unix与Linux系统默认使用是UGO（User、Group、Other）权限控制策略，其是一种粗粒度的权限管理策略。 |
| — | -
支持多线程IO模型：Redis之前版本采用的是单线程模型，从6.0版本开始支持了多线程模型。
1.4 Redis的IO模型
Redis客户端提交的各种请求是如何最终被Redis处理的？Redis处理客户端请求所采用的处理架构，称为Redis的IO模型。不同版本的Redis采用的IO模型是不同的。
1.4.1 单线程模型
对于Redis 3.0及其以前版本，Redis的IO模型采用的是纯粹的单线程模型。即所有客户端的请求全部由一个线程处理。
Redis的单线程模型采用了多路复用技术。
| 对于多路复用器的多路选择算法常见的有三种：select模型、poll模型、epoll模型。
-
poll模型的选择算法：采用的是轮询算法。该模型对客户端的就绪处理是有延迟的。
-
epoll模型的选择算法：采用的是回调方式。根据就绪事件发生后的处理方式的不同，又可分为LT模型与ET模型。
|
| — |每个客户端若要向Redis提交请求，都需要与Redis建立一个socket连接，并向事件分发器注册一个事件。一旦该事件发生就表明该连接已经就绪。而一旦连接就绪，事件分发器就会感知到，然后获取客户端通过该连接发送的请求，并将由该事件分发器所绑定的这个唯一的线程来处理。如果该线程还在处理多个任务，则将该任务写入到任务队列等待线程处理。
只所以称为事件分发器，是因为它会根据不同的就绪事件，将任务交由不同的事件处理器去处理。
1.4.2 混合线程模型
从Redis 4.0版本开始，Redis中就开始加入了多线程元素。处理客户端请求的仍是单线程模型，但对于一些比较耗时但又不影响对客户端的响应的操作，就由后台其它线程来处理。例如，持久化、对AOF的rewrite、对失效连接的清理等。
1.4.3 多线程模型
Redis 6.0版本，才是真正意义上的多线程模型。因为其对于客户端请求的处理采用的是多线程模型。
多线程IO模型中的“多线程”仅用于接受、解析客户端的请求，然后将解析出的请求写入到任务队列。而对具体任务（命令）的处理，仍是由主线程处理。这样做使得用户无需考虑线程安全问题，无需考虑事务控制，无需考虑像LPUSH/LPOP 等命令的执行顺序问题。
1.4.4 优缺点总结
1.4.4.1 单线程模型
- 优点：可维护性高，性能高。不存在并发读写情况，所以也就不存在执行顺序的不确定性，不存在线程切换开销，不存在死锁问题，不存在为了数据安全而进行的加锁/解锁开销。
- 缺点：性能会受到影响，且由于单线程只能使用一个处理器，所以会形成处理器浪费。
1.4.4.2 多线程模型
- 优点：其结合了多线程与单线程的优点，避开了它们的所有不足
- 缺点：该模型没有显示不足。如果非要找其不足的话就是，其并非是一个真正意义上的“多线程”，因为真正处理“任务”的线程仍是单线程。所以，其对性能也是有些影响的。