多进程命令

‘壹’ 多进程OSPF及进程号的意义

在配置OSPF时，我们采用的是router ospf命令，在该命令后面需要加上这个OSPF进程的进程号(Process-Id)，进程号用于在一台路由器上区分不同的OSPF进程。这就有点像人格分裂的感觉 —— 一个自然人有多种不同人格，每种人格之间相互独立，互不影响。进程号的取值范围是1-65535。

拓扑中，R1使用进程号10创建了一个OSPF进程，同时激活了自己的直连接口FE0/0，而R2使用进程号20创建了一个OSPF进程，同时也在自己的直连接口上激活了OSPF。虽然这两个进程号不一样，但是R1-R2之间的邻居关系建立是完全没有问题的。因为OSPF进程号只具有本地意义，路由器之间交互的所有OSPF报文中，都不会体现任何关于进程号的信息。进程号只在一台路由器上用于区分多个OSPF进程，因此对于R1而言，它并不关心它的直连OSPF邻居R2使用的是什么OSPF进程号，10也号，20也罢，这就有点像“自己的事自己知道就行“ -- 本地意义。

当然，在实际的网络部署中，除非有特定的需求，我们还是建议全网使用统一的进程号，虽然每台设备使用不同的进程号对OSPF的运行没什么影响，但是却给网络的管理和维护带来了多余的成本，你不会这么干的，对吧?

1. 多个OSPF进程

拓扑很有意思，在R2上，常规的做法是用一个进程号创建一个OSPF进程，同时将自己的两个直连接口都宣告进这个OSPF进程，但是为了讲解OSPF进程ID的本地意义，我这里在R2上使用两个进程号分别创建了两个OSPF进程，并且分别宣告了R2的两个直连接口，换句话说，R2使用OSPF进程12与R1建立邻居关系，使用OSPF进程23与R3建立OSPF邻居关系。如此一来，R2在本地就有了两个OSPF进程，使用进程号12及23进行区分。整个网络中也就出现了两个OSPF域(OSPF Domain)。这两个OSPF进程，都会各自从其邻居R1和R3学习到OSPF路由，但是值得强调的是：

这两个OSPF进程相互独立和隔离(两个OSPF Domain)，两个进程独立维护各自的LSDB。换而言之R2通过OSPF进程12从R1学习到的OSPF路由(严格的说，应该是LSA)，例如描述1.1.1.0/24的LSA，缺省时不会传递到进程23的(这是因为在R2，这两个OSPF进程互相独立互相隔离)，当然，从R3学习过来的OSPF路由，R2虽然自己能学习到，但是照样不会传递给R1，这就好像，这两个进程虽然都在R2上，但是彼此之间有着一道鸿沟，世界上最遥远的距离，莫过于此啊。

再者，R2这两个OSPF进程虽然说彼此隔离，但是都可以为R2自身贡献路由，例如如果R1更新过来一条路由1.1.1.0/24，R3更新过来一条3.3.3.0/24，那么在R2的全局路由表里都是能看到这两条路由的。但这两条路由不会互相灌进对方的OSPF进程(造成的直接结果是R1没有R3的路由，R3没有R1的路由)，除非 -- 对了，路由重发布，你懂的。

2. OSPF进程之间的路由重发布

同一台路由器上的不同OSPF进程相互独立，各自维护自己的LSDB。如果要把一个OSPF进程内的路由注入到另一个进程中，就需要部署路由重发布，例如上图所示，R2作为一台ASBR，要把进程12中的路由注入到进程23中，配置如上。当然，如果要实现全网路由互通，则还需要在OSPF进程12中，将进程23的路由重发布进来。

3. 什么时候会使用不同的OSPF进程

我们知道一台路由器可以创建多个OSPF进程，而且进程之间相互隔离。一般情况下，当我们在做网络建设时，整个网络就是一个统一的路由选择域，如果选用OSPF作为路由协议，则所有的OSPF路由器使用一个OSPF进程即可。

展示了一个大型企业的网络拓扑，R1、R2、R3及R4是省公司的设备，SW1、SW2及往下是市公司的设备，R5是区县站点设备(实际上有多个区县站点，此处只显示了一个)。为了实现市公司与各区县站点的网络互通，我们在市公司所有设备，以及区县站点的所有路由器上都配置了OSPF并且进行了多区域的规划。由于整个企业数据网络的规模较大，要想打通整个网络的路由，使用一个OSPF域直接从区县站点往上拉到省公司，显然是不靠谱的，一来整个域太大，路由前缀数量太多，二来OSPF的多区域设计在面对这么大规模网络的时候显得还是有点力不从心，三来总公司并不希望看到分公司以及下面的子站点的路由明细，路由汇总势必是要考虑的，加之对流量的走向还有严格的要求，策略部署上如何考虑?因此为省公司网络规划了另外一个OSPF域，在省公司的边界设备R3、R4上创建两个OSPF进程，进程1面向总公司，进程2面向下面的市公司及区县站点。两个进程相互独立不互相干扰，而R3及R4又能够学习到省公司、分公司及各个区县站点的路由，两个OSPF域可以独立规划，域内Area的设计又变得更加宽松和灵活。

当然，省公司、总干以及地市公司是需要相互通信的，这时候由于省公司的网络属于OSPF进程1，而市分公司及区县站点的网络属于OSPF进程2，相互独立，为了把路由打通，就需要在R3和R4上执行OSPF进程之间的路由相互重发布。一旦把R3、R4设计为路由重发布的执行点，他俩瞬间就变得非常重要和牛逼了，因为在重发布的过程中，可以执行路由策略、可以做路由过滤，更可以做路由汇总，网络的.设计和规划就变得非常有弹性了。

下面再来看多进程OSPF的另一个例子：

网络中，存在两个不同的业务。生产及办公，两个业务各有自己的服务器网络，两台Router分别连接着这两个业务的服务器网络。而终端用户则连接在SW上，现在终端用户需要访问各自业务的服务器，那么SW当然是需要有相应的路由的。我们希望将生产及办公的业务进行隔离，但是这两个业务的终端用户又都是连接在SW上，如何隔离?很简单，在SW上创建两个OSPF进程，其中进程1用于生产业务，进程2用于办公业务。在OSPF进程1中，激活VLAN10及VLAN20对应的SVI，并激活与SC-Router对接的三层接口;在OSPF进程2中，激活VLAN30、40对应的SCI，并激活与BG-Router对接的三层接口，如此一来办公及生产服务器网段的路由通过这两个OSPF进程在SW上进行了隔离。

这的确是一种好方法，但是虽然OSPF进程是隔离的，SW的全局路由表中却拥有者生产及办公两个业务的路由，也就是说两个业务的路由实际上在SW这个点上是打通的，显然不够安全，如果有人从办公网络登到办公终端，然后再从办公终端跳转，去访问生产服务器就麻烦了。所以，我们又引入了另一个概念——VRF(Virtual Routing Forwarding，虚拟路由转发)，所谓的VRF你可以理解为虚拟设备，通过在SW上创建VRF实例，并且将生产的OSPF进程关联到一个VRF实例中，从而彻底将生产路由与办公路由进行隔离(办公路由及业务跑在根设备上，生产路由及业务跑在VRF实例上，两者完全隔离，可以想象为两台SW)。

‘贰’ 多线程与多进程的命令应该写在什么位置

进程（Process）是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。

线程，有时被称为轻量级进程(Lightweight Process，LWP），是程序执行流的最小单元。一个标准的线程由线程ID，当前指令指针(PC），寄存器集合和堆栈组成。另外，线程是进程中的一个实体，是被系统独立调度和分派的基本单位，线程自己不拥有系统资源，只拥有一点儿在运行中必不可少的资源，但它可与同属一个进程的其它线程共享进程所拥有的全部资源。一个线程可以创建和撤消另一个线程，同一进程中的多个线程之间可以并发执行。

‘叁’ 如何使用 pm2 部署 express 多进程

使用命令：
pm2 startOrReload process.json --env prod

在process.json中配置集群 多少个核心跑你的服务器

‘肆’ windows批处理 如何同时运行多个进程

部分exe在命令行启动的话会占用命令提示符（不清楚这之间的关系）
如果你这3个不是一定要按顺序执行的话可以考虑调换顺序
如果要按顺序执行的话可以考虑把start命令的内容分别放到3个批处理里面，然后由一个批处理分别执行这3个批处理达到效果
比如：

——以下为“批处理0.bat”的内容——
@echo off

start 批处理1.bat
start 批处理2.bat
start 批处理3.bat
————结束————
——以下为“批处理1.bat”的内容——

————结束————
……类推……

不过建议你试试这样的命令格式：
cd "C:\redis-2.0.2"
start "redis" redis-server.exe redis.config
可以合并为一条：
start "redis" "C:\redis-2.0.2\redis-server.exe" redis.config

‘伍’ 如何使用gdb调试多进程

在2.5.60版Linux内核及以后，GDB对使用fork/vfork创建子进程的程序提供了follow-fork-mode选项来支持多进程调试。

follow-fork-mode的用法为：

set follow-fork-mode [parent|child]

parent: fork之后继续调试父进程，子进程不受影响。

child: fork之后调试子进程，父进程不受影响。

因此如果需要调试子进程，在启动gdb后：

(gdb) set follow-fork-mode child并在子进程代码设置断点。

此外还有detach-on-fork参数，指示GDB在fork之后是否断开（detach）某个进程的调试，或者都交由GDB控制：

set detach-on-fork [on|off]

on: 断开调试follow-fork-mode指定的进程。

off: gdb将控制父进程和子进程。follow-fork-mode指定的进程将被调试，另一个进程置于暂停（suspended）状态。

注意，最好使用GDB 6.6或以上版本，如果你使用的是GDB6.4，就只有follow-fork-mode模式。

follow-fork-mode/detach-on-fork的使用还是比较简单的，但由于其系统内核/gdb版本限制，我们只能在符合要求的系统上才能使用。而且，由于follow-fork-mode的调试必然是从父进程开始的，对于fork多次，以至于出现孙进程或曾孙进程的系统，例如上图3进程系统，调试起来并不方便。

Attach子进程

众所周知，GDB有附着（attach）到正在运行的进程的功能，即attach <pid>命令。因此我们可以利用该命令attach到子进程然后进行调试。

例如我们要调试某个进程RIM_Oracle_Agent.9i，首先得到该进程的pid

[root@tivf09 tianq]# ps -ef|grep RIM_Oracle_Agent.9i

nobody 6722 6721 0 05:57 ? 00:00:00 RIM_Oracle_Agent.9i

root 7541 27816 0 06:10 pts/3 00:00:00 grep -i rim_oracle_agent.9i通过pstree可以看到，这是一个三进程系统，oserv是RIM_Oracle_prog的父进程，RIM_Oracle_prog又是RIM_Oracle_Agent.9i的父进程。

[root@tivf09 root]# pstree -H 6722通过 pstree 察看进程

现在就可以调试了。一个新的问题是，子进程一直在运行，attach上去后都不知道运行到哪里了。有没有办法解决呢？

一个办法是，在要调试的子进程初始代码中，比如main函数开始处，加入一段特殊代码，使子进程在某个条件成立时便循环睡眠等待，attach到进程后在该代码段后设上断点，再把成立的条件取消，使代码可以继续执行下去。

至于这段代码所采用的条件，看你的偏好了。比如我们可以检查一个指定的环境变量的值，或者检查一个特定的文件存不存在。以文件为例，其形式可以如下：

void debug_wait(char *tag_file)

{

while(1)

{

if (tag_file存在)

睡眠一段时间;

else

break;

}

}当attach到进程后，在该段代码之后设上断点，再把该文件删除就OK了。当然你也可以采用其他的条件或形式，只要这个条件可以设置/检测即可。

Attach进程方法还是很方便的，它能够应付各种各样复杂的进程系统，比如孙子/曾孙进程，比如守护进程（daemon process），唯一需要的就是加入一小段代码。

GDB wrapper

很多时候，父进程 fork 出子进程，子进程会紧接着调用 exec族函数来执行新的代码。对于这种情况，我们也可以使用gdb wrapper 方法。它的优点是不用添加额外代码。

其基本原理是以gdb调用待执行代码作为一个新的整体来被exec函数执行，使得待执行代码始终处于gdb的控制中，这样我们自然能够调试该子进程代码。

还是上面那个例子，RIM_Oracle_prog fork出子进程后将紧接着执行RIM_Oracle_Agent.9i的二进制代码文件。我们将该文件重命名为RIM_Oracle_Agent.9i.binary，并新建一个名为RIM_Oracle_Agent.9i的shell脚本文件，其内容如下：

[root@tivf09 bin]# mv RIM_Oracle_Agent.9i RIM_Oracle_Agent.9i.binary

[root@tivf09 bin]# cat RIM_Oracle_Agent.9i

#!/bin/sh

gdb RIM_Oracle_Agent.binary当fork的子进程执行名为RIM_Oracle_Agent.9i的文件时，gdb会被首先启动，使得要调试的代码处于gdb控制之下。

‘陆’ 如何理解“多进程”,“多任务”的概念

多进程可以理解为运行多个程序 例如WINDOWS就能管理多个进程,在任务管理器里面能看到
多任务可以理解我同时执行多个任务,但实际是不是同完执行多个任务,而是CPU处理速度太快了让我们感觉是同时执行多个任务。
多线程可以理解为一个程序同时执行多段代码，在同一个程序内同时操多个功能；例如你点了应用按钮之后再去点其它的按钮，两个命令同时运行，如个是单线程的话点了只能等这个操作完成之后，才能进行其它的操作，如果同时操作会出现末响应的的提示，他和多任务非常的相似。

‘柒’ 如何运行多进程Docker容器

运行多进程Docker容器的方法如下：

1、使用Shell脚本依次启动Kubernetes的各个组件即可。

以下为start-kubernetes.sh

‘捌’ TCP和UDP中怎么加入多线程、多进程

1、UDP
UDP（User Datagram Protocol，用户数据报协议）不提供复杂的控制机制，利用IP提供面向无连接的通信服务。它是将应用程序发来的数据在收到的那一刻，立即按照原样发送到网络上的一种机制。
UDP的特点
UDP是一个非连接的协议，传输数据之前，源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段；由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息；UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小；UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表（有许多参数）；UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。
2、TCP
TCP（Transmission Control Protocol，传输控制协议）是面向连接的协议，也可是说是对“传输、发送、通信”进行“控制”的协议。
TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。且TCP实现了数据传输时各种控制功能，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。
TCP与UDP的区别
TCP面向连接（如打电话要先拨号建立连接）。UDP是无连接的，即发送数据之前不需要建立连接；TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。UDP尽最大努力交付，即不保证可靠交付；TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流。UDP是面向报文的；每一条TCP连接只能是点到点的。UDP支持一对一、一对多、多对一和多对多的交互通信；对系统资源的要求TCP较多，UDP少。TCP首部开销20字节，UDP的首部开销小，只有8个字节；TCP的逻辑通信信道是全双工的可靠信道。UDP则是不可靠信道。
TCP建立连接的3次握手过程
主机A通过向主机B发送一个含有同步序列号的标志位的数据段给主机B，向主机B请求建立连接，通过这个数据段，主机A告诉主机B两件事：我想要和你通信；你可以用哪个序列号作为起始数据段来回应我；主机B收到主机A的请求后，用一个带有确认应答（ACK）和同步序列号（SYN）标志位的数据段响应主机A，也告诉主机A两件事：我已经收到你的请求了，你可以传输数据了；你要用哪个序列号作为起始数据段来回应我；主机A收到这个数据段后，再发送一个确认应答，确认已收到主机B的数据段：“我已收到回复，我现在要开始传输实际数据了”。
这样3次握手就完成了，主机A和主机B就可以传输数据了。
TCP断开连接的4次确认
当主机A完成数据传输后，将控制位FIN置1，提出停止TCP连接的请求；主机B收到FIN后对其作出响应，确认这一方向上的TCP连接将关闭，将ACK置1；由B端再提出反方向的关闭请求，将FIN置1；主机A对主机B的请求进行确认，将ACK置1，双方向的关闭结束。
由TCP的3次握手和4次断开确认可以看出，TCP使用面向连接的通信方式，大大提高了数据通信的可靠性，使发送数据端和接收端在数据正式传输前就有了交互，为数据正式传输打下了可靠的基础。
我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。

‘玖’ 如何使用gdb调试多进程

在大多数系统，gdb对使用fork创建的进程没有进行特别的支持。当父进程使用fork创建子进程，gdb仍然只会调试父进程，而子进程没有得到控制和调试。这个时候，如果你在子进程执行到的代码中设置了断点，那么当子进程执行到这个断点的时候，会产生一个SIGTRAP的信号，如果没有对此信号进行捕捉处理，就会按默认的处理方式处理——终止进程。
当然，你可以使用时间延迟的方法，在子进程fork出来之后，使用Sleep函数等待一段时间再运行，在这段时间中你使用ps找到该进程，然后使用Attach方法把该进程附加到gdb中，从而达到可以调试子进程的目的。
在一部分系统中(我使用的是基于2.6内核的CentOS，支持follow-fork和detach-on-fork模式)，比如HP-UX11.x之后的版本，Linux2.5.60之后的版本，可以使用以下的方法来达到方便的进行多进程调试功能。
默认情况下，父进程fork一个子进程，gdb只会继续调试父进程而不会管子进程的运行。
如果你想跟踪子进程进行调试，可以使用set follow-fork-mode mode来设置fork跟随模式。
set follow-fork-mode 所带的mode参数可以是以下的一种：
parent
gdb只跟踪父进程，不跟踪子进程，这是默认的模式。
child
gdb在子进程产生以后只跟踪子进程，放弃对父进程的跟踪。
进入gdb以后，我们可以使用show follow-fork-mode来查看目前的跟踪模式。

可以看到目前使用的模式是parent。

然而，有的时候，我们想同时调试父进程和子进程，以上的方法就不能满足了。Linux提供了set detach-on-fork mode命令来供我们使用。其使用的mode可以是以下的一种：
on
只调试父进程或子进程的其中一个(根据follow-fork-mode来决定)，这是默认的模式。
off
父子进程都在gdb的控制之下，其中一个进程正常调试(根据follow-fork-mode来决定)
另一个进程会被设置为暂停状态。
同样，show detach-on-fork显示了目前是的detach-on-fork模式，如上图。

以上是调试fork产生子进程的情况，但是如果子进程使用exec系统函数而装载了新程序执行呢？——我们使用set follow-exec-mode mode提供的模式来跟踪这个exec装载的程序。mode可以是以下的一种：
new 当发生exec的时候，如果这个选项是new，则新建一个inferior给执行起来的子进程，而父进程的inferior仍然保留，当前保留的inferior的程序状态是没有执行。
same 当发生exec的时候，如果这个选项是same(默认值)，因为父进程已经退出，所以自动在执行exec的inferior上控制子进程。

我们可以使用apue里面第8章的例子代码来做测试：

#include "apue.h"

intglob = 6;/* external variable in initialized data */
charbuf[] = "a write to stdout\n";

int
main(void)
{
intvar;/* automatic variable on the stack */
pid_tpid;

var = 88;
if (write(STDOUT_FILENO, buf, sizeof(buf)-1) != sizeof(buf)-1)
err_sys("write error");
printf("before fork\n");/* we don't flush stdout */

if ((pid = fork()) < 0) {
err_sys("fork error");
} else if (pid == 0) {/* child */
glob++;/* modify variables */
var++;
} else {
sleep(2);/* parent */
}

printf("pid = %d, glob = %d, var = %d\n", getpid(), glob, var);
exit(0);
}