The NoteBook of EricKong

嗨心兔是品墨科技自主研發生產的一款智能共享童車，通過物聯網和微信+支付寶小程序實行操作，可實現無人值守、智能消毒、自動計費、自動扣費的新型兒童娛樂設備。加盟熱線400-6151-556

市場前景廣闊

中國統計局數據顯示,截至2018年，我國0-14歲的兒童數量已經達到2.5億人。2018 年兒童消費市場規模突破4.5 萬億，并以每年20%的速度增長,其中兒童娛樂消費市場的規模突破4600億元。

當前，80、90后成為了家長群體中的主力軍時。他們有較好的經濟基礎已經對消費升級的追求，這使得育兒支出水漲船高。 目前我國14歲以下的兒童數量較大，兒童消費已占到家庭總支出的3 0 %左右，其中玩具，童裝又占據著較高的比例。

根據行業研發報告顯示，我國兒童消費規模已經接近4.5萬億元，其中兒童娛樂消費市場的規模突破4600億元。

中共中央政治局5月31日召開會議，會議指出，進一步優化生育政策，實施一對夫妻可以生育三個子女政策及配套支持措施。我國正處于人口大國向人力資本強國轉變的重大戰略機遇期，立足國情，“三孩”政策能夠最大限度發揮人口對經濟社會發展的能動作用。

自二胎政策以來，在人口增長以及產業提升方面，開始有顯著的效果的。二孩政策的開放，促使少兒人口數量的逐漸增加，也會為一些兒童產業經濟帶來相當可觀的市場。更別說三孩政策的開放，更會給兒童經濟市場帶來一個巨大的飛躍。

新風口

嗨心兔共享童車智能柜，作為新型共享經濟的新模式，新風口，大大增加了兒童車的使用選擇、節約了購買成本，還大便利了家長帶娃，更可以增加孩子公平意識，提升社交樂趣，同時也解決很多用戶的痛點：

 市場和痛點:

兒童電動車是孩子最不可缺失的用品之一，也是孩子成長過程中最重要的“玩伴”。但是買一臺放在家里是非常占地方的，現在的樓價那么高，一臺童車占據的面積就差不多一個平方了。按照一二線城市的樓價來計算，家里買一臺童車的場地“租金”是相當高的。孩子“喜新厭舊”,玩具車很快就會“失寵”。買過兒童電動車的家長都會反饋，家里買回來的兒童電動車，只玩了兩次就不完了， 然后就放在那里了。然后想玩第三的時候，發現因為電池長期沒有充電的， 電池就報廢了，已經不能再玩了?，F在的家長對產品的品質要求都比較高，小孩子也是家里的寶貝，給小孩子買的電動兒童車，而且要買一臺質量比較好的電動兒童車，價錢也不低的?，F在家庭都是居住在小區內，對于寶媽來說，兒童電動車搬上搬下也是個特別麻煩的事情。

產品優勢和特點：

廣東品墨科技科技有限自主研發生產的一款智能共享童車，通過物聯網和微信+支付寶小程序實行操作，可實現無人值守、智能消毒、自動計費、自動扣費完美解決了這些問題，項目具備下面幾點優勢：

優勢一:無人值守免人工

傳統童車玩樂需要，人工監管，人工收費，場地大了還得多個人看守，而嗨心兔智能設備無需專人值守,自動計費,自動扣費,一個人可管理幾十個點。由于傳統童車是都是采用定時斷電的方式進行計費，這樣限制了兒童消費的沖動，影響營業收入。

優勢二：占地小租金少

傳統童車玩樂有多少車就需要多大的空地存放, 而嗨心兔共享童車智能柜的方式存放，立體空間,一套設備占地還不到1平米。一套設備可以存放2個童車，極大節省了存放的空間。

優勢三：還車自動充電

傳統童車玩樂專人負責充電,每天隨時隨地得記著，而嗨心兔采用自助充電，還車和充電一氣呵成。不會因為忘記了充電，然后影響了日常的運營。

優勢四：防水防盜防嗮

傳統童車玩樂不防雨不防盜，要是在戶外還得專門找個安全的地方存放，而嗨心兔不但防水，而且防曬，還有設計了安全警報功能,防偷防盜，智能科技呵護你的“搖錢樹”。讓你輕松的賺取睡后的收入。

優勢五：醫用級衛生保證

傳統童車玩樂輪流使用,基本沒有消毒,交叉感染可能性大,而嗨心兔采用醫用級消毒燈,—車一消毒,一次一消毒,為兒童健康提供強大保障。

優勢六：車型多正版授權

傳統童車玩樂只能坐著到處逛， 體驗感一般，而嗨心兔全是正版授權的超拉風車輛，包括但是不限于，蘭博基尼，法拉利，保時捷，賓利，勞斯萊斯這些，小朋友自駕體驗自己操控的樂趣，家長遙控著都感覺有面子。

關鍵是選址

公園

公園人流多，而且地方寬敞，也是家里留守老人帶孩子愛去的地方。所以對于嗨心兔共享童車來說，公園也是投放場地的重點推薦之一。

商場

商場在共享童車行業中毫無疑問是個優質的投放場地。商場人流大，兒童業態在購物中心的一般占比達到19%或以上，是家庭休閑娛樂的好地方。

小區

在住房壓力普遍的現在，特別是在城市，城鎮生活的打工人，尺土寸金，很多家庭室內幾乎沒有孩子騎上童車玩樂的空間。出行的話，又很難放在后備箱中攜帶，搬來搬去也很是不方便。因此小區作為家庭日常生活的場所，在這里投放共享童車是好地方

廣場

廣場，是小孩游玩的集中地。廣場地域寬闊、無車流，備受群眾喜愛，特別是夜晚時有許多父母會帶孩子一起散步，人流量越大，生意的機會就多，這也是嗨心兔共享童車投放區域的一大好選擇。

合作伙伴：

選擇合作伙伴，如同選擇伴侶般重要？首先，價格和成本相對來說，越低越好，這樣你就可以盡快償還成本。第二，要考慮設備的穩定性。要選址產品比較穩定的公司。

最終要是源頭廠家合作，要認真調研他們是不是招商公司，假如是招商公司的話，他們只是賺一筆就走了，真正能給提供服務的源頭還是廠家，但是你簽署合同的是招商公司的話，中間有服務的話，必然也隔了一層，效率必然低下。假如是源頭廠家的話，至少如果遇到問題，可以第一時間找到設計制作這個產品的人。他比任何人都清楚哪里容易出現問題，以及如何解決問題。萬一找個不專業的公司合作，特別是貼牌的招商公司，售后問題就要經過幾層才能解決。不然到時候，你遇到問題一定是瘋了。

而廣東品墨科技有限公司,是一家以物聯網,大數據,人工智能技術為依托的技術和運營推廣公司，技術團隊由來自匯豐,中國電信,華為,廣點通等頂尖企業的資深研發和營銷運營團隊組成！同時，公司還是騰訊廣告的授權的廣告服務商，對全國各地的加盟商的廣告支持是十分到位的。

廣東品墨科技有限公司,是一家專注于專注于智能設備的研發、生產、推廣于一體的企業,我公司自主研發和生成共享童車的控制主板,軟件系統，運營后臺。旗下的嗨心兔品牌專注于兒童業態的無人智能游樂設備領域，通過整合智能設備和物聯網，大數據分析技術，自主研發和設計國內更適應市場需求、更受小朋友喜愛的共享童車智能柜。

全國招商加盟熱線:400-6151-556

共享童車源頭廠家，品質保證，支持各種物聯網系統OEM定制開發

1.wireshark

wireshark安裝
　#yum install wireshark wireshark-gnome
wireshark使用
   #wireshark

2.tcpdump

tcpdump采用命令行方式，它的命令格式為：
    　　tcpdump [ -adeflnNOpqStvx ] [ -c 數量 ] [ -F 文件名 ]
　　　　　　　　　　[ -i 網絡接口 ] [ -r 文件名] [ -s snaplen ]
　　　　　　　　　　[ -T 類型 ] [ -w 文件名 ] [表達式 ]

http://anheng.com.cn/news/24/586.html

(1). tcpdump的選項介紹 
http://anheng.com.cn/news/24/586.html

　　　-a 　　　將網絡地址和廣播地址轉變成名字；
　　　-d 　　　將匹配信息包的代碼以人們能夠理解的匯編格式給出；
　　　-dd 　　 將匹配信息包的代碼以c語言程序段的格式給出；
　　　-ddd 　　將匹配信息包的代碼以十進制的形式給出；
　　　-e 　　　在輸出行打印出數據鏈路層的頭部信息；
　　　-f 　　　將外部的Internet地址以數字的形式打印出來；
　　　-l 　　　使標準輸出變為緩沖行形式；
　　　-n 　　　不把網絡地址轉換成名字；
　　　-t 　　　在輸出的每一行不打印時間戳；
　　　-v 　　　輸出一個稍微詳細的信息，例如在ip包中可以包括ttl和服務類型的信息；
　　　-vv 　　 輸出詳細的報文信息；
　　　-c 　　　在收到指定的包的數目后，tcpdump就會停止；
　　　-F 　　　從指定的文件中讀取表達式,忽略其它的表達式；
　　　-i 　　　指定監聽的網絡接口；
　　　-r 　　　從指定的文件中讀取包(這些包一般通過-w選項產生)；
　　　-w 　　　直接將包寫入文件中，并不分析和打印出來；
　　　-T 　　　將監聽到的包直接解釋為指定的類型的報文，常見的類型有rpc （遠程過程調用）和snmp（簡單網絡管理協議；）

Ethereal和Sniffit兩個網絡分析工具

PS：tcpdump是一個用于截取網絡分組，并輸出分組內容的工具，簡單說就是數據包抓包工具。tcpdump憑借強大的功能和靈活的截取策略，使其成為Linux系統下用于網絡分析和問題排查的首選工具。

tcpdump提供了源代碼，公開了接口，因此具備很強的可擴展性，對于網絡維護和入侵者都是非常有用的工具。tcpdump存在于基本的Linux系統中，由于它需要將網絡界面設置為混雜模式，普通用戶不能正常執行，但具備root權限的用戶可以直接執行它來獲取網絡上的信息。因此系統中存在網絡分析工具主要不是對本機安全的威脅，而是對網絡上的其他計算機的安全存在威脅。

一、概述
顧名思義，tcpdump可以將網絡中傳送的數據包的“頭”完全截獲下來提供分析。它支持針對網絡層、協議、主機、網絡或端口的過濾，并提供and、or、not等邏輯語句來幫助你去掉無用的信息。


# tcpdump -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:53:21.444591 IP (tos 0x10, ttl  64, id 19324, offset 0, flags [DF], proto 6, length: 92) asptest.localdomain.ssh > 192.168.228.244.1858: P 3962132600:3962132652(52) ack 2726525936 win 1266
asptest.localdomain.1077 > 192.168.228.153.domain: [bad udp cksum 166e!]  325+ PTR? 244.228.168.192.in-addr.arpa. (46)
11:53:21.446929 IP (tos 0x0, ttl  64, id 42911, offset 0, flags [DF], proto 17, length: 151) 192.168.228.153.domain > asptest.localdomain.1077:  325 NXDomain q: PTR? 244.228.168.192.in-addr.arpa. 0/1/0 ns: 168.192.in-addr.arpa. (123)
11:53:21.447408 IP (tos 0x10, ttl  64, id 19328, offset 0, flags [DF], proto 6, length: 172) asptest.localdomain.ssh > 192.168.228.244.1858: P 168:300(132) ack 1 win 1266
347 packets captured
1474 packets received by filter
745 packets dropped by kernel


不帶參數的tcpdump會收集網絡中所有的信息包頭，數據量巨大，必須過濾。

二、選項介紹

-A 以ASCII格式打印出所有分組，并將鏈路層的頭最小化。

-c 在收到指定的數量的分組后，tcpdump就會停止。

-C 在將一個原始分組寫入文件之前，檢查文件當前的大小是否超過了參數file_size 中指定的大小。如果超過了指定大小，則關閉當前文件，然后在打開一個新的文件。參數 file_size 的單位是兆字節（是1,000,000字節，而不是1,048,576字節）。

-d 將匹配信息包的代碼以人們能夠理解的匯編格式給出。

-dd 將匹配信息包的代碼以c語言程序段的格式給出。

-ddd 將匹配信息包的代碼以十進制的形式給出。

-D 打印出系統中所有可以用tcpdump截包的網絡接口。

-e 在輸出行打印出數據鏈路層的頭部信息。

-E 用spi@ipaddr algo:secret解密那些以addr作為地址，并且包含了安全參數索引值spi的IPsec ESP分組。

-f 將外部的Internet地址以數字的形式打印出來。

-F 從指定的文件中讀取表達式，忽略命令行中給出的表達式。

-i 指定監聽的網絡接口。

-l 使標準輸出變為緩沖行形式，可以把數據導出到文件。

-L 列出網絡接口的已知數據鏈路。

-m 從文件module中導入SMI MIB模塊定義。該參數可以被使用多次，以導入多個MIB模塊。

-M 如果tcp報文中存在TCP-MD5選項，則需要用secret作為共享的驗證碼用于驗證TCP-MD5選選項摘要（詳情可參考RFC 2385）。

-b 在數據-鏈路層上選擇協議，包括ip、arp、rarp、ipx都是這一層的。

-n 不把網絡地址轉換成名字。

-nn 不進行端口名稱的轉換。

-N 不輸出主機名中的域名部分。例如，‘nic.ddn.mil‘只輸出’nic‘。

-t 在輸出的每一行不打印時間戳。

-O 不運行分組分組匹配（packet-matching）代碼優化程序。

-P 不將網絡接口設置成混雜模式。

-q 快速輸出。只輸出較少的協議信息。

-r 從指定的文件中讀取包(這些包一般通過-w選項產生)。

-S 將tcp的序列號以絕對值形式輸出，而不是相對值。

-s 從每個分組中讀取最開始的snaplen個字節，而不是默認的68個字節。

-T 將監聽到的包直接解釋為指定的類型的報文，常見的類型有rpc遠程過程調用）和snmp（簡單網絡管理協議；）。

-t 不在每一行中輸出時間戳。

-tt 在每一行中輸出非格式化的時間戳。

-ttt 輸出本行和前面一行之間的時間差。

-tttt 在每一行中輸出由date處理的默認格式的時間戳。

-u 輸出未解碼的NFS句柄。

-v 輸出一個稍微詳細的信息，例如在ip包中可以包括ttl和服務類型的信息。

-vv 輸出詳細的報文信息。

-w 直接將分組寫入文件中，而不是不分析并打印出來。

三、tcpdump的表達式介紹

表達式是一個正則表達式，tcpdump利用它作為過濾報文的條件，如果一個報文滿足表 達式的條件，則這個報文將會被捕獲。如果沒有給出任何條件，則網絡上所有的信息包 將會被截獲。

在表達式中一般如下幾種類型的關鍵字：

第一種是關于類型的關鍵字，主要包括host，net，port，例如 host 210.27.48.2， 指明 210.27.48.2是一臺主機，net 202.0.0.0指明202.0.0.0是一個網絡地址，port 23 指明端口號是23。如果沒有指定類型，缺省的類型是host。

第二種是確定傳輸方向的關鍵字，主要包括src，dst，dst or src，dst and src， 這些關鍵字指明了傳輸的方向。舉例說明，src 210.27.48.2 ，指明ip包中源地址是 210.27.48.2 ， dst net 202.0.0.0 指明目的網絡地址是202.0.0.0。如果沒有指明 方向關鍵字，則缺省是src or dst關鍵字。

第三種是協議的關鍵字，主要包括fddi，ip，arp，rarp，tcp，udp等類型。Fddi指明是在FDDI (分布式光纖數據接口網絡)上的特定的網絡協議，實際上它是”ether”的別名，fddi和ether 具有類似的源地址和目的地址，所以可以將fddi協議包當作ether的包進行處理和分析。 其他的幾個關鍵字就是指明了監聽的包的協議內容。如果沒有指定任何協議，則tcpdump 將會 監聽所有協議的信息包。

除了這三種類型的關鍵字之外，其他重要的關鍵字如下：gateway， broadcast，less， greater， 還有三種邏輯運算，取非運算是 ‘not ‘ ‘! ‘， 與運算是’and’，’&&’;或運算是’or’ ，’||’； 這些關鍵字可以組合起來構成強大的組合條件來滿足人們的需要。

四、輸出結果介紹

下面我們介紹幾種典型的tcpdump命令的輸出信息

(1) 數據鏈路層頭信息
使用命令：
#tcpdump --e host ICE
ICE 是一臺裝有linux的主機。它的MAC地址是0：90：27：58：AF：1A H219是一臺裝有Solaris的SUN工作站。它的MAC地址是8：0：20：79：5B：46； 上一條命令的輸出結果如下所示：

21:50:12.847509 eth0 < 8:0:20:79:5b:46 0:90:27:58:af:1a ip 60: h219.33357 > ICE.  telne t 0:0(0) ack 22535 win 8760 (DF)

21：50：12是顯示的時間， 847509是ID號，eth0 <表示從網絡接口eth0接收該分組， eth0 >表示從網絡接口設備發送分組， 8:0:20:79:5b:46是主機H219的MAC地址， 它表明是從源地址H219發來的分組. 0:90:27:58:af:1a是主機ICE的MAC地址， 表示該分組的目的地址是ICE。 ip 是表明該分組是IP分組，60 是分組的長度， h219.33357 > ICE. telnet 表明該分組是從主機H219的33357端口發往主機ICE的 TELNET(23)端口。 ack 22535 表明對序列號是222535的包進行響應。 win 8760表明發 送窗口的大小是8760。

(2) ARP包的tcpdump輸出信息

使用命令：
#tcpdump arp

得到的輸出結果是：

22:32:42.802509 eth0 > arp who-has route tell ICE (0:90:27:58:af:1a)
22:32:42.802902 eth0 < arp reply route is-at 0:90:27:12:10:66 (0:90:27:58:af:1a)

22:32:42是時間戳， 802509是ID號， eth0 >表明從主機發出該分組，arp表明是ARP請求包， who-has route tell ICE表明是主機ICE請求主機route的MAC地址。 0:90:27:58:af:1a是主機 ICE的MAC地址。

(3) TCP包的輸出信息

用tcpdump捕獲的TCP包的一般輸出信息是：

src > dst: flags data-seqno ack window urgent options

src > dst:表明從源地址到目的地址， flags是TCP報文中的標志信息，S 是SYN標志， F (FIN)， P (PUSH) ， R (RST) “.” (沒有標記); data-seqno是報文中的數據 的順序號， ack是下次期望的順序號， window是接收緩存的窗口大小， urgent表明 報文中是否有緊急指針。 Options是選項。

(4) UDP包的輸出信息

用tcpdump捕獲的UDP包的一般輸出信息是：

route.port1 > ICE.port2: udp lenth

UDP十分簡單，上面的輸出行表明從主機route的port1端口發出的一個UDP報文 到主機ICE的port2端口，類型是UDP， 包的長度是lenth。

五、舉例

(1) 想要截獲所有210.27.48.1 的主機收到的和發出的所有的分組：
#tcpdump host 210.27.48.1

(2) 想要截獲主機210.27.48.1 和主機210.27.48.2或210.27.48.3的通信，使用命令（注意：括號前的反斜杠是必須的）：
#tcpdump host 210.27.48.1 and (210.27.48.2 or 210.27.48.3 )

(3) 如果想要獲取主機210.27.48.1除了和主機210.27.48.2之外所有主機通信的ip包，使用命令：
#tcpdump ip host 210.27.48.1 and ! 210.27.48.2

(4) 如果想要獲取主機192.168.228.246接收或發出的ssh包，并且不轉換主機名使用如下命令：
#tcpdump -nn -n src host 192.168.228.246 and port 22 and tcp

(5) 獲取主機192.168.228.246接收或發出的ssh包，并把mac地址也一同顯示：
# tcpdump -e src host 192.168.228.246 and port 22 and tcp -n -nn

(6) 過濾的是源主機為192.168.0.1與目的網絡為192.168.0.0的報頭：
tcpdump src host 192.168.0.1 and dst net 192.168.0.0/24

(7) 過濾源主機物理地址為XXX的報頭：
tcpdump ether src 00:50:04:BA:9B and dst……
（為什么ether src后面沒有host或者net？物理地址當然不可能有網絡嘍）。

(8) 過濾源主機192.168.0.1和目的端口不是telnet的報頭，并導入到tes.t.txt文件中：
Tcpdump src host 192.168.0.1 and dst port not telnet -l > test.txt

ip icmp arp rarp 和 tcp、udp、icmp這些選項等都要放到第一個參數的位置，用來過濾數據報的類型。

例題：如何使用tcpdump監聽來自eth0適配卡且通信協議為port 22，目標來源為192.168.1.100的數據包資料？

答：tcpdump -i eth0 -nn port 22 and src host 192.168.1.100

例題：如何使用tcpdump抓取訪問eth0適配卡且訪問端口為tcp 9080？

答:tcpdump -i eth0 dst 172.168.70.35 and tcp port 9080

例題：如何使用tcpdump抓取與主機192.168.43.23或著與主機192.168.43.24通信報文，并且顯示在控制臺上

tcpdump -X -s 1024 -i eth0 host (192.168.43.23 or 192.168.43.24) and  host 172.16.70.35

Linux系統出現了性能問題，一般我們可以通過top、iostat、free、vmstat等命令來查看初步定位問題。其中iostat可以給我們提供豐富的IO狀態數據。

1. 基本使用

$iostat -d -k 1 10

參數 -d 表示，顯示設備（磁盤）使用狀態；-k某些使用block為單位的列強制使用Kilobytes為單位；1 10表示，數據顯示每隔1秒刷新一次，共顯示10次。

$iostat -d -k 1 10
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              39.29        21.14         1.44  441339807   29990031
sda1              0.00         0.00         0.00       1623        523
sda2              1.32         1.43         4.54   29834273   94827104
sda3              6.30         0.85        24.95   17816289  520725244
sda5              0.85         0.46         3.40    9543503   70970116
sda6              0.00         0.00         0.00        550        236
sda7              0.00         0.00         0.00        406          0
sda8              0.00         0.00         0.00        406          0
sda9              0.00         0.00         0.00        406          0
sda10            60.68        18.35        71.43  383002263 1490928140

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             327.55      5159.18       102.04       5056        100
sda1              0.00         0.00         0.00          0          0

tps：該設備每秒的傳輸次數（Indicate the number of transfers per second that were issued to the device.）。“一次傳輸”意思是“一次I/O請求”。多個邏輯請求可能會被合并為“一次I/O請求”。“一次傳輸”請求的大小是未知的。

kB_read/s：每秒從設備（drive expressed）讀取的數據量；kB_wrtn/s：每秒向設備（drive expressed）寫入的數據量；kB_read：讀取的總數據量；kB_wrtn：寫入的總數量數據量；這些單位都為Kilobytes。

上面的例子中，我們可以看到磁盤sda以及它的各個分區的統計數據，當時統計的磁盤總TPS是39.29，下面是各個分區的TPS。（因為是瞬間值，所以總TPS并不嚴格等于各個分區TPS的總和）

2. -x 參數

使用-x參數我們可以獲得更多統計信息。

iostat -d -x -k 1 10
Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          1.56  28.31  7.80 31.49   42.51    2.92    21.26     1.46     1.16     0.03    0.79   2.62  10.28
Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          2.00  20.00 381.00  7.00 12320.00  216.00  6160.00   108.00    32.31     1.75    4.50   2.17  84.20

rrqm/s：每秒這個設備相關的讀取請求有多少被Merge了（當系統調用需要讀取數據的時候，VFS將請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的數據，FS會將這個請求合并Merge）；wrqm/s：每秒這個設備相關的寫入請求有多少被Merge了。

rsec/s：每秒讀取的扇區數；wsec/：每秒寫入的扇區數。r/s：The number of read requests that were issued to the device per second；w/s：The number of write requests that were issued to the device per second；

await：每一個IO請求的處理的平均時間（單位是微秒毫秒）。這里可以理解為IO的響應時間，一般地系統IO響應時間應該低于5ms，如果大于10ms就比較大了。

%util：在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該設備有0.8秒在處理IO，而0.2秒閑置，那么該設備的%util = 0.8/1 = 80%，所以該參數暗示了設備的繁忙程度。一般地，如果該參數是100%表示設備已經接近滿負荷運行了（當然如果是多磁盤，即使%util是100%，因為磁盤的并發能力，所以磁盤使用未必就到了瓶頸）。

3. -c 參數

iostat還可以用來獲取cpu部分狀態值：

iostat -c 1 10
avg-cpu:  %user   %nice    %sys %iowait   %idle
           1.98    0.00    0.35   11.45   86.22
avg-cpu:  %user   %nice    %sys %iowait   %idle
           1.62    0.00    0.25   34.46   63.67

4. 常見用法

$iostat -d -k 1 10        #查看TPS和吞吐量信息
iostat -d -x -k 1 10      #查看設備使用率（%util）、響應時間（await）
iostat -c 1 10            #查看cpu狀態

5. 實例分析

$$iostat -d -k 1 |grep sda10
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn   
sda10            60.72        18.95        71.53  395637647 1493241908
sda10           299.02      4266.67       129.41       4352        132
sda10           483.84      4589.90      4117.17       4544       4076
sda10           218.00      3360.00       100.00       3360        100
sda10           546.00      8784.00       124.00       8784        124
sda10           827.00     13232.00       136.00      13232        136

上面看到，磁盤每秒傳輸次數平均約400；每秒磁盤讀取約5MB，寫入約1MB。

iostat -d -x -k 1
Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda          1.56  28.31  7.84 31.50   43.65    3.16    21.82     1.58     1.19     0.03    0.80   2.61  10.29
sda          1.98  24.75 419.80  6.93 13465.35  253.47  6732.67   126.73    32.15     2.00    4.70   2.00  85.25
sda          3.06  41.84 444.90 54.08 14204.08 2048.98  7102.04  1024.49    32.57     2.10    4.21   1.85  92.24

可以看到磁盤的平均響應時間<5ms，磁盤使用率>80。磁盤響應正常，但是已經很繁忙了。

參考文獻：

1. Linux man iostat
2. How Linux iostat computes its results
3. Linux iostat

一般對負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術。具體的應用需求還得具體分析，如果是中小型的Web應用，比如日PV小于1000萬，用Nginx就完全可以了；如果機器不少，可以用DNS輪詢，LVS所耗費的機器還是比較多的；大型網站或重要的服務，且服務器比較多時，可以考慮用LVS。

AD：

PS：Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件，本人都在多個項目中實施過，參考了一些資料，結合自己的一些使用經驗，總結一下。

一般對負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術。具體的應用需求還得具體分析，如果是中小型的Web應用，比如日PV小于1000萬，用Nginx就完全可以了；如果機器不少，可以用DNS輪詢，LVS所耗費的機器還是比較多的；大型網站或重要的服務，且服務器比較多時，可以考慮用LVS。

一種是通過硬件來進行進行，常見的硬件有比較昂貴的F5和Array等商用的負載均衡器，它的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對于規模較小的網絡服務來說暫時還沒有需要使用；另外一種就是類似于Nginx/LVS/HAProxy的基于Linux的開源免費的負載均衡軟件，這些都是通過軟件級別來實現，所以費用非常低廉。

目前關于網站架構一般比較合理流行的架構方案：Web前端采用Nginx/HAProxy+Keepalived作負載均衡器；后端采用MySQL數據庫一主多從和讀寫分離，采用LVS+Keepalived的架構。當然要根據項目具體需求制定方案。

下面說說各自的特點和適用場合。

Nginx的優點是：

1、工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構，它的正則規則比HAProxy更為強大和靈活，這也是它目前廣泛流行的主要原因之一，Nginx單憑這點可利用的場合就遠多于LVS了。

2、Nginx對網絡穩定性的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢之一；相反LVS對網絡穩定性依賴比較大，這點本人深有體會；

3、Nginx安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日志打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。

3、可以承擔高負載壓力且穩定，在硬件不差的情況下一般能支撐幾萬次的并發量，負載度比LVS相對小些。

4、Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而不滿。

5、Nginx不僅僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。LNMP也是近幾年非常流行的web架構，在高流量的環境中穩定性也很好。

6、Nginx現在作為Web反向加速緩存越來越成熟了，速度比傳統的Squid服務器更快，可以考慮用其作為反向代理加速器。

7、Nginx可作為中層反向代理使用，這一層面Nginx基本上無對手，唯一可以對比Nginx的就只有lighttpd了，不過lighttpd目前還沒有做到Nginx完全的功能，配置也不那么清晰易讀，社區資料也遠遠沒Nginx活躍。

8、Nginx也可作為靜態網頁和圖片服務器，這方面的性能也無對手。還有Nginx社區非?；钴S，第三方模塊也很多。

Nginx的缺點是：

1、Nginx僅能支持http、https和Email協議，這樣就在適用范圍上面小些，這個是它的缺點。

2、對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。不支持Session的直接保持，但能通過ip_hash來解決。

LVS：使用Linux內核集群實現一個高性能、高可用的負載均衡服務器，它具有很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。

LVS的優點是：

1、抗負載能力強、是工作在網絡4層之上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件里的性能最強的，對內存和cpu資源消耗比較低。

2、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率。

3、工作穩定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived，不過我們在項目實施中用得最多的還是LVS/DR+Keepalived。

4、無流量，LVS只分發請求，而流量并不從它本身出去，這點保證了均衡器IO的性能不會收到大流量的影響。

5、應用范圍比較廣，因為LVS工作在4層，所以它幾乎可以對所有應用做負載均衡，包括http、數據庫、在線聊天室等等。

LVS的缺點是：

1、軟件本身不支持正則表達式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優勢所在。

2、如果是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較復雜了，特別后面有Windows Server的機器的話，如果實施及配置還有維護過程就比較復雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

HAProxy的特點是：

1、HAProxy也是支持虛擬主機的。

2、HAProxy的優點能夠補充Nginx的一些缺點，比如支持Session的保持，Cookie的引導；同時支持通過獲取指定的url來檢測后端服務器的狀態。

3、HAProxy跟LVS類似，本身就只是一款負載均衡軟件；單純從效率上來講HAProxy會比Nginx有更出色的負載均衡速度，在并發處理上也是優于Nginx的。

4、HAProxy支持TCP協議的負載均衡轉發，可以對MySQL讀進行負載均衡，對后端的MySQL節點進行檢測和負載均衡，大家可以用LVS+Keepalived對MySQL主從做負載均衡。

5、HAProxy負載均衡策略非常多，HAProxy的負載均衡算法現在具體有如下8種：

① roundrobin，表示簡單的輪詢，這個不多說，這個是負載均衡基本都具備的；

② static-rr，表示根據權重，建議關注；

③ leastconn，表示最少連接者先處理，建議關注；

④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制類似，我們用其作為解決session問題的一種方法，建議關注；

⑤ ri，表示根據請求的URI；

⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name；

⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；

⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定并哈希每一次TCP請求。

Nginx和LVS對比的總結：

1、Nginx工作在網絡的7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下LVS并不具備這樣的功能，所以Nginx單憑這點可利用的場合就遠多于LVS了；但Nginx有用的這些功能使其可調整度要高于LVS，所以經常要去觸碰觸碰，觸碰多了，人為出問題的幾率也就會大。

2、Nginx對網絡穩定性的依賴較小，理論上只要ping得通，網頁訪問正常，Nginx就能連得通，這是Nginx的一大優勢！Nginx同時還能區分內外網，如果是同時擁有內外網的節點，就相當于單機擁有了備份線路；LVS就比較依賴于網絡環境，目前來看服務器在同一網段內并且LVS使用direct方式分流，效果較能得到保證。另外注意，LVS需要向托管商至少申請多一個ip來做Visual IP，貌似是不能用本身的IP來做VIP的。要做好LVS管理員，確實得跟進學習很多有關網絡通信方面的知識，就不再是一個HTTP那么簡單了。

3、Nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日志打印出來。LVS的安裝和配置、測試就要花比較長的時間了；LVS對網絡依賴比較大，很多時候不能配置成功都是因為網絡問題而不是配置問題，出了問題要解決也相應的會麻煩得多。

4、Nginx也同樣能承受很高負載且穩定，但負載度和穩定度差LVS還有幾個等級：Nginx處理所有流量所以受限于機器IO和配置；本身的bug也還是難以避免的。

5、Nginx可以檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節點。目前LVS中 ldirectd也能支持針對服務器內部的情況來監控，但LVS的原理使其不能重發請求。比如用戶正在上傳一個文件，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能會因此而惱火。

6、Nginx對請求的異步處理可以幫助節點服務器減輕負載，假如使用apache直接對外服務，那么出現很多的窄帶鏈接時apache服務器將會占用大 量內存而不能釋放，使用多一個Nginx做apache代理的話，這些窄帶鏈接會被Nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相當多的資源占用。這點使用squid也有相同的作用，即使squid本身配置為不緩存，對apache還是有很大幫助的。

7、Nginx能支持http、https和email（email的功能比較少用），LVS所支持的應用在這點上會比Nginx更多。在使用上，一般最前端所采取的策略應是LVS，也就是DNS的指向應為LVS均衡器，LVS的優點令它非常適合做這個任務。重要的ip地址，最好交由LVS托管，比如數據庫的 ip、webservice服務器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給 LVS托管是最為穩妥的，這樣做的唯一缺點是需要的VIP數量會比較多。Nginx可作為LVS節點機器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所遜色于Nginx。Nginx也可作為中層代理使用，這一層面Nginx基本上無對手，唯一可以撼動Nginx的就只有lighttpd了，不過lighttpd目前還沒有能做到 Nginx完全的功能，配置也不那么清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個VIP和LVS是最完美的方案了。具體的應用還得具體分析，如果是比較小的網站（日PV小于1000萬），用Nginx就完全可以了，如果機器也不少，可以用DNS輪詢，LVS所耗費的機器還是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用LVS。

現在對網絡負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術：

第一階段：利用Nginx或HAProxy進行單點的負載均衡，這一階段服務器規模剛脫離開單服務器、單數據庫的模式，需要一定的負載均衡，但是仍然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx或HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協議就可以。這時是第一選擇。

第二階段：隨著網絡服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用Array就是首要選擇，Nginx此時就作為LVS或者Array的節點來使用，具體LVS或Array的是選擇是根據公司規模和預算來選擇，Array的應用交付功能非常強大，本人在某項目中使用過，性價比也遠高于F5，商用首選！但是一般來說這階段相關人才跟不上業務的提升，所以購買商業負載均衡已經成為了必經之路。

第三階段：這時網絡服務已經成為主流產品，此時隨著公司知名度也進一步擴展，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定制，以及降低成本來講開源的LVS，已經成為首選，這時LVS會成為主流。

最終形成比較理想的基本架構為：Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。

原文鏈接：http://www.ha97.com/5646.html

【編輯推薦】

1、date --help

%% 輸出%符號 a literal %
%a 當前域的星期縮寫 locale’s abbreviated weekday name (Sun..Sat)
%A 當前域的星期全寫 locale’s full weekday name, variable length (Sunday..Saturday)
%b 當前域的月份縮寫 locale’s abbreviated month name (Jan..Dec)
%B 當前域的月份全稱 locale’s full month name, variable length (January..December)
%c 當前域的默認時間格式 locale’s date and time (Sat Nov 04 12:02:33 EST 1989)
%C n百年 century (year divided by 100 and truncated to an integer) [00-99]
%d 兩位的天 day of month (01..31)
%D 短時間格式 date (mm/dd/yy)
%e 短格式天 day of month, blank padded ( 1..31)
%F 文件時間格式 same as %Y-%m-%d
%g the 2-digit year corresponding to the %V week number
%G the 4-digit year corresponding to the %V week number
%h same as %b
%H 24小時制的小時 hour (00..23)
%I 12小時制的小時 hour (01..12)
%j 一年中的第幾天 day of year (001..366)
%k 短格式24小時制的小時 hour ( 0..23)
%l 短格式12小時制的小時 hour ( 1..12)
%m 雙位月份 month (01..12)
%M 雙位分鐘 minute (00..59)
%n 換行 a newline
%N 十億分之一秒 nanoseconds (000000000..999999999)
%p 大寫的當前域的上下午指示 locale’s upper case AM or PM indicator (blank in many locales)
%P 小寫的當前域的上下午指示 locale’s lower case am or pm indicator (blank in many locales)
%r 12小時制的時間表示（時:分:秒,雙位） time, 12-hour (hh:mm:ss [AP]M)
%R 24小時制的時間表示 （時:分,雙位）time, 24-hour (hh:mm)
%s 自基礎時間 1970-01-01 00:00:00 到當前時刻的秒數 seconds since `00:00:00 1970-01-01 UTC’ (a GNU extension)
%S 雙位秒 second (00..60); the 60 is necessary to accommodate a leap second
%t 橫向制表位(tab) a horizontal tab
%T 24小時制時間表示 time, 24-hour (hh:mm:ss)
%u 數字表示的星期（從星期一開始 1-7）day of week (1..7); 1 represents Monday
%U 一年中的第幾周星期天為開始 week number of year with Sunday as first day of week (00..53)
%V 一年中的第幾周星期一為開始 week number of year with Monday as first day of week (01..53)
%w 一周中的第幾天 星期天為開始 0-6 day of week (0..6); 0 represents Sunday
%W 一年中的第幾周星期一為開始 week number of year with Monday as first day of week (00..53)
%x 本地日期格式 locale’s date representation (mm/dd/yy)
%X 本地時間格式 locale’s time representation (%H:%M:%S)
%y 兩位的年 last two digits of year (00..99)
%Y 年 year (1970…)
%z RFC-2822 標準時間格式表示的域 RFC-2822 style numeric timezone (-0500) (a nonstandard extension)
%Z 時間域 time zone (e.g., EDT), or nothing if no time zone is determinable

By default, date pads numeric fields with zeroes. GNU date recognizes
the following modifiers between `%’ and a numeric directive.

`-’ (hyphen) do not pad the field
`_’ (underscore) pad the field with spaces

--------------------------------------------------------------------------------

2、一些用法

1）#以yymmdd的格式輸出43天前的當前時刻

date +%Y%m%d --date='43 days ago'       

2）# 測試十億分之一秒
date +’%Y%m%d %H:%M:%S.%N’;date +’%Y%m%d %H:%M:%S.%N’;date +’%Y%m%d %H:%M:%S.%N’;date +’%Y%m%d %H:%M:%S.%N’

3）#創建以當前時間為文件名的目錄
mkdir `date +%Y%m%d`

4）#備份以時間做為文件名的
tar -cvf ./htdocs`date +%Y%m%d`.tar ./*

5）#顯示時間后跳行，再顯示目前日期 

date +%T%n%Y%m%d

6）#只顯示月份與日數 

date +%B%d

7）#獲取上周日期（day,month,year,hour）

date -d "-1 week" +%Y%m%d 　　

8）#獲取24小時前日期

date --date="-24 hour" +%Y%m%d

9）#shell腳本里面賦給變量值

date_now=`date +%s`

10）#計算執行一段sql腳本的運行時間

TIME_BEGIN=$(date '+%s.%N')
$sqlcli < queries/q1.3.sql 1>> $FILE_RESULT  2>> $FILE_ERROR
TIME_END=$(date '+%s.%N')
TIME_RUN=$(awk 'BEGIN{print '$TIME_END' - '$TIME_BEGIN'}')

11）#編寫shell腳本計算離自己生日還有多少天？

    read -p "Input your birthday(YYYYmmdd):" date1

　　m=`date --date="$date1" +%m`    #得到生日的月

　　d=`date --date="$date1" +%d`    #得到生日的日

　　date_now=`date +%s`             #得到當前時間的秒值

　　y=`date +%Y`                    #得到當前時間的年

　　birth=`date --date="$y$m$d" +%s`      #得到今年的生日日期的秒值

　　internal=$(($birth-$date_now))        #計算今日到生日日期的間隔時間

　　if [ "$internal" -lt "0" ]; then             #判斷今天的生日是否已過

　　birth=`date --date="$(($y+1))$m$d" +%s`      #得到明天的生日日期秒值

　　internal=$(($birth-$date_now))               #計算今天到下一個生日的間隔時間

　　fi

　　echo "There is :$((einternal/60/60/24)) days."       #輸出結果，秒換算為天

12）#若是不以加號作為開頭，則表示要設定時間，而時間格式為 MMDDhhmm[[CC]YY][.ss]，

其中 MM 為月份，

DD 為日，

hh 為小時，

mm 為分鐘，

CC 為年份前兩位數字，

YY 為年份后兩位數字，

ss 為秒數

13）

#顯示目前的格林威治時間，也叫“世界時”。是英國的標準時間，也是世界各地時間的參考標準。中英兩國的標準時差為8個小時，即英國的當地時間比中國的北京時間晚8小時。

date -u              
Thu Sep 28 09:32:04 UTC 2006

14）#修改時間

date -s
按字符串方式修改時間
可以只修改日期,不修改時間,輸入: date -s 2007-08-03
只修改時間,輸入:date -s 14:15:00
同時修改日期時間,注意要加雙引號,日期與時間之間有一空格,輸入:date -s "2007-08-03 14:15:00"

修改完后,記得輸入:clock -w
把系統時間寫入CMOS

增加GC相關選項：

-verbose:gc
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=512K
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/var/app/log/Push-server/gc.log

1. 如果不能確定所需內存，使用自動jvm自動調優；
2. 大致確定所需內存后，使用-Xmx -Xms設置堆大??；
3. 觀察GC log確定FullGC后剩余堆大?。礊榛钴S數據大?。?；
4. 整個堆大小宜為老年代活躍數據大小的3-4倍；
5. 永久帶大小應該比永久帶活躍數據大1.2~1.5倍；
6. 新生代空間應該為老年代空間活躍數據的1~1.5倍；
7. 通過top命令觀察棧占用空間、直接內存占用空間，決定所需機器內存大??；
8. 新生代大小決定了Minor GC的周期和時長，縮短新生代大小可以減少停頓時長，但是增加了GC頻率；在調整新生代大小時，盡量保持老年代大小不變；
9. 老年代大小不應該小于活躍數據的1.5倍；新生代空間至少為java堆大小的10%；增加堆大小時，注意不要超過可用物理內存數；
10. 從throughput收集器遷移到CMS時，需要將老年代空間增加20%~30%；
11. 新生代分為Eden和Survivor兩部分，Survivor可以通過-XX:SurvivorRatio=xx來控制，對應的大小為-Xmn<value>/(ratio+2)；
12. 通過-XX:MaxTenuringThreshold=<n>來指定晉升閾值（年齡），n為0~15之間；
13. 期望Survivor空間為剩余總存活對象大小的2倍(age=1；
14. 注意調節Survivor大小時，保持Eden大小不變；
15. 如果Survivor空間足夠大，且對象大部分并未到達老年代，那么就可以將晉升年紀指定的足夠大（15）。在Eden與Survivor之間復制和CMS老年代空間壓縮之間，我們寧愿選擇前者；
16. CMS必須能以對象從新生代提升到老年代的同等速度對老年代中的對象進行收集，否則，就會失速；
17. 如果觀察到'concurrent mode failures'，意味著失速已經發生，必須減少-XX:CMSInitiatingOccupancyFraction=<percent>的值；
18. 使用上述選項的同時，最好同時使用-XX:+UseCMSInitiatingOccupancyOnly，強制使用該比例,該比例的大小應該大于老年代占用空間和活躍數據大小之比，一般而言老年代大小*該比例>1.5*老年代活躍數據大小；
19. 使用-XX:+ExplicitGCInvokesConcurrentAndUnloadsCloasses可以使用CMS進行顯式垃圾回收（System.gc())；通過-XX:+DisableExplicitGC關閉顯示垃圾回收（慎用）；
20. 使用-XX:+CMSClassUnloadingEnabled打開永久帶垃圾回收，使用-XX:+CMSPermGenSweepingEnabled打開CMS對永久帶的掃描；使用-XX:CMSInitiatingPermOccupancyFraction=<perscent>激活回收比例閾值；
21. 使用-XX:ParallelGCThreads=<n>控制掃描線程數；使用-XX:+CMSScavengeBeforeRemark強制重新標記前進行一次MinorGC；如果由大量的引用對象或可終結對象要處理，使用-XX:+ParallelRefProcEnabled；
22. CMS包括Minor GC所帶來的開銷應該小于10%；
23. 如果缺少長時間調優的條件，安全起見，可以使用G1，僅設置如下參數即可：

-d64
-Xmx5g
-Xms5g
-XX:PermSize=100m
-XX:MaxPermSize=100m
-XX:MaxDirectMemorySize=1g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=80

G1不必明確設置新生代大小，其自動調優也十分可靠，對于停頓時間往往在長時間運行后可以達到預期效果；對吞吐量優先的應用，可能不是那么明顯。

linux系統中，我們稱之為traceroute,在MS Windows中為tracert。 traceroute通過發送小的數據包到目的設備直到其返回，來測量其需要多長時間。一條路徑上的每個設備traceroute要測3次。輸出結果中包括每次測試的時間(ms)和設備的名稱（如有的話）及其IP地址。

在大多數情況下，我們會在linux主機系統下，直接執行命令行：traceroute hostname

而在Windows系統下是執行tracert的命令： tracert hostname

1.命令格式：

traceroute[參數][主機]

2.命令功能：

traceroute指令讓你追蹤網絡數據包的路由途徑，預設數據包大小是40Bytes，用戶可另行設置。

具體參數格式：traceroute [-dFlnrvx][-f<存活數值>][-g<網關>...][-i<網絡界面>][-m<存活數值>][-p<通信端口>][-s<來源地址>][-t<服務類型>][-w<超時秒數>][主機名稱或IP地址][數據包大小]

3.命令參數：

-d 使用Socket層級的排錯功能。

-f 設置第一個檢測數據包的存活數值TTL的大小。

-F 設置勿離斷位。

-g 設置來源路由網關，最多可設置8個。

-i 使用指定的網絡界面送出數據包。

-I 使用ICMP回應取代UDP資料信息。

-m 設置檢測數據包的最大存活數值TTL的大小。

-n 直接使用IP地址而非主機名稱。

-p 設置UDP傳輸協議的通信端口。

-r 忽略普通的Routing Table，直接將數據包送到遠端主機上。

-s 設置本地主機送出數據包的IP地址。

-t 設置檢測數據包的TOS數值。

-v 詳細顯示指令的執行過程。

-w 設置等待遠端主機回報的時間。

-x 開啟或關閉數據包的正確性檢驗。

4.使用實例：

實例1：traceroute 用法簡單、最常用的用法

命令：traceroute www.baidu.com

輸出：
[root@localhost ~]# traceroute www.baidu.com
traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets
1 192.168.74.2 (192.168.74.2) 2.606 ms 2.771 ms 2.950 ms
2 211.151.56.57 (211.151.56.57) 0.596 ms 0.598 ms 0.591 ms
3 211.151.227.206 (211.151.227.206) 0.546 ms 0.544 ms 0.538 ms
4 210.77.139.145 (210.77.139.145) 0.710 ms 0.748 ms 0.801 ms
5 202.106.42.101 (202.106.42.101) 6.759 ms 6.945 ms 7.107 ms
6 61.148.154.97 (61.148.154.97) 718.908 ms * bt-228-025.bta.net.cn (202.106.228.25) 5.177 ms
7 124.65.58.213 (124.65.58.213) 4.343 ms 4.336 ms 4.367 ms
8 202.106.35.190 (202.106.35.190) 1.795 ms 61.148.156.138 (61.148.156.138) 1.899 ms 1.951 ms
9 * * *
30 * * *
[root@localhost ~]#

說明：

記錄按序列號從1開始，每個紀錄就是一跳 ，每跳表示一個網關，我們看到每行有三個時間，單位是 ms，其實就是-q的默認參數。探測數據包向每個網關發送三個數據包后，網關響應后返回的時間；如果您用 traceroute -q 4 www.58.com ，表示向每個網關發送4個數據包。

有時我們traceroute 一臺主機時，會看到有一些行是以星號表示的。出現這樣的情況，可能是防火墻封掉了ICMP的返回信息，所以我們得不到什么相關的數據包返回數據。

有時我們在某一網關處延時比較長，有可能是某臺網關比較阻塞，也可能是物理設備本身的原因。當然如果某臺DNS出現問題時，不能解析主機名、域名時，也會 有延時長的現象；您可以加-n 參數來避免DNS解析，以IP格式輸出數據。

如果在局域網中的不同網段之間，我們可以通過traceroute 來排查問題所在，是主機的問題還是網關的問題。如果我們通過遠程來訪問某臺服務器遇到問題時，我們用到traceroute 追蹤數據包所經過的網關，提交IDC服務商，也有助于解決問題；但目前看來在國內解決這樣的問題是比較困難的，就是我們發現問題所在，IDC服務商也不可能幫助我們解決。

實例2：跳數設置

命令：traceroute -m 10 www.baidu.com

輸出：
[root@localhost ~]# traceroute -m 10 www.baidu.com
traceroute to www.baidu.com (61.135.169.105), 10 hops max, 40 byte packets
1 192.168.74.2 (192.168.74.2) 1.534 ms 1.775 ms 1.961 ms
2 211.151.56.1 (211.151.56.1) 0.508 ms 0.514 ms 0.507 ms
3 211.151.227.206 (211.151.227.206) 0.571 ms 0.558 ms 0.550 ms
4 210.77.139.145 (210.77.139.145) 0.708 ms 0.729 ms 0.785 ms
5 202.106.42.101 (202.106.42.101) 7.978 ms 8.155 ms 8.311 ms
6 bt-228-037.bta.net.cn (202.106.228.37) 772.460 ms bt-228-025.bta.net.cn (202.106.228.25) 2.152 ms 61.148.154.97 (61.148.154.97) 772.107 ms
7 124.65.58.221 (124.65.58.221) 4.875 ms 61.148.146.29 (61.148.146.29) 2.124 ms 124.65.58.221 (124.65.58.221) 4.854 ms
8 123.126.6.198 (123.126.6.198) 2.944 ms 61.148.156.6 (61.148.156.6) 3.505 ms 123.126.6.198 (123.126.6.198) 2.885 ms
9 * * *
10 * * *
[root@localhost ~]#

實例3：顯示IP地址，不查主機名

命令：traceroute -n www.baidu.com

輸出：
[root@localhost ~]# traceroute -n www.baidu.com
traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets
1 211.151.74.2 5.430 ms 5.636 ms 5.802 ms
2 211.151.56.57 0.627 ms 0.625 ms 0.617 ms
3 211.151.227.206 0.575 ms 0.584 ms 0.576 ms
4 210.77.139.145 0.703 ms 0.754 ms 0.806 ms
5 202.106.42.101 23.683 ms 23.869 ms 23.998 ms
6 202.106.228.37 247.101 ms * *
7 61.148.146.29 5.256 ms 124.65.58.213 4.386 ms 4.373 ms
8 202.106.35.190 1.610 ms 61.148.156.138 1.786 ms 61.148.3.34 2.089 ms
9 * * *
30 * * *
[root@localhost ~]# traceroute www.baidu.com
traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets
1 211.151.74.2 (211.151.74.2) 4.671 ms 4.865 ms 5.055 ms
2 211.151.56.57 (211.151.56.57) 0.619 ms 0.618 ms 0.612 ms
3 211.151.227.206 (211.151.227.206) 0.620 ms 0.642 ms 0.636 ms
4 210.77.139.145 (210.77.139.145) 0.720 ms 0.772 ms 0.816 ms
5 202.106.42.101 (202.106.42.101) 7.667 ms 7.910 ms 8.012 ms
6 bt-228-025.bta.net.cn (202.106.228.25) 2.965 ms 2.440 ms 61.148.154.97 (61.148.154.97) 431.337 ms
7 124.65.58.213 (124.65.58.213) 5.134 ms 5.124 ms 5.044 ms
8 202.106.35.190 (202.106.35.190) 1.917 ms 2.052 ms 2.059 ms
9 * * *
30 * * *
[root@localhost ~]#

實例4：探測包使用的基本UDP端口設置6888

命令：traceroute -p 6888 www.baidu.com
[root@localhost ~]# traceroute -p 6888 www.baidu.com
traceroute to www.baidu.com (220.181.111.147), 30 hops max, 40 byte packets
1 211.151.74.2 (211.151.74.2) 4.927 ms 5.121 ms 5.298 ms
2 211.151.56.1 (211.151.56.1) 0.500 ms 0.499 ms 0.509 ms
3 211.151.224.90 (211.151.224.90) 0.637 ms 0.631 ms 0.641 ms
4 * * *
5 220.181.70.98 (220.181.70.98) 5.050 ms 5.313 ms 5.596 ms
6 220.181.17.94 (220.181.17.94) 1.665 ms !X * *
[root@localhost ~]#

實例5：把探測包的個數設置為值4

命令：traceroute -q 4 www.baidu.com

 
[root@localhost ~]# traceroute -q 4 www.baidu.com
traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets
1 211.151.74.2 (211.151.74.2) 40.633 ms 40.819 ms 41.004 ms 41.188 ms
2 211.151.56.57 (211.151.56.57) 0.637 ms 0.633 ms 0.627 ms 0.619 ms
3 211.151.227.206 (211.151.227.206) 0.505 ms 0.580 ms 0.571 ms 0.569 ms
4 210.77.139.145 (210.77.139.145) 0.753 ms 0.800 ms 0.853 ms 0.904 ms
5 202.106.42.101 (202.106.42.101) 7.449 ms 7.543 ms 7.738 ms 7.893 ms
6 61.148.154.97 (61.148.154.97) 316.817 ms bt-228-025.bta.net.cn (202.106.228.25) 3.695 ms 3.672 ms *
7 124.65.58.213 (124.65.58.213) 3.056 ms 2.993 ms 2.960 ms 61.148.146.29 (61.148.146.29) 2.837 ms
8 61.148.3.34 (61.148.3.34) 2.179 ms 2.295 ms 2.442 ms 202.106.35.190 (202.106.35.190) 7.136 ms
9 * * * *
30 * * * *
[root@localhost ~]#

實例6：繞過正常的路由表，直接發送到網絡相連的主機

命令：traceroute -r www.baidu.com

輸出：
[root@localhost ~]# traceroute -r www.baidu.com
traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets
connect: 網絡不可達
[root@localhost ~]#

實例7：把對外發探測包的等待響應時間設置為3秒

命令：traceroute -w 3 www.baidu.com

輸出：

[root@localhost ~]# traceroute -w 3 www.baidu.com
traceroute to www.baidu.com (61.135.169.105), 30 hops max, 40 byte packets
1 211.151.74.2 (211.151.74.2) 2.306 ms 2.469 ms 2.650 ms
2 211.151.56.1 (211.151.56.1) 0.621 ms 0.613 ms 0.603 ms
3 211.151.227.206 (211.151.227.206) 0.557 ms 0.560 ms 0.552 ms
4 210.77.139.145 (210.77.139.145) 0.708 ms 0.761 ms 0.817 ms
5 202.106.42.101 (202.106.42.101) 7.520 ms 7.774 ms 7.902 ms
6 bt-228-025.bta.net.cn (202.106.228.25) 2.890 ms 2.369 ms 61.148.154.97 (61.148.154.97) 471.961 ms
7 124.65.58.221 (124.65.58.221) 4.490 ms 4.483 ms 4.472 ms
8 123.126.6.198 (123.126.6.198) 2.948 ms 61.148.156.6 (61.148.156.6) 7.688 ms 7.756 ms
9 * * *
30 * * *
[root@localhost ~]#

Traceroute的工作原理：

Traceroute最簡單的基本用法是：traceroute hostname

Traceroute程序的設計是利用ICMP及IP header的TTL（Time To Live）欄位（field）。首先，traceroute送出一個TTL是1的IP datagram（其實，每次送出的為3個40字節的包，包括源地址，目的地址和包發出的時間標簽）到目的地，當路徑上的第一個路由器（router）收到這個datagram時，它將TTL減1。此時，TTL變為0了，所以該路由器會將此datagram丟掉，并送回一個「ICMP time exceeded」消息（包括發IP包的源地址，IP包的所有內容及路由器的IP地址），traceroute 收到這個消息后，便知道這個路由器存在于這個路徑上，接著traceroute 再送出另一個TTL是2 的datagram，發現第2 個路由器...... traceroute 每次將送出的datagram的TTL 加1來發現另一個路由器，這個重復的動作一直持續到某個datagram 抵達目的地。當datagram到達目的地后，該主機并不會送回ICMP time exceeded消息，因為它已是目的地了，那么traceroute如何得知目的地到達了呢？

Traceroute在送出UDP datagrams到目的地時，它所選擇送達的port number 是一個一般應用程序都不會用的號碼（30000 以上），所以當此UDP datagram 到達目的地后該主機會送回一個「ICMP port unreachable」的消息，而當traceroute 收到這個消息時，便知道目的地已經到達了。所以traceroute 在Server端也是沒有所謂的Daemon 程式。

Traceroute提取發 ICMP TTL到期消息設備的IP地址并作域名解析。每次 ，Traceroute都打印出一系列數據,包括所經過的路由設備的域名及 IP地址,三個包每次來回所花時間。

windows之tracert:

格式：

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

參數說明：

tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name

該診斷實用程序通過向目的地發送具有不同生存時間 (TL) 的 Internet 控制信息協議 (CMP) 回應報文，以確定至目的地的路由。路徑上的每個路由器都要在轉發該 ICMP 回應報文之前將其 TTL 值至少減 1，因此 TTL 是有效的跳轉計數。當報文的 TTL 值減少到 0 時，路由器向源系統發回 ICMP 超時信息。通過發送 TTL 為 1 的第一個回應報文并且在隨后的發送中每次將 TTL 值加 1，直到目標響應或達到最大 TTL 值，Tracert 可以確定路由。通過檢查中間路由器發發回的 ICMP 超時 (ime Exceeded) 信息，可以確定路由器。注意，有些路由器“安靜”地丟棄生存時間 (TLS) 過期的報文并且對 tracert 無效。

參數：

-d 指定不對計算機名解析地址。

-h maximum_hops 指定查找目標的跳轉的最大數目。

-jcomputer-list 指定在 computer-list 中松散源路由。

-w timeout 等待由 timeout 對每個應答指定的毫秒數。

target_name 目標計算機的名稱。

實例：

之前有做過lvs+keepalived來實現高可用?？墒乾F在nginx已經用到了很多公司的web服務器上，并且也表現出優良的性能。
那么在架構中，nginx放在前端用作負載均衡和處理靜態頁面以及緩存，是一個很重要的位置，必須要保證nginx服務器的高可用，
今天簡單介紹下用nginx+keepalived來實現nginx服務器的高可用,即實現故障自動切換。

環境：
主nginx服務器:192.168.2.117
備nginx服務器:192.168.0.170
VIP:192.168.2.114
nginx服務器的安裝和配置在此不做介紹，不會的話可以參考：

http://www.linuxyan.com/web-server/6.html

1、keepalived安裝(在主和備2臺nginx服務器上都安裝)

wget http://www.keepalived.org/software/keepalived-1.2.2.tar.gz
tar xzf keepalived-1.2.2.tar.gz
cd keepalived-1.2.2
./configure –prefix=/usr/local/keepalived
make && make install
cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
chmod +x /etc/init.d/keepalived
mkdir /etc/keepalived
ln -s /usr/local/keepalived/sbin/keepalived /usr/sbin/

然后對主nginx服務器的keepalived進行配置
vi /etc/keepalived/keepalived.conf
global_defs {
notification_email {
admin@centos.bz               #接收警報的email地址,可以添加多個
}
notification_email_from keepalived@domain.com   ###發件人地址
smtp_server 127.0.0.1          ###發送郵件的服務器
smtp_connect_timeout 30      ###超時時間
router_id LVS_DEVEL      ####load balancer 的標識 ID,用于email警報
}
vrrp_script chk_http_port {
script “/opt/nginx_pid.sh” ####檢測nginx狀態的腳本路徑
interval 2
weight 2
}
vrrp_instance VI_1 {
state MASTER ############ 輔機為 BACKUP
interface eth0 ####HA 監測網絡接口
virtual_router_id 51 #主、備機的 virtual_router_id 必須相同
mcast_src_ip 192.168.2.117 ###本機IP地址
priority 102 ########### 權值要比 back 高
advert_int 1 #主備之間的通告間隔秒數
authentication {
auth_type PASS ###主備切換時的驗證
auth_pass 1111
}
track_script {
chk_http_port ### 執行監控的服務
}
virtual_ipaddress {
192.168.2.114 ####vip的地址
}
}

備nginx服務器上配置
global_defs {
notification_email {
admin@centos.bz
}
notification_email_from keepalived@domain.com
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id LVS_DEVEL
}
vrrp_script chk_http_port {
script “/opt/nginx_pid.sh” ##檢測nginx狀態的腳本
interval 2
weight 2
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51 #### 保持主從服務器一致
mcast_src_ip 192.168.0.170 ###本機的IP地址
priority 101 ##########權值 要比 master 低。。
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
track_script {
chk_http_port ### 執行監控的服務
}
virtual_ipaddress {
192.168.2.114 ###vip的地址
}
}

之后分別在主從服務器建立nginx的監控腳本：
vi /opt/nginx_pid.sh
#!/bin/bash
A=`ps -C nginx –no-header |wc -l`
if [ $A -eq 0 ];then
/usr/local/nginx/sbin/nginx ##這個地方寫你nginx命令的路徑
sleep 3
if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
killall keepalived
fi
fi

配置好之后，分別在2臺服務器上啟動nginx和keepalived
/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
/etc/init.d/keepalived start

在主nginx服務器上執行ip a
[root@localhost ~]# ip a
1: lo: mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:58:58:5f brd ff:ff:ff:ff:ff:ff
inet 192.168.2.117/22 brd 192.168.3.255 scope global eth0
inet 192.168.2.114/32 scope global eth0
inet6 fe80::20c:29ff:fe58:585f/64 scope link
valid_lft forever preferred_lft forever
3: sit0: mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
可以看到2.114這個vip已經綁定在主nginx服務器上了,這個時候把nginx停掉
[root@localhost ~]# killall nginx
[root@localhost ~]# ps aux |grep nginx
root 9175 0.0 0.3 43268 916 ? Ss 05:45 0:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx 9176 0.0 0.5 43648 1468 ? S 05:45 0:00 nginx: worker process
root 9187 0.0 0.2 61180 716 pts/0 R+ 05:45 0:00 grep nginx
額額，，，怎么停不掉，，，，
注意看監控nginx的腳本,當腳本檢測到nginx沒有運行的時候，會嘗試啟動一次，如果啟動成功，則不轉移vip。如果啟動失敗，則把keepalived停掉，從機的keepalived會把vip綁定到備nginx服務器上，這個時候就是備nginx的服務器在提供服務了。
為了看下效果，暫且把這個腳本修改一下，不讓他嘗試啟動nginx服務
這個時候把nginx服務停掉，我們用ip a來看下vip是否還在主nginx服務器上綁定著
[root@localhost ~]# ip a
1: lo: mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:58:58:5f brd ff:ff:ff:ff:ff:ff
inet 192.168.2.117/22 brd 192.168.3.255 scope global eth0
inet6 fe80::20c:29ff:fe58:585f/64 scope link
valid_lft forever preferred_lft forever
3: sit0: mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0

可以看到已經沒有vip這個地址了
去看備nginx服務器上看vip是否綁定在了上面
[root@localhost etc]# ip a
1: lo: mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:34:cc:f9 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.170/22 brd 192.168.1.255 scope global eth0
inet 192.168.2.114/32 scope global eth0
inet6 fe80::20c:29ff:fe34:ccf9/64 scope link
valid_lft forever preferred_lft forever
3: sit0: mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0

ok，可以看到vip已經綁定在備nginx服務器上了。

對于數據流量過大的網絡中，往往單一設備無法承擔，需要多臺設備進行數據分流，而負載均衡器就是用來將數據分流到多臺設備的一個轉發器。

目前有許多不同的負載均衡技術用以滿足不同的應用需求，如軟/硬件負載均衡、本地/全局負載均衡、更高網絡層負載均衡，以及鏈路聚合技術。

我們使用的是軟負載均衡器Nginx,而農行用的是F5硬負載均衡器，這里就簡單介紹下這兩種技術：

a.軟件負載均衡解決方案

在一臺服務器的操作系統上，安裝一個附加軟件來實現負載均衡，如Nginx負載均衡（我們管理系統平臺使用的也是這款均衡器）。它的優點是基于特定環境、配置簡單、使用靈活、成本低廉，可以滿足大部分的負載均衡需求。

一、什么是Nginx

Nginx ("engine x") 是一個高性能的 HTTP 和 反向代理 服務器，也是一個 IMAP/POP3/SMTP 代理服務器。 可以說Nginx 是目前使用最為廣泛的HTTP軟負載均衡器，其將源代碼以類BSD許可證的形式發布（商業友好），同時因高效的性能、穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名于業界。像騰訊、淘寶、新浪等大型門戶及商業網站都采用Nginx進行HTTP網站的數據分流。

二、Nginx的功能特點

1、工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；

2、Nginx對網絡的依賴比較??；

3、Nginx安裝和配置比較簡單，測試起來比較方便；

4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的并發；

5、Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，www.linuxidc.com 并且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；

6、Nginx對請求的異步處理可以幫助節點服務器減輕負載；

7、Nginx能支持http和Email，這樣就在適用范圍上面小很多；

8、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡算法。

三、Nginx的原理

Nginx采用的是反向代理技術，代理服務器來接受internet上的連接請求，然后將請求轉發給內部網絡上的服務器，并將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現為一個服務器。反向代理負載均衡技術是把將來自internet上的連接請求以反向代理的方式動態地轉發給內部網絡上的多臺服務器進行處理，從而達到負載均衡的目的。

b.硬件負載均衡解決方案

直接在服務器和外部網絡間安裝負載均衡設備，這種設備我們通常稱之為負載均衡器。由于專門的設備完成專門的任務，獨立于操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。 一般而言，硬件負載均衡在功能、性能上優于軟件方式，不過成本昂貴，比如最常見的就是F5負載均衡器。

什么是F5 BIG-IP

F5負載均衡器是應用交付網絡的全球領導者F5 Networks公司提供的一個負載均衡器專用設備，F5 BIG-IP LTM 的官方名稱叫做本地流量管理器，可以做4-7層負載均衡，具有負載均衡、應用交換、會話交換、狀態監控、智能網絡地址轉換、通用持續性、響應錯誤處理、IPv6網關、高級路由、智能端口鏡像、SSL加速、智能HTTP壓縮、TCP優化、第7層速率整形、內容緩沖、內容轉換、連接加速、高速緩存、Cookie加密、選擇性內容加密、應用攻擊過濾、拒絕服務(DoS)攻擊和SYN Flood保護、防火墻—包過濾、包消毒等功能。

以下是F5 BIG-IP用作HTTP負載均衡器的主要功能：

　　①、F5 BIG-IP提供12種靈活的算法將所有流量均衡的分配到各個服務器，而面對用戶，只是一臺虛擬服務器。

　　②、F5 BIG-IP可以確認應用程序能否對請求返回對應的數據。假如F5 BIG-IP后面的某一臺服務器發生服務停止、死機等故障，F5會檢查出來并將該服務器標識為宕機，從而不將用戶的訪問請求傳送到該臺發生故障的服務器上。這樣，只要其它的服務器正常，用戶的訪問就不會受到影響。宕機一旦修復，F5 BIG-IP就會自動查證應用已能對客戶請求作出正確響應并恢復向該服務器傳送。

　　③、F5 BIG-IP具有動態Session的會話保持功能。

　　④、F5 BIG-IP的iRules功能可以做HTTP內容過濾，根據不同的域名、URL，將訪問請求傳送到不同的服務器。

方案優缺點對比

基于硬件的方式(F5)

優點：能夠直接通過智能交換機實現,處理能力更強，而且與系統無關，負載性能強更適用于一大堆設備、大訪問量、簡單應用

缺點：成本高，除設備價格高昂，而且配置冗余．很難想象后面服務器做一個集群，但最關鍵的負載均衡設備卻是單點配置；無法有效掌握服務器及應用狀態.

硬件負載均衡，一般都不管實際系統與應用的狀態，而只是從網絡層來判斷，所以有時候系統處理能力已經不行了，但網絡可能還來 得及反應（這種情況非常典型，比如應用服務器后面內存已經占用很多，但還沒有徹底不行，如果網絡傳輸量不大就未必在網絡層能反映出來）

基于軟件的方式(Nginx)

優點：基于系統與應用的負載均衡，能夠更好地根據系統與應用的狀況來分配負載。這對于復雜應用是很重要的，性價比高，實際上如果幾臺服務器，用F5之類的硬件產品顯得有些浪費，而用軟件就要合算得多，因為服務器同時還可以跑應用做集群等。

缺點：負載能力受服務器本身性能的影響，性能越好，負載能力越大。

綜述：對我們管理系統應用環境來說，由于負載均衡器本身不需要對數據進行處理，性能瓶頸更多的是在于后臺服務器，通常采用軟負載均衡器已非常夠用且其商業友好的軟件源碼授權使得我們可以非常靈活的設計，無逢的和我們管理系統平臺相結合。