高可用高性能系统（七）状态和无状态

    关于状态还是无状态这2种服务器架构，我在以前的一篇文章：《状态和无状态－－2种服务器架构之间的比较》http://blog.csdn.net /romandion/archive/2007/09/25/1800025.aspx   做了论述，也涉及到高可用高性能方面，现在想做一些补充。

一、核心区别

    每个服务器的架构，通常可以简化为请求和应答的过程，状态化和无状态化的最核心区别在于，服务器应答过程是否基于上次请求所构筑的上下文环境。一般说来， 无状态化架构基于请求所携带的信息，如果请求所携带的信息比较简单，象HTTP中表单，其实也可以将这部分状态化架构归于无状态化架构。而状态化架构的响 应则依赖于服务器中的上下文环境，比如期货交易系统中，要发起委托，则必须先登陆，否则资金、持仓等信息都无法获取。无状态化架构也可以模拟状态化结构， 比如在HTTP中，可以携带COOKIE，或者是服务端的会话ID，这种方式其实也是为服务端指定了上下文环境，实际上可以归结到状态化架构中。

二、请求迁移

    无状态化架构的响应条件完全基于请求所携带的内容，所以比较容易迁移，在发生错误的时候，由于发生错误节点并没有保存请求的上下文环境，所以由另外一个节点来处理完全可能获得相同的结果【 注意：是可能】， 而状态化架构在发生错误时，其他节点可能无法构筑相同的上下文环境，或者构筑相同的环境代价巨大。我们可以看到无状态摒弃了上下文依赖，“无官一身轻”的 自由，不过在请求携带会话ID的应用中，并没有这个自由。但我们也必须注意到，如果请求中包含资源的申请，那就不一定能够获取正确的结果了，比如文件传 输。
    状态化架构如果不是保存上下文信息的节点失效，那么实际上并不会造成影响。或者上下文环境能够比较容易地被重新构建出来，那么状态架构完全可以获取和无状 态同样的自由。这个情况在多数情况是比较困难的，比如在网络游戏中，一个角色的上下文环境可能包含很多角色信息，装备信息以及其他杂七杂八的数据。不过， 我们可以采取几种策略来达到这种效果。
    1、存储分割：一个请求所需要的上下文环境即使再复杂，他在一次处理中不会同时用到。我们可以按照某种策略，将这个环境分割成多个单元，放在不同的地方。将不太容易发生变化的数据存储到数据库中，而将容易变化的数据和另外一个节点同步。
    2、增量日志：将数据的变化过程转化成增量日志，当节点失效后，我们可以从失效点开始重构上下文。
    3、状态前置：在该节点之前，有个地方保存可以重现上下文的状态，该状态可以移植到其他节点，重构上下文。

    这种请求迁移不一定要在节点失效的情况下发生，而且很有可能是在负载过大的情况下发生。请求是否可以迁移是可用高性能系统的重要标记。状态化架构在这样处理之后，比较容易实现迁移，在负荷均衡方面作用就很大了。

三、实时响应

    实时响应是服务器对客户端的响应时间小。在客户端主动请求时，并不能看出这2种架构对响应时间的影响，因为同样依赖于服务器的处理能力。但当服务器需要主 动推动客户端处理时就不一样了，比如期货交易的风险类别的提示，这类计算多数是在服务端完成的，我们需要实时监控行情的变化，当合约的价格达到我们期望的 时候，需要马上作出处理。这时候需要服务器主动向监控者发送信息。
    在状态化架构中，我们可以从服务器中保存的上下文环境知道监控者在哪里，然后向他发送消息。但是在无状态化架构中，服务器中没有任何监控者的消息，只能等 监控者发送请求时，向他发送消息，这是被动的处理方式。监控者在这种架构中只能采取定时的方式，如果在时间极度敏感的环境中，这个显然是无法实现的，因为 时间间隔是无法跨越的鸿沟。
    这种情况同样会出现失效检测中。无状态化架构中，只能由客户端发送心跳请求，服务端被动地判断。而在状态化架构，服务器把握更大的主动性，因为他可以主动地去监控客户端。

四、资源存储

    不论哪种架构，只要他们涉及到对资源的访问，那么他们就面临同样的制约：资源存储。在WEB/P2P中，主要是对文件等静态资源的访问，这些资源没有变 化，因此当请求被迁移时，可以获取同样的结果，这个过程对状态化架构是同样适用的。不过在资源存储节点失效时，我们必须看到如果资源存储不是在多个节点具 有相同的备份，哪种架构都没招。
    如果是访问变化频繁的动态资源时，状态化架构比无状态化架构更具优势。因为状态化架构对变化具有更强地感知能力，可以实现增量更新的操作。无状态化架构只能读取全部的数据，或者由其他服务来提供需要的数据。
    曾经在期货交易系统中实现风险控制级别的计算，这个算法涉及到行情数据，客户的资金、持仓。行情数据还好说，可是客户的资金和持仓是在数据库中的，对于风 控服务器来说，没法感知到他们的变化，一个折中的办法就是发个请求给数据库，让他从操作日志中，解析出变化的数据再来更新本地的数据。其实这种方法对数据 库来说是很为难的事情，但是对于无状态架构来说，完全没有办法。
    资源存储和实时响应其实都涉及到变化的感知能力。当资源存储失效时，重定向到正确的资源存储点是最关键的问题。

五、长短连接

    长短连接指的是连接的保持时间，一般说来，无状态化架构倾向于短接连【如：HTTP】或者无连接，而状态化架构倾向于使用长连接。这是因为无状态化结构没有上下文关系，所以保持连接对他来说是没有必要的；而状态化架构往往需要连接来判断上下文关系，同属于一个连接的前后2个请求就属于同一个上下文的请求。
    这种关系的判断主要应用于TCP/IP的时候，如果在虚拟网中，这种关系会被模糊掉。 因为在虚拟网中，客户端极有可能是长连接在路由服务中的，但他发送的请求被路由服务转发到不同的服务节点，这时候，极有可能是无状态化架构。不过长连接对状态化架构支持得更好，毕竟长连接容易标识上下文环境。