CN103209223B - 分布式应用会话信息共享方法、***和应用服务器 - Google Patents

Abstract

本发明公开了一种分布式应用会话信息共享方法、***和应用服务器，涉及分布式应用技术领域。该方法包括：应用服务器接收来自负载均衡器的第一次请求，将应用建立的会话信息保存到会话数据库/服务器，并复制会话信息到本地会话；对于后续请求，应用服务器根据会话标识从会话数据库/服务器读取会话信息的更新标志；如果更新标志指示不需要更新会话信息，则应用服务器上的应用根据本地会话的会话信息处理后续请求。该方法、***和服务器混合使用会话本地存储和会话远程存储两种方式，通过减少会话信息的远程读取次数，从而使会话信息分布式共享的开销大幅减少，有效提高***性能。

Description

分布式应用会话信息共享方法、***和应用服务器

技术领域

本发明涉及分布式应用技术领域，特别涉及一种分布式应用会话信息共享方法、***和应用服务器。

背景技术

典型的Web应用***通常使用多层次的架构设计，包括展示层、业务层和数据层。通常，展示层和业务层只是逻辑分层，实际部署时都在同一个物理节点上。

许多企业级应用对于***的扩展性有很高的要求，需要展示层和业务层不仅逻辑分离还要物理分离，从而实现真正的分层结构。展示层和业务层分离后，各自可以根据其对性能的要求，按需配置资源，从而提高了***整体的扩展能力。同时，展示层和业务层解除物理耦合后，展示层和业务层的逻辑关系可以由1对1变为多对多，1个业务层可以服务于多个展示层，1个展示层也可以使用多个业务层，从而达成真正的分层松耦合的分布式***架构。

当应用使用了分布式***架构后，有些业务场景需要解决会话信息共享的问题。比如，服务器A部署登陆模块，服务器B部署用户管理模块。客户登陆后，将客户基本信息存储在会话(Session)中，服务器B的用户管理交易需要能够访问会话中的用户基本信息来完成后续操作。对于这种分布式应用需共享会话信息的情况，通常有两种解决方式：一种是将会话信息存储到专门的会话状态服务器(State-Server)上，另一种是将会话信息存储到会话数据库(State-DB)中。应用服务器直接访问State-Server或State-DB，完成对会话信息进行增删改查操作时，State-Server或State-DB负责对会话信息进行管理。

State-Server和State-DB虽然使分布式应用可以共享会话，但较之会话信息存储在本地服务器（State In-Proc)的方式，存在显著的性能问题：业务层功能在处理每一次交易之前都需均需额外访问一次远程服务器取回会话信息，整个交易链条变长，***的整体性能肯定会降低。同时，State-Server和State-DB也很容易成为***的单点瓶颈。

Java EE、.Net和LAMP平台均支持State-DB的方式，该方式也是与本发明最接近的技术方案。以.Net平台的简单Web应用为例，多个HTTP请求由负载均衡设备分发到不同的应用服务器上，应用服务器之间共享会话信息，会话信息存储在一***立的数据库服务器上。图1示出了现有State-DB方式一个例子的***示意图。如图1所示，HTTP请求经过负载均衡器（Load Balancer）11分配给服务器1或服务器2，会话信息存储在MS SQL服务器12的数据库上。会话信息存储在独立的数据库之后，对于每个交易请求，应用服务器均需额外访问数据库服务器以获得会话信息，相应的网络传输时间和数据库服务器处理时间将降低***整体的性能。

发明内容

本发明的发明人发现上述现有技术中存在问题，并因此针对所述问题中的至少一个问题提出了一种新的技术方案。

本发明的一个目的是提供一种用于分布式应用会话信息共享的技术方案。

根据本发明的第一方面，提供了一种分布式应用会话信息共享方法，包括：

应用服务器接收来自负载均衡器的第一次请求，将应用建立的会话信息保存到会话数据库/服务器，并复制会话信息到本地会话；

应用服务器接收来自负载均衡器的后续请求，后续请求中包含会话标识；

应用服务器根据会话标识从会话数据库/服务器读取会话信息的 更新标志；

如果更新标志指示不需要更新会话信息，则应用服务器上的应用根据本地会话的会话信息处理后续请求。

可选地，该方法还包括：如果更新标志指示需要更新会话信息，则应用服务器从会话数据库/服务器更新会话信息；应用服务器上的应用根据更新的会话信息处理后续请求。

可选地，应用服务器接收来自负载均衡器的后续请求之前还包括：负载均衡器接收来自客户端的后续请求，通过会话保持将后续请求分配到应用服务器。

可选地，应用服务器根据会话标识从会话数据库/服务器读取会话信息的更新标志包括：

应用服务器判断本地会话中是否存储有与会话标识对应的会话信息；

如果未存储与会话标识对应的会话信息，则应用服务器根据会话标识从会话数据库/服务器读取会话信息；

如果存储与会话标识对应的会话信息，应用服务器根据会话标识从会话数据库/服务器读取会话信息的更新标志。

可选地，应用服务器根据会话标识从会话数据库/服务器读取会话信息的更新标志包括：

应用服务器判断交易是否配置了State-InProc属性，如果是，则应用直接使用本地会话的会话信息处理后续请求；

否则，应用服务器根据会话标识从会话数据库/服务器读取会话信息的更新标志。

根据本发明的另一方面，提供一种应用服务器，包括：

会话信息生成模块，用于接收来自负载均衡器的第一次请求，将应用建立的会话信息保存到会话数据库/服务器，并复制会话信息到本地会话；

会话标识获取模块，用于接收来自负载均衡器的后续请求，后续请求中包含会话标识；

更新标志获取模块，用于根据会话标识从会话数据库/服务器读取会话信息的更新标志；

后续请求处理模块，如果更新标志指示不需要更新会话信息，使应用服务器上的应用根据本地会话的会话信息处理后续请求。

可选地，如果更新标志指示需要更新会话信息，则后续请求处理模块从会话数据库/服务器更新会话信息，应用服务器上的应用根据更新的会话信息处理后续请求。

可选地，更新标志获取模块包括：

本地会话判断单元，用于判断本地会话中是否存储有与会话标识对应的会话信息，如果未存储与会话标识对应的会话信息，则向会话信息读取单元发送会话信息读取消息，否则，向更新标志读取单元发送更新标志读取消息，会话信息读取消息和更新标志读取消息中包括会话标识；

会话信息读取单元，用于接收会话信息读取消息，根据会话标识从会话数据库/服务器读取会话信息；

更新标志读取单元，用于接收更新标志读取消息，根据会话标识从会话数据库/服务器读取会话信息的更新标志。

可选地，更新标志获取模块还包括：属性判断单元，用于接收来自本地会话判断单元的更新标志读取消息，判断交易是否配置了State-InProc属性，如果是，则不向更新标志读取单元转发更新标志读取消息，应用直接使用本地会话的会话信息处理后续请求；否则，向更新标志读取单元转发更新标志读取消息。

根据本发明的又一方面，提供一种分布式应用会话信息共享***，包括上述的应用服务器，以及负载均衡器；负载均衡器接收来自客户端的后续请求，通过会话保持将后续请求分配到应用服务器。

本发明的一个优点在于，应用服务器接收来自负载均衡器的后续请求后，根据会话标识从会话数据库/服务器上获取更新标志，对于不需要更新的会话，直接根据本地会话的会话信息处理后续请求，混合使用会话本地存储和会话远程存储两种方式，通过减少会话信息的远 程读取次数，从而使会话信息分布式共享的开销大幅减少，有效提高***性能。

通过以下参照附图对本发明的示例性实施例的详细描述，本发明的其它特征及其优点将会变得清楚。

附图说明

构成说明书的一部分的附图描述了本发明的实施例，并且连同说明书一起用于解释本发明的原理。

参照附图，根据下面的详细描述，可以更加清楚地理解本发明，其中：

图1示出了现有State-DB方式一个例子的***示意图。

图2示出根据本发明的分布式应用会话信息共享方法的一个实施例的流程图。

图3示出根据本发明的分布式应用会话信息共享方法的另一个实施例的流程图。

图4示出根据本发明的应用服务器的一个实施例的结构图。

图5示出根据本发明的应用服务器的另一个实施例的结构图。

图6示出根据本发明的实施方案的一个例子的示意图。

具体实施方式

现在将参照附图来详细描述本发明的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说 明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

本文中相关术语解释：

State-InProc方式：会话信息存储在进程中。

State-Server/State-DB方式：会话信息存储在会话服务器/会话数据库上。

State-M：实现本发明功能的技术模块。

负载均衡：将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

会话保持：会话保持就是指在负载均衡器上有这么一种机制，可以识别做客户与服务器之间交互过程的关连性，在作负载均衡的同时，还保证一系列相关联的访问请求会保持分配到一台服务器上。

图2示出根据本发明的分布式应用会话信息共享方法的一个实施例的流程图。

如图2所示，步骤202，应用服务器接收来自负载均衡器的第一次请求，将应用建立的会话信息保存到会话数据库/服务器，并复制会话信息到本地会话。负载均衡器通过负载均衡技术将请求分配到不同的应用服务器。应用服务器将生成的会话标识传送给负载均衡器。

步骤204，应用服务器接收来自负载均衡器的后续请求，后续请求中包含会话标识，例如，由负载均衡器或者客户端在后续请求中添加会话标识。应用服务器从后续请求中解析获得会话标识。

步骤206，应用服务器根据会话标识从会话数据库/服务器读取会话信息的更新标志。

步骤208，如果更新标志指示不需要更新会话信息，则应用服务器上的应用根据本地会话的会话信息处理后续请求。

如果更新标志指示需要更新会话信息，则应用服务器从会话数据库/服务器读取更新的会话信息，应用服务器上的应用根据更新的会话信息处理后续请求。

上述实施例中，应用服务器接收来自负载均衡器的后续请求后，根据会话标识从会话数据库/服务器上获取更新标志，对于不需要更新的会话，直接根据本地会话的会话信息处理后续请求，兼具State-InProc和State-DB方式的优点，使分布式会话共享的性能得到显著提升。

图3示出根据本发明的分布式应用会话信息共享方法的另一个实施例的流程图。

如图3所示，步骤302，负载均衡器接收到来自客户端的第一次请求，将该请求通过负载均衡技术分配给应用服务器。

步骤304，应用服务器接收来自负载均衡器的第一次请求，将应用建立的会话信息保存到会话数据库/服务器，复制会话信息到本地会话。

步骤306，负载均衡器接收到来自客户端的后续请求，将该后续请求通过会话保持技术分配给上次分配的应用服务器。会话保持例如包括：简单会话保持（源地址会话保持）、HTTP（HTTP-Hypertext Transfer Protocol,协议简介超文本传输协议）头（Header）的会话保持，基于SSL（Secure Sockets Layer，安全套接层）会话标识（Session ID）的会话保持，I-Rules（I规则）会话保持以及基于HTTP Cookie的会话保持，此外还有基于SIP ID以及缓存（Cache）设备的会话保持等。

步骤308，应用服务器接收来自负载均衡器的后续请求，后续请求中包含会话标识。应用服务器从后续请求中解析获得会话标识。

步骤310，应用服务器根据会话标识判断本地会话中是否存储有该会话信息？如果是，则继续步骤312，否则，继续步骤316。

步骤312，应用服务器根据会话标识从会话数据库/服务器读取会话信息的更新标志。

步骤314，根据更新标志判断是否需要更新会话信息，如果是，继续步骤316，否则，继续步骤318。

步骤316，应用服务器根据会话标识从会话数据库/服务器读取会话信息。

步骤318，应用服务器从本地会话读取会话信息。

步骤320，应用服务器上的应用根据获得会话信息处理后续请求。

企业级应用通常需要会话服务器或独立的数据库服务器使多个分布式应用共享会话信息。上述实施例中，利用负载均衡设备的会话粘贴特性，混合使用会话本地存储和会话远程存储两种方式，通过减少会话信息的远程读取次数，从而使会话信息分布式共享的开销大幅减少，有效提高***性能。

在一个实施例中，应用服务器判断交易（即用户的请求）是否配置了State-InProc属性，如果是，则应用直接使用本地会话的会话信息处理后续请求；否则，应用服务器才根据会话标识从会话数据库/服务器读取会话信息的更新标志。对于配置了State-InProc属性的交易，由于其直接从本地服务器读取会话信息，使得***不存在远程会话访问，其性能将进一步得到提高。

图4示出根据本发明的应用服务器的一个实施例的结构图。如图4所示，该应用服务器包括：会话信息生成模块41，用于接收来自负载均衡器的第一次请求，将应用建立的会话信息保存到会话数据库/服务器，并复制会话信息到本地会话；会话标识获取模块42，用于接收来自负载均衡器的后续请求，后续请求中包含会话标识；更新标志获取模块43，用于根据会话标识从所述会话数据库/服务器读取会话信息的更新标志；后续请求处理模块44，如果更新标志指示不需要更新会话信息，使应用服务器上的应用根据本地会话的会话信息处理后续请求。如果更新标志指示需要更新会话信息，则后续请求处理模块44从会话数据库/服务器更新会话信息，应用服务器上的应用根据更新的 会话信息处理后续请求。

图5示出根据本发明的应用服务器的另一个实施例的结构图。如图5所示，该应用服务器包括：会话信息生成模块41、会话标识获取模块42、更新标志获取模块53和后续请求处理模块44。其中，会话信息生成模块41、会话标识获取模块42和后续请求处理模块44可以参见上述实施例的对应描述，为简洁起见在此不再详细描述。更新标志获取模块53包括：本地会话判断单元531，用于判断本地会话中是否存储有与会话标识对应的会话信息，如果未存储与会话标识对应的会话信息，则向会话信息读取单元发送会话信息读取消息，否则，向更新标志读取单元发送更新标志读取消息，会话信息读取消息和更新标志读取消息中包括会话标识；会话信息读取单元532，用于接收会话信息读取消息，根据会话标识从会话数据库/服务器读取会话信息；更新标志读取单元534，用于接收更新标志读取消息，根据会话标识从所述会话数据库/服务器读取会话信息的更新标志。

在一个实施例中，所述更新标志获取模块53还包括：属性判断单元533，用于接收来自本地会话判断单元的更新标志读取消息，判断交易是否配置了State-InProc属性，如果是，则不向更新标志读取单元转发更新标志读取消息，应用直接使用本地会话的会话信息处理后续请求；否则，向更新标志读取单元转发更新标志读取消息。

图6示出根据本发明的实施方案的一个例子的示意图。如图6所示，该例子基于负载均衡器61，通过实现一个会话处理模块（以下简称State-M）62，使应用既可以拥有近似State-InProc的性能又可以享受State-DB所支持的分布式特性。整个***使用了负载均衡器，所以State-M可以使用“会话保持”特性。对于第一次Http请求，State-M负责将本地应用建立的会话信息保存到会话数据库63上，并复制一份到本地会话。负载均衡器收到第二次Http请求后，会将请求转发到之前的服务器上，这时State-M从数据库中读取会话信息的更新标志，如果确定需要更新则取回所有会话信息，如果不需要更新，则直接让本地应用使用本地会话。

此外，State-M还支持交易粒度的State-InProc属性，如某个交易对会话信息的变更不敏感，则可以配置State-InProc属性，这样State-M对于这个交易请求会直接使用本地会话，从而进一步降低分布式会话共享的开销。

对于会话信息变更不频繁的应用，应用服务器与State-DB之间交互的数据在大多数情况下由整个会话信息压缩到了状态时间戳。而对于配置了State-InProc属性的交易，由于其直接从本地服务器读取会话信息，使得***不存在远程会话访问，其性能将进一步得到提高。

至此，已经详细描述了根据本发明的分布式应用会话信息共享方法、***和应用服务器。为了避免遮蔽本发明的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。

可能以许多方式来实现本发明的方法和***。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法和***。用于所述方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。

虽然已经通过示例对本发明的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本发明的范围。本领域的技术人员应该理解，可在不脱离本发明的范围和精神的情况下，对以上实施例进行修改。本发明的范围由所附权利要求来限定。

Claims (10)

1.一种分布式应用会话信息共享方法，其特征在于，包括：

应用服务器接收来自负载均衡器的第一次请求，将应用建立的会话信息保存到会话数据库/会话服务器，并复制所述会话信息到本地会话；

所述应用服务器接收来自所述负载均衡器的后续请求，所述后续请求中包含会话标识；

所述应用服务器根据所述会话标识从所述会话数据库/会话服务器读取所述会话信息的更新标志；

如果所述更新标志指示不需要更新所述会话信息，则所述应用服务器上的应用根据本地会话的所述会话信息处理所述后续请求。

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

如果所述更新标志指示需要更新所述会话信息，则所述应用服务器从所述会话数据库/会话服务器更新所述会话信息；

所述应用服务器上的应用根据更新的所述会话信息处理所述后续请求。

3.根据权利要求1所述的方法，其特征在于，所述应用服务器接收来自所述负载均衡器的后续请求之前还包括：

所述负载均衡器接收来自客户端的后续请求，通过会话保持将所述后续请求分配到所述应用服务器。

4.根据权利要求1所述的方法，其特征在于，所述应用服务器根据所述会话标识从所述会话数据库/会话服务器读取所述会话信息的更新标志包括：

所述应用服务器判断本地会话中是否存储有与所述会话标识对应的会话信息；

如果未存储与所述会话标识对应的会话信息，则所述应用服务器根据所述会话标识从所述会话数据库/会话服务器读取所述会话信息；

如果存储与所述会话标识对应的会话信息，所述应用服务器根据所述会话标识从所述会话数据库/会话服务器读取所述会话信息的更新标志。

5.根据权利要求4所述的方法，其特征在于，所述应用服务器根据所述会话标识从所述会话数据库/会话服务器读取所述会话信息的更新标志包括：

所述应用服务器判断交易请求是否配置了会话信息存储在进程中State-InProc属性，如果是，则应用直接使用本地会话的所述会话信息处理所述后续请求；

否则，所述应用服务器根据所述会话标识从所述会话数据库/服务器读取所述会话信息的更新标志。

6.一种应用服务器，其特征在于，包括：

会话信息生成模块，用于接收来自负载均衡器的第一次请求，将应用建立的会话信息保存到会话数据库/会话服务器，并复制所述会话信息到本地会话；

会话标识获取模块，用于接收来自所述负载均衡器的后续请求，所述后续请求中包含会话标识；

更新标志获取模块，用于根据所述会话标识从所述会话数据库/会话服务器读取所述会话信息的更新标志；

后续请求处理模块，如果所述更新标志指示不需要更新所述会话信息，使应用服务器上的应用根据本地会话的所述会话信息处理所述后续请求。

7.根据权利要求6所述的服务器，其特征在于，

如果所述更新标志指示需要更新所述会话信息，则所述后续请求处理模块从所述会话数据库/会话服务器更新所述会话信息，所述应用服务器上的应用根据更新的所述会话信息处理所述后续请求。

8.根据权利要求6所述的服务器，其特征在于，所述更新标志获取模块包括：

本地会话判断单元，用于判断本地会话中是否存储有与所述会话标识对应的会话信息，如果未存储与所述会话标识对应的会话信息，则向会话信息读取单元发送会话信息读取消息，否则，向所述更新标志读取单元发送更新标志读取消息，所述会话信息读取消息和所述更新标志读取消息中包括所述会话标识；

会话信息读取单元，用于接收会话信息读取消息，根据所述会话标识从所述会话数据库/会话服务器读取所述会话信息；

更新标志读取单元，用于接收更新标志读取消息，根据所述会话标识从所述会话数据库/会话服务器读取所述会话信息的更新标志。

9.根据权利要求8所述的服务器，其特征在于，所述更新标志获取模块还包括：

属性判断单元，用于接收来自所述本地会话判断单元的更新标志读取消息，判断交易请求是否配置了会话信息存储在进程中State-InProc属性，如果是，则不向所述更新标志读取单元转发所述更新标志读取消息，应用直接使用本地会话的所述会话信息处理所述后续请求；否则，向所述更新标志读取单元转发所述更新标志读取消息。

10.一种分布式应用会话信息共享***，其特征在于，包括如权利要求6至9中任意一项所述的应用服务器，以及负载均衡器；

所述负载均衡器接收来自客户端的后续请求，通过会话保持将所述后续请求分配到所述应用服务器。