CN105337755A - 主从架构服务器及其处理业务的方法和处理业务的系统 - Google Patents

Abstract

本申请公开了一种主从架构服务器及其处理业务的方法和处理业务的系统，其中，主从架构服务器处理业务的方法包括：主从架构服务器的父进程解析并加载配置文件，配置文件中包含多个端口及与每个端口一一对应的进程编号；父进程为创建的子进程分配不同的进程编号；子进程根据自己的进程编号从父进程继承对应的资源，资源包括端口；以及子进程监听对应的端口以接收来自客户端的业务请求，并对业务请求进行处理，然后向客户端返回业务应答。本申请实施例，通过让不同的子进程分别监听不同端口的读写事件，可以保证一个端口下的业务请求完全交由一个子进程处理，子进程间完全独立不再相互竞争业务请求，从而避免发生惊群现象。

Description

主从架构服务器及其处理业务的方法和处理业务的系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种主从架构服务器及其处理业务的方法和处理业务的系统。

背景技术

目前，很多服务器都有多核中央处理单元(CPU)，并支持对称多处理(SymmetricMulti-Processing，SMP)架构。为充分利用CPU资源，很多高性能服务器均采用主从架构，主从架构的示意图如图1所示，先由父进程解析并加载配置文件、创建套接字并绑定监听端口，然后创建出多个子进程，每个子进程分别继承父进程的资源。子进程的个数和CPU的核数相同，为避免子进程在CPU之间迁移，还可以将子进程和特定的CPU绑定。

在主从架构下，主进程又可以称为监控进程，子进程又可以称为工作进程。每个子进程的作用完全相同，当客户端发起业务请求时，子进程通过竞争的方式来获取该业务请求的处理权。

以上主从架构存在以下几个问题：

(1)多个工作进程同时监听同一个端口，当有请求发往某个端口时，多个工作进程会去竞争该请求的处理权，而最终只有一个进程才能竞争成功，这就引起惊群现象；

(2)在真实的生产环境，尤其是在虚拟机环境下，有些进程竞争请求成功的概率高于其他进程，造成部分进程接入大量请求而过度繁忙，其他进程得不到请求而过度空闲，进程之间的负载不平衡，不能充分发挥SMP架构的优势；

(3)当工作进程存在状态时，即一些请求只有被特定的工作进程接收才能被正确处理，在这种情况下，如果这些请求被其他进程接收，接收请求的进程只能向其他进程寻求帮助，这样会增加通信成本。例如，每个工作进程单独维护自己的缓存，缓存中存放了用户的个人信息，如果A用户的个人信息在B进程的缓存中，当A发起的请求被C进程接收，由于C进程没有A用户的个人信息，所以无法直接给A用户一个正确的应答。此时只能通过进程通信的方式向B进程索取，这个行为既增加了进程B和C的执行复杂度，也增加了对A请求的响应时间；

(4)工作进程的配置统一从父进程继承下来，配置都是一样的，无法微调；

(5)为解决惊群现象、负载不平衡和不必要的进程间通信等问题，不可避免地引入进程锁，多个进程通过进程锁解决进程间的同步和互斥问题，但进程锁的引入同样会增加进程的执行复杂度、降低服务器的性能。

发明内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。为此，本申请的一个目的在于提出一种具有避免引起惊群现象的主从架构服务器及其处理业务的方法和处理业务的系统。

根据本申请实施例的主从架构服务器处理业务的方法，包括：主从架构服务器的父进程解析并加载配置文件，配置文件中包含多个端口及与每个端口一一对应的进程编号；父进程为创建的子进程分配不同的进程编号；子进程根据自己的进程编号从父进程继承对应的资源，资源包括端口；以及子进程监听对应的端口以接收来自客户端的业务请求，并对业务请求进行处理，然后向客户端返回业务应答。

根据本申请实施例的主从架构服务器处理业务的方法，通过让不同的子进程分别监听不同端口的读写事件，可以保证一个端口下的业务请求完全交由一个子进程处理，子进程间完全独立不再相互竞争业务请求，从而避免发生惊群现象。

根据本申请实施例的主从架构服务器，包括：解析加载模块，用于主从架构服务器的父进程解析并加载配置文件，配置文件中包含多个端口及与每个端口一一对应的进程编号；分配模块，用于父进程为创建的子进程分配不同的进程编号；继承模块，用于子进程根据自己的进程编号从父进程继承对应的资源，资源包括端口；以及处理模块，用于子进程监听对应的端口以接收来自客户端的业务请求，并对业务请求进行处理，然后向客户端返回业务应答。

根据本申请实施例的主从架构服务器，父进程通过解析加载模块41解析并加载配置文件，通过分配模块为创建的子进程分配不同的进程编号，子进程通过继承模块从父进程继承对应的资源，通过处理模块监听对应的端口以接收来自客户端的业务请求，并对上述业务请求进行处理，然后向上述客户端返回业务应答，使得多个子进程监听自己的端口，避免了惊群现象的发生，提高了业务处理效率。

根据本申请实施例的处理业务的系统，包括上述主从架构服务器和客户端，其中：客户端，用于根据获取到的地址信息，向对应的主从架构服务器发送业务请求。

根据本申请实施例的处理业务的系统，通过让不同的子进程分别监听不同端口的读写事件，可以保证一个端口下的业务请求完全交由一个子进程处理，子进程间完全独立不再相互竞争业务请求，从而避免发生惊群现象。

附图说明

图1是传统主从架构服务器中父子进程的关系示意图。

图2是根据本申请一个实施例的主从架构服务器处理业务的方法的流程图。

图3是根据本申请一个实施例的实现进程间负载均衡的信令流程图。

图4是根据本申请一个实施例的主从架构服务器的结构示意图。

图5是根据本申请一个实施例的处理业务的系统的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的主从架构服务器处理业务的方法、主从架构服务器和处理业务的系统。

图2是根据本申请一个实施例的主从架构服务器处理业务的方法的流程图，其中，主从架构服务器包括一个父进程和至少一个子进程，父进程监控子进程的运行状态，子进程负责处理实际业务，通过开启多个子进程可以实现对SMP架构下多核CPU的充分利用。

如图2所示，该主从架构服务器处理业务的方法包括：

S201，主从架构服务器的父进程解析并加载配置文件，配置文件中包含多个端口及与每个端口一一对应的进程编号。

在该实施例中，配置文件可以包括很多配置信息，例如可以包括一一对应的端口及进程编号，如表1所示。

表1端口及进程编号的对应关系

进程编号	端口
		1	4
2	3
		3	2
4	1

另外，由于各端口的请求流量不尽相同，或者各子进程的状态存在差异性，导致各子进程间的配置参数需要微调，因此，配置文件中还可以包括其他配置参数，且该配置参数具有多个值，每个值与一个进程编号对应，即每个子进程使用和自己进程编号匹配的配置参数值。

例如，同时开启了80和8080端口以提供两种不同的业务，假定向80端口发起的业务请求数会超过向8080端口发起的业务请求数，可以将为80端口提供服务的子进程的缓存空间设置得更大。为了实现这个功能，也可以为“缓存空间”这个配置参数指定对应的进程编号，即子进程只采用和自己的进程编号匹配的配置参数值。

由此可见，通过有针对性地设置配置参数，可以实现对不同子进程的适配。

S202，父进程为创建的子进程分配不同的进程编号。

在该实施例中，父进程维护了一个数组和一个全局变量，数组的长度等于子进程的个数，全局变量的初始值为1。父进程每新建一个子进程，就从数组中顺次取出第一个未被使用的表项，将该表项的进程号字段设置为新建子进程的进程号，将该表项的进程编号字段设置为全局变量的值。子进程创建成功后，父进程将全局变量的值加1。每个子进程继承了父进程的全局变量的当前值，并将其作为自己的进程编号。由于全局变量在每次创建子进程之前都不一样，所以每个子进程继承下来的全局变量的值也不一样，当然，每个子进程的进程编号也不一样。又因为全局变量是逐次加1的，所以进程编号也是逐次加1的。

需要说明的是，当有子进程退出时，主进程捕获到操作系统发送过来的子进程退出信号，根据子进程退出信号中包含的进程号找到数组中的对应表项，并根据对应表项获取到退出子进程的进程编号，然后新建子进程，新建的子进程继承了退出子进程的进程编号。这样，既保证了主从架构中子进程的个数保持不变，又保证每个子进程的进程编号是逐次加1的。

由此可见，当有工作进程退出时，新建的子进程和退出子进程采用相同的进程编号，监听的端口也相同，即新建的子进程接管了退出子进程对来自特定端口的请求的处理权，这样可以保证服务器对子进程意外退出的良好应对，从而使服务器可以作为整体对外提供稳定的服务。

S203，子进程根据自己的进程编号从父进程继承对应的资源，资源包括端口。

父进程在加载配置文件后可以获得很多资源，而子进程可以继承父进程的资源，例如端口等。

具体地，假定配置文件中包含表1的内容，则1号子进程可以使用端口4接收业务请求,2号子进程可以使用端口3接收业务请求，等等。

S204，子进程监听对应的端口以接收来自客户端的业务请求，并对业务请求进行处理，然后向客户端返回业务应答。

在该实施例中，主进程可以创建多个套接字，每个套接字绑定一个端口，然后创建多个子进程，每个子进程只将自己的进程编号和自身匹配的套接字的读写事件放入自己的监听队列中，这样当有来自客户端的业务请求时，由于只有一个子进程将该端口的读写事件加入自身的监听队列中，所以只有一个子进程可以感知到该业务请求。

由此可见，通过让不同的子进程分别监听不同端口的读写事件，可以保证一个端口下的业务请求完全交由一个子进程处理，子进程间完全独立不再相互竞争业务请求，从而避免发生惊群现象。

为了保证进程间的负载均衡，在该实施例中，在客户端向主从架构服务器发起业务请求之前，可以先从前端的调度服务器获取主从架构服务器的地址信息，例如可以是(IP,端口)二元组。调度服务器根据预设的比例返回各个主从架构服务器的地址，客户端再向该地址发起请求，只要调度服务器能在整体上保证返回的每个地址的概率符合权重，就可以保证向每台服务器的每个端口发起的请求数符合权重，进而保证服务器的各进程的负载均衡。

具体地，客户端、调度服务器和主从架构服务器实现进程间负载均衡的过程如图3所示，该过程包括：

S301，客户端向调度服务器请求获取地址列表。

S302，调度服务器根据特定的算法选择多个主从架构服务器。

S303，调度服务器向客户端返回选择的主从架构服务器的地址列表，每个表项包含了主从架构服务器的IP和端口。

在该实施例中，调度服务器通过控制返回的IP和端口(PORT)的组合的个数，既可以实现不同服务器之间的流量分配，也可以实现同一服务器下不同端口的流量分配。例如，调度服务器给出的应答包含IP1的应答数是包含IP2的N倍，则IP1这台服务器的流量是IP2的N倍；若包含IP1的应答中包含PORT1的应答数是PORT2的M倍，则监听PORT1的子进程承接的流量是监听PORT2的子进程的M倍。于是，子进程之间的负载均衡由原先的主从架构服务器的自身的保障机制转移到了前端的调度服务器，避免了主从架构服务器为实现负载均衡而引入进程锁等进程间通信带来的开销。

S304，客户端对获取的地址列表进行解析，并选择列表中的第一台作为请求对象。

S305，客户端向作为请求对象的主从架构服务器发起请求，若请求超时，则选择地址列表中的下一台作为请求对象。

S306，主从架构服务器处理业务请求。

主从架构服务器处理业务请求的过程可参见S201-204，通过让不同的子进程分别监听不同端口的读写事件，使得同一个端口下的业务请求可以完全交由同一个子进程处理。

S307，主从架构服务器向客户端返回业务应答。

在该实施例中，客户端将地址列表缓存在本地，之后将直接向列表内的服务器发起请求。当列表内所有服务器都无法连接或缓存时间超出有效时间，则缓存失效，客户端将重复S301-S304过程，重新获得可用的地址列表。

由此可见，主从架构服务器通过和调度服务器相配合，可以将业务请求引导到不同的端口下，使得在无锁的情况下可以实现子进程间的负载均衡，极大地提升了主从架构服务器的整体性能。

另外，如果子进程存在状态，例如存放了用户的个人信息，则该用户的请求只能被匹配的子进程接收才能正确处理。在这种情况下，调度服务器返回的地址列表的有效时间可以被设置地很长或永久有效，以保证对应客户端的请求始终落在同一台服务器的同一个端口下，并交由同一个子进程来处理。调度服务器在选择主从架构服务器时可以通过算法保证向同一个用户返回的地址列表始终是一致的，这样即使客户端的地址列表缓存丢失或失效仍可保证该客户端的请求被同一子进程处理。

进一步地，在没有调度服务器的情况下，客户端也可以记录上次业务请求发往的端口，以在后续有业务请求时向同一端口发起请求，从而可以将请求交由同一子进程处理。

由此可见，对于有状态的子进程而言，特定的请求只能由特定的子进程才能正确地处理。在该实施例中，客户端被分配一个服务器地址之后，在该地址的有效期内一直向该地址发起请求，这样就保证了该客户端的请求一直由某个子进程来处理。前端调度服务器还可以根据请求参数等信息为一些业务请求返回特定的端口，客户端也可以有意识地选择服务器的端口，将指定请求交由指定的子进程来处理，从而避免进程协作带来的额外开销。

综上，上述主从架构服务器处理业务的方法实施例，避免了惊群现象并解决了负载均衡问题，保证在有状态时请求的有序接收，子进程之间彼此独立不需要任何协作，不需要进程锁等用来保证进程同步和互斥的工具，在简化服务器架构的同时提升了服务器的性能。由于本申请实施例并没有在本质上改变主从架构，所以只需微调配置文件就可以正常运行，实现简单。

为了实现上述实施例，本申请还提出一种主从架构服务器。

图4是根据本申请一个实施例的主从架构服务器的结构示意图，如图4所示，该主从架构服务器包括：解析加载模块41、分配模块42、继承模块43和处理模块44，其中：

解析加载模块41用于上述主从架构服务器的父进程解析并加载配置文件，上述配置文件中包含多个端口及与每个端口一一对应的进程编号；分配模块42用于上述父进程为创建的子进程分配不同的进程编号；继承模块43用于上述子进程根据自己的进程编号从上述父进程继承对应的资源，上述资源包括端口；处理模块44用于上述子进程监听对应的端口以接收来自客户端的业务请求，并对上述业务请求进行处理，然后向上述客户端返回业务应答。

具体地，上述分配模块42可以包括维护单元421和设置单元422，其中：维护单元421用于上述父进程维护一个数组和一个全局变量，其中，上述数组中的每个表项均包含进程号和进程编号两个字段，上述进程编号为上述全局变量的值，上述全局变量的初始值为一；设置单元422用于上述父进程为创建的每个子进程依次从上述数组中取出第一个未被使用的表项，并根据上述表项的内容为当前子进程设置进程号和进程编号，同时将上述全局变量做加一处理。

另外，该主从架构服务器还可以包括：监控模块45，该监控模块45用于在上述父进程根据上述表项的内容为当前子进程设置进程号和进程编号之后，监控已创建的上述子进程的存活状态，当监控到子进程退出信号时，根据上述子进程退出信号获取到退出子进程的进程编号，创建新的子进程，并将上述退出子进程的进程编号作为上述新的子进程的进程编号。这样，新建的子进程接管了退出子进程对来自特定端口的请求的处理权，可以保证服务器对子进程意外退出的良好应对，从而使服务器可以作为整体对外提供稳定的服务。

进一步地，该主从架构服务器还可以包括：建立模块46，该建立模块46用于上述父进程创建多个套接字，并将上述套接字与上述端口建立一对一绑定关系；上述处理模块44可以具体用于：子进程将自己的进程编号和绑定的套接字的读写事件放入自己的监听队列中，并通过监听队列监听对应的端口。通过让不同的子进程分别监听不同端口的读写事件，可以保证一个端口下的业务请求完全交由一个子进程处理，子进程间完全独立不再相互竞争业务请求，从而避免发生惊群现象。

其中，配置文件中可以包含很多配置信息，例如可以包含具有多个参数值的配置参数，上述参数值与上述进程编号一一对应，这样可以微调子进程的配置。

上述主从架构服务器实施例，父进程通过解析加载模块41解析并加载配置文件，通过分配模块为创建的子进程分配不同的进程编号，子进程通过继承模块从父进程继承对应的资源，通过处理模块监听对应的端口以接收来自客户端的业务请求，并对上述业务请求进行处理，然后向上述客户端返回业务应答，使得多个子进程监听自己的端口，避免了惊群现象的发生，提高了业务处理效率。

为了实现上述实施例，本申请还提出一种处理业务的系统。

图5是根据本申请一个实施例的处理业务的系统的结构示意图，如图5所示，该系统包括图4所示的主从架构服务器51和客户端52，客户端52用于根据获取到的地址信息，向对应的主从架构服务器发送业务请求。

为了保证进程间的负载均衡，该系统还可以包括：调度服务器53，调度服务器53用于接收上述客户端52发送的地址获取请求，并基于预设的比例获取地址列表，然后向上述客户52端返回上述地址列表。具体的实现过程可参见图3，此处不赘述。

由此可见，主从架构服务器通过和调度服务器相配合，可以将业务请求引导到不同的端口下，使得在无锁的情况下可以实现子进程间的负载均衡，极大地提升了主从架构服务器的整体性能。

其中，上述客户端52通过对接收到的地址列表进行解析以获取到地址信息。

另外，上述客户端52还可以在本地缓存地址列表，并设置上述地址列表的有效时间。之后可以将直接向地址列表内的服务器发起请求，若无法与上述地址列表中的地址信息对应的所有服务器建立连接或缓存时间超出上述有效时间，则向上述调度服务器发送上述地址获取请求，以重新获得可用的地址列表。

进一步地，如果子进程存在状态，例如存放了用户的个人信息，则该用户的请求只能被匹配的子进程接收才能正确处理。在这种情况下，调度服务器返回的地址列表的有效时间可以被设置地很长或永久有效，以保证对应客户端的请求始终落在同一台服务器的同一个端口下，并交由同一个子进程来处理。调度服务器在选择主从架构服务器时可以通过算法保证向同一个用户返回的地址列表始终是一致的，这样即使客户端的地址列表缓存丢失或失效仍可保证该客户端的请求被同一子进程处理。

另外，在没有调度服务器的情况下，客户端也可以记录上次业务请求发往的端口，以在后续有业务请求时向同一端口发起请求，从而可以将请求交由同一子进程处理。为了实现该功能，客户端52还可以用于：判断当前业务请求是否属于预设类型，若属于预设类型，则记录获取到的与上述当前业务请求对应的地址信息，以用于根据记录的地址信息发送上述当前业务请求。此处的预设类型的业务请求是指与有状态的进程对应的业务请求。

上述处理业务的系统实施例，避免了惊群现象并解决了负载均衡问题，保证在有状态时请求的有序接收，子进程之间彼此独立不需要任何协作，不需要进程锁等用来保证进程同步和互斥的工具，在简化服务器架构的同时提升了服务器的性能。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (18)

1.一种主从架构服务器处理业务的方法，其特征在于，包括：

所述主从架构服务器的父进程解析并加载配置文件，所述配置文件中包含多个端口及与每个端口一一对应的进程编号；

所述父进程为创建的子进程分配不同的进程编号；

所述子进程根据自己的进程编号从所述父进程继承对应的资源，所述资源包括端口；以及

所述子进程监听对应的端口以接收来自客户端的业务请求，并对所述业务请求进行处理，然后向所述客户端返回业务应答。

2.根据权利要求1所述的方法，其特征在于，所述业务请求为所述客户端在接收调度服务器返回的地址列表后发送的，其中，所述地址列表为所述调度服务器在接收所述客户端发送的地址获取请求后基于预设的比例获取的，所述地址列表中包含IP地址和端口信息。

3.根据权利要求1或2所述的方法，其特征在于，所述父进程为创建的子进程分配不同的进程编号，包括：

所述父进程维护一个数组和一个全局变量，其中，所述数组中的每个表项均包含进程号和进程编号两个字段，所述进程编号为所述全局变量的值，所述全局变量的初始值为一；

所述父进程为创建的每个子进程依次从所述数组中取出第一个未被使用的表项，并根据所述表项的内容为当前子进程设置进程号和进程编号，同时将所述全局变量做加一处理。

4.根据权利要求3所述的方法，其特征在于，在所述父进程根据所述表项的内容为当前子进程设置进程号和进程编号之后，还包括：

所述父进程监控已创建的所述子进程的存活状态，当监控到子进程退出信号时，根据所述子进程退出信号获取到退出子进程的进程编号，创建新的子进程，并将所述退出子进程的进程编号作为所述新的子进程的进程编号。

5.根据权利要求3所述的方法，其特征在于，所述方法还包括：

所述父进程创建多个套接字，并将所述套接字与所述端口建立一对一绑定关系；

所述子进程监听对应的端口，包括：

所述子进程将自己的进程编号和绑定的套接字的读写事件放入自己的监听队列中，并通过所述监听队列监听对应的端口。

6.根据权利要求2所述的方法，其特征在于，所述地址列表中还包含有效时间信息，以保证向同一客户端返回相同的地址列表。

7.根据权利要求2所述的方法，其特征在于，所述配置文件中还包含配置参数，所述配置参数具有多个参数值，其中，所述参数值与所述进程编号一一对应。

8.一种主从架构服务器，其特征在于，包括：

解析加载模块，用于所述主从架构服务器的父进程解析并加载配置文件，所述配置文件中包含多个端口及与每个端口一一对应的进程编号；

分配模块，用于所述父进程为创建的子进程分配不同的进程编号；

继承模块，用于所述子进程根据自己的进程编号从所述父进程继承对应的资源，所述资源包括端口；以及

处理模块，用于所述子进程监听对应的端口以接收来自客户端的业务请求，并对所述业务请求进行处理，然后向所述客户端返回业务应答。

9.根据权利要求8所述的主从架构服务器，其特征在于，所述分配模块，包括：

维护单元，用于所述父进程维护一个数组和一个全局变量，其中，所述数组中的每个表项均包含进程号和进程编号两个字段，所述进程编号为所述全局变量的值，所述全局变量的初始值为一；

设置单元，用于所述父进程为创建的每个子进程依次从所述数组中取出第一个未被使用的表项，并根据所述表项的内容为当前子进程设置进程号和进程编号，同时将所述全局变量做加一处理。

10.根据权利要求9所述的主从架构服务器，其特征在于，还包括：

监控模块，用于在所述父进程根据所述表项的内容为当前子进程设置进程号和进程编号之后，监控已创建的所述子进程的存活状态，当监控到子进程退出信号时，根据所述子进程退出信号获取到退出子进程的进程编号，创建新的子进程，并将所述退出子进程的进程编号作为所述新的子进程的进程编号。

11.根据权利要求9所述的主从架构服务器，其特征在于，所述主从架构服务器还包括：

建立模块，用于所述父进程创建多个套接字，并将所述套接字与所述端口建立一对一绑定关系；

所述处理模块，具体用于：所述子进程将自己的进程编号和绑定的套接字的读写事件放入自己的监听队列中，并通过所述监听队列监听对应的端口。

12.根据权利要求8所述的主从架构服务器，其特征在于，所述配置文件中还包含配置参数，所述配置参数具有多个参数值，其中，所述参数值与所述进程编号一一对应。

13.一种处理业务的系统，其特征在于，包括如权利要求8-13任一权利要求所述的主从架构服务器和客户端，其中：

所述客户端，用于根据获取到的地址信息，向对应的主从架构服务器发送业务请求。

14.根据权利要求13所述的系统，其特征在于，所述系统还包括：

调度服务器，用于接收所述客户端发送的地址获取请求，并基于预设的比例获取地址列表，然后向所述客户端返回所述地址列表。

15.根据权利要求14所述的系统，其特征在于，所述客户端，具体用于：对接收到的地址列表进行解析并获取到所述地址信息。

16.根据权利要求14所述的系统，其特征在于，所述客户端，还用于：在本地缓存所述地址列表，并设置所述地址列表的有效时间。

17.根据权利要求16所述的系统，其特征在于，所述客户端，还用于：若无法与所述地址列表中的地址信息对应的所有服务器建立连接或缓存时间超出所述有效时间，则向所述调度服务器发送所述地址获取请求。

18.根据权利要求15所述的系统，其特征在于，所述客户端，还用于：判断当前业务请求是否属于预设类型，若属于预设类型，则记录获取到的与所述当前业务请求对应的地址信息，以用于根据记录的地址信息发送所述当前业务请求。