Wifidog Portal认证示例PHP脚本

在上一篇文章“ OpenWRT下实现Portal认证(WEB认证) ”发布之后,很多人留言和发邮件与我交流,我感到很是欣慰。我之所以写上一篇文章的目的,一方面Wifidog是很好的解决方案,虽然有很成熟的应用,但相关技术性的文章很少,官方文档也不全。已完成开发的一般也就做成商业解决方案收费,让很多爱折腾的极客难以入手。实际上Wifidog的功能我还没发掘完,如果你有能力,你同意通过各种分析手段尽心分析,甚至是自行解读源代码。我在写了上一篇文章,我自行写了一些PHP测试代码,测试Portal功能能否正确实现,当然我没有公布测试代码,初衷是希望授之以鱼不如授之以渔,不过鉴于给个测试代码可能对初学者更有帮助,另外也有很多人来邮询问,故经修改公开供读者学习。
声明:代码属于测试代码,缺乏安全性等方面的优化,用于线上环境请慎重,因此而出现的任何问题我当然不会负责。转载请说明出处。
PHP脚本,Portal服务器需要有Apache或Nginx环境,当然如果你会配置,IIS也行,另外需要使用数据库存储用户的用户名和密码,我选择使用常用的MySQL。
先介绍数据库的结构,我构建的数据库名是portal,表名是User,用于记录等录用用户的用户名、密码等的信息:

1
2
3
4
5
6
7
8
9
10
11
12
13
create database portal;
CREATE TABLE `User` (
`Username` varchar(255) NOT NULL,
`Password` text NOT NULL,
`Token` text,
`LoginTime` datetime DEFAULT NULL,
`Gw_address` text,
`Gw_port` text,
`Gw_id` text,
`Mac` text,
`Url` text,
PRIMARY KEY (`Username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

首先介绍的是登陆脚本,即上一篇文章介绍的LoginScriptPathFragment配置项配置的脚本(详细介绍见上一篇文章)。
auth.php,主要用于认证服务器验证路由网关提交的token。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
<?php
//首先获取URL传递过来的参数,包括stage、ip、mac、token、incoming、outgoing和gw_id.
$stage = isset($_GET["stage"]) ? $_GET["stage"] : null;
$ip = isset($_GET["ip"]) ? $_GET["ip"] : null;
$mac = isset($_GET["mac"]) ? $_GET["mac"] : null;
$token = isset($_GET["token"]) ? $_GET["token"] : null;
$incoming = isset($_GET["incoming"]) ? $_GET["incoming"] : null;
$outgoing = isset($_GET["outgoing"]) ? $_GET["outgoing"] : null;
$gw_id = isset($_GET["gw_id"]) ? $_GET["gw_id"] : null;
//mac和token是必需参数,不能为空,只有mac和token均不为空才有可能通过验证,缺失参数将不显示登录表单.
if(!empty($mac) && !empty($token)){
//mysql连接,相应的参数mysql_host、mysql_user和mysql_password需要换成你自己的参数.
$con = mysql_connect(‘mysql_host’, ‘mysql_user’, ‘mysql_password’);
//数据库连接失败,验证不通过.
if(!$con){
echo "Auth: 0";
}
else{
//选择mysql数据库,如果你的数据库名不是portal,请自行更改.
mysql_select_db(‘portal’, $con);
//用户登陆成功后,会把用户的参数(ip、mac和系统自动生成的token等)记录到数据库,系统主要通过mac识别用户,当然这种方式在大规模系统中可能存在漏洞.
$result = mysql_query("SELECT * FROM User WHERE Mac='".$mac."' AND Token='".$token."'");
//如果token匹配,验证通过,否则验证失败.
if(!empty($result) && mysql_num_rows($result) != 0){
echo "Auth: 1";
}
else{
echo "Auth: 0";
}
}
}
else{
echo "Auth: 0";
}
?>

接下来介绍的是登陆成功脚本,即上文介绍的PortalScriptPathFragment配置项配置的脚本(详细介绍见上一篇文章)。
portal.php,主要作用是告知用户登录成功,并跳转用户登录前访问的页面。

1
2
3
4
5
6
7
8
<?php
//告知用户登陆成功.
//echo ‘登录成功’;
//认证前用户访问任意url,然后被重定向登录页面,session记录的是这个“任意url”.
$url = $_SESSION["url"];
//跳转到登陆前页面.
header("Location: ".$url);
?>

当然,这个脚本没有任何界面,为提升用户体验,你可以设计一个好的界面,显示登陆成功信息。

接下来介绍的是错误信息展示脚本,即上文介绍的MsgScriptPathFragment配置项配置的脚本,(详细介绍见上一篇文章)。
gw_message.php,主要作用是当认证过程出现错误的时候,向用户显示用户信息。

1
2
3
4
5
6
7
<?php
$message = null;
if(isset($_GET["message"])){
$message = $_GET["message"];
}
echo $message;
?>

脚本非常简单,错误信息就在message参数中,告知用户即可。当然这个错误信息是英文的,如有需要,可以做做翻译,以提升用户体验。这个脚本同样没有任何界面,需自行设计。

接下来介绍的是心跳脚本,即上文介绍的PingScriptPathFragment配置项配置的脚本,(详细介绍见上一篇文章)。
ping.php,其主要作用是路由确认认证服务器仍然存活,没有死机,另外一个功能是认证服务器可以收集路由的负载等的信息。路由器会定时访问这个脚本,脚本必须回复Pong,否则将认为认证服务器失效而出错。

1
2
3
<?php
echo ‘Pong’;
?>

最后介绍的是登陆脚本,即上文介绍的AuthScriptPathFragment配置项配置的脚本,(详细介绍见上一篇文章)。
login.php,主要作用是显示登录界面,用户登陆成功后,跳转到路由器网关的特定接口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
<?php
//获取url传递过来的参数
$gw_address = isset($_GET["gw_address"]) ? $_GET["gw_address"] : null;
$gw_port = isset($_GET["gw_port"]) ? $_GET["gw_port"] : null;
$gw_id = isset($_GET["gw_id"]) ? $_GET["gw_id"] : null;
$mac = isset(isset($_GET["mac"]) ? isset($_GET["mac"] : null;
$url = isset($_GET["url"]) ? $_GET["url"] : null;
//gw_address、gw_port、gw_id和mac是必需参数,缺少不能认证成功.
if(!empty($gw_address) && !empty($gw_port) && !empty($gw_id) && !empty($mac)){
//参数初始化
$post_username = null;
$post_password = null;
$error_message = null;
//如果用户提交用户名和密码,进行验证
if(isset($_POST["username"]) && isset($_POST["password"])){
$post_username = $_POST["username"];
$post_password = $_POST["password"];
//mysql数据库连接,相应的参数mysql_host、mysql_user和mysql_password需要换成你自己的参数.
$con = mysql_connect(‘mysql_host’, ‘mysql_user’, ‘mysql_password’);
//数据库连接失败,展示错误信息
if(!$con){
$error_message = "数据库连接错误!".mysql_error();
//login_view.php展示的是登陆表单(下文介绍),如有错误,展示错误信息.
include("login_view.php");
}
else{
//选择mysql数据库,如果你的数据库名不是portal,请自行更改.
mysql_select_db(‘portal’, $con);
//用户名和密码验证.
$result = mysql_query("SELECT * FROM User WHERE Username='".$post_username."' AND Password='".$post_password."'");
if(!empty($result) && mysql_num_rows($result) != 0){
//用户名和密码验证成功,生成随机token.
$token = "";
$pattern="1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLOMNOPQRSTUVWXYZ";
for($i=0;$i<32;$i++){
$token .= $pattern{mt_rand(0,35)};
}
//把token等参数写入数据库,已被用于后续验证(上文提到的auth.php).
mysql_query("Update User SET Token='".$token."', LoginTime='".date("Y-m-d H:i:s")."', Gw_address='".$gw_address."', Gw_port='".$gw_port."', Gw_id='".$gw_id."', Mac='".$mac."', Url='".$url."' WHERE Username='".$post_username."'");
$error_message = mysql_error();
//把用户名和url存进session,以备后续使用.
session_start();
$_SESSION['username'] = $post_username;
$_SESSION['url'] = $url;
//登陆成功,跳转到路由网管指定的页面.
header("Location: http://".$gw_address.":".$gw_port."/wifidog/auth?token=".$token);
}
else{
//登录失败,显示错误信息.
$error_message = "用户名或密码错误!";
include("login_view.php");
}
}
}
else{
include("login_view.php");
}
}
?>

Login_view.php登陆表单。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="language" content="en" />
<title>Portal Login</title>
</head>
<body>
<form method="post" action="<?php echo "login.php?gw_address=$gw_address&gw_port=$gw_port&gw_id=$gw_id&mac=$mac&url=$url"; ?>">
<label for="username">Username</label>
<input type="text" id="username" name="username" value="<?php echo $post_username; ?>"/>
<label for="password">Password</label>
<input type="password" id="password" name="password" value="<?php echo $post_password; ?>"/>
<?php
if(!empty($error_message)){
echo "<h4>$error_message</h4>";
}
?>
<input type="submit" value="Submit"/>
</form>
</body>

这大致就是一个简单的认证系统脚本。再次啰唆,脚本安全性、稳定现等均得不到保证,不能防范sql注入等的黑客主机,仅供交流和测试,线上使用需慎重。转载请注明出处。当然,系统仍然有位开发的功能,有待各位自行发掘。

转载自 http://talk.withme.me/?p=267

OpenWRT下实现Portal认证(WEB认证)

首先简单介绍一下什么是Portal认证,Portal认证,通常也会叫Web认证,未认证用户上网时,设备强制用户登录到特定站点,用户可以免费访问其中的服务。当用户需要使用互联网中的其它信息时,必须在门户网站进行认证,只有认证通过后才可以使用互联网资源。现金很多中国移动CMCC、中国联通、中国电信ChinaNet的WIFI都使用这种认证接入方式。
在OpenWRT上实现Portal认证,实际上早已有解决方案:

  1. chillispot,但原维护作者停止更新,被chillispot.info接管继续开发;
    2.coova-chilli,它是基于chillispot开发拓展的,功能最为强大;可以去官方看一下Coova-chilli;
    3.wifidog
    前两个由于原维护作者停止更新,笔者也没有深入研究,重点钻研了wifidog,Wifidog也是OpenWRT和DD-WRT中实现Portal比较出名的。
    但是,Wifidog只是实现AP认证网关,需要配合外部的Portal服务器才能使用,Portal主要是提供认证所需的WEB页面且实现认证计费等的功能。虽然这也有很多商用解决方案,例如wiwiz、wifiap等,但是这些商业解决方案的目标都是盈利,即使可以免费使用,免费账号的功能和权限都受到了很大的限制,例如不能自定义页面,Web认证页面有广告等等。有条件的人可能打算自己搭建Portal服务器,但是看看Wifidog的官方Wiki,对搭建过程实在是难以理解。后来,笔者发现网络上还有一个authpuppy方案,官方网站 www.authpuppy.org,是一个已实现好的Wifidog认证服务器,里面包含各种插件供你使用,官方的安装过程也很简单,如果你懂的HTML和面向对象编程的相关知识且拥有一个服务器,可以自行修改认证页面,使用authpuppy也是一个不错的方案。
    但是,即便如此,这些方案还是不够灵活,经过笔者认真钻研,查阅大量资料并经过多次抓包分析,终于理解了Wifidog的工作原理。接下来笔者将会跟你介绍如何自行编写一个轻量级的Web Portal认证服务器。当然,这需要你具有程序设计基础,HTML、CSS当然是少不得的,后端开发语言可以使用PHP或Python或Java等。
    首先,需要简单介绍一下Wifidog的工作原理:
    1.客户端发出初始化请求,比如访问 www.baidu.com。
    2.网关的防火墙规则将这个请求重定向到本地网关的端口上。这个端口是Wifidog监听的端口。
    3.Wfidog提供一个HTTP重定向回复,重定向到Web认证页面,重定向的Url的Querystring中包含了Gateway的ID,Gateway的FQDN以及其他的信息。
    4.用户向认证服务器发出认证请求
    http://portal_server:port/login_script?
    gw_id=[GatewayID, default: “default”]
    gw_address=[GatewayAddress, internal IP of router]
    gw_port=[GatewayPort, port that wifidog Gateway is listening on]
    url=[user requested url];
    5.网关返回一个(可以是自定义的)splash(也称作“登录”)页面。
    6.用户提供他的凭据信息,比如用户名和密码。
    7.成功认证的话,客户端将会被重定向到网关的自己的web页面上,并且带有一个认证凭据(一个一次性的token),内容比如:
    http://GatewayIP:GatewayPort/wifidog/auth?token=[auth token];
    8.用户就是用获取到的凭据访问网关。
    9.网关去认证服务器询问token的有效性。
    10.认证服务器确认token的有效性。
    11.网关发送重定向给客户端,以从认证服务器上获取 成功提示页面,重定向到 http://portal_server:port/portal_script 这个位置。
    12.认证服务器通知客户请求成功,可以上网了。
    图解:
    1
    然后考察一下Wifidog的配置文件/etc/wifidog.conf,关键的配置项是:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    AuthServer {
    Hostname (Mandatory; Default: NONE)
    SSLAvailable (Optional; Default: no; Possible values: yes, no)
    SSLPort (Optional; Default: 443)
    HTTPPort (Optional; Default: 80)
    Path (Optional; Default: /wifidog/ Note: The path must be both prefixed and suffixed by /. Use a single / for server root.)
    LoginScriptPathFragment (Optional; Default: login/? Note: This is the script the user will be sent to for login.)
    PortalScriptPathFragment (Optional; Default: portal/? Note: This is the script the user will be sent to after a successfull login.)
    MsgScriptPathFragment (Optional; Default: gw_message.php? Note: This is the script the user will be sent to upon error to read a readable message.)
    PingScriptPathFragment (Optional; Default: ping/? Note: This is the script the user will be sent to upon error to read a readable message.)
    AuthScriptPathFragment (Optional; Default: auth/? Note: This is the script the user will be sent to upon error to read a readable message.)
    }

    # Listen on this port
    GatewayPort 2060

    # Parameter: CheckInterval
    # Default: 60
    # Optional
    #
    # How many seconds should we wait between timeout checks. This is also
    # how often the gateway will ping the auth server and how often it will
    # update the traffic counters on the auth server. Setting this too low
    # wastes bandwidth, setting this too high will cause the gateway to take
    # a long time to switch to it's backup auth server(s).
    CheckInterval 60

    # Parameter: ClientTimeout
    # Default: 5
    # Optional
    #
    # Set this to the desired of number of CheckInterval of inactivity before a client is logged out
    # The timeout will be INTERVAL * TIMEOUT
    ClientTimeout 5

AuthServer是Portal服务器的配置项;GatewayPort是Wifidog监听的地址,默认是2060,一般保持默认即可;CheckInterval是心跳时长,单位是秒,什么是心跳呢,客户端认证成功之后,如果有网络访问动作,Wifidog getway就会每隔一段时间访问Portal服务器的一个脚本,用于认证计费,当然,如果客户使用超时或超流量,也可以通过心跳强制客户端下线。ClientTimeout是用户一次认证成功后的网络访问时长,超过这个时间需要重新认证,这个时长并非由ClientTimeout单独决定,取决于INTERVAL * TIMEOUT。详细的配置信息可以访问: http://dev.wifidog.org/browser/trunk/wifidog/wifidog.conf
我们重点讨论Portal服务器的配置项,Hostname是Portal服务器的ip或者是域名,SSLAvailable和SSLPort是SSL加密配置,如果你的Portal服务器有配置HTTPS加密,则需要配置这两项;Path是指你的脚本路径(举例,http://a.com/to/,则a.com是域名,/to/是路径),注意路径必须以“/”开头和结尾,如果是根路径,则填一个“/”即可;接下来的5个配置指明你的脚本名,这说明了我们需要写五个脚本,我会详细说明。(以下文中涉及的“第几步”均是指Wifidog认证过程的步骤)
LoginScriptPathFragment配置项配置的是登陆脚本,它通过GET方式接受传入参数gw_address、gw_port、gw_id、mac和url,gw_address是AP Getway的ip地址;gw_port是Wifidog监听的端口,即上面介绍的wifidog.conf中的GatewayPort配置;gw_id是AP Getway的id,配置文件wifidog.conf中可以配置,默认值是default,这个值的作用是当存在多个AP是,服务器或管理员可以根据不同的id确定用户的接入点;mac是客户计算机的网卡物理地址,注意不是AP网关的mac,这个mac是用来识别客户计算机的;url是客户初始访问的Url,这些Querystring都是AP Getway向客户端发出重定向请求自动生成的。这个脚本同时需要提供登陆页面,如果登陆成功,需要向客户;端返回302重定向,重定向到:http://gw_address:gw_port/wifidog/auth?token=[token];即实现第7步,其中[token]是你自己自动生成的token字符串,随机生成一个字符串即可,但是长度最好长些,安全性更高,另外,token需要根据不同用户保存,最好保存于数据库中,之后的AP Getway询问token有效性(第9步)还需要用到。这里最好使用cookie或session,使之后的登陆成功页面可以判断用户已经成功,阻止未登录成功的人访问认证成功页面。
PortalScriptPathFragment配置项配置的是登陆成功后服务器展示的脚本(第11步),它通过GET方式接受1个传入参数,gw_id,这个脚本比较简单,告知用户登陆成功即可,当然,最好重定向到用户之前想要方位的url,即第1步用户输入的URL。
MsgScriptPathFragment配置项配置的是错误信息展示脚本,它通过GET方式接受一个传入参数message,这个脚本也很简单,展示message的内容即可,目的是当认证过程出现错误,AP Getway会重定向到这个脚本,URL中含有错误的信息。
PingScriptPathFragment配置项配置的是心跳脚本,这个脚本它通过GET方式接受5个传入参数,gw_id,sys.uptime,sys.memfree,sys.load,wifidog.uptime,其中,sys.uptime指的是AP Getway的启动时间,sys.memfree指的是AP Getway的空闲内存,sys.load指的是AP Getway的CPU负载,wifidog.uptime指的是wifidog的启动时间,这个脚本每隔一段时间(Wifidog.conf里配置的CheckInterval),Wifidog会自动访问,但是其目的不是用户验证,而是帮助管理员管理AP节点,了解AP节点的负载情况,适时增加节点等,Wifidog访问这个脚本时,需要这个脚本返回Pong,如果你没有统计AP节点负载数据的需求,可以丢弃这些数据,直接回应Pong,注意,这个回应只包含“Pong”字符串,无需包含其他html标签。
AuthScriptPathFragment是用户认证脚本,实现的是第10步的功能,这个脚本它通过GET方式接受7个传入参数:stage、ip、mac、token、incoming、outcoming和gw_id。其中stage的值是login,ip是客户端的ip,注意不是AP Getwap的ip;mac是客户端的网卡物理地址,token就是你在认证脚本生成并返回给客户端的;incoming和outcoming用于流量控制,默认值为0;gw_id同上。如何识别用户登录成功,通过mac和token吧,LoginScriptPathFragment登陆脚本在用户登陆成功后需要记录用户的mac和token,然后在此处验证,如果匹配,回复Auth: 1,否则,回复Auth: 0。另外,这个脚本也是心跳脚本,每隔一段时间Wifidog会自动访问,如果用户使用时间超过限制或流量超过额度,服务器可以及时回应Auth: 0结束用户的访问。另外需要注意的是,回应同样无需包含html标签,另外,在Auth后的冒号和0/1之间,有一个空格,缺少这个空格也会导致出错。
在配置Wifidog的配置文件wifidog.conf是,配置脚本的配置项都必须以“?”结尾,否则以GET方式传递的QueryString会因Url缺少问号访问错误的脚本。
看到了吧,仅仅5个简单脚本,就可以实现利用Wifidog的Portal认证,当然,这过中还可以有很多应用尚未发掘,比如流量控制、带宽控制、结合Radius服务器实现认证等,你的开发也可以更上一层楼,实现更多功能。不过笔者还有一个建议,在登录页面除了用户名和密码意外,最好加个验证码,防止不怀好意之人暴力破解。
这样,你只需要一个免费的空间,甚至是简单的百度云、新浪SAE等,就可以实现一个认证服务器;有的人可能还会问,能不能把这些脚本集成到路由器当中,我的回答是能,只要你的脚本的功能不多,问题应该不大,但是这么做的风险比较大,路由的负载比较高,导致路由的运行会很不稳定,甚至经常死机,这也是笔者亲身实践的结果,所以笔者不建议这么做。
最后啰嗦提醒的是,WiFidog是使用iptables基于三层协议工作的,所以使用Wifidog的结果是,不仅是Wifi接入需要Portal认证,有线接入同样需要认证。避免这种情况最简单的做法是设立mac白名单。可能有的人又会问,能不能做到仅是Wifi接入需要认证,有线接入的无需认证,有的人可能想更上一层楼,能不能开两个Wifi,仅其中一个Wifi需要认证,另一个Wifi和有线网络不需要Portal认证,我的回答是能,至于具体做法,以后再介绍。

转载自 http://talk.withme.me/?p=222

设计模式六大原则

单一职责原则(Single Responsibility Principle)
定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。
问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。
解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。
说到单一职责原则,很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则,因为这是常识。在软件编程中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,但是即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。
比如:类T只负责一个职责P,这样设计是符合单一职责原则的。后来由于某种原因,也许是需求变更了,也许是程序的设计者境界提高了,需要将职责P细分为粒度更细的职责P1,P2,这时如果要使程序遵循单一职责原则,需要将类T也分解为两个类T1和T2,分别负责P1、P2两个职责。但是在程序已经写好的情况下,这样做简直太费时间了。所以,简单的修改类T,用它来负责两个职责是一个比较不错的选择,虽然这样做有悖于单一职责原则。
举例说明,用一个类描述动物呼吸这个场景:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Animal{
public void breathe(String animal){
System.out.println(animal+"呼吸空气");
}
}

public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
}
}

运行结果:
牛呼吸空气
羊呼吸空气
猪呼吸空气

程序上线后,发现问题了,并不是所有的动物都呼吸空气的,比如鱼就是呼吸水的。修改时如果遵循单一职责原则,需要将Animal类细分为陆生动物类Terrestrial,水生动物Aquatic,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class Terrestrial{
public void breathe(String animal){
System.out.println(animal+"呼吸空气");
}
}
class Aquatic{
public void breathe(String animal){
System.out.println(animal+"呼吸水");
}
}

public class Client{
public static void main(String[] args){
Terrestrial terrestrial = new Terrestrial();
terrestrial.breathe("牛");
terrestrial.breathe("羊");
terrestrial.breathe("猪");

Aquatic aquatic = new Aquatic();
aquatic.breathe("鱼");
}
}

运行结果:
牛呼吸空气
羊呼吸空气
猪呼吸空气
鱼呼吸水

我们会发现如果这样修改花销是很大的,除了将原来的类分解之外,还需要修改客户端。而直接修改类Animal来达成目的虽然违背了单一职责原则,但花销却小的多,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Animal{
public void breathe(String animal){
if("鱼".equals(animal)){
System.out.println(animal+"呼吸水");
}else{
System.out.println(animal+"呼吸空气");
}
}
}

public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
animal.breathe("鱼");
}
}

可以看到,这种修改方式要简单的多。但是却存在着隐患:有一天需要将鱼分为呼吸淡水的鱼和呼吸海水的鱼,则又需要修改Animal类的breathe方法,而对原有代码的修改会对调用“猪”“牛”“羊”等相关功能带来风险,也许某一天你会发现程序运行的结果变为“牛呼吸水”了。这种修改方式直接在代码级别上违背了单一职责原则,虽然修改起来最简单,但隐患却是最大的。还有一种修改方式:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Animal{
public void breathe(String animal){
System.out.println(animal+"呼吸空气");
}

public void breathe2(String animal){
System.out.println(animal+"呼吸水");
}
}

public class Client{
public static void main(String[] args){
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("猪");
animal.breathe2("鱼");
}
}

可以看到,这种修改方式没有改动原来的方法,而是在类中新加了一个方法,这样虽然也违背了单一职责原则,但在方法级别上却是符合单一职责原则的,因为它并没有动原来方法的代码。这三种方式各有优缺点,那么在实际编程中,采用哪一中呢?其实这真的比较难说,需要根据实际情况来确定。我的原则是:只有逻辑足够简单,才可以在代码级别上违反单一职责原则;只有类中方法数量足够少,才可以在方法级别上违反单一职责原则;
例如本文所举的这个例子,它太简单了,它只有一个方法,所以,无论是在代码级别上违反单一职责原则,还是在方法级别上违反,都不会造成太大的影响。实际应用中的类都要复杂的多,一旦发生职责扩散而需要修改类时,除非这个类本身非常简单,否则还是遵循单一职责原则的好。
遵循单一职责原的优点有:
可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
提高类的可读性,提高系统的可维护性;
变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都需要遵循这一重要原则。

里氏替换原则(Liskov Substitution Principle)
肯定有不少人跟我刚看到这项原则的时候一样,对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的。
定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型。
定义2:所有引用基类的地方必须能透明地使用其子类的对象。
问题由来:有一功能P1,由类A完成。现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障。
解决方案:当使用继承时,遵循里氏替换原则。类B继承类A时,除添加新的方法完成新增功能P2外,尽量不要重写父类A的方法,也尽量不要重载父类A的方法。
继承包含这样一层含义:父类中凡是已经实现好的方法(相对于抽象方法而言),实际上是在设定一系列的规范和契约,虽然它不强制要求所有的子类必须遵从这些契约,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。
继承作为面向对象三大特性之一,在给程序设计带来巨大便利的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加了对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能会产生故障。
举例说明继承的风险,我们需要完成一个两数相减的功能,由类A来负责。

1
2
3
4
5
6
7
8
9
10
11
12
13
class A{
public int func1(int a, int b){
return a-b;
}
}

public class Client{
public static void main(String[] args){
A a = new A();
System.out.println("100-50="+a.func1(100, 50));
System.out.println("100-80="+a.func1(100, 80));
}
}

运行结果:
100-50=50
100-80=20
后来,我们需要增加一个新的功能:完成两数相加,然后再与100求和,由类B来负责。即类B需要完成两个功能:
两数相减。
两数相加,然后再加100。
由于类A已经实现了第一个功能,所以类B继承类A后,只需要再完成第二个功能就可以了,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class B extends A{
public int func1(int a, int b){
return a+b;
}

public int func2(int a, int b){
return func1(a,b)+100;
}
}

public class Client{
public static void main(String[] args){
B a = new B();
System.out.println("100-50="+b.func1(100, 50));
System.out.println("100-80="+b.func1(100, 80));
System.out.println("100+20+100="+b.func2(100, 20));
}
}

类B完成后,运行结果:
100-50=150
100-80=180
100+20+100=220
我们发现原本运行正常的相减功能发生了错误。原因就是类B在给方法起名时无意中重写了父类的方法,造成所有运行相减功能的代码全部调用了类B重写后的方法,造成原本运行正常的功能出现了错误。在本例中,引用基类A完成的功能,换成子类B之后,发生了异常。在实际编程中,我们常常会通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的几率非常大。如果非要重写父类的方法,比较通用的做法是:原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖、聚合,组合等关系代替。

里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。它包含以下4层含义:
子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。
看上去很不可思议,因为我们会发现在自己编程中常常会违反里氏替换原则,程序照样跑的好好的。所以大家都会产生这样的疑问,假如我非要不遵循里氏替换原则会有什么后果?
后果就是:你写的代码出问题的几率将会大大增加。

依赖倒置原则(Dependence Inversion Principle)
定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。
问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。
解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中,抽象指的是接口或者抽象类,细节就是具体的实现类,使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。
依赖倒置原则的中心思想是面向接口编程,我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的,母亲给孩子讲故事,只要给她一本书,她就可以照着书给孩子讲故事了。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Book{
public String getContent(){
return "很久很久以前有一个阿拉伯的故事……";
}
}

class Mother{
public void narrate(Book book){
System.out.println("妈妈开始讲故事");
System.out.println(book.getContent());
}
}

public class Client{
public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book());
}
}

运行结果
妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
运行良好,假如有一天,需求变成这样:不是给书而是给一份报纸,让这位母亲讲一下报纸上的故事。

1
2
3
4
5
class Newspaper{
public String getContent(){
return "林书豪38+7领导尼克斯击败湖人……";
}
}

这位母亲却办不到,因为她居然不会读报纸上的故事,这太荒唐了,只是将书换成报纸,居然必须要修改Mother才能读。假如以后需求换成杂志呢?换成网页呢?还要不断地修改Mother,这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了,必须降低他们之间的耦合度才行。
我们引入一个抽象的接口IReader。读物,只要是带字的都属于读物。

1
2
3
interface IReader{
public String getContent();
}

Mother类与接口IReader发生依赖关系,而Book和Newspaper都属于读物的范畴,他们各自都去实现IReader接口,这样就符合依赖倒置原则了,代码修改为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class Newspaper implements IReader {
public String getContent(){
return "林书豪17+9助尼克斯击败老鹰……";
}
}
class Book implements IReader{
public String getContent(){
return "很久很久以前有一个阿拉伯的故事……";
}
}

class Mother{
public void narrate(IReader reader){
System.out.println("妈妈开始讲故事");
System.out.println(reader.getContent());
}
}

public class Client{
public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book());
mother.narrate(new Newspaper());

}
}

运行结果
妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
妈妈开始讲故事
林书豪17+9助尼克斯击败老鹰……
这样修改后,无论以后怎样扩展Client类,都不需要再修改Mother类了。这只是一个简单的例子,实际情况中,代表高层模块的Mother类将负责完成主要的业务逻辑,一旦需要对它进行修改,引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性,提高系统的稳定性,降低修改程序造成的风险。
采用依赖倒置原则给多人并行开发带来了极大的便利,比如上例中,原本Mother类与Book类直接耦合时,Mother类必须等Book类编码完成后才可以进行编码,因为Mother类依赖于Book类。修改后的程序则可以同时开工,互不影响,因为Mother与Book类一点关系也没有。参与协作开发的人越多、项目越庞大,采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。
传递依赖关系有三种方式,以上的例子中使用的方法是接口传递,另外还有两种传递方式:构造方法传递和setter方法传递,相信用过Spring框架的,对依赖的传递方式一定不会陌生。
在实际编程中,我们一般需要做到如下3点:
低层模块尽量都要有抽象类或接口,或者两者都有。
变量的声明类型尽量是抽象类或接口。
使用继承时遵循里氏替换原则。
总之,依赖倒置原则就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。

接口隔离原则(Interface Segregation Principle)
定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。
问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法。
解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
举例来说明接口隔离原则:
1
(图1 未遵循接口隔离原则的设计)
这个图的意思是:类A依赖接口I中的方法1、方法2、方法3,类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5,类D是对类C依赖的实现。对于类B和类D来说,虽然他们都存在着用不到的方法(也就是图中红色字体标记的方法),但由于实现了接口I,所以也必须要实现这些用不到的方法。对类图不熟悉的可以参照程序代码来理解,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

interface I {
public void method1();
public void method2();
public void method3();
public void method4();
public void method5();
}

class A{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method2();
}
public void depend3(I i){
i.method3();
}
}

class B implements I{
public void method1() {
System.out.println("类B实现接口I的方法1");
}
public void method2() {
System.out.println("类B实现接口I的方法2");
}
public void method3() {
System.out.println("类B实现接口I的方法3");
}
//对于类A来说,method4和method5不是必需的,但是由于接口A中有这两个方法,
//所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。
public void method4() {}
public void method5() {}
}

class C{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method4();
}
public void depend3(I i){
i.method5();
}
}

class D implements I{
public void method1() {
System.out.println("类D实现接口I的方法1");
}
//对于类C来说,method2和method3不是必需的,但是由于接口A中有这两个方法,
//所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。
public void method2() {}
public void method3() {}

public void method4() {
System.out.println("类D实现接口I的方法4");
}
public void method5() {
System.out.println("类D实现接口I的方法5");
}
}

public class Client{
public static void main(String[] args){
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());

C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D()); }
}

可以看到,如果接口过于臃肿,只要接口中出现的方法,不管对依赖于它的类有没有用处,实现类中都必须去实现这些方法,这显然不是好的设计。如果将这个设计修改为符合接口隔离原则,就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口,拆分后的设计如图2所示:
2
(图2 遵循接口隔离原则的设计)
照例贴出程序的代码,供不熟悉类图的朋友参考:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
interface I1 {
public void method1();
}

interface I2 {
public void method2();
public void method3();
}

interface I3 {
public void method4();
public void method5();
}

class A{
public void depend1(I1 i){
i.method1();
}
public void depend2(I2 i){
i.method2();
}
public void depend3(I2 i){
i.method3();
}
}

class B implements I1, I2{
public void method1() {
System.out.println("类B实现接口I1的方法1");
}
public void method2() {
System.out.println("类B实现接口I2的方法2");
}
public void method3() {
System.out.println("类B实现接口I2的方法3");
}
}

class C{
public void depend1(I1 i){
i.method1();
}
public void depend2(I3 i){
i.method4();
}
public void depend3(I3 i){
i.method5();
}
}

class D implements I1, I3{
public void method1() {
System.out.println("类D实现接口I1的方法1");
}
public void method4() {
System.out.println("类D实现接口I3的方法4");
}
public void method5() {
System.out.println("类D实现接口I3的方法5");
}
}

接口隔离原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中,将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中,依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”,通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。
说到这里,很多人会觉的接口隔离原则跟之前的单一职责原则很相似,其实不然。其一,单一职责原则原注重的是职责;而接口隔离原则注重对接口依赖的隔离。其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口接口,主要针对抽象,针对程序整体框架的构建。
采用接口隔离原则对接口进行约束时,要注意以下几点:
接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。
为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。
提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。
运用接口隔离原则,一定要适度,接口设计的过大或过小都不好。设计接口的时候,只有多花些时间去思考和筹划,才能准确地实践这一原则。

迪米特法则(Law Of Demeter)
定义:一个对象应该对其他对象保持最少的了解。
问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。
解决方案:尽量降低类与类之间的耦合。
自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的。
迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。迪米特法则还有一个更简单的定义:只与直接的朋友通信。首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。
举一个例子:有一个集团公司,下属单位有分公司和直属部门,现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

//总公司员工
class Employee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}

//分公司员工
class SubEmployee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}

class SubCompanyManager{
public List<SubEmployee> getAllEmployee(){
List<SubEmployee> list = new ArrayList<SubEmployee>();
for(int i=0; i<100; i++){
SubEmployee emp = new SubEmployee();
//为分公司人员按顺序分配一个ID
emp.setId("分公司"+i);
list.add(emp);
}
return list;
}
}

class CompanyManager{

public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<Employee>();
for(int i=0; i<30; i++){
Employee emp = new Employee();
//为总公司人员按顺序分配一个ID
emp.setId("总公司"+i);
list.add(emp);
}
return list;
}

public void printAllEmployee(SubCompanyManager sub){
List<SubEmployee> list1 = sub.getAllEmployee();
for(SubEmployee e:list1){
System.out.println(e.getId());
}

List<Employee> list2 = this.getAllEmployee();
for(Employee e:list2){
System.out.println(e.getId());
}
}
}

public class Client{
public static void main(String[] args){
CompanyManager e = new CompanyManager();
e.printAllEmployee(new SubCompanyManager());
}
}

现在这个设计的主要问题出在CompanyManager中,根据迪米特法则,只与直接的朋友发生通信,而SubEmployee类并不是CompanyManager类的直接朋友(以局部变量出现的耦合不属于直接朋友),从逻辑上讲总公司只与他的分公司耦合就行了,与分公司的员工并没有任何联系,这样设计显然是增加了不必要的耦合。按照迪米特法则,应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
class SubCompanyManager{
public List<SubEmployee> getAllEmployee(){
List<SubEmployee> list = new ArrayList<SubEmployee>();
for(int i=0; i<100; i++){
SubEmployee emp = new SubEmployee();
//为分公司人员按顺序分配一个ID
emp.setId("分公司"+i);
list.add(emp);
}
return list;
}
public void printEmployee(){
List<SubEmployee> list = this.getAllEmployee();
for(SubEmployee e:list){
System.out.println(e.getId());
}
}
}

class CompanyManager{
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<Employee>();
for(int i=0; i<30; i++){
Employee emp = new Employee();
//为总公司人员按顺序分配一个ID
emp.setId("总公司"+i);
list.add(emp);
}
return list;
}

public void printAllEmployee(SubCompanyManager sub){
sub.printEmployee();
List<Employee> list2 = this.getAllEmployee();
for(Employee e:list2){
System.out.println(e.getId());
}
}
}

修改后,为分公司增加了打印人员ID的方法,总公司直接调用来打印,从而避免了与分公司的员工发生耦合。
迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。但是凡事都有度,虽然可以避免与非直接的类通信,但是要通信,必然会通过一个“中介”来发生联系,例如本例中,总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则,会产生大量这样的中介和传递类,导致系统复杂度变大。所以在采用迪米特法则时要反复权衡,既做到结构清晰,又要高内聚低耦合。

开闭原则(Open Close Principle)
定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试。
解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。
开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统。开闭原则可能是设计模式六项原则中定义最模糊的一个了,它只告诉我们对扩展开放,对修改关闭,可是到底如何才能做到对扩展开放,对修改关闭,并没有明确的告诉我们。以前,如果有人告诉我“你进行设计的时候一定要遵守开闭原则”,我会觉的他什么都没说,但貌似又什么都说了。因为开闭原则真的太虚了。
在仔细思考以及仔细阅读很多设计模式的文章后,终于对开闭原则有了一点认识。其实,我们遵循设计模式前面5大原则,以及使用23种设计模式的目的就是遵循开闭原则。也就是说,只要我们对前面5项原则遵守的好了,设计出的软件自然是符合开闭原则的,这个开闭原则更像是前面五项原则遵守程度的“平均得分”,前面5项原则遵守的好,平均分自然就高,说明软件设计开闭原则遵守的好;如果前面5项原则遵守的不好,则说明开闭原则遵守的不好。
其实笔者认为,开闭原则无非就是想表达这样一层意思:用抽象构建框架,用实现扩展细节。因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。而软件中易变的细节,我们用从抽象派生的实现类来进行扩展,当软件需要发生变化时,我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理,要对需求的变更有前瞻性和预见性才行。
说到这里,再回想一下前面说的5项原则,恰恰是告诉我们用抽象构建框架,用实现扩展细节的注意事项而已:单一职责原则告诉我们实现类要职责单一;里氏替换原则告诉我们不要破坏继承体系;依赖倒置原则告诉我们要面向接口编程;接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合。而开闭原则是总纲,他告诉我们要对扩展开放,对修改关闭。
最后说明一下如何去遵守这六个原则。对这六个原则的遵守并不是是和否的问题,而是多和少的问题,也就是说,我们一般不会说有没有遵守,而是说遵守程度的多少。任何事都是过犹不及,设计模式的六个设计原则也是一样,制定这六个原则的目的并不是要我们刻板的遵守他们,而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内,就算是良好的设计。我们用一幅图来说明一下。
3
图中的每一条维度各代表一项原则,我们依据对这项原则的遵守程度在维度上画一个点,则如果对这项原则遵守的合理的话,这个点应该落在红色的同心圆内部;如果遵守的差,点将会在小圆内部;如果过度遵守,点将会落在大圆外部。一个良好的设计体现在图中,应该是六个顶点都在同心圆中的六边形。
4
在上图中,设计1、设计2属于良好的设计,他们对六项原则的遵守程度都在合理的范围内;设计3、设计4设计虽然有些不足,但也基本可以接受;设计5则严重不足,对各项原则都没有很好的遵守;而设计6则遵守过渡了,设计5和设计6都是迫切需要重构的设计。

转载自 http://blog.csdn.net/zhengzhb/article/details/7296944

高效率去掉js数组中重复项

Array类型并没有提供去重复的方法,如果要把数组的重复元素干掉,那得自己想办法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function unique(arr) {
var result = [], isRepeated;
for (var i = 0, len = arr.length; i < len; i++) {
isRepeated = false;
for (var j = 0, len = result.length; j < len; j++) {
if (arr[i] == result[j]) {
isRepeated = true;
break;
}
}
if (!isRepeated) {
result.push(arr[i]);
}
}
return result;
}

总体思路是把数组元素逐个搬运到另一个数组,搬运的过程中检查这个元素是否有重复,如果有就直接丢掉。从嵌套循环就可以看出,这种方法效率极低。我们可以 用一个hashtable的结构记录已有的元素,这样就可以避免内层循环。恰好,在Javascript中实现hashtable是极为简单的,改进如 下:

1
2
3
4
5
6
7
8
9
10
11
function unique(arr) {
var result = [], hash = {};
for (var i = 0, elem; (elem = arr[i]) != null; i++) {
if (!hash[elem]) {
result.push(elem);
hash[elem] = true;
}
}
return result;
//http://www.cnblogs.com/sosoft/
}

转载自 http://www.cnblogs.com/sosoft/archive/2013/12/08/3463830.html

运维角度浅谈:MySQL数据库优化(转)

本博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段:

1、数据库表设计
项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计。对于数据库来说,这点很重要,如果设计不当,会直接影响访问速度和用户体验。影响的因素很多,比如慢查询、低效的查询语句、没有适当建立索引、数据库堵塞(死锁)等。当然,有测试工程师的团队,会做压力测试,找bug。对于没有测试工程师的团队来说,大多数开发工程师初期不会太多考虑数据库设计是否合理,而是尽快完成功能实现和交付,等项目有一定访问量后,隐藏的问题就会暴露,这时再去修改就不是这么容易的事了。

2、数据库部署
该运维工程师出场了,项目初期访问量不会很大,所以单台部署足以应对在1500左右的QPS(每秒查询率)。考虑到高可用性,可采用MySQL主从复制+Keepalived做双击热备,常见集群软件有Keepalived、Heartbeat。
双机热备博文:http://lizhenliang.blog.51cto.com/7876557/1362313

3、数据库性能优化
如果将MySQL部署到普通的X86服务器上,在不经过任何优化情况下,MySQL理论值正常可以处理2000左右QPS,经过优化后,有可能会提升到2500左右QPS,否则,访问量当达到1500左右并发连接时,数据库处理性能就会变慢,而且硬件资源还很富裕,这时就该考虑软件问题了。那么怎样让数据库最大化发挥性能呢?一方面可以单台运行多个MySQL实例让服务器性能发挥到最大化,另一方面是对数据库进行优化,往往操作系统和数据库默认配置都比较保守,会对数据库发挥有一定限制,可对这些配置进行适当的调整,尽可能的处理更多连接数。

具体优化有以下三个层面:
3.1 数据库配置优化
MySQL常用有两种存储引擎,一个是MyISAM,不支持事务处理,读性能处理快,表级别锁。另一个是InnoDB,支持事务处理(ACID),设计目标是为处理大容量数据发挥最大化性能,行级别锁。

表锁:开销小,锁定粒度大,发生死锁概率高,相对并发也低。
行锁:开销大,锁定粒度小,发生死锁概率低,相对并发也高。

为什么会出现表锁和行锁呢?主要是为了保证数据的完整性,举个例子,一个用户在操作一张表,其他用户也想操作这张表,那么就要等第一个用户操作完,其他用户才能操作,表锁和行锁就是这个作用。否则多个用户同时操作一张表,肯定会数据产生冲突或者异常。
根据以上看来,使用InnoDB存储引擎是最好的选择,也是MySQL5.5以后版本中默认存储引擎。每个存储引擎相关联参数比较多,以下列出主要影响数据库性能的参数。

公共参数默认值:

1
2
3
4
5
6
7
8
9
10
max_connections = 151
#同时处理最大连接数,推荐设置最大连接数是上限连接数的80%左右
sort_buffer_size = 2M
#查询排序时缓冲区大小,只对order by和group by起作用,可增大此值为16M
query_cache_limit = 1M
#查询缓存限制,只有1M以下查询结果才会被缓存,以免结果数据较大把缓存池覆盖
query_cache_size = 16M
#查看缓冲区大小,用于缓存SELECT查询结果,下一次有同样SELECT查询将直接从缓存池返回结果,可适当成倍增加此值
open_files_limit = 1024
#打开文件数限制,如果show global status like 'open_files'查看的值等于或者大于open_files_limit值时,程序会无法连接数据库或卡死

MyISAM参数默认值:

1
2
3
4
key_buffer_size = 16M
#索引缓存区大小,一般设置物理内存的30-40%
read_buffer_size = 128K
#读操作缓冲区大小,推荐设置16M或32M

InnoDB参数默认值:

1
2
3
4
5
6
7
8
9
10
innodb_buffer_pool_size = 128M
#索引和数据缓冲区大小,一般设置物理内存的60%-70%
innodb_buffer_pool_instances = 1
#缓冲池实例个数,推荐设置4个或8个
innodb_flush_log_at_trx_commit = 1
#关键参数,0代表大约每秒写入到日志并同步到磁盘,数据库故障会丢失1秒左右事务数据。1为每执行一条SQL后写入到日志并同步到磁盘,I/O开销大,执行完SQL要等待日志读写,效率低。2代表只把日志写入到系统缓存区,再每秒同步到磁盘,效率很高,如果服务器故障,才会丢失事务数据。对数据安全性要求不是很高的推荐设置2,性能高,修改后效果明显。
innodb_file_per_table = OFF
#默认是共享表空间,共享表空间idbdata文件不断增大,影响一定的I/O性能。推荐开启独立表空间模式,每个表的索引和数据都存在自己独立的表空间中,可以实现单表在不同数据库中移动。
innodb_log_buffer_size = 8M
#日志缓冲区大小,由于日志最长每秒钟刷新一次,所以一般不用超过16M

3.2 系统内核优化
大多数MySQL都部署在linux系统上,所以操作系统的一些参数也会影响到MySQL性能,以下对linux内核进行适当优化。

3.3 硬件配置
加大物理内存,提高文件系统性能。linux内核会从内存中分配出缓存区(系统缓存和数据缓存)来存放热数据,通过文件系统延迟写入机制,等满足条件时(如缓存区大小到达一定百分比或者执行sync命令)才会同步到磁盘。也就是说物理内存越大,分配缓存区越大,缓存数据越多。当然,服务器故障会丢失一定的缓存数据。
SSD硬盘代替SAS硬盘,将RAID级别调整为RAID1+0,相对于RAID1和RAID5有更好的读写性能(IOPS),毕竟数据库的压力主要来自磁盘I/O方面。

4、数据库架构扩展
随着业务量越来越大,单台数据库服务器性能已无法满足业务需求,该考虑加机器了,该做集群了~~~。主要思想是分解单台数据库负载,突破磁盘I/O性能,热数据存放缓存中,降低磁盘I/O访问频率。

4.1 主从复制与读写分离
因为生产环境中,数据库大多都是读操作,所以部署一主多从架构,主数据库负责写操作,并做双击热备,多台从数据库做负载均衡,负责读操作,主流的负载均衡器有LVS、HAProxy、Nginx。怎么来实现读写分离呢?大多数企业是在代码层面实现读写分离,效率比较高。另一个种方式通过代理程序实现读写分离,企业中应用较少,常见代理程序有MySQL Proxy、Amoeba。在这样数据库集群架构中,大大增加数据库高并发能力,解决单台性能瓶颈问题。如果从数据库一台从库能处理2000 QPS,那么5台就能处理1w QPS,数据库横向扩展性也很容易。
有时,面对大量写操作的应用时,单台写性能达不到业务需求。如果做双主,就会遇到数据库数据不一致现象,产生这个原因是在应用程序不同的用户会有可能操作两台数据库,同时的更新操作造成两台数据库数据库数据发生冲突或者不一致。在单库时MySQL利用存储引擎机制表锁和行锁来保证数据完整性,怎样在多台主库时解决这个问题呢?有一套基于perl语言开发的主从复制管理工具,叫MySQL-MMM(Master-Master replication managerfor Mysql,Mysql主主复制管理器),这个工具最大的优点是在同一时间只提供一台数据库写操作,有效保证数据一致性。

4.2 增加缓存
给数据库增加缓存系统,把热数据缓存到内存中,如果内存缓存中有要请求的数据就不再去数据库中返回结果,提高读性能。缓存实现有本地缓存和分布式缓存,本地缓存是将数据缓存到本地服务器内存中或者文件中,速度快。分布式可以缓存海量数据,扩展容易,主流的分布式缓存系统有memcached、redis,memcached性能稳定,数据缓存在内存中,速度很快,QPS可达8w左右。如果想数据持久化那就用redis,性能不低于memcached。

工作过程:
640

4.3 分库
分库是根据业务不同把相关的表切分到不同的数据库中,比如web、bbs、blog等库。如果业务量很大,还可将切分后的库做主从架构,进一步避免单个库压力过大。

4.4 分表
数据量的日剧增加,数据库中某个表有几百万条数据,导致查询和插入耗时太长,怎么能解决单表压力呢?你就该考虑是否把这个表拆分成多个小表,来减轻单个表的压力,提高处理效率,此方式称为分表。
分表技术比较麻烦,要修改程序代码里的SQL语句,还要手动去创建其他表,也可以用merge存储引擎实现分表,相对简单许多。分表后,程序是对一个总表进行操作,这个总表不存放数据,只有一些分表的关系,以及更新数据的方式,总表会根据不同的查询,将压力分到不同的小表上,因此提高并发能力和磁盘I/O性能。

分表分为垂直拆分和水平拆分:
垂直拆分:把原来的一个很多字段的表拆分多个表,解决表的宽度问题。你可以把不常用的字段单独放到一个表中,也可以把大字段独立放一个表中,或者把关联密切的字段放一个表中。
水平拆分:把原来一个表拆分成多个表,每个表的结构都一样,解决单表数据量大的问题。

4.5 分区
分区就是把一张表的数据分成多个区块,这些区块可以在一个磁盘上,也可以在不同的磁盘上,分区后,表面上还是一张表,但数据散列在多个位置,这样一来,多块硬盘同时处理不同的请求,从而提高磁盘I/O读写性能,实现比较简单。
注:增加缓存、分库、分表和分区主要由程序猿来实现。

5、数据库维护
数据库维护是运维工程师或者DBA主要工作,包括性能监控、性能分析、性能调优、数据库备份和恢复等。

5.1 性能状态关键指标

  • QPS,Queries Per Second:每秒查询数,一台数据库每秒能够处理的查询次数;
  • TPS,Transactions Per Second:每秒处理事务数。

通过show status查看运行状态,会有300多条状态信息记录,其中有几个值帮可以我们计算出QPS和TPS,如下:

  • Uptime:服务器已经运行的实际,单位秒
  • Questions:已经发送给数据库查询数
  • Com_select:查询次数,实际操作数据库的
  • Com_insert:插入次数
  • Com_delete:删除次数
  • Com_update:更新次数
  • Com_commit:事务次数
  • Com_rollback:回滚次数

那么,计算方法来了,基于Questions计算出QPS:

QPS = Questions / Uptime

1
2
mysql> show global status like 'Questions';
mysql> show global status like 'Uptime';

基于Com_commit和Com_rollback计算出TPS:

1
2
3
4
mysql> show global status like 'Com_commit';
mysql> show global status like 'Com_rollback';
mysql> show global status like 'Uptime';
TPS = (Com_commit + Com_rollback) / Uptime

另一计算方式:基于Com_select、Com_insert、Com_delete、Com_update计算出QPS。

1
2
mysql> show global status where Variable_name in('com_select','com_insert','com_delete','com_update');
等待1秒再执行,获取间隔差值,第二次每个变量值减去第一次对应的变量值,就是QPS

TPS计算方法:

1
2
3
mysql> show global status where Variable_name in('com_insert','com_delete','com_update');
计算TPS,就不算查询操作了,计算出插入、删除、更新四个值即可。
经网友对这两个计算方式的测试得出,当数据库中myisam表比较多时,使用Questions计算比较准确。当数据库中innodb表比较多时,则以Com_*计算比较准确。

5.2 开启慢查询日志
MySQL开启慢查询日志,分析出哪条SQL语句比较慢,使用set设置变量,重启服务失效,可以在my.cnf添加参数永久生效。

1
2
3
4
mysql> set global slow-query-log=on #开启慢查询功能
mysql> set global slow_query_log_file='/var/log/mysql/mysql-slow.log'; #指定慢查询日志文件位置
mysql> set global log_queries_not_using_indexes=on; #记录没有使用索引的查询
mysql> set global long_query_time=1; #只记录处理时间1s以上的慢查询

分析慢查询日志,可以使用MySQL自带的mysqldumpslow工具,分析的日志较为简单。

1
# mysqldumpslow -t 3 /var/log/mysql/mysql-slow.log #查看最慢的前三个查询

也可以使用percona公司的pt-query-digest工具,日志分析功能全面,可分析slow log、binlog、general log。

  • 分析慢查询日志:pt-query-digest /var/log/mysql/mysql-slow.log
  • 分析binlog日志:mysqlbinlog mysql-bin.000001 >mysql-bin.000001.sql
  • pt-query-digest –type=binlog mysql-bin.000001.sql
  • 分析普通日志:pt-query-digest –type=genlog localhost.log

5.3 数据库备份
备份数据库是最基本的工作,也是最重要的,否则后果很严重,你懂得!但由于数据库比较大,上百G,往往备份都很耗费时间,所以就该选择一个效率高的备份策略,对于数据量大的数据库,一般都采用增量备份。常用的备份工具有mysqldump、mysqlhotcopy、xtrabackup等,mysqldump比较适用于小的数据库,因为是逻辑备份,所以备份和恢复耗时都比较长。mysqlhotcopy和xtrabackup是物理备份,备份和恢复速度快,不影响数据库服务情况下进行热拷贝,建议使用xtrabackup,支持增量备份。
Xtrabackup备份工具使用博文:http://lizhenliang.blog.51cto.com/7876557/1612800

5.4 数据库修复
有时候MySQL服务器突然断电、异常关闭,会导致表损坏,无法读取表数据。这时就可以用到MySQL自带的两个工具进行修复,myisamchk和mysqlcheck。

myisamchk:只能修复myisam表,需要停止数据库

常用参数:
-f –force 强制修复,覆盖老的临时文件,一般不使用
-r –recover 恢复模式
-q –quik 快速恢复
-a –analyze 分析表
-o –safe-recover 老的恢复模式,如果-r无法修复,可以使用此参数试试
-F –fast 只检查没有正常关闭的表

快速修复weibo数据库:

1
2
# cd /var/lib/mysql/weibo 
# myisamchk -r -q *.MYI

mysqlcheck:myisam和innodb表都可以用,不需要停止数据库,如修复单个表,可在数据库后面添加表名,以空格分割。

常用参数:
-a –all-databases 检查所有的库
-r –repair 修复表
-c –check 检查表,默认选项
-a –analyze 分析表
-o –optimize 优化表
-q –quik 最快检查或修复表
-F –fast 只检查没有正常关闭的表

快速修复weibo数据库:

1
mysqlcheck -r -q -uroot -p123 weibo

5.5 另外,查看CPU和I/O性能方法

  • 查看CPU性能0
  • 参数-P是显示CPU数,ALL为所有,也可以只显示第几颗1
  • 查看I/O性能2

参数-m是以M单位显示,默认K
%util:当达到100%时,说明I/O很忙。
await:请求在队列中等待时间,直接影响read时间。
I/O极限:IOPS(r/s+w/s),一般在1200左右。(IOPS,每秒进行读写(I/O)操作次数)
I/O带宽:在顺序读写模式下SAS硬盘理论值在300M/s左右,SSD硬盘理论值在600M/s左右。

以上是本人使用MySQL三年来总结的一些主要优化方案,能力有限,有些不太全面,但这些基本能够满足中小型企业数据库需求。由于关系型数据库初衷设计限制,一些BAT公司海量数据放到关系型数据库中,在海量数据查询和分析方面已经达不到更好的性能。因此NoSQL火起来了,非关系型数据库,大数据量,具有高性能,同时也弥补了关系型数据库某方面不足,渐渐大多数公司已经将部分业务数据库存放到NoSQL中,如MongoDB、HBase等。数据存储方面采用分布式文件系统,如HDFS、GFS等。海量数据计算分析采用Hadoop、Spark、Storm等。这些都是与运维相关的前沿技术,也是在存储方面主要学习对象,小伙伴们共同加油吧!哪位博友有更好的优化方案,欢迎交流哦。

Rolling cURL: PHP并发最佳实践

在实际项目或者自己编写小工具(比如新闻聚合,商品价格监控,比价)的过程中, 通常需要从第3方网站或者API接口获取数据, 在需要处理1个URL队列时, 为了提高性能, 可以采用cURL提供的curl_multi_*族函数实现简单的并发.

本文将探讨两种具体的实现方法, 并对不同的方法做简单的性能对比.

1. 经典cURL并发机制及其存在的问题
经典的cURL实现机制在网上很容易找到, 比如参考PHP在线手册的如下实现方式:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
function classic_curl($urls, $delay) {
$queue = curl_multi_init();
$map = array();

foreach ($urls as $url) {
// create cURL resources
$ch = curl_init();

// set URL and other appropriate options
curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt($ch, CURLOPT_TIMEOUT, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_NOSIGNAL, true);

// add handle
curl_multi_add_handle($queue, $ch);
$map[$url] = $ch;
}

$active = null;

// execute the handles
do {
$mrc = curl_multi_exec($queue, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);

while ($active > 0 && $mrc == CURLM_OK) {
if (curl_multi_select($queue, 0.5) != -1) {
do {
$mrc = curl_multi_exec($queue, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
}
}

$responses = array();
foreach ($map as $url=>$ch) {
$responses[$url] = callback(curl_multi_getcontent($ch), $delay);
curl_multi_remove_handle($queue, $ch);
curl_close($ch);
}

curl_multi_close($queue);
return $responses;
}

首先将所有的URL压入并发队列, 然后执行并发过程, 等待所有请求接收完之后进行数据的解析等后续处理. 在实际的处理过程中, 受网络传输的影响, 部分URL的内容会优先于其他URL返回, 但是经典cURL并发必须等待最慢的那个URL返回之后才开始处理, 等待也就意味着CPU的空闲和浪费. 如果URL队列很短, 这种空闲和浪费还处在可接受的范围, 但如果队列很长, 这种等待和浪费将变得不可接受.

2. 改进的Rolling cURL并发方式
仔细分析不难发现经典cURL并发还存在优化的空间, 优化的方式时当某个URL请求完毕之后尽可能快的去处理它, 边处理边等待其他的URL返回, 而不是等待那个最慢的接口返回之后才开始处理等工作, 从而避免CPU的空闲和浪费. 闲话不多说, 下面贴上具体的实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
function rolling_curl($urls, $delay) {
$queue = curl_multi_init();
$map = array();

foreach ($urls as $url) {
$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_TIMEOUT, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_NOSIGNAL, true);

curl_multi_add_handle($queue, $ch);
$map[(string) $ch] = $url;
}

$responses = array();
do {
while (($code = curl_multi_exec($queue, $active)) == CURLM_CALL_MULTI_PERFORM) ;

if ($code != CURLM_OK) { break; }

// a request was just completed -- find out which one
while ($done = curl_multi_info_read($queue)) {

// get the info and content returned on the request
$info = curl_getinfo($done['handle']);
$error = curl_error($done['handle']);
$results = callback(curl_multi_getcontent($done['handle']), $delay);
$responses[$map[(string) $done['handle']]] = compact('info', 'error', 'results');

// remove the curl handle that just completed
curl_multi_remove_handle($queue, $done['handle']);
curl_close($done['handle']);
}

// Block for data in / output; error handling is done by curl_multi_exec
if ($active > 0) {
curl_multi_select($queue, 0.5);
}

} while ($active);

curl_multi_close($queue);
return $responses;
}

3. 两种并发实现的性能对比
改进前后的性能对比试验在LINUX主机上进行, 测试时使用的并发队列如下:

简要说明下实验设计的原则和性能测试结果的格式: 为保证结果的可靠, 每组实验重复20次, 在单次实验中, 给定相同的接口URL集合, 分别测量Classic(指经典的并发机制)和Rolling(指改进后的并发机制)两种并发机制的耗时(秒为单位), 耗时短者胜出(Winner), 并计算节省的时间(Excellence, 秒为单位)以及性能提升比例(Excel. %). 为了尽量贴近真实的请求而又保持实验的简单, 在对返回结果的处理上只是做了简单的正则表达式匹配, 而没有进行其他复杂的操作. 另外, 为了确定结果处理回调对性能对比测试结果的影响, 可以使用usleep模拟现实中比较负责的数据处理逻辑(如提取, 分词, 写入文件或数据库等).

性能测试中用到的回调函数为:

1
2
3
4
5
function callback($data, $delay) {
preg_match_all('/<h3>(.+)<\/h3>/iU', $data, $matches);
usleep($delay);
return compact('data', 'matches');
}

数据处理回调无延迟时: Rolling Curl略优, 但性能提升效果不明显.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
------------------------------------------------------------------------------------------------
Delay: 0 micro seconds, equals to 0 milli seconds
------------------------------------------------------------------------------------------------
Counter Classic Rolling Winner Excellence Excel. %
------------------------------------------------------------------------------------------------
1 0.1193 0.0390 Rolling 0.0803 67.31%
2 0.0556 0.0477 Rolling 0.0079 14.21%
3 0.0461 0.0588 Classic -0.0127 -21.6%
4 0.0464 0.0385 Rolling 0.0079 17.03%
5 0.0534 0.0448 Rolling 0.0086 16.1%
6 0.0540 0.0714 Classic -0.0174 -24.37%
7 0.0386 0.0416 Classic -0.0030 -7.21%
8 0.0357 0.0398 Classic -0.0041 -10.3%
9 0.0437 0.0442 Classic -0.0005 -1.13%
10 0.0319 0.0348 Classic -0.0029 -8.33%
11 0.0529 0.0430 Rolling 0.0099 18.71%
12 0.0503 0.0581 Classic -0.0078 -13.43%
13 0.0344 0.0225 Rolling 0.0119 34.59%
14 0.0397 0.0643 Classic -0.0246 -38.26%
15 0.0368 0.0489 Classic -0.0121 -24.74%
16 0.0502 0.0394 Rolling 0.0108 21.51%
17 0.0592 0.0383 Rolling 0.0209 35.3%
18 0.0302 0.0285 Rolling 0.0017 5.63%
19 0.0248 0.0553 Classic -0.0305 -55.15%
20 0.0137 0.0131 Rolling 0.0006 4.38%
------------------------------------------------------------------------------------------------
Average 0.0458 0.0436 Rolling 0.0022 4.8%
------------------------------------------------------------------------------------------------
Summary: Classic wins 10 times, while Rolling wins 10 times

数据处理回调延迟5毫秒: Rolling Curl完胜, 性能提升40%左右.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
------------------------------------------------------------------------------------------------
Delay: 5000 micro seconds, equals to 5 milli seconds
------------------------------------------------------------------------------------------------
Counter Classic Rolling Winner Excellence Excel. %
------------------------------------------------------------------------------------------------
1 0.0658 0.0352 Rolling 0.0306 46.5%
2 0.0728 0.0367 Rolling 0.0361 49.59%
3 0.0732 0.0387 Rolling 0.0345 47.13%
4 0.0783 0.0347 Rolling 0.0436 55.68%
5 0.0658 0.0286 Rolling 0.0372 56.53%
6 0.0687 0.0362 Rolling 0.0325 47.31%
7 0.0787 0.0337 Rolling 0.0450 57.18%
8 0.0676 0.0391 Rolling 0.0285 42.16%
9 0.0668 0.0351 Rolling 0.0317 47.46%
10 0.0603 0.0317 Rolling 0.0286 47.43%
11 0.0714 0.0350 Rolling 0.0364 50.98%
12 0.0627 0.0215 Rolling 0.0412 65.71%
13 0.0617 0.0401 Rolling 0.0216 35.01%
14 0.0721 0.0226 Rolling 0.0495 68.65%
15 0.0701 0.0428 Rolling 0.0273 38.94%
16 0.0674 0.0352 Rolling 0.0322 47.77%
17 0.0452 0.0425 Rolling 0.0027 5.97%
18 0.0596 0.0366 Rolling 0.0230 38.59%
19 0.0679 0.0480 Rolling 0.0199 29.31%
20 0.0657 0.0338 Rolling 0.0319 48.55%
------------------------------------------------------------------------------------------------
Average 0.0671 0.0354 Rolling 0.0317 47.24%
------------------------------------------------------------------------------------------------
Summary: Classic wins 0 times, while Rolling wins 20 times

通过上面的性能对比, 在处理URL队列并发的应用场景中Rolling cURL应该是更加的选择, 并发量非常大(1000+)时, 可以控制并发队列的最大长度, 比如20, 每当1个URL返回并处理完毕之后立即加入1个尚未请求的URL到队列中, 这样写出来的代码会更加健壮, 不至于并发数太大而卡死或崩溃. 详细的实现请参考: http://code.google.com/p/rolling-curl/(博主注:rolling-curl 源码下载

5. 参考资料和延伸阅读

转载自 http://www.searchtb.com/2012/06/rolling-curl-best-practices.html

Ubuntu 14.04 安装 QQ 7.2

  首先,添加 ppa,并安装 wine1.7。要是 apt-get update 的时候报错请参考前一篇文章《Ubuntu 使用 shadowsocks 科学上网》。

1
2
3
sudo add-apt-repository ppa:ubuntu-wine/ppa
sudo apt-get update
sudo apt-get install wine1.7

  wine 1.7 安装完成后,安装一些依赖:

1
winetricks riched20 gdiplus msxml4 vcrun2005 msctf mfc42 fakechinese corefonts sound=alsa

  之后,将 win 下字体文件夹(C:\Windows\Fonts)内的所有字体复制至 ~/.wine/drive_c/windows/Fonts。
  打开 http://im.qq.com 下载最新版 QQ,双击安装即可。
  安装完成后,需要自行建立快捷方式:

1
vi ~/桌面/QQ.desktop

1
2
3
4
5
[Desktop Entry]
Name=腾讯QQ
Exec=wine "C:\\Program Files (x86)\\Tencent\\QQ\\bin\\QQ.exe"
Type=Application
StartupNotify=true

  给快捷方式加上可执行权限:

1
chmod +x ~/桌面/QQ.desktop

  效果如图
Screenshots_2015_06_02_21_09_01

  小 bug 还是有点的,比如图中有些字依旧是方块,不过是字体问题,找到对应字体 copy 下就行。还有,切记!千!万!不!能!最!小!化!消!息!列!表!因为没有状态栏。。。要是不小心最小化或者不见了,可以用以下命令解决问题:

1
2
killall QQ.exe
wine "C:\\Program Files (x86)\\Tencent\\QQ\\bin\\QQ.exe"

  你没看错。。就是重启 QQ

  最后,提供几个比较好的补丁,希望各位喜欢:

  感谢 (╯‵□′)╯︵┻━┻ 提供技术支持。

  参考:

Ubuntu 使用 shadowsocks 科学上网

  不知道为什么我的系统运行有 gui 的版本会假死。。Ubuntu 14.04:
2015-05-31 20:10:21屏幕截图
  所以,我用了 sslocal + tsocks 实现的科学上网,chrome 需要插件 SwitchyOmega,文末提供下载链接及安装配置方法。
  首先,安装 sslocal,pip install shadowsocks

  安装完成后,新建 json 配置文件,这里位置为 /etc/shadowsocks.json,文件内容大致如下:
QQ截图20150531201514
  配置完成后,运行 sslocal

1
sslocal -c /etc/shadowsocks.json --pid-file /var/run/shadowsocks.pid -d start

  安装 tsocks 实现 socks5 转 http 代理:

1
apt-get install tsocks

  配置 tsocks(/etc/tsocks.conf):
QQ截图20150531201836
  使用时只需在命令前加上 tsocks 即可,比如 tsocks apt-get update

  关于 chrome 的配置:
  下载 SwitchyOmega,并解压。将解压出来的 SwitchyOmega.crx 拖动至 chrome://extensions/ 安装即可。
  安装完成后会自动弹出配置页,如图配置即可:
2015-05-31 20:25:54屏幕截图

感觉我又恶劣了一把。。

以前研究学校的 WiFi,写过一篇文章:纯靠点小聪明搞定学校 WiFi 该死的 web 登陆,然后利用这个。。。咳咳懂的。但最近遇到点事情需要收回账号,但给出账号时已经给出了所有权限,包括修改密码的,结果只能用点特殊手段,看图。
QQ图片20150507200223
输错五次密码自动锁定五分钟。。这样的话,要永久锁定不就是件很简单的事情了?只要写个程序不断模拟提交错误密码就行,但是,这里却遇到个问题:验证码。网上搜了很多资料,发现一篇很有用的文章:http://www.geekso.com/Valite2/ 修改了下字模,很顺利地认出了学校 Web Portal 弱智的验证码:
QQ图片20150507201318
2333,写完以后扔在了一部小渣机里,结果居然不卡
QQ图片20150507185259
QQ图片20150507185322

用.htaccess设置PHP错误显示(转)

今天在网上看到使用.htaccess可以在某种程度上更改PHP的错误显示的设置,实际上相当于更改PHP.ini的参数,很是方便。将以下相应代码放到对应目录中的.htaccess文件,即可实现相应功能。

关闭错误显示:

1
2
3
4
5
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_value docref_root 0
php_value docref_ext 0

只显示PHP错误:

1
2
3
php_flag  display_errors        on
php_flag display_startup_errors on
php_value error_reporting 2047

其中,“2047”为要显示的错误的级别,详细表格如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
2047 E_ALL
2048 E_STRICT
4096 E_RECOVERABLE_ERROR

要把错误保存到日志文件中,可以这样设置:

1
2
3
# enable PHP error logging
php_flag log_errors on
php_value error_log /home/path/public_html/domain/PHP_errors.log

然后,可以设置不允许访问.log文件:

1
2
3
4
5
6
# prevent access to PHP error log
<Files PHP_errors.log>
Order allow,deny
Deny from all
Satisfy All
</Files>

设置错误日志的最大体积,以bytes为单位:

1
2
3
4
5
6
# general directive for



setting max error size
log_errors_max_len integer

综合上述,.htaccess的PHP错误显示设置汇总:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# PHP error handling for production servers

# disable display of startup errors
php_flag display_startup_errors off

# disable display of all other errors
php_flag display_errors off

# disable html markup of errors
php_flag html_errors off

# enable logging of errors
php_flag log_errors on

# disable ignoring of repeat errors
php_flag ignore_repeated_errors off

# disable ignoring of unique source errors
php_flag ignore_repeated_source off

# enable logging of php memory leaks
php_flag report_memleaks on

# preserve most recent error via php_errormsg
php_flag track_errors on

# disable formatting of error reference links
php_value docref_root 0

# disable formatting of error reference links
php_value docref_ext 0

# specify path to php error log
php_value error_log /home/path/public_html/domain/PHP_errors.log

# specify recording of all php errors
php_value error_reporting 999999999

# disable max error string length
php_value log_errors_max_len 0

# protect error log by preventing public access
<Files /home/path/public_html/domain/PHP_errors.log>
Order allow,deny
Deny from all
Satisfy All
</Files>

以下则是适合开发者应用的设置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# PHP error handling for



development servers
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag log_errors on
php_flag ignore_repeated_errors off
php_flag ignore_repeated_source off
php_flag report_memleaks on
php_flag track_errors on
php_value docref_root 0
php_value docref_ext 0
php_value error_log /home/path/public_html/domain/PHP_errors.log
php_value error_reporting 999999999
php_value log_errors_max_len 0

<Files /home/path/public_html/domain/PHP_errors.log>
Order allow,deny
Deny from all
Satisfy All
</Files>

本文大部分内容参考这篇文章:How to Enable PHP Error Logging via htaccess ,大家有兴趣的话可以阅读英文原版。

转载自 http://blog.slogra.com/post-79.html