所有由suliang20发布的文章

RBAC打造通用WEB权限

 

RBAC不用给用户单个分配权限,只用指向对应的角色就会有对应的权限,而且分配权限和收回权限都很方便

5个关系对应5张表

五张表设计

复制代码
 1 CREATE TABLE `user` (
 2   `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
 3   `name` varchar(20) NOT NULL DEFAULT '' COMMENT '姓名',
 4   `email` varchar(30) NOT NULL DEFAULT '' COMMENT '邮箱',
 5   `is_admin` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否是超级管理员 1表示是 0 表示不是',
 6   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1:有效 0:无效',
 7   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
 8   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
 9   PRIMARY KEY (`id`),
10   KEY `idx_email` (`email`)
11 ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='用户表';
12 
13 CREATE TABLE `role` (
14   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
15   `name` varchar(50) NOT NULL DEFAULT '' COMMENT '角色名称',
16   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1:有效 0:无效',
17   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
18   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
19   PRIMARY KEY (`id`)
20 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色表';
21 
22 CREATE TABLE `user_role` (
23   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
24   `uid` int(11) NOT NULL DEFAULT '0' COMMENT '用户id',
25   `role_id` int(11) NOT NULL DEFAULT '0' COMMENT '角色ID',
26   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
27   PRIMARY KEY (`id`),
28   KEY `idx_uid` (`uid`)
29 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户角色表';
30 
31 CREATE TABLE `access` (
32   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
33   `title` varchar(50) NOT NULL DEFAULT '' COMMENT '权限名称',
34   `urls` varchar(1000) NOT NULL DEFAULT '' COMMENT 'json 数组',
35   `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1:有效 0:无效',
36   `updated_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '最后一次更新时间',
37   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
38   PRIMARY KEY (`id`)
39 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='权限详情表';
40 
41 CREATE TABLE `role_access` (
42   `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
43   `role_id` int(11) NOT NULL DEFAULT '0' COMMENT '角色id',
44   `access_id` int(11) NOT NULL DEFAULT '0' COMMENT '权限id',
45   `created_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '插入时间',
46   PRIMARY KEY (`id`),
47   KEY `idx_role_id` (`role_id`)
48 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色权限表';
49 
50 CREATE TABLE `app_access_log` (
51   `id` int(11) NOT NULL AUTO_INCREMENT,
52   `uid` bigint(20) NOT NULL DEFAULT '0' COMMENT '品牌UID',
53   `target_url` varchar(255) NOT NULL DEFAULT '' COMMENT '访问的url',
54   `query_params` longtext NOT NULL COMMENT 'get和post参数',
55   `ua` varchar(255) NOT NULL DEFAULT '' COMMENT '访问ua',
56   `ip` varchar(32) NOT NULL DEFAULT '' COMMENT '访问ip',
57   `note` varchar(1000) NOT NULL DEFAULT '' COMMENT 'json格式备注字段',
58   `created_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
59   PRIMARY KEY (`id`),
60   KEY `idx_uid` (`uid`)
61 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户操作记录表';
62 
63 
64 INSERT INTO `user` (`id`, `name`, `email`, `is_admin`, `status`, `updated_time`, `created_time`)
65 VALUES(1, '超级管理员', 'apanly@163.com', 1, 1, '2016-11-15 13:36:30', '2016-11-15 13:36:30');
复制代码

用户与角色关联起来,角色与权限关联起来,通过判断角色来管理权限(哪些页面不能访问)

 

判断权限逻辑:根据用户ID取出用户角色==》如果是超级管理员则不需要做权限判断,否则根据角色取出所属权限==》根据权限取出可访问链接列表==》判断当前操作是否在列表中==》无权限则返回提示页面;

 

本内容整理自慕课网视频教程——《RBAC打造通用web管理权限》

RBAC权限管理模型:基本模型及角色模型解析及举例

我们在做任何一款产品的时候,或多或少都会涉及到用户和权限的问题。譬如,做企业类软件,不同部门、不同职位的人的权限是不同的;做论坛类产品的时候,版主和访客权限也是不一样的;再例如一款产品的收费用户和免费用户权限也是迥然不同的。

但在设计产品的用户和权限的关系的时候,很多产品经理可能按照感觉来,在并不清楚用户和权限是否存在优秀的理论模型的时候,就按照自我推理搭建了产品的用户和权限模型。而这种基于感觉和推理的模型肯定是有诸多问题的,譬如写死了关系导致权限不够灵活、考虑不周导致权限覆盖能力弱等等。

正如牛顿所言,站在巨人的肩膀上才能看的更远。我们不妨去参照已有的比较成熟的权限模型,如:RBAC(Role-Based Access Control)——基于角色的访问控制。我搜集了网上很多关于RBAC的资料,大多与如何用数据表实现RBCA相关,并不容易理解。所以,我会以产品经理的角度去解析RBAC模型,并分别举例如何运用这套已得到验证的成熟模型。

一、RBAC模型是什么?

RBAC是一套成熟的权限模型。在传统权限模型中,我们直接把权限赋予用户。而在RBAC中,增加了“角色”的概念,我们首先把权限赋予角色,再把角色赋予用户。这样,由于增加了角色,授权会更加灵活方便。在RBAC中,根据权限的复杂程度,又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中,RBAC0是基础,RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度,选取适合的权限模型。

1

二、基本模型RBAC0

解析:

RBAC0是基础,很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中,我们把权限赋予角色,再把角色赋予用户。用户和角色,角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。

2

举例:

譬如我们做一款企业管理产品,如果按传统权限模型,给每一个用户赋予权限则会非常麻烦,并且做不到批量修改用户权限。这时候,可以抽象出几个角色,譬如销售经理、财务经理、市场经理等,然后把权限分配给这些角色,再把角色赋予用户。这样无论是分配权限还是以后的修改权限,只需要修改用户和角色的关系,或角色和权限的关系即可,更加灵活方便。此外,如果一个用户有多个角色,譬如王先生既负责销售部也负责市场部,那么可以给王先生赋予两个角色,即销售经理+市场经理,这样他就拥有这两个角色的所有权限。

三、角色分层模型RBAC1

解析:

RBAC1建立在RBAC0基础之上,在角色中引入了继承的概念。简单理解就是,给角色可以分成几个等级,每个等级权限不同,从而实现更细粒度的权限管理。

3

举例:

基于之前RBAC0的例子,我们又发现一个公司的销售经理可能是分几个等级的,譬如除了销售经理,还有销售副经理,而销售副经理只有销售经理的部分权限。这时候,我们就可以采用RBAC1的分级模型,把销售经理这个角色分成多个等级,给销售副经理赋予较低的等级即可。

四、角色限制模型RBAC2

解析:

RBAC2同样建立在RBAC0基础之上,仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类,即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图:

4

举例:

还是基于之前RBAC0的例子,我们又发现有些角色之间是需要互斥的,譬如给一个用户分配了销售经理的角色,就不能给他再赋予财务经理的角色了,否则他即可以录入合同又能自己审核合同;再譬如,有些公司对角色的升级十分看重,一个销售员要想升级到销售经理,必须先升级到销售主管,这时候就要采用先决条件限制了。

五、统一模型RBAC3

解析:

RBAC3是RBAC1和RBAC2的合集,所以RBAC3既有角色分层,也包括可以增加各种限制。

5

举例:

这个就不举例了,统一模型RBAC3可以解决上面三个例子的所有问题。当然,只有在系统对权限要求非常复杂时,才考虑使用此权限模型。

六、基于RBAC的延展——用户组

解析:

基于RBAC模型,还可以适当延展,使其更适合我们的产品。譬如增加用户组概念,直接给用户组分配角色,再把用户加入用户组。这样用户除了拥有自身的权限外,还拥有了所属用户组的所有权限。

6

举例:

譬如,我们可以把一个部门看成一个用户组,如销售部,财务部,再给这个部门直接赋予角色,使部门拥有部门权限,这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权,且不影响用户本来就拥有的角色权限。

七、最后的话

无论是本次的权限模型,还是其他产品相关实现方案,很多都已经被前人所总结提炼,我们应深度掌握这些成熟的知识和经验,而不是绞尽脑汁自我推理。还是文章开头那句话,站在巨人的肩膀上我们可以看得更远,而不是再造一个轮子。

RBAC权限管理

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。(如下图)

角色是什么?可以理解为一定数量的权限的集合,权限的载体。例如:一个论坛系统,“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等,这些是权限。要给某个用户授予这些权限,不需要直接将权限授予用户,可将“版主”这个角色赋予该用户。

 

当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有多个用户。除了可给用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)

在应用系统中,权限表现成什么?对功能模块的操作,对上传文件的删改,菜单的访问,甚至页面上某个按钮、某个图片的可见性控制,都可属于权限的范畴。有些权限设计,会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类,这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时,可把功能操作和资源统一管理,也就是都直接与权限表进行关联,这样可能更具便捷性和易扩展性。(见下图)


请留意权限表中有一列“权限类型”,我们根据它的取值来区分是哪一类权限,如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。

 

这样设计的好处有二。其一,不需要区分哪些是权限操作,哪些是资源,(实际上,有时候也不好区分,如菜单,把它理解为资源呢还是功能模块权限呢?)。其二,方便扩展,当系统要对新的东西进行权限控制时,我只需要建立一个新的关联表“权限XX关联表”,并确定这类权限的权限类型字符串。

 

这里要注意的是,权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。(文件、页面权限点、功能操作等同理)。也就是每添加一个菜单,就得同时往这三个表中各插入一条记录。这样,可以不需要权限菜单关联表,让权限表与菜单表直接关联,此时,须在权限表中新增一列用来保存菜单的ID,权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

 

到这里,RBAC权限模型的扩展模型的完整设计图如下:


随着系统的日益庞大,为了方便管理,可引入角色组对角色进行分类管理,跟用户组不同,角色组不参与授权。例如:某电网系统的权限管理模块中,角色就是挂在区局下,而区局在这里可当作角色组,它不参于权限分配。另外,为方便上面各主表自身的管理与查找,可采用树型结构,如菜单树、功能树等,当然这些可不需要参于权限分配。

Nginx内置变量以及日志格式变量参数详解

Nginx内置变量以及日志格式变量参数详解

$args                    #请求中的参数值
$query_string            #同 $args
$arg_NAME                #GET请求中NAME的值
$is_args                 #如果请求中有参数,值为"?",否则为空字符串
$uri                     #请求中的当前URI(不带请求参数,参数位于$args),可以不同于浏览器传递的$request_uri的值,它可以通过内部重定向,或者使用index指令进行修改,$uri不包含主机名,如"/foo/bar.html"。
$document_uri            #同 $uri
$document_root           #当前请求的文档根目录或别名
$host                    #优先级:HTTP请求行的主机名>"HOST"请求头字段>符合请求的服务器名.请求中的主机头字段,如果请求中的主机头不可用,则为服务器处理请求的服务器名称
$hostname                #主机名
$https                   #如果开启了SSL安全模式,值为"on",否则为空字符串。
$binary_remote_addr      #客户端地址的二进制形式,固定长度为4个字节
$body_bytes_sent         #传输给客户端的字节数,响应头不计算在内;这个变量和Apache的mod_log_config模块中的"%B"参数保持兼容
$bytes_sent              #传输给客户端的字节数
$connection              #TCP连接的序列号
$connection_requests     #TCP连接当前的请求数量
$content_length          #"Content-Length" 请求头字段
$content_type            #"Content-Type" 请求头字段
$cookie_name             #cookie名称
$limit_rate              #用于设置响应的速度限制
$msec                    #当前的Unix时间戳
$nginx_version           #nginx版本
$pid                     #工作进程的PID
$pipe                    #如果请求来自管道通信,值为"p",否则为"."
$proxy_protocol_addr     #获取代理访问服务器的客户端地址,如果是直接访问,该值为空字符串
$realpath_root           #当前请求的文档根目录或别名的真实路径,会将所有符号连接转换为真实路径
$remote_addr             #客户端地址
$remote_port             #客户端端口
$remote_user             #用于HTTP基础认证服务的用户名
$request                 #代表客户端的请求地址
$request_body            #客户端的请求主体:此变量可在location中使用,将请求主体通过proxy_pass,fastcgi_pass,uwsgi_pass和scgi_pass传递给下一级的代理服务器
$request_body_file       #将客户端请求主体保存在临时文件中。文件处理结束后,此文件需删除。如果需要之一开启此功能,需要设置client_body_in_file_only。如果将次文件传 递给后端的代理服务器,需要禁用request body,即设置proxy_pass_request_body off,fastcgi_pass_request_body off,uwsgi_pass_request_body off,or scgi_pass_request_body off
$request_completion      #如果请求成功,值为"OK",如果请求未完成或者请求不是一个范围请求的最后一部分,则为空
$request_filename        #当前连接请求的文件路径,由root或alias指令与URI请求生成
$request_length          #请求的长度 (包括请求的地址,http请求头和请求主体)
$request_method          #HTTP请求方法,通常为"GET"或"POST"
$request_time            #处理客户端请求使用的时间,单位为秒,精度毫秒; 从读入客户端的第一个字节开始,直到把最后一个字符发送给客户端后进行日志写入为止。
$request_uri             #这个变量等于包含一些客户端请求参数的原始URI,它无法修改,请查看$uri更改或重写URI,不包含主机名,例如:"/cnphp/test.php?arg=freemouse"
$scheme                  #请求使用的Web协议,"http" 或 "https"
$server_addr             #服务器端地址,需要注意的是:为了避免访问linux系统内核,应将ip地址提前设置在配置文件中
$server_name             #服务器名
$server_port             #服务器端口
$server_protocol         #服务器的HTTP版本,通常为 "HTTP/1.0" 或 "HTTP/1.1"
$status                  #HTTP响应代码
$time_iso8601            #服务器时间的ISO 8610格式
$time_local              #服务器时间(LOG Format 格式)
$cookie_NAME             #客户端请求Header头中的cookie变量,前缀"$cookie_"加上cookie名称的变量,该变量的值即为cookie名称的值
$http_NAME               #匹配任意请求头字段;变量名中的后半部分NAME可以替换成任意请求头字段,如在配置文件中需要获取http请求头:"Accept-Language",$http_accept_language即可
$http_cookie
$http_host               #请求地址,即浏览器中你输入的地址(IP或域名)
$http_referer            #url跳转来源,用来记录从那个页面链接访问过来的
$http_user_agent         #用户终端浏览器等信息
$http_x_forwarded_for
$sent_http_NAME          #可以设置任意http响应头字段;变量名中的后半部分NAME可以替换成任意响应头字段,如需要设置响应头Content-length,$sent_http_content_length即可
$sent_http_cache_control
$sent_http_connection
$sent_http_content_type
$sent_http_keep_alive
$sent_http_last_modified
$sent_http_location
$sent_http_transfer_encoding

log_format有一个默认的、无须设置的combined日志格式设置,相当于Apache的combined日志格式,其具体参数如下:

log_format combined  ‘$remote_addr-$remote_user [$time_local]’

‘ “$request” $status $body_bytes_sent’

‘ “$http_referer” “$http_user_agent” ‘;

 

我现在使用的日志格式:

log_format access  ‘$http_x_forwarded_for $remote_addr [$time_local] “http://$host” “$request” ‘
‘$status $body_bytes_sent “$http_referer” “$http_user_agent” “$remote_user” ‘;

当日志文件中记录的值为”“时,表示为空

access为自定义的日志格式的名称,使用时引用即可:

access_log  /data/logs/nginx/ihouse_access.log access;

——————————————————————————————————

正确设置nginx中remote_addr和x_forwarded_for参数

什么是remote_addr:

remote_addr代表客户端的IP,但它的值不是由客户端提供的,而是服务端根据客户端的ip指定的,当你的浏览器访问某个网站时,假设中间没有任何代理,那么网站的web服务器(Nginx,Apache等)就会把remote_addr设为你的机器IP,如果你用了某个代理,那么你的浏览器会先访问这个代理,然后再由这个代理转发到网站,这样web服务器就会把remote_addr设为这台代理机器的IP

什么是x_forwarded_for:

正如上面所述,当你使用了代理时,web服务器就不知道你的真实IP了,为了避免这个情况,代理服务器通常会增加一个叫做x_forwarded_for的头信息,把连接它的客户端IP(即你的上网机器IP)加到这个头信息里,这样就能保证网站的web服务器能获取到真实IP

使用HAProxy做反向代理时

通常网站为了支撑更大的访问量,会增加很多web服务器,并在这些服务器前面增加一个反向代理(如HAProxy),它可以把负载均匀的分布到这些机器上。你的浏览器访问的首先是这台反向代理,它再把你的请求转发到后面的web服务器,这就使得web服务器会把remote_addr设为这台反向代理的IP,为了能让你的程序获取到真实的客户端IP,你需要给HAProxy增加以下配置

   option forwardfor

它的作用就像上面说的,增加一个x_forwarded_for的头信息,把客户端的ip添加进去,否则的话经测试为空值

如上面的日志格式所示:$http_x_forwarded_for 是客户端真实的IP地址,$remote_addr是前端Haproxy的IP地址

或者:

当Nginx处在HAProxy后面时,就会把remote_addr设为HAProxy的IP,这个值其实是毫无意义的,你可以通过nginx的realip模块,让它使用x_forwarded_for里的值。使用这个模块需要重新编译Nginx,增加--with-http_realip_module参数

./configure  –user=www –group=www –prefix=/usr/local/nginx –with-http_stub_status_module –with-http_ssl_module \                                                              –with-http_realip_module –http-log-path=/data/logs/nginx/access.log –error-log-path=/data/logs/nginx/error.log

     set_real_ip_from 10.1.10.0/24;

     real_ip_header X-Forwarded-For;

上面的两行配置就是把从10.1.10这一网段过来的请求全部使用X-Forwarded-For里的头信息作为remote_addr,这样此时remote_addr就是客户端真实的IP地址

————————————————————–

X-Forwarded-For 和 X-Real-IP 获取客户端的ip的区别:

一般来说,X-Forwarded-For是用于记录代理信息的,每经过一级代理(匿名代理除外),代理服务器都会把这次请求的来源IP追加在X-Forwarded-For中 来自4.4.4.4的一个请求,header包含这样一行 X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3 代表 请求由1.1.1.1发出,经过三层代理,第一层是2.2.2.2,第二层是3.3.3.3,而本次请求的来源IP 4.4.4.4是第三层代理 而X-Real-IP,一般记录真实发出请求的客户端IP,上面的例子,如果配置了X-Read-IP,将会是 X-Real-IP: 1.1.1.1 所以 ,如果只有一层代理,这两个头的值就是一样的

 

 

 

所有相关变量具体请详看官网:

http://nginx.org/en/docs/varindex.html

http://blog.csdn.net/njxdy/article/details/9998481

PHP超时处理全面总结

概述

在PHP开发中工作里非常多使用到超时处理到超时的场合,我说几个场景:

  1. 异步获取数据如果某个后端数据源获取不成功则跳过,不影响整个页面展现
  2. 为了保证Web服务器不会因为当个页面处理性能差而导致无法访问其他页面,则会对某些页面操作设置
  3. 对于某些上传或者不确定处理时间的场合,则需要对整个流程中所有超时设置为无限,否则任何一个环节设置不当,都会导致莫名执行中断
  4. 多个后端模块(MySQL、Memcached、HTTP接口),为了防止单个接口性能太差,导致整个前面获取数据太缓慢,影响页面打开速度,引起雪崩
  5. 。。。很多需要超时的场合

这些地方都需要考虑超时的设定,但是PHP中的超时都是分门别类,各个处理方式和策略都不同,为了系统的描述,我总结了PHP中常用的超时处理的总结。

Web服务器超时处理

Apache

一般在性能很高的情况下,缺省所有超时配置都是30秒,但是在上传文件,或者网络速度很慢的情况下,那么可能触发超时操作。

目前apachefastcgiphp-fpm模式下有三个超时设置:

fastcgi超时设置:

修改httpd.conf的fastcgi连接配置,类似如下:

<IfModulemod_fastcgi.c>FastCgiExternalServer/home/forum/apache/apache_php/cgi-bin/php-cgi-socket/home/forum/php5/etc/php-fpm.sock
ScriptAlias/fcgi-bin//home/forum/apache/apache_php/cgi-bin/”

AddHandlerphp-fastcgi.php

Actionphp-fastcgi/fcgi-bin/php-cgi

AddTypeapplication/x-httpd-php.php

</IfModule>

缺省配置是30s,如果需要定制自己的配置,需要修改配置,比如修改为100秒:(修改后重启apache):

<IfModulemod_fastcgi.c>
FastCgiExternalServer/home/forum/apache/apache_php/cgi-bin/php-cgi-socket/home/forum/php5/etc/php-fpm.sock-idle-timeout100

ScriptAlias/fcgi-bin//home/forum/apache/apache_php/cgi-bin/”

AddHandlerphp-fastcgi.php

Actionphp-fastcgi/fcgi-bin/php-cgi

AddTypeapplication/x-httpd-php.php

</IfModule>

如果超时会返回500错误,断开跟后端php服务的连接,同时记录一条apache错误日志:

[ThuJan2718:30:152011][error][client10.81.41.110]FastCGI:commwithserver”/home/forum/apache/apache_php/cgi-bin/php-cgi”aborted:idletimeout(30sec)

[ThuJan2718:30:152011][error][client10.81.41.110]FastCGI:incompleteheaders(0bytes)receivedfromserver”/home/forum/apache/apache_php/cgi-bin/php-cgi”

其他fastcgi配置参数说明:

IdleTimeout发呆时限ProcessLifeTime一个进程的最长生命周期,过期之后无条件kill
MaxProcessCount最大进程个数
DefaultMinClassProcessCount每个程序启动的最小进程个数
DefaultMaxClassProcessCount每个程序启动的最大进程个数
IPCConnectTimeout程序响应超时时间
IPCCommTimeout与程序通讯的最长时间,上面的错误有可能就是这个值设置过小造成的
MaxRequestsPerProcess每个进程最多完成处理个数,达成后自杀

Lighttpd

配置:lighttpd.conf

Lighttpd配置中,关于超时的参数有如下几个(篇幅考虑,只写读超时,写超时参数同理):

主要涉及选项:

server.max-keep-alive-idle=5
server.max-read-idle=60
server.read-timeout=0
server.max-connection-idle=360

————————————————–

#每次keep-alive的最大请求数,默认值是16

server.max-keep-alive-requests=100

#keep-alive的最长等待时间,单位是秒,默认值是5

server.max-keep-alive-idle=1200

#lighttpd的work子进程数,默认值是0,单进程运行

server.max-worker=2

#限制用户在发送请求的过程中,最大的中间停顿时间(单位是秒),

#如果用户在发送请求的过程中(没发完请求),中间停顿的时间太长,lighttpd会主动断开连接

#默认值是60(秒)

server.max-read-idle=1200

#限制用户在接收应答的过程中,最大的中间停顿时间(单位是秒),

#如果用户在接收应答的过程中(没接完),中间停顿的时间太长,lighttpd会主动断开连接

#默认值是360(秒)

server.max-write-idle=12000

#读客户端请求的超时限制,单位是秒,配为0表示不作限制

#设置小于max-read-idle时,read-timeout生效

server.read-timeout=0

#写应答页面给客户端的超时限制,单位是秒,配为0表示不作限制

#设置小于max-write-idle时,write-timeout生效

server.write-timeout=0

#请求的处理时间上限,如果用了mod_proxy_core,那就是和后端的交互时间限制,单位是秒

server.max-connection-idle=1200

————————————————–

说明:

对于一个keep-alive连接上的连续请求,发送第一个请求内容的最大间隔由参数max-read-idle决定,从第二个请求起,发送请求内容的最大间隔由参数max-keep-alive-idle决定。请求间的间隔超时也由max-keep-alive-idle决定。发送请求内容的总时间超时由参数read-timeout决定。Lighttpd与后端交互数据的超时由max-connection-idle决定。

延伸阅读:

http://www.snooda.com/read/244

Nginx

配置:nginx.conf

http{
#Fastcgi:(针对后端的fastcgi生效,fastcgi不属于proxy模式)

fastcgi_connect_timeout5;#连接超时

fastcgi_send_timeout10; #写超时

fastcgi_read_timeout10;#读取超时

#Proxy:(针对proxy/upstreams的生效)

proxy_connect_timeout15s;#连接超时

proxy_read_timeout24s;#读超时

proxy_send_timeout10s; #写超时

}

说明:

Nginx 的超时设置倒是非常清晰容易理解,上面超时针对不同工作模式,但是因为超时带来的问题是非常多的。

延伸阅读:

http://hi.baidu.com/pibuchou/blog/item/a1e330dd71fb8a5995ee3753.html
http://hi.baidu.com/pibuchou/blog/item/7cbccff0a3b77dc60b46e024.html
http://hi.baidu.com/pibuchou/blog/item/10a549818f7e4c9df703a626.html
http://www.apoyl.com/?p=466

PHP本身超时处理

PHP-fpm

配置:php-fpm.conf

<?xmlversion=”1.0″?>
<configuration>

//…

Setsthelimitonthenumberofsimultaneousrequeststhatwillbeserved.

EquivalenttoApacheMaxClientsdirective.

EquivalenttoPHP_FCGI_CHILDRENenvironmentinoriginalphp.fcgi

Usedwithanypm_style.

#php-cgi的进程数量

<valuename=”max_children”>128</value>

Thetimeout(inseconds)forservingasinglerequestafterwhichtheworkerprocesswillbeterminated

Shouldbeusedwhen’max_execution_time’inioptiondoesnotstopscriptexecutionforsomereason

’0s’means’off’

#php-fpm 请求执行超时时间,0s为永不超时,否则设置一个 Ns 为超时的秒数

<valuename=”request_terminate_timeout”>0s</value>

Thetimeout(inseconds)forservingofsinglerequestafterwhichaphpbacktracewillbedumpedtoslow.logfile

’0s’means’off’

<valuename=”request_slowlog_timeout”>0s</value>

</configuration>

说明:

在php.ini中,有一个参数max_execution_time可以设置PHP脚本的最大执行时间,但是,在php-cgi(php-fpm)中,该参数不会起效。真正能够控制PHP脚本最大执行时:

<valuename=”request_terminate_timeout”>0s</value>

就是说如果是使用mod_php5.so的模式运行max_execution_time是会生效的,但是如果是php-fpm模式中运行时不生效的。

延伸阅读:

http://blog.s135.com/file_get_contents/

PHP

配置:php.ini

选项:

max_execution_time=30

或者在代码里设置:

ini_set(“max_execution_time”,30);

set_time_limit(30);

说明:

对当前会话生效,比如设置0一直不超时,但是如果php的safe_mode打开了,这些设置都会不生效。

效果一样,但是具体内容需要参考php-fpm部分内容,如果php-fpm中设置了request_terminate_timeout的话,那么max_execution_time就不生效。

后端&接口访问超时

HTTP访问

一般我们访问HTTP方式很多,主要是:curl,socket,file_get_contents()等方法。

如果碰到对方服务器一直没有响应的时候,我们就悲剧了,很容易把整个服务器搞死,所以在访问http的时候也需要考虑超时的问题。

CURL 访问HTTP

CURL 是我们常用的一种比较靠谱的访问HTTP协议接口的lib库,性能高,还有一些并发支持的功能等。

CURL:

curl_setopt($ch,opt)可以设置一些超时的设置,主要包括:

*(重要)CURLOPT_TIMEOUT设置cURL允许执行的最长秒数。

*(重要)CURLOPT_TIMEOUT_MS设置cURL允许执行的最长毫秒数。(在cURL7.16.2中被加入。从PHP5.2.3起可使用。)

CURLOPT_CONNECTTIMEOUT在发起连接前等待的时间,如果设置为0,则无限等待。

CURLOPT_CONNECTTIMEOUT_MS尝试连接等待的时间,以毫秒为单位。如果设置为0,则无限等待。在cURL7.16.2中被加入。从PHP5.2.3开始可用。

CURLOPT_DNS_CACHE_TIMEOUT设置在内存中保存DNS信息的时间,默认为120秒。

curl普通秒级超时:

$ch=curl_init();

curl_setopt($ch,CURLOPT_URL,$url);

curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);

curl_setopt($ch,CURLOPT_TIMEOUT,60);//只需要设置一个秒的数量就可以

curl_setopt($ch,CURLOPT_HTTPHEADER,$headers);

curl_setopt($ch,CURLOPT_USERAGENT,$defined_vars['HTTP_USER_AGENT']);

curl普通秒级超时使用:

curl_setopt($ch,CURLOPT_TIMEOUT,60);

curl如果需要进行毫秒超时,需要增加:

curl_easy_setopt(curl,CURLOPT_NOSIGNAL,1L);

或者是:

curl_setopt($ch,CURLOPT_NOSIGNAL,true);是可以支持毫秒级别超时设置的

curl一个毫秒级超时的例子:

<?php
if(!isset($_GET['foo'])){

//Client

$ch=curl_init(‘http://example.com/’);

curl_setopt($ch,CURLOPT_RETURNTRANSFER,true);

curl_setopt($ch,CURLOPT_NOSIGNAL,1);//注意,毫秒超时一定要设置这个

curl_setopt($ch,CURLOPT_TIMEOUT_MS,200);//超时毫秒,cURL7.16.2中被加入。从PHP5.2.3起可使用

$data=curl_exec($ch);

$curl_errno=curl_errno($ch);

$curl_error=curl_error($ch);

curl_close($ch);

if($curl_errno>0){

echo”cURLError($curl_errno):$curl_errorn”;

}else{

echo”Datareceived:$datan”;

}

}else{

//Server

sleep(10);

echo”Done.”;

}

?>

其他一些技巧:

  1. 按照经验总结是:cURL版本>=libcurl/7.21.0版本,毫秒级超时是一定生效的,切记。
  2. curl_multi的毫秒级超时也有问题。。单次访问是支持ms级超时的,curl_multi并行调多个会不准

流处理方式访问HTTP

除了curl,我们还经常自己使用fsockopen、或者是file操作函数来进行HTTP协议的处理,所以,我们对这块的超时处理也是必须的。

一般连接超时可以直接设置,但是流读取超时需要单独处理。

自己写代码处理:

$tmCurrent=gettimeofday();

$intUSGone=($tmCurrent['sec']-$tmStart['sec'])*1000000

+($tmCurrent['usec']-$tmStart['usec']);

if($intUSGone>$this->_intReadTimeoutUS){

returnfalse;

}

或者使用内置流处理函数stream_set_timeout()和stream_get_meta_data()处理:

<?php//Timeoutinseconds
$timeout=5;

$fp=fsockopen(“example.com”,80,$errno,$errstr,$timeout);

if($fp){

fwrite($fp,”GET/HTTP/1.0rn”);

fwrite($fp,”Host:example.comrn”);

fwrite($fp,”Connection:Closernrn”);

stream_set_blocking($fp,true);//重要,设置为非阻塞模式

stream_set_timeout($fp,$timeout);//设置超时

$info=stream_get_meta_data($fp);

while((!feof($fp))&&(!$info['timed_out'])){

$data.=fgets($fp,4096);

$info=stream_get_meta_data($fp);

ob_flush;

flush();

}

if($info['timed_out']){

echo”ConnectionTimedOut!”;

}else{

echo$data;

}

}

file_get_contents超时:

<?php$timeout=array(
‘http’=>array(

‘timeout’=>5//设置一个超时时间,单位为秒

)

);

$ctx=stream_context_create($timeout);

$text=file_get_contents(“http://example.com/”,0,$ctx);

?>

fopen超时:

<?php$timeout=array(
‘http’=>array(

‘timeout’=>5//设置一个超时时间,单位为秒

)

);

$ctx=stream_context_create($timeout);

if($fp=fopen(“http://example.com/”,”r”,false,$ctx)){

while($c=fread($fp,8192)){

echo$c;

}

fclose($fp);

}

?>

MySQL

php中的mysql客户端都没有设置超时的选项,mysqli和mysql都没有,但是libmysql是提供超时选项的,只是我们在php中隐藏了而已。

那么如何在PHP中使用这个操作捏,就需要我们自己定义一些MySQL操作常量,主要涉及的常量有:

MYSQL_OPT_READ_TIMEOUT=11;

MYSQL_OPT_WRITE_TIMEOUT=12;

这两个,定义以后,可以使用options设置相应的值。

不过有个注意点,mysql内部实现:

  1. 超时设置单位为秒,最少配置1秒
  2. 但mysql底层的read会重试两次,所以实际会是3秒

重试两次+ 自身一次=3倍超时时间,那么就是说最少超时时间是3秒,不会低于这个值,对于大部分应用来说可以接受,但是对于小部分应用需要优化。

查看一个设置访问mysql超时的php实例:

<?php//自己定义读写超时常量
if(!defined(‘MYSQL_OPT_READ_TIMEOUT’)){

define(‘MYSQL_OPT_READ_TIMEOUT’,11);

}

if(!defined(‘MYSQL_OPT_WRITE_TIMEOUT’)){

define(‘MYSQL_OPT_WRITE_TIMEOUT’,12);

}

//设置超时

$mysqli=mysqli_init();

$mysqli->options(MYSQL_OPT_READ_TIMEOUT,3);

$mysqli->options(MYSQL_OPT_WRITE_TIMEOUT,1);

//连接数据库

$mysqli->real_connect(“localhost”,”root”,”root”,”test”);

if(mysqli_connect_errno()){

printf(“Connectfailed:%s/n”,mysqli_connect_error());

exit();

}

//执行查询sleep1秒不超时

printf(“Hostinformation:%s/n”,$mysqli->host_info);

if(!($res=$mysqli->query(‘selectsleep(1)’))){

echo”query1error:”.$mysqli->error.”/n”;

}else{

echo”Query1:querysuccess/n”;

}

//执行查询sleep9秒会超时

if(!($res=$mysqli->query(‘selectsleep(9)’))){

echo”query2error:”.$mysqli->error.”/n”;

}else{

echo”Query2:querysuccess/n”;

}

$mysqli->close();

echo”closemysqlconnection/n”;

?>

延伸阅读:

http://blog.csdn.net/heiyeshuwu/article/details/5869813

Memcached

PHP扩展

php_memcache客户端:

连接超时:boolMemcache::connect(string$host[,int$port[,int$timeout]])

在get和set的时候,都没有明确的超时设置参数。

libmemcached客户端:在php接口没有明显的超时参数。

说明:所以说,在PHP中访问Memcached是存在很多问题的,需要自己hack部分操作,或者是参考网上补丁。

C&C++访问Memcached

客户端:libmemcached客户端

说明:memcache超时配置可以配置小点,比如5,10个毫秒已经够用了,超过这个时间还不如从数据库查询。

下面是一个连接和读取set数据的超时的C++示例:

//创建连接超时(连接到Memcached)
memcached_st*MemCacheProxy::_create_handle()

{

memcached_st*mmc=NULL;

memcached_return_tprc;

if(_mpool!=NULL){//getfrompool

mmc=memcached_pool_pop(_mpool,false,&prc);

if(mmc==NULL){

__LOG_WARNING__(“MemCacheProxy”,”gethandlefrompoolerror[%d]“,(int)prc);

}

returnmmc;

}

memcached_st*handle=memcached_create(NULL);

if(handle==NULL){

__LOG_WARNING__(“MemCacheProxy”,”create_handleerror”);

returnNULL;

}

//设置连接/读取超时

memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_HASH,MEMCACHED_HASH_DEFAULT);

memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_NO_BLOCK,_noblock);//参数MEMCACHED_BEHAVIOR_NO_BLOCK为1使超时配置生效,不设置超时会不生效,关键时候会悲剧的,容易引起雪崩

memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_CONNECT_TIMEOUT,_connect_timeout);//连接超时

memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_RCV_TIMEOUT,_read_timeout);//读超时

memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_SND_TIMEOUT,_send_timeout);//写超时

memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_POLL_TIMEOUT,_poll_timeout);

//设置一致hash

//memcached_behavior_set_distribution(handle,MEMCACHED_DISTRIBUTION_CONSISTENT);

memcached_behavior_set(handle,MEMCACHED_BEHAVIOR_DISTRIBUTION,MEMCACHED_DISTRIBUTION_CONSISTENT);

memcached_returnrc;

for(uinti=0;i<_server_count;i++){

rc=memcached_server_add(handle,_ips[i],_ports[i]);

if(MEMCACHED_SUCCESS!=rc){

__LOG_WARNING__(“MemCacheProxy”,”addserver[%s:%d]failed.”,_ips[i],_ports[i]);

}

}

_mpool=memcached_pool_create(handle,_min_connect,_max_connect);

if(_mpool==NULL){

__LOG_WARNING__(“MemCacheProxy”,”create_poolerror”);

returnNULL;

}

mmc=memcached_pool_pop(_mpool,false,&prc);

if(mmc==NULL){

__LOG_WARNING__(“MyMemCacheProxy”,”gethandlefrompoolerror[%d]“,(int)prc);

}

//__LOG_DEBUG__(“MemCacheProxy”,”gethandle[%p]“,handle);

returnmmc;

}

//设置一个key超时(set一个数据到memcached)

boolMemCacheProxy::_add(memcached_st*handle,unsignedint*key,constchar*value,intlen,unsignedinttimeout)

{

memcached_returnrc;

chartmp[1024];

snprintf(tmp,sizeof(tmp),”%u#%u”,key[0],key[1]);

//有个timeout值

rc=memcached_set(handle,tmp,strlen(tmp),(char*)value,len,timeout,0);

if(MEMCACHED_SUCCESS!=rc){

returnfalse;

}

returntrue;

}

//Memcache读取数据超时(没有设置)

libmemcahed源码中接口定义:

LIBMEMCACHED_APIchar*memcached_get(memcached_st*ptr,constchar*key,size_tkey_length,size_t*value_length,uint32_t*flags,memcached_return_t*error);

LIBMEMCACHED_APImemcached_return_tmemcached_mget(memcached_st*ptr,constchar*const*keys,constsize_t*key_length,size_tnumber_of_keys);

从接口中可以看出在读取数据的时候,是没有超时设置的。

延伸阅读:

http://hi.baidu.com/chinauser/item/b30af90b23335dde73e67608
http://libmemcached.org/libMemcached.html

如何实现超时

程序中需要有超时这种功能,比如你单独访问一个后端Socket模块,Socket模块不属于我们上面描述的任何一种的时候,它的协议也是私有的,那么这个时候可能需要自己去实现一些超时处理策略,这个时候就需要一些处理代码了。

PHP中超时实现

一、初级:最简单的超时实现 (秒级超时)

思路很简单:链接一个后端,然后设置为非阻塞模式,如果没有连接上就一直循环,判断当前时间和超时时间之间的差异。

phpsocket中实现原始的超时:(每次循环都当前时间去减,性能会很差,cpu占用会较高)

<?$host=”127.0.0.1″;
$port=”80″;

$timeout=15;//timeoutinseconds

$socket=socket_create(AF_INET,SOCK_STREAM,SOL_TCP)

ordie(“Unabletocreatesocketn”);

socket_set_nonblock($socket) //务必设置为阻塞模式

ordie(“Unabletosetnonblockonsocketn”);

$time=time();

//循环的时候每次都减去相应值

while(!@socket_connect($socket,$host,$port))//如果没有连接上就一直死循环

{

$err=socket_last_error($socket);

if($err==115||$err==114)

{

if((time()-$time)>=$timeout)//每次都需要去判断一下是否超时了

{

socket_close($socket);

die(“Connectiontimedout.n”);

}

sleep(1);

continue;

}

die(socket_strerror($err).”n”);

}

socket_set_block($this->socket)//还原阻塞模式

ordie(“Unabletosetblockonsocketn”);

?>

二、升级:使用PHP自带异步IO去实现(毫秒级超时)

说明:

异步IO:异步IO的概念和同步IO相对。当一个异步过程调用发出后,调用者不能立刻得到结果。实际处理这个调用的部件在完成后,通过状态、通知和回调来通知调用者。异步IO将比特分成小组进行传送,小组可以是8位的1个字符或更长。发送方可以在任何时刻发送这些比特组,而接收方从不知道它们会在什么时候到达。

多路复用:复用模型是对多个IO操作进行检测,返回可操作集合,这样就可以对其进行操作了。这样就避免了阻塞IO不能随时处理各个IO和非阻塞占用系统资源的确定。

使用socket_select()实现超时

socket_select(…,floor($timeout),ceil($timeout*1000000));

select的特点:能够设置到微秒级别的超时!

使用socket_select()的超时代码(需要了解一些异步IO编程的知识去理解)

编程 调用类 编程

<?php

$server=newServer;

$client=newClient;

for(;;){

foreach($select->can_read(0)as$socket){

if($socket==$client->socket){

//NewClientSocket

$select->add(socket_accept($client->socket));

}

else{

//there’ssomethingtoreadon$socket

}

}

}

?>

编程 异步多路复用IO & 超时连接处理类 编程

<?php

classselect{

var$sockets;

functionselect($sockets){

$this->sockets=array();

foreach($socketsas$socket){

$this->add($socket);

}

}

functionadd($add_socket){

array_push($this->sockets,$add_socket);

}

functionremove($remove_socket){

$sockets=array();

foreach($this->socketsas$socket){

if($remove_socket!=$socket)

$sockets[]=$socket;

}

$this->sockets=$sockets;

}

functioncan_read($timeout){

$read=$this->sockets;

socket_select($read,$write=NULL,$except=NULL,$timeout);

return$read;

}

functioncan_write($timeout){

$write=$this->sockets;

socket_select($read=NULL,$write,$except=NULL,$timeout);

return$write;

}

}

?>

C&C++中超时实现

一般在LinuxC/C++中,可以使用:alarm()设置定时器的方式实现秒级超时,或者:select()、poll()、epoll()之类的异步复用IO实现毫秒级超时。也可以使用二次封装的异步io库(libevent,libev)也能实现。

一、使用alarm中用信号实现超时 (秒级超时)

说明:Linux内核connect超时通常为75秒,我们可以设置更小的时间如10秒来提前从connect中返回。这里用使用信号处理机制,调用alarm,超时后产生SIGALRM信号(也可使用select实现)

用alarym秒级实现 connect设置超时代码示例:

//信号处理函数staticvoidconnect_alarm(intsigno)
{

debug_printf(“SignalHandler”);

return;

}

//alarm超时连接实现

staticvoidconn_alarm()

{

Sigfunc*sigfunc;//现有信号处理函数

sigfunc=signal(SIGALRM,connect_alarm);//建立信号处理函数connect_alarm,(如果有)保存现有的信号处理函数

inttimeout=5;

//设置闹钟

if(alarm(timeout)!=0){

//…闹钟已经设置处理

}

//进行连接操作

if(connect(m_Socket,(structsockaddr*)&addr,sizeof(addr))<0){

if(errno==EINTR){//如果错误号设置为EINTR,说明超时中断了

debug_printf(“Timeout”);

浅析PAC,教你动手修改你的PAC文件及user-rule文件实现自动代理

Shadowsocks作为现在一种很流行的穿墙工具,以其轻量级、速度感人等优点深受广大网友热捧。与VP_N相比,他就像一把锋利的”瑞士军刀”,不用受制于“系统全局代理”模式的困扰,控制更加便捷,基于Socks5安全加密协议,防止GF*W通过分析流量特征从而干扰的问题。而又不像GoAgent这种集中式爬墙模式,一般不会出现全局封锁等现象。不管你是因为什么原因喜欢上Shadowsocks,我相信她一定有给你带来好的体验的方面。

在Shadowsocks里面,系统代理模式有两种,一种是“系统代理模式”,另一种是“PAC代理模式”,通常情况下我们会选择后者,今天这里给大家解析一下PAC模式的原理以及如何修改PAC文件、user-rule文件实现自动代理,希望大家可以通过本文更的“科学上网”。

什么是PAC

代理自动配置(英语:Proxy auto-config,简称PAC)是一种网页浏览器技术,用于定义浏览器该如何自动选择适当的代理服务器来访问一个网址。

一个PAC文件包含一个JavaScript形式的函数“FindProxyForURL(url, host)”。这个函数返回一个包含一个或多个访问规则的字符串。用户代理根据这些规则适用一个特定的代理其或者直接访问。当一个代理服务器无法响应的时候,多个访问规则提供了其他的后备访问方法。浏览器在访问其他页面以前,首先访问这个PAC文件。PAC文件中的URL可能是手工配置的,也可能是是通过网页的网络代理自发现协议(Web Proxy Autodiscovery Protocol)自动配置的。

上面是从维基百科摘录的关于PAC的解释,我做了一个简单的图片解释什么是PAC:

简单的讲,PAC就是一种配置,它能让你的浏览器智能判断哪些网站走代理,哪些不需要走代理。用过Shadowsocks的朋友应该会知道, shadowsocks.exe 同级目录下有一个 pac.txt 文件,这正是我们本文刚刚所说的pac配置文件。

打开 pac.txt 文件,可以看到如下内容

可以看到pac配置文件是用的JavaScript语法,里面有一个变量 rules ,是一个JSon数组格式的数据类型,数组里面存放的是各种URL的通配符,那么在pac模式下,如果当访问符合这个数组里面任意一个URL通配符的网址时,系统会走代理,反之直连。比如图中pac配置,如果访问 http://www.cloudflare.com/index.php 时,会走代理,而访问百度、新浪等国内网站则会选择直连方式。

PAC的优势

PAC自动代理属于智能判断模式,相比全局代理,它的优点有:

  1. 不影响国内网站的访问速度,防止无意义的绕路
  2. 节省Shadowsocks服务的流量,节省服务器资源
  3. 控制方便

PAC文件及user-rule文件的语法规则

那么,当一个网站被墙,如何添加到PAC里面让其能够正常访问呢?在Shadowsocks里面,可以有如下两个方式:

1. 添加到 pac.txt 文件中

编辑 pac.txt 文件,模仿里面的一些URL通配符,再添加一个,例如"||ip138.com", ,注意不要忘记了 , 半角逗号,那么意思就是所有 ip138.com域名下的网址都将走Shadowsocks代理,打开ip138可以看到IP已经变成Shadowsocks所用的国外代理了

2. 添加到 user-rule.txt 文件中

编辑 user-rule.txt 文件,这里和 pac.txt 文件语法不完全相同,user-rule文件中,每一行表示一个URL通配符,但是通配符语法类似。例如添加一行||ip138.com^ ,然后记得右键小飞机-PAC-从GFWList更新本地PAC,打开ip138可以看到IP已经变成Shadowsocks所用的国外代理了

注意末尾不要忘记 ^ 符号,意思是要么在这个符号的地方结束,要么后面跟着?,/等符号。

自定义代理规则的设置语法与GFWlist相同,语法规则如下:

  1. 通配符支持。比如 *.example.com/* 实际书写时可省略 * , 如.example.com/ , 和 *.example.com/* 效果一样
  2. 正则表达式支持。以 \ 开始和结束, 如 \[\w]+:\/\/example.com\
  3. 例外规则 @@ ,如 @@*.example.com/* 满足 @@ 后规则的地址不使用代理
  4. 匹配地址开始和结尾 | ,如 |http://example.com 、 example.com| 分别表示以 http://example.com 开始和以 example.com 结束的地址
  5. || 标记,如 ||example.com 则 http://example.com 、https://example.com 、 ftp://example.com 等地址均满足条件
  6. 注释 ! 。 如 !我是注释

更多user-rule.txt语法规则,可以参考AdBlockPlus过滤规则https://adblockplus.org/en/filter-cheatsheet

全球免费开放的电子图书馆

1.澳大利亚国立大学ANU电子出版库:http://dspace.anu.edu.au/

2.阿德雷德大学电子文本收藏中心,包括古典文学,哲学,科学和医学著作:http://ebooks.adelaide.edu.au/

3.澳大利亚数字化人文门户(澳大利亚人文学界的数字化资源门户) http://www.ehum.edu.au/

4.科廷大学技术文献库(科廷技术大学科研人员和研究生的科研成果)http://espace.library.curtin.edu.au/R

5.墨尔本大学电子出版物收藏网
http://www.lib.unimelb.edu.au/eprints/

6.昆士兰大学数字文库
http://espace.library.uq.edu.au/

7.SETIS悉尼大学学术电子文本及图像服务 http://setis.library.usyd.edu.au/

8.新西兰数字文献收集网
http://nzdl.sadl.uleth.ca/cgi-bin/library

9.古腾堡数字化图书馆
http://www.gutenberg.org/wiki/Main_Page

10.Infomotions 西方文学/哲学网 (包括自美国/英国的文学和西方哲学公开著作)
http://infomotions.com/

11.康奈尔大学Arxiv (收藏了物理,数学,非线性科学和计算机科学方面的数字化 “预印本” 出版物)
http://arxiv.org/

12.Bartleby.com (包含世界历史百科全书,以及哈佛经典著作,提供免费的电子文本)
http://www.bartleby.com/

13.Bibliomania (提供超过2000部免费电子文献,以及研究成果) http://www.bibliomania.com/

14.Cogprints(有各类心理学,神经科学,语言学,哲学,生物学,人类学和计算机科学电子文献, 部分区域需要注册)
http://cogprints.org/

15.印第安纳大学国际文献档案库(这是一个服务公众的全文数字图书馆,作者可以提交著作,并被连入参考文献)
http://dlc.dlib.indiana.edu/dlc/

16.DLESE地球系统教育数字图书馆( 涵盖了环境,地理,地质,海洋以及其他物理科学;空间科学与技术;教育方法和科学哲学内容) http://www.dlese.org/library/

17.Elfwood(拥有超过两万部文学和艺术作品,来自超过一千五百名幻想/科幻艺术家和作家)
http://www.elfwood.com/

18.Eserver.org(收藏了大量在线智慧文学和资源,由华盛顿大学创立)http://eserver.org/

19.IPL互联网公共图书馆 (密歇根大学信息学院的学习和教学环境) http://www.ipl.org/

20.库尔特·斯塔博的在线图书馆(收藏了古代和现代的大量生物学著作,其中很多珍本, 可在线阅读) http://www.zum.de/

21.麻省理工学院的开放文献网站 http://ocw.mit.edu/OcwWeb/web/home/home/index.htm

22.美国国家科学院在线数据据库
(超过3000部科学,工程和健康卫生方面的著作,可以在线阅读,这些文献代表了美国在这些领域的研究精华)
http://www.nap.edu/

23.Ndltd.org
(搜集了来自澳大利亚,加拿大,许多欧洲国家,香港,台湾和美国的论文)http://www.ndltd.org/

24.宾夕法尼亚大学网站
(有超过 16000 部在线电子书 ,值得一读) :http://digital.library.upenn.edu/books/

25.牛津大学档案馆
(建于1976年,这里有用于研究和教学的大量高品质文献 资料公共区域可以免费在线检索目录,下载):http://ota.ahds.ac.uk/

26.弗吉尼亚大学电子文献中心
(超过10000 部可以公开或取的著作(以及超过 164000 幅图像):http://www2.lib.virginia.edu/etext/index.html

27.Gallica.bnf.fr
(法兰西国家图书馆资助的网站,法文):http://gallica.bnf.fr/

28.世界图书馆(世界图书馆,法语) http://abu.cnam.fr/

29.意大利电子书网站(包括小说,诗歌,古典文学,戏剧,传记,恐怖和幻想小说,新经济学等)http://www.ebookgratis.it/

30.日本文学著作( 格式包括 HTML , ZIP(下载)和日文电子书格式)http://www.aozora.gr.jp/

31.今日美国开放图书计划
(一家报纸网站的独立部门,一些有名的小说家开放了他们的版权,供所有的访客阅)http://www.usatoday.com/life/books/openbooks/2005-02-01-abounding-gutter_x.htm

32.英语文学网站
(超过一千位学生为这个巨大的网站捐助成果,焦点是英语文学) http://www.litencyc.com/

33.计算机程序设计电子书
(包括:Abap, Java, Linux, Php, Oracle & Vb.net 。 PDF 格式。注意,在下载之前,需先建立一个账户)
http://www.downloadfreepdf.com/

34.数学世界
(为学生,教育家,数学爱好者和研究者准备的全面地数学百科全书)http://mathworld.wolfram.com/

35.在线医学百科全书
(超过1500主题的在线医学百科全书,包括康复,疾病,伤害,营养,手术,症状,试验)http://www.healthopedia.com/

36.医生的免费电子书(免费使用的医学电子书) http://freebooks4doctors.com/

37.奥地利文献
(超过12000 部奥地利文献,甚至包括明信片,可以在因特网上访问)http://www.literature.at/default.alo;jsessionid=453DD0DC127BBBB02C863B1887F76E28

38.GPO Access(美国政府文献):http://www.access.gpo.gov/

39.世界最大的社会科学文献网站(ICPSR)
(Inter-university Consortium for Political and Social Research):http://www.icpsr.umich.edu/icpsrweb/ICPSR/

40.National Academy Press
(美国国家科学院、国家工程院、医学协会等机构的论文/报告/PPT,内容几乎涵盖所有学科)
http://www.nationalacademies.org/publications/

41.UNESCO
(联合国教科文组织提供的文档,包含自然科学与社会科学,有多种语言,包括中文)
http://www.unesco.org/new/en/unesco/

后话:最后关于UNESCO的疏忽一直没有发现,很抱歉,现在已经补充,同时增添Alexa搜索中文官方网站的网址http://cn.alexa.com/
很有用的网站搜索,需要什么可以去那里搜索。

Redis应用场景

1.  MySql+Memcached架构的问题

Memcached采用客户端服务器的架构,客户端和服务器端的通讯使用自定义的协议标准,只要满足协议格式要求,客户端Library可以用任何语言实现。

Memcached服务器使用基于Slab的内存管理方式,有利于减少内存碎片和频繁分配销毁内存所带来的开销。各个Slab按需动态分配一个page的内存(和4Kpage的概念不同,这里默认page1M),page内部按照不同slab
class
的尺寸再划分为内存chunk供服务器存储KV键值对使用(slab机制相当于内存池机制,
实现从操作系统分配一大块
内存, 然后 memcached 自己管理这块内存, 负责分配与回收。)

关于memcached的内存分配机制:Memcached
内存分配机制介绍

      实际MySQL是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:

  1.MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间。

  2.Memcached与MySQL数据库数据一致性问题。

  3.Memcached数据命中率低或down机,大量访问直接穿透到DB,MySQL无法支撑。

  4.跨机房cache同步问题。

       关于memcached问题:Memcache存储大数据的问题

  众多NoSQL百花齐放,如何选择

  最近几年,业界不断涌现出很多各种各样的NoSQL产品,那么如何才能正确地使用好这些产品,最大化地发挥其长处,是我们需要深入研究和思考的问题,实际归根结底最重要的是了解这些产品的定位,并且了解到每款产品的tradeoffs,在实际应用中做到扬长避短,总体上这些NoSQL主要用于解决以下几种问题

  1.少量数据存储,高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问,同时提供数据落地的功能,实际这正是Redis最主要的适用场景。

  2.海量数据存储,分布式系统支持,数据一致性保证,方便的集群节点添加/删除。

  3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计,节点之间通过gossip方式传递集群信息,数据保证最终一致性,后者是一个中心化的方案设计,通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo
log,然后定期compat归并到磁盘上,将随机写优化为顺序写,提高写入性能。

  4.Schema free,auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的,直接存储json格式数据,并且支持auto-sharding等功能,比如mongodb。

  面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。

       Redis最适合所有数据in-momory的场景,虽然Redis也提供持久化功能,但实际更多的是一个disk-backed的功能,跟传统意义上的持久化有比较大的差别,那么可能大家就会有疑问,似乎Redis更像一个加强版的Memcached,那么何时使用Memcached,何时使用Redis呢?

 

memcache和redis的比较:

 

  • 性能方面:没有必要过多的关心性能,因为二者的性能都已经足够高了。由于Redis只使用单核,而Memcached可以使用多核,所以在比较上,平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起Memcached,还是稍有逊色。说了这么多,结论是,无论你使用哪一个,每秒处理请求的次数都不会成为瓶颈。(比如瓶颈可能会在网卡)
  • 内存使用效率:使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,由于其组合式的压缩,其内存利用率会高于Memcached。当然,这和你的应用场景和数据特性有关。
  • 数据持久化:如果你对数据持久化和数据同步有所要求,那么推荐你选择Redis,因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失,选择Redis也是明智的。
  • 数据结构:当然,最后还得说到你的具体应用需求。Redis相比Memcached来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在Memcached里,你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中,这些复杂的操作通常和一般的GET/SET一样高效。所以,如果你需要缓存能够支持更复杂的结构和操作,那么Redis会是不错的选择。
  • 网络IO模型方面:Memcached是多线程,分为监听线程、worker线程,引入锁,带来了性能损耗。Redis使用单线程的IO复用模型,将速度优势发挥到最大,也提供了较简单的计算功能 

  • 内存管理方面:Memcached使用预分配的内存池的方式,带来一定程度的空间浪费 并且在内存仍然有很大空间时,新的数据也可能会被剔除,而Redis使用现场申请内存的方式来存储数据,不会剔除任何非临时数据 Redis更适合作为存储而不是cache 

  • 数据的一致性方面:Memcached提供了cas命令来保证.而Redis提供了事务的功能,可以保证一串 命令的原子性,中间不会被任何操作打断 

 

    如果简单地比较Redis与Memcached的区别,大多数都会得到以下观点:

     1 、Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,zset,hash等数据结构的存储。

     2 、Redis支持数据的备份,即master-slave模式的数据备份。

     3 、Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。

     4、Redis可以实现主从复制,实现故障恢复。

     5、Redis的Sharding技术: 很容易将数据分布到多个Redis实例中

 

 

2.  Redis常用数据类型

Redis最为常用的数据类型主要有以下:

  • String
  • Hash
  • List
  • Set
  • Sorted set
  • pub/sub
  • Transactions

在具体描述这几种数据类型之前,我们先通过一张图了解下Redis内部内存管理中是如何描述这些不同数据类型的:

         首先Redis内部使用一个redisObject对象来表示所有的key和value,redisObject最主要的信息如上图所示:

type代表一个value对象具体是何种数据类型,

encoding是不同数据类型在redis内部的存储方式,

比如:type=string代表value存储的是一个普通字符串,那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的,当然前提是这个字符串本身可以用数值表示,比如:”123″ “456”这样的字符串。

这里需要特殊说明一下vm字段,只有打开了Redis的虚拟内存功能,此字段才会真正的分配内存,该功能默认是关闭状态的,该功能会在后面具体描述。通过上图我们可以发现Redis使用redisObject来表示所有的key/value数据是比较浪费内存的,当然这些内存管理成本的付出主要也是为了给Redis不同数据类型提供一个统一的管理接口,实际作者也提供了多种方法帮助我们尽量节省内存使用,我们随后会具体讨论。

 

 

3.  各种数据类型应用和实现方式

下面我们先来逐一的分析下这7种数据类型的使用和内部实现方式:

  • String:
Strings 数据结构是简单的key-value类型,value其实不仅是String,也可以是数字.

常用命令:  set,get,decr,incr,mget 等。

应用场景:String是最常用的一种数据类型,普通的key/ value 存储都可以归为此类.即可以完全实现目前 Memcached 的功能,并且效率更高。还可以享受Redis的定时持久化,操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外,Redis还提供了下面一些操作:

      • 获取字符串长度
      • 往字符串append内容
      • 设置和获取字符串的某一段内容
      • 设置及获取字符串的某一位(bit)
      • 批量设置一系列字符串的内容

实现方式:String在redis内部存储默认就是一个字符串,被redisObject所引用,当遇到incr,decr等操作时会转成数值型进行计算,此时redisObject的encoding字段为int。

  • Hash

常用命令:hget,hset,hgetall 等。

应用场景:在Memcached中,我们经常将一些结构化的信息打包成HashMap,在客户端序列化后存储为一个字符串的值,比如用户的昵称、年龄、性别、积分等,这时候在需要修改其中某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去。这样不仅增大了开销,也不适用于一些可能并发操作的场合(比如两个并发的操作都需要修改积分)。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。

我们简单举个实例来描述下Hash的应用场景,比如我们要存储一个用户信息对象数据,包含以下信息:

用户ID为查找的key,存储的value用户对象包含姓名,年龄,生日等信息,如果用普通的key/value结构来存储,主要有以下2种存储方式:

 

第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储,这种方式的缺点是,增加了序列化/反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入CAS等复杂问题。

第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿,用用户ID+对应属性的名称作为唯一标识来取得对应属性的值,虽然省去了序列化开销和并发问题,但是用户ID为重复存储,如果存在大量这样的数据,内存浪费还是非常可观的。

那么Redis提供的Hash很好的解决了这个问题,Redis的Hash实际是内部存储的Value为一个HashMap,并提供了直接存取这个Map成员的接口,如下图:

也就是说,Key仍然是用户ID, value是一个Map,这个Map的key是成员的属性名,value是属性值,这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题。很好的解决了问题。

这里同时需要注意,Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多,那么涉及到遍历整个内部Map的操作,由于Redis单线程模型的缘故,这个遍历操作可能会比较耗时,而另其它客户端的请求完全不响应,这点需要格外注意。

实现方式:

上面已经说到Redis Hash对应Value内部实际就是一个HashMap,实际这里会有2种不同实现,这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储,而不会采用真正的HashMap结构,对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

  • List

常用命令:lpush,rpush,lpop,rpop,lrange等。

应用场景:

Redis list的应用场景非常多,也是Redis最重要的数据结构之一,比如twitter的关注列表,粉丝列表等都可以用Redis的list结构来实现。

Lists 就是链表,相信略有数据结构知识的人都应该能理解其结构。使用Lists结构,我们可以轻松地实现最新消息排行等功能。Lists的另一个应用就是消息队列,
可以利用Lists的PUSH操作,将任务存在Lists中,然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作Lists中某一段的api,你可以直接查询,删除Lists中某一段的元素。

实现方式:

Redis list的实现为一个双向链表,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销,Redis内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。

  • Set

常用命令:

sadd,spop,smembers,sunion 等。

应用场景:

Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。

Sets 集合的概念就是一堆不重复值的组合。利用Redis提供的Sets数据结构,可以存储一些集合性的数据,比如在微博应用中,可以将一个用户所有的关注人存在一个集合中,将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功能,对上面的所有集合操作,你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

实现方式:

set 的内部实现是一个 value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。

  • Sorted Set

常用命令:

zadd,zrange,zrem,zcard等

使用场景:

Redis sorted set的使用场景与set类似,区别是set不是自动有序的,而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序,并且是插入有序的,即自动排序。当你需要一个有序的并且不重复的集合列表,那么可以选择sorted set数据结构,比如twitter 的public timeline可以以发表时间作为score来存储,这样获取时就是自动按时间排好序的。

另外还可以用Sorted Sets来做带权重的队列,比如普通消息的score为1,重要消息的score为2,然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

实现方式:

Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。

  • Pub/Sub

Pub/Sub 从字面上理解就是发布(Publish)与订阅(Subscribe),在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。

  • Transactions

谁说NoSQL都不支持事务,虽然Redis的Transactions提供的并不是严格的ACID的事务(比如一串用EXEC提交执行的命令,在执行中服务器宕机,那么会有一部分命令执行了,剩下的没执行),但是这个Transactions还是提供了基本的命令打包执行的功能(在服务器不出问题的情况下,可以保证一连串的命令是顺序在一起执行的,中间有会有其它客户端命令插进来执行)。Redis还提供了一个Watch功能,你可以对一个key进行Watch,然后再执行Transactions,在这过程中,如果这个Watched的值进行了修改,那么这个Transactions会发现并拒绝执行。

 

4.  Redis实际应用场景

        Redis在很多方面与其他数据库解决方案不同:它使用内存提供主存储支持,而仅使用硬盘做持久性的存储;它的数据模型非常独特,用的是单线程。另一个大区别在于,你可以在开发环境中使用Redis的功能,但却不需要转到Redis。

转向Redis当然也是可取的,许多开发者从一开始就把Redis作为首选数据库;但设想如果你的开发环境已经搭建好,应用已经在上面运行了,那么更换数据库框架显然不那么容易。另外在一些需要大容量数据集的应用,Redis也并不适合,因为它的数据集不会超过系统可用的内存。所以如果你有大数据应用,而且主要是读取访问模式,那么Redis并不是正确的选择。

        然而我喜欢Redis的一点就是你可以把它融入到你的系统中来,这就能够解决很多问题,比如那些你现有的数据库处理起来感到缓慢的任务。这些你就可以通过Redis来进行优化,或者为应用创建些新的功能。在本文中,我就想探讨一些怎样将Redis加入到现有的环境中,并利用它的原语命令等功能来解决 传统环境中碰到的一些常见问题。在这些例子中,Redis都不是作为首选数据库。

1、显示最新的项目列表

下面这个语句常用来显示最新项目,随着数据多了,查询毫无疑问会越来越慢。

SELECT * FROM foo WHERE ... ORDER BY time DESC LIMIT 10 

        在Web应用中,“列出最新的回复”之类的查询非常普遍,这通常会带来可扩展性问题。这令人沮丧,因为项目本来就是按这个顺序被创建的,但要输出这个顺序却不得不进行排序操作。

        类似的问题就可以用Redis来解决。比如说,我们的一个Web应用想要列出用户贴出的最新20条评论。在最新的评论边上我们有一个“显示全部”的链接,点击后就可以获得更多的评论。

        我们假设数据库中的每条评论都有一个唯一的递增的ID字段。

        我们可以使用分页来制作主页和评论页,使用Redis的模板,每次新评论发表时,我们会将它的ID添加到一个Redis列表:

 LPUSH latest.comments <ID> 

       我们将列表裁剪为指定长度,因此Redis只需要保存最新的5000条评论:

       LTRIM latest.comments 0 5000

      每次我们需要获取最新评论的项目范围时,我们调用一个函数来完成(使用伪代码):

FUNCTION get_latest_comments(start, num_items):
    id_list = redis.lrange("latest.comments",start,start+num_items - 1)
    IF id_list.length < num_items
        id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")
    END
    RETURN id_list
END

 

      这里我们做的很简单。在Redis中我们的最新ID使用了常驻缓存,这是一直更新的。但是我们做了限制不能超过5000个ID,因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候,才需要去访问数据库。

        我们的系统不会像传统方式那样“刷新”缓存,Redis实例中的信息永远是一致的。SQL数据库(或是硬盘上的其他类型数据库)只是在用户需要获取“很远”的数据时才会被触发,而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

2、删除与过滤

      我们可以使用LREM来删除评论。如果删除操作非常少,另一个选择是直接跳过评论条目的入口,报告说该评论已经不存在。

       有些时候你想要给不同的列表附加上不同的过滤器。如果过滤器的数量受到限制,你可以简单的为每个不同的过滤器使用不同的Redis列表。毕竟每个列表只有5000条项目,但Redis却能够使用非常少的内存来处理几百万条项目。

3、排行榜相关

      另一个很普遍的需求是各种数据库的数据并非存储在内存中,因此在按得分排序以及实时更新这些几乎每秒钟都需要更新的功能上数据库的性能不够理想。

      典型的比如那些在线游戏的排行榜,比如一个Facebook的游戏,根据得分你通常想要:

         – 列出前100名高分选手

         – 列出某用户当前的全球排名

      这些操作对于Redis来说小菜一碟,即使你有几百万个用户,每分钟都会有几百万个新的得分。

      模式是这样的,每次获得新得分时,我们用这样的代码:

      ZADD leaderboard  <score>  <username>

     你可能用userID来取代username,这取决于你是怎么设计的。

      得到前100名高分用户很简单:ZREVRANGE leaderboard 0 99。

      用户的全球排名也相似,只需要:ZRANK leaderboard <username>。

4、按照用户投票和时间排序

      排行榜的一种常见变体模式就像Reddit或Hacker News用的那样,新闻按照类似下面的公式根据得分来排序:

       score = points / time^alpha

      因此用户的投票会相应的把新闻挖出来,但时间会按照一定的指数将新闻埋下去。下面是我们的模式,当然算法由你决定。

      模式是这样的,开始时先观察那些可能是最新的项目,例如首页上的1000条新闻都是候选者,因此我们先忽视掉其他的,这实现起来很简单。

      每次新的新闻贴上来后,我们将ID添加到列表中,使用LPUSH + LTRIM,确保只取出最新的1000条项目。

      有一项后台任务获取这个列表,并且持续的计算这1000条新闻中每条新闻的最终得分。计算结果由ZADD命令按照新的顺序填充生成列表,老新闻则被清除。这里的关键思路是排序工作是由后台任务来完成的。

5、处理过期项目

      另一种常用的项目排序是按照时间排序。我们使用unix时间作为得分即可。

      模式如下:

       – 每次有新项目添加到我们的非Redis数据库时,我们把它加入到排序集合中。这时我们用的是时间属性,current_time和time_to_live。

       – 另一项后台任务使用ZRANGE…SCORES查询排序集合,取出最新的10个项目。如果发现unix时间已经过期,则在数据库中删除条目。

6、计数

       Redis是一个很好的计数器,这要感谢INCRBY和其他相似命令。

       我相信你曾许多次想要给数据库加上新的计数器,用来获取统计或显示新信息,但是最后却由于写入敏感而不得不放弃它们。

       好了,现在使用Redis就不需要再担心了。有了原子递增(atomic increment),你可以放心的加上各种计数,用GETSET重置,或者是让它们过期。

       例如这样操作:

         INCR user:<id> EXPIRE

         user:<id> 60

       你可以计算出最近用户在页面间停顿不超过60秒的页面浏览量,当计数达到比如20时,就可以显示出某些条幅提示,或是其它你想显示的东西。

7、特定时间内的特定项目

        另一项对于其他数据库很难,但Redis做起来却轻而易举的事就是统计在某段特点时间里有多少特定用户访问了某个特定资源。比如我想要知道某些特定的注册用户或IP地址,他们到底有多少访问了某篇文章。

      每次我获得一次新的页面浏览时我只需要这样做:

       SADD page:day1:<page_id> <user_id>

      当然你可能想用unix时间替换day1,比如time()-(time()%3600*24)等等。

      想知道特定用户的数量吗?只需要使用SCARD page:day1:<page_id>。

       需要测试某个特定用户是否访问了这个页面?SISMEMBER page:day1:<page_id>。

 

8、实时分析正在发生的情况,用于数据统计与防止垃圾邮件等

        我们只做了几个例子,但如果你研究Redis的命令集,并且组合一下,就能获得大量的实时分析方法,有效而且非常省力。使用Redis原语命令,更容易实施垃圾邮件过滤系统或其他实时跟踪系统。

9、Pub/Sub

       Redis的Pub/Sub非常非常简单,运行稳定并且快速。支持模式匹配,能够实时订阅与取消频道。

10、队列

        你应该已经注意到像list push和list pop这样的Redis命令能够很方便的执行队列操作了,但能做的可不止这些:比如Redis还有list pop的变体命令,能够在列表为空时阻塞队列。

       现代的互联网应用大量地使用了消息队列(Messaging)。消息队列不仅被用于系统内部组件之间的通信,同时也被用于系统跟其它服务之间的交互。消息队列的使用可以增加系统的可扩展性、灵活性和用户体验。非基于消息队列的系统,其运行速度取决于系统中最慢的组件的速度(注:短板效应)。而基于消息队列可以将系统中各组件解除耦合,这样系统就不再受最慢组件的束缚,各组件可以异步运行从而得以更快的速度完成各自的工作。

    此外,当服务器处在高并发操作的时候,比如频繁地写入日志文件。可以利用消息队列实现异步处理。从而实现高性能的并发操作。

 

11、缓存

        Redis的缓存部分值得写一篇新文章,我这里只是简单的说一下。Redis能够替代memcached,让你的缓存从只能存储数据变得能够更新数据,因此你不再需要每次都重新生成数据了。

此部分内容的原文地址:http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

 

5.  国内外三个不同领域巨头分享的Redis实战经验及使用场景

     随着应用对高性能需求的增加,NoSQL逐渐在各大名企的系统架构中生根发芽。这里我们将为大家分享社交巨头新浪微博、传媒巨头Viacom及图片分享领域佼佼者Pinterest带来的Redis实践,首先我们看新浪微博 @启盼cobain的Redis实战经验分享:


一、新浪微博:史上最大的Redis集群

Tape is Dead,Disk is Tape,Flash is Disk,RAM Locality is King. — Jim Gray

Redis不是比较成熟的memcache或者Mysql的替代品,是对于大型互联网类应用在架构上很好的补充。现在有越来越多的应用也在纷纷基于Redis做架构的改造。首先简单公布一下Redis平台实际情况:

  • 2200+亿 commands/day 5000亿Read/day 500亿Write/day
  • 18TB+ Memory
  • 500+ Servers in 6 IDC 2000+instances

应该是国内外比较大的Redis使用平台,今天主要从应用角度谈谈Redis服务平台。

Redis使用场景

1.Counting(计数)

计数的应用在另外一篇文章里较详细的描述,计数场景的优化 http://www.xdata.me/?p=262这里就不多加描述了。

可以预见的是,有很多同学认为把计数全部存在内存中成本非常高,我在这里用个图表来表达下我的观点:

很多情况大家都会设想纯使用内存的方案会很有很高成本,但实际情况往往会有一些不一样:

  • COST,对于有一定吞吐需求的应用来说,肯定会单独申请DB、Cache资源,很多担心DB写入性能的同学还会主动将DB更新记入异步队列,而这三块的资源的利用率一般都不会太高。资源算下来,你惊异的发现:反而纯内存的方案会更精简!
  • KISS原则,这对于开发是非常友好的,我只需要建立一套连接池,不用担心数据一致性的维护,不用维护异步队列。
  • Cache穿透风险,如果后端使用DB,肯定不会提供很高的吞吐能力,cache宕机如果没有妥善处理,那就悲剧了。
  • 大多数的起始存储需求,容量较小。

2.Reverse cache(反向cache)

面对微博常常出现的热点,如最近出现了较为火爆的短链,短时间有数以万计的人点击、跳转,而这里会常常涌现一些需求,比如我们向快速在跳转时判定用户等级,是否有一些账号绑定,性别爱好什么的,已给其展示不同的内容或者信息。

普通采用memcache+Mysql的解决方案,当调用id合法的情况下,可支撑较大的吞吐。但当调用id不可控,有较多垃圾用户调用时,由于memcache未有命中,会大量的穿透至Mysql服务器,瞬间造成连接数疯长,整体吞吐量降低,响应时间变慢。

这里我们可以用redis记录全量的用户判定信息,如string key:uid int:type,做一次反向的cache,当用户在redis快速获取自己等级等信息后,再去Mc+Mysql层去获取全量信息。如图:

当然这也不是最优化的场景,如用Redis做bloomfilter,可能更加省用内存。

3.Top 10 list

产品运营总会让你展示最近、最热、点击率最高、活跃度最高等等条件的top list。很多更新较频繁的列表如果使用MC+MySQL维护的话缓存失效的可能性会比较大,鉴于占用内存较小的情况,使用Redis做存储也是相当不错的。

4.Last Index

用户最近访问记录也是redis list的很好应用场景,lpush lpop自动过期老的登陆记录,对于开发来说还是非常友好的。

5.Relation List/Message Queue

这里把两个功能放在最后,因为这两个功能在现实问题当中遇到了一些困难,但在一定阶段也确实解决了我们很多的问题,故在这里只做说明。

Message Queue就是通过list的lpop及lpush接口进行队列的写入和消费,由于本身性能较好也能解决大部分问题。

6.Fast transaction with Lua

Redis 的Lua的功能扩展实际给Redis带来了更多的应用场景,你可以编写若干command组合作为一个小型的非阻塞事务或者更新逻辑,如:在收到message推送时,同时1.给自己的增加一个未读的对话 2.给自己的私信增加一个未读消息 3.最后给发送人回执一个完成推送消息,这一层逻辑完全可以在Redis Server端实现。

但是,需要注意的是Redis会将lua script的全部内容记录在aof和传送给slave,这也将是对磁盘,网卡一个不小的开销。

7.Instead of Memcache

  1. 很多测试和应用均已证明,
  2. 在性能方面Redis并没有落后memcache多少,而单线程的模型给Redis反而带来了很强的扩展性。
  3. 在很多场景下,Redis对同一份数据的内存开销是小于memcache的slab分配的。
  4. Redis提供的数据同步功能,其实是对cache的一个强有力功能扩展。

Redis使用的重要点

1.rdb/aof Backup!

我们线上的Redis 95%以上是承担后端存储功能的,我们不仅用作cache,而更为一种k-v存储,他完全替代了后端的存储服务(MySQL),故其数据是非常重要的,如果出现数据污染和丢失,误操作等情况,将是难以恢复的。所以备份是非常必要的!为此,我们有共享的hdfs资源作为我们的备份池,希望能随时可以还原业务所需数据。

2.Small item & Small instance!

由于Redis单线程(严格意义上不是单线程,但认为对request的处理是单线程的)的模型,大的数据结构list,sorted set,hash set的批量处理就意味着其他请求的等待,故使用Redis的复杂数据结构一定要控制其单key-struct的大小。

另外,Redis单实例的内存容量也应该有严格的限制。单实例内存容量较大后,直接带来的问题就是故障恢复或者Rebuild从库的时候时间较长,而更糟糕的是,Redis rewrite aof和save rdb时,将会带来非常大且长的系统压力,并占用额外内存,很可能导致系统内存不足等严重影响性能的线上故障。我们线上96G/128G内存服务器不建议单实例容量大于20/30G。

3.Been Available!

业界资料和使用比较多的是Redis sentinel(哨兵)

http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.html

http://qiita.com/wellflat/items/8935016fdee25d4866d9

2000行C实现了服务器状态检测,自动故障转移等功能。

但由于自身实际架构往往会复杂,或者考虑的角度比较多,为此 @许琦eryk和我一同做了hypnos项目。

hypnos是神话中的睡神,字面意思也是希望我们工程师无需在休息时间处理任何故障。:-)

其工作原理示意如下:

Talk is cheap, show me your code! 稍后将单独写篇博客细致讲下Hypnos的实现。

4.In Memory or not?

发现一种情况,开发在沟通后端资源设计的时候,常常因为习惯使用和错误了解产品定位等原因,而忽视了对真实使用用户的评估。也许这是一份历史数据,只有最近一天的数据才有人进行访问,而把历史数据的容量和最近一天请求量都抛给内存类的存储现实是非常不合理的。

所以当你在究竟使用什么样的数据结构存储的时候,请务必先进行成本衡量,有多少数据是需要存储在内存中的?有多少数据是对用户真正有意义的。因为这其实对后端资源的设计是至关重要的,1G的数据容量和1T的数据容量对于设计思路是完全不一样的

Plans in future?

1.slave sync改造

全部改造线上master-slave数据同步机制,这一点我们借鉴了MySQL Replication的思路,使用rdb+aof+pos作为数据同步的依据,这里简要说明为什么官方提供的psync没有很好的满足我们的需求:

假设A有两个从库B及C,及 A `— B&C,这时我们发现master A服务器有宕机隐患需要重启或者A节点直接宕机,需要切换B为新的主库,如果A、B、C不共享rdb及aof信息,C在作为B的从库时,仍会清除自身数据,因为C节点只记录了和A节点的同步状况。

故我们需要有一种将A`–B&C 结构切换切换为A`–B`–C结构的同步机制,psync虽然支持断点续传,但仍无法支持master故障的平滑切换。

实际上我们已经在我们定制的Redis计数服务上使用了如上功能的同步,效果非常好,解决了运维负担,但仍需向所有Redis服务推广,如果可能我们也会向官方Redis提出相关sync slave的改进。

2.更适合redis的name-system Or proxy

细心的同学发现我们除了使用DNS作为命名系统,也在zookeeper中有一份记录,为什么不让用户直接访问一个系统,zk或者DNS选择其一呢?

其实还是很简单,命名系统是个非常重要的组件,而dns是一套比较完善的命名系统,我们为此做了很多改进和试错,zk的实现还是相对复杂,我们还没有较强的把控粒度。我们也在思考用什么做命名系统更符合我们需求。

3.后端数据存储

大内存的使用肯定是一个重要的成本优化方向,flash盘及分布式的存储也在我们未来计划之中。(原文链接: Largest Redis Clusters Ever


二、Pinterest:Reids维护上百亿的相关性

      Pinterest已经成为硅谷最疯故事之一,在2012年,他们基于PC的业务增加1047%,移动端采用增加1698%, 该年3月其独立访问数量更飙升至533亿。在Pinterest,人们关注的事物以百亿记——每个用户界面都会查询某个board或者是用户是否关注的行为促成了异常复杂的工程问题。这也让Redis获得了用武之地。经过数年的发展,Pinterest已经成为媒体、社交等多个领域的佼佼者,其辉煌战绩如下:

  • 获得的推荐流量高于Google+、YouTube及LinkedIn三者的总和
  • 与Facebook及Twitter一起成为最流行的三大社交网络
  • 参考Pinterest进行购买的用户比其它网站更高( 更多详情

如您所想,基于其独立访问数,Pinterest的高规模促成了一个非常高的IT基础设施需求。

 

通过缓存来优化用户体验

近日,Pinterest工程经理Abhi Khune对其公司的用户体验需求及Redis的使用经验 进行了分享。即使是滋生的应用程序打造者,在分析网站的细节之前也不会理解这些特性,因此先大致的理解一下使用场景:首先,为每个粉丝进行提及到的预检查;其次,UI将准确的显示用户的粉丝及关注列表分页。高效的执行这些操作,每次点击都需要非常高的性能架构。

不能免俗,Pinterest的软件工程师及架构师已经使用了MySQL及memcache,但是缓存解决方案仍然达到了他们的瓶颈;因此为了拥有更好的用户体验,缓存必须被扩充。而在实际操作过程中,工程团队已然发现缓存只有当用户sub-graph已经在缓存中时才会起到作用。因此。任何使用这个系统的人都需要被缓存,这就导致了整个图的缓存。同时,最常见的查询“用户A是否关注了用户B”的答案经常是否定的,然而这却被作为了缓存丢失,从而促成一个数据库查询,因此他们需要一个新的方法来扩展缓存。最终,他们团队决定使用Redis来存储整个图,用以服务众多的列表。

使用Redis存储大量的Pinterest列表

Pinterest使用了Redis作为解决方案,并将性能推至了内存数据库等级,为用户保存多种类型列表:

  • 关注者列表
  • 你所关注的board列表
  • 粉丝列表
  • 关注你board的用户列表
  • 某个用户中board中你没有关注的列表
  • 每个board的关注者及非关注者

Redis为其7000万用户存储了以上的所有列表,本质上讲可以说是储存了所有粉丝图,通过用户ID分片。鉴于你可以通过类型来查看以上列表的数据,分析概要信息被用看起来更像事务的系统储存及访问。Pinterest当下的用户like被限制为10万,初略进行统计:如果每个用户关注25个board,将会在用户及board间产生17.5亿的关系。同时更加重要的是,这些关系随着系统的使用每天都会增加。

Pinterest的Reids架构及运营

通过Pinterest的一个创始人了解到,Pinterest开始使用Python及订制的Django编写应用程序,并一直持续到其拥有1800万用户级日410TB用户数据的时候。虽然使用了多个存储对数据进行储存,工程师根据用户id使用了8192个虚拟分片,每个分片都运行在一个Redis DB之上,同时1个Redis实例将运行多个Redis DB。为了对CPU核心的充分使用,同一台主机上同时使用多线程和单线程Redis实例。

鉴于整个数据集运行在内存当中,Redis在Amazon EBS上对每秒传输进来的写入都会进行持久化。扩展主要通过两个方面进行:第一,保持50%的利用率,通过主从转换,机器上运行的Redis实例一半会转译到一个新机器上;第二,扩展节点和分片。整个Redis集群都会使用一个主从配置,从部分将被当做一个热备份。一旦主节点失败,从部分会立刻完成主的转换,同时一个新的从部分将会被添加,ZooKeeper将完成整个过程。同时他们每个小时都会在Amazon S3上运行BGsave做更持久的储存——这项Reids操作会在后端进行,之后Pinterest会使用这些数据做MapReduce和分析作业。(更多内容见原文)


三、Viacom:Redis在系统中的用例盘点

Viacom是全球最大的传媒集体之一,同时也遭遇了当下最大的数据难题之一:如何处理日益剧增的动态视频内容。

着眼这一挑战的上升趋势,我们会发现:2010年世界上所有数据体积达到ZB级,而单单2012这一年,互联网产生的数据就增加了2.8个ZB,其中大部分的数据都是非结构化的,包括了视频和图片。

覆盖MVN(以前称为MTV Networks、Paramount及BET),Viacom是个名副其实的传媒巨头,支持众多人气站点,其中包括The Daily Show、osh.0、South Park Studios、GameTrailers.com等。作为媒体公司,这些网站上的文档、图片、视频短片都在无时无刻的更新。长话短说,下面就进入Viacom高级架构师Michael Venezia 分享的Redis实践:

Viacom的网站架构背景

对于Viacom,横跨多个站点传播内容让必须专注于规模的需求,同时为了将内容竟可能快的传播到相应用户,他们还必须聚焦内容之间的关系。然而即使The Daily Show、Nickelodeon、Spike或者是VH1 这些单独的网站上,日平均PV都可以达到千万,峰值时流量更会达到平均值的20-30倍。同时基于对实时的需求,动态的规模及速度已成为架构的基础之一。

除去动态规模之外,服务还必须基于用户正在浏览的视频或者是地理位置来推测用户的喜好。比如说,某个页面可能会将一个独立的视频片段与本地的促销,视频系列的额外部分,甚至是相关视频联系起来。为了能让用户能在网站上停留更长的时间,他们建立了一个能基于详细元数据自动建立页面的软件引擎,这个引擎可以根据用户当下兴趣推荐额外的内容。鉴于用于兴趣的随时改变,数据的类型非常广泛——类似graph-like,实际上做的是大量的join。

这样做有利于减少类似视频的大体积文件副本数,比如数据存储中一个独立的记录是Southpark片段“Cartman gets an Anal Probe”,这个片段可能也会出现在德语的网站上。虽然视频是一样的,但是英语用户搜索的可能就是另一个不同的词语。元数据的副本转换成搜索结果,并指向相同的视频。因此在美国用户搜索真实标题的情况下,德国浏览者可能会使用转译的标题——德国网站上的“Cartman und die Analsonde”。

这些元数据覆盖了其它记录或者是对象,同时还可以根据使用环境来改变内容,通过不同的规则集来限制不同地理位置或者是设备请求的内容。

Viacom的实现方法

尽管许多机构通过使用ORM及传统关系型数据库来解决这个问题,Viacom却使用了一个迥然不同的方法。

本质上,他们完全承担不了对数据库的直接访问。首先,他们处理的大部分都是流数据,他们偏向于使用Akamai从地理上来分配内容。其次,基于页面的复杂性可能会取上万个对象。取如此多的数据显然会影响到性能,因此JSON在1个数据服务中投入了使用。当然,这些JSON对象的缓存将直接影响到网站性能。同时,当内容或者是内容之间的关系发生改变时,缓存还需要动态的进行更新。

Viacom依靠对象基元和超类解决这个问题,继续以South Park为例:一个私有的“episode”类包含了所有该片段相关信息,一个“super object”将有助于发现实际的视频对象。超类这个思想确实非常有益于建设低延迟页面的自动建设,这些超类可以帮助到基元对象到缓存的映射及保存。

Viacom为什么要使用Redis

每当Viacom上传一个视频片段,系统将建立一个私有的对象,并于1个超类关联。每一次修改,他们都需要重估私有对象的每个改变,并更新所有复合对象。同时,系统还需要无效Akamail中的URL请求。系统现有架构的组合及更敏捷的管理方法需求将Viacom推向了Redis。

基于Viacom主要基于PHP,所以这个解决方案必须支持PHP。他们首先选择了memcached做对象存储,但是它并不能很好的支持hashmap;同时他们还需要一个更有效的进行无效步骤的重估,即更好的理解内容的依赖性。本质上说,他们需要时刻跟进无效步骤中的依赖性改变。因此他们选择了Redis及Predis的组合来解决这个问题。

他们团队使用Redis给southparkstudios.com和thedailyshow.com两个网站建设依赖性图,在取得了很大的成功后他们开始着眼Redis其它适合场景。

Redis的其它使用场景

显而易见,如果有人使用Redis来建设依赖性图,那么使用它来做对象处理也是说得通的。同样,这也成了架构团队为Redis选择的第二使用场景。Redis的复制及持久化特性同时也征服了Viacom的运营团队,因此在几个开发周期后,Redis成为他们网站的主要数据及依赖性储存。

后两个用例则是行为追踪及浏览计数的缓冲,改变后的架构是Redis每几分钟向MySQL中储存一次,而浏览计数则通过Redis进行存储及计数。同时Redis还被用来做人气的计算,一个基于访问数及访问时间的得分系统——如果某个视频最近被访问的次数越多,它的人气就越高。在如此多内容上每隔10-15分钟做一次计算绝对不是类似MySQL这样传统关系型数据库的强项,Viacom使用Redis的理由也非常简单——在1个存储浏览信息的Redis实例上运行Lua批处理作业,计算出所有的得分表。信息被拷贝到另一个Redis实例上,用以支持相关的产品查询。同时还在MySQL上做了另一个备份,用以以后的分析,这种组合会将这个过程耗费的时间降低60倍。

Viacom还使用Redis存储一步作业信息,这些信息被插入一个列表中,工作人员则使用BLPOP命令行在队列中抓取顶端的任务。同时zsets被用于从众多社交网络(比如Twitter及Tumblr)上综合内容,Viacom通过Brightcove视频播放器来同步多个内容管理系统。

横跨这些用例,几乎所有的Redis命令都被使用——sets、lists、zlists、hashmaps、scripts、counters等。同时,Redis也成为Viacom可扩展架构中不可或缺的一环。

 

Squid

一、Squid简介与原理分析
1、Squid
Squid cache(简称为Squid)是一个流行的自由软件,它符合GNU通用公共许可证。Squid作为网页服务器的前置cache服务器,可以代理用户向web服务器请求数据并进行缓存,也可以用在局域网中,使局域网用户通过代理上网。Squid主要设计用于在Linux一类系统运行。

2、Squid典型的代理服务
(1)标准的代理缓冲服务器
(2)透明代理缓冲服务器
(3)反向代理缓冲服务器

3、反向代理工作原理
反向代理服务器位于本地WEB服务器和Internet之间,当用户浏览器发出一个HTTP请求时,通过域名解析将请求定向到反向代理服务器(如果要实现多个WEB服务器的反向代理,需要将多个WEB服务器的域名都指向反向代理服务器)。由反向代理服务器处理请求。反向代理一般只缓存可缓存的数据(比如html网页和图片等),而一些CGI脚本程序或者ASP之类的程序不缓存。它根据从WEB服务器返回的HTTP头标记来缓冲静态页面。有四个最重要HTTP标记:
#Last-Modiffied:告诉反向代理页面什么时间被修改
#Expires:告诉反向代理页面什么时间应该从缓冲区中删除
#Cache-Controll:告诉反向代理页面是否应该被缓冲
#Pragma:告诉反向代理页面是否应该被缓冲

4、CDN实现拓扑图
CDN achieve topology

5、Squid反向代理拓扑
Squids reverse proxy topology

Linux 命令行快捷键

开始说说历史记录个数的 “HISTFILESIZE” 和 “HISTSIZE” 的区别,

  默认情况下 HISTFILESIZE 和 HISTSIZE的值都是 500,表示可以记录 500 条命令记录。

HISTFILESIZE 表示记录在文件中的命令条数
HISTSIZE 表示记录在内存中的命令条数
  当我们在 shell 命令行执行命令的时候,最近的 HISTSIZE 条命令被保存在内存当中可以使用上下光标或者 ctrl+p,ctrl+n 上下查找命令。

  当退出 shell 时 HISTFILESIZE 条命令被保存到历史命令文件中,下次登录 shell 时会从历史命令文件中读取命令道内存历史命令道中。

  当网络中断等异常时,你会发现之前的历史命令,下次登录时用上下光标找不到上次的历史命令,所以要正常退出或者发送探测包保持 shell 在线。

  如果想增加历史命令保存的数量,可以在 ~/.bash_profile 中手动修改 HISTFILESIZE 和 HISTSIZE 这两个变量的值。

搜索操作快捷键

  搜索历史命令的快捷键:Ctrl + r

  它是通过关键字去匹配历史记录,执行后会提示:(reverse-i-search)`’:

  输入你记得的关键字去匹配,如果出现你需要的命令,按Enter就可以选择命令;如果不是请输入更精确的关键字去匹配。

移动操作快捷键

Ctrl + f– 向右移动一个字符,当然多数人用→
Ctrl + b– 向左移动一个字符, 多数人用←
ESC + f– 向右移动一个单词,MAC下建议用ALT + →
ESC + b– 向左移动一个单词,MAC下建议用ALT + ←
Ctrl + a– 跳到行首
Ctrl + e– 跳到行尾

删除操作快捷键

Ctrl + d– 向右删除一个字符
Ctrl + h– 向左删除一个字符
Ctrl + u– 删除当前位置字符至行首(输入密码错误的时候多用下这个)
Ctrl + k– 删除当前位置字符至行尾
Ctrl + w– 删除从光标到当前单词开头

命令切换操作快捷键

Ctrl + p– 上一个命令,也可以用↑
Ctrl + n– 下一个命令,也可以用↓

其他操作快捷键

Ctrl + y– 插入最近删除的单词
Ctrl + c– 终止操作
Ctrl + d– 当前操作转到后台
Ctrl + l– 清屏 (有时候为了好看)