浅谈常规网站是如何从小变大的

二、用户的session如何来同步？That’s a good question，TOO！

虽然HTTP协议是一个无状态的服务协议，但是，用户的基本信息是要求能够保证的。比如：登录信息。原来在单机的时候，我们可以很简单的使用类似setSession（“user”， ”XXX”）的函数来解决。当使用多机的时候，该怎么样来解决呢？

其实这个问题也是当年困扰我很久的一个问题。如果用setSession，用户在某一台机器上登录了，当下次请求来的时候，到其他机器了，就变成未登录了。Oh，My God！

Ok，让我们一个个的来看：

1、一台机器登录，其他机器不知道；

2、用户请求可能到多台机器。

对于第一个问题，如果我们在一台机器的登录信息让其他机器知道，不就OK了嘛。或者，大家都在一台机器上登录，不就可以了嘛。 对于第二个问题，如果我们让同一个用户的请求，只落在同一台机器上，不就OK了嘛。因此，我们可以提出三种解决方案：

1、提供session同步机制；

2、提供统一session服务；

3、将同一用户分流到同一机器。

嗯，这三种方式，你会选哪个呢？如果是我，我就选最后一个。因为我是一个懒虫，我会选最简单的一个，我信奉的一个原则既是：简单粗暴有效！哈哈。在WebServer层使用一致Hash算法，按session_id进行分流（如果WebServer没有提供该功能，可以简单写一个扩展，或者干脆在WebServer后面做一个代理即可）。但是这种方案有一个致命的问题，当一台机器宕机了以后，该机器上的所有用户的session信息即会丢失，即使是做了磁盘备份，也会有一段时间出现session失效。

好，那看看第一种方案。其实现在有一些框架已经提供了这样的服务机制。比如Tomcat就提供session同步机制。利用自有的协议，将一台机器上的session数据同步到其他的机器上。这样就有一个问题，我需要在所有的机器上配置需要同步的机器，机器的耦合度瞬间就增加了，烦啊！而且，如果session量比较大的话，同步的实效性还是一个问题。

那再来看看第二种方案，提供统一session服务。这个就是单独再写一个逻辑程序，来管理session，并且以网络服务的方式提供查询和更新。对于这样的一个阶段的服务来讲，显得重了一些。因为，我们如果这样做，又会面临一堆其他的问题，比如：这个服务是否存在单点（一台服务器，如果宕机服务就停止），使用什么样的协议来进行交互等等。这些问题在我们这个阶段都还得不到解决。所以，看起来这个方案也不是很完美。

好吧，三种方案选其一，如果是你，你会选哪一种呢？或者还有更好的方案？如果我没钱没实力（传说中的“屌丝”，哈哈），我就可能牺牲一下服务的稳定性，采用代价最低的。

三、数据访问同步问题。

当多个请求同时到达，并且竞争同一资源的时候（比如：秒杀，或是定火车票），我们怎么来解决呢？

这个时候，因为我们用到了单机数据库，可以很好的利用数据库的“锁”功能来解决这个问题。一般的数据库都提供事务的功能。事务的级别分多种，比如可重复读、串行化等，根据不同的业务需求，可能会选择不同的事务级别。我们可以在需要竞争的资源上加上锁，用于同步资源的请求。但是，这个东东也不是万能的，锁会极大的影响效率，所以尽量的减少锁的使用，并且已经使用锁的地方尽量的优化，并检查是否可能出现死锁。

cache也有对应的解决方案，比如延迟删除或者冻结时间等技术，就是让资源在一段时间处于不可读状态，用户直接从数据库查询，这样保证数据的有效性。

好了，上述三个问题，应该涵盖了我们在这个阶段遇到的大部分问题。那么，我们现在可以把整体的架构图画出来看看。

样的结构，足够我们撑一段时间了，并且因为逻辑程序的无状态性，可以通过增加机器来扩展。而接下来我们要面对的，就是提交增长和查询量增加带来的存储性能的瓶颈。

【第六阶段：写分离，提升IO性能】

好了，到现在这个阶段，我们的单机数据库可能已经逐步成为瓶颈，数据库出现比较严重的读写冲突（即：多个线程或进程因为读写需要，争抢磁盘，使得磁盘的磁头不断变换磁道或盘片，造成读写都很缓慢）。

那我们针对这样的问题，看看有哪些方法来解决。