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日召开会议，会议指出，进一步优化生育政策，实施一对夫妻可以生育三个子女政策及配套支持措施。我国正处于人口大国向人力资本强国转变的重大战略机遇期，立足国情，“三孩”政策能够最大限度发挥人口对经济社会发展的能动作用。

自二胎政策以来，在人口增长以及产业提升方面，开始有显著的效果的。二孩政策的开放，促使少儿人口数量的逐渐增加，也会为一些儿童产业经济带来相当可观的市场。更别说三孩政策的开放，更会给儿童经济市场带来一个巨大的飞跃。

新风口

嗨心兔共享童车智能柜，作为新型共享经济的新模式，新风口，大大增加了儿童车的使用选择、节约了购买成本，还大便利了家长带娃，更可以增加孩子公平意识，提升社交乐趣，同时也解决很多用户的痛点：

 市场和痛点:

儿童电动车是孩子最不可缺失的用品之一，也是孩子成长过程中最重要的“玩伴”。但是买一台放在家里是非常占地方的，现在的楼价那么高，一台童车占据的面积就差不多一个平方了。按照一二线城市的楼价来计算，家里买一台童车的场地“租金”是相当高的。孩子“喜新厌旧”,玩具车很快就会“失宠”。买过儿童电动车的家长都会反馈，家里买回来的儿童电动车，只玩了两次就不完了， 然后就放在那里了。然后想玩第三的时候，发现因为电池长期没有充电的， 电池就报废了，已经不能再玩了。现在的家长对产品的品质要求都比较高，小孩子也是家里的宝贝，给小孩子买的电动儿童车，而且要买一台质量比较好的电动儿童车，价钱也不低的。现在家庭都是居住在小区内，对于宝妈来说，儿童电动车搬上搬下也是个特别麻烦的事情。

产品优势和特点：

广东品墨科技科技有限自主研发生产的一款智能共享童车，通过物联网和微信+支付宝小程序实行操作，可实现无人值守、智能消毒、自动计费、自动扣费完美解决了这些问题，项目具备下面几点优势：

优势一:无人值守免人工

传统童车玩乐需要，人工监管，人工收费，场地大了还得多个人看守，而嗨心兔智能设备无需专人值守,自动计费,自动扣费,一个人可管理几十个点。由于传统童车是都是采用定时断电的方式进行计费，这样限制了儿童消费的冲动，影响营业收入。

优势二：占地小租金少

传统童车玩乐有多少车就需要多大的空地存放, 而嗨心兔共享童车智能柜的方式存放，立体空间,一套设备占地还不到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社区非常活跃，第三方模块也很多。

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后剩余堆大小（即为活跃数据大小）；
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来实现高可用。可是现在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之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用做集群等。

缺点：负载能力受服务器本身性能的影响，性能越好，负载能力越大。

综述：对我们管理系统应用环境来说，由于负载均衡器本身不需要对数据进行处理，性能瓶颈更多的是在于后台服务器，通常采用软负载均衡器已非常够用且其商业友好的软件源码授权使得我们可以非常灵活的设计，无逢的和我们管理系统平台相结合。