介紹如何透過 Scale-Out 分散工作到多台伺服器，涵蓋 RESTful API, Stateless Application Server, Redis, Proxy, Middleware, Database Replication, Job Server, Message Queue Server, 與 Long Polling Server 等主題。 本文為 2014/7/20 於 Mozilla Space 的活動投影片，作者為香港講師 Triton。該活動由 Amigo 擔任 Event Host，Mozilla Taiwan 提供免費空間使用。

1. By Triton Ho@Mar's Potato
High Availability and High Performance
Server Side

2. By Triton Ho@Mar's Potato
關於 Triton Ho
● Mars' Potato 公司建立者之一
● 擁有面對各式各樣的火星爛系統的救火經驗
● 喜歡資料庫
● 喜歡貓
● 出沒於 Hong Kong Linux User Group

3. By Triton Ho@Mar's Potato
重點
● 24*7 系統不等於真的連一分鐘 down time 都不會有
● 你會不會問一個人：「請問你死了嗎？」
● 因為你不知道一個組件是太忙而未能即時回答你。你必
須等待一段時間才知道它是真的掛掉了。
● 如果這是關鍵組件（像 master database ），這段短時
間還是會引起 down time
● 再貴的電腦都有掛的一天，絕對別相信組件不會掛，而
是要準備掛掉後的災難控制。（ Defense-in-depth ）
● 紙和筆永遠是最可信的朋友。全面電子化的香港海關依
然可以用傳真方式的報關。（沒事別亂用）

4. By Triton Ho@Mar's Potato
繼續重點
● Think Big, Be Small ，你應該為你的架構保留未來性。
但是別在開始階段便建立能支持一百萬人的系統
● 當你的系統有一百萬人在線，你肯定有足夠金錢來租到強大
的伺服器（以及找高手來幫忙）
● 正確的 RESTful 設計，和正確的資料庫結構（ database
schema ）最最影響系統效能
● 工程師時薪遠比 CPU 貴！
在系統初期階段， scale-up （改用更貴伺服器）一般比
scale-out （使用能把工作分散到多台伺服器）更具成本效益
● 正確架設的 Postgresql ，配合正確的 API 和系統架構，能支
持同時在線５萬人中型系統，別輕易使用各式各樣的 NoSQL
● Facebook 初期也是使用 MySQL, Instagram 初期使用
PostgreSQL

5. By Triton Ho@Mar's Potato
Basic Architecture
Client Application
Server
Database

6. By Triton Ho@Mar's Potato
Scale-out on Application Server
Client
Stateful
Application
Server
Database
Stateful
Application
Server
Stateful
Application
Server
Stateful
Application
Server
HAproxy
HAProxy Load Balancing:
Source IP / URL Parameter
Stateful
Application
Server

7. By Triton Ho@Mar's Potato
問題在那裡？
● 因為 Application Server （之後簡稱 AS ）是有狀態（因
為用上了 Java 的 HttpSession ，或是 PHP 的
Session ）
● 如果一個客戶端的連線在 AS1 建立了 Session ，那這
客戶端之後的通訊必需只能由 AS1 負責。因為其他
Server 沒有這客戶端的 Session Data
● 分流器（ Load balancer ）必須記錄每一個客戶端對應
的 AS ，大幅吃掉吃掉分流器的 CPU 和 RAM （價值百
萬的分流器便是用在這種地方）
● 要是 AS1 掛掉，在那裡的 Session 會全部掛掉

8. By Triton Ho@Mar's Potato
引起更多問題的解決方案
● 方案一：讓 AS 之間建立溝通渠道，並且建立後備 AS 。讓所
有 Session 都拷貝到後備 AS 上
● 新問題一：這台後備 AS 將會存放全部的 Session ，這台
AS 的 CPU 和 RAM 很快會成為系統瓶頸
● 方案二：建立多於一台後備 AS ，例如： (AS1, 3, 5) 拷貝到
後備 AS-standby1 ， (AS2, 4, 6) 拷貝後備 AS-standby2
● 新問題二：你的 Load Balancer 的 failover rule 設定將會非
常好玩

9. By Triton Ho@Mar's Potato
Scale-out on Application Server
Client
Stateless
Application
Server
Database
Stateful
Application
Server
Stateless
Application
Server
Stateless
Application
Server
HAProxy
HAProxy Load Balancing:
Round Robin
Stateless
Application
Server
Redis DB

10. By Triton Ho@Mar's Potato
Stateless AS 好處
● 因為 AS 是 Stateless ，任何一台 AS 掛掉都無傷大雅
● 在 RESTful 世界中，掛掉的 AS 手上的工作，客戶端會
自動重做
● 分流器可以隨便把工作派到任何一台 AS ，而無需知道之
前的通訊歷史。分流器可以用便宜很多的電腦
● 系統可根據使用量動態加／減ＡＳ數量

11. By Triton Ho@Mar's Potato
為什麼 Redis
● 根據 RESTful 要求， AS 必須 Stateless 的，所以必須找
一個地方存放 Session
● Session 都是短生命期，而且生命期內經常改動的數據，
不同 Session 之間沒任何關聯性，不適合放在主資料庫
● 否則，不管主資料庫是 Postgresql ， MySQL 還是
Oracle ，主資料庫管理者都肯定把你五馬分屍
● Redis 把資料都放在 RAM ，一定比放在 SSD/HDD 的主
資料庫更快
● Redis 比 memcached 支援更多功能，除了存放短期數
據，還可以用作：
● 簡單版的 Message Queue Server
● 簡單版的 Explicit Locking Server

12. By Triton Ho@Mar's Potato
HA on database
Client
Stateless
Application
Server
Database
(Master)
Stateless
Application
Server
Stateless
Application
Server
HAProxy
HAProxy Load Balancing:
Round Robin
Stateless
Application
Server
Redis DB
(Master)
Redis DB
(Slave)
pgpool
pgpool
pgpool
pgpool
Database
(replica)
Database
(replica)

13. By Triton Ho@Mar's Potato
資料庫 HA 重點
● 同一機箱內的 HDD / SSD 是好兄弟，不求同年同月同日
生，但會同年同月同日死
● RAID 1 只保護到單一硬碟故障，對於小動物闖入機箱
／電源故障／在機房打翻泡麵的工程師引起的全硬碟掛
掉， RAID 1 無能為力
● 不過還是需要 RAID 1
● 強烈不建議 RAID 0 和 RAID 5
● 所以，主資料庫需要有後備資料庫來支援，以及定期的
DVD ／磁帶備份

14. By Triton Ho@Mar's Potato
pgpool 重點
● 一個 AS 與資料庫之間的中間件（ middleware ）
● 讓軟件層不用知道底層資料庫的狀態下，自動把
READ-ONLY 交易給後後備資料庫來處理，把
READ+WRITE 交易給主資料庫來處理
● 建議與 AS 放到同一台伺服器內。不管那台伺服
器上的 AS 還是 pgpool 掛掉，一律當作二者都掛
掉而不工作派到這台伺服器

15. By Triton Ho@Mar's Potato
同步與非同步備份
● 同步備份＝在資料庫處理 commit 時，必須先等待資料也
送到後備資料庫，才向客戶端回答「成功了」
● 好處一：所有 committed transaction 一定不會流失
● 好處二：不會 incoherent data problem （詳見接下來的
0.5 秒悲劇）
● 壞處：很慢，特別是主資料庫和後備資料庫不是放在同
一地方時

16. By Triton Ho@Mar's Potato
0.5 秒的悲劇
● 主角絕對不是我！
● 某豬哥工程師在系統中向女生說：「我愛你，你也愛我
嗎？」，在等待回應時，豬哥還定下了每秒自動重新載
入
● 女生回答「我也愛你耶！」，豬哥也看到了
● 然後豬哥再重新載入網頁時，「我也愛你耶！」的狀態
不見了！
● 豬哥以為女生刪掉訊息玩弄他的感情，把電腦砸掉也把
把女生聯絡刪掉
● 其實只要再次重新載入，那段訊息便會重新出現

17. By Triton Ho@Mar's Potato
0.5 秒的悲劇原因
● 因為系統在使用非同步備份，同時讓後備資料庫
處理 READ-ONLY 的要求
● 女生回答「我也愛你耶！」時，最新資料只存在
於主資料庫，還未傳送到後備資料庫
● 豬哥看到「我也愛你耶！」，資料是來自主資料
庫
● 之後 0.5 秒豬哥看不到訊息，資料來自後備資料
庫

18. By Triton Ho@Mar's Potato
如何避免 0.5 秒的悲劇
● 告白請當面進行。（你收過發錯目標的好人卡嗎？）
● 方案一：高關注度數據只使用主資料庫來讀取，不使用
後備資料庫
● 方案二：使用同步備份（不建議）
● 方案三：使用 HTTP 的 conditional GET
● 方案四：把短期性，高關注度數據不放在主資料庫，放
到 Redis

19. By Triton Ho@Mar's Potato
HA on load balancer
Client
Stateless
Application
Server
Database
(Master)
Stateless
Application
Server
Stateless
Application
Server
HA
Proxy1
DNS Load Balancing:
Round Robin
HAProxy Load Balancing:
Round Robin
Stateless
Application
Server
Redis DB
(Master)
Redis DB
(Slave)
pgpool
pgpool
pgpool
pgpool
Database
(replica)
Database
(replica)
HAProxy2
HAProxy1

20. By Triton Ho@Mar's Potato
分流器 HA
● 避免 single point of failure
● 分流器的網絡效能有上限
● OS 中能同時開啟的 TCP/IP 通道有上限
● 所以，使用 round-robin DNS ，讓一個網絡域名
背後有多於一個 IP

21. By Triton Ho@Mar's Potato
Sharding on Short Term DB
Client
Stateless
Application
Server
Database
(Master)
Stateless
Application
Server
Stateless
Application
Server
HA
Proxy1
DNS Load Balancing:
Round Robin
HAProxy Load Balancing:
Round Robin
Stateless
Application
Server
Redis DB1
(Master)
Redis DB1
(Slave)
pgpool
pgpool
pgpool
pgpool
Database
(replica)
Database
(replica)
HAProxy2
HAProxy1
Coherent Short Term DB
Redis DB2
(Master)
Redis DB3
(Master)
Redis DB2
(Slave)
Redis DB3
(Slave)

22. By Triton Ho@Mar's Potato
Sharding on Short Term DB
● Sharding 只應天上有，人間能得幾回聞
● 工程師的時間成本比 CPU 的貴上太多（雖然主
管從來不這麼想）
● 未用上 64GB / 128GB RAM 的伺服器
前， Sharding 不合成本效益
● 要是你公司的伺服器最多只能使用 8GB
RAM ，請認真思考要轉換跑道
● 動態增減 Shard 是超級痛苦
● Consistent hash 會有大幅幫助，但是還是很痛

23. By Triton Ho@Mar's Potato
Add Reporting Module
Client
Stateless
Application
Server
Database
(Master)
Stateless
Application
Server
Stateless
Application
Server
Stateless
Application
Server
Redis DB1
(Master)
Redis DB1
(Slave)
pgpool
pgpool
pgpool
pgpool
Database
(replica)
Database
(replica)
Production database
HA
Proxy1
Coherent Short Term DB
Redis DB2
(Master)
Redis DB3
(Master)
Redis DB2
(Slave)
Redis DB3
(Slave)
HA
Proxy2
ETL engine
Reporting
DB
Internal
Reporting
Server

24. By Triton Ho@Mar's Potato
Asynchronous API and Server Push
Client
Stateless
Application
Server
Database
(Master)
Stateless
Application
Server
Stateless
Application
Server
Stateless
Application
Server
Redis DB1
(Master)
Redis DB1
(Slave)
pgpool
pgpool
pgpool
pgpool
Database
(replica)
Database
(replica)
Production database
HA
Proxy1
Coherent Short Term DB
Redis DB2
(Master)
Redis DB3
(Master)
Redis DB2
(Slave)
Redis DB3
(Slave)
HA
Proxy2
MQ server1
Asynchronous Job Server Farm
Job Server
Job Server
Job Server
Job Server
Long
Polling
Server
Long
Polling
Server
RabbitMQ Cluster
MQ server2
MQ server3

25. By Triton Ho@Mar's Potato
非同步 API 例子
● 你在玩暗黑破壞神時，老媽叫你做家務
● 你忙於跟 Azmodan 戰鬥，回答「指令收到了」
● 五一小時後，你終於有空做家務，在你做完家務
後，你回答「做完了」
● 看吧，連三歲小孩都懂得應用 Asynchronous API
和 Server Push （謎之聲：喂！）

26. By Triton Ho@Mar's Potato
非同步 API 重點
● 一些需要大量時間的 API request ，你可以在收到工作後立即
回答「收到了」給客戶端，然後再慢慢處理。這樣，客戶端
便不會在等待期間誤會連線斷掉。
● 非同步工作可以丟到後端 job server ，讓 AS 保留更多 CPU
處理即時性 Request
● 傳統 HTTP 是 Request-Reply 的，伺服器沒法主動告知客戶
端工作進度
● 別在客戶端每三秒問一下：「工作做完了嗎？」，這是浪費
CPU 和網絡數據的行為
（雖然現實中的主管會這麼做）
● 所以你需要 Long-Polling 機制

27. By Triton Ho@Mar's Potato
Long-Polling 重點
● 不建議用 AS 來處理
● 因為會持續吃掉一個 TCP/IP 通道
● 因為會吃掉一個 AS worker thread （註： tomcat 原始
設定是 200 ）
● 遇上 cracker 發出大量 Long-polling 攻擊，會讓所有 AS
的 worker thread 全被吃掉
● 所以，使用像 node.JS 這樣的 Server 來專門處理 Long-
Polling

28. By Triton Ho@Mar's Potato
High Availability and High Performance
Server Side
演講結束