前面说了分布式系统和单机系统五个部分的区别，输出设备输入设别除了传统的人机交互多了节点，控制器变成了负载均衡，以及运算器分布式和存储器分布式的变化。
分布式系统的介绍（2）--分布式系统&中间件从入门到精通（二）
当访问的网站有海量的数据和非常高的红发，那么他肯定是一个分布式系统，即便用小机型而不是PC Servver，也需要用集群才可以解决。
当我们需要用单机构建一个网站时候，基本会选择一个开源的server容器，直接使用servlet等技术或者使用一些开源框架来构建我们的应用。选择一个数据库管理系统来存储我们的数据，如mysql，通过jdbc来对数据库进行连接。
于是整个服务器包含着：Application Server，JDBC，DB数据库。Application Server里实现具体的功能。
举个例子，如果我们做一个交易网站，那么application Server里面就有交易，商品，用户等业务这些是在jvm 里面处理的，然后通过jdbc连接db，db里面有交易，商品，用户表。这里面的各个功能之间都是通过jvm内部的额方法调用进行交互的。
当单机负载过高，数据库和业务分离
当我们对外的服务访问人数越来越多，服务器的负载持续升高，不光应对业务计算的需求，还要应对db查询的负载，这时候就可以采用两个服务器，一个服务器放application Server，一个服务器放DB数据库，这样调整之后，可以很好地缓解当前系统的压力，不过随着时间的推移，访问量持续增加，系统还是要继续改进。
当应用服务器继续发出负载警告，这时候可以根据应用检测针对性的进行优化，把业务代码集群部署在多个服务器上，一起访问通过一个DB服务器。这里就会涉及到用户在多个服务器的选择问题，就可用到我们前面提到的负载均衡器，硬件软件都可以。
解决集群后的session问题
我们先了解一下session，用户访问浏览器，浏览器跟web服务器会多次进行交互，但是http协议是无状态协议，这时候基于http协议支持会话协议（session state）的机制，这样的协议可以保证web服务器在众多http请求中区分它们。具体实现是在会话开始的时候，web服务器会生成一个session，浏览器中的cookie里会存储这个session，当下次再访问web服务器的时候，web服务器就可以通过浏览器发过来的cookie来识别当前属于哪个会话。Web服务器会独立保存各个会话，如果我们浏览器在禁用cookie的情况下，一般会把这个会话标识放入到url参数中。
当我们集群部署多个web服务器的时候就会遇到session问题，当访问其中一个web服务器，关键点在于session保存在单机的服务器上，当我们第一次访问A服务器，获取到session，但是第二次访问了B服务器，此刻B服务器里是不存在session的。
1、Session Sticky
这个解决原理也很简单，因为用户浏览器每次访问不同的web服务器，导致的，所以我们可以在负载均衡器上做手脚，当访问的是A服务器，就一直访问A服务器就好，不过会有以下问题：
如果有一台web服务器重启或者宕机，那么这台机器上的数据会丢失，如果有登入状态，则需要重新登入，不满足高可用。
会话标识是应用层信息，那么负载均衡器需要将同一个会话保存在同一个web服务器上的话，就需要进行应用层（第7层）解析，开销比第4层要大。
负载均衡从无状态节点变成了有状态节点，内存消耗更大，容灾方面麻烦很大。
2、session Replication
这个方法不再要求每次访问的都是同一个服务器，而是我们在web服务器之间增加了会话数据的同步，通过同步保证不同web服务器的session一致性。这个方式虽然对负载均衡没有太大影响，但是也有他不足的地方：
同步session会造成比较大的开销，只要session有变化，就需要同步，数据和用户越多带来的开销越大。
每台web服务器都要保存session，存储的内容太冗余。
3、session数据集中存储
把session数据集中存储一起，然后不同web服务器从同样的地方获取session。与replication不同的是，web服务器里没有存储session数据复制，而是妨碍另一个地方集中存着。这样不论哪个web服务器，也不论修改哪个session，最终修改的都发生在这个地方，而web服务器获取session数据时候，也从集中的地方获取。而存储session可以用数据库，也可以用其他分布式的中间件。这个方案的不足之处：
读写session引入了网络操作，这时候就会有不稳定和延迟性，不过我们通信基本在内网，影响基本忽略。
如果存储session的机器或者集群除了问题，则会影响整体应用。
4、cookie based
这个方案对于同一个会话的不同请求也不限制具体处理机器，通过cookie来传递session数据，我们session数据放在cookie中，然后web服务上生成对应的session数据，这个方案和前面不同的是，不会依赖外部的存储系统，不过还是有不足的地方。
Cookie长度限制，这样就限制了session的长度。
安全性。Session本身就是服务端的数据，结果限制吧session写入了cookie，本身就不安全，虽然可以加密，但是为了安全的本质就不该接触。
带宽消耗，这里指数据中心整体发送的消耗，不是内部web服务器的消耗。
性能影响，每次处理都带着大量的session数据，响应的结果输出越少，支持并发请求会越多。
