程序原本(一百零八):系统的基本组织方法与原理——领域间的组织(以数据为中心:从会话中抽离状态)

阅读数:23 2019 年 10 月 5 日 13:50

程序原本(一百零八):系统的基本组织方法与原理——领域间的组织(以数据为中心:从会话中抽离状态)

接下来我们讨论三种常见的、以数据为中心的服务:会话、登录与镜像。

会话这一服务,是将数据理解为公共数据与状态。通过会话来形成事务是一种常见的策略,但其可靠性是受置疑的。例如我们可以将用户在 Web 上的一次交易,看做是一个有着松散的事务关系的过程,从选择商品、下单、确认、支付以及转入到发货环节。这在整体上有着工作流的特点,在部分结点上有着事务性的要求。在这样的背景下,我们要求从选择商品开始建立一个会话,并在其后的行为中基于会话来实现处理逻辑。

将会话作为一个“状态”其实是非常危险的,因为 Web 交易中不可避免地会发生用户刷新页面导致的重复提交。因此,在同一个状态上出现两个等待逻辑的状况就会出现。若这种逻辑又正好是在事务型的结点上,例如支付,那么该怎么办呢?

在稍小一些的系统中,由于相关的领域和应用结点不是非常多,因而我们还有能力应付交叉逻辑中的种种锁关系。但如果系统的规模相当大,应用逻辑相当复杂,那我们就必须回到最原初的设定上进行重新思考:会话,是否应当将数据作为状态?

在此前我们讲到过,一个能保证确定性的“数据全集 x”必须是{x,x,Sx}整个集合,其中的 Sx 就是状态。将会话数据作为状态是典型的{x,Sx}集合,因此它表现为数据确定而逻辑(x)可变。我们之所以会在逻辑中出现锁关系,便是因为逻辑对 Sx 产生了依赖(而非对 x 产生依赖)。因而将“状态 (Sx)”这一性质从“会话数据”中抽离是我们必然面临的问题。

一个可选的策略是加入消息服务。这基本上借鉴自语言设计中对并发的处理,例如在 Pascal/Delphi 系列中采用的共享状态模型,以及在 Erlang 中采用的消息传送模型。图 50 说明相关语言特性的演化8

8 该图是对 Peter Van Roy 的“主要编程范式”一图中部分内容的重新表达。参见:< www.info.ucl.ac.be/~pvr/paradigms.html >

图 50 两种可选可替代的并发模型:共享状态模型与消息传递模型

程序原本(一百零八):系统的基本组织方法与原理——领域间的组织(以数据为中心:从会话中抽离状态)

这说明共享状态模型与消息传送模型是可以相互替代的。具体来说,如果我们试图从会话中抽取掉状态,则应该考虑在多个任务(task)中“有效地传递或限制传递”这一状态 (Sx),而不是将 Sx 放到另一个数据结点中去。后面这种策略,以及之前提到的会话服务事实上都是因为 Sx 的存在而形成了数据单点。

当我们加入消息服务 M 之后(消息本身的“数据性质”中并不包括 Sx,并且也不包括逻辑 x),任务 T1,,Tn 之间便只因为“共享了会话数据”而变成相同的 n 个任务。当它们的“修改状态”请求被投送给 M 之后,M 的端口(或其他消息限制策略)将请求的消息信息队列化,进而将状态 Sx 中的时序信息拿掉9,因而在具体的、在消息服务 M 中的、有关消息响应的逻辑中,就不必再处理时序信息了。

9 从概念上来说,数据全集 x 包括指示它自身的状态 Sx;也就是说,Sx 是 x 之于时间的信息。

在消息服务 M 中是否使用同一个会话数据作为上下文,是消息模型中的一个可选策略。这可以表达为对“(确定数据下的)PD 模型”的两种不同理解,如图 51 所示。

图 51 对确定数据下的 PD 模型的两种不同理解

程序原本(一百零八):系统的基本组织方法与原理——领域间的组织(以数据为中心:从会话中抽离状态)

在解释 1 中,认为逻辑 Pn 通过确定数据之后,得到的是一个包括数据映像的新逻辑 Pn。在这种情况下,新逻辑是可以基于数据映像进一步求值的。这一思路可以理解为缓存,即在一个存储上加上 IO 逻辑。当通过 IO 逻辑得到数据时,我们并不关注数据是原始的确定数据,还是这一数据的一个映像,并且事实上我们也不关心映像与确定数据之间的同步问题,这是 IO 逻辑之下的服务层的责任。解释 2 则认为逻辑通过确定数据之后,得到的是可以用作后续计算的数据。因此,这一思路可以理解为函数连续调用,也是函数式语言的一个基本范式。

这两种模型都可以解释“消息服务 M 中是否使用同一个会话数据作为上下文”10:对于解释 1,要求会话数据是通过一个存取界面得到的;对于解释 2,要求会话数据是在消息 M 的处理逻辑中自行持有的(例如可以队列化、加锁,或使用类似闭包的方式得到一个映像)。

10 这里的“同一个会话数据”即是指数据确定,并强制要求使用该会话数据的逻辑不得有 update 操作。

评论

发布