High Availability and High Performance Server Side
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 和系統架構,能支
持同時在線5萬人中型系統,別輕易使用各式各樣的 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 ,而無需知道之
前的通訊歷史。分流器可以用便宜很多的電腦
● 系統可根據使用量動態加/減AS數量
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)
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
演講結束