解决session的问题的本质也就是解决session的存储问题

　　在我的公司里客户端的请求到达web服务器之前，会先到F5，F5是一个用来做负载均衡的硬件设备，它的作用是将用户请求均匀的分发到后台的服务器集群，F5是硬件的负载均衡解决方案，如果我们没那么多钱买这样的设备，也有软件的负载均衡解决方案，这个方案就是大名鼎鼎的LVS了，这些负载均衡设备除了可以分发请求外它们还有个能力，这个能力是根据http协议的特点设计的，一个http请求从客户端到达最终的存储服务器之前可能会经过很多不同的设备，如果我们把一个请求比作高速公路上的一辆汽车，这些设备也可以叫做这些节点就是高速路上的收费站，这些收费站都能根据自己的需求改变http报文的内容，所以负载均衡设备可以记住每个sessionid值对应的后台服务器，当一个带有sessionid值的请求通过负载均衡设备时候，负载均衡设备会根据该sessionid值直接找到指定的web服务器，这种做法有个专有名词就是session粘滞，这种做法也比那种session信息在不同服务器之间拷贝复制要高效，不过该做法还是比存cookie的效率低下，而且对于网站的稳定性也有一定影响即如果某台服务器挂掉了，那么连接到该服务器的用户的会话都会失效。

　　解决session的问题的本质也就是解决session的存储问题，其本质也就是解决网站的存储问题，一个初建的网站在早期的运营期需要解决的问题基本都是由存储导致的。上文里我提到时下很多新建的web应用会将服务器部署后云平台里，好的云平台里或许会帮助我们解决负载均衡和session同步的问题，但是云平台里有个问题很难解决那就是数据库的存储问题，如果我们使用的云平台发生了重大事故，导致云平台存储的数据丢失，这种会不会导致我们在云平台里数据库的信息也会丢失了，虽然这个事情的概率不高，但是发生这种事情的几率还是有的，虽然很多云平台都声称自己多么可靠，但是真实可靠性有多高不是局中人还真不清楚哦，因此使用云平台我们首要考虑的就是要做好数据备份，假如真发生了数据丢失，对于一个快速成长的网站而言可能非常致命。

　　写到这里一个婴儿般的网站就这样被我们创造出来了，我们希望网站能健康快速的成长，如果网站真的按我们预期成长了，那么一定会有一天我们制造的宝宝屋已经满足不了现实的需求，这个时候我们应该如何抉择了?换掉，全部换掉，使用新的架构例如我们以前长提的SOA架构，分布式技术，这个方法不错，但是SOA和分布式技术是很难的，成本是很高的，如果这时候我们通过添加几台服务器就能解决问题的话，我们绝对不要去选择什么分布式技术，因为这个成本太高了。上面我讲到几种session共享的方案，这个方案解决了应用的水平扩展问题，那么当我们网站出现瓶颈时候就多加几台服务器不就行了吗?那么这里就有个问题了，当网站成长很快，网站首先碰到的瓶颈到底是哪个方面的问题?

　　本人是做金融网站的，我们所做的网站有个特点就是当用户访问到我们所做的网站时候，目的都很明确就是为了付钱，用户到了我们所做的网站时候都希望能快点，再快点完成本网站的操作，很多用户在使用我们做的网站时候不太去关心网站的其他内容，因此我们所做的网站相对于数据库而言就是读写比例其实非常的均匀，甚至很多场景写比读要高，这个特点是很多专业服务网站的特点，其实这样的网站和企业开发的特点很类似：业务操作的重要度超过了业务展示的重要度，因此专业性网站吸纳企业系统开发的特点比较多。但是大部分我们日常常用的网站，我们逗留时间很长的网站按数据库角度而言往往是读远远大于写，例如大众点评网站它的读写比率往往是9比1。

　　12306或许是中国最著名的网站之一，我记得12306早期经常出现一个问题就是用户登录老是登不上，甚至在高峰期整个网站挂掉，页面显示503网站拒绝访问的问题，这个现象很好理解就是网站并发高了，大量人去登录网站，购票，系统挂掉了，最后所有的人都不能使用网站了。当网站出现503拒绝访问时候，那么这个网站就出现了最致命的问题，解决大用户访问的确是个超级难题，但是当高并发无法避免时候，整个网站都不能使用这个只能说网站设计上发生了致命错误，一个好的网站设计在应对超出自己能力的并发时候我们首先应该是不让他挂掉，因为这种结果是谁都不能使用，我们希望那些在可接受的请求下，让在可接受请求范围内的请求还是可以正常使用，超出的请求可以被拒绝，但是它们绝对不能影响到全网站的稳定性，现在我们看到了12306网站的峰值从未减少过，而且是越变越多，但是12306出现全站挂掉的问题是越来越少了。通过12036网站改变我们更进一步思考下网站的瓶颈问题。