认真考虑如何存储会话数据可以确保系统能够持续扩展。许多Web服务器或语言都提供了简单的基于服务器的会话管理方法，但这些方法通常有一些问题，例如把用户关联到了特定的服务器。实现分布式缓存，就可以在系统中存放会话数据，使系统能够持续扩展。
在你得出需要在应用或系统中维护状态，以及确定不能把状态存放在最终用户的浏览器上的结论之前，我们希望你花时间认真考虑一下推荐的流程。你应该为此决定感到难过，为自己不能想办法开发出无状态的系统或者不能让最终用户维护状态而感到羞愧。
当然，这是在开玩笑，因为我们已经承认，的确有些系统必须维护状态，即便是很少量的状态，而且这些状态最好是在服务、应用或产的基础设施中维护。考虑到这一点，我们来讨论几个在应用中维护状态的原则。
第一，也是最重要的，远离那些要求关联到一个应用或Web服务器的有状态系统。这种实现的可用性比那些可以远程访问任何服务器上的状态的实现低。如果关联的服务器死机了，那么这台服务器上的所有会话信息(包括状态)都会失效，相关的客户(很可能是几千个)就需要重复他们的操作。即使把数据存放在了本地或网络存储上，用户也需要在另一台服务器上从头来过，而上且这期间还会有服务中断。
第二，不要使用状态或会话复制服务，如某些应用服务器或第三方集群服务器上的服务。如本章前面所述，这样的系统不能很好地扩展，因为对会话的修改需要传播到很多结点上。因此，选择这种类类型的实现，我们就要关注为了扩展系统需要使用多少内存。
第三，在选择会话或状态缓存或持久引时，要选择不执行真正处理的服务器上的缓存。虽然这有点挑剔，但的确有助于提高可用性，因为当你丢失了一台服务器时，只会丢失与之相关的缓存，或者只会丢失其上运行的服务，而不会同时丢失两者。创建一个缓存(或持续)层，也使得我们可以只基于缓存访问就能进行扩展，而不必再依靠应用服务和内部及远程的缓存服务了。
采用分布式会话/状态缓存不要做哪些事：
下面列出了实现缓存管理会话或状态时要避免的三种方法口不要实现要求关联到服务器的系统。
不要使用状态或会话复制，在不同的系统中创建重复的数据。
不要把缓存放在执行操作的系统上(这并不是说不应该有本地应用缓存，只是说最好把会话信息放在自己的服务器层上)。
如果你遵守不要做哪些事情的原则，那么选择需要做哪些事情就容易多了。对于这些题，找们看不可知论的态度，因此，我们更关心的是设计，而不是实现细节，如应该采用哪种开源的缓存或数据库解决方案等。我们有一个强烈的感觉，你几乎不需要自己开发缓存方案。有了那么多分布式对象缓存选择，从memcached到开源的或第三方的数据库，如果谁还需要为存放会话信息而实现自己的缓存方案，会显得很荒谬可笑。
这就带来了问题，应该用什么实现缓存呢?对我们来说，这个问题实际上是在可靠性和持久性与成本之间进行衡量。如果你期望把会话或状态信息保存一段时间，如购物车，那么可能会决定采用具有长期可持久性的解决方案存放部分或所有的会话信息。在我们见过的许多实例中，都是采用数据库来实现的。但是，采用数据库显然会使每一事务处理的成本大于简单的解决方案，如非持久性的分布式对象缓存。
如果你不需要持久性，就可以从众多的对象缓存中选择一种。关于对象缓存及其用法的讨论。在有些情况下，你可能两者都会选择，即数据库的持久性和数据库前端的缓存的低成本性。这样的实现，既具有数据库的持久性，也可以通过数据库前端的缓存实现高成本效益的事务处理扩展。
关于分布式会话状态缓存的考虑因素
下面是三种常见的分布式缓存的实现方法及其优缺点。
只用数据库来实现成本最高，但所有数据都是持久性的，在分布式环境中可以将更新和读操作之间的冲突处理得非常好。
非持久性的分布式对象缓存比较快，成本相对较低，但出出故障后，不能恢复数据，对于用户访问间隔时间较长的情况不适用。
有的为网站建设，由数掂库提供持久性，由缓存提供高性价比的扩展性，很适合需要持久性又想成本低的情况。
本文地址：//www.gogoparty.cc//article/3517.html
