Redis单线程模型
redis单线程模型：redis只使用一个线程，处理所有的命令请求。不是说一个redis服务器进程内部真的就只有一个线程，其实也有多个线程，多个线程是在处理网络IO
假设，有多个客户端，同时操作一个redis服务器：
还记得在多线程章节中，针对于类似于这样的场景，两个线程尝试同时对一个变量进行自增，表面上看是自增了两次，实际上可能只自增了一次。
当前这两个客户端，也相当于"并发"地发起了上述请求~~此时是否意味着服务器这边也存在类似的线程安全的问题呢？
并不会，redis服务器实际上是单线程模型，保证了当前收到的这个多个请求时串行执行的！！！多个请求同时到达redis服务器，也要先在队列中排队，再等待服务器一个一个地取出里面的命令再执行。微观上讲，redis服务器是串行/顺序执行这多个命令的。
这个事情就像高中的时候，下课铃一响，我们这些"干饭人"就会从各自的教学楼奔向食堂，宏观上，我们这些人冲向食堂就是一个并发的过程；微观上，我们进了食堂的门，还是要排队。
redis能够使用单线程模型很好地工作，原因主要在于redis的核心业务逻辑，都是短平快的~~不太消耗cpu资源也就不太吃多核了！！！
弊端：使用redis必须要特别小心，某个操作占用时间长，就会阻塞其他命令的执行！！
Redis快的原因（重要面试题）
Redis虽然是单线程模型，为什么效率还这么高？速度这么快呢？
首先，说redis快对比的是其他的关系型数据库，如：mysql，oracle，sql server
1、redis访问的是内存，数据库则是访问硬盘
2、redis的核心功能比数据库的核心功能更简单。
数据库对于数据的插入删除查询......都有更复杂的功能支持。这样的功能势必要花费更多的开销。比如：针对插入数据，数据库中的各种约束，都会使数据库做额外的工作。
redis干的活少，提供的功能相比mysql也是少了不少~~
3、单线程模型，避免了一些不必要的竞争开销
redis每个基本操作，都是短平快的~~就是简单操作一下内存数据，不是什么特别消耗CPU的操作，就算搞多个线程，提升也不大~~
4、处理网络IO的时候，使用了epoll这样的IO多路复用的机制~
IO多路复用：一个线程，就可以管理多个socket。
针对TCP来说，服务器这边每次要服务一个客户端，都需要给这个客户端安排一个socket，一个服务器服务多个客户端，同时就有很多个socket，这些socket都不是在无时无刻地传输数据，很多时刻下，每个客户端和服务器之间地通信也没有那么频繁，很多socket大部分时间都是静默地，上面是没有数据需要传输的，只有少数socket是活跃的~~
此时就可以使用一个线程来操作socket，节省线程创建和销毁的开销。
举个例子来帮助理解：
晚上，我们一家要吃晚饭，但是我们家对于吃晚饭这件事是很纠结的，往往吃不到一块去。
譬如，我要吃蛋炒饭，我妈妈想吃饺子，我爸爸想吃猪脚饭，而这三个小摊正好都在同一个集市上。
此时就有三种方案：
1、我自己去，先买蛋炒饭，然后等~
再买饺子，继续等~
最后买猪脚饭，等~
这种方案就相当于串行化执行。
2、我们三个人一起去，
我买蛋炒饭
妈妈买饺子
爸爸买猪脚饭
此时相当于多线程执行，效率大大提升了，但是系统开销就大了。
3、我自己去~~
先去买蛋炒饭，等的过程去买饺子，再在等的过程去买猪脚饭~~
这三份饭，哪个先做好了，对应的老板就可以喊我一嗓子~~
这个方案就像IO多路复用，此时就能让我一个线程同时做三件事，能高效完成这件事的前提是：这三件事的交互都不太频繁，大部分时间都在等（等待IO）！！！
如果这三件是都是交互特别频繁的（CPU密集型的），那还是老老实实多搞几个线程靠谱~~
一个线程很容易忙不过来。