Question

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

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

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

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

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

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

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

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

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

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

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

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

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