Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载 在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。
因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能 最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value 的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能。比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可 以做高性能的tag系统等等。
另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的 memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据 的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
字符串（String）：二进制安全字符串。
列表（List）：根据插入顺序排序的字符串元素列表，基于链表实现。
集合（Set）：唯一的乱序的字符串元素的集合。
有序集合（Sorted Set）：与集合类似，但是每个字符串元素都与一个称为score的数字相关联。元素总是按其score排序，并且可以检索一定score范围的元素。
哈希（Hash）：由字段与值相关联组成的映射，字段和值都是字符串。
位图（Bitmap）:像操作位数组一样操作字符串值，可以设置和清除某个位，对所有为1的位进行计数，找到第一个设置1的位，找到第一个设置0的位等等。
HyperLogLogs：一种概率数据结构，使用较小的内存空间来统计唯一元素的数量，误差小于1％。
1.完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；
2.数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；
3.采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4.使用多路 I/O 复用模型，非阻塞 IO；
5.使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；
1.缓存：减轻数据库的压力，提高系统性能。
2.排行榜：利用 Redis 的 SortSet（有序集合）实现；
3.计数器/限速器：利用 Redis 中原子性的自增操作，我们可以统计类似用户点赞数、用户访问数等。这类操作如果用 MySQL，频繁的读写会带来相当大的压力；限速器比较典型的使用场景是限制某个用户访问某个 API 的频率，常用的有抢购时，防止用户疯狂点击带来不必要的压力；
4.好友关系：利用集合的一些命令，比如求交集、并集、差集等。可以方便解决一些共同好友、共同爱好之类的功能；
5.消息队列：除了 Redis 自身的发布/订阅模式，我们也可以利用 List 来实现一个队列机制，比如：到货通知、邮件发送之类的需求，不需要高可靠，但是会带来非常大的 DB 压力，完全可以用 List 来完成异步解耦；
6.Session 共享：Session 是保存在服务器的文件中，如果是集群服务，同一个用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用 Redis 保存 Session 后，无论用户落在那台机器上都能够获取到对应的 Session 信息。
缓存穿透指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。
解决方案：
1)将空数据也缓存：占有一定的空间，可能带来短期的数据不一致。
如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟，
2)使用布隆过滤器bloom filter：是一种预防的方案，占用空间少、误差可控。
将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
缓存雪崩是指在某一个时间段，缓存集中过期失效。当某一个时刻出现大规模的缓存失效的情况，那么就会导致大量的请求直接打在数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩。
解决方案
1)过期时间设置随机值:在原有的失效时间上加上一个随机值，比如，1-5分钟随机。这样就避免了同一时间大量数据过期现象的发生而导致缓存雪崩。
2)分布式部署且均匀分布热点数据:如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。同时，分布式集群可以防止Redis宕机导致缓存雪崩的问题。
3)热点数据永不过期:设置热点数据永远不过期。
4)使用熔断机制。当流量到达一定的阈值时，就直接返回“系统拥挤”之类的提示，防止过多的请求打在数据库上。至少能保证一部分用户是可以正常使用，其他用户多刷新几次也能得到结果。
5)提高数据库的容灾能力，可以使用分库分表，读写分离的策略。
造成缓存雪崩的关键在于在同一时间大规模的key失效。出现这个问题有下面几种可能：
第一种可能是Redis宕机，
第二种可能是采用了相同的过期时间。
某一个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，甚至可能打垮数据库。
解决方案：
1.加互斥锁。在并发的多个请求中，只有第一个请求线程能拿到锁并执行数据库查询操作，其他的线程拿不到锁就阻塞等着，等到第一个线程将数据写入缓存后，直接走缓存。
2.JVM 锁保证了在单台服务器上只有一个请求走到数据库，通常来说已经足够保证数据库的压力大大降低，同时在性能上比分布式锁更好。
需要注意的是，无论是使用“分布式锁”，还是“JVM 锁”，加锁时要按 key 维度去加锁。
Redis通过MULTI、EXEC、WATCH等一组命令集合，来实现事务机制。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。简言之，Redis事务就是顺序性、一次性、排他性的执行一个队列中的一系列命令。
Redis执行事务的流程如下：开始事务（MULTI）、命令入队、执行事务（EXEC）、撤销事务（DISCARD ）。
可以的，Redis提供两个指令生成RDB，分别是save和bgsave。
如果是save指令，会阻塞，因为是主线程执行的。
如果是bgsave指令，是fork一个子进程来写入RDB文件的，快照持久化完全交给子进程来处理，父进程则可以继续处理客户端的请求。
一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。
如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。
缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
解决方案
1.直接写个缓存刷新页面，上线时手工操作一下；
2.数据量不大，可以在项目启动的时候自动进行加载；
3.定时刷新缓存；
Redis6.0采用多线程IO，不过命令的执行还是单线程的。
Redis6.0之前，IO线程和执行线程都是单线程的。
分表是EXPIRE和PERSIST命令进行设置。
加锁重键（互斥锁）：
热键不过期：在缓存中创建一个时间戳，先判断时间戳是否过期，如果没有过期返回原数据，过期了则访问数据源。
官方微信
官方抖音
京公网安备 11030102010736号