1、应用服务器层的水平扩展。实现应用服务器层的负载均衡，是实现应用服务器水平扩展的最主要手段，具体实现负载均衡的策略有以下两种：
      a.基于硬件负载均衡设备实现负载均衡，如F5设备。
      b.基于软件的方式实现负载均衡，例如通过配置Apache Http Server。

      Apache可以实现负载均衡，根据服务器的压力情况，将每个用户请求分布到不同的应用服务器上。但大部分应用的用户请教是有状态的（一般使用Session记录用户状态）。这种情况下，如何能够在多台应用服务器之间保持用户状态，将是实现应用服务器层水平扩展的关键。
      a.Session复制。Session复制的技术实现非常复杂，在大规模集群中实用性并不强，服务器之间大量的Session复制会严重影响这些服务器的性能。而随着服务器数量的增加，这种性能影响会显得更加突出，甚至不可接受。在大部分互联网应用中，Session复制技术应该是很少采用的。
      b.Session Sticky。为了避免Session复制所带来的性能影响，更简单、也是更高效的一种做法是Session Sticky。这种方式将同一用户的请求转发到特定的JBoss服务器上，避免了集群中Session的复制。Session Sticky的实现非常简单，但是这种方式不能满足fail-over的需求。即当一台应用服务器down的时候，这台服务器上正在访问的所有用户的Session都失效了，所有用户不得不再次重新登录。而且这种方式还容易导致负载不够均衡。
      c.基于Cache的集中式Session。这种方案通常使用集中式的Cache来代替本地Session。集中式的Session服务器采用的是MemCached，其本身也具备水平扩展能力。当Session数量大到一台Cache服务器都不能承受的程度时，我们也仅需要增加相应的Cache服务器即可。

      三种水平扩展方式的比较：

      2、数据库层的水平扩展。相对于应用服务器层的水平扩展，数据库层的水平扩展更难实现。实现数据库的水平扩展也有多种方式：
      a.数据库的垂直切分：将不同的功能模块所涉及的表划分到不同的物理数据库中，从而将对这些表的访问压力分担到多个不同的物理数据库中。
      b.数据库的读/写分离：同一个数据库在多个物理服务器上具有多份Copy，彼此同步。然后将对于数据库的写操作都统一到一个主服务器上，而读操作则分摊到多台从服务器上。通过读/写分离，实现数据库访问压力的分担。
      c.数据库的水平切分：将原来存储在一个数据表中的数据，按照一定的规则，切分到多个不同的物理数据库中。每个数据库的数据结构完全相同，但是数据各不相同。最终对于业务数据的访问，会根据其数据所在的数据库，定位到某一个数据库中查询。

      2.1、数据库的垂直切分。尽管数据库的垂直切分是最容易想到的，但对于大部分应用而言，除非模块间的关联很少，否则要实现垂直切分也不容易：
      a.原本可能存在的表连接，需要想办法去除。
      b.原本同一个数据库的事务操作，可能会变成跨库事务。可见数据库的垂直切分是一个可以适当采用，但很难广泛采用的数据库层扩展技术。

      2.2、数据库的读/写分离技术。对于读多写少的互联网应用，会广泛采用读/写分离技术。尽管Slave Database Server数量是可以线性扩展的，但是基于以下两个原因，Slave Database Server也不是越多越好。
      a.如果应用读/写比例不是很悬殊，单纯增加Slave Database Server对于应用性能提升并且没有特别的作用，通常情况下，Slave Server的数量与读/写比例对应。
      b.Slave Database Server过多可能造成Master-Slave之间的同步性能降低。

      2.3、数据库的水平切分。无论数据库的垂直切分还是读/写分离，对于实现数据库层的水平扩展，适用范围都比较狭窄。数据库的水平切分，通常有两种处理方式：
      a.一种是采用Hash算法。采用Hash算法实现更为简单，性能也高，但是扩展性略差。因为Hash算法一开始就确定，如果后面变更的话，会涉及数据的迁移。
      b.另一种是将对应到哪个物理数据库也作为关系表存储在集中式的租户数据库中。这种方式更为常见。在用户登录时，通过查询相应的关系表，即可以确定其对应租房的业务数据存储在具体的哪个物理数据库中。

      三种数据库层的水平扩展方案对比：