从事服务端开发，少不了要接触网络编程。epoll 作为 Linux 下高性能网络服务器的必备技术至关重要，nginx、Redis、Skynet 和大部分游戏服务器都使用到这一多路复用技术。

epoll 很重要，但是 epoll 与 select 的区别是什么呢？epoll 高效的原因是什么？

网上虽然也有不少讲解 epoll 的文章，但要么是过于浅显，或者陷入源码解析，很少能有通俗易懂的。笔者于是决定编写此文，让缺乏专业背景知识的读者也能够明白 epoll 的原理。

本文核心思想是：要让读者清晰明白 epoll 为什么性能好。

文章会从网卡接收数据的流程讲起，串联起 CPU 中断、操作系统进程调度等知识；再一步步分析阻塞接收数据、select 到 epoll 的进化过程；最后探究 epoll 的实现细节。

从网卡接收数据说起

下边是一个典型的计算机结构图，计算机由 CPU、存储器（内存）与网络接口等部件组成，了解 epoll 本质的第一步，要从硬件的角度看计算机怎样接收网络数据。

下图展示了网卡接收数据的过程。

• 在 ① 阶段，网卡收到网线传来的数据；
• 经过 ② 阶段的硬件电路的传输；
• 最终 ③ 阶段将数据写入到内存中的某个地址上。

这个过程涉及到 DMA 传输、IO 通路选择等硬件有关的知识，但我们只需知道：网卡会把接收到的数据写入内存。

网卡接收数据的过程

通过硬件传输，网卡接收的数据存放到内存中，操作系统就可以去读取它们。

如何知道接收了数据？

了解 epoll 本质的第二步，要从 CPU 的角度来看数据接收。理解这个问题，要先了解一个概念——中断。

计算机执行程序时，会有优先级的需求。比如，当计算机收到断电信号时，它应立即去保存数据，保存数据的程序具有较高的优先级（电容可以保存少许电量，供 CPU 运行很短的一小段时间）。

一般而言，由硬件产生的信号需要 CPU 立马做出回应，不然数据可能就丢失了，所以它的优先级很高。CPU 理应中断掉正在执行的程序，去做出响应；当 CPU 完成对硬件的响应后，再重新执行用户程序。中断的过程如下图，它和函数调用差不多，只不过函数调用是事先定好位置，而中断的位置由“信号”决定。

中断程序调用

以键盘为例，当用户按下键盘某个按键时，键盘会给 CPU 的中断引脚发出一个高电平，CPU 能够捕获这个信号，然后执行键盘中断程序。下图展示了各种硬件通过中断与 CPU 交互的过程。

CPU 中断（图片来源：net.pku.edu.cn）

现在可以回答“如何知道接收了数据？”这个问题了：当网卡把数据写入到内存后，网卡向 CPU 发出一个中断信号，操作系统便能得知有新数据到来，再通过网卡中断程序去处理数据。

进程阻塞为什么不占用 CPU 资源？

了解 epoll 本质的第三步，要从操作系统进程调度的角度来看数据接收。阻塞是进程调度的关键一环，指的是进程在等待某事件（如接收到网络数据）发生之前的等待状态，recv、select 和 epoll 都是阻塞方法。下边分析一下进程阻塞为什么不占用 CPU 资源？

为简单起见，我们从普通的 recv 接收开始分析，先看看下面代码：

1
2
3
4
5
6
7
8
9
10
11
12

//创建socket
int s = socket(AF_INET, SOCK_STREAM, 0);   
//绑定
bind(s, ...)
//监听
listen(s, ...)
//接受客户端连接
int c = accept(s, ...)
//接收客户端数据
recv(c, ...);
//将数据打印出来
printf(...)

这是一段最基础的网络编程代码，先新建 socket 对象，依次调用 bind、listen 与 accept，最后调用 recv 接收数据。recv 是个阻塞方法，当程序运行到 recv 时，它会一直等待，直到接收到数据才往下执行。

那么阻塞的原理是什么？

工作队列

操作系统为了支持多任务，实现了进程调度的功能，会把进程分为“运行”和“等待”等几种状态。运行状态是进程获得 CPU 使用权，正在执行代码的状态；等待状态是阻塞状态，比如上述程序运行到 recv 时，程序会从运行状态变为等待状态，接收到数据后又变回运行状态。操作系统会分时执行各个运行状态的进程，由于速度很快，看上去就像是同时执行多个任务。

下图的计算机中运行着 A、B 与 C 三个进程，其中进程 A 执行着上述基础网络程序，一开始，这 3 个进程都被操作系统的工作队列所引用，处于运行状态，会分时执行。

抽奖系统的背景引入

本文给大家分享一个之前经历过的抽奖系统的流量削峰架构的设计方案。

抽奖、抢红包、秒杀，这类系统其实都有一些共同的特点，那就是在某个时间点会瞬间涌入大量的人来点击系统，给系统造成瞬间高于平时百倍、千倍甚至几十万倍的流量压力。

比如抽奖，有一种场景：某个网站或者APP规定好了在某个时间点，所有人都可以参与抽奖，那么可能百万级的用户会蹲守在那个时间点，到时间大家一起参与这个抽奖。

抢红包，可能是某个电视节目上，突然说扫码可以抢红包，那么电视机前可能千万级的用户会瞬间一起打开手机扫码抢红包。

秒杀更是如此，所谓秒杀，意思是让大家都在电脑前等着，在某个时间突然就可以抢购某个限量的商品

比如某个手机平时卖5999，现在限量100台价格才2999，50%的折扣，可能百万级的用户就会蹲守在电脑前在比如凌晨12点一起点击按钮抢购这款手机。

类似的场景其实现在是很多的，那么本文就用一个抽奖系统举例，说说应对这种瞬时超高并发的流量，应该如何设计流量削峰的架构来应对，才能保证系统不会突然跨掉？

结合具体业务需求分析抽奖系统

假设现在有一个抽奖的业务场景，用户在某个时间可以参与抽奖，比如一共有1万个奖，奖品就是某个礼物。

然后参与抽奖的用户可能有几十万，一瞬间可能几十万请求涌入过来，接着瞬间其中1万人中奖了，剩余的人都是没中奖的。然后中奖的1万人的请求会联动调用礼品服务，完成这1万中奖人的礼品发放。

简单来说，需求场景就是如此，然而这里就有很多的地方值得优化了。

一个未经过优化的系统架构

先来看一个未经过任何优化的系统架构，简单来说就是有一个负载均衡的设备会把瞬间涌入的超高并发的流量转发到后台的抽奖服务上。

这个抽奖服务就是用普通的Tomcat来部署的，里面实现了具体的抽奖逻辑，假设刚开始最常规的抽奖逻辑是基于MySQL来实现的，接着就是基于Tomcat部署的礼品服务，抽奖服务如果发现中奖了需要调用礼品服务去发放礼品。

如下图所示：

负载均衡层的限流

防止用户重复抽奖

首先第一次在负载均衡层可以做的事情，就是防止重复抽奖。

我们可以在负载均衡设备中做一些配置，判断如果同一个用户在1分钟之内多次发送请求来进行抽奖，就认为是恶意重复抽奖，或者是他们自己写的脚本在刷奖，这种流量一律认为是无效流量，在负载均衡设备那个层次就给直接屏蔽掉。

举个例子，比如有几十万用户瞬间同时抽奖，最多其实也就几十万请求而已，但是如果有人重复抽奖或者是写脚本刷奖，那可能瞬间涌入的是几百万的请求，就不是几十万的请求了，所以这里就可以把无效流量给拦截掉。

如下图所示：

全部开奖后暴力拦截流量

其实秒杀、抢红包、抽奖，这类系统有一个共同的特点，那就是假设有50万请求涌入进来，可能前5万请求就直接把事儿干完了，甚至是前500请求就把事儿干完了，后续的几十万流量是无效的，不需要让他们进入后台系统执行业务逻辑了。

什么意思呢？

举个例子，秒杀商品，假设有50万人抢一个特价手机，人家就准备了100台手机，那么50万请求瞬间涌入，其实前500个请求就把手机抢完了，后续的几十万请求没必要让他转发到Tomcat服务中去执行秒杀业务逻辑了，不是吗？

抽奖、红包都是一样的 ，可能50万请求涌入，但是前1万个请求就把奖品都抽完了，或者把红包都抢完了，后续的流量其实已经不需要放到Tomcat抽奖服务上去了，直接暴力拦截返回抽奖结束就可以了。

这样的话，其实在负载均衡这一层（可以考虑用Nginx之类的来实现）就可以拦截掉99%的无效流量。

所以必须让抽奖服务跟负载均衡之间有一个状态共享的机制。

就是说抽奖服务一旦全部开奖完毕，直接更新一个共享状态。然后负载均衡感知到了之后，后续请求全部拦截掉返回一个抽奖结束的标识就可以了。

这么做可能就会做到50万人一起请求，结果就可能2万请求到了后台的Tomcat抽奖服务中，48万请求直接拦截掉了。

我们可以基于Redis来实现这种共享抽奖状态，它非常轻量级，很适合两个层次的系统的共享访问。

当然其实用ZooKeeper也是可以的，在负载均衡层可以基于zk客户端监听某个znode节点状态。一旦抽奖结束，抽奖服务更新zk状态，负载均衡层会感知到。

下图展示了上述所说的过程：

Tomcat线程数量的优化

其次就是对于线上生产环境的Tomcat，有一个至关重要的参数是需要根据自己的情况调节好的，那就是他的工作线程数量。

背景引入：很多同学看不懂kafka参数

今天给大家聊一个很有意思的话题，大家知道很多公司都会基于Kafka作为MQ来开发一些复杂的大型系统。

而在使用Kafka的客户端编写代码与服务器交互的时候，是需要对客户端设置很多的参数的。

所以我就见过很多年轻的同学，可能刚刚加入团队，对Kafka这个技术其实并不是很了解。

此时就会导致他们看团队里的一些资深同事写的一些代码，会看不懂是怎么回事，不了解背后的含义，这里面尤其是一些Kafka参数的设置。

所以这篇文章，我们还是采用老规矩画图的形式，来聊聊Kafka生产端一些常见参数的设置，让大家下次看到一些Kafka客户端设置的参数时，不会再感到发怵。

一段Kafka生产端的示例代码

1
2
3
4
5
6
7
8
9
10
11
12
13

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092"); 
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("buffer.memory", 67108864); 
props.put("batch.size", 131072); 
props.put("linger.ms", 100); 
props.put("max.request.size", 10485760); 
props.put("acks", "1"); 
props.put("retries", 10); 
props.put("retry.backoff.ms", 500);

KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);

内存缓冲的大小

首先我们看看“buffer.memory”这个参数是什么意思？

Kafka的客户端发送数据到服务器，一般都是要经过缓冲的，也就是说，你通过KafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲里，然后把很多消息收集成一个一个的Batch，再发送到Broker上去的。

所以这个“buffer.memory”的本质就是用来约束KafkaProducer能够使用的内存缓冲的大小的，他的默认值是32MB。

那么既然了解了这个含义，大家想一下，在生产项目里，这个参数应该怎么来设置呢？

你可以先想一下，如果这个内存缓冲设置的过小的话，可能会导致一个什么问题？

首先要明确一点，那就是在内存缓冲里大量的消息会缓冲在里面，形成一个一个的Batch，每个Batch里包含多条消息。

然后KafkaProducer有一个Sender线程会把多个Batch打包成一个Request发送到Kafka服务器上去。

那么如果要是内存设置的太小，可能导致一个问题：消息快速的写入内存缓冲里面，但是Sender线程来不及把Request发送到Kafka服务器。

消息中间件在生产系统中的使用

这是一个非常典型的生产环境的问题，很多公司都会在生产系统里使用MQ，即消息队列，或者消息中间件。

也就是说，一个系统跟另外一个系统之间进行通信的时候，假如系统A希望发送一个消息给系统B，让他去处理。

但是系统A不关注系统B到底怎么处理或者有没有处理好，所以系统A把消息发送给MQ，然后就不管这条消息的“死活”了，接着系统B从MQ里消费出来处理即可。

至于怎么处理，是否处理完毕，什么时候处理，都是系统B的事儿，与系统A无关。

上述过程，可以通过下图看的很清晰：

这样的一种通信方式，就是所谓的“异步”通信方式

对于系统A来说，只要把消息发给MQ，然后系统B就会异步的去进行处理了，系统A不需要“同步”的等待系统B处理完。

这样的好处是什么呢？

两个字：解耦

系统A要跟系统B通信，但是他不需要关注系统B如何处理的一些细节。我们来举几个例子说明：

比如，A不需要关注B什么时候处理完，这样假如系统B处理一个消息要耗费10分钟也不关系统A的事儿。

否则，系统A直接调用系统B的接口，系统B一下子处理了10分钟怎么办？难不成系统A也阻塞等待10分钟？

再比如，系统A不需要关注系统B处理成功与否，即使系统B处理失败了，也是系统B自己去考虑这个场景和重新尝试处理。

否则如果系统调用系统B的接口，万一处理失败了报错了，系统A受到一个调用异常该怎么处理？

还有，系统A不需要关注系统B是否存活。万一要是系统B挂掉了，系统A通过MQ来通信也不需要管系统B的“死活”，系统B自己恢复了之后就可以从MQ消费消息再次处理即可。

否则系统A直接调用系统B的接口，万一系统B挂了，难道系统A还要把消息暂存到数据库？等待系统B恢复了再给他发过去吗？

这就是通过MQ进行异步通信，让两个系统解耦之后的好处，可以大幅度提升整个大系统的容错性，增加系统的弹性，而不是处处耦合，一个系统出错连带导致其他系统全部出错。

解耦之后，即使出错也只是大系统中的一个系统B出错而已，不影响别人。

经典生产案例：早教盒子APP的发货

接下来用一个经典的生产案例给大家说说MQ在生产的使用。

现在很多早教类的APP，都会提供早教盒子，什么意思呢？

早教APP提供的核心服务就是三块：

1. APP里的早教视频课程
2. 线上微信群的助教答疑指导
3. 线下送你早教盒子，里面有很多上课道具

这样一个妈妈陪伴孩子上早教的过程可能是这样的：

• 首先在APP里看早教视频课程，孩子看着很感兴趣。
• 接着妈妈从早教盒子里取出来道具，陪孩子把视频里的游戏和任务都做一遍，让孩子加深印象
• 最后每天妈妈会打卡，有助教会来给妈妈进行答疑。

所以说，假设现在我们要在一个早教APP里购买一个早教课程，他的流程大致如下：

• 选择购买早教课程
• 直接支付
• 创建订单
• 给用户增加课程权限
• 通知仓库准备发早教盒子
• 通知物流公司去仓库取早教盒子进行配送。

我们来分析一下每个环节。首先你要是购买一个早教课程，那么点击“购买”的按钮之后，一般直接会跳入一个支付界面。

这个时候，你就可以直接选择支付了。此时后台系统一定会通过支付系统跟第三方支付系统进行通信，比如说支付宝、微信之类的，然后等待支付完成。

一旦支付完成，就会在自己内部系统干两个事：

• 第一，给这个用户id创建一个订单；
• 第二，给这个用户id增加看某个早教视频课程的权限。

此时用户其实在“我的订单”界面就可以看到自己的订单了，而且在“我的课程”界面，就可以开始看早教课程的视频了。

如果对上面过程不太理解的，再看看下面的图，应该就清楚了：

但是现在问题主要在后面两个步骤，现在你的订单系统作为核心入口，他要通知仓库系统去扣减一个早教盒子的库存。

同时，还得准备好早教盒子的发货（比如说提前打包装箱，准备一些给快递公司使用的发货单之类的，需要帖子箱子上）。

然后通知第三方物流公司的系统，可以去自己的仓库取早教盒子发货了。

这两个步骤需要涉及到对仓库系统以及第三方物流公司系统的调用，那么是采用订单系统直接同步调用那两个系统的方式吗？

恐怕不妥，因为这里最大的问题就是性能问题和可用性问题。

正则表达式在几乎所有语言中都可以使用，无论是前端的JavaScript、还是后端的Java、c#。他们都提供相应的接口/函数支持正则表达式。

很神奇的是：无论你大学选择哪一门计算机语言，都没有关于正则表达式的课程给你修，在你学会正则之前，你只能看着那些正则大师们，写了一串外星文似的字符串，替代了你用一大篇幅的if else代码来做一些数据校验。

既然喜欢，那就动手学呗，可当你百度出一一堆相关资料时，你发现无一不例外的枯燥至极，难以学习。

本文旨在用最通俗的语言讲述最枯燥的基本知识！

正则基础知识点

元字符

万物皆有缘，正则也是如此，元字符是构造正则表达式的一种基本元素。

我们先来记几个常用的元字符：

元字符说明.匹配除换行符以外的任意字符w匹配字母或数字或下划线或汉字s匹配任意的空白符d匹配数字匹配单词的开始或结束^匹配字符串的开始$匹配字符串的结束

有了元字符之后，我们就可以利用这些元字符来写一些简单的正则表达式了，

比如：

匹配有abc开头的字符串：abc或者^abc

匹配8位数字的QQ号码：^dddddddd$

匹配1开头11位数字的手机号码：^1dddddddddd$

重复限定符

有了元字符就可以写不少的正则表达式了，但细心的你们可能会发现：别人写的正则简洁明了，而不理君写的正则一堆乱七八糟而且重复的元字符组成的。正则没提供办法处理这些重复的元字符吗？

答案是有的！

为了处理这些重复问题，正则表达式中一些重复限定符，把重复部分用合适的限定符替代，下面我们来看一些限定符：

语法说明*重复零次或更多次+重复一次或更多次?重复零次或一次{n}重复n次{n,}重复n次或更多次{n,m}重复n到m次

有了这些限定符之后，我们就可以对之前的正则表达式进行改造了，比如：

匹配8位数字的QQ号码：^d{8}$

匹配1开头11位数字的手机号码：^1d{10}$

匹配银行卡号是14~18位的数字：^d{14,18}$

匹配以a开头的，0个或多个b结尾的字符串^ab*$

分组

从上面的例子（4）中看到，限定符是作用在与他左边最近的一个字符，那么问题来了，如果我想要ab同时被限定那怎么办呢？

正则表达式中用小括号()来做分组，也就是括号中的内容作为一个整体。

因此当我们要匹配多个ab时，我们可以这样。

如匹配字符串中包含0到多个ab开头：^(ab)*

转义

我们看到正则表达式用小括号来做分组，那么问题来了：

如果要匹配的字符串中本身就包含小括号，那是不是冲突？应该怎么办？

针对这种情况，正则提供了转义的方式，也就是要把这些元字符、限定符或者关键字转义成普通的字符，做法很简答，就是在要转义的字符前面加个斜杠，也就是即可。

如要匹配以(ab)开头：^((ab))*

条件或

回到我们刚才的手机号匹配，我们都知道：国内号码都来自三大网，它们都有属于自己的号段，比如联通有130/131/132/155/156/185/186/145/176等号段，假如让我们匹配一个联通的号码，那按照我们目前所学到的正则，应该无从下手的，因为这里包含了一些并列的条件，也就是“或”，那么在正则中是如何表示“或”的呢？

正则用符号 | 来表示或，也叫做分支条件，当满足正则里的分支条件的任何一种条件时，都会当成是匹配成功。

那么我们就可以用“或”条件来处理这个问题：^(130|131|132|155|156|185|186|145|176)d{8}$

区间

看到上面的例子，是不是看到有什么规律？是不是还有一种想要简化的冲动？

实际是有的

正则提供一个元字符中括号 [] 来表示区间条件。

• 限定0到9 可以写成[0-9]
• 限定A-Z 写成[A-Z]
• 限定某些数字 [165]

那上面的正则我们还改成这样：

^((13[0-2])|(15[56])|(18[5-6])|145|176)d{8}$

好了，正则表达式的基本用法就讲到这里了，其实它还有非常多的知识点以及元字符，我们在此只列举了部分元字符和语法来讲，旨在给那些不懂正则或者想学正则但有看不下去文档的人做一个快速入门级的教程，看完本教程，即使你不能写出高大上的正则，至少也能写一些简单的正则或者看得懂别人写的正则了。

正则进阶知识点

零宽断言

无论是零宽还是断言，听起来都古古怪怪的，

那先解释一下这两个词。

断言：俗话的断言就是“我断定什么什么”，而正则中的断言，就是说正则可以指明在指定的内容的前面或后面会出现满足指定规则的内容，意思正则也可以像人类那样断定什么什么，比如”ss1aa2bb3”,正则可以用断言找出aa2前面有bb3，也可以找出aa2后面有ss1.

零宽：就是没有宽度，在正则中，断言只是匹配位置，不占字符，也就是说，匹配结果里是不会返回断言本身。

意思是讲明白了，那他有什么用呢？

我们来举个栗子：假设我们要用爬虫抓取csdn里的文章阅读量。通过查看源代码可以看到文章阅读量这个内容是这样的结构

“阅读数：641“

其中也就‘641’这个是变量，也就是说不同文章不同的值，当我们拿到这个字符串时，需要获得这里边的‘641’有很多种办法，但如果正则应该怎么匹配呢？

下面先来讲几种类型的断言：