CN113254278A - 一种用于处理互联网请求的方法和系统 - Google Patents

Abstract

本发明涉及一种用于处理互联网请求的系统和方法。本申请的系统包括处理模块和存储模块；其中，存储模块包括处理规则数据库和处理结果数据库；处理模块包括大于或等于3的奇数个处理节点，每个处理节点包括逻辑处理单元和本地存储单元，大于或等于3的奇数个处理节点中的一个处理节点为领导者节点，其他的所述处理节点为跟随者节点。本申请实施例能够在满足快速、正确、可靠和可处理复杂任务请求的前提下，使得系统架构简单化且无需依赖外部系统即可完成请求的处理。

Description

一种用于处理互联网请求的方法和系统

技术领域

本申请涉及计算机信息技术领域，具体而言，涉及一种用于处理互联网请求的方法和系统。

背景技术

互联网应用的业务场景需要IT系统应付大规模的请求。例如，在促销活动中的抢单、各种秒杀等互联网应用的业务场景中，需要IT系统满足以下四项要求：1）快速，即能快速处理请求；2）正确性，业务处理的逻辑须维持线性一致性，即处理结果像一次处理这些请求一样。3）可靠，即在系统发生异常时也能保证处理正确，并且能最大程度维持系统的可用性。4）可处理复杂任务请求，即，对于并非数量扣减的复杂业务场景，能快速处理复杂业务的请求。

因此，如何在满足快速、正确、可靠和可处理复杂任务请求的前提下，通过更为简化且不依赖于外部系统的系统架构完成复杂请求的处理，是亟待解决的技术问题。

发明内容

有鉴于此，本申请实施例提供了一种用于处理互联网请求的方法和系统，能够在满足快速、正确、可靠和可处理复杂任务请求的前提下，使得系统架构简单化且无需依赖外部系统即可完成请求的处理。

第一方面，本申请实施例提供了一种用于处理互联网请求的系统，所述系统包括处理模块和存储模块；其中，

所述存储模块，包括处理规则数据库和处理结果数据库；其中，所述处理规则数据库配置为存储业务逻辑规则，所述处理结果数据库配置为持久化存放所述处理模块的处理结果；

所述处理模块，包括大于或等于3的奇数个处理节点，每个所述处理节点包括逻辑处理单元和本地存储单元，所述大于或等于3的奇数个处理节点中的一个处理节点为领导者节点，其他的所述处理节点为跟随者节点；

所述本地存储单元，配置为对状态机更新日志进行持久化存储；

所述逻辑处理单元，配置为执行如下处理：在本处理节点为所述领导者节点时，收到来自互联网的请求后，按照所述处理规则数据库中的业务逻辑规则对所述请求进行业务逻辑处理，将相应的处理结果通过本处理节点内部维持的状态机表现并写入所述处理结果数据库，根据所述业务逻辑处理中状态机的变化形成状态机更新日志，将所述状态机更新日志持久化到本处理节点的所述本地存储单元并复制给每个所述跟随者节点；在本处理节点为所述跟随者节点时，接收来自所述领导者节点的所述状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的所述本地存储单元。

一些实施例中，所述本地存储单元为基于LSM-Tree结构的存储器。

一些实施例中，所述处理模块中的所有处理节点之间通过Raft协议保持一致。

一些实施例中，所述领导者节点和所述跟随者节点是通过Raft协议进行领导者选举而确定的。

一些实施例中，所述领导者节点的逻辑处理单元，还配置为在超过半数的所述处理节点发生宕机时，暂停接收复杂请求，待半数或半数以上的所述处理节点恢复后开始接收复杂请求。

一些实施例中，所述逻辑处理单元，还配置为：在本处理节点为所述跟随者节点时，本处理节点发生宕机再重启后，从所述领导者节点的本地存储单元获取所述领导者节点的状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的所述本地存储单元，以恢复本处理节点的状态机；在本处理节点为所述领导者节点时，发生宕机的处理节点的数量超过半数则停止接收和处理来自互联网的请求，发生宕机的处理节点的数量未超过半数则继续接收和处理来自互联网的请求。

一些实施例中，所述请求为复杂请求。

第一方面，本申请实施例提供了一种处理互联网请求的方法，通过上述系统实现，所述方法包括：

领导者节点收到来自互联网的请求后，按照来自处理规则数据库的业务逻辑规则对所述请求进行业务逻辑处理，将相应的处理结果通过本处理节点内部维持的状态机表现并写入处理结果数据库；

领导者节点根据所述业务逻辑处理中状态机的变化形成状态机更新日志，将所述状态机更新日志持久化到本地并复制给每个跟随者节点；

跟随者节点接收来自领导者节点的所述状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机，并持久化到本地。

一些实施例中，所述方法还包括：初始状态和/或领导者节点发生宕机后，所述系统中的所有处理节点之间通过Raft协议进行领导者选举，以选出所述领导者节点并确定所述跟随者节点。

一些实施例中，所述方法还包括：初始状态和/或跟随者节点发生宕机再重启后，跟随者节点向领导者节点获取领导者节点的状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机并持久化到本地，以恢复本处理节点的状态机。

一些实施例中，所述方法还包括：在所述系统中发生宕机的处理节点的数量超过半数时，所述领导者节点停止接收和处理来自互联网的请求；在所述系统中发生宕机的处理节点的数量未超过半数时，所述领导者节点继续接收并处理来自互联网的请求。

本申请实施例能够让业务处理逻辑在内存中处理，保证了处理的快速性，同时也可以很方便地处理复杂的业务逻辑。通过分布式的方案，集群中各个处理节点之间互为备份，降低了数据丢失的可能性，也提高了系统的可用性。并且，无需采用外部的组件，降低了系统架构复杂性，降低了实施难度，从而在满足快速、正确、可靠和可处理复杂任务请求的前提下，使得系统架构简单化且无需依赖外部系统即可完成请求的处理。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的用于处理互联网请求的系统的结构示意图。

图2为本申请实施例提供的用于处理互联网请求的方法的流程示意图。

图3为本申请实施例中提供的电子设备的结构示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

相关技术的复杂处理主要存在如下三种缺陷：

1. 直接在数据库上进行操作，即对请求处理中的各种逻辑判断、计算等操作均直接在数据库上进行。如果操作之间需要互斥，则通过数据库加锁的方式进行互斥处理。

2. 在Redis等内存数据库上进行操作，即将业务数据加载到Redis中，对业务逻辑判断、计算操作在Redis中的数据上进行。如果操作之间需要互斥，则在Redis上实现锁以进行互斥处理。

3. 使用能持久化数据的消息队列进行处理，即建立不会丢失数据的分布式的消息队列，请求先进入消息队列进行持久化，然后后端代码通过读取消息队列中的处理请求，进行依次处理。

上述三种方式，复杂度高，导致处理复杂请求的系统架构复杂度高，并且需依赖外部系统才可完成。

鉴于此，本申请实施例提供了如下的用于处理互联网请求的系统和方法，其能够有效简化请求处理的流程，系统架构简单且无需依赖外部系统。

需要说明的是，本申请实施例所述的“复杂请求”是指大规模的请求、复杂任务请求或者复杂业务请求。例如，复杂请求可以是但不限于互联网应用中促销活动中诸如抢单、秒杀等复杂业务的交易请求。

图1示出了本申请实施例提供的用于处理互联网请求的系统100的结构示意图。参见图1所示，该系统100可以包括：处理模块110和存储模块120。

存储模块120，包括处理规则数据库121和处理结果数据库122；其中，处理规则数据库121配置为存储业务逻辑规则，处理结果数据库122配置为持久化存放处理模块110的处理结果。如此，可以将业务逻辑规则和处理结果进行分离存储，处理结果数据库122中仅需要存储处理结果，极大地减少了数据库的读写量，能大大提高系统100的整体吞吐量。

一些实施例中，存储模块120是对信息进行持久化存储的模块，可以采用关系数据库实现，存储模块120可以包含2个组件，即处理规则数据库121和处理结果数据库122。

一些示例中，处理规则数据库121可以用于存储各个处理节点中逻辑处理单元111-1进行业务逻辑处理所需的业务逻辑规则，业务逻辑规则可以根据不用的应用需求自由定制。

一些示例中，处理结果数据库122用于存放各个处理节点中逻辑处理单元111-1进行务逻辑处理而得到的处理结果，即对处理结果进行持久化保存。

处理模块110，包括大于或等于3的奇数个处理节点111，每个处理节点111包括逻辑处理单元111-1和本地存储单元111-2，大于或等于3的奇数个处理节点111中的一个处理节点111为领导者节点（图中未示出），其他的处理节点111为跟随者节点。

本地存储单元111-2是对状态机更新日志进行持久化的存储组件，用于保证处理节点宕机再重启后的状态机状态恢复。具体地，本地存储单元111-2，配置为对状态机更新日志进行持久化存储。由此，对互联网请求进行处理时，业务处理的中间状态可以通过处理节点内的本地存储单元111-2以及Raft协议来维护。

一些实施例中，本地存储单元111-2主要进行顺序写入，可采用对顺序写入最优化的基于LSM-Tree结构的存储器。换言之，本地存储单元111-2可以为基于LSM-Tree结构的存储器。

逻辑处理单元111-1是对按照业务逻辑规则对互联网请求进行处理的单元。具体地，逻辑处理单元111-1配置为在本处理节点为领导者节点时，收到来自互联网的请求后，按照处理规则数据库121中的业务逻辑规则对所述请求进行业务逻辑处理，将相应的处理结果通过本处理节点内部维持的状态机（图中未示出）表现并写入所述处理结果数据库122，根据业务逻辑处理中状态机的变化形成状态机更新日志，将状态机更新日志持久化到本处理节点的本地存储单元111-2并复制给每个所述跟随者节点。具体地，逻辑处理单元111-1还配置为在本处理节点为所述跟随者节点时，接收来自领导者节点的状态机更新日志，将状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的本地存储单元111-2。

实际应用中，对不同的请求，逻辑处理单元111-1需要根据当前的系统状态进行不同的处理，并且某个或某些请求被处理后，系统状态将会产生变化，进而影响后续的其他请求的处理，处理结果通过状态机表现即是由状态机将某个或某些请求被处理后将系统状态的变化传递到后续请求的处理中。例如，以基于互联网的交易请求为例，由状态机将交易请求的处理结果引起的系统状态的变化（比如，剩余商品数量、优惠额度使用量等的变化）传递到后续的交易请求的处理中。

可见，因逻辑处理单元111-1执行处理时使用的业务逻辑规则来自于存储模块120中的处理规则数据库121，因此，逻辑处理单元111-1对请求的处理可以完全在处理节点111的内存中进行，不涉及任何外部数据库等外部系统。并且，逻辑处理单元111-1得到的处理结果可以通过本处理节点内部的状态机来表现，这样全在内存处理的模式可以保证系统100具有极高的处理性能，因而能够处理非常复杂的业务逻辑，也就是说，逻辑处理单元111-1可以处理复杂请求，特别是大规模的复杂请求。

一些实施例中，处理模块110包含分布式的大于或等于3的奇数个处理节点111为分布式节点。处理模块110的所有处理节点111之间通过Raft协议保持一致。Raft协议是一种分布式一致性的实现协议。通过Raft协议，可以在每个分布式的处理节点111中维持一个状态机，在系统100的处理节点111中，逻辑处理单元111-1是通过Raft协议中维护的状态机实现业务处理逻辑的。如此，可以将业务处理逻辑融合到Raft协议所维持的状态机中，以便在处理节点的内存中完成所有的业务处理逻辑，保证了业务处理的快速性。

一些实施例中，领导者节点和跟随者节点是通过Raft协议进行领导者选举而确定的。具体地，采用Raft协议，可以通过多数同意等原则选择出领导者节点，并通过将状态机更新日志从领导者节点一致性地复制到跟随者节点，从而让整个Raft集群（也即处理模块110中的所有处理节点111）保持一致。

一些实施例中，逻辑处理单元111-1还可配置为在本处理节点为所述领导者节点时，发生宕机的处理节点的数量超过半数则停止接收和处理来自互联网的请求，发生宕机的处理节点的数量未超过半数则继续接收和处理来自互联网的请求。这样，由于系统100中的处理节点总数是大于或等于3的奇数，只要不超过半数的处理节点111宕机，系统100都可以保持可用性。

一些实施例中，逻辑处理单元111-1还可以配置为在本处理节点为所述跟随者节点时，本处理节点发生宕机再重启后，从领导者节点的本地存储单元111-2获取领导者节点的状态机更新日志，将状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的本地存储单元111-2，以恢复本处理节点的状态机。如此，可通过状态机更新日志恢复处理节点内部维持的状态机。

本申请实施例的系统100能够可靠处理大规模复杂请求。也就是说，来自互联网的请求可以是复杂请求，或者说，可以是复杂业务请求。此外，来自互联网的请求可以是大规模的复杂请求（例如，促销活动中诸如抢单、秒杀等复杂业务的交易请求），系统100中包含分布式的多个处理节点，这些分布式的多个处理节点可以在保持一致性的前提下完成大规律复杂请求的处理。可以理解，本申请实施例的系统100也可支持简单请求或其他任何类型请求的处理，对此，本申请实施例不予限制。

图2示出了本申请实施例提供的处理互联网请求的方法的流程示意图，该方法通过上述系统100实现。参见图2所示，该方法可以包括：

步骤S210，领导者节点收到来自互联网的请求后，按照来自处理规则数据库的业务逻辑规则对所述请求进行业务逻辑处理，将相应的处理结果通过本处理节点内部维持的状态机表现并写入处理结果数据库；

步骤S220，领导者节点根据所述业务逻辑处理中状态机的变化形成状态机更新日志，将所述状态机更新日志持久化到本地并复制给每个跟随者节点；

步骤S230，跟随者节点接收来自领导者节点的所述状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机，并持久化到本地。

一些实施例中，上述方法还可以包括：初始状态和/或领导者节点发生宕机后，所述系统中的所有处理节点之间通过Raft协议进行领导者选举，以选出所述领导者节点并确定所述跟随者节点。由此，可以通过Raft协议中维护的状态机实现互联网请求的处理。

一些实施例中，上述方法还可以包括：初始状态和/或跟随者节点发生宕机再重启后，跟随者节点向领导者节点获取领导者节点的状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机并持久化到本地，以恢复本处理节点的状态机。由此，能保证处理节点宕机恢复后，使得系统中的所有处理节点之间仍然能保持一致性。

一些实施例中，上述方法还可以包括：在所述系统中发生宕机的处理节点的数量超过半数时，所述领导者节点停止接收和处理来自互联网的请求；在所述系统中发生宕机的处理节点的数量未超过半数时，所述领导者节点继续接收并处理来自互联网的请求。由此，通过包含大于或等于3的奇数个处理节点的系统100进行互联网请求处理时，只要不超过半数的处理节点宕机，系统100都可以保持可用性，互联网请求的处理均可以继续。

下面对本申请实施例的示例性具体实现方式进行详细说明。

系统100可以按照如下步骤1~步骤9进行互联网请求的处理：

步骤1，系统100启动时，处理模块110中的每个处理节点111从其本地存储单元111-2中加载状态机的初始状态。

步骤2，每个处理节点111从存储模块120中的处理规则数据库121中加载业务逻辑规则，并初始化逻辑处理单元111-1以按照该业务逻辑规则运行。

步骤3，按照Raft协议的选举领导者过程，在处理模块110的所有处理节点111中选择一个处理节点作为领导者，其他的处理节点作为跟随者。

为便于引述，作为领导者的处理节点简称为领导者节点，作为跟随者的处理节点简称为跟随者节点。

步骤4，领导者节点的逻辑处理单元111-1接收来自互联网的请求（例如，复杂请求），按照业务逻辑规则对该请求进行处理，更新状态机，根据状态机的变化形成状态机更新日志，将状态机更新日志持久化到本处理节点的本地存储单元111-2，并通过Raft协议复制到各个跟随者节点。

步骤5，领导者节点的逻辑处理单元111-1将按照业务逻辑规则处理请求所获得的处理结果写入到存储模块120的处理结果数据库122中。

步骤6，各个跟随者节点接收到来自领导者节点的状态机更新日志后，跟随者节点的逻辑处理单元111-1将状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的本地存储单元111-2中，以使得本处理节点的状态机与领导者节点的状态机保持一致。

步骤7，如果跟随者节点发生宕机，只要宕机的节点数量不超过所有处理节点的一半，系统仍然保持运行，领导者节点的逻辑处理单元111-1继续接收并处理来自互联网的请求。当跟随者节点重新恢复后，跟随者节点的逻辑处理单元111-1通过向领导者节点读取状态机更新日志，将该状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的本地存储单元111-2，让本处理节点的状态机和领导者节点的状态机保持一致。

步骤8，如果领导者节点宕机，则暂停接收来自互联网的请求，按照步骤3和步骤4的方式，选举新的领导者节点，由新的领导者节点的的逻辑处理单元111-1接收并处理来自互联网的请求。

步骤9，如果超过半数的处理节点发生宕机，则整个系统暂停，领导者节点的逻辑处理单元111-1停止接收和处理来自互联网的请求，等待至少超过半数的处理节点恢复之后，正常运行的处理节点继续接收并处理来自互联网的请求，领导者节点的逻辑处理单元111-1继续接收并处理来自互联网的请求。本步骤中，跟随者节点重新恢复后，跟随者节点的逻辑处理单元111-1可以通过向领导者节点的本地存储单元111-2读取状态机更新日志，将该状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的本地存储单元111-2，让本处理节点的状态机和领导者节点的状态机保持一致。

本申请实施例具有如下的技术效果：

1）每个处理节点将业务处理逻辑融合到本处理节点维持（例如，按照Raft协议维持）的状态机中，使得所有的业务处理逻辑均可在内存进行，不仅可以实现复杂的业务逻辑，而且保证了业务处理的快速性；

2）采用分布式的多个处理节点，处理节点总数是大于或等于3的奇数，如此，只要不超过半数的处理节点宕机，系统仍可以保持可用，也即系统发生异常时也能保证处理正确并且能最大程度维持系统的可用性；

3）采用分布式的多个处理节点，并将处理节点之间采用Raft协议保持状态一致性，每个处理节点均包含一个本地存储单元，通过本地存储单元可以使各个处理节点的状态机更新日志保持一致，能保证处理节点宕机恢复后仍能保持整个系统的一致性，同时开销小，保证了整个系统的处理性能。

4）将业务处理逻辑和结果存储分离开，处理结果数据库中仅存储业务处理结果，处理规则数据库中存储业务逻辑规则，而业务处理的中间状态则通过处理节点内的本地存储单元以及Raft协议来维护，可以有效减少数据库的读写量，从而提高系统的整体吞吐量。

由上可见，本申请实施例能够在同时满足快速、正确、可靠、可处理复杂请求的前提下，让系统架构简单化，无需依赖外部的系统即可实现互联网请求的处理，具有很高的实用价值。

本申请实施例中，各个处理节点可以通过一个或多个电子设备来实现。图3示出了该电子设备的结构。参见图3所示，电子设备30可以包括：一个或多个处理器31；以及存储器32，存储有计算机程序，所述计算机程序在被所述处理器31运行时使所述处理器31执行上述处理互联网请求的方法。具体应用中，逻辑处理单元111-1可以设置于该一个或多个处理器31中或者通过该一个或多个处理器31来实现，本地存储单元111-2可以设置于该存储器32中或者通过该存储器32实现。一些示例中，该电子设备30还可包括通信接口33，以便通过通信接口33与其他电子设备（即其他的处理节点）进行通信。

本申请实施例中，各处理节点中可以包含一计算机可读存储介质，该计算机可读存储介质中其上存储有计算机程序，所述计算机程序在被处理器运行时使得所述处理器执行上述处理互联网请求的方法。

应该指出，上述详细说明都是示例性的，旨在对本申请提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语均具有与本申请所属技术领域的普通技术人员的通常理解所相同的含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请所述的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式。此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，以便这里描述的本申请的实施方式能够以除了在这里图示或描述的那些以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于描述，在这里可以使用空间相对术语，如“在……之上”、“在……上方”、“在……上表面”、“上面的”等，用来描述如在图中所示的一个器件或特征与其他器件或特征的空间位置关系。应当理解的是，空间相对术语旨在包含除了器件在图中所描述的方位之外的在使用或操作中的不同方位。例如，如果附图中的器件被倒置，则描述为“在其他器件或构造上方”或“在其他器件或构造之上”的器件之后将被定位为“在其他器件或构造下方”或“在其他器件或构造之下”。因而，示例性术语“在……上方”可以包括“在……上方”和“在……下方”两种方位。该器件也可以其他不同方式定位，如旋转90度或处于其他方位，并且对这里所使用的空间相对描述作出相应解释。

在上面详细的说明中，参考了附图，附图形成本文的一部分。在附图中，类似的符号典型地确定类似的部件，除非上下文以其他方式指明。在详细的说明书、附图及权利要求书中所描述的图示说明的实施方案不意味是限制性的。在不脱离本文所呈现的主题的精神或范围下，其他实施方案可以被使用，并且可以作其他改变。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种用于处理互联网请求的系统，其特征在于，所述系统包括处理模块和存储模块；其中，

所述存储模块，包括处理规则数据库和处理结果数据库；其中，所述处理规则数据库配置为存储业务逻辑规则，所述处理结果数据库配置为持久化存放所述处理模块的处理结果；

所述处理模块，包括大于或等于3的奇数个处理节点，每个所述处理节点包括逻辑处理单元和本地存储单元，所述大于或等于3的奇数个处理节点中的一个处理节点为领导者节点，其他的所述处理节点为跟随者节点；

所述本地存储单元，配置为对状态机更新日志进行持久化存储；

所述逻辑处理单元，配置为执行如下处理：

在本处理节点为所述领导者节点时，收到来自互联网的请求后，按照所述处理规则数据库中的业务逻辑规则对所述请求进行业务逻辑处理，将相应的处理结果通过本处理节点内部维持的状态机表现并写入所述处理结果数据库，根据所述业务逻辑处理中状态机的变化形成状态机更新日志，将所述状态机更新日志持久化到本处理节点的所述本地存储单元并复制给每个所述跟随者节点；

在本处理节点为所述跟随者节点时，接收来自所述领导者节点的所述状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的所述本地存储单元。

2.根据权利要求1所述的系统，其特征在于，所述本地存储单元为基于LSM-Tree结构的存储器。

3.根据权利要求1所述的系统，其特征在于，所述处理模块中的所有处理节点之间通过Raft协议保持一致。

4.根据权利要求1所述的系统，其特征在于，所述领导者节点和所述跟随者节点是通过Raft协议进行领导者选举而确定的。

5.根据权利要求1所述的系统，其特征在于，所述逻辑处理单元，还配置为：

在本处理节点为所述跟随者节点时，本处理节点发生宕机再重启后，从所述领导者节点的本地存储单元获取所述领导者节点的状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机并持久化到本处理节点的所述本地存储单元，以恢复本处理节点的状态机；

在本处理节点为所述领导者节点时，发生宕机的处理节点的数量超过半数则停止接收和处理来自互联网的请求，发生宕机的处理节点的数量未超过半数则继续接收和处理来自互联网的请求。

6.根据权利要求1至5任一项所述的系统，其特征在于，所述请求为复杂请求。

7.一种处理互联网请求的方法，其特征在于，通过权利要求1至6任一项所述的系统实现，所述方法包括：

领导者节点收到来自互联网的请求后，按照来自处理规则数据库的业务逻辑规则对所述请求进行业务逻辑处理，将相应的处理结果通过本处理节点内部维持的状态机表现并写入处理结果数据库；

领导者节点根据所述业务逻辑处理中状态机的变化形成状态机更新日志，将所述状态机更新日志持久化到本地并复制给每个跟随者节点；

跟随者节点接收来自领导者节点的所述状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机，并持久化到本地。

8.根据权利要求7所述的方法，其特征在于，还包括：初始状态和/或领导者节点发生宕机后，所述系统中的所有处理节点之间通过Raft协议进行领导者选举，以选出所述领导者节点并确定所述跟随者节点。

9.根据权利要求7所述的方法，其特征在于，还包括：初始状态和/或跟随者节点发生宕机再重启后，跟随者节点向领导者节点获取领导者节点的状态机更新日志，将所述状态机更新日志应用到本处理节点的状态机并持久化到本地，以恢复本处理节点的状态机。

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

在所述系统中发生宕机的处理节点的数量超过半数时，所述领导者节点停止接收和处理来自互联网的请求；

在所述系统中发生宕机的处理节点的数量未超过半数时，所述领导者节点继续接收并处理来自互联网的请求。

Images