《高性能網站構建實戰》筆記

Linux集羣簡介：

一、高可用集羣：Turbolinux,TurboHA

二、負載均衡集羣：Linux Virtual Server,TurboLinux Cluster Server。

三、超級計算機集羣：任務片式，並行計算方式

 

硬件負載

做爲啓動器，設備形式多樣。

將負載均衡功能置於交換設備中，置於服務器與internet間，如Alteon,ArrowPoint

運用兩塊網絡適配器將這一功能集成到計算機中，其中一塊鏈接到前端止於web服務器的交換機上，另外一塊經過路由器或其它設備鏈接到internet上。如Coyote Point,F5 Networks以及HydraWeb。

 

軟件負載均衡

DNS輪詢：最先的負載均衡是經過DNS輪詢實現的,在DNS配置多個A記錄。

代理服務器

 

LVS+Keepalive環境

前端負載均衡機：direct server(DR)、後端實際服務器:real server(RS)、IP虛擬服務軟件IPVS（IP Virtual Server）

IPVS軟件實現了3種IP負載均衡技術，大體原理：

NAT(VS/NAT) 網絡地址轉換（network address translation）

經過網絡地址轉換，調度器重寫請求報文的目標地址，根據預設調度算法，將請求分發到後端真實服務器

IP Tunneling(VS/TUN)

調度器把請求報文經過IP隧道發送給真實服務器，而真實服務器將響應直接返回給客戶

Direct Routing(VS/DR)

經過改寫用戶請求報文中的MAC地址，將請求發給真實服務器，再由真實服務器將響應直接返回給客戶

 

LVS幾種經常使用算法：

輪詢、加權輪詢、最少鏈接、加權最少鏈接、基於局部性的最少鏈接、帶複製的基於局部性的最少鏈接、目標地址散列等

 

Keepalive是咱們平時說的第三層、四層、五層交換。檢測服務器故障，若是有死機或工做故障，keepalive會檢測到並將其從系統中剔除。當服務器正常後，keepalive再將服務器加入到服務器羣中。主要用於real server健康檢測以及loadbalance主機和Backup主機之間的failover實現。

 

LVS/DR模式網絡拓補

VRRP塊

實例狀態state

 

Lvs Cluter多臺LVS服務器安裝方案

http://my.oschina.net/lxcong/blog/143904

 

服務器架構：

負載均衡服務器：2臺（LVS+Keepalive）

WEB服務器（Nginx+PHP）：4臺

數據庫服務器（MySql一主兩從）：3臺

 

HAProxy高性能負載均衡器

Nginx服務器做負載均衡

 

 

頁面緩存：內存緩存、文件緩存

Squid：普通代理、透明代理（使用iptables實現）、反向代理

        Sarg日誌分析工具

 

Varnish:目前還不能加速https。基於內存的緩存，比基於文件（硬盤）的效率高

 

 

Nginx:輕量級。須要加載第三方模塊（nginx_cache_purge用於清除指定緩存）

 

 

 

 

WEB服務器

Apache，最新穩定版2.4.17

--enable-so指明編譯動態加載模塊（DSO）；

--enable-mods-shared=<MODULE-LIST>指定DSO編譯的模塊，all指有，more大多數，也可羅列模塊名以空格分開。

--with-mpm=<MPM>。MPM有：worker,prefork,mpm_os2,beos,event。

   Prefork是unix機上默認。沒有線程，只有主線程根據須要開闢子線程。系統穩定性高。

   Worker是支持多線程多進程混合模型的MPM，能夠處理海量請求，但系統開銷小於prefork，所以建議使用worker。

一、      日誌切割apache自帶的rotatelogs小工具。

二、      GZIP模塊。Apache兩種算法mod_gzip（壓縮比高）和mod_deflate（壓縮速度快）。Mime類型根據實際狀況添加，至於PDF,JPEG自己就是高壓縮的，重複壓縮意義不大，還會形成服務器負擔。

三、      簡單防DDOS攻擊：Mod_dosevasive。

四、      多線程下載抵禦：Mod_limitipconn模塊。設置客戶端IP最大鏈接數。

 

Nginx:關閉空主機頭

 

 

 

 

NOSQL

NoSQL特色：

一、      數據高併發讀寫。傳統關係型支撐10000併發讀還行，若是是寫，磁盤I/O沒法承受。普通的BBS站都面臨着高併發寫請求。

二、      海量數據的存儲。如一個SNS站一個月用戶動態信息達到2.5億條。大型WEB網站的登錄系統，例如騰訊、盛大數以億計的帳號，關係數據庫難以應付。

三、      高可擴展和高可用。

 

Memcached

複製功能：repcached用以實現一主一從,且主從均可複製。

監控工具：自身的stats命令查看。也可用memcache-top小工具和Memcache.php

Redis

4種數據類型：string字符串、list雙向鏈表（push,pop）,set(多集合求交併差),zset。

監控工具：自身的stats命令查看。也可用memcache-top小工具和Memcache.php

 

 

分佈式文件存儲數據庫

MongoDB適用場景

 

主從配置：master,slave

MongoDB管理工具:Mongostat,profile(相似於mysql的showlog)，自帶的web控制檯

 

 

分佈式文件系統

若是是創業公司, 建議使用雲服務, 阿里雲OSS 或者 七牛 比較不錯, 儘可能把時間和精力花在業務上。但若是以爲必定要花些時間去作本身的分佈式文件系統, 並且是偏向於存儲小型文件的話, 下面是我瞭解到的:

Swift openstack 子產品. 此產品以 amazon s3 爲假想競爭對手作的

GridFS mongo 社區的

Gluster 背後是 redhat 公司

TFS 淘寶本身開源的

Mogilefs memcached 那公司弄的(?)

HDFS:Hadoop簡化的GFS

GFS：GOOGLE弄的

 

單處理器單用戶的本地文件系統（如DOS文件系統）；

多處理器單用戶的本地文件系統（如OS/2文件系統）；

多處理器多用戶的本地文件系統，如UNIX本地文件系統；

多處理器多用戶的分佈式文件系統，如Lustre文件系統

 

本地文件系統，處理器經過系統總線直接訪問物理存儲資源。

分佈式文件系統，文件管理系統管理的物理資源不必定在本地節點，而是經過網絡鏈接。

 

採用哪一種方案，須要運維人員進行選型。備選方案以下：

1、GOOGLE文件系統GFS:

GFSClient： 應用程序的訪問接口

Master（主控服務器）：管理節點，在邏輯上只有一個（還有一臺「影子服務器「，在主控服務器失效時提供元數據，但並非完整的熱備服務器），保存系統的元數據，負責整個文件系統的管理。

Chunk Server（數據庫服務器）：負責具體的存儲工做，數據以文件的形式存儲在Chunk Server上；相應GFS客戶端的讀寫請求。

好處：管理相對簡單

壞處：不少服務請求都通過主控服務器，容易成爲整個系統的瓶頸；可能存在單點失效問題。

 

二、HDFS

 

是Hadoop中的大規模分佈式文件系統，在整個架構上與GFS大體相同，更簡化，好比同一時刻只容許一個客戶端對文件進行追加寫操做。

它具備如下幾個特色：

1）適合存儲很是大的文件

2）適合流式數據讀取，即適合「只寫一次，讀屢次」的數據處理模式

3）適合部署在廉價的機器上

但HDFS不適合如下場景（任何東西都要分兩面看，只有適合本身業務的技術纔是真正的好技術）：

1）不適合存儲大量的小文件，由於受Namenode內存大小限制

2）不適合實時數據讀取，高吞吐量和實時性是相悖的，HDFS選擇前者

3）不適合須要常常修改數據的場景

 

 

總體架構

由NameNode，DataNode，Secondary NameNode以及客戶端組成。

 

監控系統

Cacti概述

Cacti是一套基於PHP,MySQL,SNMP及RRDTool開發的網絡流量監測圖形分析工具。

Cacti和Nagios的監控體系能夠說是使用普遍並且支持豐富的國內外的運維人員都須要掌握的一套監控體系，這套體系的好處在於使用Cacti的強大畫圖和自定義畫圖能力，以及Nagios的可控報警

 

Zabbix企業級分佈式監控系統

zabbix（音同 zæbix）是一個基於WEB界面（和Cacti同樣也是用PHP）的提供分佈式系統監視以及網絡監視功能的企業級的開源解決方案

 

iftop流量監控工具

 

Nmon性能監視和分析工具