嗨心兔是品墨科技自主研发生产的一款智能共享童车，通过物联网和微信+支付宝小程序实行操作，可实现无人值守、智能消毒、自动计费、自动扣费的新型儿童娱乐设备。加盟热线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之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用做集群等。

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

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

1、首先，bash中0，1，2三个数字分别代表STDIN_FILENO、STDOUT_FILENO、STDERR_FILENO，即标准输入（一般是键盘），标准输出（一般是显示屏，准确的说是用户终端控制台），标准错误（出错信息输出）。

2、输入输出可以重定向，所谓重定向输入就是在命令中指定具体的输入来源，譬如 cat < test.c 将test.c重定向为cat命令的输入源。输出重定向是指定具体的输出目标以替换默认的标准输出，譬如ls > 1.txt将ls的结果从标准输出重定向为1.txt文本。有时候会看到如 ls >> 1.txt这类的写法，> 和 >> 的区别在于：> 用于新建而>>用于追加。即ls > 1.txt会新建一个1.txt文件并且将ls的内容输出到新建的1.txt中，而ls >> 1.txt则用在1.txt已经存在，而我们只是想将ls的内容追加到1.txt文本中的时候。

3、默认输入只有一个（0，STDIN_FILENO），而默认输出有两个（标准输出1 STDOUT_FILENO，标准错误2 STDERR_FILENO）。因此默认情况下，shell输出的错误信息会被输出到2，而普通输出信息会输出到1。但是某些情况下，我们希望在一个终端下看到所有的信息（包括标准输出信息和错误信息），要怎么办呢？

       对了，你可以使用我们上面讲到的输出重定向。思路有了，怎么写呢？ 非常直观的想法就是2>1（将2重定向到1嘛），行不行呢？试一试就知道了。我们进行以下测试步骤：

1）mkdir test && cd test                ; 创建test文件夹并进入test目录

2）touch a.txt b.c c                          ; 创建a.txt b.c c 三个文件

3）ls > 1                                           ; 按我们的猜测，这句应该是将ls的结果重定向到标准输出，因此效果和直接ls应该一样。但是实际这句执行后，标准输出中并没有任何信息。

4）ls                                                  ; 执行3之后再次ls，则会看到test文件夹中多了一个文件1

5）cat 1                                            ; 查看文件1的内容，实际结果为：1 a.txt b.c c     可见步骤3中 ls > 1并不是将ls的结果重定向为标准输出，而是将结果重定向到了一个文件1中。即1在此处不被解释为STDOUT_FILENO，而是文件1。

4、到了此时，你应该也能猜到2>&1的用意了。不错，2>&1就是用来将标准错误2重定向到标准输出1中的。此处1前面的&就是为了让bash将1解释成标准输出而不是文件1。至于最后一个&，则是让bash在后台执行。

1．什么是会话保持？
在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。

    而这一系列的相关的交互过程可能是由客户到服务器的一个连接的多次会话完成，也可能是在客户与服务器之间的多个不同连接里的多次会话完成。不同连接的多次会话，最典型的例子就是基于http的访问，一个客户完成一笔交易可能需多次点击，而一个新的点击产生的请求，可能会重用上一次点击建立起来的连接，也可能是一个新建的连接。

    会话保持就是指在负载均衡器上有这么一种机制，可以识别做客户与服务器之间交互过程的关连性，在作负载均衡的同时，还保证一系列相关连的访问请求会保持分配到一台服务器上。

2．F5支持什么样的会话保持方法？
    F5 Big-IP支持多种的会话保持方法，其中包括：简单会话保持（源地址会话保持）、HTTP Header的会话保持，基于SSL Session ID的会话保持，i-Rules会话保持以及基于HTTP Cookie的会话保持，此外还有基于SIP ID以及Cache设备的会话保持等，但常用的是简单会话保持，HTTP Header的会话保持以及 HTTP Cookie会话保持以及基于i-Rules的会话保持。

2.1 简单会话保持
    简单会话保持也被称为基于源地址的会话保持，是指负载均衡器在作负载均衡时是根据访问请求的源地址作为判断关连会话的依据。对来自同一IP地址的所有访问 请求在作负载均时都会被保持到一台服务器上去。在BIG-IP设备上可以为“同一IP地址”通过网络掩码进行区分，比如可以通过对IP地址 192.168.1.1进行255.255.255.0的网络掩码，这样只要是来自于192.168.1.0/24这个网段的流量BIGIP都可以认为他们是来自于同一个用户，这样就将把来自于192.168.1.0/24网段的流量会话保持到特定的一台服务器上。

    简单会话保持里另外一个很重要的参数就是连接超时值，BIGIP会为每一个进行会话保持的会话设定一个时间值，当一个会话上一次完成到这个会话下次再来之前的间隔如果小于这个超时值，BIGIP将会将新的连接进行会话保持，但如果这个间隔大于该超时值，BIGIP将会将新来的连接认为是新的会话然后进行负载平衡。

    基于原地址的会话保持实现起来简单，只需要根据数据包三、四层的信息就可以实现，效率也比较高。存在的问题就在于当多个客户是通过代理或地址转换的方式来访问服务器时，由于都分配到同一台服务器上，会导致服务器之间的负载严重失衡。另外一种情况上客户机数量很少，但每个客户机都会产生多个并发访问，对这些并发访问也要求通过负载均衡器分配到多个服器上，这时基于客户端源地址的会话保持方法也会导致负载均衡失效。

2.2 基于Cookie的会话保持
2.2.1 Cookie插入模式：
    在Cookie插入模式下，Big-IP将负责插入cookie，后端服务器无需作出任何修改

    当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIG-IP， BIG-IP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（不带cookie）被发回BIGIP，然后 BIG-IP插入cookie，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP插入的cookie）进入 BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，由于服务器并不写入cookie，HTTP回复将不带有cookie，恢复流量再次经过进入BIG-IP时，BIG-IP再次写入更新后的会话保持 cookie。

2.2.2 Cookie 重写模式
    当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个空白的cookie并发回BIGIP，然后BIGIP重新在cookie里写入会话保持数值，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP重写的 cookie）进入BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有空的cookie，恢复流量再次经过进入BIGIP时，BIGIP再次写入更新后会话保持数值到该 cookie。

2.2.3 Passive Cookie 模式，服务器使用特定信息来设置cookie。
    当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后 BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入 BIGIP，然后BIGIP根据cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请 求回复，HTTP回复里又将带有更新的会话保持cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该cookie的请求回复给客户端。

2.2.4 Cookie Hash模式：
    当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后 BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入 BIGIP，然后BIGIP根据cookie里的一定的某个字节的字节数来决定后台服务器接受请求，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有更新后的cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该 cookie的请求回复给客户端。

2.3 SSL Session ID会话保持
    在用户的SSL访问系统的环境里，当SSL对话首次建立时，用户与服务器进行首次信息交换以：1}交换安全证书，2）商议加密和压缩方法，3）为每条对话 建立Session ID。由于该Session ID在系统中是一个唯一数值，由此，BIGIP可以应用该数值来进行会话保持。当用户想与该服务器再次建立连接时，BIGIP可以通过会话中的 SSL Session ID识别该用户并进行会话保持。

    基于SSL Session ID的会话保持就需要客户浏览器在进行会话的过程中始终保持其SSL Session ID不变，但实际上，微软Internet Explorer被发现在经过特定一段时间后将主动改变SSL Session ID，这就使基于SSL Session ID的会话保持实际应用范围大大缩小。

Linux系统中，有时候普通用户有些事情是不能做的，除非是root用户才能做到。这时就需要用su命令临时切换到root身份来做事了。

su：substitute['sʌbstɪtjuːt]代替 user
su 的语法为：
su [OPTION选项参数] [用户]
-, -l, --login 登录并改变到所切换的用户环境；
-c, --commmand=COMMAND 执行一个命令，然后退出所切换到的用户环境；

用su命令切换用户后，可以用 exit 命令或快捷键[Ctrl+D]可返回原登录用户。

例子：
su 在不加任何参数，默认为切换到root用户，但没有转到root用户家目录下，也就是说这时虽然是切换为root用户了，但并没有改变root登录环境；用户默认的登录环境，可以在/etc/passwd 中查得到，包括家目录，SHELL定义等；
su 加参数 - ，表示默认切换到root用户，并且改变到root用户的环境；

用su是可以切换用户身份，如果每个普通用户都能切换到root身份，如果某个用户不小心泄漏了root的密码，那岂不是系统非常的不安全？没有错，为了改进这个问题，产生了sudo这个命令。使用sudo执行一个root才能执行的命令是可以办到的，但是需要输入密码，这个密码并不是root的密码而是用户自己的密码。默认只有root用户能使用sudo命令，普通用户想要使用sudo，是需要root预先设定的，即，使用visudo命令去编辑相关的配置文件/etc/sudoers。如果没有visudo这个命令，请使用 "yum install -y sudo" 安装。

默认root能够sudo是因为这个文件中有一行” root ALL=(ALL) ALL”

sudo 的适用条件：
由于su对切换到超级权限用户root后，权限的无限制性，所以su并不能担任多个管理员所管理的系统。如果用su来切换到超级用户来管理系统，也不能明 确哪些工作是由哪个管理员进行的操作。特别是对于服务器的管理有多人参与管理时，最好是针对每个管理员的技术特长和管理范围，并且有针对性的下放给权限， 并且约定其使用哪些工具来完成与其相关的工作，这时我们就有必要用到 sudo。
通过sudo，我们能把某些超级权限有针对性的下放，并且不需要普通用户知道root密码，所以sudo 相对于权限无限制性的su来说，还是比较安全的，所以sudo 也能被称为受限制的su ；另外sudo 是需要授权许可的，所以也被称为授权许可的su；
sudo 执行命令的流程：是当前用户切换到root（或其它指定切换到的用户），然后以root（或其它指定的切换到的用户）身份执行命令，执行完成后，直接退回到当前用户；而这些的前提是要通过sudo的配置文件/etc/sudoers来进行授权；

从编写 sudo 配置文件/etc/sudoers开始
sudo的配置文件是/etc/sudoers ，我们可以用他的专用编辑工具visodu ，此工具的好处是在添加规则不太准确时，保存退出时会提示给我们错误信息；配置好后，可以用切换到您授权的用户下，通过sudo -l 来查看哪些命令是可以执行或禁止的；
/etc/sudoers 文件中每行算一个规则，前面带有#号可以当作是说明的内容，并不执行；如果规则很长，一行列不下时，可以用\号来续行，这样看来一个规则也可以拥有多个行；
/etc/sudoers 的规则可分为两类；一类是别名定义，另一类是授权规则；别名定义并不是必须的，但授权规则是必须的；

sudo授权规则(sudoers配置)：
授权用户 主机=命令动作
这三个要素缺一不可，但在动作之前也可以指定切换到特定用户下，在这里指定切换的用户要用( )号括起来，如果不需要密码直接运行命令的，应该加NOPASSWD:参数，但这些可以省略；举例说明；

sudoers的缺省配置：
Html代码  收藏代码
#############################################################  
# sudoers file.  
#  
# This file MUST be edited with the 'visudo' command as root.  
#  
# See the sudoers man page for the details on how to write a sudoers file.  
#  
# Host alias specification  
# User alias specification  
# Cmnd alias specification  
# Defaults specification  
# User privilege specification  
root    ALL=(ALL) ALL  
# Uncomment to allow people in group wheel to run all commands  
# %wheel        ALL=(ALL)       ALL  
# Same thing without a password  
# %wheel        ALL=(ALL)       NOPASSWD: ALL  
# Samples  
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom  
# %users  localhost=/sbin/shutdown -h now  
##################################################################  

1. 最简单的配置，让普通用户support具有root的所有权限
执行visudo之后，可以看见缺省只有一条配置：
root    ALL=(ALL) ALL
那么你就在下边再加一条配置：
support ALL=(ALL) ALL
这样，普通用户support就能够执行root权限的所有命令
以support用户登录之后，执行：
sudo su -
然后输入support用户自己的密码，就可以切换成root用户了
2. 让普通用户support只能在某几台服务器上，执行root能执行的某些命令
首先需要配置一些Alias，这样在下面配置权限时，会方便一些，不用写大段大段的配置。Alias主要分成4种
Host_Alias
Cmnd_Alias
User_Alias
Runas_Alias
1) 配置Host_Alias：就是主机的列表
Host_Alias      HOST_FLAG = hostname1, hostname2, hostname3
2) 配置Cmnd_Alias：就是允许执行的命令的列表，命令前加上!表示不能执行此命令.
命令一定要使用绝对路径，避免其他目录的同名命令被执行，造成安全隐患 ,因此使用的时候也是使用绝对路径!
Cmnd_Alias      COMMAND_FLAG = command1, command2, command3 ，!command4
3) 配置User_Alias：就是具有sudo权限的用户的列表
User_Alias USER_FLAG = user1, user2, user3
4) 配置Runas_Alias：就是用户以什么身份执行（例如root，或者oracle）的列表
Runas_Alias RUNAS_FLAG = operator1, operator2, operator3
5) 配置权限
配置权限的格式如下：
USER_FLAG HOST_FLAG=(RUNAS_FLAG) COMMAND_FLAG
如果不需要密码验证的话，则按照这样的格式来配置
USER_FLAG HOST_FLAG=(RUNAS_FLAG) NOPASSWD: COMMAND_FLAG
配置示例：
Html代码  收藏代码
############################################################################  
# sudoers file.  
#  
# This file MUST be edited with the 'visudo' command as root.  
#  
# See the sudoers man page for the details on how to write a sudoers file.  
#  
# Host alias specification  
Host_Alias      EPG = 192.168.1.1, 192.168.1.2  
# User alias specification  
# Cmnd alias specification  
Cmnd_Alias      SQUID = /opt/vtbin/squid_refresh, !/sbin/service, /bin/rm 
 
Cmnd_Alias      ADMPW = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd, !/usr/bin/passwd root  
# Defaults specification  
# User privilege specification  
root    ALL=(ALL) ALL  
support EPG=(ALL) NOPASSWD: SQUID  
support EPG=(ALL) NOPASSWD: ADMPW 
# Uncomment to allow people in group wheel to run all commands  
# %wheel        ALL=(ALL)       ALL  
# Same thing without a password  
# %wheel        ALL=(ALL)       NOPASSWD: ALL  
# Samples  
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom  
# %users  localhost=/sbin/shutdown -h now  
############################################################### 

LVS和Nginx都可以用作多机负载的方案，它们各有优缺，在生产环境中需要好好分析实际情况并加以利用。

　　首先提醒，做技术切不可人云亦云，我云即你云；同时也不可太趋向保守，过于相信旧有方式而等别人来帮你做垫被测试。把所有即时听说到的好东西加以钻研，从而提高自己对技术的认知和水平，乃是一个好习惯。

下面来分析一下两者：

一、lvs的优势：

　　1、抗负载能力强，因为lvs工作方式的逻辑是非常之简单，而且工作在网络4层仅做请求分发之用，没有流量，所以在效率上基本不需要太过考虑。在我手里的 lvs，仅仅出过一次问题：在并发最高的一小段时间内均衡器出现丢包现象，据分析为网络问题，即网卡或linux2.4内核的承载能力已到上限，内存和 cpu方面基本无消耗。

　　2、配置性低，这通常是一大劣势，但同时也是一大优势，因为没有太多可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。

　　3、工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。

　　4、无流量，上面已经有所提及了。lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。

　　5、基本上能支持所有应用，因为lvs工作在4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等等。

　　另：lvs也不是完全能判别节点故障的，譬如在wlc分配方式下，集群里有一个节点没有配置VIP，会使整个集群不能使用，这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以，用lvs也得多多当心为妙。

二、nginx和lvs作对比的结果

　　1、nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具备这样的功能，所以 nginx单凭这点可利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰触碰，由lvs的第2条优点 看，触碰多了，人为出问题的几率也就会大。

　　2、nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的 节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。另 外注意，lvs需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。

　　3、nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了，因为同上所述，lvs对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。

　　4、nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险较大，单机上的事情全都很难说。

　　5、nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs中 ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚 好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能 会因此而恼火。

　　6、nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用Apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个nginx做apache代理的话，这些窄带链接会被nginx挡住，apache上就不会堆积过多的请求，这样就减少了相 当多的内存占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。lvs没有这些功能，也就无法能 比较。

　　7、nginx能支持http和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是最完美的方案了。

　　nginx也可作为网页静态服务器，不过超出了本文讨论的范畴，简单提一下。

　　具体的应用还得具体分析，如果是比较小的网站（日PV<1000万），用nginx就完全可以了，如果机器也不少，可以用DNS轮询，lvs所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用lvs。

在Linux中常用于判断问题所在的初步定位或性能瓶颈，iostat则给我们提供了丰富的IO状态信息，其他工具还有iotop。

letong@me:~$ sudo iostat
Linux 3.13.0-41-generic (me) 2014年12月18日 _x86_64_ (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
8.92 0.12 2.27 0.65 0.00 88.05

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 5.12 85.24 1.97 586069 13512
sdb 9.51 43.74 112.81 300771 775678
rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目。即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s
rsec/s: 每秒读扇区数。即 delta(rsect)/s
wsec/s: 每秒写扇区数。即 delta(wsect)/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。(需要计算)
wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
常用参数：
-d 1 #每1秒显示1次
-x #显示更详细信息
-c #显示cpu相关

常见用法
iostat -d -k 1 10 #查看TPS和吞吐量信息
iostat -d -x -k 1 10 #查看设备使用率、响应时间
iostat -c 1 10 #查看cpu状态

如果在测试过程中遇到某个进程的CPU利用率过高或者卡死而需要去调试该进程时，可以利用gdb命令生成coredump文件，然后再去调试coredump文件来定位问题。

那么如何使用gdb生成coredump文件呢？其实步骤很简单：

1. 安装好gdb，然后使用命令 'gdb'。（假设需要调试的进程号为 21509）

2. 使用 ‘attach 21590’命令将gdb附加到进程21509上。

3. 使用‘gcore core_name’命令生成coredump文件core_name。

4. 使用‘detach’命令断开连接。

5.使用‘q’命令退出gdb。

此时，在当前目录下就会产生一个名为core_name的coredump文件。下面就可以利用gdb工具来对该coredump文件进行调试了。

性能测试排查定位问题，分析调优过程中，会遇到要分析gc日志，人肉分析gc日志有时比较困难，相关图形化或命令行工具可以有效地帮助辅助分析。

Gc日志参数

通过在tomcat启动脚本中添加相关参数生成gc日志

-verbose.gc开关可显示GC的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。

打开 -xx:+ printGCdetails开关，可以详细了解GC中的变化。

打开 -XX: + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。

最后，通过 -xx: + PrintHeapAtGC开关了解堆的更详细的信息。

为了了解新域的情况，可以通过 -XX:=PrintTenuringDistribution开关了解获得使用期的对象权。

-Xloggc:$CATALINA_BASE/logs/gc.loggc日志产生的路径

XX:+PrintGCApplicationStoppedTime//输出GC造成应用暂停的时间

-XX:+PrintGCDateStamps// GC发生的时间信息

Gc日志

日志中显示了gc发生的时间，young区回收情况，整体回收情况，fullGC情况，回收所消耗时间等

常用JVM参数

分析gc日志后，经常需要调整jvm内存相关参数，常用参数如下

-Xms：初始堆大小，默认为物理内存的1/64(<1GB)；默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制

-Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制

-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。整个堆大小=新生代大小+老生代大小+永久代大小。 
在保证堆大小不变的情况下，增大新生代后,将会减小老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX:SurvivorRatio：新生代中Eden区域与Survivor区域的容量比值，默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

-Xss：每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。一般小的应用， 如果栈不是很深， 应该是128k够用的，大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"-Xss is translated in a VM flag named ThreadStackSize”一般设置这个值就可以了。

-XX:PermSize：设置永久代(perm gen)初始值。默认值为物理内存的1/64。

-XX:MaxPermSize：设置持久代最大值。物理内存的1/4。

Gc日志分析工具

(1)GCHisto

http://java.net/projects/gchisto

直接点击gchisto.jar就可以运行，点add载入gc.log

统计了总共gc次数，youngGC次数，FullGC次数，次数的百分比，GC消耗的时间，百分比，平均消耗时间，消耗时间最小最大值等

统计的图形化表示

YoungGC,FullGC不同消耗时间上次数的分布图，勾选可以显示youngGC或fullGC单独的分布情况

整个时间过程详细的gc情况，可以对整个过程进行剖析

(2)GCLogViewer

http://code.google.com/p/gclogviewer/

点击run.bat运行

整个过程gc情况的趋势图，还显示了gc类型，吞吐量，平均gc频率，内存变化趋势等

Tools里还能比较不同gc日志

(3)HPjmeter

获取地址 http://www.hp.com/go/java 
参考文档 http://www.javaperformancetuning.com/tools/hpjtune/index.shtml

工具很强大，但只能打开由以下参数生成的GC log，-verbose:gc -Xloggc:gc.log,添加其他参数生成的gc.log无法打开。

(4)GCViewer

http://www.tagtraum.com/gcviewer.html

这个工具用的挺多的，但只能在JDK1.5以下的版本中运行，1.6以后没有对应。

(5)garbagecat

http://code.google.com/a/eclipselabs.org/p/garbagecat/wiki/Documentation

其它监控方法

Jvisualvm动态分析jvm内存情况和gc情况，插件：visualGC

jvisualvm还可以heapdump出对应hprof文件（默认存放路径：监控的服务器/tmp下），利用相关工具，比如HPjmeter可以对其进行分析

grep Full gc.log粗略观察FullGC发生频率

jstat –gcutil [pid] [intervel] [count]

jmap -histo pid可以观测对象的个数和占用空间 
jmap -heap pid可以观测jvm配置参数，堆内存各区使用情况

jprofiler,jmap dump出来用MAT分析

如果要分析的dump文件很大的话，就需要很多内存，很容易crash。

所以在启动时，我们应该加上一些参数：Java–Xms512M–Xmx1024M–Xss8M

不同的JVM及其选项会输出不同的日志。

GC 日志

生成下面日志使用的选项： -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:d:/GClogs/tomcat6-gc.log。

4.231: [GC 4.231: [DefNew: 4928K->512K(4928K), 0.0044047 secs] 6835K->3468K(15872K), 0.0045291 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
 
4.445: [Full GC (System) 4.445: [Tenured: 2956K->3043K(10944K), 0.1869806 secs] 4034K->3043K(15872K), [Perm : 3400K->3400K(12288K)], 0.1870847 secs] [Times: user=0.05 sys=0.00, real=0.19 secs] 

最前面的数字 4.231 和 4.445 代表虚拟机启动以来的秒数。

[GC 和 [Full GC 是垃圾回收的停顿类型，而不是区分是新生代还是年老代，如果有 Full 说明发生了 Stop-The-World 。如果是调用 System.gc() 触发的，那么将显示的是 [Full GC (System) 。

接下来的 [DefNew, [Tenured, [Perm 表示 GC 发生的区域，区域的名称与使用的 GC 收集器相关。 Serial 收集器中新生代名为 "Default New Generation"，显示的名字为 "[DefNew"。对于ParNew收集器，显示的是 "[ParNew"，表示 “Parallel New Generation”。 对于 Parallel Scavenge 收集器，新生代名为 "PSYoungGen"。年老代和永久代也相同，名称都由收集器决定。

方括号内部显示的 “4928K->512K(4928K)” 表示 “GC 前该区域已使用容量 -> GC 后该区域已使用容量 (该区域内存总容量) ”。

再往后的 “0.0044047 secs” 表示该区域GC所用时间，单位是秒。

再往后的 “6835K->3468K(15872K)” 表示 “GC 前Java堆已使用容量 -> GC后Java堆已使用容量 （Java堆总容量）”。

再往后的 “0.0045291 secs” 是Java堆GC所用的总时间。

最后的 “[Times: user=0.00 sys=0.00, real=0.00 secs]” 分别代表 用户态消耗的CPU时间、内核态消耗的CPU时间 和 操作从开始到结束所经过的墙钟时间。墙钟时间包括各种非运算的等待耗时，如IO等待、线程阻塞。CPU时间不包括等待时间，当系统有多核时，多线程操作会叠加这些CPU时间，所以user或sys时间会超过real时间。

堆的分代

在上图中：

• young区域就是新生代，存放新创建对象；
• tenured是年老代，存放在新生代经历多次垃圾回收后仍存活的对象；
• perm是永生代，存放类定义信息、元数据等信息。

当GC发生在新生代时，称为Minor GC，次收集；当GC发生在年老代时，称为Major GC，主收集。 一般的，Minor GC的发生频率要比Major GC高很多。

VM性能的快速测试方法

核心提示： 经常有同行问怎么样去做这些性能评测。其实这些性能评测都很简单，任何一个具备Linux基础知识的工程师都可以完成。我们通常使用UnixBench来评估虚拟机CPU性能，mbw来评估内存性能，iozone来评估文件IO性能，iperf来评估网络性能，pgbench来评估数据库性能。在这里我将我自己做性能测试的过程整理一下，供各位同行参考。

中国IDC圈10月30日报道 前段时间陆续发布了一些对公有云服务性能评测的数据。经常有同行问怎么样去做这些性能评测。其实这些性能评测都很简单，任何一个具备Linux基础知识的工程师都可以完成。我们通常使用UnixBench来评估虚拟机CPU性能，mbw来评估内存性能，iozone来评估文件IO性能，iperf来评估网络性能，pgbench来评估数据库性能。在这里我将我自己做性能测试的过程整理一下，供各位同行参考。

（0）安装必要的软件

假定VM的操作系统是Ubuntu，可以按照如下步骤安装必要的软件：

（1）CPU性能测试

我们使用UnixBench来进行CPU性能测试。UnixBench是一套具有悠久历史的性能测试工具，其测试结果反映的是一台主机的综合性能。从理论上来说UnixBench测试结果与被测试主机的CPU、内存、存储、操作系统都有直接的关系。但是根据我们的观察，对于现代的计算机系统来说，UnixBench测试结果受CPU 处理能力的影响更大一些。因此，在这里我们用UnixBench测试结果来代表虚拟机的vCPU 处理能力。每个UnixBench测试结果包括两个数据，一个是单线程测试结果，另一个是多线程测试结果（虚拟机上有几颗虚拟CPU，就有几个并发的测试线程）。

cd ~/UnixBench

./Run

下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3）。我们分别测试了宿主机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在本地磁盘上的虚拟机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在NFS上的虚拟机的CPU性能。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存，运行Ubuntu 12.04 AMD64 Server操作系统。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优。

从如上测试结果可以看出，在没有进行任何性能调优的情况下，在单线程CPU性能方面，宿主机 >> 本地磁盘上的虚拟机 >> NFS服务上的虚拟机；在多线程CPU性能方面，宿主机 >> 本地磁盘上的虚拟机 ＝ NFS服务上的虚拟机。需要注意的是，在多线程测试结果方面，宿主机所占的优势完全是由于宿主机比虚拟机多占用了两个物理线程，也就是一个物理核心。可以认为，在如上所述测试中，物理机和虚拟机的CPU性能基本上是一致的，虚拟化基本上没有导致CPU性能损失。

（2）文件IO性能测试

我们使用iozone来进行文件IO性能测试。iozone性能测试结果表示的是文件IO的吞吐量（KBps），但是通过吞吐量可以估算出IOPS.在如下命令中，我们评估的是以256K为数据块大小对文件进行写、重写、读、重读、随机读、随机写性能测试，在测试过程当中使用/io.tmp作为临时测试文件，该测试文件的大小是4 GB.需要注意的是，命令中所指定的测试文件是带路径的，因此我们可以测试同一虚拟机上不同文件系统的性能。例如我们通过NFS将某一网络共享文件系统挂载到虚拟机的/mnt目录，那么我们可以将该测试文件的路径设定为/mnt/io.tmp.

cd ~/iozone3_414/src/current

./iozone -Mcew -i0 -i1 -i2 -s4g -r256k -f /io.tmp

下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3）。我们分别测试了宿主机、NFS、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在本地磁盘上的虚拟机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在NFS上的虚拟机、以及从虚拟机内部挂载宿主机NFS服务（虚拟网卡启用了virtio）的磁盘IO性能。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存，运行Ubuntu 12.04 AMD64 Server操作系统。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优。

从如上测试结果可以看出，在如上所述特定测试场景中，在文件IO性能方面，宿主机 > NFS > 虚拟机中的NFS > 本地磁盘上的虚拟机 >NFS服务上的虚拟机。值得注意的是，即使是从虚拟机中挂载NFS服务，其文件IO性能也远远超过本地磁盘上的虚拟机。
        

［特别说明］需要注意的是，当我们说文件（或者磁盘）IO性能的时候，我们指的通常是应用程序（例如iozone）进行文件读写操作时所看到的IO性能。这个性能通常是与系统相关的，包括了多级缓存（磁盘自身的缓存机制、操作系统的缓存机制）的影响，而不仅仅是磁盘本身。利用iozone进行文件IO性能测试时，测试结果与主机的内存大小、测试数据块的大小、测试文件的大小都有很大的关系。如果要全面地描述一个特定系统（CPU、内存、硬盘）的文件IO性能，往往需要对测试数据块的大小和测试文件的大小进行调整，进行一系列类似的测试并对测试结果进行全面分析。本文所提供的仅仅是一个快速测试方法，所提供的测试参数并没有针对任何特定系统进行优化，仅仅是为了说明iozone这个工具的使用方法。如上所述之测试数据，仅仅在如上所述之测试场景下是有效的，并不足以定性地说明任何虚拟化场景下宿主机和虚拟机的文件IO性能差异。建议读者在掌握了iozone这个工具的使用方法的基础上，对被测试对象进行更加全面的测试。（感谢saphires网友的修改建议。）

（3）内存性能测试

我们使用mbw来测试虚拟机的内存性能。mbw通常用来评估用户层应用程序进行内存拷贝操作所能够达到的带宽（MBps）。

mbw 128

下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3），虚拟机运行Ubuntu 12.04 AMD64 Server操作系统。我们分别测试了宿主机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在本地磁盘上的虚拟机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在NFS上的虚拟机的内存性能。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优。

从如上测试结果可以看出，在没有进行任何性能调优的情况下，宿主机、本地磁盘上的虚拟机、NFS服务上的虚拟机在内存性能方面基本上是一致的，虚拟化基本上没有导致内存性能损失。

（4）网络带宽测试

我们使用iperf来测试虚拟机之间的网络带宽（Mbps）。测试方法是在一台虚拟机上运行iperf服务端，另外一台虚拟机上运行iperf客户端。假设运行服务端的虚拟机的IP地址是192.168.1.1，运行客户端的虚拟机的IP地址是192.168.1.2.

在服务端执行如下命令：

iperf -s

在客户端执行如下命令：

iperf -c 192.168.1.1

测试完成后，在客户端会显示两台虚拟机之间的网络带宽。

下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3）。我们分别测试了宿主机之间、宿主机与虚拟机之间、虚拟机与虚拟机之间的内网带宽。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存，运行Ubuntu 12.04 AMD64 Server操作系统。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优，但是虚拟机的网卡启用了virtio.

从如上测试结果可以看出，宿主机之间的内网带宽接近内网交换

机的极限。在启用了virtio的情况下，宿主机与虚拟机之间内网带宽有小幅度的性能损失，基本上不会影响数据传输能力；虚拟机与虚拟机之间的内网带宽有接近15%的损失，对数据传输能力影响也不是很大。

（5）数据库性能测试

postgresql是一个著名的开源数据库系统。在MySQL被Sun 公司收购并进一步被Oracle公司收购之后，越来越多的公司正在从MySQL迁移到postgresql.pgbench是一个针对postgresql的性能测试工具，其测试结果接近于TPC-B.pgbench的优点之一在于它能够轻易地进行多线程测试，从而充分利用多核处理器的处理能力。

在虚拟机上以postgres用户登录：

su -l postgres

将/usr/lib/postgresql/9.1/bin加入到路径PATH当中。

创建测试数据库：

createdb pgbench

初始化测试数据库：

pgbench -i -s 16 pgbench

执行单线程测试：

pgbench -t 2000 -c 16 -U postgres pgbench

执行多线程测试，在下面的命令中将N替换为虚拟机的vCPU数量：

pgbench -t 2000 -c 16 -j N -U postgres pgbench

下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3），虚拟机运行Ubuntu 12.04 AMD64 Server操作系统。我们分别测试了宿主机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在本地磁盘上的虚拟机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在NFS上的虚拟机的数据库性能。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存，运行Ubuntu 12.04 AMD64 Server操作系统。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优。

从如上测试结果可以看出，在没有进行任何性能调优的情况下，在数据库性能方面，宿主机 >> 本地磁盘上的虚拟机 >> NFS服务上的虚拟机。

本文是参考logstash官方文档实践的笔记，搭建环境和所需组件如下：

• Redhat 5.7 64bit / CentOS 5.x
• JDK 1.6.0_45
• logstash 1.3.2 (内带kibana)
• elasticsearch 0.90.10
• redis 2.8.4

搭建的集中式日志分析平台流程如下： 

elasticsearch

1、下载elasticsearch。

wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.10.tar.gz 

2、解压后，进入bin目录。执行如下命令，让elasticsearch以前台方式启动：

./elasticsearch -f 

[2014-01-16 16:21:31,825][INFO ][node                     ] [Saint Elmo] version[0.90.10], pid[32269], build[0a5781f/2014-01-10T10:18:37Z] [2014-01-16 16:21:31,826][INFO ][node                     ] [Saint Elmo] initializing ... [2014-01-16 16:21:31,836][INFO ][plugins                  ] [Saint Elmo] loaded [], sites [] [2014-01-16 16:21:35,425][INFO ][node                     ] [Saint Elmo] initialized [2014-01-16 16:21:35,425][INFO ][node                     ] [Saint Elmo] starting ... [2014-01-16 16:21:35,578][INFO ][transport                ] [Saint Elmo] bound_address {inet[/0.0.0.0:9300]}, publish_address {inet[/10.0.2.15:9300]} 

Redis

1、其安装方式可以参考我的另一篇文章Redis编译安装。

2、进入其bin目录，执行如下命令，使之在控制台输出debug信息：

./redis-server --loglevel verbose 

[32470] 16 Jan 16:45:57.330 * The server is now ready to accept connections on port 6379 [32470] 16 Jan 16:45:57.330 - 0 clients connected (0 slaves), 283536 bytes in use 

logstash日志生成器（shipper）

1、新建一个配置文件：shipper.conf，其内容如下：

input {     stdin {         type => "example"     } }  output {     stdout {         codec => rubydebug     }     redis {         host => "127.0.0.1"         port => 6379         data_type => "list"         key => "logstash"     } } 

2、启动shipper。执行如下命令：

java -jar logstash-1.3.2-flatjar.jar agent -f shipper.conf  

终端窗口将出现如下提示信息：

Using milestone 2 output plugin 'redis'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.3.2/plugin-milestones {:level=>:warn} 

然后在终端窗口直接按回车，将出现如下信息：

{        "message" => "",       "@version" => "1",     "@timestamp" => "2014-01-16T08:15:19.400Z",           "type" => "example",           "host" => "redhat" } 

这个json信息将发送给redis， 同时redis的终端窗口将出现类似下面的提示信息：

[32470] 16 Jan 17:09:23.604 - Accepted 127.0.0.1:44640 [32470] 16 Jan 17:09:27.127 - DB 0: 1 keys (0 volatile) in 4 slots HT. [32470] 16 Jan 17:09:27.127 - 1 clients connected (0 slaves), 304752 bytes in use 

logstash日志索引器（indexer）

1、新建一个配置文件：indexer.conf，其内容如下：

input {   redis {     host => "127.0.0.1"     # these settings should match the output of the agent     data_type => "list"     key => "logstash"      # We use the 'json' codec here because we expect to read     # json events from redis.     codec => json   } }  output {   stdout { debug => true debug_format => "json"}    elasticsearch {     host => "127.0.0.1"   } } 

2、启动日志索引器。执行如下命令：

java -jar logstash-1.3.2-flatjar.jar agent -f indexer.conf  

终端窗口将出现如下提示信息：

Using milestone 2 input plugin 'redis'. This plugin should be stable, but if you see strange behavior, please let us know! For more information on plugin milestones, see http://logstash.net/docs/1.3.2/plugin-milestones {:level=>:warn} You are using a deprecated config setting "debug_format" set in stdout. Deprecated settings will continue to work, but are scheduled for removal from logstash in the future.  If you have any questions about this, please visit the #logstash channel on freenode irc. {:name=>"debug_format", :plugin=>, :level=>:warn} 

索引器从Redis接收到信息，在终端窗口会显示类似如下的信息：

{"message":"","@version":"1","@timestamp":"2014-01-16T17:10:03.831+08:00","type":"example","host":"redhat"}{"message":"","@version":"1","@timestamp":"2014-01-16T17:13:20.545+08:00","type":"example","host":"redhat"}{ 

logstash WEB界面（kibana）

1、启动kibana。执行如下命令：

java -jar logstash-1.3.2-flatjar.jar web 

2、打开浏览器（须支持HTML5），输入地址：http://127.0.0.1:9292/index.html#/dashboard/file/logstash.json。界面效果如下： 

 

参考资料

• logstash-getting-started-centralized
• 访谈与书评：《LogStash，使日志管理更简单》

Fluentd是一个开源收集事件和日志系统，它目前提供150+扩展插件让你存储大数据用于日志搜索，数据分析和存储。

官方地址http://fluentd.org/  插件地址http://fluentd.org/plugin/

Kibana 是一个为 ElasticSearch 提供日志分析的 Web ui工具，可使用它对日志进行高效的搜索、可视化、分析等各种操作。官方地址http://www.elasticsearch.org/overview/kibana/

elasticsearch 是开源的（Apache2协议），分布式的，RESTful的，构建在Apache Lucene之上的的搜索引擎.

官方地址http://www.elasticsearch.org/overview/    中文地址 http://es-cn.medcl.net/

具体的工作流程就是利用fluentd 监控并过滤hadoop集群的系统日志，将过滤后的日志内容发给全文搜索服务ElasticSearch, 然后用ElasticSearch结合Kibana 进行自定义搜索web页面展示.

下面开始说部署方法和过程。以下安装步骤在centos 5 64位测试通过

一、  elasticsearch安装部署

elasticsearch 官方提供了几种安装包，适用于windows的zip压缩包，适用于unix/linux的tar.gz压缩包，适用于centos系统的rpm包和ubuntu的deb包。大家可以自己选择安装使用。

因为elasticsearch 需要java环境运行，首先需要安装jdk,安装步骤就省略了。

使用.tar.gz压缩包安装部署的话，先下载压缩包

# wget  https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.5.tar.gz

# tar zxvf elasticsearch-0.90.5.tar.gz

////////////如果是单机部署

# cd elasticsearch-0.90.5

# elasticsearch-0.90.5/bin/elasticsearch -f

就可以启动搜索服务了，查看端口9200是否打开，如果打开说明启动正常。

////////////////如果是部署集群的话，需要进行配置

例如在192.168.0.1   192.168.0.2 两台服务器部署，两台服务器都安装好jdk，下载elasticsearch 解压缩，然后编辑配置文件

//////////////////////192.168.0.1   服务器编辑文件

vi elasticsearch-0.90.5/config/elasticsearch.yml

删除cluster.name 前面注释，修改集群名称 

cluster.name: es_cluster

删除node.name前注释 ，修改节点名称，不修改的话，系统启动后会生成随即node名称。

node.name: "elastic_inst1"

node.master: true    设置该节点为主节点

/////////////////////////192.168.0.2  编辑文件

vi elasticsearch-0.90.5/config/elasticsearch.yml

删除cluster.name 前面注释，修改集群名称 

cluster.name: es_cluster

删除node.name前注释 ，修改节点名称，不修改的话，系统启动后会生成随即node名称。

node.name: "elastic_inst2"

node.master: false    设置该节点为主节点

分别启动两台服务器的服务后，在192.168.0.2的日志中会看到

 [elastic_inst2] detected_master [elastic_inst1]     日志信息。说明集群连接成功。

二、安装部署fluentd

在需要监控分析的hadoop集群节点中安装fluentd，安装步骤很简单

curl -L http://toolbelt.treasure-data.com/sh/install-redhat.sh | sh

# vim /etc/td-agent/td-agent.conf

[html] view plaincopyprint?

1. <source>  
2.   type tail  #### tail方式采集日志  
3.   path /var/log/hadoop/mapred/hadoop-mapred-tasktracker-node-128-70.log   ### hadoop日志路径  
4.   pos_file /var/log/td-agent/task-access.log.pos  
5.   tag task.mapred  
6.   format /^(?<message>.+(WARN|ERROR).+)$/   #### 收集error 或者warn 日志。  
7. </source>  
8.   
9. <match task.**>  
10.   host 192.168.0.1  #####  <span style="font-family:Arial,Helvetica,sans-serif">elasticsearch 服务器地址</span>  
11.   type elasticsearch  
12.   logstash_format true  
13.   flush_interval 5s  
14.   include_tag_key true  
15.   tag_key mapred  
16. </match>  

# service td-agent start

三、安装部署kibana 3

kibana 3 是使用html 和javascript 开发的web ui前端工具。

下载 wget http://download.elasticsearch.org/kibana/kibana/kibana-latest.zip

解压缩 unzip kibana-latest.zip

安装apache    yum -y install httpd

cp -r  kibana-latest /var/www/html

因为我将kibana3 安装在和elasticsearch同一台服务器中，所以不用修改配置文件

启动apache  service httpd start

打开浏览器 http://ip/kibana 就可以看到kibana 界面

初次使用kibana 需要自己定义模块

前言
    持续集成这个概念已经成为软件开发的主流，可以更频繁的进行测试，尽早发现问题并提示。自动化部署就更不用说了，可以加快部署速度，并可以有效减少人为操作的失误。之前一直没有把这个做起来，最近的新项目正好有机会，费了一番功夫总算搞好了，特此记录。

1. 开发环境
    我这边建立的标准开发环境如下：
    1. Maven做项目管理；
    2. Git做代码管理；
    3. SpringMVC+Spring+Mybatis搭建的程序框架；
    4. Mysql作为数据存储，Druid做连接池；
    5. unitils作为测试框架；
    6. Hibernate Validator作为数据验证；

    7. log4j作为日志输出。
    注：其实这套东西非常像Grails，但不敢用太激进的技术和框架，担心招人的问题-_-!

2. Jenkins的部署
    Jenkins原名是Hudson，这个渊源这里就不追溯了，网上多得是，但是千万别下错了，官网地址是http://jenkins-ci.org/。建议直接下载最新版本。

    这个软件的安装是我见过最简单的了，直接取war包放到tomcat下，启动tomcat即可。相应的工程配置会在~/.jenkins目录中。（当然你根据官网给的那种安装方法也行，只是在debian的那个弄法还要去下载openjdk等等，多下了很多东西，相关配置也按linux目录标准分开的，还要去找。）

    另外提醒一下，建议把Jenkins安装在Linux上，这样就不会出现ssh等命令找不到的问题，否则还要想办法去处理。

3. Jenkins的插件
    安装好后直接访问“http://yourhost:8080/jenkins”即可进入主界面，点击“系统管理”->“管理插件”，首次进入都是空白的，要等1分钟左右才能看到内容，在后台估计是在做更新或者下载，然后重新再进此界面就能看到内容了。

3.1 Git插件
    在“可选插件”中找到“GIT plugin”安装，最下面有个安装完重启的勾选项，选中即可。这里最搞笑的是检测网络是否连通的办法是去尝试打开google，岂不知天朝是打不开的，还好不影响下载。。。

3.2 Email插件
    这个事情非常蛋疼，之前测试怎么都发布出来邮件，最后升级了一下默认插件就行了，狂汗。在“可更新”中找到“Mailer Plugin”选中并更新即可。另外如果想有更丰富的邮件内容，就去“可选插件”中安装“Email Extension Plugin”，具体邮件内容配置网上大把可以搜。

3.3 其他插件
    默认就装了很多常用插件，比如Maven、Junit等等，如果使用感觉有问题可以尝试升级一下版本，但是没有升级说明，也不知道升级了什么东西。

4. 系统设置
    主界面点击“系统管理”->“系统设置”即可进入。重点配置以下内容：
    1. Java、Git、Maven的目录位置，确保可以正确找到命令；

    2. Jenkins URL，自动生成的，检查一下即可;
    3. 邮件的设置。这里注意一下，上面有一个“系统管理员邮件地址”需要填写，另外“Extended E-mail Notification”中填写配置，原来的“邮件配置”就不用再理会了。

5. 项目设置
    在主界面直接“新建”，就会有一个新的项目。重点配置以下内容：

    1. 源码管理：选择Git，填写“Repository URL”，并加上相应的“Credentials”，其中认证信息用私钥的话干脆直接把私钥内容填上去就行了，省的不知道目录查找规则还不知道出的啥问题。

    2. 构建触发器：这个地方要把“Build periodically”和“Poll SCM”都选上，时间格式都填写成一样的即可，比如“H/15  * * * *”，下面会有个具体执行时间的提示，Build动作会自动比Poll延迟3分40秒，这个设定还是很合理的。

    3. 构建：增加两个构建步骤，分别是“Execute shell”和“Invoke top-level Maven target”，注意先后顺序，可以拖拽摆放的。脚本执行根据自己需要，比如我需要去修改数据库连接配置，官方建议是自己在工程里面写好脚本，这里直接调用，而不是在这写一个完整的脚本。Maven构建就加上“clean test”即可，就是运行“mvn clean test”的命令。

    4. Publish Junit test result report：在测试报告（XML）上加上“**/target/surefire-reports/*.xml”即可，这样就会每次测试完自动找到测试报告，在Jenkins上即可在每个构建结构里面查看到。

    5. 邮件通知：在构建后增加“Editable Email Notification”，填写邮件的接受者、内容格式可以直接用全局变量，重点是配置一下发送触发条件。

6. 安全性配置
    经过以上配置进行一次构建就会发现，Jenkins可以看到太多内容了，包括pull到的源码，所以非常有必要增加权限控制。进入“系统管理”->“Configure Global Security”中进行如下步骤：
    1. 启用安全；

    2. Jenkins专有用户数据库，先允许用户注册；
    3. 授权策略选择“安全矩阵”，新加一个“admin”的用户，把所有权限都开给admin用户；
    4. 在主界面的用户中找到admin，进行配置，设置登陆密码；
    5. 先重新登陆测试一下是否admin正常，没有问题就关闭允许用户注册，把匿名用户的所有权限都去掉。

7. 自动化部署
    这里我没有让Jenkins每次测试都去部署，一方面是考虑到单元测试基本已经满足需要了，另一方面因为测试太频繁了，一直部署也搞得Stage测试环境要经常重启，反而影响正常的人工测试。所以自己写了个脚本，在必要的时候去运行一下去自动完成整个部署工作。
#!/bin/sh 
  
# update code 
git pull 
  
# package 
mvn clean 
mvn package -Dmaven.test.skip=true
  
# deploy 
WAR=`ls target | grep war` 
TOMCAT=/home/test/apache-tomcat-6.0.41 
mv target/$WAR $TOMCAT 
cd $TOMCAT 
# invoke another deploy script 
sh deploy-war.sh $WAR webapps

8. 一个非常蛋疼的问题
    这个和以上问题都无关，只是极其不解的是这个错误在Windows下不出现，在Linux下打成War也不会出现，只有在Linux下直接执行Maven test就会出错。其实问题的根源就是配置书写不够规范，但是错误出现的不一致性实在让人蛋疼。报错如下：
1 org.apache.ibatis.binding.BindingException: Invalid bound statement (not found): xxx

    这个就是Mybatis找不到绑定的类，但是xml是正确打包的，怎么看都是没大问题，并且windows也是对的，最后发现是我在写模糊路径的时候，classpath后面必须要加个*才是标准写法，正确写法如下：

    <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"> 
        <property name="basePackage" value="com.gzxitao.demo.*.dao"/> 
    </bean> 
  
    <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> 
        <property name="dataSource" ref="dataSource"/> 
        <property name="configLocation" value="classpath:configuration.xml"/> 
        <!-- 这里是要扫描多个目录下的文件，必须声明成“classpath*”，否则在某些情况下会报错 -->
        <property name="mapperLocations" value="classpath*:com/gzxitao/demo/*/dao/*.xml" /> 
    </bean>

Maven权威指南_中文完整版清晰PDF  http://www.linuxidc.com/Linux/2014-06/103690.htm

Maven 3.1.0 发布，项目构建工具 http://www.linuxidc.com/Linux/2013-07/87403.htm

Linux 安装 Maven http://www.linuxidc.com/Linux/2013-05/84489.htm

Maven3.0 配置和简单使用 http://www.linuxidc.com/Linux/2013-04/82939.htm

Ubuntu下搭建sun-jdk和Maven2 http://www.linuxidc.com/Linux/2012-12/76531.htm

Maven使用入门 http://www.linuxidc.com/Linux/2012-11/74354.htm

Jenkins的分布式构建及部署——节点  http://www.linuxidc.com/Linux/2015-05/116903.htm

Jenkins 的详细介绍：请点这里
Jenkins 的下载地址：请点这里

本文永久更新链接地址：http://www.linuxidc.com/Linux/2015-06/118606.htm

《目录》

一、安装Jenkins

二、配置Jenkins

三、自动编译

四、自动测试

五、自动部署

一、安装Jenkins

地址http://mirrors.jenkins-ci.org/下载适合的Jenkins版本。

Windows最新稳定版的Jenkins地址为：http://mirrors.jenkins-ci.org/windows-stable/jenkins-1.409.1.zip

把Jenkins 1.409.1版解压，把得到的war包直接扔到tomcat下，启动tomcat，Jenkins就安装完毕，是不是很简单啊。

二、配置Jenkins

1、打开http://10.3.15.78:8080/jenkins/，第一次进入里面没有数据，我们需要创建job，我们这有2个项目，需要创建2个job。http://10.3.34.163:9890/jenkins/

2、点击左上角的new job，在new job页面需要选择job的类型，Jenkins支持几种类型，我们选择“构建一个maven2/3项目”

3、点击OK按钮后，进会进入详细配置界面，详细配置界面的配置项很多，不过不用怕，大部分使用默认配置就可以了，下面就说说我们需要修改的几个地方：

3.1）Source Code Management

因为我们使用SVN管理源码，所以这里选择Subversion，并在Repository URL中输入我们的SVN地址：

http://10.3.34.163:9880/XXXX/trunk/

输入SVN库的URL地址后，Jenkins会自动验证地址，并给予提示。

点击红色字体部分的enter credential链接，进入页面

设置好访问SVN库的用户名和密码后，点击OK按钮

设置成功。点击Close按钮，返回之前的Source Code Management页面。此时不再有红色警告信息了。

3.2）配置自动构建的计划，假设我们想让项目中每天12点和晚上8点自动构建一次，只需要在Build Triggers中选择Build periodically，并在Schedule中输入 0 12,20 * * *。

我配置的是每晚8点自动构建

注：Schedule的配置规则是有5个空格隔开的字符组成，从左到右分别代表：分时天月年。*代表所有，0 12,20 * * * 表示“在任何年任何月任何天的12和20点0分”进行构建。

3.3）配置到这里，可能有人发现在Build配置节点，有红色错误信息，提示

Jenkins needs to know where your Maven2 is installed.
Please do so from the system configuration.

是因为Jenkins找不到maven的原因，点击"system configuration"，是system configuration的maven配置中添加maven目录就OK。

我设置了JRE 6和MAVEN 3的安装目录。

点击左下角的SAVE按钮，保存设置。

3.4）保存好所有配置后，我们第1个job就算是完成了。

3.5）创建第2个job，配置和上面的配置相同。只需把svn地址改成：http://localhost/svn/Web

三、自动编译

在经过上面的配置后，回到Jenkins首页，在首页可以看到刚才添加的2个job

点击某1个job后后面的"Schedule a build"图片手动构建，点击完后，会在左边的Build Queue或者Build Executor Status显示正在构建的任务，在自动构建完后，刷新页面，就可以看到构建结果了，如何某个项目构建失败，点击项目后面的构建数字(从1开始递增)进入项目的"Console Output "可以查看项目构建失败的原因。当然我们也可以配置把构建失败的结果发到邮箱。

到目前为止，1个简单的自动构建环境就搭建好了，很简单吧。

简介

awk是一个强大的文本分析工具，相对于grep的查找，sed的编辑，awk在其对数据分析并生成报告时，显得尤为强大。简单来说awk就是把文件逐行的读入，以空格为默认分隔符将每行切片，切开的部分再进行各种分析处理。

awk有3个不同版本: awk、nawk和gawk，未作特别说明，一般指gawk，gawk 是 AWK 的 GNU 版本。

awk其名称得自于它的创始人 Alfred Aho 、Peter Weinberger 和 Brian Kernighan 姓氏的首个字母。实际上 AWK 的确拥有自己的语言： AWK 程序设计语言 ， 三位创建者已将它正式定义为“样式扫描和处理语言”。它允许您创建简短的程序，这些程序读取输入文件、为数据排序、处理数据、对输入执行计算以及生成报表，还有无数其他的功能。

使用方法

awk '{pattern + action}' {filenames}

尽管操作可能会很复杂，但语法总是这样，其中 pattern 表示 AWK 在数据中查找的内容，而 action 是在找到匹配内容时所执行的一系列命令。花括号（{}）不需要在程序中始终出现，但它们用于根据特定的模式对一系列指令进行分组。 pattern就是要表示的正则表达式，用斜杠括起来。

awk语言的最基本功能是在文件或者字符串中基于指定规则浏览和抽取信息，awk抽取信息后，才能进行其他文本操作。完整的awk脚本通常用来格式化文本文件中的信息。

通常，awk是以文件的一行为处理单位的。awk每接收文件的一行，然后执行相应的命令，来处理文本。

调用awk

有三种方式调用awk

1.命令行方式 awk [-F  field-separator]  'commands'  input-file(s) 其中，commands 是真正awk命令，[-F域分隔符]是可选的。 input-file(s) 是待处理的文件。 在awk中，文件的每一行中，由域分隔符分开的每一项称为一个域。通常，在不指名-F域分隔符的情况下，默认的域分隔符是空格。  2.shell脚本方式 将所有的awk命令插入一个文件，并使awk程序可执行，然后awk命令解释器作为脚本的首行，一遍通过键入脚本名称来调用。 相当于shell脚本首行的：#!/bin/sh 可以换成：#!/bin/awk  3.将所有的awk命令插入一个单独文件，然后调用： awk -f awk-script-file input-file(s) 其中，-f选项加载awk-script-file中的awk脚本，input-file(s)跟上面的是一样的。

 本章重点介绍命令行方式。

入门实例

假设last -n 5的输出如下

[root@www ~]# last -n 5 <==仅取出前五行 root     pts/1   192.168.1.100  Tue Feb 10 11:21   still logged in root     pts/1   192.168.1.100  Tue Feb 10 00:46 - 02:28  (01:41) root     pts/1   192.168.1.100  Mon Feb  9 11:41 - 18:30  (06:48) dmtsai   pts/1   192.168.1.100  Mon Feb  9 11:41 - 11:41  (00:00) root     tty1                   Fri Sep  5 14:09 - 14:10  (00:01)

如果只是显示最近登录的5个帐号

#last -n 5 | awk  '{print $1}'
root
root
root
dmtsai
root

awk工作流程是这样的：读入有'\n'换行符分割的一条记录，然后将记录按指定的域分隔符划分域，填充域，$0则表示所有域,$1表示第一个域,$n表示第n个域。默认域分隔符是"空白键" 或 "[tab]键",所以$1表示登录用户，$3表示登录用户ip,以此类推。

如果只是显示/etc/passwd的账户

#cat /etc/passwd |awk  -F ':'  '{print $1}'   root daemon bin sys

这种是awk+action的示例，每行都会执行action{print $1}。

-F指定域分隔符为':'。

如果只是显示/etc/passwd的账户和账户对应的shell,而账户与shell之间以tab键分割

#cat /etc/passwd |awk  -F ':'  '{print $1"\t"$7}' root    /bin/bash daemon  /bin/sh bin     /bin/sh sys     /bin/sh

如果只是显示/etc/passwd的账户和账户对应的shell,而账户与shell之间以逗号分割,而且在所有行添加列名name,shell,在最后一行添加"blue,/bin/nosh"。

cat /etc/passwd |awk  -F ':'  'BEGIN {print "name,shell"}  {print $1","$7} END {print "blue,/bin/nosh"}' name,shell root,/bin/bash daemon,/bin/sh bin,/bin/sh sys,/bin/sh .... blue,/bin/nosh

awk工作流程是这样的：先执行BEGING，然后读取文件，读入有/n换行符分割的一条记录，然后将记录按指定的域分隔符划分域，填充域，$0则表示所有域,$1表示第一个域,$n表示第n个域,随后开始执行模式所对应的动作action。接着开始读入第二条记录······直到所有的记录都读完，最后执行END操作。

搜索/etc/passwd有root关键字的所有行

#awk -F: '/root/' /etc/passwd root:x:0:0:root:/root:/bin/bash

这种是pattern的使用示例，匹配了pattern(这里是root)的行才会执行action(没有指定action，默认输出每行的内容)。

搜索支持正则，例如找root开头的: awk -F: '/^root/' /etc/passwd

搜索/etc/passwd有root关键字的所有行，并显示对应的shell

# awk -F: '/root/{print $7}' /etc/passwd              /bin/bash

 这里指定了action{print $7}

awk内置变量

awk有许多内置变量用来设置环境信息，这些变量可以被改变，下面给出了最常用的一些变量。

ARGC               命令行参数个数 ARGV               命令行参数排列 ENVIRON            支持队列中系统环境变量的使用 FILENAME           awk浏览的文件名 FNR                浏览文件的记录数 FS                 设置输入域分隔符，等价于命令行 -F选项 NF                 浏览记录的域的个数 NR                 已读的记录数 OFS                输出域分隔符 ORS                输出记录分隔符 RS                 控制记录分隔符

 此外,$0变量是指整条记录。$1表示当前行的第一个域,$2表示当前行的第二个域,......以此类推。

统计/etc/passwd:文件名，每行的行号，每行的列数，对应的完整行内容:

#awk  -F ':'  '{print "filename:" FILENAME ",linenumber:" NR ",columns:" NF ",linecontent:"$0}' /etc/passwd filename:/etc/passwd,linenumber:1,columns:7,linecontent:root:x:0:0:root:/root:/bin/bash filename:/etc/passwd,linenumber:2,columns:7,linecontent:daemon:x:1:1:daemon:/usr/sbin:/bin/sh filename:/etc/passwd,linenumber:3,columns:7,linecontent:bin:x:2:2:bin:/bin:/bin/sh filename:/etc/passwd,linenumber:4,columns:7,linecontent:sys:x:3:3:sys:/dev:/bin/sh

使用printf替代print,可以让代码更加简洁，易读

 awk  -F ':'  '{printf("filename:%10s,linenumber:%s,columns:%s,linecontent:%s\n",FILENAME,NR,NF,$0)}' /etc/passwd

print和printf

awk中同时提供了print和printf两种打印输出的函数。

其中print函数的参数可以是变量、数值或者字符串。字符串必须用双引号引用，参数用逗号分隔。如果没有逗号，参数就串联在一起而无法区分。这里，逗号的作用与输出文件的分隔符的作用是一样的，只是后者是空格而已。

printf函数，其用法和c语言中printf基本相似,可以格式化字符串,输出复杂时，printf更加好用，代码更易懂。

 awk编程

 变量和赋值

除了awk的内置变量，awk还可以自定义变量。

下面统计/etc/passwd的账户人数

awk '{count++;print $0;} END{print "user count is ", count}' /etc/passwd root:x:0:0:root:/root:/bin/bash ...... user count is  40

count是自定义变量。之前的action{}里都是只有一个print,其实print只是一个语句，而action{}可以有多个语句，以;号隔开。

这里没有初始化count，虽然默认是0，但是妥当的做法还是初始化为0:

awk 'BEGIN {count=0;print "[start]user count is ", count} {count=count+1;print $0;} END{print "[end]user count is ", count}' /etc/passwd [start]user count is  0 root:x:0:0:root:/root:/bin/bash ... [end]user count is  40

统计某个文件夹下的文件占用的字节数

ls -l |awk 'BEGIN {size=0;} {size=size+$5;} END{print "[end]size is ", size}'
[end]size is  8657198

如果以M为单位显示:

ls -l |awk 'BEGIN {size=0;} {size=size+$5;} END{print "[end]size is ", size/1024/1024,"M"}' 
[end]size is  8.25889 M

注意，统计不包括文件夹的子目录。

条件语句

 awk中的条件语句是从C语言中借鉴来的，见如下声明方式：

if (expression) {     statement;     statement;     ... ... }  if (expression) {     statement; } else {     statement2; }  if (expression) {     statement1; } else if (expression1) {     statement2; } else {     statement3; }

统计某个文件夹下的文件占用的字节数,过滤4096大小的文件(一般都是文件夹):

ls -l |awk 'BEGIN {size=0;print "[start]size is ", size} {if($5!=4096){size=size+$5;}} END{print "[end]size is ", size/1024/1024,"M"}' 
[end]size is  8.22339 M

循环语句

awk中的循环语句同样借鉴于C语言，支持while、do/while、for、break、continue，这些关键字的语义和C语言中的语义完全相同。

数组

  因为awk中数组的下标可以是数字和字母，数组的下标通常被称为关键字(key)。值和关键字都存储在内部的一张针对key/value应用hash的表格里。由于hash不是顺序存储，因此在显示数组内容时会发现，它们并不是按照你预料的顺序显示出来的。数组和变量一样，都是在使用时自动创建的，awk也同样会自动判断其存储的是数字还是字符串。一般而言，awk中的数组用来从记录中收集信息，可以用于计算总和、统计单词以及跟踪模板被匹配的次数等等。

显示/etc/passwd的账户

awk -F ':' 'BEGIN {count=0;} {name[count] = $1;count++;}; END{for (i = 0; i < NR; i++) print i, name[i]}' /etc/passwd 0 root 1 daemon 2 bin 3 sys 4 sync 5 games ......

这里使用for循环遍历数组

awk编程的内容极多，这里只罗列简单常用的用法，更多请参考 http://www.gnu.org/software/gawk/manual/gawk.html

用途说明

在执行Linux命令时，我们可以把输出重定向到文件中，比如 ls >a.txt，这时我们就不能看到输出了，如果我们既想把输出保存到文件中，又想在屏幕上看到输出内容，就可以使用tee命令了。tee命令读取标准输入，把这些内容同时输出到标准输出和（多个）文件中（read from standard input and write to standard output and files. Copy standard input to each FILE, and also to standard output. If a FILE is -, copy again to standard output.）。在info tee中说道：tee命令可以重定向标准输出到多个文件（`tee': Redirect output to multiple files. The `tee' command copies standard input to standard output and also to any files given as arguments.  This is useful when you want not only to send some data down a pipe, but also to save a copy.）。要注意的是：在使用管道线时，前一个命令的标准错误输出不会被tee读取。

常用参数

格式：tee

只输出到标准输出，因为没有指定文件嘛。

格式：tee file

输出到标准输出的同时，保存到文件file中。如果文件不存在，则创建；如果已经存在，则覆盖之。（If a file being written to does not already exist, it is created. If a file being written to already exists, the data it previously
contained is overwritten unless the `-a' option is used.）

格式：tee -a file

输出到标准输出的同时，追加到文件file中。如果文件不存在，则创建；如果已经存在，就在末尾追加内容，而不是覆盖。

格式：tee -

输出到标准输出两次。（A FILE of `-' causes `tee' to send another copy of input to standard output, but this is typically not that useful as the copies are interleaved.）

格式：tee file1 file2 -

输出到标准输出两次，同时保存到file1和file2中。

一 初级

1）Notepad++ （编辑和查看Perl）

2）Komobo Edit （编辑和执行Perl） 

二 高级

A  Perl Express

主页：http://www.perl-express.com/

使用： 很简单

B Eclipse+EPIC+PadWalker

a) 下载解压Eclipse

b）下载EPIC插件之设置 (help->install new software)

c）下载EPIC插件之下载 

d）EPIC设置（菜单windows->preferences）

c）下载perl模块PadWalker (用来在debug时显示变量值)

 ppm install PadWalker 或cpan> install PadWalker （注意模块名字的大小写）

d）运行和调试perl 

完！ 

也可以使用防止SQL注入PreparedStatement方法

[java] view plaincopy

1. PreparedStatement stmt = null;  
2. ResultSet res = null;  
3. Connection conn = null;  
4. CallableStatement proc = null;  
5. String sql = " select T.REC_NO, T.AIRLINE,T.DEPARTURE,T.ARRIVAL from CDP_MAIN_ORDER t where t.departure=upper(?)";  
6.   
7. try {  
8.     Class.forName(driver);  
9.     conn = DriverManager.getConnection(url, "abc123", "abc123");  
10.     stmt = conn.prepareStatement(sql);  
11.     stmt.setString(1, "pek");  
12.     res = stmt.executeQuery();  

我在上传些代码的时候，有时候会遇到“git did not exit cleanly (exit code 128)”错误。通常都是网络原因。

找了网上解决的方法：

1、鼠标右键 -> TortoiseGit -> Settings -> Network

2、SSH client was pointing to C:\Program Files\TortoiseGit\bin\TortoisePlink.exe

3、Changed path to C:\Program Files (x86)\Git\bin\ssh.exe

JDK内置工具使用

一、javah命令(C Header and Stub File Generator)

二、jps命令(Java Virtual Machine Process Status Tool)

三、jstack命令(Java Stack Trace)

四、jstat命令(Java Virtual Machine Statistics Monitoring Tool)

五、jmap命令(Java Memory Map)

六、jinfo命令(Java Configuration Info)

七、jconsole命令(Java Monitoring and Management Console)

八、jvisualvm命令(Java Virtual Machine Monitoring, Troubleshooting, and Profiling Tool)

九、jhat命令(Java Heap Analyse Tool)

十、Jdb命令(The Java Debugger)

十一、Jstatd命令(Java Statistics Monitoring Daemon)

jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64"，Windows的jstack使用方式只支持以下的这种方式：
     jstack [-l][F] pid
     如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。进程处于hung死状态可以用-F强制打出stack。
     dump 文件里，值得关注的线程状态有：
     死锁，Deadlock（重点关注）
     执行中，Runnable  
     等待资源，Waiting on condition（重点关注）
     等待获取监视器，Waiting on monitor entry（重点关注）
     暂停，Suspended
     对象等待中，Object.wait() 或 TIMED_WAITING
     阻塞，Blocked（重点关注） 
     停止，Parked

在摘了另一篇博客的三种场景：

实例一：Waiting to lock 和 Blocked

"RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000]    java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.log4j.Category.callAppenders(Category.java:201) - waiting to lock <0x00000000acf4d0c0> (a org.apache.log4j.Logger) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:234) at com.tuan.core.common.lang.cache.remote.SpyMemcachedClient.get(SpyMemcachedClient.java:110)

说明：
1）线程状态是 Blocked，阻塞状态。说明线程等待资源超时！
2）“ waiting to lock <0x00000000acf4d0c0>”指，线程在等待给这个 0x00000000acf4d0c0 地址上锁（英文可描述为：trying to obtain  0x00000000acf4d0c0 lock）。
3）在 dump 日志里查找字符串 0x00000000acf4d0c0，发现有大量线程都在等待给这个地址上锁。如果能在日志里找到谁获得了这个锁（如locked < 0x00000000acf4d0c0 >），就可以顺藤摸瓜了。
4）“waiting for monitor entry”说明此线程通过 synchronized(obj) {……} 申请进入了临界区，从而进入了下图1中的“Entry Set”队列，但该 obj 对应的 monitor 被其他线程拥有，所以本线程在 Entry Set 队列中等待。
5）第一行里，"RMI TCP Connection(267865)-172.16.5.25"是 Thread Name 。tid指Java Thread id。nid指native线程的id。prio是线程优先级。[0x00007fd4f8684000]是线程栈起始地址。

实例二：Waiting on condition 和 TIMED_WAITING

"RMI TCP Connection(idle)" daemon prio=10 tid=0x00007fd50834e800 nid=0x56b2 waiting on condition [0x00007fd4f1a59000]    java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for  <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323) at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:662)

说明：

1）“TIMED_WAITING (parking)”中的 timed_waiting 指等待状态，但这里指定了时间，到达指定的时间后自动退出等待状态；parking指线程处于挂起中。

2）“waiting on condition”需要与堆栈中的“parking to wait for  <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)”结合来看。首先，本线程肯定是在等待某个条件的发生，来把自己唤醒。其次，SynchronousQueue 并不是一个队列，只是线程之间移交信息的机制，当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务，因此这就是本线程在等待的条件。
3）别的就看不出来了。

实例三：in Obejct.wait() 和 TIMED_WAITING

"RMI RenewClean-[172.16.5.19:28475]" daemon prio=10 tid=0x0000000041428800 nid=0xb09 in Object.wait() [0x00007f34f4bd0000]    java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock) at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:516) at java.lang.Thread.run(Thread.java:662)

说明：

1）“TIMED_WAITING (on object monitor)”，对于本例而言，是因为本线程调用了 java.lang.Object.wait(long timeout) 而进入等待状态。

2）“Wait Set”中等待的线程状态就是“ in Object.wait() ”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ，“ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态。

3）RMI RenewClean 是 DGCClient 的一部分。DGC 指的是 Distributed GC，即分布式垃圾回收。

4）请注意，是先 locked <0x00000000aa672478>，后 waiting on <0x00000000aa672478>，之所以先锁再等同一个对象，请看下面它的代码实现：
static private class  Lock { };
private Lock lock = new Lock();
public Reference<? extends T> remove(long timeout)
{
    synchronized (lock) {
        Reference<? extends T> r = reallyPoll();
        if (r != null) return r;
        for (;;) {
            lock.wait(timeout);
            r = reallyPoll();
            ……
       }
}
即，线程的执行中，先用 synchronized 获得了这个对象的 Monitor（对应于  locked <0x00000000aa672478> ）；当执行到 lock.wait(timeout);，线程就放弃了 Monitor 的所有权，进入“Wait Set”队列（对应于  waiting on <0x00000000aa672478> ）。
5）从堆栈信息看，是正在清理 remote references to remote objects ，引用的租约到了，分布式垃圾回收在逐一清理呢。

参考：

命令汇总：http://blog.csdn.net/fenglibing/article/details/6411940
三种实例：http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html

1. 如何加大tomcat连接数

在tomcat配置文件server.xml中的<Connector ... />配置中，和连接数相关的参数有：

maxThreads ： tomcat起动的最大线程数，即同时处理的任务个数，默认值为200。

minProcessors：最小空闲连接线程数，用于提高系统处理性能，默认值为10 。

maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为75 。

acceptCount： 当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100。

minSpareThreads ：Tomcat初始化时创建的线程数。

maxSpareThreads ：一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。

enableLookups：是否反查域名，取值为：true或false。 缺省值为false,表示使用客户端主机名的DNS解析功能，被ServletRequest.getRemoteHost方法调用。

connectionTimeout：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。

其中和最大连接数相关的参数为maxProcessors和acceptCount。如果要加大并发连接数，应同时加大这两个参数。

web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

Unix中如何设置这些参数，请参阅Unix常用监控和管理命令

tomcat5中的配置示例：

<Connector port="8090" maxHttpHeaderSize="8169"  maxThreads="1000" minSpareThreads="75" maxSpareThreads="300"               enableLookups="false" redirectPort="8649" acceptCount="100" connectionTimeout="50000" disableUploadTimeout="true" URIEncoding="GBK"/>

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" minProcessors="10" maxProcessors="1024" enableLookups="false" redirectPort="8443" acceptCount="1024" debug="0" connectionTimeout="30000" /> 
对于其他端口的侦听配置，以此类推。
2. tomcat中如何禁止列目录下的文件

在{tomcat_home}/conf/web.xml中，把listings参数设置成false即可，如下：

<servlet> ... <init-param> <param-name>listings</param-name> <param-value>false</param-value> </init-param> ... </servlet>

3. 如何加大tomcat可以使用的内存

tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。
Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，增加如下设置：

JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】' 需要把这个两个参数值调大。

例如： JAVA_OPTS='-Xms256m -Xmx512m' 表示初始化内存为256MB，可以使用的最大内存为512MB 。

export JAVA_HOME='/home/ftpuser/xjSheetHome/java/jdk1.5.0_22/'

JAVA_OPTS="-Xms1500m -Xmx1500m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m -Dfile.encoding=GBK"

参数说明：

-Xms 是指设定程序启动时占用内存大小。一般来讲，大点，程序会启动的 快一点，但是也可能会导致机器暂时间变慢。

-Xmx 是指设定程序运行期间最大可占用的内存大小。如果程序运行需要占 用更多的内存，超出了这个设置值，就会抛出OutOfMemory 异常。

-Xss 是指设定每个线程的堆栈大小。这个就要依据你的程序，看一个线程 大约需要占用多少内存，可能会有多少线程同时运行等。

-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64 。

-XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。

<Context path="/Sheet" defaultSessionTimeOut="3600" docBase="/home/user/Sheet"  >
  <Resource name="jdbc/app" auth="Container"
                        type="javax.sql.DataSource"
                        username="SHEET" password="SHEET"
            driverClassName="oracle.jdbc.driver.OracleDriver"
            url="jdbc:oracle:thin:@136.24.248.106:1521:kf"
            maxActive="1000" maxIdle="75"/>
  <ResourceLink name="UserTransaction"
            global="UserTransaction"
            type="javax.transaction.UserTransaction"/>
</Context>
参数说明：
defaultSessionTimeOut：设置会话时间 单位为秒
maxActive ： 连接池的最大数据库连接数。设为0表示无限制。
maxIdle ：可以同时闲置在连接池中的连接的最大数  
maxWait ： 最大超时时间，以毫秒计

1.内存设置(VM参数调优)
(1). Windows环境下，是tomcat解压版(执行startup.bat启动tomcat) ,解决办法:
修改“%TOMCAT_HOME%\bin\catalina.bat”文件，在文件开头增加如下设置：
set JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=512m
备注：一定加在catalina.bat最前面。
(2). Windows环境下，是tomcat安装版(利用windows的系统服务启动tomcat),解决办法:
修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat6\Parameters\JavaOptions
原值为:
-Dcatalina.home=E:\Tomcat 6.0
-Dcatalina.base=E:\Tomcat 6.0
-Djava.endorsed.dirs=E:\Tomcat 6.0\common\endorsed
-Djava.io.tmpdir=E:\Tomcat 6.0\temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=E:\Tomcat 6.0\conf\logging.properties
加入：
Xms512m -Xmx512m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=512m
重起tomcat服务,设置生效。
(3). Linux环境下, ,解决办法:
修改“%TOMCAT_HOME%\bin\catalina.sh”文件，在文件开头增加如下设置：JAVA_OPTS=’-Xms256m -Xmx512m’

各参数详解：
-Xms：设置JVM初始内存大小(默认是物理内存的1/64)
-Xmx：设置JVM可以使用的最大内存(默认是物理内存的1/4，建议：物理内存80%)
-Xmn：设置JVM最小内存(128-256m就够了,一般不设置)
默认空余堆内存小于 40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、 -Xmx相等以避免在每次GC 后调整堆的大小。
在较大型的应用项目中，默认的内存是不够的，有可能导致系统无法运行。常见的问题是报Tomcat内存溢出错误“java.lang.OutOfMemoryError: Java heap space”，从而导致客户端显示500错误。

-XX:PermSize ：为JVM启动时Perm的内存大小
-XX:MaxPermSize ：为最大可占用的Perm内存大小(默认为32M)
-XX:MaxNewSize，默认为16M
PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现“java.lang.OutOfMemoryError: PermGen space”错误。
对于WEB项目，jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小，为了避免调整)，你可以使用更多的参数配置。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小,那么就会产生此错误信息了。
其它参数：
-XX:NewSize ：默认为2M，此值设大可调大新对象区，减少Full GC次数
-XX:NewRatio ：改变新旧空间的比例，意思是新空间的尺寸是旧空间的1/8（默认为8）
-XX:SurvivorRatio ：改变Eden对象空间和残存空间的尺寸比例，意思是Eden对象空
间的尺寸比残存空间大survivorRatio+2倍（缺省值是10）
-XX:userParNewGC 可用来设置并行收集【多CPU】
-XX:ParallelGCThreads 可用来增加并行度【多CPU】
-XXUseParallelGC 设置后可以使用并行清除收集器【多CPU】
2.修改tomcat让其支持NIO
修改前：
protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"/>
修改成支持NIO的类型，配置如下 ：
protocol="org.apache.coyote.http11.Http11NioProtocol " connectionTimeout="20000" redirectPort="8443" />
3.并发数设置
默认的tomcat配置，并发测试时，可能30个USER上去就当机了。
添加

maxThreads="600" //最大线程数
minSpareThreads="100" //初始化时创建的线程数
maxSpareThreads="500" //一旦线程超过这个值，Tomcat会关闭不需要的socket线程
acceptCount="700"//指定当所有可以使用的处理请求的线程数都被使用时，可以放到
处理队列中的请求数，超过这个数的请求将不予处理
connectionTimeout="20000"
redirectPort="8443" />

或者
name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="500" minSpareThreads="400" />

executor="tomcatThreadPool" port="80" protocol="HTTP/1.1" connectionTimeout="20000" enableLookups="false"
redirectPort="8443" URIEncoding="UTF-8" acceptCount="1000" />
4.Java虚拟机调优
应该选择SUN的JVM，在满足项目需要的前提下，尽量选用版本较高的JVM，一般来说高版本产品在速度和效率上比低版本会有改进。 JDK1.4比JDK1.3性能提高了近10%-20%，JDK1.5比JDK1.4性能提高25%-75%。
5.禁用DNS查询
设置enableLookups="false"：
enableLookups="false" redirectPort="8443" URIEncoding="UTF-8" acceptCount="1000" />
　当web应用程序向要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关闭 DNS查询，方式是修改server.xml文件中的enableLookups参数值为false。
6.设置解决乱码问题
URIEncoding="UTF-8" acceptCount="1000" />

二、TOMCAT内存监控

1.设置tomcat的perm size:

2.开启监控

在命令行输入jconsole，在弹出窗口中建立本地端口监控，如下图：

使用安装版Tomcat 6.0 ，打开tomcat界面选择java这一项，在java options:
加入

Java代码  

1. -Djava.rmi.server.hostname=127.0.0.1 
2. -Dcom.sun.management.jmxremote.port=8088 
3. -Dcom.sun.management.jmxremote.ssl=false 
4. -Dcom.sun.management.jmxremote.authenticate=false 

[java] view plaincopyprint?

1. -Djava.rmi.server.hostname=127.0.0.1  
2. -Dcom.sun.management.jmxremote.port=8088  
3. -Dcom.sun.management.jmxremote.ssl=false  
4. -Dcom.sun.management.jmxremote.authenticate=false  

使用jconsole 127.0.0.1:8088可以连接成功，也能看到jvm运行情况，
但此时访问已经部署的应用，却提示“无法显示网页”
今天又研究了一会，猜想了一下是不是这个端口独占的，不能和应用冲突，把Dcom.sun.management.jmxremote.port=8088 改为80， 重启tomcat 果然，应用可以访问。之后去网上看来些相关信息，确实为两个端口，不能占用。

首先我们先介绍一下为什么要让 Apache 与 Tomcat 之间进行连接。事实上 Tomcat 本身已经提供了 HTTP 服务，该服务默认的端口是 8080，装好 tomcat 后通过 8080 端口可以直接使用 Tomcat 所运行的应用程序，你也可以将该端口改为 80。

既然 Tomcat 本身已经可以提供这样的服务，我们为什么还要引入 Apache 或者其他的一些专门的 HTTP 服务器呢？原因有下面几个：

1. 提升对静态文件的处理性能

2. 利用 Web 服务器来做负载均衡以及容错

3. 无缝的升级应用程序

这三点对一个 web 网站来说是非常之重要的，我们希望我们的网站不仅是速度快，而且要稳定，不能因为某个 Tomcat 宕机或者是升级程序导致用户访问不了，而能完成这几个功能的、最好的 HTTP 服务器也就只有 apache 的 http server 了，它跟 tomcat 的结合是最紧密和可靠的。

接下来我们介绍三种方法将 apache 和 tomcat 整合在一起。

JK

这是最常见的方式，你可以在网上找到很多关于配置JK的网页，当然最全的还是其官方所提供的文档。JK 本身有两个版本分别是 1 和 2，目前 1 最新的版本是 1.2.19，而版本 2 早已经废弃了，以后不再有新版本的推出了，所以建议你采用版本 1。

JK 是通过 AJP 协议与 Tomcat 服务器进行通讯的，Tomcat 默认的 AJP Connector 的端口是 8009。JK 本身提供了一个监控以及管理的页面 jkstatus，通过 jkstatus 可以监控 JK 目前的工作状态以及对到 tomcat 的连接进行设置，如下图所示：

图 1：监控以及管理的页面 jkstatus

在这个图中我们可以看到当前JK配了两个连接分别到 8109 和 8209 端口上，目前 s2 这个连接是停止状态，而 s1 这个连接自上次重启后已经处理了 47 万多个请求，流量达到 6.2 个 G，最大的并发数有 13 等等。我们也可以利用 jkstatus 的管理功能来切换 JK 到不同的 Tomcat 上，例如将 s2 启用，并停用 s1，这个在更新应用程序的时候非常有用，而且整个切换过程对用户来说是透明的，也就达到了无缝升级的目的。关于 JK 的配置文章网上已经非常多了，这里我们不再详细的介绍整个配置过程，但我要讲一下配置的思路，只要明白了配置的思路，JK 就是一个非常灵活的组件。

JK 的配置最关键的有三个文件，分别是

httpd.conf 
Apache 服务器的配置文件，用来加载 JK 模块以及指定 JK 配置文件信息

workers.properties
到 Tomcat 服务器的连接定义文件

uriworkermap.properties
URI 映射文件，用来指定哪些 URL 由 Tomcat 处理，你也可以直接在 httpd.conf 中配置这些 URI，但是独立这些配置的好处是 JK 模块会定期更新该文件的内容，使得我们修改配置的时候无需重新启动 Apache 服务器。

其中第二、三个配置文件名都可以自定义。下面是一个典型的 httpd.conf 对 JK 的配置

# (httpd.conf) # 加载 mod_jk 模块 LoadModule jk_module modules/mod_jk.so  # # Configure mod_jk #  JkWorkersFile conf/workers.properties JkMountFile conf/uriworkermap.properties JkLogFile logs/mod_jk.log JkLogLevel warn

接下来我们在 Apache 的 conf 目录下新建两个文件分别是 workers.properties、uriworkermap.properties。这两个文件的内容大概如下

# # workers.properties #   # list the workers by name  worker.list=DLOG4J, status  # localhost server 1 # ------------------------ worker.s1.port=8109 worker.s1.host=localhost worker.s1.type=ajp13  # localhost server 2 # ------------------------ worker.s2.port=8209 worker.s2.host=localhost worker.s2.type=ajp13 worker.s2.stopped=1  worker.DLOG4J.type=lb worker.retries=3 worker.DLOG4J.balanced_workers=s1, s2 worker.DLOG4J.sticky_session=1  worker.status.type=status

以上的 workers.properties 配置就是我们前面那个屏幕抓图的页面所用的配置。首先我们配置了两个类型为 ajp13 的 worker 分别是 s1 和 s2，它们指向同一台服务器上运行在两个不同端口 8109 和 8209 的 Tomcat 上。接下来我们配置了一个类型为 lb（也就是负载均衡的意思）的 worker，它的名字是 DLOG4J，这是一个逻辑的 worker，它用来管理前面配置的两个物理连接 s1 和 s2。最后还配置了一个类型为 status 的 worker，这是用来监控 JK 本身的模块。有了这三个 worker 还不够，我们还需要告诉 JK，哪些 worker 是可用的，所以就有 worker.list = DLOG4J, status 这行配置。

接下来便是 URI 的映射配置了，我们需要指定哪些链接是由 Tomcat 处理的，哪些是由 Apache 直接处理的，看看下面这个文件你就能明白其中配置的意义

/*=DLOG4J /jkstatus=status  !/*.gif=DLOG4J !/*.jpg=DLOG4J !/*.png=DLOG4J !/*.css=DLOG4J !/*.js=DLOG4J !/*.htm=DLOG4J !/*.html=DLOG4J

相信你已经明白了一大半了：所有的请求都由 DLOG4J 这个 worker 进行处理，但是有几个例外，/jkstatus 请求由 status 这个 worker 处理。另外这个配置中每一行数据前面的感叹号是什么意思呢？感叹号表示接下来的 URI 不要由 JK 进行处理，也就是 Apache 直接处理所有的图片、css 文件、js 文件以及静态 html 文本文件。

通过对 workers.properties 和 uriworkermap.properties 的配置，可以有各种各样的组合来满足我们前面提出对一个 web 网站的要求。您不妨动手试试！

回页首

http_proxy

这是利用 Apache 自带的 mod_proxy 模块使用代理技术来连接 Tomcat。在配置之前请确保是否使用的是 2.2.x 版本的 Apache 服务器。因为 2.2.x 版本对这个模块进行了重写，大大的增强了其功能和稳定性。

http_proxy 模式是基于 HTTP 协议的代理，因此它要求 Tomcat 必须提供 HTTP 服务，也就是说必须启用 Tomcat 的 HTTP Connector。一个最简单的配置如下

ProxyPass /images ! ProxyPass /css ! ProxyPass /js ! ProxyPass / http://localhost:8080/

在这个配置中，我们把所有 http://localhost 的请求代理到 http://localhost:8080/ ，这也就是 Tomcat 的访问地址，除了 images、css、js 几个目录除外。我们同样可以利用 mod_proxy 来做负载均衡，再看看下面这个配置

ProxyPass /images ! ProxyPass /css !  ProxyPass /js !  ProxyPass / balancer://example/ <Proxy balancer://example/> BalancerMember http://server1:8080/ BalancerMember http://server2:8080/ BalancerMember http://server3:8080/ </Proxy>

配置比 JK 简单多了，而且它也可以通过一个页面来监控集群运行的状态，并做一些简单的维护设置。

图 2：监控集群运行状态

回页首

ajp_proxy

ajp_proxy 连接方式其实跟 http_proxy 方式一样，都是由 mod_proxy 所提供的功能。配置也是一样，只需要把 http:// 换成 ajp:// ，同时连接的是 Tomcat 的 AJP Connector 所在的端口。上面例子的配置可以改为：

ProxyPass /images ! ProxyPass /css !  ProxyPass /js !  ProxyPass / balancer://example/ <Proxy balancer://example/> BalancerMember ajp://server1:8080/ BalancerMember ajp://server2:8080/ BalancerMember ajp://server3:8080/ </Proxy>

采用 proxy 的连接方式，需要在 Apache 上加载所需的模块，mod_proxy 相关的模块有 mod_proxy.so、mod_proxy_connect.so、mod_proxy_http.so、mod_proxy_ftp.so、mod_proxy_ajp.so， 其中 mod_proxy_ajp.so 只在 Apache 2.2.x 中才有。如果是采用 http_proxy 方式则需要加载 mod_proxy.so 和 mod_proxy_http.so；如果是 ajp_proxy 则需要加载 mod_proxy.so 和 mod_proxy_ajp.so这两个模块。

回页首

三者比较

相对于 JK 的连接方式，后两种在配置上是比较简单的，灵活性方面也一点都不逊色。但就稳定性而言就不像 JK 这样久经考验，毕竟 Apache 2.2.3 推出的时间并不长，采用这种连接方式的网站还不多，因此，如果是应用于关键的互联网网站，还是建议采用 JK 的连接方式。

有段时间没用maven了，最近使用maven下载jar包时速度缓慢，最初以为是自己网速的问题，后来确定是访问maven的central repository端速度缓慢。在网上找到了一个maven repository的中国镜像，速度相当不错。特此收藏。

<mirror>

      <id>CN</id>
      <name>OSChina Central</name>                                                                                                                       
      <url>http://maven.oschina.net/content/groups/public/</url>
      <mirrorOf>central</mirrorOf>

    </mirror>

========================================================

OSChina Maven 库使用帮助


==================其他maven仓库镜像==========================

<mirror>  
      <id>repo2</id>  
      <mirrorOf>central</mirrorOf>  
      <name>Human Readable Name for this Mirror.</name>  
      <url>http://repo2.maven.org/maven2/</url>  
</mirror>  
<mirror>  
      <id>net-cn</id>  
      <mirrorOf>central</mirrorOf>  
      <name>Human Readable Name for this Mirror.</name>  
      <url>http://maven.net.cn/content/groups/public/</url>   
</mirror>  
<mirror>  
      <id>ui</id>  
      <mirrorOf>central</mirrorOf>  
      <name>Human Readable Name for this Mirror.</name>  
     <url>http://uk.maven.org/maven2/</url>  
</mirror>  
<mirror>  
      <id>ibiblio</id>  
      <mirrorOf>central</mirrorOf>  
      <name>Human Readable Name for this Mirror.</name>  
     <url>http://mirrors.ibiblio.org/pub/mirrors/maven2/</url>  
</mirror>  
<mirror>  
      <id>jboss-public-repository-group</id>  
      <mirrorOf>central</mirrorOf>  
      <name>JBoss Public Repository Group</name>  
     <url>http://repository.jboss.org/nexus/content/groups/public</url>  
</mirror>

<mirror>  
      <id>JBossJBPM</id> 
　　　　<mirrorOf>central</mirrorOf> 
　　　　<name>JBossJBPM Repository</name> 
　　　　<url>https://repository.jboss.org/nexus/content/repositories/releases/</url>
</mirror>

在开发时，有时候可能需要根据不同的环境设置不同的系统参数，我们都知道，在使用java -jar命令时可以使用-D参数来设置运行时的系统变量，同样，在Eclipse中运行java程序时，我们怎么设置该系统变量呢？

另外，如果我们的程序需要输入运行参数，在Eclipse中如何配置？

答案很简单，具体步骤为：

在要运行的类上右键点击Run As-->Run Configurations...

在弹出界面中点击Arguments

然后弹出如下界面：

1.其中Program arguments栏里可以输入程序运行所需的参数，也就是main方法的参数，如果参数为多个，则用空格分开。

2.VM arguments里接收的是系统变量参数，系统变量输入格式为：-Dargname=argvalue，同样，多个参数之间用空格隔开。另外如果参数值中间有空格，则用引号括起来

示例程序代码如下：

Java代码  

1. /** 
2.  * ClassName: Main <br/> 
3.  * Function: Eclipse系统变量和运行参数. <br/> 
4.  * date: 2013-8-27 下午04:06:09 <br/> 
5.  * 
6.  * @author chenzhou1025@126.com 
7.  * @version  
8.  */  
9. public class Main {  
10.     public static void main(String[] args){  
11.         System.out.println("打印所有的参数:");  
12.         if(args.length>0){  
13.             for(int i=0;i<args.length;i++){  
14.                 System.out.println("第"+i+"个参数为:"+args[i]);  
15.             }  
16.         }  
17.         System.out.println("打印系统变量:");  
18.         String env = System.getProperty("service.env");  
19.         System.out.println("service.env:"+env);  
20.         String logpath = System.getProperty("logfile.path");  
21.         System.out.println("logfile.path:"+logpath);  
22.     }  
23. }  

运行程序，控制台输出如下：

Console代码  

1. 打印所有的参数:  
2. 第0个参数为:chenzhou  
3. 第1个参数为:chenzhou2  
4. 第2个参数为:chenzhou3  
5. 打印系统变量:  
6. service.env:DEV  
7. logfile.path:E:\u03\project\logs  

Mac下面除了用dmg、pkg来安装软件外，比较方便的还有用MacPorts来帮助你安装其他应用程序，跟BSD中的ports道理一样。MacPorts就像apt-get、yum一样，可以快速安装些软件。

下面将MacPorts的安装和使用方法记录在这里以备查。

访问官方网站http://www.macports.org/install.php，这里提供有dmg安装和源码安装两种方式，dmg就多说了，下载MacPorts-1.9.2-10.6-SnowLeopard.dmg，下一步下一步安装即可。

通过Source安装MacPorts

MacPorts使用
更新ports tree和MacPorts版本，强烈推荐第一次运行的时候使用-v参数，显示详细的更新过程。
sudo port -v selfupdate

搜索索引中的软件
port search name

安装新软件
sudo port install name

卸载软件
sudo port uninstall name

查看有更新的软件以及版本
port outdated

升级可以更新的软件
sudo port upgrade outdated

Eclipse的插件需要subclipse需要JavaHL，下面通过MacPorts来安装
sudo port install subversion-javahlbindings

EGIT下载地址：

一、Eclipse上安装GIT插件EGit

      Eclipse的版本eclipse-java-helios-SR2-win32.zip（在Eclipse3.3版本找不到对应的 EGit插件，无法安装）

EGit插件地址：http://download.eclipse.org/egit/updates

OK，随后连续下一步默认安装就可以，安装后进行重启Eclipse

二、在Eclipse中配置EGit

准备工作：需要在https://github.com 上注册账号

Preferences > Team > Git > Configuration

这里的user.name 是你在https://github.com上注册用户名

user.email是你在github上绑定的邮箱。在这里配置user.name即可

三、新建项目，并将代码提交到本地的GIT仓库中

1、新建项目 git_demo，并新建HelloWorld.java类

2、将git_demo项目提交到本地仓库，如下图

到此步，就成功创建GIT仓库。但文件夹处于untracked状态（文件夹中的符号”?”表示），下面我们需要提交代码到本地仓库，如下图

OK，这样代码提交到了本地仓库

四：将本地代码提交到远程的GIT仓库中

准备工作：在https://github.com上创建仓库

点击“Create repository” ，ok,这样在github上的仓库就创建好了。

注意创建好远程仓库后，点击进去，此时可以看到一个HTTP地址，如红线框，这个是你http协议的远程仓库地址

准备工作做好了，那开始将代码提交到远程仓库吧

OK，这样提交远程GIT就完成了，可以在https://github.com核对一下代码是否已经提交

注意的问题

   如果是首次提交会第一步：先在本地建立一个一样的仓库，称本地仓库。

          第二步：在本地进行commit操作将把更新提交到本地仓库；

          第三步： 将服务器端的更新pull到本地仓库进行合并，最后将合并好的本地仓库push到服务器端，这样就进行了一次远程提交。

  如果非首次提交同样的道理

          第一步：将修改的代码commit操作更新到本地仓库；

         第二步：第三步： 将服务器端的更新pull到本地仓库进行合并，最后将合并好的本地仓库push到服务器端

ImageView中XML属性src和background的区别：

background会根据ImageView组件给定的长宽进行拉伸，而src就存放的是原图的大小，不会进行拉伸。src是图片内容（前景），bg是背景，可以同时使用。

此外：scaleType只对src起作用；bg可设置透明度，比如在ImageButton中就可以用android:scaleType控制图片的缩放方式

如上所述，background设置的图片会跟View组件给定的长宽比例进行拉伸。举个例子， 36x36 px的图标放在 xhdpi 文件夹中，在854x480（FWVGA，对应hdpi）环境下，按照

xhdpi : hdpi : mdpi: ldip = 2 : 1.5 : 1 : 0.75

的比例计算，在FWVGA下，图标的实际大小应该是 27x27。

但是当我把它放到一个 layout_width = 96px, layout_height = 75px 的 LinearLayout，布局代码如下：

[html] view plaincopy

1. <LinearLayout android:gravity="center" android:layout_width="96px" android:layout_height="75px"  >  
2.     <ImageButton android:layout_width="wrap_content" android:layout_height="wrap_content" android:background="@drawable/toolbar_bg"/>      
3. </LinearLayout>  

实际情况是，我们得到的ImageButton的大小是 33x27，很明显width被拉伸了，这是我们不想看到的情况。

解决方案一：

代码中动态显式设置ImageButton的layout_width和layout_width，如下 

[java] view plaincopy

1. LinearLayout.LayoutParams layoutParam = new LinearLayout.LayoutParams(27, 27);  
2. layout.addView(imageButton, layoutParam);  

解决方案二：

在你通过setBackgroundResource()或者在xml设置android:background属性时，将你的background以XML Bitmap的形式定义，如下：

[html] view plaincopy

1. <?xml version="1.0" encoding="utf-8"?>  
2. <bitmap xmlns:android="http://schemas.android.com/apk/res/android"  
3.     android:id="@id/toolbar_bg_bmp"  
4.     android:src="@drawable/toolbar_bg"  
5.     android:tileMode="disabled" android:gravity="top" >  
6. </bitmap>  

    imageButton.setBackgroundResource(R.drawable.toolbar_bg_bmp)

或者

    <ImageButton ...  android:background="@drawable/toolbar_bg_bmp" ... />

若背景图片有多种状态，还可参照toolbar_bg_selector.xml：

[html] view plaincopy

1. <?xml version="1.0" encoding="utf-8"?>  
2. <selector xmlns:android="http://schemas.android.com/apk/res/android" >  
3.     <item android:state_pressed="true" >  
4.         <bitmap android:src="@drawable/toolbar_bg_sel" android:tileMode="disabled" android:gravity="top" />  
5.     </item>  
6.     <item >  
7.         <bitmap android:src="@drawable/toolbar_bg" android:tileMode="disabled" android:gravity="top" />  
8.     </item>  
9. </selector>  

如此，不管是通过代码方式setBackgroundResource()或XML android:background方式设置背景，均不会产生被拉伸的情况。

在任何浏览器上方便地实现Ajax请求是每一个Ajax框架的初衷。Dojo在这方面无疑提供了非常丰富的支持。除了XMLHttpRequest之外，动态script、iframe、RPC也应有尽有，并且接口统一，使用方便，大多数情况下都只需要一句话就能达到目的，从而免除重复造轮子的麻烦。而且，Dojo一贯追求的概念完整性也在这里有所体现，换句话说，在使用Dojo的Ajax工具的过程中不会感到任何的不自然，相反更容易有触类旁通的感觉，因为API的模式是统一的，而且这里涉及到的某些概念（如Deferred对象）也贯穿在整个Dojo之中。

　　Dojo的XHR函数

　　Dojo的XMLHttpRequest函数就叫dojo.xhr，除了把自己取名美元符号之外，这好像是最直接的办法了。它定义在Dojo基本库里，所以不需要额外的require就能使用。它可以实现任何同域内的http请求。不过更常用的是dojo.xhrGet和dojo.xhrPost，它们只不过是对dojo.xhr函数的简单封装；当然根据REST风格，还有dojo.xhrPut和dojo.xhrDelete。

　　这些函数的参数都很统一。除了dojo.xhr的第一个参数是http方法名之外，所有的dojo.xhr*系列函数都接受同一种散列式的参数，其中包含请求的细节，例如url、是否同步、要传给服务器的内容（可以是普通对象、表单、或者纯文本）、超时设定、返回结果的类型（非常丰富且可扩展）、以及请求成功和失败时的回调。所有dojo.xhr*函数（实际上是所有IO函数）返回值也都一样，都是一个Deferred对象，顾名思义，它能让一些事情延迟发生，从而让API用起来更灵活。

　　下面的两个例子可能会带来一点直观感受：

dojo.xhrGet({

url: "something.html",

load: function(response, ioArgs){

//用response干一些事

        console.log("xhr get success:", response)

return response //必须返回response

    },

error: function(response, ioArgs){

console.log("xhr get failed:", response)

return response //必须返回response

    }

})

//Deferred对象允许用同步调用的写法写异步调用

var deferredResult = dojo.xhrPost({

url: "something.html",

form: formNode, //Dojo会自动将form转成object

    timeout: 3000, //Dojo会保证超时设定的有效性

    handleAs: "json" //得到的response将被认为是JSON，并自动转为object

})

//当响应结果可用时再调用回调函数

deferredResult.then(function(response){

console.log("xhr get success:", response)

return response //必须返回response

})

　　首先解释一下timeout。除了IE8之外，目前大多数XMLHttpRequest对象都没有内置的timeout功能，因此必须用 setTimeout。当同时存在大量请求时，需要为每一个请求设置单独的定时器，这在某些浏览器（主要是IE）会造成严重的性能问题。dojo的做法是只用一个单独的setInterval，定时轮询（间隔50ms）所有还未结束的请求的状态，这样就高效地解决了一切远程请求（包括JSONP和 iframe）的超时问题。

　　值得一提的还有handleAs参数，通过设置这个参数，可以自动识别服务器的响应内容格式并转换成对象或文本等方便使用的形式。根据文档，它接受如下值：text (默认), json, json-comment-optional, json-comment-filtered, javascript, xml。

　　而且它还是可扩展的。其实handleAs只是告诉xhr函数去调用哪个格式转换插件，即dojo.contentHandlers对象里的一个方法。例如 dojo.contentHandlers.json就是处理JSON格式的插件。你可以方便地定制自己所需要的格式转换插件，当然，你也可修改现有插件的行为：

dojo.contentHandlers.json = (function(old){

return function(xhr){

var json = old(xhr)

if(json.someSignalFormServer){

doSomthing(json)

delete json.someSignalFormServer

}

return json

}

})(dojo.contentHandlers.json)//一个小技巧，利用传参得到原方法

　　如果要了解每个参数的细节，可以参考Dojo的文档。

　　虚拟的参数类

　　这里特别提一下Dojo在API设计上的两个特点。其一是虚拟的参数类概念：通过利用javascript对象可以灵活扩展的特点，强行规定一个散列参数属于某个类。例如dojo.xhr*系列函数所接受的参数就称为dojo.__XhrArgs。这个类并不存在于实际代码中（不要试图用 instanceof验证它），只停留在概念上，比抽象类还抽象，因此给它加上双下划线前缀（Dojo习惯为抽象类加单下划线前缀）。

　　这样做看起来没什么意思，但实际上简化了API，因为它使API之间产生了联系，更容易记忆也就更易于使用。这一点在对这种类做继承时更明显。例如 dojo.__XhrArgs继承自dojo.__IoArgs，这是所有IO函数所必须支持的参数集合，同样继承自dojo.__IoArgs的还有 dojo.io.script.__ioArgs和dojo.io.iframe.__ioArgs，分别用于动态脚本请求和iframe请求。子类只向父类添加少量的属性，这样繁多的参数就具有了树形类结构。原本散列式参数是用精确的参数名代替了固定的参数顺序，在增加灵活性和可扩展性的同时，实际上增加了记忆量（毕竟参数名不能拼错），使得API都不像看起来那么好用，有了参数类的设计就缓解了这个问题。

　　这种参数类的做法在Dojo里随处可见，读源码的话就会发现它们都是被正儿八经地以正常代码形式声明在一种特殊注释格式里的，像这样：

/*=====

dojo.declare("dojo.__XhrArgs", dojo.__IoArgs, {

constructor: function(){

//summary:

//...

//handleAs:

//...

//......

}

})

=====*/

　　这种格式可以被jsDoc工具自动提取成文档，在文档里这些虚拟出来的类就像真的类一样五脏俱全了。

　　Deferred对象

　　另一个API设计特点就是Deferred对象的广泛使用。Dojo里的Deferred是基于MochiKit实现稍加改进而成的，而后者则是受到 python的事件驱动网络工具包Twisted里同名概念的启发。概括来说的话，这个对象的作用就是将异步IO中回调函数的声明位置与调用位置分离，这样在一个异步IO最终完成的地方，开发人员可以简单地说货已经到了，想用的可以来拿了，而不用具体地指出到底该调用哪些回调函数。这样做的好处是让异步IO的写法和同步IO一样（对数据的处理总是在取数据函数的外面，而不是里面），从而简化异步编程。

　　具体做法是，异步函数总是同步地返回一个代理对象（这就是Deferred对象），可以将它看做你想要的数据的代表，它提供一些方法以添加回调函数，当数据可用时，这些回调函数(可以由很多个)便会按照添加顺序依次执行。如果在取数据过程中出现错误，就会调用所提供的错误处理函数(也可以有很多个)；如果想要取消这个异步请求，也可通过Deferred对象的cancel方法完成。

dojo.Deferred的核心方法如下：



then(callback, errback) //添加回调函数

callback(result) //表示异步调用成功完成，触发回调函数

errback(error) //表示异步调用中产生错误，触发错误处理函数

cancel() //取消异步调用

　　Dojo还提供了一个when方法，使同步的值和异步的Deferred对象在使用时写法一样。例如：

//某个工具函数的实现

var obj = {

getItem: function(){

if(this.item){

return this.item //这里同步地返回数据

        }else{

return dojo.xhrGet({  //这里返回的是Deferred对象

                url: "toGetItem.html",

load: dojo.hitch(this, function(response){

this.item = response

return response

})

})

}

}

}

//用户代码

dojo.when(obj.getItem(), function(item){

//无论同步异步，使用工具函数getItem的方式都一样

})

　　在函数闭包的帮助下，Deferred对象的创建和使用变得更为简单，你可以轻易写出一个创建Deferred对象的函数，以同步的写法做异步的事。例如写一个使用store获取数据的函数：

var store = new dojo.data.QueryReadStore({...})

function getData(start, count){

var d = new dojo.Deferred() //初始化一个Deferred对象

    store.fetch({

start: start,

count: count,

onComplete: function(items){

//直接取用上层闭包里的Deferred对象

            d.callback(items) 

}

})

return d //把它当做结果返回

}

　　用dojo.io.script跨域

　　dojo.xhr* 只是XmlHttpRequest对象的封装，由于同源策略限制，它不能发跨域请求，要跨域还是需要动态创建script标签。Dojo 没有像JQuery一样把所有东西都封装在一起（JQuery的ajax()方法可以跨域，当然用的是JSONP，所以它不敢把自己称为xhr），而是坚持一个API只干一件事情。毕竟在大部分应用中，同域请求比跨域请求多得多，如果一个应用不需要跨域，就没必要加载相关代码。因此与xhr不同，dojo 的跨域请求组件不在基本库，而在核心库，需要require一下才能使用：

dojo.require("dojo.io.script") 

　　这个包里面基本上只需要用到一个函数：dojo.io.script.get()。它也返回Deferred对象，并接受类型为 dojo.io.script.__ioArgs的散列参数。受益于虚拟参数类，我们不用从头开始学习这个参数，它继承了dojo.__IoArgs，因此和dojo.xhr*系列的参数大同小异。唯一需要注意的是handleAs在这里无效了，代之以jsonp或者checkString。

　　前者用于实现JSONP协议，其值由服务器端指定，当script标签加载后就按照JSONP协议执行这个函数，然后Dojo会自动介入，负责把真正的数据传给load函数。需要指出的是在Dojo1.4以前，这个参数叫callbackParamName，冗长但意义明确。毕竟Dojo太早了，它成型的时候（2005）JSONP这个词才刚出现不久。现在callbackParamName还是可用的（为了向后兼容），不过处于deprecated状态。

　　下面的例子从flickr获取feed数据：

dojo.io.script.get({

url: "http://www.flickr.com/services/feeds/photos_public.gne",

jsonp: "jsoncallback", //由flickr指定

    content: {format: "json"},

load: function(response){

console.log(response)

return response

},

error: function(response){

console.log(response)

return response

}

})

　　与jsonp不同，checkString参数专门用于跨域获取javascript代码，它其实是那段跨域脚本里的一个有定义的变量的名字，Dojo会用它来判断跨域代码是否加载完毕，配合前面提到的timeout机制就能实现有效的超时处理。

dojo.io.script.get({

url: "http://......", //某个提供脚本的URL

    checkString: "obj",

load: function(response){

//脚本加载完毕，可以直接使用其中的对象了，如obj。

        Return response

}

})

　　用dojo.io.iframe传数据

　　dojo.io 包里还有一个工具就是iframe，常用于以不刷新页面的方式上传或下载文件。这个很经典的Ajax技巧在Dojo里就是一句 dojo.io.iframe.send({...})。这个函数接受dojo.io.iframe.__ioArgs，相比 dojo.__IoArgs，它只多了一个method参数，用于指定是用GET还是POST（默认）方法发送请求。下面的例子就实现了通过无刷新提交表单来上传文件：

dojo.io.iframe.send({

form: "formNodeId", //某个form元素包含本地文件路径

    handleAs: "html", //服务器将返回html页面

    load: onSubmitted, //提交成功

    error: onSubmitError //提交失败

})

　　目前send函数的handleAs参数支持html, xml, text, json, 和javascript五种响应格式。除了html和xml之外，使用其他格式有一个比较特别的要求，就是服务端返回的响应必须具有以下格式： 

html

head/head

body

textarea真正的响应内容/textarea

/body

/html

　　这是因为服务器返回的东西是加载在iframe里的，而只有html页面才能在任何浏览器里保证成功加载（有个DOM在，以后取数据也方便）。加一个textarea则可以尽量忠实于原始文本数据的格式，而不会受到html的影响。

　　试试RPC(远程过程调用)

　　如果dojo.xhr*函数以及Deferred机制仍然无法避免代码的混乱，那RPC可能就是唯一的选择了。dojo.rpc包提供了基于简单方法描述语言(SMD)的RPC实现。SMD的原理类似于WSDL（Web服务描述语言），不过是基于JSON的，它定义了远程方法的名称、参数等属性，让 Dojo能创建出代理方法以供调用。

　　Dojo提供了两种方式实现rpc：XHR和JSONP，分别对应dojo.rpc.JsonService类和dojo.rpc.JsonpService类，用户可以根据是否需要跨域各取所需。

一个简单的例子：

var smdObj = {

serviceType: "JSON-RPC",

serviceURL: "http://...."

methods: [

{name: "myFunc", parameters: []}

]

}

var rpc = new dojo.rpc.JsonpService(smdObj) //传入SMD

var result = rpc.myFunc() //直接调用远程方法，返回Deferred对象

dojo.when(result, function(result){

//得到结果

})

　　SMD还没有一个被广泛认可的官方标准，一直以来都是Dojo社区领导着它的发展，以后这个模块也有可能发生改变，但整个RPC基本的框架会保持稳定。

　　结语

　　Ajax请求这个主题太大，本文只能挂一漏万地介绍一点dojo在这方面设计和实现的皮毛，包括基本XHR请求、动态script、iframe请求、以及RPC，并特别强调了几个有Dojo特色的设计，如timeout机制、虚拟参数类、Deferred对象等。

　　Dojo由Ajax领域的先驱们写就，相信从它的代码中我们一定能学到更多的东西。

何时我们需要 Dojo 的 build 工具

Dojo 作为一个非常实用的 Ajax 实现框架已经被许多 web2.0 开发人员广泛使用，但使用 Dojo 会导致客户端浏览器需要加载大量的 Dojo 文件，导致应用程序性能下降。解决 Dojo 性能问题的方法之一就是对 Dojo 文件进行定制打包和压缩 ( 提高 Dojo 性能的具体方案请参看“提高基于 Dojo 的 Web 2.0 应用程序的性能”。Dojo 本身已经提供了一套对 Dojo 库文件 ( 自己编写的 Javascript 文件只要符合 Dojo 的规范同样可以进行打包 ) 进行 build 的工具，通过定制库文件和压缩文件的方法来减少浏览器加载文件的时间。

Dojo 的主要库文件 (dojo 包 ) 大小在 1M 左右，dijit 包和 dojox 包大小都在 4M-5M，但我们并不总是需要所有的这些库文件，可以根据开发者自身的需要定制一份 Dojo 库，实际使用的库文件大小往往能大大降低；以笔者目前的开发项目为例，经过定制后实际使用的 Dojo 库文件大小只有 300K 左右。

另外 Dojo 的 build 工具也通过压缩 Javascript 文件的手段来降低浏览器加载文件的时间（该过程中需要使用 ShrinkSafe，有关其详细介绍请参看“http://dojotoolkit.org/docs/shrinksafe”），具体的方法如下：

1. 压缩 Javascript 文件，包括：
   1. 删除所有的空格和空行
   2. 删除所有的注释
   3. 将定义变量名用更简短的字符代替
2. 将所有打包的的 Javascript 文件的内容合并为一个文件

经过压缩处理，Javascript 文件的大小总体可减少 30%-50%，同时将所有的 Javascript 文件打包成一个文件也减少了浏览器加载时多次开闭文件的负担，从而降低了加载时间。

准备工作

• 到“dojo 下载网站”下载 Dojo 源代码，下载后直接解压即可，设 Dojo 的解压目录为 \dojo（下文中皆用“\dojo”指代 Dojo 文件的解压目录）；
• 下载并安装 JDK( 尽量使用 1.5 以上的版本 )，设置 JAVA_HOME 环境变量；

jdk 下载地址：http://java.sun.com/javase/downloads/index.jsp

使用 Dojo 的 build 工具

Dojo 提供的 build 工具位于 \dojo\util\buildsrcipts 下，在 windows 下调用该目录内的 build.bat（linux 下使用 build.sh）文件既可执行 build 工作。

下面是在一个在 windows 下调用 build.bat 的例子：

build profile=base action=release releaseName=myDojo optimize=shrinksafe

该命令中包括了几个最常用的参数，其意义如下：

• action: 指定本次命令的类型，提供的三个值是：clean, release, help；
• releaseName：本次 release 的名字，默认为 dojo；
• optimize：本次 build 中进行优化的方式，一般使用 shrinksafe 既可；
• profile：指定 build 使用的 profile 文件，profile 文件中提供了 build 相关的配置信息，在 \dojo\util\buildsrcipts\profiles 目录下有很多 *.profile.js 文件，我们自定义的 profile 文件也放在这个目录下，例子中“profile=base”表示指定 base.profile.js 作为 build 的参数。

实际上在使用 Dojo 的 build 工具时，关键在于提供的 profile 文件里的内容，在下面的例子中会详细说明 profile 文件的配置方法。

定制 Dojo 文件

Dojo 库中提供了大量的文件供使用者调用，但有的时候我们并不是需要所有的这些文件，此时我们可以使用 Dojo 的 build 工具定制一份个性化的 Dojo 库文件，首先我们需要编写一个 profile 文件来描述我们的需求：

清单 1. profile 文件配置示例 1

 /* example.profile.js */ 
 dependencies = { 
 layers: [    // 可以根据需要制定多个不同的 layer 
 { 
 name: "example.js",   // 打包生成的 js 文件的名
 dependencies: [       // 需要打包的 js 文件列表
"dojo.date", 
"dojox.uuid"       
 ] 
 } 
 ], 
 prefixes: [       // 设置路径
 [ "dijit", "../dijit" ], 
 [ "dojox", "../dojox" ] 
 ] 
 }

注意：

1. dojo.js 是默认被打包的，不需要在 dependencies中声明
2. 在 prefixes 设置路径应该是相对 dojo\dojo\dojo.js 的路径，../dijit 实际上是 dojo\dijit

将该文件 (example.profile.js) 放在 \dojo\util\buildsrcipts\profiles 目录下，执行：

 build profile=example action=release releaseName=myDojo optimize=shrinksafe

build 完成后，会在 \dojo 下生成一个 release 文件夹，如下图所示：

图示 1. build 后释放的文件示意：

因为我们设置了 build 的参数 releaseName=myDojo, 因此 release 下会生成一个 myDojo 文件夹，本次 build 产生的文件都置于该文件夹下。在 \dojo\release\myDojo\dojo\ 目录下，我们可以找到两个文件：example.js 和 example.uncompressed.js，这就是我们需要的打包后的文件，example.uncompressed.js 只是包含了我们指定的所有 dojo 文件，example.js 则在 example.uncompressed.js 基础上又进行了压缩处理。

build 我们自己的 Javascript 文件

对于我们自己编写的 Javascript 文件，我们同样可是借助 Dojo 提供的 build 工具进行压缩和打包，前提是这些 js 文件需要按照 Dojo 相关的的规范编写。打包我们自己的 Javascript 文件与打包 Dojo 文件并没有太大的差别，假设我们有两个 Javascript 文件如下：

清单 2. 假设需要打包的 2 个 Javascript 文件

 /* my.example1 */ 
 dojo.provide("my.example1");  
 dojo.require("my.example2");   // 声明了对 my.example2 的依赖
 /* 
 * this is a js file witch named example1.js 
 */ 

 /* my.example2 */ 
 dojo.provide("my.example2"); 
 /* 
 * this is a js file witch named example2.js 
 */

在 \dojo 下新建一个文件夹“my”, 将上面的两个文件放在该文件夹下，profile 文件配置如下：

清单 3. profile 文件配置示例 2

 /* example.profile.js */ 
 dependencies = { 
	 layers: [ 
 { 
        name: "example.js",   
 dependencies: [       
"dojo.date", 
"dojox.uuid", 
"my.example1"     // 注意这里我们只声明了 my.example1 
 ]   
    } 
 ], 
	 prefixes: [ 
    [ "dijit", "../dijit" ], 
 [ "dojox", "../dojox" ], 
 [ "my", "../my"]      // 刚才新建的 my 文件夹需要在此声明路径
	 ] 
 }

执行：

 build.bat profile=example action=release releaseName=myDojo optimize=shrinksafe

请注意，在 profile 文件中，只声明了将 my.example1 进行打包，但在 build 生成的 example.js 中我们会发现 my.example2 中的内容也已经被添加进来了。这是因为在 build 过程中，build 程序在分析 js 文件内容时通过识别一些关键字 ( 例如 dojo.require) 来判断当前文件是否依赖其他的文件，并将这些依赖的文件一同进行打包。因此当 build 程序在 my.example1 中读到 dojo.require("my.example2"); 时，判断出该文件需要依赖另一个文件"my.example2"，根据 prefixes 提供的路径 build 程序找到了 my.example2.js 文件，并将该文件的内容添加进来。

按照上面的例子 build 后，我们自己编写的 Javascript 文件会和我们定制 Dojo 的文件合并在一个文件中，我们可能需要独立使用这些自己编写的 Javascript 文件，那么我们修改一下 profile 文件既可：

清单 4. profile 文件配置示例 3

 /* example.profile.js */ 
 dependencies = { 
 layers: [ 
 {   // 这个 layer 用来打包我们定制的 dojo 文件
 name: "mydojo.js",   
 dependencies: [       
"dojo.date", 
"dojox.uuid"
 ] 
 }, 
 {  // 这个 layer 用于打包我们自己的 js 文件
 name: "example.js",   
 dependencies: [       
"my.example1"
 ] 
 } 
 ], 
 prefixes: [ 
 [ "dijit", "../dijit" ], 
 [ "dojox", "../dojox" ], 
 [ "my", "../my"] 
 ] 
 }

执行：

 build.bat profile=example action=release releaseName=myDojo optimize=shrinksafe

这样 build 后在 \dojo\release\myDojo\dojo\ 我们会分别得到 mydojo 和 example 两个 layer 的打包文件：

• mydojo.js 和 mydojo.uncompressed.js：打包的是我们定制的 Dojo 文件
• example.js 和 example.uncompressed.js：打包了我们自己编写 Javascript 文件，我们可以根据需要独立使用他们

需要注意的问题

1. 在上面我们已经讲到了 build 程序会按照 dojo.require 等关键字将依赖文件添加进来，因此在每个 layer 的 dependencies 中我们不必列出所有我们需要打包的文件，只需要将一些根文件列出既可 ( 如清单 3 所示 )；另外我们也应该确保这些需要打包的文件以及他们所依赖的其他文件所在的路径都在 prefixes 声明注册过，否则 build 程序会因为找不到所需要的文件而失败。
2. 上面提到在 build 过程中，会调用 shrinksafe 将 js 文件进行压缩，压缩策略包括将定义的变量名用更为简洁的字符串替代，例如我们定义 ”var identifier”，经过压缩处理可能就变成了 ”var _v01”，。如果我们的 Javascript 代码中使用了 eval语句，并且 eval的内容里包含了一些我们定义的变量名，就会导致打包后的文件出现错误而无法使用。例如下面的 Javascript 代码：

 var identifier = “”; 
 eval(“alert(identifier)”);

因为经过压缩后变量名 identifier 被 build 程序以其他的名字替代，因此在执行 eval 方法 , 也就是调用 alert(identifier) 时，会因为无法识别 identifier 而报出 undefined 的错误。

小结

本文站在一个初学者的角度简单地介绍了 Dojo 的 build 工具的使用方法（关键在于 profile 文件的配置），通过以上内容读者应该能够使用该工具进行基本的定制和打包处理，有兴趣的读者可以通过提供的参考资料进行进一步的学习。

1. HTTPS概念

        1）简介   

        HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

      2）HTTPS和HTTP的区别

　　a. https协议需要到ca申请证书，一般免费证书很少，需要交费。

　　b. http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。

　　c. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

d. http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

      3）HTTPS的作用

      它的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

　　a． 一般意义上的https，就是服务器有一个证书。主要目的是保证服务器就是他声称的服务器，这个跟第一点一样；服务端和客户端之间的所有通讯，都是加密的。

　　b. 具体讲，是客户端产生一个对称的密钥，通过服务器的证书来交换密钥，即一般意义上的握手过程。

　　c. 接下来所有的信息往来就都是加密的。第三方即使截获，也没有任何意义，因为他没有密钥，当然篡改也就没有什么意义了。

　　d．少许对客户端有要求的情况下，会要求客户端也必须有一个证书。

这里客户端证书，其实就类似表示个人信息的时候，除了用户名/密码，还有一个CA 认证过的身份。因为个人证书一般来说是别人无法模拟的，所有这样能够更深的确认自己的身份。目前少数个人银行的专业版是这种做法，具体证书可能是拿U盘（即U盾）作为一个备份的载体。

2.SSL简介

　　1）简介

　　SSL (Secure Socket Layer)为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取及窃听。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。

　　2）SSL提供的服务

　　a.认证用户和服务器，确保数据发送到正确的客户机和服务器

　　b.加密数据以防止数据中途被窃取

　　c.维护数据的完整性，确保数据在传输过程中不被改变。

　　3) SSL协议的握手过程

　　SSL 协议既用到了公钥加密技术又用到了对称加密技术，对称加密技术虽然比公钥加密技术的速度快，可是公钥加密技术提供了更好的身份认证技术。SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下：

　　①客户端的浏览器向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

　　②服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。

　　③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。

　　④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后传给服务器。

　　⑤服务器用私钥解密“对称密码”(此处的公钥和私钥是相互关联的，公钥加密的数据只能用私钥解密，私钥只在服务器端保留。详细请参看： http://zh.wikipedia.org/wiki/RSA%E7%AE%97%E6%B3%95)，然后用其作为服务器和客户端的“通话密码”加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

　　⑥客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑤中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

　　⑦服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑤中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

　　⑧SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

3.配置服务器端证书

　　为了能实施SSL，一个web服务器对每个接受安全连接的外部接口(IP 地址)必须要有相应的证书(Certificate)。关于这个设计的理论是一个服务器必须提供某种合理的保证以证明这个服务器的主人就是你所认为的那个人。这个证书要陈述与这个网站相关联的公司，以及这个网站的所有者或系统管理员的一些基本联系信息。

　　这个证书由所有人以密码方式签字，其他人非常难伪造。对于进行电子商务(e-commerce)的网站，或其他身份认证至关重要的任何商业交易，认证书要向大家所熟知的认证权威(Certificate Authority (CA))如VeriSign或Thawte来购买。这样的证书可用电子技术证明属实。实际上，认证权威单位会担保它发出的认证书的真实性，如果你信任发出认证书的认证权威单位的话，你就可以相信这个认证书是有效的。

　　关于权威证书的申请，请参考：http://www.cnblogs.com/mikespook/archive/2004/12/22/80591.aspx

　　在许多情况下，认证并不是真正使人担忧的事。系统管理员或许只想要保证被服务器传送和接收的数据是秘密的，不会被连接线上的偷窃者盗窃到。庆幸的是，Java提供相对简单的被称为keytool的命令行工具，可以简单地产生“自己签名”的证书。自己签名的证书只是用户产生的证书，没有正式在大家所熟知的认证权威那里注册过，因此不能确保它的真实性。但却能保证数据传输的安全性。

　　用Tomcat来配置SSL主要有下面这么两大步骤：

　　1)生成证书

　　a. 在命令行下执行：

　　%Java_home%\bin\keytool -genkey -alias tomcat -keyalg RSA

　　在此命令中，keytool是JDK自带的产生证书的工具。把RSA运算法则作为主要安全运算法则，这保证了与其它服务器和组件的兼容性。

这个命令会在用户的home directory产生一个叫做" .keystore " 的新文件。在执行后，你首先被要求出示keystore密码。Tomcat使用的默认密码是" changeit "(全都是小写字母)，如果你愿意，你可以指定你自己的密码。你还需要在server.xml配置文件里指定自己的密码，这在以后会有描述。

　　b .你会被要求出示关于这个认证书的一般性信息，如公司，联系人名称，等等。这些信息会显示给那些试图访问你程序里安全网页的用户，以确保这里提供的信息与他们期望的相对应。

　　c.你会被要求出示密钥(key)密码，也就是这个认证书所特有的密码(与其它的储存在同一个keystore文件里的认证书不同)。你必须在这里使用与keystore密码相同的密码。(目前，keytool会提示你按ENTER键会自动帮你做这些)。

　　如果一切顺利，你现在就拥有了一个可以被你的服务器使用的有认证书的keystore文件。

　　2) 配置tomcat

　　第二个大步骤是把secure socket配置在$CATALINA_HOME/conf/server.xml文件里。$CATALINA_HOME代表安装Tomcat的目录。一个例子是SSL连接器的元素被包括在和Tomcat一起安装的缺省server.xml文件里。它看起来象是这样：

$CATALINA_HOME/conf/server.xml

< -- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->

< !--

< Connector

port="8443" minProcessors="5" maxProcessors="75"

enableLookups="true" disableUploadTimeout="true"

acceptCount="100" debug="0" scheme="https" secure="true";

clientAuth="false" sslProtocol="TLS"/>

-->

　　Connector元素本身，其默认形式是被注释掉的(commented out)，所以需要把它周围的注释标志删除掉。然后，可以根据需要客户化(自己设置)特定的属性。一般需要增加一下keystoreFile和keystorePass两个属性，指定你存放证书的路径（如：keystoreFile="C:/.keystore"）和刚才设置的密码（如：keystorePass="123456"）。关于其它各种选项的详细信息，可查阅Server Configuration Reference。

　　在完成这些配置更改后，必须象重新启动Tomcat，然后你就可以通过SSL访问Tomcat支持的任何web应用程序。只不过指令需要像下面这样：https://localhost:8443

4.客户端代码实现

　　在Java中要访问Https链接时，会用到一个关键类HttpsURLConnection；参见如下实现代码：

        // 创建URL对象
        URL myURL = new URL("https://www.sun.com");
 
        // 创建HttpsURLConnection对象，并设置其SSLSocketFactory对象
        HttpsURLConnection httpsConn = (HttpsURLConnection) myURL.openConnection();
 
        // 取得该连接的输入流，以读取响应内容
        InputStreamReader insr = new InputStreamReader(httpsConn.getInputStream());
 
        // 读取服务器的响应内容并显示
        int respInt = insr.read();
        while (respInt != -1) {
            System.out.print((char) respInt);
            respInt = insr.read();
        }

　　在取得connection的时候和正常浏览器访问一样，仍然会验证服务端的证书是否被信任（权威机构发行或者被权威机构签名）；如果服务端证书不被信任，则默认的实现就会有问题，一般来说，用SunJSSE会抛如下异常信息：

　　上面提到SunJSSE，JSSE（Java Secure Socket Extension）是实现Internet安全通信的一系列包的集合。它是一个SSL和TLS的纯Java实现，可以透明地提供数据加密、服务器认证、信息完整性等功能，可以使我们像使用普通的套接字一样使用JSSE建立的安全套接字。JSSE是一个开放的标准，不只是Sun公司才能实现一个SunJSSE，事实上其他公司有自己实现的JSSE，然后通过JCA就可以在JVM中使用。

　　关于JSSE的详细信息参考官网Reference：http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html；
　　以及Java Security Guide：http://java.sun.com/j2se/1.5.0/docs/guide/security/；

　　在深入了解JSSE之前，需要了解一个有关Java安全的概念：客户端的TrustStore文件。客户端的TrustStore文件中保存着被客户端所信任的服务器的证书信息。客户端在进行SSL连接时，JSSE将根据这个文件中的证书决定是否信任服务器端的证书。在SunJSSE中，有一个信任管理器类负责决定是否信任远端的证书，这个类有如下的处理规则：
1)若系统属性javax.net.sll.trustStore指定了TrustStore文件，那么信任管理器就去jre安装路径下的lib/security/目录中寻找并使用这个文件来检查证书。
2)若该系统属性没有指定TrustStore文件，它就会去jre安装路径下寻找默认的TrustStore文件，这个文件的相对路径为：lib/security/jssecacerts。
3)若jssecacerts不存在，但是cacerts存在（它随J2SDK一起发行，含有数量有限的可信任的基本证书），那么这个默认的TrustStore文件就是lib/security/cacerts。

　　那遇到这种情况，怎么处理呢？有以下两种方案：
　　1)按照以上信任管理器的规则，将服务端的公钥导入到jssecacerts，或者是在系统属性中设置要加载的trustStore文件的路径；证书导入可以用如下命令：keytool -import -file src_cer_file –keystore dest_cer_store；至于证书可以通过浏览器导出获得；
　　2)、实现自己的证书信任管理器类，比如MyX509TrustManager，该类必须实现X509TrustManager接口中的三个method；然后在HttpsURLConnection中加载自定义的类，可以参见如下两个代码片段，其一为自定义证书信任管理器，其二为connect时的代码：

package test;
import java.io.FileInputStream;
import java.security.KeyStore;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;
public class MyX509TrustManager implements X509TrustManager {
    /*
     * The default X509TrustManager returned by SunX509.  We'll delegate
     * decisions to it, and fall back to the logic in this class if the
     * default X509TrustManager doesn't trust it.
     */
    X509TrustManager sunJSSEX509TrustManager;
    MyX509TrustManager() throws Exception {
        // create a "default" JSSE X509TrustManager.
        KeyStore ks = KeyStore.getInstance("JKS");
        ks.load(new FileInputStream("trustedCerts"),
            "passphrase".toCharArray());
        TrustManagerFactory tmf =
        TrustManagerFactory.getInstance("SunX509", "SunJSSE");
        tmf.init(ks);
        TrustManager tms [] = tmf.getTrustManagers();
        /*
         * Iterate over the returned trustmanagers, look
         * for an instance of X509TrustManager.  If found,
         * use that as our "default" trust manager.
         */
        for (int i = 0; i < tms.length; i++) {
            if (tms[i] instanceof X509TrustManager) {
                sunJSSEX509TrustManager = (X509TrustManager) tms[i];
                return;
            }
        }
        /*
         * Find some other way to initialize, or else we have to fail the
         * constructor.
         */
        throw new Exception("Couldn't initialize");
    }
    /*
     * Delegate to the default trust manager.
     */
    public void checkClientTrusted(X509Certificate[] chain, String authType)
                throws CertificateException {
        try {
            sunJSSEX509TrustManager.checkClientTrusted(chain, authType);
        } catch (CertificateException excep) {
            // do any special handling here, or rethrow exception.
        }
    }
    /*
     * Delegate to the default trust manager.
     */
    public void checkServerTrusted(X509Certificate[] chain, String authType)
                throws CertificateException {
        try {
            sunJSSEX509TrustManager.checkServerTrusted(chain, authType);
        } catch (CertificateException excep) {
            /*
             * Possibly pop up a dialog box asking whether to trust the
             * cert chain.
             */
        }
    }
    /*
     * Merely pass this through.
     */
    public X509Certificate[] getAcceptedIssuers() {
        return sunJSSEX509TrustManager.getAcceptedIssuers();
    }
}
        // 创建SSLContext对象，并使用我们指定的信任管理器初始化
        TrustManager[] tm = { new MyX509TrustManager() };
        SSLContext sslContext = SSLContext.getInstance("SSL", "SunJSSE");
        sslContext.init(null, tm, new java.security.SecureRandom());
        // 从上述SSLContext对象中得到SSLSocketFactory对象
        SSLSocketFactory ssf = sslContext.getSocketFactory();
        // 创建URL对象
        URL myURL = new URL("https://ebanks.gdb.com.cn/sperbank/perbankLogin.jsp");
        // 创建HttpsURLConnection对象，并设置其SSLSocketFactory对象
        HttpsURLConnection httpsConn = (HttpsURLConnection) myURL.openConnection();
        httpsConn.setSSLSocketFactory(ssf);
        // 取得该连接的输入流，以读取响应内容
        InputStreamReader insr = new InputStreamReader(httpsConn.getInputStream());
        // 读取服务器的响应内容并显示
        int respInt = insr.read();
        while (respInt != -1) {
            System.out.print((char) respInt);
            respInt = insr.read();
        }

　　对于以上两种实现方式，各有各的优点，第一种方式不会破坏JSSE的安全性，但是要手工导入证书，如果服务器很多，那每台服务器的JRE都必须做相同的操作；第二种方式灵活性更高，但是要小心实现，否则可能会留下安全隐患；

　　参考文献： 　　　　 　　

　　http://baike.baidu.com/view/14121.htm

　　http://zh.wikipedia.org/wiki/RSA%E7%AE%97%E6%B3%95

　　http://blog.csdn.net/sfdev/article/details/2957240

　　http://blog.csdn.net/cyberexp2008/article/details/6695691

1 系统属性javax.xml.parsers.DocumentBuilderFactory或javax.xml.parsers.SAXParserFactory

2 在jdk-dir/lib/jaxp.properties中设定的javax.xml.parsers.DocumentBuilderFactory或javax.xml.parsers.SAXParserFactory属性

3 运行时jar包中META-INF/services/javax.xml.parsers.DocumentBuilderFactory或javax.xml.parsers.SAXParserFactory文件中设定的值

4. 如果上面的解析器都没有找到，则使用Crimson。如果还没有。。。。。。那报ClassNotFound异常了。

通过JAXP查找解析器的顺序，我们可以使用下面方式来决定，我们使用的实际解析器，
1 在程序中写死实际的解析器
如
javax.xml.parsers.DocumentBuilderFactory factory＝ new org.apache.crimson.jaxp.DocumentBuilderFactoryImpl();
2 使用JAXP的 DocumentBuilderFactory 工厂类，如
javax.xml.parsers.DocumentBuilderFactory factory＝ javax.xml.parsers.DocumentBuilderFactory.newInstance();
再通过下面的方式来指定实际的解析器类
方法一:在运行java时，通过设置java -D javax.xml.parsers.DocumentBuilderFactory=new org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
方法二:在程序中调用System.setProperty(“javax.xml.parsers.DocumentBuilderFactory”,” org.apache.crimson.jaxp.DocumentBuilderFactoryImpl”)
来设定实际的XML解析器.
方法三:编写一个jaxp.properties文件，在其中加入如下内容
javax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
再将此文件放入JAVA_HOME/lib/下
方法四:在打jar包下，在目录META-INF/下新建一个services目录，在此目录新建一个文件名为javax.xml.parsers.DocumentBuilderFactory的文件，
文件内容写上实际使用的解析器类，如写org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
通过，上面，我们就可以对JAXP有一个比较深的了解。其实，JAVA中有许多这种思想的做法，这种思想，指的是什么的，就是平台无关性，发展到不依赖于具体的实现。
如我们熟悉的JNDI，JDBC，JAXP等。JNDI是抽像各种目录服务操作的类库，因为目录服务器厂商太多了，如SUN公司的ldapsdk,还有novell公司等等。JDBC是抽像各种数据库
操作的类库，因为数据库厂商也太多了，如ORACLE，SQLSERVER，MYSQL，INFORMIX等等，JAXP就是抽像各种XML解析器和转换器产品的类库，因为XML解析器和转换器产品够多
的了。

访问AIX系统中部署在OC4J中的web 模块的页面时遇到这个错误：
javax.xml.parsers.FactoryConfigurationError: Provider null could not be instantiated: 
java.lang.NullPointerException
at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
at org.apache.commons.digester.Digester.getFactory(Digester.java:478)
at org.apache.commons.digester.Digester.getParser(Digester.java:683)
at org.apache.commons.digester.Digester.getXMLReader(Digester.java:891)
at org.apache.commons.digester.Digester.parse(Digester.java:1591)
at org.apache.struts.action.ActionServlet.initServlet(ActionServlet.java:1433)
at org.apache.struts.action.ActionServlet.init(ActionServlet.java:466)
at javax.servlet.GenericServlet.init(GenericServlet.java:256)
at com.evermind[Oracle Containers for J2EE 10g (10.1.3.0.0) ].server.http.HttpApplication.loadServlet(HttpApplication.java:2231)
at com.evermind[Oracle Containers for J2EE 10g (10.1.3.0.0) ].server.http.HttpApplication.findServlet(HttpApplication.java:4617)
……
或者这样的异常：
javax.servlet.jsp.JspException: Can't get definitions factory from context.
at org.apache.struts.taglib.tiles.InsertTag.processDefinitionName(InsertTag.java:583)
at org.apache.struts.taglib.tiles.InsertTag.createTagHandler(InsertTag.java:487)
at org.apache.struts.taglib.tiles.InsertTag.doStartTag(InsertTag.java:451)
at _welcome._jspService(_welcome.java:54)
[SRC:/welcome.jsp:4]

…… 
而当在Windows环境下部署时就没有问题。

这里是因为IBM的AIX系统使用的是IBM的JDK。而出现这个问题正是因为IBM和SUN的JDK的差异。 具体是因为$JAVA_HOME/jre/lib/jaxp.properties 这个文件。

这个文件以key=value的形式配置和指定实际使用的XML解析器实现类(譬如：javax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl)。在XML解析器初始化之前，JDK首先会搜索System的properties寻找解析器的配置项，如果没有则会搜索 $JAVA_HOME/jre/lib 路径下的 jaxp.properties 文件，如果还没有，接下来会在classpath上的.jar包中寻找，仍然没有的话就会使用默认的解析器。

实际上这个文件在SUN的JDK中是不存在的。在找不到文件的情况下，最终将使用默认解析器。在IBM的JDK中存在 jaxp.properties这个文件。但是这个文件中默认所有的配置项是注释掉的，所以在搜索到此处时，不再继续向下搜索，但是由于读取不到配置项，所以会返回null ，于是出现了上文的第一个错误。第二个异常大概是因为访问使用tiles框架的页面时，由于XML解析器初始化出错，所以tiles框架的配置文件也就读取不了了。

Windows 强制删除文件及文件夹命令