通常會用到 load balance 都會是比較大型一點的架構，假設我們預期一台機器上限是 200 個連線數，今天有一個活動會有千人同時在線，這時候我們有可能有兩種作法
- 垂直拓展，將機器的規格在開大
- 水平拓展，做 load balance 開更多台機器來負載需求
也因為今天開了五台機器，我們希望能夠分流這 1000 人的需求，但不可能讓 DNS 同時對到五台機器，所以在架構上，必須在這五台機器之前架設一台 load balance 的機器來做分流。
設定時有幾個重點
- 設定後端五台機器的 IP，這樣 load balance 才知道要去哪幾台
- 判斷機器是否運作正常，不正常應該排除於服務之外，通常會用 https 連線來判斷
- 對 load balance 做 https 設定
- 設定分流基準，可以用 CPU 或是記憶體用量來判斷後端機器是否忙碌。
作法一: persistence
通常我們在寫程式時，都是以使用者會連到同一台機器上來撰寫的，正常來說，當這個使用者的 session 存在時，我們會將他導到同一台機器，直到 session 失效。
這種分流會遇到的問題是：
當服務請求變的更大時，我們加開的機器，並不會將原本的使用者分流過來，假設目前已經有 1000 人在前面五台機器上，這時候你開了第六台，前面的 1000 人並不會被分流過來，而是第 1001 人才會。
也因為 session 都在固定的機器上，如果今天使用者的 session 在第二台機器上，當第二台機器發生故障被導向第四台的時候，則使用者會被重新登入操錯（可能會覺得很怪）
作法二: affinity
這個作法的彈性好一些，可以根據機器的忙碌程度來決定將使用者導向何處。
那這種作法一樣會有問題發生，例如有使用者透過第一台機器登入了，但因為分流機制將第二個查詢動作給了第五台機器，那第五台機器沒有這個使用者的 session，也就會查不到資料了。
很明顯的，各機器有各自的 session，如果要解決這個問題，就必須設計共有的 session 機制。
Cluster(叢級)
可以將多台 server 連在一起，通常要看使用的伺服器有沒有這個功能，一般來說依照設定就可以完成，也因為叢級功能基本上就有「共用 session」的功能了。
也可以用第三方服務來設計「共用 session」，比方 Memcached、AWS dynamoDB。