High Availability and High Performance Server Side
54 likes4,429 views
文档讨论了高可用性和高性能服务器端架构的设计原则，包括持续运营、系统扩展、数据库架构和会话管理。强调利用无状态应用服务器、Redis和适当的负载均衡策略来提高系统容错能力和性能，同时提出了防止数据不一致的问题解决方案。总结了有效备份和异步API的必要性，以提高系统响应速度和用户体验。
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 和系統架構，能支 持同時在線５萬人中型系統，別輕易使用各式各樣的 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 演講結束