17.企业应用架构模式 --- 会话状态模式

1.客户会话状态
	将会话状态保存在客户端。

	1.运行机制
		即使是最面向服务器的设计也至少要用到一些客户会话状态，哪怕是用来记录会话标识号。有的应用中可以考虑把所有的会话状态都保存到客户端，这种情况下，客户端
	  每次请求都把所有的会话数据传给服务器，服务器在每次响应时把所有的会话状态传给客户。这样的服务器可以是完全无状态的。
	  	通常使用数据传输对象来传输数据。数据传输对象可以在网络上序列化。
	  	客户也需要存储数据。

	  	如果使用HTML，情况就会复杂一些。一般有3种方法：url参数，表单的隐藏域和cookie。
	  	url参数对于小量数据比较容易使用。实际上所有请求页面的url都会带上一个会话状态作为参数，一个明显的限制是url的长度，对于只有少数几个数据项的参数可以很
	  方便的处理，这也是经常用它来传递会话标识号的原因。一些平台会自动通过重写url来加上会话标识号，但改变url会影响浏览器收藏夹，因此不主张在供客户使用的系统中
	  使用。
	  	表单隐藏域是一些不会在web浏览器中显示出来的表单域。使用标记<input type="hidden">来定义隐藏域。服务器在每次响应时将会话状态序列化到一些隐藏域中，就
	  能在每次接收客户请求时读到它们。一般需要将数据格式化以便放在隐藏域中。xml显然是一种标准方式，但是它太啰嗦了。可以将数据转化成为本传输。隐藏域只能通过页面
	  源码看到它们。
	  	最后一种，也是最有争议的一种方式是使用cookie，它自动在服务器与客户传输。与使用隐藏域一样，可以把会话数据序列化后存放在cookie中。cookie的大小一般是有限制
	  的。而且，有些用户不愿意使用cookie。如果这样，基于cookie的站点就不能工作了。需要说明的是cookie并不比别的方式更安全，数据也会被挖掘出来。另外cookie只能工作
	  在同一个域名的站点中，如果一个站点包含了多个域名，cookie不会再它们之间传递。

	2.使用时机
		客户会话状态有一定的优点。特别是支持无状态服务器对象，从而提高最大的集群性能和容错恢复。当然，如果客户崩溃了，它所有的会话数据就丢失了，但用户通常认为这是合理的。
	  客户会话状态受数据量的影响非常大。它可以很漂亮的处理小数据量的会话状态，一旦数据量大了，何处保存数据的问题和每次请求时传输所有的数据导致的延迟会令人无法接受。还有
	  就是安全问题。所有送到客户的数据都很容易泄露或者被篡改。只能通过加密的方式来保证数据安全，但是每次处理请求都要进行加密会影响性能。
	  	几乎总是用客户会话来处理会话标记。幸运的是，它一般只是一个数字，没有上面的问题。但仍然要注意会话被盗用，因为会有恶意用户尝试通过改变其会话标识来窃取别人的会话数据。
	  大多数平台提供一个随机选取的会话id来避免这种风险。如果不行，还可以通过一个散列函数来运行一个简单的会话id。

2.服务器会话状态
	将会话状态以序列化的形式存放在服务器。

	1.运行机制
		这种模式里面最简单的一种方法是把会话数据存放在应用服务器的内存中。可以将会话数据以会话标识号作为键标识存放在内存映射表中。只需要客户端给出会话标识号，服务器就可以从
	  映射表中取出会话数据。
	  	当然，这种方法假设应用服务器有足够的内存进行处理，而且只能有一个应用服务器---即，没有集群---如果这个应用服务器崩溃了，所有的会话数据就会丢失的无影无踪。
	  	首先解决会话数据占用内存资源的问题。实际上，这是服务器会话状态最大的缺点。办法就是不把会话数据存放在内存中，而是序列化到备忘录持久保存起来。这又带来2个问题：以
	  什么样的形式持久化服务器会话状态和持久化到哪儿。
	  	使用的形式越简单越好，因为服务器会话状态就是为了简化编程。一些平台提供了一个简单的二进制序列化机制，这个机制让你很轻易的序列化对象图。还看以序列化到其他形式，比如
	  文本---最流行的是xml文档。
	  	二进制的形式通常会简单些，因为不需要怎么编程，而文本形式需要至少处理下。二进制序列化更省空间，虽然一般不用担心磁盘空间不够，但越大的序列化映像需要越长的时间装入内存。
	  使用二进制序列化有2个问题。第一个问题是序列化后的内容不便于人们阅读。第二个是版本问题。如果对类进行了修改，比如在序列化后又给类加了一个数据域，就无法读出以前序列化的数据。
	  	现在只有将会话状态持久化到哪儿的问题了。最可能的方案是放在应用服务器上，文件系统或本地数据库。这是最简单的办法，但无法支持有效的集群和故障恢复。为了支持这些方面，服务器
	  会话状态需要放到一个公共访问的地方，如共享服务器。这样既可以支持集群和故障恢复，代价是需要更长的时间激活服务器---尽管使用高速缓存可以很好的减少这个代价。

	  	如果将服务器会话状态存放到数据库中，还要作废的话进行处理。尤其是一个面向顾客的应用中。一种方法是用一个监督进程检查并删除过期的会话，但这样会导致很多与会话表的连接。另外
	  一种方法是：将会话表分成12段，每2个小时轮换一次，轮换时先删除时间最旧的段中的所有数据。虽然这样会把那些超过24小时的会话强制删除，但实际上不用去担心这样极少数的情况。

	2.使用时机
		服务器会话状态的最大好处是简单。大多数情况下根本不需要编程。是否只需要这样做哟啊看使用内存的方案是否满足需求。如果不满足，再看看应用服务器能帮什么忙。

3.数据库会话状态
	将会话数据作为已提交的数据保存到数据库中。

	1.运行机制
		当客户向服务器发出请求时，服务器要先从数据库中读出请求所需的数据，进行处理，然后再将数据写回数据库中。为了从数据库中读数据，服务器对象需要知道会话的一些信息，至少
	  知道客户传来的会话标识号。通常情况下，这些信息是一些用来从数据库读取信息的关键字值。
	  	用到的数据不外乎只与当前交互有关的会话状态和会影响其他交互的已提交到数据库中的数据。
	  	关键问题是会话状态是会话的局部数据，通常不能在整体体积到数据库之前影响系统的其他部分。
	  	那怎样区别对待会话数据呢？在每个数据行加上一个说明是否是会话数据的字段是一个办法。最简的形式只要一个isPending的布尔字段。第二种方法是使用单独的临时表。
	2.使用时机	
		数据库会话状态是一种处理会话状态的方法，应该与服务器会话状态和客户端会话状态比较一下。
		首先考虑一下性能。使用无状态的对象可以提高服务器性能，使缓冲和集群变得容易。但要在处理每个请求时多花时间进行数据库读写。可以通过缓存一些数据来减少数据库操作的开销，
	  如果在读数据时缓存命中，则省了读的事件，但写数据仍然要花费时间。
	  	其次考虑编程量，多数编程用来处理会话状态。如果没有会话数据，而且每次请求都可以直接提交成记录数据，就最适合这种模式，因为没有任何编程量和性能损失。
	  	在选择数据库会话和服务器会话时，关键取决于在特定应用服务器上使用服务器会话便于集群和故障恢复的程度。至少在一般情况下，使用数据库会话进行集群和故障恢复要更直接一些。