原理，老师讲的真好。相见恨晚。
以下内容是按视频课程的章节安排，在我自己听完课之后，凭借记忆总结的。（可能存在疏漏不足，后期补全和修正，同时也在这个过程巩固我自己的对于这个组件相关原理的学习）
2、原理篇-Redis网络模型
2.1 用户空间和内核态空间
为什么分层：用户应用不能直接操纵硬件CPU 内存 网关等设备，要不然就乱套了。
怎么实现：中间需要一个中间层 被称为内核空间，然后用户应用放在用户空间，系统那些直接操作硬件设备的放在内核空间
流程：如上图，应用这边发起了一个读操作，调用系统调用（硬件）的接口，然后硬件驱动那边在获取数据，系统调用的那个接口，就一直等着这个数据回来（这里其实就造成了阻塞。）
还有怎么把数据拷回去呢，是放在内核空间的buffer（缓冲区）里面，然后再复制到用户空间的缓冲区。
从这里也可以看出，那里显得比较繁琐了吧。
时间的浪费 系统接口调用等着数据回来这个过程是阻塞的
空间时间的浪费 buffer在两个空间之间的拷贝
2.2.网络模型-阻塞IO
老师这里直接搬出 unix 网络编程 这本书，上面详尽的介绍了几种IO模型
就是上面这样的
2.3 网络模型-非阻塞IO
用户应用进程一直调用recvfrom来确认，
其实屁用没有。消耗的时间还是阻塞那么久，然后还让这边一直调用，然后CPU 蹭的一下上去了。
这里的进程就像这个收银员一样，然后那个任务就像是顾客点餐。阻塞IO就是他一直站那里点餐，然后收银员就等着。
非阻塞就是就是顾客一直站那里点餐，然后收银员 一直问：“选好了没有 选好了没有 选好了没有”。
2.4 网络模型-IO多路复用
继续上面的点餐，来说。能怎么优化呢。
IO多路复用，在假定只有一个服务员的情况下，怎么利用。
那不就是那个顾客点好了，让服务员过去记一下。这个是比较合理的
2.5 网络模型-IO多路复用-select方式
现在顾客点好餐了（任务完成了），呼叫服务员。
服务员那边有个小铃铛，知道有人点好餐了，他要过去，但是不知道是哪个人点的，他要一路上问过去。
然后在实现上面：
这个用的还是 long int 数组，存储的数量的数量是固定的，现在数据量多大呀，不够用
然后他这个知道任务完成了，还要通过遍历，太慢了
然后他还需要把 数组在内核态和用户态之间拷贝来拷贝去。
2.6 网络模型-IO多路复用模型-poll模式
和select一个德行
这个用的还是 long int 数组，存储的数量的数量是固定的，现在数据量多大呀，不够用 ，不过用的是链表了，可以无限了，
但还是要遍历，那无限长的链表，无限遍历，更慢了
然后他还需要把 链表在内核态和用户态之间拷贝来拷贝去。
2.7 网络模型-IO多路复用模型-epoll函数
最后也就是现在用的多的。
这个是那个任务好了（谁点餐了），直接把号发过去。合理
用的红黑树（用来存任务节点），和链表（用来返回那些已经完成的节点id）。之后把这个链表返回就行了
任务节点都有这个回调函数，就是任务完成的时候把自己的id写到链表里面、
实现上有三个操作 epoll_create（初始化，直接存在内核态） epoll_ctl（新增节点） epoll_wait（看看哪个完成了，插入链表）
他就是把 之前两个那种新增+监听的操作，拆成两个（epoll_ctl epoll_wait）了，
2.8、网络模型-epoll中的ET和LT
ET就是一直重复的发
LT就发一次
ET会惊群效应，可能就一个完成了，他就都发出去了
LT是发一次，就把那个链表断开了，节点删除了，但我们可以通过epoll_ctl再把这个链表建起来，达成ET模式的效果。
2.9 网络模型-基于epoll的服务器端流程
3.0 、网络模型-信号驱动
3.0.1 异步IO
3.0.2 对比
3.1 、网络模型-Redis是单线程的吗？为什么使用单线程
在内存命令上还是单线程的。
但整体而言，已经是多线程的形状了。
单线程快呀，内存多快呀，制约速度的永远是IO，网络IO 或者数据库IO
然后 多线程的弊端，额外的上下文切换，然后安全性还要加锁，又慢了
3.2 、Redis的单线程模型-Redis单线程和多线程网络模型变更
是在网络IO的时候引入多线程来加速的，也就是将请求数据写入那里，还有，将结果写入reply那里。
3、Redis通信协议-RESP协议
3.1、Redis通信协议-基于Socket自定义Redis的客户端
命令的解析（得解析的出来），还有命令回复得让服务器看得懂
所以有个这个协议
+单行字符串
-异常
$ 多行字符串
*数组
：数字
3.2、Redis内存回收-过期key处理
惰性删除
周期删除：slow fast
3.3 Redis内存回收-内存淘汰策略
8种 lru lfu random ttl allkeys
