Redis学习

一、场景

#1.场景一：
Redis作为键值数据库，应用比较广泛，为了保证数据的可靠性，Redis需要在磁盘上读写AOF和RDB，但在高并发场景里，这就会直接带来两个新问题：一个是AOF和RDB会造成Redis性能抖动，另一个是Redis集群数据同步和实例恢复时，读RDB比较慢，限制了同步和回恢复速度

#1.处理方法：
可行的解决方案就是使用非易失内存NVM，因为它既能保证告诉的读写，又能快速持久化数据


#2.场景二： Redis的不同使用方法
redis可以用做缓存、数据库、分布式锁，总体来说坑主要体现在以下几个方面：
(1)CPU使用上的坑，例如：数据结构的复杂度，跨CPU核的访问；
(2)内存使用上的坑，例如：主从同步和AOF的内存竞争
(3)存储持久化上的坑，例如：在SSD上做快照的性能抖动
(4)网络通信上的坑，例如：多实例时的异常网络丢包


#为什么懂了一个个技术点，却依然用不好Redis
很多同学都是带着一个个具体的问题来学redis的，比如说：redis数据怎么做持久化，集群方案应该怎么做，这些问题当然很重要，但是如果只是基于解决这个细微的问题，redis的使用能力就很难得到质的提升，只关注零散的技术点，没有建立起一套完整的知识框架，缺乏系统观，但是系统观其实是至关重要的，从某种程度上来说，在解决问题时拥有了系统观，就意味着你能有依据，有章法的定位和解决问题


#3.场景三：redis的长尾延迟问题处理
很多redis服务面临的请求规模很大，因此在评估性能时，仅仅看平均延时已经不够了，举个栗子：假设Redis处理了100个请求，99个请求的相应时间都是1s，而有一个请求的想用时间是100s，那么如果看平均延时，这100个请求的平均延时是1.99s，但是对于这个响应时间是100s的请求而言，它对应的用户体验将是非常糟糕的，如果有100w个请求，哪怕只有1%的请求时100s，这也对应了1万个糟糕的用户体验，这1%的请求延时就属于长尾延时

#3.1分析过程：
单线程redis任何阻塞性操作都会导致长尾延时的产生，
网络阻塞方面：随着对Redis网络框架的理解，Redis网络IO使用了IO复用机制，并不会阻塞在单个进程中
键值对数据结构：
持久化机制下的fork调用
主从库同步时的AOF重写
缓冲区溢出等
绕了一大圈之后，这条影响长尾延时的证据链才得以形成，这样一来，也系统的掌握了影响Redis性能的关键因素路径


#4.Redis的知识全景图
#4.1 Reids的两大维度，三大主线
应用维度： 缓存应用、 集群应用、数据结构应用
系统维度：
处理层：   线程模型  主从复制   数据分片
内存层：   数据结构  哨兵机制   
存储层：   AOF      RDB      负载均衡
网络层：   epool网络框架

#4.2 从系统维度上说，需要了解redis的各项关键技术的设计原理，系统设计规范，例如：run-to-complete模型、epoll模型

#4.3 三大主线
高性能主线：包括线程模型，数据结构，持久化，网络架构
高可靠专线：包括主从复制，哨兵机制
高可扩展主线：包括数据分片，负载均衡

#4.4 学习方式，应用场景驱动和典型案例驱动
应用场景驱动：例如缓存和集群是Redis的两大广泛的应用场景，提到缓存场景，肯定会联想到缓存机制、缓存替换、缓存异常等一连串问题

并不是所有东西都适合采用这种方式，比如说Redis丰富的数据模型，就导致它有很多零碎的应用场景，还有一些问题隐藏的比较深，只有特定的业务场景下(亿级访问压力场景)才会出现，并不是普遍现象，所以也难于梳理出结构化体系。

典型案例驱动：可以重点解读一些对Redis的三高特性影响较大的使用案例，例如：大厂在万亿级访问量和万亿级数据量的情况下对redis的深度优化，解读这些优化时间，有助于透彻理解Redis。梳理一些方法论，做成checklist

#5.Redis各大典型问题，结合相关的技术点，整理出一个问题画像图
主从库：数据丢失、主从不一致、哨兵机制、AOF、RDB、AOF重写
性能：阻塞、抖动、bigkey、AOF重写、异步机制、数据结构
内存：bigkey、占用飙升、数据结构、淘汰机制
缓存：污染、雪崩、穿透
切片机群：数据热点、秒杀、数据分布

以问题->主线->技术点的方式梳理知识点