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.另一種是將對應到哪個物理數據庫也作為關系表存儲在集中式的租戶數據庫中。這種方式更為常見。在用戶登錄時，通過查詢相應的關系表，即可以確定其對應租房的業務數據存儲在具體的哪個物理數據庫中。

      三種數據庫層的水平擴展方案對比：