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.另一种是将对应到哪个物理数据库也作为关系表存储在集中式的租户数据库中。这种方式更为常见。在用户登录时，通过查询相应的关系表，即可以确定其对应租房的业务数据存储在具体的哪个物理数据库中。

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

将存放在同一个数据库中为同一个应用程序服务的数据分散存放到多个数据库上面，以达到分散单台设备负载的效果，并提高可用性。

2.       垂直切分

按照系统的模块和功能切分。需要尽早作出切分

优点：

•   切分容易

•   应用程序模块清晰，整合容易。
• 数据维护方便。

缺点：

•   模块间的数据表会有关联。
•   数据量大的表仍有性能问题。
•   表关联无法在数据库级别完成，要在程序中完成。
•   事务处理复杂。
• 不能过度切分（粒度适宜）

3.       水平切分

对大数据量的表按照某种规则进行散列拆分。根据社区模块、用户类型、特定字段类别等。

优点：

• 表关联基本能够在数据库端全部完成。
• 不会存在数据过量问题
• 应用程序端整体改动小
• 事务处理简单
• 扩展性限制小

缺点：

• 切分规则复杂，很难有一个全面的切分规则
• 后期数据的维护难度复杂，手工定位数据难
• 应用系统各模块耦合度高，可能会对后面数据拆分造成困难

4.       联合切分

通常先垂直切分，再对大表进行水平切分。

交替进行切分。

优点：

• 系统扩展性最大化
• 避免各自缺陷

缺点：

• 数据库系统架构复杂
• 应用程序架构也复杂
• 整合方案

两种解决方案：

a ）每个应用程序模块中配置管理自己需要的一个或多个数据库，直接访问各个数据库，在模块内整合数据。

b) 通过中间代理层来统一管理数据源，后端数据库集群对前端应用程序透明

实现类别：

      a)         自行开发代理层

      b)        使用数据库 Proxy

如 MySQL 的 Proxy 。实现连接路由、 Query 分析、 Query 过滤和修改，负载均衡，以及基本的 HA 机制。

      c)        其他开源中间件

6.       可能的问题

      a.       分布式事务问题。

——使用小事务，提高应用程序的健壮性。

      b.       跨节点 Join 问题

——使用数据库 Federated （ DB Link 等）

——使用应用程序来处理（使用缓存等）

      c.       跨节点合并排序分页问题

——使用数据库 Federated

——应用程序

当 b 和 c 同时出现时，比较难处理。