《大規模web服務開發技術》筆記

前段時間趁空把《大規模web服務開發技術》這本書看完了，今天用一下午時間從新翻了一遍，把其中的要點記了下來，權當複習和備忘。因爲本身對數據壓縮、全文檢索等還算比較熟，因此筆記內容主要涉及前5章內容，後面的零星記了一些。本文可能對以下人士比較有幫助：一、對這本書有興趣，但對內容存疑的；二、對大規模Web服務有必定經驗的，可對照着查漏補缺。

Hatena的規模(2010年4月)

• 註冊用戶150w，UU1900w/月

• 請求數：幾十億/月

• 繁忙時流量：850Mbps（不含圖像）

• 硬件（服務器）600臺，經過虛擬化技術，主機超過1300臺

• 日誌天天幾GB級別，數據庫GB到TB級別

系統增加的戰略

• 最小化開端、預見變化的管理和設計

平衡效率和質量

• 開會、規範化、文檔、敏捷等

GB級別（千萬）的文本數據庫，不用索引，一句select查詢200s也未能執行完

內存和硬盤的速度差別

• 尋址：前者是後者的10w到100w倍
• 傳輸速度（總線）：前者——7.5G/s，後者——58M/s

找尋單機瓶頸（用足單機的性能，不要推測，要測量）

• sar或vmstat查看是CPU問題仍是IO問題

• 如果CPU問題
• top或sar查看是系統進程仍是用戶程序
• ps查看進程狀態和cpu使用狀況，肯定問題進程
• 用strace或oprofile找出程序或進程的具體問題所在

• 如果IO問題
• 發生頻繁頁交換--->內存不足
• ps查看程序所用內存
• 可否改善程序，減小內存佔用
• 不行增長硬件或分佈式
• 若無，則多是緩存的內存不夠
• 增長內存
• 不行就增長機器，分佈式

CPU擴展比較方便，但IO負載的擴展比較困難

• 查看實際負載：top結果中的load average（1分鐘 5分鐘 15分鐘）

• 查看是IO負載太高仍是CPU負載太高：sar -P（多核）

 

處理大規模技術的重點

• 儘可能在內存中進行，可實現分佈式，利用局部性

• 算法的複雜度，O(n) --> O(logn)有質的飛躍

• 數據壓縮和檢索技術

緩存機制

• 頁面緩存（page cache）
• 現代操做系統均採用虛擬內存
• 內核分配過的內存會盡可能留下來，下次無需訪問磁盤，即頁面緩存
• 操做系統以頁爲單位緩存，即虛擬內存的最小單位
• 增長內存可提升緩存的命中率，下降IO負載

• sar命令
• sar -r 便可查看當前的內存狀態（kbbuffered緩存使用的物理內存大小）
• sar  1 3 一秒1次，總共3次
• sar -u 查看CPU使用率
• sar -q 查看平均負載
• sar -r 查看內存使用狀況

下降IO負載的策略

1. 提升緩存，即加內存

2. 擴展到多臺服務器

3. 2實際可能未提升緩存命中率（每臺機器的數據不變），須要切分（Partition）數據

切分（Partition）——利用局部性的分佈式

• 以RDBMS的表爲單位

• 從數據中間切分
• a-c服務器1，d-f服務器2……
• 一致性哈希

• 按用途將系統分紅不一樣的「島」
• 爬蟲
• 圖像API
• 通常訪問

以頁面緩存爲基礎的基本運維規則

• 操做系統啓動時不要立刻投入生產環境，要先預熱，即讀一遍全部文件
• 性能測試要在緩存優化後進行

 

數據庫橫向擴展策略

靈活應用操做系統緩存

• 儘可能讓數據庫大小小於物理內存

• 考慮表的結構設計對數據庫大小的影響

創建索引

• B+樹

• 提升搜索效率（logn），改善磁盤尋道次數

• MySQL的explain命令幫助查看索引是否有效

MySQL的分佈式

• master/slave設計（master更新，slave讀）
• 查詢能夠擴展（slave）
• 但master沒法擴展（數據一致性）
• 但Web應用大多數狀況下90%都是讀取查詢
• master的負載可經過分庫分表或更換實現方法來解決

MySQL的Partition

• 將聯繫不緊密的表放在不一樣機器上

• 避免對不一樣機器上表進行JOIN操做
• 使用INNER JOIN或where...in…
• 使用自定義的ORM

• Partition的代價
• 運維變得複雜，故障率上升，成本上升

• 實現冗餘化最少須要多少臺機器
• 4臺——1臺master，3臺slave
• 3臺slave中，一臺用於提供持續服務，一臺可能會故障，最後一臺用於故障後複製

 

Web服務的基礎設施重視的三點

1. 低成本、高效率
• 不該追求100%可靠性

2. 設計很重要
• 可擴展性和響應時間

3. 開發速度很重要
• Web服務常常添加或更改功能，需爲服務提供靈活的資源

 

一臺服務器能處理的流量極限

• Hatena標準服務器：4核CPU，8G內存；

• 性能：繁忙時每分鐘幾千請求

• 若4核CPU*2，32G內存
• 100w~200wPV/月

調優

• 掌握負載
• 服務器監控工具

 

冗餘性與系統穩定性

master的冗餘化

• multi-master
• 一般有兩臺服務器，組成Active/Standby結構
• 一臺是Active的，另外一臺Standby
• 兩臺服務器互爲slave，一方的寫入數據傳入另一方，雙向replication
• 當Standby經過VRRP協議發現Active停機，則Standby自動提高爲Active，變成新的master
• Active服務器有個虛擬ip，將此ip分配給哪臺機器，哪臺機器就是Active的master
• 缺點
• 仍是有不一致的風險

系統的穩定性

• 資源應都保留必定餘量，只用到70%左右

• 去除不穩定因素（儘可能自動化處理）
• 規定SQL負載上限
• 減小內存泄露，遇到可自動重啓
• 異常行爲的自律控制
• 自動DOS判斷
• 自動重啓
• 自動終止耗時查詢

 

虛擬化技術

• 好處
• 可擴展性
• 將額外開銷降至最低
• 動態遷移
• 性價比
• 提升資源利用率
• 提升運維的靈活程度
• 軟件層面的主機控制
• 高可用性
• 環境隔離

• Hatena的虛擬化應用
• Xen（CentOS 5.2、Xen 3.0.3）+ 本地磁盤構建LVM
• 用HyperVisor替代IPMI
• 使用準虛擬化（ParaVirtualization）
• 控制資源消耗
• 負載太高時警告
• 調整負載
• 檢測工具：monit
• 提升資源利用率
• CPU空閒 --> Web服務器
• IO空閒 --> 數據庫服務器
• 內存空閒 --> 緩存服務器
• 避免消耗傾向相同的組合在一塊兒
• 虛擬化的額外開銷
• CPU：2%~3%
• 內存性能：10%
• 網絡性能：50%
• IO性能：5%

SSD的壽命

• 損耗程度指標：S.M.A.R.T值中的E9（Media Wearout Indicator）---> smartctl命令

• Hatena寫入最頻繁的SSD用了9個月左右

 

網絡的分界點

• 1Gbps，即30wpps，是PC路由器的極限（1Gbps是千兆以太網的界限，30wpps是Linux內核的極限）
• 對策：多個PC路由，購買昂貴成品路由

• 500臺主機，是子網、ARP表的極限
• 對策：對網絡進行層次化

 

RDBMS仍是k-v存儲

• 判斷依據
• 平均數據大小
• 最大數據大小
• 新數據增長頻率
• 更新頻率
• 刪除頻率
• 訪問頻率

• MyISAM vs. InnoDB
• MyISAM
• 優勢
• 未經update、delete的表也能快速insert
• 啓動、中止十分迅速
• 表移動、更名稱可直接從文件系統中操做
• 缺點
• 異常中止可能會損壞表
• 不支持事務
• update、delete、insert（追加數據以外）會鎖表，在更新較多的應用中性能很差
• 適合場景
• 只有數據追加
• 使用SELECT COUNT(*)
• InnoDB
• 優勢
• 支持事務
• 異常中止恢復
• 數據更新時執行行鎖定
• 缺點
• 啓動、中止慢
• 表操做徹底經過數據庫
• 適合場景
• 更新頻率高
• 須要事務

• 分佈式k-v
• memcached
• TokyoTyrant

 

緩存系統

• Squid
• 用做HTTP、HTTPS、FTP等多種（反向）代理
• 訪問控制、認證功能

• Varnish
• 高性能HTTP加速器
• 靈活的設置語言
• 基本徹底在內存中執行
• 速度比Squid快

• nginx、pound……
• 緩存服務器上線時注意
• 兩臺負載均衡時，一臺故障會致使另外一臺沒法承受負載
• 備足服務器
• 即便備足服務器也要注意
• 新服務器（或剛啓動）要預熱，流量從小到大慢慢增大