docker搭建maven私有仓库 （一）引言在实际开发工作中，通常需要搭建maven私有仓库。（二）Nexus介绍　　Nexus 是Maven仓库管理器，如果你使用Maven，你可以从Maven中央仓库 下载所需要的构件（artifact），但这通常不是一个好的做法，你应该在本地架设一个Maven仓库服务器，在代理远程仓库的同时维护本地仓库，以节省带宽和时间，Nexus就可以满足这样的需要。此外，他还提供了强大的仓库管理功能，构件搜索功能，它基于REST，友好的UI是一个extjs的REST客户端，它占用较少的内存，基于简单文件系统而非数据库。这些优点使其日趋成为最流行的Maven仓库管理器。（三）安装docker请参考 Docker安装_Icoolkj的博客（四）docker中安装nexus31、拉取镜像## 通过docker search nexus 命令搜索一下docker公有库在的 nexus相关的镜像 [root@icoolkj ~]# docker search nexus## 拉取nexus3镜像 [root@icoolkj /]# docker pull sonatype/nexus3 Using default tag: latest latest: Pulling from sonatype/nexus3 f70d60810c69: Pull complete 545277d80005: Pull complete 10b49635409a: Pull complete Digest: sha256:3fd7e90bcf49fb55d87d852cab854e5669ed115b09bdb25f47c45ee0797231aa 147.6MB/295.3MB Status: Downloaded newer image for sonatype/nexus3:latest docker.io/sonatype/nexus3:latest [root@icoolkj /]# 2、建立数据储存文件夹## 建立数据存放文件夹，用于docker中nexus的数据与本地物理机映射 [root@icoolkj /]# mkdir -p /usr/local/nexus3/nexus-data [root@icoolkj /]# ll /usr/local/nexus3/ 总用量 4 drwxr-xr-x 2 root root 4096 6月 3 18:06 nexus-data ## 更改权限 [root@icoolkj /]# chmod 777 /usr/local/nexus3/nexus-data/ [root@icoolkj /]# ll /usr/local/nexus3/ 总用量 4 drwxr-xr-x 2 777 root 4096 6月 3 18:06 nexus-data [root@icoolkj /]# 3、安装并运行容器## 编写启动脚本docker-nexus3-start.sh docker rm -f docker-nexus3 || true docker run --name docker-nexus3 \ -p 8081:8081 \ -v /usr/local/nexus3/nexus-data:/nexus-data \ --restart=always \ -d sonatype/nexus3 ## 参数说明 --name nexus #启动该容器的名字，可以自己更改为自己想要的名字 -p 8081:8081 #端口映射，将本地8081端口映射为容器的8081端口,第一个8081可以改成自己想要放开的端口 -v /docker/nexus/nexus-data:/nexus-data # 将容器的/nexus-data地址 代理到 本地/docker/nexus/nexus-data文件夹下 --restart=always #在重启docker时，自动重启改容器。 -d sonatype/nexus3 #即为后台运行一直sonatype/nexus34、获取容器的日志[root@icoolkj nexus3]# docker logs -f --tail 20 docker-nexus3（五）使用nexus31、浏览器访问2、配置Nexus提示输入密码，并告知你的密码储存位置Your admin user password is located in /nexus-data/admin.password on the server.因为docker中nexus3的数据储存位置与本地物理机建立了映射关系，所有在物理机上的地址应该是/usr/local/nexus3/nexus-data/admin.password登录成功后需要更改密码，更改密码需要记住（浏览器都有记住密码的功能，顺⼿点保存⾯，下次你直接登录就好了）；更改密码完成之后，admin.password⽂件⾃动删除！！！## 默认仓库说明 maven-central：maven中央库，默认从https://repo1.maven.org/maven2/拉取jar maven-releases：私库发行版jar，初次安装请将Deployment policy设置为Allow redeploy maven-snapshots：私库快照（调试版本）jar maven-public：仓库分组，把上面三个仓库组合在一起对外提供服务，在本地maven基础配置settings.xml或项目pom.xml中使用## Nexus仓库类型介绍 hosted：本地仓库，通常我们会部署自己的构件到这一类型的仓库。比如公司的第二方库。 proxy：代理仓库，它们被用来代理远程的公共仓库，如maven中央仓库。 group：仓库组，用来合并多个hosted/proxy仓库，当你的项目希望在多个repository使用资源时就不需要多次引用了，只需要引用一个group即可。如图所示，代理仓库负责代理远程中央仓库，托管仓库负责本地资源，组资源库 = 代理资源库 + 托管资源库3、配置阿里云代理仓库1）、新建仓库(Create repository)Repository-->Repositories-->Create repository-->maven2(proxy)填写仓库名称——maven-aliyun，并填入仓库urlhttps://maven.aliyun.com/repository/public2）、配置仓库组(默认已有一个maven-public) 注：注意仓库顺序。maven查找依赖时会依次遍历仓库组中的仓库。## 官方文档中建议： It is recommended practice to place hosted repositories higher in the list than proxy repositories. For proxy repositories, the repository manager needs to check the remote repository which will incur more overhead than a hosted repository lookup. 希望将hosted repositories【托管资源库】的顺序放在proxy repositories【代理资源库】之前，因为一个group【组资源库】中可以涵括这些托管资源库和代理资源库。而一整个的group是作为一个public，一个接口给别人使用的。所以当查找架包的时候，如果代理资源库在前面，那就是先从远程去查找jar，而不是先从托管资源库（本地仓库）去查找是否有jar。这样访问外网的消耗比起来在本地查找，当然是将托管资源库放在代理资源库之前的优先位置了。4、创建角色创建角色（develop），并分配nx-all权限Security-->Roles-->Create注：创建角色的同时可以为当前创建的角色分配权限。5、创建用户创建用户（developer），并授予develop角色Security-->Users-->Create注：创建用户并为创建的用户挂上相应的角色。（六）maven配置文件Maven下的setting.xml文件和项目中的pom.xml文件的关系是：settting.xml文件是全局设置，而pom.xml文件是局部设置。pom.xml文件对于项目来说，是优先使用的。而pom.xml文件中如果没有配置镜像地址的话，就按照settting.xml中定义的地址去查找。修改本地maven配置文件(conf/setting.xml)servers节点下添加以下内容(username和password为刚刚在nexus3中添加的用户和其密码) <!--nexus服务器,id为组仓库name--> <servers> <server> <id>maven-public</id> <username>developer</username> <password>icoolkj</password> </server> <server> <id>maven-releases</id> <!--对应pom.xml的id=releases的仓库--> <username>developer</username> <password>icoolkj</password> </server> <server> <id>maven-snapshots</id> <!--对应pom.xml中id=snapshots的仓库--> <username>developer</username> <password>icoolkj</password> </server> </servers>mirrors节点下添加以下内容 <!--仓库组的url地址，id和name可以写组仓库name，mirrorOf的值设置为central--> <mirrors> <mirror> <id>maven-public</id> <name>maven-public</name> <!--镜像采用配置好的组的地址--> <url>http://182.92.199.85:8081/repository/maven-public/</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors>（七）项目中发布pom.xml配置实际使用中distributionManagement可以配置在parent项目中，子项目无需重复配置。上述配置全部完成后就可以在项目中使用mven clean deploy将项目的jar包上传到自己的私服上了。 <repositories> <repository> <id>maven-public</id> <name>Nexus Repository</name> <url>http://192.168.1.188:8081/repository/maven-public/</url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>maven-public</id> <name>Nexus Plugin Repository</name> <url>http://192.168.1.188:8081/repository/maven-public/</url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </pluginRepository> </pluginRepositories> <!--项目分发信息，在执行mvn deploy后表示要发布的位置。有了这些信息就可以把网站部署到远程服务器或者把构件jar等部署到远程仓库。 --> <distributionManagement> <repository><!--部署项目产生的构件到远程仓库需要的信息 --> <id>maven-releases</id><!-- 此处id和settings.xml的id保持一致 --> <name>Nexus Release Repository</name> <url>http://192.168.1.188:8081/repository/maven-releases/</url> </repository> <snapshotRepository><!--构件的快照部署到哪里？如果没有配置该元素，默认部署到repository元素配置的仓库，参见distributionManagement/repository元素 --> <id>maven-snapshots</id><!-- 此处id和settings.xml的id保持一致 --> <name>Nexus Snapshot Repository</name> <url>http://192.168.1.188:8081/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement>至此，nexus搭建完毕，支持本地部署依赖jar包。

java实现WebSocket服务端 WebSocket服务端配置类import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.stereotype.Service; import org.springframework.web.socket.config.annotation.EnableWebSocket; import org.springframework.web.socket.server.standard.ServerEndpointExporter; /** * websocket配置类 * @author daiyg * @date 2021/8/24 17:19 */ @Service @Configuration @EnableWebSocket public class WebSocketConfig { @Bean public ServerEndpointExporter serverEndpointExporter(){ return new ServerEndpointExporter(); } }服务端代码import com.caso.common.core.utils.StringUtils; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; import org.springframework.stereotype.Component; import javax.websocket.*; import javax.websocket.server.PathParam; import javax.websocket.server.ServerEndpoint; import java.io.IOException; import java.util.ArrayList; import java.util.List; import java.util.concurrent.ConcurrentHashMap; /** * @author daiyg * @date 2021/8/24 18:15 */ @Component @ServerEndpoint(value = "/websocket/{id}/{key}", subprotocols = {"protocol"}) public class WebSocketServer { private static int onlineCount = 0; private static ConcurrentHashMap<String, WebSocketServer> webSocketSet = new ConcurrentHashMap<>(); private static ConcurrentHashMap<String, List<String>> map = new ConcurrentHashMap<>(); //与某个客户端的连接会话，需要通过它来给客户端发送数据 private Session session; private static Logger log = LogManager.getLogger(WebSocketServer.class); private String id = ""; private String key= ""; /** * 连接建立成功调用的方法 */ @OnOpen public void onOpen(@PathParam(value = "id") String id,@PathParam("key") String key, Session session) { this.session = session; this.id = id;//接收到发送消息的人员编号 this.key = key; if ("1".equals(id)) { log.info("非门岗用户连接！"); } else { List<String> ids = new ArrayList<>(); ids = map.get(id); if(StringUtils.isEmpty(ids)){ ids = new ArrayList<>(); } ids.add(key); map.put(id,ids); webSocketSet.put(key, this); //加入set中 } addOnlineCount(); //在线数加1 log.info("用户" + id + "连接成功！当前在线人数为" + getOnlineCount()); try { sendMessage("连接成功"); } catch (IOException e) { log.error("websocket IO异常"); } } /** * 连接关闭调用的方法 */ @OnClose public void onClose() { //删除map中值 List<String> keys = map.get(this.id); for (int i = 0; i < keys.size(); i++) { if(this.key.equals(keys.get(i))){ keys.remove(i); i--; } } webSocketSet.remove(this.key); //从set中删除 subOnlineCount(); //在线数减1 log.info("有一连接关闭！当前在线人数为" + getOnlineCount()); } /** * 收到客户端消息后调用的方法 * * @param message 客户端发送过来的消息 */ @OnMessage public void onMessage(String message) { log.info("来自客户端的消息:" + message); } /** * @param session * @param error */ @OnError public void onError(Session session, Throwable error) { log.error("发生错误"); try { session.close(); } catch (IOException e) { e.printStackTrace(); } error.printStackTrace(); } /** * 服务端主动推送消息 * * @param message * @throws IOException */ public void sendMessage(String message) throws IOException { this.session.getBasicRemote().sendText(message); } /** * 发送信息给指定ID用户，如果用户不在线则返回不在线信息给自己 * * @param message * @param personKeys * @throws IOException */ public static void sendtoUser(String message, String[] personKeys) throws IOException { //获取人员集合 for (String personKey : personKeys) { //获取map中对应的链接 if (map.get(personKey) != null && StringUtils.isNotEmpty(map.get(personKey))) { //遍历给连接人发送信息 for(String s : map.get(personKey)){ webSocketSet.get(s).sendMessage(message); } } else { //如果用户不在线则返回不在线信息给自己 log.error("当前用户不在线：" + personKey); } } } /** * 发送信息给所有人 * * @param * @throws IOException */ public void sendtoAll(String message) throws IOException { for (String key : webSocketSet.keySet()) { try { webSocketSet.get(key).sendMessage(message); } catch (IOException e) { e.printStackTrace(); } } } public static synchronized int getOnlineCount() { return onlineCount; } public static synchronized void addOnlineCount() { WebSocketServer.onlineCount++; } public static synchronized void subOnlineCount() { WebSocketServer.onlineCount--; } }

Java实现WebSocket服务 一、使用Tomcat提供的WebSocket库　　Java可以使用Tomcat提供的WebSocket库接口实现WebSocket服务，代码编写也非常的简单。现在的H5联网游戏基本上都是使用WebSocket协议，基于长连接，服务器可以主动推送消息，而不是传统的网页采用客户端轮询的方式获取服务器的消息。下面给出简单使用Tomcat的WebSocket服务的基本代码结构。@ServerEndpoint("/webSocket") public class WebSocket { @OnOpen public void onOpen(Session session) throws IOException{ logger.debug("新连接"); } @OnClose public void onClose(){ logger.debug("连接关闭"); } @OnMessage public void onMessage(String message, Session session) throws IOException { logger.debug("收到消息"); } @OnError public void onError(Session session, Throwable error){ error.printStackTrace(); } }二、WebSocket协议的整个流程1. 基于TCP协议WebSocket本质是基于TCP协议的，采用Java编写WebSocket服务时可以使用NIO或者AIO实现高并发的服务。2. 握手过程客户端采用TCP协议连接服务器指定端口后，首先需要发送一条HTTP的握手协议GET /web HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: 127.0.0.1:8001 Origin: http://127.0.0.1:8001 Sec-WebSocket-Key: hj0eNqbhE/A0GkBXDRrYYw== Sec-WebSocket-Version: 13请求的头里面必须包含以下内容：Connection 其值为Upgrade，表示升级协议Upgrade 其值为websocket，表示升级为WebSocket协议Sec-WebSocket-Key 客户端发送给服务器的密钥，用于标识每个客户端，其值是16位的随机base64编码。Sec-WebSocket-Version WebSocket的协议版本服务器收到这条协议验证成功后进行协议升级，并且不会关闭Socket连接，并发送给客户端响应升级握手成功的HTTP协议包。HTTP/1.1 101 Switching Protocols Content-Length: 0 Upgrade: websocket Sec-Websocket-Accept: ZEs+c+VBk8Aj01+wJGN7Y15796g= Connection: Upgrade Date: Wed, 21 Jun 2017 03:29:14 GMT　　响应的协议包里面，首先是101的状态码，更换协议；其中最重要的就是Sec-WebSocket-Accept字段。其值是通过客户端的Key加上固定的"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"密钥，通过采用16位的base64编码后发送给客户端验证，如果客户端也验证成功就表示握手完成。String acc = secKey + WEBSOCK_MAGIC_TAG; MessageDigest sh1 = MessageDigest.getInstance("SHA1"); String key = Base64.getEncoder().encodeToString(sh1.digest(acc.getBytes()));3. 数据的读写握手成功后就可以进行数据发送和读取，WebSocket的数据可以是二进制或者纯文本。每次读取和发送数据需要打包成帧数据，需要按照其标准的格式进行发送或读取才能够正常的进行数据通信。上图就是帧数据的结构图，解析帧数据的代码如下，由于是摘录的部分代码，所以只能作为理解和参考，不可直接使用。protected WebSocketFrameData ParseFrame(NetPacketBuffer bytes){ bytes.mark(); WebSocketFrameData frame = new WebSocketFrameData(); int opData = bytes.readByte(); frame.UnPackOpCodeHeader(opData); // 第一步 int length = frame.UnPackMaskHeader(bytes.readByte()); // 第二步 // 读取长度 if (length == 126) { length = bytes.readShort(); } else if (length == 127){ length = (int) bytes.readInt64(); } // 数据不足,进来的是半包 if(length + 4 > bytes.remaining()){ bytes.reset(); // return null; } // 读取mask if frame.mMasked byte[] masks = new byte[4]; // 第三步 for (int i = 0; i < 4; i++) { masks[i] = (byte) bytes.readByte(); } frame.mLength = length; frame.mData = bytes.readMulitBytes(length); frame.MaskData(masks); // 第四步 return frame; }上面代码中第一步是解析出当前帧是否是最后帧mFin标记、操作码mOpCode，采用位处理，具体的实现如下。public void UnPackOpCodeHeader(int opData){ mRsv1 = (opData & 64) == 64; mRsv2 = (opData & 32) == 32; mRsv3 = (opData & 16) == 16; mFin = (opData & 128) == 128; mOpCode = (opData & 15); }第二步在读取长度前，先解析当前帧是否有采用Mask掩码加密处理，并且里面有可能包含整个帧的长度信息，具体看上面的判断代码。public int UnPackMaskHeader(int mkData){ mMasked = (mkData & 128) == 128; return (mkData & 127); // 这里返回的是长度信息 }接下来就是读取Mask内容，注意只有客户端发送给服务端时需要采用Mask对数据做处理，服务端发送给客户端时不需要做处理。最后通过Mask掩码解析出真实数据。public void MaskData(byte[] masks){ if (!mMasked or masks.length == 0) return ; for (int i = 0; i < mLength; i++) { mData[i] = (byte) (mData[i] ^ masks[i % 4]); } }以上就解析出单帧的数据，帧数据可以分为消息数据(细分为文本数据和二进制数据)、PING包、PONG包、CLOSE包、CONTINUATION包(数据未发送完成包)。而且帧数据又有mFin标记数据是否完整，否则需要将多个帧数据合成一个完整的消息数据。// 读取帧数据，可能存在多帧数据，因此需要手动拆分 WebSocketFrameData frame = ParseFrame(mCachePacket); if(frame == null){ break; // 说明数据不完整，暂不处理。 } // 不完整的帧的时候，只有第一帧会标记帧的类型 opCode = opCode == -1? frame.mOpCode: opCode; mCacheFrame.append(frame.mData, 0, frame.mLength); if(!frame.mFin) // 非完整的数据不处理。 { continue; } // 处理完整的数据 switch(opCode) { case WebSocketFrameData.OP_TEXT: case WebSocketFrameData.OP_BINARY: mCacheFrame.flip(); this.OnMessage(mCacheFrame, opCode); break; case WebSocketFrameData.OP_PING: this.OnPing(mCacheFrame); break; case WebSocketFrameData.OP_PONG: this.OnPong(mCacheFrame); break; case WebSocketFrameData.OP_CLOSE: this.OnClosed(); break; case WebSocketFrameData.OP_CONTINUATION: this.Close(); break; } opCode = -1; mCacheFrame.clear();读取整个客户端的协议数据流程就已经完成了，服务端发送回去的数据就只需要注意两点：大的数据包需要分帧数据发送。不需要采用Mask掩码加密，因此Mask位置设置为0，并且不写入掩码数据。原文摘自

别人的字节面经 如果你知道 MySQL 一行记录的存储结构，那么这个问题对你没什么难度。如果你不知道也没关系，这次我跟大家聊聊 MySQL 一行记录是怎么存储的？知道了这个之后，除了能应解锁前面这道面试题，你还会解锁这些面试题：MySQL 的 NULL 值会占用空间吗？MySQL 怎么知道 varchar(n) 实际占用数据的大小？varchar(n) 中 n 最大取值为多少？行溢出后，MySQL 是怎么处理的？这些问题看似毫不相干，其实都是在围绕「 MySQL 一行记录的存储结构」这一个知识点，所以攻破了这个知识点后，这些问题就引刃而解了。MySQL 的数据存放在哪个文件？大家都知道 MySQL 的数据都是保存在磁盘的，那具体是保存在哪个文件呢？MySQL 存储的行为是由存储引擎实现的，MySQL 支持多种存储引擎，不同的存储引擎保存的文件自然也不同。InnoDB 是我们常用的存储引擎，也是 MySQL 默认的存储引擎。所以，本文主要以 InnoDB 存储引擎展开讨论。先来看看 MySQL 数据库的文件存放在哪个目录？mysql> SHOW VARIABLES LIKE 'datadir'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | datadir | /var/lib/mysql/ | +---------------+-----------------+ 1 row in set (0.00 sec)我们每创建一个 database（数据库） 都会在 /var/lib/mysql/ 目录里面创建一个以 database 为名的目录，然后保存表结构和表数据的文件都会存放在这个目录里。比如，我这里有一个名为 my_test 的 database，该 database 里有一张名为 t_order 数据库表。然后，我们进入 /var/lib/mysql/my_test 目录，看看里面有什么文件？[root@xiaolin ~]#ls /var/lib/mysql/my_test db.opt t_order.frm t_order.ibd可以看到，共有三个文件，这三个文件分别代表着：db.opt，用来存储当前数据库的默认字符集和字符校验规则。t_order.frm ，t_order 的表结构会保存在这个文件。在 MySQL 中建立一张表都会生成一个.frm 文件，该文件是用来保存每个表的元数据信息的，主要包含表结构定义。t_order.ibd，t_order 的表数据会保存在这个文件。表数据既可以存在共享表空间文件（文件名：ibdata1）里，也可以存放在独占表空间文件（文件名：表名字.idb）。这个行为是由参数 innodb_file_per_table 控制的，若设置了参数 innodb_file_per_table 为 1，则会将存储的数据、索引等信息单独存储在一个独占表空间，从 MySQL 5.6.6 版本开始，它的默认值就是 1 了，因此从这个版本之后， MySQL 中每一张表的数据都存放在一个独立的 .idb 文件。好了，现在我们知道了一张数据库表的数据是保存在「 表名字.idb 」的文件里的，这个文件也称为独占表空间文件。那这个表空间文件的结构是怎么样的？表空间由段（segment）、区（extent）、页（page）、行（row）组成 ，InnoDB存储引擎的逻辑存储结构大致如下图：下面我们从下往上一个个看看。1、行（row）数据库表中的记录都是按行（row）进行存放的，每行记录根据不同的行格式，有不同的存储结构。后面我们详细介绍 InnoDB 存储引擎的行格式，也是本文重点介绍的内容。2、页（page）记录是按照行来存储的，但是数据库的读取并不以「行」为单位，否则一次读取（也就是一次 I/O 操作）只能处理一行数据，效率会非常低。因此，InnoDB 的数据是按「页」为单位来读写的，也就是说，当需要读一条记录的时候，并不是将这个行记录从磁盘读出来，而是以页为单位，将其整体读入内存。默认每个页的大小为 16KB，也就是最多能保证 16KB 的连续存储空间。页是 InnoDB 存储引擎磁盘管理的最小单元，意味着数据库每次读写都是以 16KB 为单位的，一次最少从磁盘中读取 16K 的内容到内存中，一次最少把内存中的 16K 内容刷新到磁盘中。页的类型有很多，常见的有数据页、undo 日志页、溢出页等等。数据表中的行记录是用「数据页」来管理的，数据页的结构这里我就不讲细说了，之前文章有说过，感兴趣的可以去看这篇文章：换一个角度看 B+ 树总之知道表中的记录存储在「数据页」里面就行。3、区（extent）我们知道 InnoDB 存储引擎是用 B+ 树来组织数据的。B+ 树中每一层都是通过双向链表连接起来的，如果是以页为单位来分配存储空间，那么链表中相邻的两个页之间的物理位置并不是连续的，可能离得非常远，那么磁盘查询时就会有大量的随机I/O，随机 I/O 是非常慢的。解决这个问题也很简单，就是让链表中相邻的页的物理位置也相邻，这样就可以使用顺序 I/O 了，那么在范围查询（扫描叶子节点）的时候性能就会很高。那具体怎么解决呢？在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照区（extent）为单位分配。每个区的大小为 1MB，对于 16KB 的页来说，连续的 64 个页会被划为一个区，这样就使得链表中相邻的页的物理位置也相邻，就能使用顺序 I/O 了。4、段（segment）表空间是由各个段（segment）组成的，段是由多个区（extent）组成的。段一般分为数据段、索引段和回滚段等。索引段：存放 B + 树的非叶子节点的区的集合；数据段：存放 B + 树的叶子节点的区的集合；回滚段：存放的是回滚数据的区的集合，之前讲事务隔离的时候就介绍到了 MVCC 利用了回滚段实现了多版本查询数据。好了，终于说完表空间的结构了。接下来，就具体讲一下 InnoDB 的行格式了。之所以要绕一大圈才讲行记录的格式，主要是想让大家知道行记录是存储在哪个文件，以及行记录在这个表空间文件中的哪个区域，有一个从上往下切入的视角，这样理解起来不会觉得很抽象。InnoDB 行格式有哪些？行格式（row_format），就是一条记录的存储结构。InnoDB 提供了 4 种行格式，分别是 Redundant、Compact、Dynamic和 Compressed 行格式。Redundant 是很古老的行格式了， MySQL 5.0 版本之前用的行格式，现在基本没人用了。由于 Redundant 不是一种紧凑的行格式，所以 MySQL 5.0 之后引入了 Compact 行记录存储方式，Compact 是一种紧凑的行格式，设计的初衷就是为了让一个数据页中可以存放更多的行记录，从 MySQL 5.1 版本之后，行格式默认设置成 Compact。Dynamic 和 Compressed 两个都是紧凑的行格式，它们的行格式都和 Compact 差不多，因为都是基于 Compact 改进一点东西。从 MySQL5.7 版本之后，默认使用 Dynamic 行格式。Redundant 行格式我这里就不讲了，因为现在基本没人用了，这次重点介绍 Compact 行格式，因为 Dynamic 和 Compressed 这两个行格式跟 Compact 非常像。所以，弄懂了 Compact 行格式，之后你们在去了解其他行格式，很快也能看懂。COMPACT 行格式长什么样？先跟 Compact 行格式混个脸熟，它长这样：可以看到，一条完整的记录分为「记录的额外信息」和「记录的真实数据」两个部分。接下里，分别详细说下。记录的额外信息记录的额外信息包含 3 个部分：变长字段长度列表、NULL 值列表、记录头信息。1. 变长字段长度列表varchar(n) 和 char(n) 的区别是什么，相信大家都非常清楚，char 是定长的，varchar 是变长的，变长字段实际存储的数据的长度（大小）不固定的。所以，在存储数据的时候要把这些数据占用的字节数也存起来，存到「变长字段长度列表」里面，读取数据的时候才能根据这个「变长字段长度列表」去读取对应长度的数据。其他 TEXT、BLOB 等变长字段也是这么实现的。为了展示「变长字段长度列表」具体是怎么保存变长字段占用的字节数，我们先创建这样一张表，字符集是 ascii（所以每一个字符占用的 1 字节），行格式是 Compact，t_user 表中 name 和 phone 字段都是变长字段：CREATE TABLE `t_user` ( `id` int(11) NOT NULL, `name` VARCHAR(20) NOT NULL, `phone` VARCHAR(20) DEFAULT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`) USING BTREE ) ENGINE = InnoDB DEFAULT CHARACTER SET = ascii ROW_FORMAT = COMPACT;现在 t_user 表里有这三条记录：接下来，我们看看看看这三条记录的行格式中的 「变长字段长度列表」是怎样存储的。先来看第一条记录：name 列的值为 a，长度是 1 字节，十六进制 0x01phone 列的值为 123，长度是 3 字节，十六进制 0x03age 列和 id 列不是变长字段，所以这里不用管。这些变长字段的长度值会按照列的顺序逆序存放（等下会说为什么要这么设计），所以「变长字段长度列表」里的内容是「 03 01」，而不是 「01 03」。同样的道理，我们也可以得出第二条记录的行格式中，「变长字段长度列表」里的内容是「 04 02」，如下图：第三条记录中 phone 列的值是 NULL，NULL 是不会存放在行格式中记录的真实数据部分里的，所以「变长字段长度列表」里不需要保存值为 NULL 的变长字段的长度。为什么「变长字段长度列表」的信息要按照逆序存放？这个设计是有想法的，主要是因为「记录头信息」中指向下一个记录的指针，指向的是下一条记录的「记录头信息」和「真实数据」之间的位置，这样的好处是向左读就是记录头信息，向右读就是真实数据，比较方便。「变长字段长度列表」中的信息之所以要逆序存放，是因为这样可以使得位置靠前的记录的真实数据和数据对应的字段长度信息可以同时在一个 CPU Cache Line 中，这样就可以提高 CPU Cache 的命中率。同样的道理， NULL 值列表的信息也需要逆序存放。如果你不知道什么是 CPU Cache，可以看这篇文章：面试官：如何写出让 CPU 跑得更快的代码？，这属于计算机组成的知识。每个数据库表的行格式都有「变长字段字节数列表」吗？其实变长字段字节数列表不是必须的。当数据表没有变长字段的时候，比如全部都是 int 类型的字段，这时候表里的行格式就不会有「变长字段长度列表」了，因为没必要，不如去掉以节省空间。所以「变长字段长度列表」只出现在数据表有变长字段的时候。2. NULL 值列表表中的某些列可能会存储 NULL 值，如果把这些 NULL 值都放到记录的真实数据中会比较浪费空间，所以 Compact 行格式把这些值为 NULL 的列存储到 NULL值列表中。如果存在允许 NULL 值的列，则每个列对应一个二进制位（bit），二进制位按照列的顺序逆序排列。二进制位的值为1时，代表该列的值为NULL。二进制位的值为0时，代表该列的值不为NULL。另外，NULL 值列表必须用整数个字节的位表示（1字节8位），如果使用的二进制位个数不足整数个字节，则在字节的高位补 0。还是以 t_user 表的这三条记录作为例子：接下来，我们看看看看这三条记录的行格式中的 NULL 值列表是怎样存储的。先来看第一条记录，第一条记录所有列都有值，不存在 NULL 值，所以用二进制来表示是酱紫的：但是 InnoDB 是用整数字节的二进制位来表示NULL值列表的，现在不足 8 位，所以要在高位补 0，最终用二进制来表示是酱紫的：所以，对于第一条数据，NULL 值列表用十六进制表示是 0x00。接下来看第二条记录，第二条记录 age 列是 NULL 值，所以，对于第二条数据，NULL值列表用十六进制表示是 0x04。最后第三条记录，第三条记录 phone 列 和 age 列是 NULL 值，所以，对于第三条数据，NULL 值列表用十六进制表示是 0x06。我们把三条记录的 NULL 值列表都填充完毕后，它们的行格式是这样的：每个数据库表的行格式都有「NULL 值列表」吗？NULL 值列表也不是必须的。当数据表的字段都定义成 NOT NULL 的时候，这时候表里的行格式就不会有 NULL 值列表了。所以在设计数据库表的时候，通常都是建议将字段设置为 NOT NULL，这样可以节省 1 字节的空间（NULL 值列表占用 1 字节空间）。3. 记录头信息记录头信息中包含的内容很多，我就不一一列举了，这里说几个比较重要的：delete_mask ：标识此条数据是否被删除。从这里可以知道，我们执行 detele 删除记录的时候，并不会真正的删除记录，只是将这个记录的 delete_mask 标记为 1。next_record：下一条记录的位置。从这里可以知道，记录与记录之间是通过链表组织的。在前面我也提到了，指向的是下一条记录的「记录头信息」和「真实数据」之间的位置，这样的好处是向左读就是记录头信息，向右读就是真实数据，比较方便。record_type：表示当前记录的类型，0表示普通记录，1表示B+树非叶子节点记录，2表示最小记录，3表示最大记录 记录的真实数据 记录真实数据部分除了我们定义的字段，还有三个隐藏字段，分别为：row_id、trx_id、roll_pointer，我们来看下这三个字段是什么。row_id如果我们建表的时候指定了主键或者唯一约束列，那么就没有 row_id 隐藏字段了。如果既没有指定主键，又没有唯一约束，那么 InnoDB 就会为记录添加 row_id 隐藏字段。row_id不是必需的，占用 6 个字节。trx_id事务id，表示这个数据是由哪个事务生成的。trx_id是必需的，占用 6 个字节。roll_pointer这条记录上一个版本的指针。roll_pointer 是必需的，占用 7 个字节。如果你熟悉 MVCC 机制，你应该就清楚 trx_id 和 roll_pointer 的作用了。varchar(n) 中 n 最大取值为多少？varchar(n) 字段类型的 n 代表的是最多存储的字符数量，那 n 最大能设置多少？这个问题要考虑两个因素：行格式中「变长字段长度列表」最大能表示多少字节？知道了这个才能知道，一行数据最大能存储多少字节的数据。数据库表的字符集，确定了这个，才能知道 1 个字符占用多少字节。行格式中「变长字段长度列表」有时候是占用 1 字节，有时候是占用 2 字节：如果变长字段允许存储的最大字节数小于等于 255 字节，「变长字段长度列表」就占用 1 个字节；如果变长字段允许存储的最大字节数大于 255 字节，「变长字段长度列表」就占用 2 个字节；可以看到，「 变长字段长度列表」占用的字节数最大不会不超过 2 字节。 2 个字节的最大值是 65535（十进制），从这里可以推测一行记录最大能存储 65535 字节的数据，实际上真的是这样吗？我这里以 ascii 字符集作为例子，这意味着 1 个字符占用 1 字节。那么 varchar(65535) 就意味着最多可存储 65535 个 ascii 字符，刚好满足一行记录最大能存储 65535 字节的数据。我们定义一个 varchar(65535) 类型的字段，字符集为 ascii 的数据库表。CREATE TABLE test ( `name` VARCHAR(65535) NULL ) ENGINE = InnoDB DEFAULT CHARACTER SET = ascii ROW_FORMAT = COMPACT;看能不能成功创建一张表：可以看到，创建失败了。从报错信息就可以知道一行数据的最大字节数是 65535（不包含 TEXT、BLOBs 这种大对象类型），其中包含了 storage overhead。问题来了，这个 storage overhead 是什么呢？其实就是变长字段长度列表和 NULL 值列表，也就是说一行数据的最大字节数 65535，其实是包含「变长字段长度列表」和 「NULL 值列表」所占用的字节数的。我们存储字段类型为 varchar(n) 的数据时，其实分成了三个部分来存储：真实数据真实数据占用的字节数NULL 标识，如果不允许为NULL，这部分不需要前面我创建表的时候，字段是允许为 NULL 的，所以会占用 1 字节来存储 NULL 标识，字段是变长字段且变长字段允许存储的最大字节数大于 255 字节 ，所以会占用 2 字节存储真实数据的占用的字节数，所以最多可以存储 65535- 2 - 1 = 65532 个字节。我们先来测试看看 varchar(65533) 是否可行？可以看到，还是不行，接下来看看 varchar(65532) 是否可行？可以看到，创建成功了。当然，我上面这个例子是针对字符集为 ascii 情况，如果采用的是 UTF-8，varchar(n) 最多能存储的数据计算方式就不一样了：在 UTF-8 字符集下，一个字符串最多需要三个字节，varchar(n) 的 n 最大取值就是 65532/3 = 21844。上面所说的只是针对于一个字段的计算方式。如果有多个字段的话，要保证所有字段的长度 + 变长字段字节数列表所占用的字节数 + NULL值列表所占用的字节数 <= 65535。行溢出后，MySQL 是怎么处理的？MySQL 中磁盘和内存交互的基本单位是页，一个页的大小一般是 16KB，也就是 16384字节，而一个 varchar(n) 类型的列最多可以存储 65532字节，一些大对象如 TEXT、BLOB 可能存储更多的数据，这时一个页可能就存不了一条记录。这个时候就会发生行溢出，多的数据就会存到另外的「溢出页」中。如果一个数据页存不了一条记录，InnoDB 存储引擎会自动将溢出的数据存放到「溢出页」中。在一般情况下，InnoDB 的数据都是存放在 「数据页」中。但是当发生行溢出时，溢出的数据会存放到「溢出页」中。当发生行溢出时，在记录的真实数据处只会保存该列的一部分数据，而把剩余的数据放在「溢出页」中，然后真实数据处用 20 字节存储指向溢出页的地址，从而可以找到剩余数据所在的页。大致如下图所示。上面这个是 Compact 行格式在发生行溢出后的处理。Compressed 和 Dynamic 这两个行格式和 Compact 非常类似，主要的区别在于处理行溢出数据时有些区别。这两种格式采用完全的行溢出方式，记录的真实数据处不会存储该列的一部分数据，只存储 20 个字节的指针来指向溢出页。而实际的数据都存储在溢出页中，看起来就像下面这样：总结MySQL 的 NULL 值是怎么存放的？MySQL 的 Compact 行格式中会用「NULL值列表」来标记值为 NULL 的列，NULL 值并不会存储在行格式中的真实数据部分。NULL值列表会占用 1 字节空间，当表中所有字段都定义成 NOT NULL，行格式中就不会有 NULL值列表，这样可节省 1 字节的空间。MySQL 怎么知道 varchar(n) 实际占用数据的大小？MySQL 的 Compact 行格式中会用「变长字段长度列表」存储变长字段实际占用的数据大小。varchar(n) 中 n 最大取值为多少？一行记录最大能存储 65535 字节的数据，但是这个是包含「变长字段字节数列表所占用的字节数」和「NULL值列表所占用的字节数」。如果一张表只有一个 varchar(n) 字段，且允许为 NULL，字符集为 ascii。varchar(n) 中 n 最大取值为 65532。计算公式：65535 - 变长字段字节数列表所占用的字节数 - NULL值列表所占用的字节数 = 65535 - 2 - 1 = 65532行溢出后，MySQL 是怎么处理的？如果一个数据页存不了一条记录，InnoDB 存储引擎会自动将溢出的数据存放到「溢出页」中。Compact 行格式针对行溢出的处理是这样的：当发生行溢出时，在记录的真实数据处只会保存该列的一部分数据，而把剩余的数据放在「溢出页」中，然后真实数据处用 20 字节存储指向溢出页的地址，从而可以找到剩余数据所在的页。Compressed 和 Dynamic 这两种格式采用完全的行溢出方式，记录的真实数据处不会存储该列的一部分数据，只存储 20 个字节的指针来指向溢出页。而实际的数据都存储在溢出页中。

Linux进程是如何创建出来的？ 在 Linux 中，进程是我们非常熟悉的东东了，哪怕是只写过一天代码的人也都用过它。但是你确定它不是你最熟悉的陌生人？我们今天通过深度剖析进程的创建过程，帮助你提高对进程的理解深度。在这篇文章中，我会用 Nginx 创建 worker 进程的例子作为引入，然后带大家了解一些进程的数据结构 task_struct，最后再带大家看一下 fork 执行的过程。学习完本文，你将深度理解进程中的那些关键要素，诸如进程地址空间、当前目录、父子进程关系、进程打开的文件 fd 表、进程命名空间等。也能学习到内核在保存已经使用的 pid 号时是如何优化内存占用的。我们展开今天的拆解！一、Nginx 之 fork 创建 worker在 Linux 进程的创建中，最核心的就是 fork 系统调用。不过我们先不着急介绍它，先拿多进程服务中的一个经典例子 - Nginx，来看看他是如何使用 fork 来创建 worker 的。Nginx 服务采用的是多进程方式来工作的，它启动的时候会创建若干个 worker 进程出来，来响应和处理用户请求。创建 worker 子进程的源码位于 nginx 源码的 src/os/unix/ngx_process_cycle.c 文件中。通过循环调用 ngx_spawn_process 来创建 n 个 worker 出来。//file:src/os/unix/ngx_process_cycle.c static void ngx_start_worker_processes(...) { ... for (i = 0; i < n; i++) { ngx_spawn_process(cycle, ngx_worker_process_cycle, (void *) (intptr_t) i, "worker process", type); ... } }我们在来看下负责具体进程创建的 ngx_spawn_process 函数。//file: src/os/unix/ngx_process.c ngx_pid_t ngx_spawn_process(ngx_cycle_t *cycle, ngx_spawn_proc_pt proc,...) { pid = fork(); switch (pid) { case -1: //出错了 ... case 0: //子进程创建成功 ... proc(cycle, data); break; } ... }在 ngx_spawn_process 中调用 fork 来创建进程，创建成功后 Worker 进程就将进入自己的入口函数中开始工作了。二、Linux 中对进程的表示在深入理解进程创建之前，我们先来看一下进程的数据结构。在 Linux 中，是用一个 task_struct 来实现 Linux 进程的（其实 Linux 线程也同样是用 task_struct 来表示的，这个我们以后文章单独再说）。我们来看看 task_struct 具体的定义，它位于 include/linux/sched.h//file:include/linux/sched.h struct task_struct { //2.1 进程状态 volatile long state; //2.2 进程线程的pid pid_t pid; pid_t tgid; //2.3 进程树关系：父进程、子进程、兄弟进程 struct task_struct __rcu *parent; struct list_head children; struct list_head sibling; struct task_struct *group_leader; //2.4 进程调度优先级 int prio, static_prio, normal_prio; unsigned int rt_priority; //2.5 进程地址空间 struct mm_struct *mm, *active_mm; //2.6 进程文件系统信息（当前目录等） struct fs_struct *fs; //2.7 进程打开的文件信息 struct files_struct *files; //2.8 namespaces struct nsproxy *nsproxy; }2.1 进程线程状态进程线程都是有状态的，它的状态就保存在 state 字段中。常见的状态中 TASK_RUNNING 表示进程线程处于就绪状态或者是正在执行。TASK_INTERRUPTIBLE 表示进程线程进入了阻塞状态。一个任务（进程或线程）刚创建出来的时候是 TASK_RUNNING 就绪状态，等待调度器的调度。调度器执行 schedule 后，任务获得 CPU 后进入 执行进行运行。当需要等待某个事件的时候，例如阻塞式 read 某个 socket 上的数据，但是数据还没有到达的时候，任务进入 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE 状态，任务被阻塞掉。当等待的事件到达以后，例如 socket 上的数据到达了。内核在收到数据后会查看 socket 上阻塞的等待任务队列，然后将之唤醒，使得任务重新进入 TASK_RUNNING 就绪状态。任务如此往复地在各个状态之间循环，直到退出。一个任务（进程或线程）的大概状态流转图如下。全部的状态值在 include/linux/sched.h 中进行了定义。//file:include/linux/sched.h #define TASK_RUNNING 0 #define TASK_INTERRUPTIBLE 1 #define TASK_UNINTERRUPTIBLE 2 #define __TASK_STOPPED 4 #define __TASK_TRACED 8 ... #define TASK_DEAD 64 #define TASK_WAKEKILL 128 #define TASK_WAKING 256 #define TASK_PARKED 512 #define TASK_STATE_MAX 1024 ......2.2 进程 ID我们知道，每一个进程都有一个进程 id 的概念。在 task_struct 中有两个相关的字段，分别是 pid 和 tgid。//file:include/linux/sched.h struct task_struct { ...... pid_t pid; pid_t tgid; }其中 pid 是 Linux 为了标识每一个进程而分配给它们的唯一号码，称做进程 ID 号，简称 PID。对于没有创建线程的进程(只包含一个主线程)来说，这个 pid 就是进程的 PID，tgid 和 pid 是相同的。2.3 进程树关系在 Linux 下所有的进程都是通过一棵树来管理的。在操作系统启动的时候，会创建 init 进程，接下来所有的进程都是由这个进程直接或者间接创建的的。通过 pstree 命令可以查看你当前服务器上的进程树信息。init-+-atd |-cron |-db2fmcd |-db2syscr-+-db2fmp---4*[{db2fmp}] | |-db2fmp---3*[{db2fmp}] | |-db2sysc---13*[{db2sysc}] | |-3*[db2syscr] | |-db2vend | `-{db2syscr} |-dbus-daemon那么，这棵进程树就是由 task_struct 下的 parent、children、sibling 等字段来表示的。这几个字段将系统中的所有 task 串成了一棵树。2.4 进程调度优先级在 task_struct 中有几个字段是表示进程优先级的，在进程调度的时候会根据这几个字段来决定优先让哪个任务（进程或线程）开始执行。static_prio: 用来保存静态优先级，可以调用 nice 系统直接来修改取值范围为 100~139rt_priority: 用来保存实时优先级,取值范围为 0~99prio: 用来保存动态优先级normal_prio: 它的值取决于静态优先级和调度策略2.5 进程地址空间对于用户进程来讲，内存描述符 mm_struct( mm 代表的是 memory descriptor)是非常核心的数据结构。整个进程的虚拟地址空间部分都是由它来表示的。进程在运行的时候，在用户态其所需要的代码，全局变量数据，以及 mmap 内存映射等全部都是通过 mm_struct 来进行内存查找和寻址的。这个数据结构的定义位于 include/linux/mm_types.h 文件下。//file:include/linux/mm_types.h struct mm_struct { struct vm_area_struct * mmap; /* list of VMAs */ struct rb_root mm_rb; unsigned long mmap_base; /* base of mmap area */ unsigned long task_size; /* size of task vm space */ unsigned long start_code, end_code, start_data, end_data; unsigned long start_brk, brk, start_stack; unsigned long arg_start, arg_end, env_start, env_end; }其中 start_code、end_code 分别指向代码段的开始与结尾、start_data 和 end_data 共同决定数据段的区域、start_brk 和 brk 中间是堆内存的位置、start_stack 是用户态堆栈的起始地址。整个 mm_struct 和地址空间、页表、物理内存的关系如下图。在内核内存区域，可以通过直接计算得出物理内存地址，并不需要复杂的页表计算。而且最重要的是所有内核进程、以及用户进程的内核态，这部分内存都是共享的。另外要注意的是，mm（mm_struct）表示的是虚拟地址空间。而对于内核线程来说，是没有用户态的虚拟地址空间的。所以内核线程的 mm 的值是 null。2.6 进程文件系统信息（当前目录等）进程的文件位置等信息是由 fs_struct 来描述的，它的定义位于 include/linux/fs_struct.h 文件中。//file:include/linux/fs_struct.h struct fs_struct { ... struct path root, pwd; }; //file:include/linux/path.h struct path { struct vfsmount *mnt; struct dentry *dentry; };通过以上代码可以看出，在 fs_struct 中包含了两个 path 对象，而每个 path 中都指向了一个 struct dentry。在 Linux 内核中，denty 结构是对一个目录项的描述。拿 pwd 来举例，该指针指向的是进程当前目录所处的 denty 目录项。假如我们在 shell 进程中执行 pwd，或者用户进程查找当前目录下的配置文件的时候，都是通过访问 pwd 这个对象，进而找到当前目录的 denty 的。2.7 进程打开的文件信息每个进程用一个 files_struct 结构来记录文件描述符的使用情况， 这个 files_struct 结构称为用户打开文件表。它的定义位于 include/linux/fdtable.h。{callout color="#fa0000"}注意：这里用的内核源码一直是 3.10.0, 不同版本的源码这里稍微可能有些出入。{/callout}//file:include/linux/fdtable.h struct files_struct { ...... //下一个要分配的文件句柄号 int next_fd; //fdtable struct fdtable __rcu *fdt; } struct fdtable { //当前的文件数组 struct file __rcu **fd; ...... };在 files_struct 中，最重要的是在 fdtable 中包含的 file **fd 这个数组。这个数组的下标就是文件描述符，其中 0、1、2 三个描述符总是默认分配给标准输入、标准输出和标准错误。这就是你在 shell 命令中经常看到的 2>&1 的由来。这几个字符的含义就是把标准错误也一并打到标准输出中来。在数组元素中记录了当前进程打开的每一个文件的指针。这个文件是 Linux 中抽象的文件，可能是真的磁盘上的文件，也可能是一个 socket。2.8 namespaces在 Linux 中，namespace 是用来隔离内核资源的方式。通过 namespace 可以让一些进程只能看到与自己相关的一部分资源，而另外一些进程也只能看到与它们自己相关的资源，这两拨进程根本就感觉不到对方的存在。具体的实现方式是把一个或多个进程的相关资源指定在同一个 namespace 中，而进程究竟是属于哪个 namespace，都是在 task_struct 中由 *nsproxy 指针表明了这个归属关系。//file:include/linux/nsproxy.h struct nsproxy { atomic_t count; struct uts_namespace *uts_ns; struct ipc_namespace *ipc_ns; struct mnt_namespace *mnt_ns; struct pid_namespace *pid_ns; struct net *net_ns; };命名空间包括PID命名空间、挂载点命名空间、网络命名空间等多个。在这篇文章《动手实验+源码分析，彻底弄懂Linux网络命名空间》这一文中详细介绍过网络命名空间，感兴趣的同学可以详细阅读。三、解密 fork 系统调用前面我们看了 Nginx 使用 fork 来创建 worker 进程，也了解了进程的数据结构 task_struct ，我们再来看看 fork 系统调用的内部逻辑。这个 fork 在内核中是以一个系统调用来实现的，它的内核入口是在 kernel/fork.c 下。//file:kernel/fork.c SYSCALL_DEFINE0(fork) { return do_fork(SIGCHLD, 0, 0, NULL, NULL); }这里注意下调用 do_fork 时传入的第一个参数，这个参数是一个 flag 选项。它可以传入的值包括 CLONE_VM、CLONE_FS 和 CLONE_FILES 等等很多，但是这里只传了一个 SIGCHLD（子进程在终止后发送 SIGCHLD 信号通知父进程），并没有传 CLONE_FS 等其它 flag。//file:include/uapi/linux/sched.h //cloning flags: ... #define CLONE_VM 0x00000100 #define CLONE_FS 0x00000200 #define CLONE_FILES 0x00000400 ...在 do_fork 的实现中，核心是一个 copy_process 函数，它以拷贝父进程的方式来生成一个新的 task_struct 出来。//file:kernel/fork.c long do_fork(unsigned long clone_flags, unsigned long stack_start, unsigned long stack_size, int __user *parent_tidptr, int __user *child_tidptr) { //复制一个 task_struct 出来 struct task_struct *p; p = copy_process(clone_flags, stack_start, stack_size, child_tidptr, NULL, trace); //子任务加入到就绪队列中去，等待调度器调度 wake_up_new_task(p); ... }在创建完毕后，调用 wake_up_new_task 将新创建的任务添加到就绪队列中，等待调度器调度执行。copy_process 的代码很长，我对其进行了一定程度的精简，参加下面的代码。//file:kernel/fork.c static struct task_struct *copy_process(...) { //3.1 复制进程 task_struct 结构体 struct task_struct *p; p = dup_task_struct(current); ... //3.2 拷贝 files_struct retval = copy_files(clone_flags, p); //3.3 拷贝 fs_struct retval = copy_fs(clone_flags, p); //3.4 拷贝 mm_struct retval = copy_mm(clone_flags, p); //3.5 拷贝进程的命名空间 nsproxy retval = copy_namespaces(clone_flags, p); //3.6 申请 pid && 设置进程号 pid = alloc_pid(p->nsproxy->pid_ns); p->pid = pid_nr(pid); p->tgid = p->pid; if (clone_flags & CLONE_THREAD) p->tgid = current->tgid; ...... }可见，copy_process 先是复制了一个新的 task_struct 出来，然后调用 copy_xxx 系列的函数对 task_struct 中的各种核心对象进行拷贝处理，还申请了 pid。接下来我们分小节来查看该函数的每一个细节。3.1 复制进程 task_struct 结构体注意一下，上面调用 dup_task_struct 时传入的参数是 current，它表示的是当前进程。在 dup_task_struct 里，会申请一个新的 task_struct 内核对象，然后将当前进程复制给它。需要注意的是，这次拷贝只会拷贝 task_struct 结构体本身，它内部包含的 mm_struct 等成员只是复制了指针，仍然指向和 current 相同的对象。我们来简单看下具体的代码。 //file:kernel/fork.c static struct task_struct *dup_task_struct(struct task_struct *orig) { //申请 task_struct 内核对象 tsk = alloc_task_struct_node(node); //复制 task_struct err = arch_dup_task_struct(tsk, orig); ... }其中 alloc_task_struct_node 用于在 slab 内核内存管理区中申请一块内存出来。关于 slab 机制请参考- 内核内存管理//file:kernel/fork.c static struct kmem_cache *task_struct_cachep; static inline struct task_struct *alloc_task_struct_node(int node) { return kmem_cache_alloc_node(task_struct_cachep, GFP_KERNEL, node); }申请完内存后，调用 arch_dup_task_struct 进行内存拷贝。//file:kernel/fork.c int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src) { *dst = *src; return 0; }3.2 拷贝 files_struct由于进程之间都是独立的，所以创建出来的新进程需要拷贝一份独立的 files 成员出来。我们看 copy_files 是如何申请和拷贝 files 成员的。//file:kernel/fork.c static int copy_files(unsigned long clone_flags, struct task_struct *tsk) { struct files_struct *oldf, *newf; oldf = current->files; if (clone_flags & CLONE_FILES) { atomic_inc(&oldf->count); goto out; } newf = dup_fd(oldf, &error); tsk->files = newf; ... }看上面代码中判断了是否有 CLONE_FILES 标记，如果有的话就不执行 dup_fd 函数了，增加个引用计数就返回了。前面我们说了，do_fork 被调用时并没有传这个标记。所以还是会执行到 dup_fd 函数：//file:fs/file.c struct files_struct *dup_fd(struct files_struct *oldf, ...) { //为新 files_struct 申请内存 struct files_struct *newf; newf = kmem_cache_alloc(files_cachep, GFP_KERNEL); //初始化 & 拷贝 new_fdt->max_fds = NR_OPEN_DEFAULT; ... }这个函数就是到内核中申请一块内存出来，保存 files_struct 使用。然后对新的 files_struct 进行各种初始化和拷贝。至此，新进程有了自己独立的 files 成员了。3.3 拷贝 fs_struct同样，新进程也需要一份独立的文件系统信息 - fs_struct 成员的。我们来看 copy_fs 是如何申请和初始化 fs_struct 的。//file:kernel/fork.c static int copy_fs(unsigned long clone_flags, struct task_struct *tsk) { struct fs_struct *fs = current->fs; if (clone_flags & CLONE_FS) { fs->users++; return 0; } tsk->fs = copy_fs_struct(fs); return 0; }在创建进程的时候，没有传递 CLONE_FS 这个标志，所会进入到 copy_fs_struct 函数中申请新的 fs_struct 并进行赋值。//file:fs/fs_struct.c struct fs_struct *copy_fs_struct(struct fs_struct *old) { //申请内存 struct fs_struct *fs = kmem_cache_alloc(fs_cachep, GFP_KERNEL); //赋值 fs->users = 1; fs->root = old->root; fs->pwd = old->pwd; ... return fs; }3.4 拷贝 mm_struct前面我们说过，对于进程来讲，地址空间是一个非常重要的数据结构。而且进程之间地址空间也必须是要隔离的，所以还会新建一个地址空间。创建地址空间的操作是在 copy_mm 中执行的。 //file:kernel/fork.c static int copy_mm(unsigned long clone_flags, struct task_struct *tsk) { struct mm_struct *mm, *oldmm; oldmm = current->mm; if (clone_flags & CLONE_VM) { atomic_inc(&oldmm->mm_users); mm = oldmm; goto good_mm; } mm = dup_mm(tsk); good_mm: return 0; }do_fork 被调用时也没有传 CLONE_VM，所以会调用 dup_mm 申请一个新的地址空间出来。//file:kernel/fork.c struct mm_struct *dup_mm(struct task_struct *tsk) { struct mm_struct *mm, *oldmm = current->mm; mm = allocate_mm(); memcpy(mm, oldmm, sizeof(*mm)); ... }在 dup_mm 中，通过 allocate_mm 申请了新的 mm_struct，而且还将当前进程地址空间 current->mm 拷贝到新的 mm_struct 对象里了。地址空间是进程线程最核心的东西，每个进程都有独立的地址空间3.5 拷贝进程的命名空间 nsproxy在创建进程或线程的时候，还可以让内核帮我们创建独立的命名空间。在默认情况下，创建进程没有指定命名空间相关的标记，因此也不会创建。新旧进程仍然复用同一套命名空间对象。3.6 申请pid接下来 copy_process 还会进入 alloc_pid 来为当前任务申请 PID。//file:kernel/fork.c static struct task_struct *copy_process(...) { ... //申请pid pid = alloc_pid(p->nsproxy->pid_ns); //赋值 p->pid = pid_nr(pid); p->tgid = p->pid; ... }注意下，在调用 alloc_pid 的时候，其参数传递的是新进程的 pid namespace。我们来深看一下 alloc_pid 的执行逻辑。//file:kernel/pid.c struct pid *alloc_pid(struct pid_namespace *ns) { //申请 pid 内核对象 pid = kmem_cache_alloc(ns->pid_cachep, GFP_KERNEL); if (!pid) goto out; //调用到alloc_pidmap来分配一个空闲的pid编号 //注意，在每一个命令空间中都需要分配进程号 tmp = ns; pid->level = ns->level; for (i = ns->level; i >= 0; i--) { nr = alloc_pidmap(tmp); pid->numbers[i].nr = nr; ... } ... return pid }这里的 PID 并不是一个整数，而是一个结构体，所以先试用 kmem_cache_alloc 把它申请出来。接下来调用 alloc_pidmap 到 pid 命名空间中申请一个 pid 号出来，申请完后赋值记录。回顾我们开篇提到的一个问题：操作系统是如何记录使用过的进程号的？在 Linux 内部，为了节约内存，进程号是通过 bitmap 来管理的。在每一个 pid 命名空间内部，会有一个或者多个页面来作为 bitmap。其中每一个 bit 位（注意是 bit 位，不是字节）的 0 或者 1 的状态来表示当前序号的 pid 是否被占用。//file:include/linux/pid_namespace.h #define BITS_PER_PAGE (PAGE_SIZE * 8) #define PIDMAP_ENTRIES ((PID_MAX_LIMIT+BITS_PER_PAGE-1)/BITS_PER_PAGE) struct pid_namespace { struct pidmap pidmap[PIDMAP_ENTRIES]; ... }在 alloc_pidmap 中就是以 bit 的方式来遍历整个 bitmap，找到合适的未使用的 bit，将其设置为已使用，然后返回。//file:kernel/pid.c static int alloc_pidmap(struct pid_namespace *pid_ns) { ... map = &pid_ns->pidmap[pid/BITS_PER_PAGE]; }在各种语言中，一般一个 int 都是 4 个字节，换算成 bit 就是 32 bit。而使用这种 bitmap 的思想的话，只需要一个 bit 就可以表示一个整数，相当的节约内存。所以，在很多超大规模数据处理中都会用到这种思想来进行优化内存占用的。3.7 进入就绪队列当 copy_process 执行完毕的时候，表示新进程的一个新的 task_struct 对象就创建出来了。接下来内核会调用 wake_up_new_task 将这个新创建出来的子进程添加到就绪队列中等待调度。//file:kernel/fork.c long do_fork(...) { //复制一个 task_struct 出来 struct task_struct *p; p = copy_process(clone_flags, stack_start, ...); //子任务加入到就绪队列中去，等待调度器调度 wake_up_new_task(p); ... }等操作系统真正调度开始的时候，子进程中的代码就可以真正开始执行了。四、总结在这篇文章中，我用 Nginx 创建 worker 进程的例子作为引入，然后带大家了解一些进程的数据结构 task_struct，最后又带大家看一下 fork 执行的过程。在 fork 创建进程的时候，地址空间 mm_struct、挂载点 fs_struct、打开文件列表 files_struct 都要是独立拥有的，所以都去申请内存并初始化了它们。但由于今天我们的例子父子进程是同一个命名空间，所以 nsproxy 还仍然是共用的。其中 mm_struct 是一个非常核心的数据结构，用户进程的虚拟地址空间就是用它来表示的。对于内核线程来讲，不需要虚拟地址空间，所以 mm 成员的值为 null。另外还学到了内核是用 bitmap 来管理使用和为使用的 pid 号的，这样做的好处是极大地节约了内存开销。而且由于数据存储的足够紧凑，遍历起来也是非常的快。一方面原因是数据小，加载起来快。另外一方面是会加大提高 CPU 缓存的命中率，访问非常快。今天的进程创建过程就学习完了。不过细心的同学可能发现了，我们这里只介绍了子进程的调用。但是对于 Nginx 主进程如何加载起来执行的还没有讲到。我们将来还会展开叙述，敬请期待！