多路复用

redis的线程模型 Redis基于Reactor模式开发了文件事件处理器，文件事件处理器包含了4个部分：多个socket，io多路复用程序，文件事件分派器，事件处理器。事件处理器又分为连接应答处理器，命令请求处理器，命令回复处理器，事件处理器是单线程的，但是通过io多路复用可以监听多个socket，实现了高性能的通讯模型。多个socket可能并发不同的事件，但是通过io多路复用程序将不同的事件压入一个队列中，每次从队列中取出一个socket给文件事件分派器。事件分派器把socket给对应的事件处理器，事件处理器处理完成后，io多路服用程序才会将下一个socket从队列中取出给文件事件分派器，文件事件分派器再根据当前socket的事件选择对应的处理器来处理。 客户端与redis的一次通讯流程 首先redis服务端进程初始化的时候，会将server socket的AE_READABLE事件与连接应答处理器关联，这里的server socket是专门用来创建客户端与服务端socket连接的特殊socket。 客户端socket01像向redis进程的server socket请求建立连接，此时server socket会产生AE_READABLE事件，io多路复用程序监听到事件后会将该socket压入队列中，文件事件分派器从队列中拿到这个socket后交给连接应答处理器

1、为什么使用redis 2、使用redis有什么缺点 3、单线程的redis为什么这么快 4、redis的数据类型，以及每种数据类型的使用场景 5、redis的过期策略以及内存淘汰机制 6、redis和数据库双写一致性问题 7、如何应对缓存穿透和缓存雪崩问题 8、如何解决redis的并发竞争问题 正文 1、为什么使用redis 分析:博主觉得在项目中使用redis，主要是从两个角度去考虑:性能和并发。当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等)代替，并不是非要使用redis。因此，这个问题主要从性能和并发两个角度去答。 回答:如下所示，分为两点 （一）性能 如下图所示，我们在碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。 题外话：忽然想聊一下这个迅速响应的标准。其实根据交互效果的不同，这个响应时间没有固定标准。不过曾经有人这么告诉我:”在理想状态下，我们的页面跳转需要在瞬间解决，对于页内操作则需要在刹那间解决。另外，超过一弹指的耗时操作要有进度提示，并且可以随时中止或取消，这样才能给用户最好的体验。” 那么瞬间、刹那、一弹指具体是多少时间呢？ 根据《摩诃僧祗律》记载 一刹那者为一念，二十念为一瞬，二十瞬为一弹指

为何要有操作系统 程序员无法把所有的硬件操作细节都了解到，因为管理这些硬件并加以优化使用是非常繁琐的工作，这个繁琐的工作就是操作系统来干的，有了他，程序员就从这些繁琐的工作中解脱出来，只需要考虑自己的应用软件的编写就可以了，应用软件直接使用操作系统提供的功能来间接使用硬件 操作系统的位置 操作系统位于计算机硬件与应用软件之间，本质也是一个软件。操作系统由操作系统的内核（运行于内核态，管理硬件资源）以及系统调用（运行于用户态，为应用程序员写的应用程序提供系统调用接口）两部分组成 操作系统的功能 隐藏了丑陋的硬件调用接口，为应用程序员提供调用硬件资源更好，更简单，更清晰的模型（系统调用接口）应用程序员有了这些接口后，就不用再考虑操作硬件的细节，专心开发自己的应用程序即可 将应用程序对硬件资源的竞态请求变的有序化（多路复用） 操作系统的发展 第一代（1940~1955）真空管和穿孔卡片 特点：没有操作系统的概念，所有的程序设计都由纯粹的机器语言编写 工作过程：程序员在墙上的机时表预约一段时间，然后程序员拿着他的插件板到机房里，将自己的插件版接到计算机里，这几个小时内他独享整个计算机的资源，后面的一批人都得等着（2万多个真空管经常有被烧坏的情况出现），后来出现了穿孔卡片，可以将程序写在卡片上，然后读入机而不用插件板 优点：程序员在申请的时间段里独享整个资源，即时调整自己的程序

Nginx是一个开源，高性能，可高的http中间件，代理服务 常见的中间件服务： httpd apache基金会的产品 IIS 微软的产品 gws google的产品 选择Nginx的原因： 第一：IO多路复用（多线程） IO 多路复用的实现方式：select poll epoll 来源： https://www.cnblogs.com/yujianadu/p/12066685.html

I/O多路复用实际上就是用select, poll, epoll监听多个io对象，当io对象有变化（有数据）的时候就通知用户进程。好处就是单个进程可以处理多个socket。当然具体区别我们后面再讨论，现在先来看下I/O多路复用的流程： 1. 阻塞I/O模型 老李去火车站买票，排队三天买到一张退票。 耗费：在车站吃喝拉撒睡 3天，其他事一件没干。 2. 非阻塞I/O模型 老李去火车站买票，隔12小时去火车站问有没有退票，三天后买到一张票。耗费：往返车站6次，路上6小时，其他时间做了好多事。 3. I/O复用模型 1.select/poll 老李去火车站买票，委托黄牛，然后 每隔6小时电话黄牛询问 ，黄牛三天内买到票，然后老李去火车站交钱领票。 耗费： 打电话 2.epoll 老李去火车站买票，委托黄牛， 黄牛买到后即通知老李去领 ，然后老李去火车站交钱领票。 耗费： 无需打电话 4. 信号驱动I/O模型 老李去火车站买票， 给售票员留下电话 ，有票后，售票员电话通知老李，然后老李去火车站交钱领票。 耗费：无需打电话 5. 异步I/O模型 老李去火车站买票，给售票员留下电话，有票后，售票员电话通知老李并快递送票上门。 耗费：无需打电话 1. I/O多路复用 1.1 它的形成原因 如果一个I/O流进来，我们就开启一个进程处理这个I/O流。那么假设现在有一百万个I/O流进来，

int select ( int maxfd , fd_set * readset , fd_set * writeset , fd_set * exceptset , const struct timeval * timeout ) ; 返回：若有就绪描述符则为其数目，若超时则为 0 ，若出错则为 - 1 maxfd 表示的是待测试的描述符基数，它的值是待测试的最大描述符加 1。 void FD_ZERO ( fd_set * fdset ) ; 　　　　　　 void FD_SET ( int fd , fd_set * fdset ) ; 　　 void FD_CLR ( int fd , fd_set * fdset ) ; 　　　 int FD_ISSET ( int fd , fd_set * fdset ) ; struct timeval { long tv_sec ; /* seconds */ long tv_usec ; /* microseconds */ } ; 1、将timeval置为空，表示如果没有IO事件发生就将一直等待下去 2、表示一段固定的时间后，select从阻塞调用中返回 3、将tv_sec和tv_usec都置为0，表示不等待，立即返回 来源： CSDN 作者： track_down 链接： https://blog.csdn.net/qq

1、多路复用 　　作用：一个通讯连接的基础上，可以同时进行多个请求响应处理。 　　由于上层应用协议的制定问题，很多传统服务不能支持多路复用，例如：http1.1，sqlserver 和 redis 等。有些服务提供批量处理，但是这些处理都是基于一个RPS(每秒请求数)下。 　　单路存在的问题：每个请求响应独占一个连接，独占连接网络读写，导致连接大量时间被闲置，无法更好的利用网络资源。 　　独占读写IO，这样导致 RPS 处理量必须由 IO 承担，IO 操作起来比较损耗性能，所以再高 RPS 处理就会出现性能问题。 　　多路复用在一个连接上同时处理多个请求响应，大大减少连接的数量，并提高了网络的处理能力。 　　共享连接，不同请求响应数据包可以合并到一个 IO 上处理，降低 IO 的处理量，性能更好。 　　NIO 和 Netty 就用到了多路复用的技术 2、StringBuilder 为什么线程不安全 　　StringBuilder 都是通过一个 char 数据存储字符串的，并且数组是可变的。 　　StringBuilder 有两个成员变量(继承的父类里)：char[] value 和 int count。并且 StringBuilder 的 append() 方法调用父类 AbstractStringBuilder 的 append() 方法。其中有一行：count+= len

1.管道机制、多路复用 1.1 管道机制(Pipelining) HTTP 1.1 引入了管道机制（Pipelining），即客户端可通过同一个TCP连接同时发送多个请求。如果客户端需要请求两个资源，以前的做法是在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求；而管道机制则允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。 1.2 多路复用(Multiplexing) 虽然 HTTP 1.1 默认启用长TCP连接，但所有的请求-响应都是按序进行的(这里的长连接可理解成半双工协议。即便是HTTP 1.1引入了管道机制，也是如此)。复用同一个TCP连接期间，即便是通过管道同时发送了多个请求，服务端也是按请求的顺序依次给出响应的；而客户端在未收到之前所发出所有请求的响应之前，将会阻塞后面的请求(排队等待)，这称为"队头堵塞"（Head-of-line blocking）。 HTTP/2复用TCP连接则不同，虽然依然遵循请求-响应模式，但客户端发送多个请求和服务端给出多个响应的顺序不受限制，这样既避免了"队头堵塞"，又能更快获取响应。在复用同一个TCP连接时，服务器同时(或先后)收到了A、B两个请求，先回应A请求，但由于处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后

服务器端编程经常需要构造高性能的IO模型，常见的IO模型有四种： （1）同步阻塞IO（Blocking IO）：即传统的IO模型。 （2）同步非阻塞IO（Non-blocking IO）：默认创建的socket都是阻塞的，非阻塞IO要求socket被设置为NONBLOCK。注意这里所说的NIO并非Java的NIO（New IO）库。 （3）IO多路复用（IO Multiplexing）：（经典的Reactor设计模式，基于此设计模式，对用户线程来说在I/O的第一阶段即内核准备数据阶段，是异步非阻塞的，但对于Reactor来说，它是阻塞的，它阻塞在了select/epoll上。在I/O第二阶段即内核拷贝数据到用户空间，通过Reactor通知用户线程数据到达了或者回调用户线程注册的回调函数，用户线程此时要发起系统调用recv，recv这个系统调用有些人认为它算是一个阻塞过程，有些人认为这不是阻塞过程，具体情况参照描述的上下文决定。如果用户线程直接调用select/epoll，那么用户线程是同步阻塞的），Java中的Selector和Linux中的epoll都是这种模型。 （4）异步IO（Asynchronous IO）：经典的Proactor设计模式，也称为异步非阻塞IO。 同步和异步的概念描述的是用户线程与内核的交互方式

redis服务器就是一个事件驱动程序，服务器需要处理两类事件： 文件事件(file-event)： redis服务器通过套接字与客户端进行连接。 文件事件就是服务器对于套接字操作的抽象。 服务器与客户端的通信会产生相应的文件事件 服务器通过监听并处理这些事件来完成一系列网络通信操作 时间事件(time-event): redis服务器中的一些操作(比如serverCron函数)需要在给定时间点执行 时间事件就是服务器对于这类定时操作的抽象 文件事件 redis给予reactor模式开发了自己的网络事件处理器：文件事件处理器(file-event-handler) 文件事件处理器使用I/O多路复用程序来同时监听多个套接字；文件事件处理器会根据目前执行的任务来为套接字关联不同的事件处理器 文件事件处理器以单线程方式运行，通过使用I/O多路复用来监听多个套接字 既可以很好的以单线程方式与redis服务器中其他模块对接 又可以利用多路复用机制保障了高性能的网络通信 文件事件处理器构成 套接字 I/O多路复用程序 文件事件分派器 事件处理器 文件事件(file-event)是对套接字的操作抽象 每当一个套接字准备好执行accept,write,read.close等操作时，就会产生一个文件事件 一个服务器会有多个套接字，所以文件事件会并发出现 I