序言
许多人都母汤氏触发器程式设计，并行程式设计，但好像对积极响应式程式设计那个新名称感到很孤单，即使他们在前述项目中早已在使用这种程式设计形式。
这篇该文是来如是说积极响应式程式设计（Reactive Progamming）究竟是怎么回事。
假如他们在 Google 中输出 Reactive Programming，企图了解这究竟是怎样的一类程式设计商业模式，他们很快会发现大量的该文，但看完他们就会癫狂，基本概念还是不是所以明晰。这可能是因为许多如是说该文对应用领域的强关连导致的。
比如说最常见的一类如是说是用一类报文（data stream）的形式来展现出，还有是后端应用领域的命令行事件流，虽然这些情景是积极响应式程式设计适宜的，但对我而言，总觉得还是不够简单。即使我面对的是网络通讯的程式设计情景。
只不过积极响应式程式设计没必要跟具体的程式设计应用领域关连，它是两个能普遍适用的基本概念和程式设计数学模型。
并行与触发器
分布式系统互联网系统中，各个合作方结点的运转是相互独立的，没有K47A，没有自上而下计时器。各结点透过最新消息来展开沟通交流。在传统的经营理念中，他们会把这样的互联网根据他们通信形式叙述成并行和触发器的。
单纯而言，并行互联网是对最新消息的抵达天数有限量发行明确要求（time bounded），以期确保互联网公益活动者完成某件先期事情，那个倚赖等候的明确要求，是并行互联网。即使他倚赖两个回复才能展开先期动作。换言之，假如两个结点推送最新消息之后，不倚赖另两个结点的回复也能正常运转，所以是触发器互联网。
在并行互联网中，假如 早已证明了，在前述的互联网中，假如不对互联网前提施予任何管制，所以互联网估值合理是永远无法达到的。因此，为了确保互联网公益活动的估值合理，他们通常会互联网前提施予一些管制，比如说，最典型的是最新消息抵达的天数管制。
解释了同步互联网和触发器互联网的区别，他们再来看并行程式设计和触发器程式设计，只不过他们接触这两个程式设计商业模式好久了。并行程式设计单纯而言是，收到两个各项任务，然后等候继续执行。而触发器程式设计是，收到两个各项任务，不等候结论，就继续收到下两个各项任务。至于上两个各项任务的继续执行结论，他们能透过两种形式获得，两个是主动的业务培训，另两个是消极的转交意见反馈。由于在触发器程式设计中，他们从来不等候继续执行结论，就能展开其它各项任务（前提是那个各项任务本身不倚赖上两个各项任务的结论）。假如要继续执行的某一其它各项任务倚赖于上两个各项任务的结论，所以他们能内要一段天数业务培训一次，或者另外开两个缓存去等候转交各项任务结论。无论何种情况，他们的互联网都不会堵塞在某两个原则上的各项任务上。
积极响应式程式设计
现在，他们很自然的过渡到积极响应式程式设计（Reactive Programming）那个基本概念上，它是一类基于事件商业模式的数学模型。在上面的触发器程式设计商业模式中，他们叙述了两种获得上两个各项任务继续执行结论的形式，两个是主动业务培训，他们把它称为 Proactive 形式。另两个是消极转交意见反馈，他们称为 Reactive。单纯而言，在 Reactive 形式中，上两个各项任务的结论的意见反馈是两个事件，那个事件的到来将会触发下两个各项任务的继续执行。
这也是 Reactive 的内涵。他们把处理和收到事件的主体称为 Reactor，它能接受事件并处理，也能在处理完事件后，收到下两个事件给其它 Reactor。两个 Reactors 之间没有必然的强耦合，他们之间透过最新消息管道来传递最新消息。Reactor 能定义一些事件处理函数，根据转交到的事件不同类型来展开不同的处理。假如他们的系统复杂，他们还能专门定义不同功能类别的 Reactors，分别处理不同类型的事件。而在每个 Reactor 中对事件又展开细分处理。
需要强调的是，实现 Reactive 数学模型最核心的是缓存和最新消息管道。缓存用于侦听事件，最新消息管道用于 Reactor 之间通信不同的最新消息。与他们相关的是事件管理器用于注册、注销事件，而最新消息分配器则会根据最新消息类型分发。
下面是两个 Reactive 数学模型的示意图：
术语理解
在了解了上述触发器程式设计数学模型的本质之后，他们再来看一些他们常见的术语，就会发现一切都变得明晰明了了。
比如说，倚赖链（Dependency chain），假定他们有两个事件倚赖链是这样：睡觉 -> 吃饭 -> 饿了，很直觉的是，在那个倚赖链中，只有满足了后面的前提，前面的才会继续执行。
这种倚赖链是那个世界普遍的一类情景，一类正向的处理商业模式是，内要一段天数就业务培训检测是否满足睡觉的前提，在检查是否能睡觉的时候，会先检查是否早已吃饭，检查是否早已吃饭的时候，会先检查是否饿了。所以这是 Proactive 商业模式！而 Reactive 商业模式则反过来，先有事件的触发，然后事件来到积极响应方，积极响应方展开处理，这种形式也叫 Pub/Sub 商业模式。他们在 OOP 语言中，也会用到同样的基本概念和逻辑，他们把之叫做 Observer 商业模式，而在 Funcaitonal Programming 中，也有同样的基本概念，它能用 monads 来实现。
比如说，他们有两个 Publisher ，会产生 “饿” 事件，同时还有两个或多个 Subscriber，在收到 “饿” 事件的发生之后，展开积极响应（会更新状态或者作出其它预先注册好的行为）。
单纯而言，Reactive Programming 是编写关于怎么积极响应事件的程式设计商业模式，这些事件包括：用户输出，报文，系统状态的变化等等。
总结一下，积极响应式程式设计通常会用在两个事件流相关的情景中，在两个事件流中，一旦触发第两个事件，先期的事件会被依次触发，就像两个 Pipeline 系统，不断有输出和输出。
积极响应式程式设计的设计与实现
接下来，讲一下积极响应式程式设计的具体设计和实现：
Reactor 的作用只不过是他们最常见的 eventHandler，是事件转交方和处理方。通常 Reactor 的数量能是预先定义的，即使两个系统，他们通常能约定它处理哪些预定义的事件，比如说有处理互联网连接的 Reactor，处理日志收集的 Reactor，处理数据存储的 Reactor 等等，各司其职。而错误（未定义）事件则能原则上放在两个专门处理 Error/Exception 的 Reactor 中。
透过事件管理器，每个 Reactor 能根据要收到或者转交的最新消息，临时的创建两个缓存去继续执行积极响应的操作。收到和转交最新消息能根据业务的复杂度，分开原则上缓存，也能放在两个缓存。这样的设计架构单纯而明晰。
下面是两个单纯的示意图：
全文完！
相关阅读：
区块链新型共识算法：Snowflake to Avalanche
P2P 互联网核心技术：Gossip 协议P2P 互联网核心技术：UPnP 和 SSDP 协议P2P 互联网核心技术：Kademlia 协议
…
，
搜索“deliverit”或
