「深度学习福利」大神带你进阶工程师,立即查看>>>
第一节：单点登录简介
第一步：了解单点登录
SSO主要特点是: SSO应用之间使用Web协议(如HTTPS),并且只有一个登录入口.
SSO的体系中有下面三种角色:
1) User(多个)
2) Web应用(多个)
3) SSO认证中心(一个)
SSO实现包含以下三个原则:
1)所有的登录都在SSO认证中心进行。
2) SSO认证中心通过一些方法来告诉Web应用当前访问用户究竟是不是通过认证的用户.
3) SSO认证中心和所有的Web应用建立一种信任关系.
CAS的基本原理CAS(Central Authentication Service)是Yale耶鲁大学发起的构建Web SSO的Java开源项目。
1.CAS术语解释:
SSO－Single Sign On单点登录
TGT－Ticket Granting Ticket用户身份认证凭证票据
ST－Service Ticket服务许可凭证票据
TGC－Ticket Granting Cookie存放用户身份认证凭证票据的cookie.
第二步：了解单点登录体系结构
1)CAS Server负责完成对用户信息的认证,需要单独部署,CAS Server会处理用户名/密码等凭证(Credentials).
2)CAS Client部署在客户端,当有对本地Web应用受保护资源的访问请求,并且需要对请求方进行身份认证,重定向到CAS Server进行认证.
第三步：单点登录环境准备工作
1)cas-server-3.5.0-release.zip（CAS服务端）
2)cas-client-3.3.3-release.zip（CAS客户端）
3)apache-tomcat-7.0.40
4)cas-client-core-3.2.1.jar
5)cas-server-core-3.5.0.jar
6)cas-server-support-jdbc-3.5.0.jar
第二节：单点登录环境搭建与部署
第一步：环境部署
1.通过Java JDK生成证书三部曲
证书对于实现此单点登录非常之重要,证书是服务器端和客户端安全通信的凭证,本教程只是演示,所有用了JDK自带的证书生成工具keytool。
当然在实际项目中你可以到专门的证书认证中心购买证书。
使用JDK自带的keytool生成证书
第一步生成证书:
keytool -genkey -alias mycacerts -keyalg RSA -keystore C:/common/keys/keycard
注意：输入相关信息用于生成证书.其中名字与姓氏这一最好写你的域名,如果在单击测试你可以在C:\Windows\System32\drivers\etc\hosts文件中映射一个虚拟域名,
注意不要写IP。
第二步导出证书:
keytool -export -file C:/common/keys/keycard.crt -alias mycacerts -keystoreC:/common/keys/keycard
第三步导入到JDK安装目录证书:
keytool -import -keystore C:/"ProgramFiles"/Java/jdk1.6.0_32/jre/lib/security/cacerts -fileC:/common/keys/keycard.crt -alias mycacerts
2.解压cas-server-3.5.0-release.zip文件,
在cas-server-3.5.0-release\cas-server-3.5.0\modules目录下找到cas-server-webapp-3.5.0.war文件并命名为cas.war,并复制到在Tomcat根目录的webapps目录下,
如下图：
3.修改host文件（C:\Windows\System32\drivers\etc）hosts文件中添加添加以下配置
127.0.0.1 jeesz.cn (配置自己的域名.)
注意：如果想在一台PC机上模拟这个单点登录,就必须域名重定向,如果是多台ＰＣ机,可以不配置此项,下文有用到 fast-web.cn,可以用相应ＰＣ机的ＩＰ代替
4.修改Tomcat文件下的server.xml(apache-tomcat-7.0.40\conf\server.xml)添加以下内容：
在server.xml文件中把
maxThreads="150" scheme="https"secure="true"
clientAuth="false" sslProtocol="TLS" />
修改成如下：
port="8443"
protocol="org.apache.coyote.http11.Http11Protocol"
maxThreads="150"
SSLEnabled="true"
scheme="https"
secure="true"
clientAuth="false"
sslProtocol="TLS"
keystoreFile="C:/common/keys/keycard"
keystorePass="xxxxxx "
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"
/>
5.启动Tomcat服务,查看信息,（如果有报错,可以根据信息查找错误）,打开浏览器,输入 jeesz.cn:8080/cas如果出现以下界面,则代表CAS服务端配置成功。
注：这个是最简单的CAS服务,只要输入的用户名跟密码一样,就可以正常登陆,在我们实际开发中,这个验证因为跟数据库作比较,接下来,我们就配置数据库校验。
第二步：配置数据库验证
1.在apache-tomcat-7.0.2\webapps\cas\WEB-INF目录下找到deployerConfigContext.xml文件,找到如下代码：

添加下面代码：
这里sql属性是从user表中根据cas登陆名查找密码-->
2.增加数据源dataSource,
在deployerConfigContext.xml,（跟上面同一个文件）找到
,在下面添加如下代码：
com.mysql.jdbc.Driver
jdbc:mysql://127.0.0.1:3306/sso根据自己的数据库URL地址-->
root根据自己的数据库用户名-->
根据自己的数据库密码-->
3.数据库添加用户表及数据（这里用的mysql）,比如在mysql数据库中有t_user表
4.增加jar包,cas-client-core-3.2.1.jar、cas-server-core-3.5.0.jar、cas-server-support-jdbc-3.5.0.jar包拷贝到apache-tomcat-7.0.2\webapps\cas\WEB-INF\lib目录下。
5.重启Tomcat,打开浏览器,输入 jeesz.cn:8080/,输入数据库里的用户名和密码,如果出现如下界面,则配置成功。
现在我们的CAS服务端已经配置好了,接下来,我们配置客户端
第二节：配置自己的Web工程（客户端）
1.在host文件下,添加如下代码：
127.0.0.1 www.sso1.com
127.0.0.1 www.sso2.com
注意：这个网址最好不要用互联网已经存在的域名,否则你将无法访问该地址。
如果想在一台PC机上模拟这个单点登录,就必须域名重定向,如果是多台ＰＣ机,可以不配置此项,下文有用到www.sso1.com,www.sso2.com,可以用相应ＰＣ机的ＩＰ代替
1.在Tomcat根目录下创建一个sso1,sso2目录。如下如：
2在eclipse新建两个web工程,分别为sso1,sso2。
3在自己的Web工程里加入cas-client-core.jar,commons-logging-1.1.jar,（解压cas-client-3.2.0-release.zip,在cas-client-3.2.0-release.zip\cas-client-3.2.0\modules,找到该JAR包）分别加入到sso1,sso2工程的lib里。

「深度学习福利」大神带你进阶工程师,立即查看>>>
uiautomatorviewer和appium无法捕获App页面
报错
uiautomatorviewer报错 Error obtaining ui hierarchy Reason: error taking device screenshot:EOF
appium报错 App Source Could not obtain source: [object Object]
appium server日志报错 Error: Cannot get screenshot data because of 'The size of the taken screenshot equals to zero.'. Make sure the 'LayoutParams.FLAG_SECURE' is not set for the current view
原因
App页面已经被禁止截屏,禁用用户截屏的代码如下： getWindow().addFlags(WindowManager.LayoutParams.FLAG_SECURE); setContentView(R.layout.activity_main);
解决
执行代码,进入该页面,通过 String source = driver.getPageSource(); 获取该页面的dom,通过dom找到需要定位的元素。

「深度学习福利」大神带你进阶工程师,立即查看>>>
JAVAEE平台由一整套服务（Services）、应用程序接口（APIs）和协议构成,它对开发基于Web的多层应用提供了功能支持,下面对JAVAEE中的13种技术规范进行简单的描述(限于篇幅,这里只进行简单的描述)：
1、JDBC(Java Database Connectivity) 　　JDBC API为访问不同的数据库提供了一种统一的途径,象ODBC一样,JDBC对开发者屏蔽了一些细节问题,另外,JDCB对数据库的访问也具有平台无关性。
2、JNDI(Java Name and Directory Interface) 　　JNDI API被用于执行名字和目录服务。它提供了一致的模型来存取和操作企业级的资源如DNS和LDAP,本地文件系统,或应用服务器中的对象。
3、EJB(Enterprise JavaBean) 　　JAVAEE技术之所以赢得媒体广泛重视的原因之一就是EJB。它们提供了一个框架来开发和实施分布式商务逻辑,由此很显著地简化了具有可伸缩性和高度复杂的企业级应用的开发。EJB规范定义了EJB组件在何时如何与它们的容器进行交互作用。容器负责提供公用的服务,例如目录服务、事务管理、安全性、资源缓冲池以及容错性。但这里值得注意的是,EJB并不是实现JAVAEE的唯一途径。正是由于JAVAEE的开放性,使得有的厂商能够以一种和EJB平行的方式来达到同样的目的。
4、RMI(Remote Method Invoke) 　　正如其名字所表示的那样,RMI协议调用远程对象上方法。它使用了序列化方式在客户端和服务器端传递数据。RMI是一种被EJB使用的更底层的协议。
5、Java IDL/CORBA 　　在Java IDL的支持下,开发人员可以将Java和CORBA集成在一起。他们可以创建Java对象并使之可在CORBA ORB中展开, 或者他们还可以创建Java类并作为和其它ORB一起展开的CORBA对象的客户。后一种方法提供了另外一种途径,通过它Java可以被用于将你的新的应用和旧的系统相集成。
6、JSP(Java Server Pages) 　　JSP页面由HTML代码和嵌入其中的Java代码所组成。服务器在页面被客户端所请求以后对这些Java代码进行处理,然后将生成的HTML页面返回给客户端的浏览器。
7、Java Servlet 　　Servlet是一种小型的Java程序,它扩展了Web服务器的功能。作为一种服务器端的应用,当被请求时开始执行,这和CGI Perl脚本很相似。Servlet提供的功能大多与JSP类似,不过实现的方式不同。JSP通常是大多数HTML代码中嵌入少量的Java代码,而servlets全部由Java写成并且生成HTML。
8、XML(Extensible Markup Language) 　　XML是一种可以用来定义其它标记语言的语言。它被用来在不同的商务过程中共享数据。 XML的发展和Java是相互独立的,但是,它和Java具有的相同目标正是平台独立性。通过将Java和XML的组合,您可以得到一个完美的具有平台独立性的解决方案。
9、JMS(Java Message Service) 　　JMS是用于和面向消息的中间件相互通信的应用程序接口(API)。它既支持点对点的域,有支持发布/订阅(publish/subscribe)类型的域,并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递,一致性消息和具有持久性的订阅者支持。JMS还提供了另 一种方式来对您的应用与旧的后台系统相集成。
10、JTA(Java Transaction Architecture) 　　JTA定义了一种标准的API,应用系统由此可以访问各种事务监控。
11、JTS(Java Transaction Service) 　　JTS是CORBA OTS事务监控的基本的实现。JTS规定了事务管理器的实现方式。该事务管理器是在高层支持Java Transaction API (JTA)规范,并且在较底层实现OMG OTS specification的Java映像。JTS事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器提供了事务服务。
12、JavaMail 　　JavaMail是用于存取邮件服务器的API,它提供了一套邮件服务器的抽象类。不仅支持SMTP服务器,也支持IMAP服务器。
13、JAF(JavaBeans Activation Framework) 　　JavaMail利用JAF来处理MIME编码的邮件附件。MIME的字节流可以被转换成Java对象,或者转换自Java对象。

「深度学习福利」大神带你进阶工程师,立即查看>>>
字符 python的字符串表示可以用双引号或单引号,都 表示字符串。这种灵活性可以在字符串中包含引号,只要和最外面引号不一样即可。str(var)
可把var变为字符串类型。int(var)
可把vat变为整型注释 单行注释
+ 单行注释是#code。多行注释
+ 多行注释是”’code”’(三引号,双引号或单引号都可）
列表（类似于数组）
注： 同一列表中可以存在任何类型的元素。
table = ["1","2","3"];
访问最后一个元素：table[-1],倒数第二个table[-2],以此类推。添加元素
在列表末尾添加(append)
table.append(var);
在任何位置插入元素(insert)
table.insert(index,var);//添加元素var使他的下标为index;删除元素(del) 排序 列表反转
reverse()
table.reverse();列表长度
len()
len(table);转化为列表
list()
比如把一串数字转化为列表：
n = list(range(1,4,2));//range(1,4,2)是指从1开始每次加2(默认是1)加入数字串,直到数字大于或等于4(不包括4)列表解析
列表解析是一句话生成一个想要的列表：
squares = [value**2 for value in range(1,11)]
表达式是value**2,for循环为表达式提供值。整个列表的元素就是所有的value**2。(python中**是乘方运算)列表切片
列表切片其实就是截取列表的一部分使之成为一个新的列表
n = [1,2,3,4,5];
n = n[1:3];
意思是取列表n从下标1开始到下标2的这一部分做为一个新的列表赋值给n。复制列表
n = [1,2,3,4];
m = n[:];
这是正确的复制列表,即取n的整个切片,而
n = [1,2,3,4];
m=n;
是错误的,这里m和n指向同一个列表,没达到复制的目的(注意与其他语言的不同)判断列表是否为空：
n = [];
if(n);//python中列表至少有一个元素时返回true使用集合函数set()
集合函数set()去除列表中相同的元素：
a = [1,2,3,1];
a = set(a);//集合去除相同的值,保证集合中的元素各不相同永久排序
sort()
table.sort(); 默认字典序
table.sort(reverse = True);反字典序临时排序,只是为了输出等,不改变原列表的顺序
sorted()
sorted(table);//返回排序后的列表
sorted(table,reverse = True);del 删除元素
del table[index];pop()弹出并返回列表末尾的元素
var = table.pop();pop(index)弹出并返回列表中任一位置的元素remove(var)根据值删除元素(只删除第一个出现的值）
table.remove(var)
元组（不可修改的列表）
yz = (200,50);
即yz元组有两个元素200和50;
修改元组的值将会报错;
如果需要存储不可变的一组值,可以使用元组。
遍历元组
和遍历列表一样;
循环
for name in array：
print(name);
print(name.title());
注：python是按缩进来区分代码块的,而不是一般语言中的大括号{},所以上面的两个print都是在一个for循环。python中的缩进是非常严格的,不该缩进的缩进还将产生语法错误！while
while a>=5:
print();
a--;条件语句 if-elif-else
if car =="jj":
print();
elif car =="dd":
print();
else:
print();and/orin/not in
判断元素是(否)在列表中：
>>>n=[1,2,4,8];
>>>"88" in n:
>>>true;字典
字典是一系列的键值对,其中值可以对应数字,字符串,列表乃至字典等任何python对象。
如： a = ['1':0,'2':3];
for key,value in a.items():
print(key);
print(value);
这里使用了字典的一个方法item(),它返回一个键值对列表。当不使用值时,可以只遍历键:
for key in a.keys():
print(key);
这里使用了key()方法,提取键列表。当不使用键时只使用值时,可以只遍历值：
for value in a.values():
`print(value);字典定义：alien = {'color':'green','points':5};访问字典元素：alien['color']; 添加键值对:
alien = {'color':'green','points':5};
alien['x']=0;alien['y']=1;//添加x,y
注:键值对的添加顺序和排列顺序不同,python不关注键值对的存储顺序,只关注键值对之间的关联关系。删除键值对
del alien['x'];遍历字典 输入 message = input(some input information);
input获取用户的输入解析为字符串并存入message,参数是显示给用户的信息。以用户输入回车结束input() 函数 import function as f;from function import test as t;定义:
def a(b="dd"):
print();
return b;
def 说明这是个函数定义,a是函数名,b是参数并且有个默认值,且为返回值,后面的所有缩进行构成了函数体。 注意：
1.python函数的形参列表必须是先列出没有默认值的,再列出有默认值的。
2.以列表为参数时,函数内对列表的修改都是永久性的.其他参数不一定。如果想传递列表参数而不改变原列表,可以传递列表的副本作为参数,即切片a[:];调用: a("ff");实参的类型： 传递任意数量的实参
有时我们不知道函数需要接受多少实参,python中允许函数接受任意数量的实参： 将函数存放到文件中并导入
可以将函数存放到文件中,使用时导入这个文件。
比如function.py文件中有一个test()函数： import function
这种方式导入时是导入整个文件,调用函数使用function.test()from function import test
这种是把特定的函数导入,调用时直接使用test()from function import *
这种是把文件中的所有函数导入,与导入整个包类似,不过调用时直接test()为了避免有时候函数重名或名字太长,可以给文件或函数起别名： 任意数量的非关键字实参
def a(*value):
这里形参前加了星号,这样无论调用函数时传入多少实参,函数会把这些实参存入元组value。也就是说这里value是一个元组,他接受任意数量的非关键字实参加入。我们就可以通过遍历这个元组来获得传入的实参。 注意：任意数量的形参必须放到最后,python把余下的实参都收集到最后一个行参（元组）中。任意数量的关键字实参
def a(**value):
这里行参前加了两个星号,这样传入任意数量的关键字实参后,都会存入字典value,也就是说这里value是个字典,他接受任意数量的关键字实参加入。位置实参
即实参的位置必须与行参的位置一一对应关键字实参
实参的位置不必与行参的位置对应,但必须指明行参的名字, 如:
函数定义：def a(value,key):
调用:a(key =“d”,value=“g”）;

「深度学习福利」大神带你进阶工程师,立即查看>>>
负载均衡技术原理浅析
https://help.aliyun.com/knowledge_detail/39444.html?spm=5176.7839438.2.6.XBbX5l
阿里定制版的LVC 开源地址：https://github.com/alibaba/LVS?spm=5176.7739444.2.10.WxLaqZ
更新时间：2016-07-12 13:21:10
1、 技术架构
2、 LVS技术特点 FULLNAT技术概述 SYNPROXY技术概述 集群部署方式 Keepalived优化
3、 Tengine技术特点
4、 更多功能

SLB（Server Load Balancer）服务通过设置虚拟服务地址（IP）,将位于同一地域（Region）的多台云服务器（Elastic Compute Service,简称ECS）资源虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式,将来自客户端的网络请求分发到云服务器池中。
SLB服务会检查云服务器池中ECS的健康状态,自动隔离异常状态的ECS,从而解决了单台ECS的单点问题,同时提高了应用的整体服务能力。在标准的负载均衡功能之外,SLB服务还具备TCP与HTTP抗DDoS攻击的特性,增强了应用服务器的防护能力。
SLB服务是ECS面向多机方案的一个配套服务,需要同ECS结合使用。
1、技术架构
整个负载均衡系统由3部分构成：四层负载均衡、七层负载均衡和控制系统,如下图所示：
四层负载均衡
采用开源软件LVS（Linux Virtual Server）构建,并根据云计算需求对其进行了定制和优化。 七层负载均衡
采用开源软件Tengine构建。 控制系统
用于配置和监控负载均衡系统。
2、LVS技术特点
LVS是全球最流行的四层负载均衡开源软件,可以实现LINUX平台下的负载均衡。
LVS是 基于Linux Netfilter框架实现的一个内核模块（ IPTables是基于Netfilter基本架构实现的一个可扩展的数据报高级管理系统或核外配置工具）,名称为IPVS。其钩子函数分别HOOK在LOCAL_IN和FORWARD两个HOOK点,如下图所示：

在云计算大规模网络环境下,官方LVS存在如下问题： 问题1：LVS支持NAT/DR/TUNNEL三种转发模式,上述模式在多VLAN网络环境下部署时,存在网络拓扑复杂,运维成本高的问题。 问题2：和商用负载均衡设备（如F5等）相比,LVS缺少DDOS攻击防御功能。 问题3：LVS采用PC服务器,常用Keepalived软件的VRRP心跳协议进行主备部署,其性能无法扩展。 问题4：LVS常用管理软件Keepalived的配置和健康检查性能不足。
为了解决上述问题, SLB在官方LVS基础上进行了如下定制化和优化： 解决1：新增转发模式FULLNAT,实现LVS-RealServer间跨VLAN通讯。 解决2：新增了SYNPROXY等TCP标志位DDOS攻击防御功能。 解决3：采用LVS集群方式部署。 解决4：对Keepalived的性能进行了优化。

Aliyun-LVS开源地址： https://github.com/alibaba/LVS 。 更多相关说明如下所述。 FULLNAT技术概述
如下图所示,FULLNAT主要实现方式为： 引入local address（内网IP地址）。cip-vip转换为lip->rip,而 lip和rip均为IDC内网IP,可以跨VLAN通讯。 IN/OUT的数据流全部经过LVS,为了保证带宽,采用万兆（10G）网卡。 FULLNAT转发模式,当前仅支持TCP协议。
SYNPROXY技术概述
LVS针对TCP标志位DDOS攻击,采取如下策略： 对于SYN flood类型攻击,利用SYNPROXY模块进行防御。
如下图所示,主要实现方式为：参照Linux TCP协议栈中SYN cookie的思想,LVS代理TCP三次握手。代理过程：
1) Client发送SYN包给LVS。
2) LVS构造特殊SEQ的SYN ACK包给Client。
3) Client回复ACK给LVS。
4) LVS验证ACK包中ack_seq是否合法。
5) 如果合法,则LVS再和Realserver建立3次握手。
对于ACK/FIN/RSTFlood类型攻击,查找连接表,如果不存在,则直接丢弃。
集群部署方式
LVS集群部署方式实现的主要方式为： LVS和上联交换机间运行OSPF协议。 上联交换机通过ECMP等价路由,将数据流分发给LVS集群。 LVS集群再转发给业务服务器。
集群方式部署极大的保证了异常情况下,负载均衡服务的稳定性： 健壮性
LVS和交换机间运行OSPF心跳。1个VIP配置在集群的所有LVS上。当一台LVS down,交换机会自动发现并将其从ECMP等价路由中剔除。 可扩展
如果当前LVS集群无法支撑某个VIP的流量,LVS集群可以进行水平扩容。
Keepalived优化
阿里云在SLB中针对LVS管理软件Keepalived进行了全面优化,主要包括： 优化了网络异步模型,select方式改为epoll方式。 优化了reload过程。
综上所述,基于LVS的SLB四层负载均衡产品具有如下特点； 高可用：LVS集群保证了冗余性,无单点。 安全：LVS自带攻击防御+云盾,提供了接近于实时防御的能力。 健康检查：SLB对后端ECS进行健康检查,自动屏蔽异常状态的ECS,待该ECS恢复正常后自动解除屏蔽。
3、Tengine技术特点
Tengine是阿里巴巴发起的WEB服务器项目,其在Nginx的基础上,针对大访问量网站的需求,添加了很多高级功能和特性是当前最流行的7层负载均衡开源软件之一。Tengine的性能和稳定性已经在大型的网站如 淘宝网 , 天猫商城 等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。
注：Tengine开源地址http://tengine.taobao.org/。
针对云计算场景,Tengine定制的主要特性如下： 继承Nginx-1.4.6的所有特性,100%兼容Nginx的配置。 动态模块加载（DSO）支持。加入一个模块不再需要重新编译整个Tengine。 更加强大的负载均衡能力,包括一致性Hash模块、会话保持模块,还可以对后端的服务器进行主动健康检查,根据服务器状态自动上线下线。 监控系统的负载和资源占用从而对系统进行保护。 对运维人员更友好的出错信息,便于定位出错机器。 更强大的防攻击（访问速度限制等）模块。
采用Tengine作为SLB的基础模块的阿里云SLB七层负载均衡产品,具有如下特点： 高可用：Tengine集群保证了冗余性,无单点。 安全：多维度的CC攻击防御能力。 健康检查：SLB对后端ECS进行健康检查,自动屏蔽异常状态的ECS,待该ECS恢复正常后自动解除屏蔽。 会话保持：支持7层会话保持功能。 一致性：支持一致性hash调度。
4、更多功能
SLB作为负载均衡设备,其最重要的指标是【稳定性】,在进一步提高稳定性方面,主要工作包括： 支持集群内部 session同步。 采用Anycast技术实现同城双A。
在功能方面有更多支持,包括： 白名单访问控制
从SLB层面实现访问控制,用户可以在SLB系统上配置白名单,便于用户灵活限定外部访问请求。 更多服务协议的支持
当前已经支持HTTPS、UDP。

四层和七层负载均衡的区别

　　 （一）
　　 简单理解四层和七层负载均衡:
　　 ① 所谓四层就是基于IP+端口的负载均衡；七层就是基于URL等应用层信息的负载均衡；同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址；三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址；四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器；七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器。
　　 ② 所谓的四到七层负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量。 比如四层的负载均衡,就是通过发布三层的IP地址（VIP）,然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡,就是在四层的基础上（没有四层是绝对不可能有七层的）,再考虑应用层的特征,比如同一个Web服务器的负载均衡,除了根据VIP加80端口辨别是否需要处理的流量,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,如果你的Web服务器分成两组,一组是中文语言的,一组是英文语言的,那么七层负载均衡就可以当用户来访问你的域名时,自动辨别用户语言,然后选择对应的语言服务器组进行负载均衡处理。
　　 ③ 负载均衡器通常称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层,实现四层流量负载均衡。七层交换机除了支持四层负载均衡以外,还有分析应用层的信息,如HTTP协议URI或Cookie信息。
　　1、负载均衡分为L4 switch（四层交换）,即在OSI第4层工作,就是TCP层啦。此种Load Balance不理解应用协议（如HTTP/FTP/MySQL等等）。例子：LVS,F5。
　　2、另一种叫做L7 switch（七层交换）,OSI的最高层,应用层。此时,该Load Balancer能理解应用协议。例子： haproxy,MySQL Proxy。
　　注意：上面的很多Load Balancer既可以做四层交换,也可以做七层交换。
　　（二）
　　负载均衡设备也常被称为"四到七层交换机",那么四层和七层两者到底区别在哪里？
　　第一,技术原理上的区别。
　　所谓四层负载均衡 ,也就是主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
　　以常见的TCP为例,负载均衡设备在接收到第一个来自客户端的SYN 请求时,即通过上述方式选择一个最佳的服务器,并对报文中目标IP地址进行修改(改为后端服务器IP）,直接转发给该服务器。TCP的连接建立,即三次握手是客户端和服务器直接建立的,负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下,为保证服务器回包可以正确返回给负载均衡设备,在转发报文的同时可能还会对报文原来的源地址进行修改。
　　所 谓七层负载均衡 ,也称为“内容交换”,也就是主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。
　　以常见的TCP为例,负载均衡设备如果要根据真正的应用层内容再选择服务器,只能先代理最终的服务器和客户端建立连接(三次握手)后,才可能接受到客户端发送的真正应用层内容的报文,然后再根据该报文中的特定字段,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。负载均衡设备在这种情况下,更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看,七层负载均衡明显的对负载均衡设备的要求更高,处理七层的能力也必然会低于四层模式的部署方式。
　　第二,应用场景的需求。
　　七层应用负载的好处,是使得整个网络更" 智能化 "。例如访问一个网站的用户流量,可以通过七层的方式,将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例,从技术原理上,这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改,极大的提升了应用系统在网络层的灵活性。很多在后台,例如Nginx或者Apache上部署的功能可以前移到负载均衡设备上,例如客户请求中的Header重写,服务器响应中的关键字过滤或者内容插入等功能。
　　另外一个常常被提到功能就 是 安全性。网络中最常见的SYN Flood攻击,即黑客控制众多源客户端,使用虚假IP地址对同一目标发送SYN攻击,通常这种攻击会大量发送SYN报文,耗尽服务器上的相关资源,以达到Denial of Service( DoS )的目的。从技术原理上也可以看出,四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击自然在负载均衡设备上就截止,不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略,过滤特定报文,例如SQL Injection等应用层面的特定攻击手段,从应用层面进一步提高系统整体安全。
　　现在的7层负载均衡,主要还是着重于 应用 HTTP协议,所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用,例如基于C/S开发的ERP等系统。
　　第三,七层应用需要考虑的问题。
　　1：是否真的必要 ,七层应用的确可以提高流量智能化,同时必不可免的带来设备配置复杂,负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。
　　2：是否真的可以提高安全性 。例如SYN Flood攻击,七层模式的确将这些流量从服务器屏蔽,但负载均衡设备本身要有强大的抗DDoS能力,否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。
　　3：是否有足够的灵活度 。七层应用的优势是可以让整个应用的流量智能化,但是负载均衡设备需要提供完善的七层功能,满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备,可以让客户根据需求任意设定功能,才真正有可能提供强大的灵活性和智能性。
　　（本节出自 “ADC技术博客” 博客,请务必保留此出处http://virtualadc.blog.51cto.com/3027116/591396）
　　（三）
　　负载均衡四七层介绍:
　　负载均衡（Load Balance）建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
　　负载均衡有两方面的含义：首先,大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间；其次,单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给用户,系统处理能力得到大幅度提高。
　　本文所要介绍的负载均衡技术主要是指在均衡服务器群中所有服务器和应用程序之间流量负载的应用,目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。
　　负载均衡技术分类
　　目前有许多不同的负载均衡技术用以满足不同的应用需求,下面从负载均衡所采用的设备对象、应用的网络层次（指OSI参考模型）及应用的地理结构等来分类。
　　软/硬件负载均衡
　　软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡,如DNS Load Balance,CheckPoint Firewall-1 ConnectControl等,它的优点是基于特定环境,配置简单,使用灵活,成本低廉,可以满足一般的负载均衡需求。
　　软件解决方案缺点也较多,因为每台服务器上安装额外的软件运行会消耗系统不定量的资源,越是功能强大的模块,消耗得越多,所以当连接请求特别大的时候,软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好,受到操作系统的限制；由于操作系统本身的Bug,往往会引起安全问题。
　　硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备,这种设备我们通常称之为负载均衡器,由于专门的设备完成专门的任务,独立于操作系统,整体性能得到大量提高,加上多样化的负载均衡策略,智能化的流量管理,可达到最佳的负载均衡需求。
　　负载均衡器有多种多样的形式,除了作为独立意义上的负载均衡器外,有些负载均衡器集成在交换设备中,置于服务器与Internet链接之间,有些则以两块网络适配器将这一功能集成到PC中,一块连接到Internet上,一块连接到后端服务器群的内部网络上。
　　一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵。
　　本地/全局负载均衡
　　负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance,也叫地域负载均衡),本地负载均衡是指对本地的服务器群做负载均衡,全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。
　　本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题,并且不需花费昂贵开支购置性能卓越的服务器,充分利用现有设备,避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充升级,也只是简单地增加一个新的服务器到服务群中,而不需改变现有网络结构、停止现有的服务。
　　全局负载均衡主要用于在一个多区域拥有自己服务器的站点,为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器,从而获得最快的访问速度,也可用于子公司分散站点分布广的大公司通过Intranet（企业内部互联网）来达到资源统一合理分配的目的。
　　网络层次上的负载均衡
　　针对网络上负载过重的不同瓶颈所在,从网络的不同层次入手,我们可以采用相应的负载均衡技术来解决现有问题。
　　随着带宽增加,数据流量不断增大,网络核心部分的数据接口将面临瓶颈问题,原有的单一线路将很难满足需求,而且线路的升级又过于昂贵甚至难以实现,这时就可以考虑采用链路聚合（Trunking）技术。
　　链路聚合技术（第二层负载均衡）将多条物理链路当作一条单一的聚合逻辑链路使用,网络数据流量由聚合逻辑链路中所有物理链路共同承担,由此在逻辑上增大了链路 的 容量,使其能满足带宽增加的需求。
　　现代负载均衡技术通常操作于网络的第四层或第七层。第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址,对每次 TCP连接请求动态使用其中一个内部IP地址,达到负载均衡的目的。在第四层交换机中,此种均衡技术得到广泛的应用,一个目标地址是服务器群VIP（虚拟 IP,Virtual IP address）连接请求的数据包流经交换机,交换机根据源端和目的IP地址、TCP或UDP端口号和一定的负载均衡策略,在服务器IP和VIP间进行映射,选取服务器群中最好的服务器来处理连接请求。
　　第七层负载均衡控制应用层服务的内容,提供了一种对访问流量的高层控制方式,适合对HTTP服务器群的应用。第 七层负载均衡技术通过检查流经的HTTP报头,根据报头内的信息来执行负载均衡任务 。
　　第七层负载均衡优点表现在如下几个方面：
　　通过对HTTP报头的检查,可以检测出HTTP400、500和600系列的错误信息,因而能透明地将连接请求重新定向到另一台服务器,避免应用层故障。
　　可根据流经的数据类型（如判断数据包是图像文件、压缩文件或多媒体文件格式等）,把数据流量引向相应内容的服务器来处理,增加系统性能。
　　能根据连接请求的类型,如是普通文本、图象等静态文档请求,还是asp、cgi等的动态文档请求,把相应的请求引向相应的服务器来处理,提高系统的性能及安全性。
　　第七层负载均衡受到其所支持的协议限制（一般只有HTTP）,这样就限制了它应用的广泛性,并且检查HTTP报头会占用大量的系统资源,势必会影响到系统的性能,在大量连接请求的情况下,负载均衡设备自身容易成为网络整体性能的瓶颈。
　　 负载均衡策略
　　在实际应用中,我们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器,而不管服务器是否宕机。而是想使Pentium III服务器比Pentium II能接受更多的服务请求,一台处理服务请求较少的服务器能分配到更多的服务请求,出现故障的服务器将不再接受服务请求直至故障恢复等等。
　　选择合适的负载均衡策略,使多个设备能很好的共同完成任务,消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中,针对不同的应用需求,在OSI参考模型的第二、三、四、七层的负载均衡都有相应的负载均衡策略。
　　负载均衡策略的优劣及其实现的难易程度有两个关键因素：一、负载均衡算法,二、对网络系统状况的检测方式和能力。
　　考虑到服务请求的不同类型、服务器的不同处理能力以及随机选择造成的负载分配不均匀等问题,为了更加合理的把负载分配给内部的多个服务器,就需要应用相应的能够正确反映各个服务器处理能力及网络状态的 负载均衡算法 ：
　　轮循均衡（Round Robin）：每一次来自网络的请求轮流分配给内部中的服务器,从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
　　权重轮循均衡（Weighted Round Robin）：根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1,B的权值是 3,C的权值是6,则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率,避免低性能的服务器负载过重。
　　随机均衡（Random）：把来自网络的请求随机分配给内部中的多个服务器。
　　权重随机均衡（Weighted Random）：此种均衡算法类似于权重轮循算法,不过在处理请求分担时是个随机选择的过程。
　　响应速度均衡（Response Time）：负载均衡设备对内部各服务器发出一个探测请求（例如Ping）,然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态,但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间,而不是客户端与服务器间的最快响应时间。
　　最少连接数均衡（Least Connection）：客户端的每一次请求服务在服务器停留的时间可能会有较大的差异,随着工作时间加长,如果采用简单的轮循或随机均衡算法,每一台服务器上的连接进程可能会产生极大的不同,并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录,记录当前该服务器正在处理的连接数量,当有新的服务连接请求时,将把当前请求分配给连接数最少的服务器,使均衡更加符合实际情况,负载更加均衡。此种均衡算法适合长时处理的请求服务,如FTP。
　　处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成）最轻的服务器,由于考虑到了内部服务器的处理能力及当前网络运行状况,所以此种均衡算法相对来说更加精确,尤其适合运用到第七层（应用层）负载均衡的情况下。
　　DNS响应均衡（Flash DNS）：在Internet上,无论是HTTP、FTP或是其它的服务请求,客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法下,分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求,并在同一时间内把此域名解析成各自相对应服务器的IP地址（即与此负载均衡设备在同一位地理位置的服务器的IP地址）并返回给客户端,则客户端将以最先收到的域名解析IP地址来继续请求服务,而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下,对本地负载均衡是没有意义的。
　　尽管有多种的负载均衡算法可以较好的把数据流量分配给服务器去负载,但如果负载均衡策略没有对网络系统状况的检测方式和能力,一旦在某台服务器或某段负载均衡设备与服务器网络间出现故障的情况下,负载均衡设备依然把一部分数据流量引向那台服务器,这势必造成大量的服务请求被丢失,达不到不间断可用性的要求。所以良好的负载均衡策略应有对网络故障、服务器系统故障、应用服务故障的检 测方式和能力 ：
　　Ping侦测：通过ping的方式检测服务器及网络系统状况,此种方式简单快速,但只能大致检测出网络及服务器上的操作系统是否正常,对服务器上的应用服务检测就无能为力了。
　　TCP Open侦测：每个服务都会开放某个通过TCP连接,检测服务器上某个TCP端口（如Telnet的23口,HTTP的80口等）是否开放来判断服务是否正常。
　　HTTP URL侦测：比如向HTTP服务器发出一个对main.html文件的访问请求,如果收到错误信息,则认为服务器出现故障。
　　负载均衡策略的优劣除受上面所讲的两个因素影响外,在有些应用情况下,我们需要将来自同一客户端的所有请求都分配给同一台服务器去负担,例如服务器将客户端注册、购物等服务请求信息保存的本地数据库的情况下,把客户端的子请求分配给同一台服务器来处理就显的至关重要了。有两种方式可以解决此问题,一是根据IP地址把来自同一客户端的多次请求分配给同一台服务器处理,客户端IP地址与服务器的对应信息是保存在负载均衡设备上的；二是在客户端浏览器 cookie内做独一无二的标识来把多次请求分配给同一台服务器处理,适合通过代理服务器上网的客户端。
　　还有一种路径外返回模式（Out of Path Return）,当客户端连接请求发送给负载均衡设备的时候,中心负载均衡设备将请求引向某个服务器,服务器的回应请求不再返回给中心负载均衡设备,即绕过流量分配器,直接返回给客户端,因此中心负载均衡设备只负责接受并转发请求,其网络负担就减少了很多,并且给客户端提供了更快的响应时间。此种模式一般用于HTTP服务器群,在各服务器上要安装一块虚拟网络适配器,并将其IP地址设为服务器群的VIP,这样才能在服务器直接回应客户端请求时顺利的达成三次握手。
　　 负载均衡实施要素
　　负载均衡方案应是在网站建设初期就应考虑的问题,不过有时随着访问流量的爆炸性增长,超出决策者的意料,这也就成为不得不面对的问题。当我们在引入某种负载均衡方案乃至具体实施时,像其他的许多方案一样,首先是确定当前及将来的应用需求,然后在代价与收效之间做出权衡。
　　针对当前及将来的应用需求,分析网络瓶颈的不同所在,我们就需要确立是采用哪一类的负载均衡技术,采用什么样的均衡策略,在可用性、兼容性、安全性等等方面要满足多大的需求,如此等等。
　　不管负载均衡方案是采用花费较少的软件方式,还是购买代价高昂在性能功能上更强的第四层交换机、负载均衡器等硬件方式来实现,亦或其他种类不同的均衡技术,下面这几项都是我们在引入均衡方案时可能要考虑的问题：
　　性能：性能是我们在引入均衡方案时需要重点考虑的问题,但也是一个最难把握的问题。衡量性能时可将每秒钟通过网络的数据包数目做为一个参数,另一个参数是均衡方案中服务器群所能处理的最大并发连接数目,但是,假设一个均衡系统能处理百万计的并发连接数,可是却只能以每秒2个包的速率转发,这显然是没有任何作用的。性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关,并且有两点需要注意：一、均衡方案对服务器群整体的性能,这是响应客户端连接请求速度的关键；二、负载均衡设备自身的性能,避免有大量连接请求时自身性能不足而成为服务瓶颈。有时我们也可以考虑采用混合型负载均衡策略来提升服务器群的总体性能,如DNS负载均衡与NAT负载均衡相结合。另外,针对有大量静态文档请求的站点,也可以考虑采用高速缓存技术,相对来说更节省费用,更能提高响应性能；对有大量ssl/xml内容传输的站点,更应考虑采用ssl/xml加速技术。
　　可扩展性：IT技术日新月异,一年以前最新的产品,现在或许已是网络中性能最低的产品；业务量的急速上升,一年前的网络,现在需要新一轮的扩展。合适的均衡解决方案应能满足这些需求,能均衡不同操作系统和硬件平台之间的负载,能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不同服务器的负载,并且能以对客户端完全透明的方式动态增加或删除某些资源。
　　灵活性：均衡解决方案应能灵活地提供不同的应用需求,满足应用需求的不断变化。在不同的服务器群有不同的应用需求时,应有多样的均衡策略提供更广泛的选择。
　　可靠性：在对服务质量要求较高的站点,负载均衡解决方案应能为服务器群提供完全的容错性和高可用性。但在负载均衡设备自身出现故障时,应该有良好的冗余解决方案,提高可靠性。使用冗余时,处于同一个冗余单元的多个负载均衡设备必须具有有效的方式以便互相进行监控,保护系统尽可能地避免遭受到重大故障的损失。
　　易管理性：不管是通过软件还是硬件方式的均衡解决方案,我们都希望它有灵活、直观和安全的管理方式,这样便于安装、配置、维护和监控,提高工作效率,避免差错。在硬件负载均衡设备上,目前主要有三种管理方式可供选择：一、命令行接口（CLI：Command Line Interface）,可通过超级终端连接负载均衡设备串行接口来管理,也能telnet远程登录管理,在初始化配置时,往往要用到前者；二、图形用户接口（GUI：Graphical User Interfaces）,有基于普通web页的管理,也有通过Java Applet 进行安全管理,一般都需要管理端安装有某个版本的浏览器；三、SNMP（Simple Network Management Protocol,简单网络管理协议）支持,通过第三方网络管理软件对符合SNMP标准的设备进行管理。


lvs、haproxy、nginx 负载均衡的比较分析
对软件实现 负载均衡 的几个软件,小D详细看了一下,从性能和稳定上还是LVS最牛,基本达到了F5硬件设备的60%性能,其他几个10%都有点困难。
不过就因为LVS忒牛了,配置也最麻烦了,而且健康检测需要另外配置Ldirector,其他HAPROXY和NGINX自己就用,而且配置超级简单。



所以小D建议,如果网站访问量不是门户级别的用HAPROXY或者NGINX就OK了,到了门户级别在用LVS+Idirector吧 哈哈
lvs和nginx都可以用作多机负载的方案,它们各有优缺,在生产环境中需要好好分析实际情况并加以利用。
首先提醒,做技术切不可人云亦云,我云即你云；同时也不可太趋向保守,过于相信旧有方式而等别人来帮你做垫被测试。把所有即时听说到的好东西加以钻研,从而提高自己对技术的认知和水平,乃是一个好习惯。
下面来分析一下两者：
一、lvs的优势：
1、抗负载能力强,因为lvs工作方式的逻辑是非常之简单,而且工作在网络4层仅做请求分发之用,没有流量,所以在效率上基本不需要太过考虑。在我手里的 lvs,仅仅出过一次问题：在并发最高的一小段时间内均衡器出现丢包现象,据分析为网络问题,即网卡或linux2.4内核的承载能力已到上限,内存和 cp u方面基本无消耗。
2、配置性低,这通常是一大劣势,但同时也是一大优势,因为没有太多可配置的选项,所以除了增减服务器,并不需要经常去触碰它,大大减少了人为出错的几率。
3、工作稳定,因为其本身抗负载能力很强,所以稳定性高也是顺理成章,另外各种lvs都有完整的双机热备方案,所以一点不用担心均衡器本身会出什么问题,节点出现故障的话,lvs会自动判别,所以系统整体是非常稳定的。
4、无流量,上面已经有所提及了。lvs仅仅分发请求,而流量并不从它本身出去,所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5、基本上能支持所有应用,因为lvs工作在4层,所以它可以对几乎所有应用做负载均衡,包括http、数据库、聊天室等等。
另：lvs也不是完全能判别节点故障的,譬如在wlc分配方式下, 集群 里有一个节点没有配置VIP,会使整个集群不能使用,这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以,用lvs也得多多当心为妙。
二、nginx和lvs作对比的结果
1、nginx工作在网络的7层,所以它可以针对http应用本身来做分流策略,比如针对域名、目录结构等,相比之下lvs并不具备这样的功能,所以 nginx单凭这点可利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs,所以经常要去触碰触碰,由lvs的第2条优点 看,触碰多了,人为出问题的几率也就会大。
2、nginx对网络的依赖较小,理论上只要 ping 得通,网页访问正常,nginx就能连得通,nginx同时还能区分内外网,如果是同时拥有内外网的 节点,就相当于单机拥有了备份线路；lvs就比较依赖于网络环境,目前来看服务器在同一网段内并且lvs使用direct方式分流,效果较能得到保证。另 外注意,lvs需要向托管商至少申请多一个ip来做Vi su al IP,貌似是不能用本身的IP来做VIP的。要做好LVS管理员,确实得跟进学习很多有关网络通信方面的知识,就不再是一个HTTP那么简单了。
3、nginx安装和配置比较简单,测试起来也很方便,因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间了,因为同上所述,lvs对网络依赖比较大,很多时候不能配置成功都是因为网络问题而不是配置问题,出了问题要解决也相应的会麻烦得多。
4、nginx也同样能承受很高负载且稳定,但负载度和稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案,所以跑在单机上还是风险较大,单机上的事情全都很难说。
5、nginx可以检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点。目前lvs中 ldirectd也能支持针对服务器内部的情况来监控,但lvs的原理使其不能重发请求。重发请求这点,譬如用户正在上传一个文件,而处理该上传的节点刚 好在上传过程中出现故障,nginx会把上传切到另一台服务器重新处理,而lvs就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能 会因此而恼火。
6、nginx对请求的异步处理可以帮助节点服务器减轻负载,假如使用apache直接对外服务,那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放,使用多一个nginx做apache代理的话,这些窄带链接会被nginx挡住,apache上就不会堆积过多的请求,这样就减少了相 当多的内存占用。这点使用squ id 也有相同的作用,即使squid本身配置为不缓存,对apache还是有很大帮助的。lvs没有这些功能,也就无法能 比较。
7、nginx能支持http和email（email的功能估计比较少人用）,lvs所支持的应用在这点上会比nginx更多。
在使用上,一般最前端所采取的策略应是lvs,也就是DNS的指向应为lvs均衡器,lvs的优点令它非常适合做这个任务。
重要的ip地址,最好交由lvs托管,比如数据库的ip、webservice服务器的ip等等,这些ip地址随着时间推移,使用面会越来越大,如果更换ip则故障会接踵而至。所以将这些重要ip交给lvs托管是最为稳妥的,这样做的唯一缺点是需要的VIP数量会比较多。
nginx可作为lvs节点机器使用,一是可以利用nginx的功能,二是可以利用nginx的性能。当然这一层面也可以直接使用squid,squid的功能方面就比nginx弱不少了,性能上也有所逊色于nginx。
nginx也可作为中层代理使用,这一层面nginx基本上无对手,唯一可以撼动nginx的就只有lig httpd 了,不过lighttpd目前还没有 能做到nginx完全的功能,配置也不那么清晰易读。另外,中层代理的IP也是重要的,所以中层代理也拥有一个VIP和lvs是最完美的方案了。
nginx也可作为网页静态服务器,不过超出了本文讨论的范畴,简单提一下。

具体的应用还得具体分析,如果是比较小的网站（日PV<1000万）,用nginx就完全可以了,如果机器也不少,可以用DNS轮询,lvs所耗费的机器还是比较多的；大型网站或者重要的服务,机器不发愁的时候,要多多考虑利用lvs。
****************************************************************************************************************
Nginx的优点:
性能好,可以负载超过1万的并发。
功能多,除了负载均衡,还能作Web服务器,而且可以通过Geo模块来实现流量分配。
社区活跃,第三方补丁和模块很多
支持g zip proxy
缺点:
不支持session保持。
对后端rea ls erver的健康检查功能效果不好。而且只支持通过端口来检测,不支持通过url来检测。
nginx对big request header的支持不是很好,如果client_header_buffer_size设置的比较小,就会返回400bad request页面。
Haproxy的优点:
它的优点正好可以补充nginx的缺点。支持session保持,同时支持通过获取指定的url来检测后端服务器的状态。
支持tcp模式的负载均衡。比如可以给 MySQL 的从服务器集群和邮件服务器做负载均衡。
缺点：
不支持虚拟主机(这个很傻啊)
目前没有nagios和cacti的性能监控模板
LVS的优点:
性能好,接近硬件设备的网络吞吐和连接负载能力。
LVS的DR模式,支持通过广域网进行负载均衡。这个其他任何负载均衡软件目前都不具备。
缺点：
比较重型。另外社区不如nginx活跃。
*************************************************************************************

现在网络中常见的的负载均衡主要分为两种：一种是通过硬件来进行进行,常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器,也有类似于LVS、Nginx、HAproxy的基于 Linux 的开源的负载均衡策略,
商用负载均衡里面NetScaler从效果上比F5的效率上更高。对于负载均衡器来说,不过商用负载均衡由于可以建立在四~七层协议之上,因此适用 面更广所以有其不可替代性,他的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用。
另一种负载均衡的方式是通过软件：比较常见的有LVS、Nginx、HAproxy等,其中LVS是建立在四层协议上面的,而另外Nginx和HAproxy是建立在七层协议之上的,下面分别介绍关于
LVS：使用集群技术和Linux 操作系统 实现一个高性能、高可用的服务器,它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
LVS的特点是：
1、抗负载能力强、是工作在网络4层之上仅作分发之用,没有流量的产生；
2、配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率；
3、工作稳定,自身有完整的双机热备方案；
4、无流量,保证了均衡器IO的性能不会收到大流量的影响；
5、应用范围比较广,可以对所有应用做负载均衡；
6、LVS需要向IDC多申请一个IP来做Visual IP,因此需要一定的网络知识,所以对操作人的要求比较高。
Nginx的特点是：
1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构；
2、Nginx对网络的依赖比较小；
3、Nginx安装和配置比较简单, 测试 起来比较方便；
4、也可以承担高的负载压力且稳定,一般能支撑超过1万次的并发；
5、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测；
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载；
7、Nginx能支持http和Email,这样就在适用范围上面小很多；
8、不支持Session的保持、对Big request header的支持不是很好,另外默认的只有Round-robin和IP-hash两种负载均衡 算法 。
HAProxy的特点是：
1、HAProxy是工作在网络7层之上。
2、能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
3、支持url检测后端的服务器出问题的检测会有很好的帮助。
4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
6、HAProxy可以对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡。
***********************************************************************************************

现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：
第一阶段：利用Nginx或者HAProxy进行单点的负载均衡,这一阶段服务器规模刚脱离开单服务器、单 数据库 的模式,需要一定的负载均衡,但是 仍然规模较小没有专业的维护团队来进行维护,也没有需要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择,此时这些东西上手快, 配置容易,在七层之上利用HTTP协议就可以。这时是第一选择
第二阶段：随着网络服务进一步扩大,这时单点的Nginx已经不能满足,这时使用LVS或者商用F5就是首要选择,Nginx此时就作为LVS或者 F5的节点来使用,具体LVS或者F5的是选择是根据公司规模,人才以及资金能力来选择的,这里也不做详谈,但是一般来说这阶段相关人才跟不上业务的提 升,所以购买商业负载均衡已经成为了必经之路。
第三阶段：这时网络服务已经成为主流产品,此时随着公司知名度也进一步扩展,相关人才的能力以及数量也随之提升,这时无论从开发适合自身产品的定制,以及降低成本来讲开源的LVS,已经成为首选,这时LVS会成为主流。
最终形成比较理想的状态为：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。


LVS：三种负载均衡方式比较

1、什么是 LVS ？
　　首先简单介绍一下LVS ( Linux Virtual Server)到底是什么东西,其实它是一种集群(Cluster)技术,采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的 服务器 上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。
　　为此,在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说,LVS集
　　群采用三层结构,其体系结构如图所示：
　　LVS集群的体系结构
　　2、LVS主要组成部分为：
　　负载调度器(load balancer/ Director ),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个IP地址(我们可称之为虚拟IP地址)上的。
　　服务器池(server pool/ Realserver),是一组真正执行客户请求的服务器,执行的服务一般有WEB、MAIL、 FTP 和DNS等。
　　共享 存储 (shared storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。
　　3、LVS负载均衡方式:
　　◆Virtual Server via Network Address Translation NAT(VS/NAT)
　　VS/NAT是一种最简单的方式,所有的RealServer只需要将自己的 网关 指向Director即可。客户端可以是任意 操作系统 ,但此方式下,一个Director能够带动的RealServer比较有限。在VS/NAT的方式下,Director也可以兼为一台RealServer。VS/NAT的体系结构如图所示。
　　VS/NAT的体系结构
　　◆Virtual Server via IP Tunneling(VS/TUN)
　　IP隧道(IP tunneling)是将一个IP报文 封装 在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个IP地址,另一端也有唯一的IP地址。它的连接调度和管理与VS/NAT中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况,动态地选择一台服务器,将请求报文封装在另一个IP报文中,再将封装后的IP报文转发给选出的服务器;服务器收到报文后,先将报文解封获得原来目标地址为 VIP 的报文,服务器发现VIP地址被配置在本地的IP隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。
　　VS/TUN的体系结构
　　VS/TUN的工作流程：
　　◆Virtual Server via Direct Routing(VS/DR)
　　VS/DR方式是通过改写请求报文中的 MAC 地址部分来实现的。Director和RealServer必需在物理上有一个网卡通过不间断的 局域网 相连。 RealServer上绑定的VIP配置在各自Non- ARP 的网络设备上(如lo或tunl),Director的VIP地址对外可见,而RealServer的VIP对外是不可见的。RealServer的地址即可以是内部地址,也可以是真实地址。
　　VS/DR的体系结构
　　VS/DR的工作流程
　　VS/DR的工作流程如图所示：它的连接调度和管理与VS/NAT和VS/TUN中的一样,它的报文转发方法又有不同,将报文直接路由给目标服务器。在VS/DR中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。
　　VS/DR的工作流程
　　4、三种负载均衡方式比较：
　　◆Virtual Server via NAT
　　VS/NAT 的优点是服务器可以运行任何支持 TCP/IP 的操作系统,它只需要一个IP地址配置在调度器上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限,当服务器结点数目升到20时,调度器本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载调度器。我们在Pentium166 处理器 的主机上测得重写报文的平均延时为60us, 性能更高 的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes,则调度器的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s,这样一个调度器可以带动10台服务器。(注：这是很早以前测得的数据)
　　基于 VS/NAT的的集群系统可以适合许多服务器的性能要求。如果负载调度器成为系统新的瓶颈,可以有三种方法解决这个问题：混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中,有若干个VS/NAT负调度器,每个负载调度器带自己的服务器集群,同时这些负载调度器又通过RR-DNS组成简单的 域名 。
　　但VS/TUN和VS/DR是提高系统吞吐量的更好方法。
　　对于那些将IP地址或者端口号在报文数据中传送的网络服务,需要编写相应的应用 模块 来转换报文数据中的IP地址或者端口号。这会带来实现的工作量,同时应用模块检查报文的开销会降低系统的吞吐率。
　　◆Virtual Server via IP Tunneling
　　在VS/TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。这样,负载调度器就可以处理大量的请求,它甚至可以调度百台以上的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡,整个系统的最大吞吐量可超过 1Gbps。所以,VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器,而它本身不会成为系统的瓶颈,可以用来构建高性能的超级服务器。VS/TUN技术对服务器有要求,即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前,VS/TUN的后端服务器主要运行Linux操作系统,我们没对其他操作系统进行测试。因为“IP Tunneling”正成为各个操作系统的标准协议,所以VS/TUN应该会适用运行其他操作系统的后端服务器。
　　◆Virtual Server via Direct Routing
　　跟VS/TUN方法一样,VS/DR调度器只处理客户到服务器端的连接,响应数据可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。跟VS/TUN相比,这种方法没有IP隧道的开销,但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备(或者设备别名)不作ARP响应,或者能将报文重定向(Redirect)到本地的Socket端口上。
　　三种LVS负载均衡技术的优缺点归纳以下表：
　　VS/NATVS/TUNVS/DR
　　服务器操作系统任意支持隧道多数(支持Non-arp)
　　服务器网络私有网络局域网/广域网局域网
　　服务器数目(100M网络)10~20100大于100
　　服务器网关负载均衡器自己的路由自己的路由
　　效率一般高最高
　　注：以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡,调度器的硬件配置与后端服务器的硬件配置相同,而且是对一般Web服务。使 用更高的硬件配置(如千兆网卡和更快的处理器)作为调度器,调度器所能调度的服务器数量会相应增加。当应用不同时,服务器的数目也会相应地改变。所以,以上数据估计主要是为三种方法的伸缩性进行量化比较。
　　5、负载均衡调度算法
　　◆最少的连接方式(Least Connection)：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配, 直到其恢复正常。
　　◆最快模式(Fastest)：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
　　◆观察模式(Observed)：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
　　◆预测模式(Predictive)：BIG-IP利用收集到的服务器当前的性能指标,进行预测分析,选择一台服务器在下一个时间片内,其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)
　　◆动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和 应用服务 器的各项性能参数,动态调整流量分配。
　　◆动态服务器补充(Dynamic Server Act.):当主服务器群中因故障导致数量减少时,动态地将备份服务器补充至主服务器群。
　　◆服务质量(QoS):按不同的优先级对数据流进行分配。
　　◆服务类型(ToS): 按不同的服务类型(在Type of Field中标识)负载均衡对数据流进行分配。
　　◆规则模式：针对不同的数据流设置导向规则,用户可自行


1、什么是 LVS ？
　　首先简单介绍一下LVS ( Linux Virtual Server)到底是什么东西,其实它是一种集群(Cluster)技术,采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的 服务器 上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。
　　为此,在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说,LVS集
　　群采用三层结构,其体系结构如图所示：
　　LVS集群的体系结构
　　2、LVS主要组成部分为：
　　负载调度器(load balancer/ Director ),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个IP地址(我们可称之为虚拟IP地址)上的。
　　服务器池(server pool/ Realserver),是一组真正执行客户请求的服务器,执行的服务一般有WEB、MAIL、 FTP 和DNS等。
　　共享 存储 (shared storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。
　　3、LVS负载均衡方式:
　　◆Virtual Server via Network Address Translation NAT(VS/NAT)
　　VS/NAT是一种最简单的方式,所有的RealServer只需要将自己的 网关 指向Director即可。客户端可以是任意 操作系统 ,但此方式下,一个Director能够带动的RealServer比较有限。在VS/NAT的方式下,Director也可以兼为一台RealServer。VS/NAT的体系结构如图所示。
　　VS/NAT的体系结构
　　◆Virtual Server via IP Tunneling(VS/TUN)
　　IP隧道(IP tunneling)是将一个IP报文 封装 在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个IP地址,另一端也有唯一的IP地址。它的连接调度和管理与VS/NAT中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况,动态地选择一台服务器,将请求报文封装在另一个IP报文中,再将封装后的IP报文转发给选出的服务器;服务器收到报文后,先将报文解封获得原来目标地址为 VIP 的报文,服务器发现VIP地址被配置在本地的IP隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。
　　VS/TUN的体系结构
　　VS/TUN的工作流程：
　　◆Virtual Server via Direct Routing(VS/DR)
　　VS/DR方式是通过改写请求报文中的 MAC 地址部分来实现的。Director和RealServer必需在物理上有一个网卡通过不间断的 局域网 相连。 RealServer上绑定的VIP配置在各自Non- ARP 的网络设备上(如lo或tunl),Director的VIP地址对外可见,而RealServer的VIP对外是不可见的。RealServer的地址即可以是内部地址,也可以是真实地址。
　　VS/DR的体系结构
　　VS/DR的工作流程
　　VS/DR的工作流程如图所示：它的连接调度和管理与VS/NAT和VS/TUN中的一样,它的报文转发方法又有不同,将报文直接路由给目标服务器。在VS/DR中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。
　　VS/DR的工作流程
　　4、三种负载均衡方式比较：
　　◆Virtual Server via NAT
　　VS/NAT 的优点是服务器可以运行任何支持 TCP/IP 的操作系统,它只需要一个IP地址配置在调度器上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限,当服务器结点数目升到20时,调度器本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载调度器。我们在Pentium166 处理器 的主机上测得重写报文的平均延时为60us, 性能更高 的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes,则调度器的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s,这样一个调度器可以带动10台服务器。(注：这是很早以前测得的数据)
　　基于 VS/NAT的的集群系统可以适合许多服务器的性能要求。如果负载调度器成为系统新的瓶颈,可以有三种方法解决这个问题：混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中,有若干个VS/NAT负调度器,每个负载调度器带自己的服务器集群,同时这些负载调度器又通过RR-DNS组成简单的 域名 。
　　但VS/TUN和VS/DR是提高系统吞吐量的更好方法。
　　对于那些将IP地址或者端口号在报文数据中传送的网络服务,需要编写相应的应用 模块 来转换报文数据中的IP地址或者端口号。这会带来实现的工作量,同时应用模块检查报文的开销会降低系统的吞吐率。
　　◆Virtual Server via IP Tunneling
　　在VS/TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。这样,负载调度器就可以处理大量的请求,它甚至可以调度百台以上的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡,整个系统的最大吞吐量可超过 1Gbps。所以,VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器,而它本身不会成为系统的瓶颈,可以用来构建高性能的超级服务器。VS/TUN技术对服务器有要求,即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前,VS/TUN的后端服务器主要运行Linux操作系统,我们没对其他操作系统进行测试。因为“IP Tunneling”正成为各个操作系统的标准协议,所以VS/TUN应该会适用运行其他操作系统的后端服务器。
　　◆Virtual Server via Direct Routing
　　跟VS/TUN方法一样,VS/DR调度器只处理客户到服务器端的连接,响应数据可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。跟VS/TUN相比,这种方法没有IP隧道的开销,但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上,服务器网络设备(或者设备别名)不作ARP响应,或者能将报文重定向(Redirect)到本地的Socket端口上。
　　三种LVS负载均衡技术的优缺点归纳以下表：
　　VS/NATVS/TUNVS/DR
　　服务器操作系统任意支持隧道多数(支持Non-arp)
　　服务器网络私有网络局域网/广域网局域网
　　服务器数目(100M网络)10~20100大于100
　　服务器网关负载均衡器自己的路由自己的路由
　　效率一般高最高
　　注：以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡,调度器的硬件配置与后端服务器的硬件配置相同,而且是对一般Web服务。使 用更高的硬件配置(如千兆网卡和更快的处理器)作为调度器,调度器所能调度的服务器数量会相应增加。当应用不同时,服务器的数目也会相应地改变。所以,以上数据估计主要是为三种方法的伸缩性进行量化比较。
　　5、负载均衡调度算法
　　◆最少的连接方式(Least Connection)：传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配, 直到其恢复正常。
　　◆最快模式(Fastest)：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
　　◆观察模式(Observed)：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。
　　◆预测模式(Predictive)：BIG-IP利用收集到的服务器当前的性能指标,进行预测分析,选择一台服务器在下一个时间片内,其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)
　　◆动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和 应用服务 器的各项性能参数,动态调整流量分配。
　　◆动态服务器补充(Dynamic Server Act.):当主服务器群中因故障导致数量减少时,动态地将备份服务器补充至主服务器群。
　　◆服务质量(QoS):按不同的优先级对数据流进行分配。
　　◆服务类型(ToS): 按不同的服务类型(在Type of Field中标识)负载均衡对数据流进行分配。
　　◆规则模式：针对不同的数据流设置导向规则,用户可自行
分享阿里云SLB-负载均衡的实现基本原理架构
标签： base 量化 ssi tin 优缺点 ushare 就会 七层 and
原文地址：http://www.cnblogs.com/micro-chen/p/6697889.html

「深度学习福利」大神带你进阶工程师,立即查看>>>
这个页面中的相关平台中的内容是不被支持的。因此,Atlassian 支持 不能保证能够为你提供任何支持 。请注意,这个页面下面提供的信息仅为你提供参考同时也不能保证所有的的配置能正常工作。如果你按照本页面中的内容进行配置,所有的风险自负。
一些 Confluence 的宏,例如 {rss} 和 {jiraissues} 需要向外部的服务器发起请求并且获得数据。如果 Confluence 是部署在数据库中心或者 DMZ 中的话,你可能不能访问互联网来获得需要的数据完成请求。如果你发现 {rss} 宏不能正常工作,请询问你的网络管理员,或者可能 Confluence 需要通过代理才能访问外部数据。
在 Confluence 中配置外部 HTTP 代理
Proxy 的支持是通过在启动的时候传递一些 system properties 到 Java 虚拟机中（Java Virtual Machine）。 http.proxyHostConfl http.proxyPort (default: 80) http.nonProxyHosts (default: ) https.proxyHost https.proxyPort
在最小的配置情况,你需要在 HTTP 代理中配置定义 http.proxyHost 和 https.proxyHost 来配置 HTTPS 的代理。系统属性的配置在 Configuring System Properties 页面中进行描述。
属性 http.proxyHost 和 http.proxyPort 确定了 http 协议处理中将会使用代理服务器和代理服务器使用的端口。同时, https.proxyHost 和 https.proxyPort 同时也为 https 协议以处理中定义的相同的参数。 -Dhttp.proxyHost=proxy.example.org -Dhttp.proxyPort=8080 -Dhttps.proxyHost=proxy.example.org -Dhttps.proxyPort=8080
属性 http.nonProxyHosts 确定了应该直接连接的主机和不通过的代理服务器。这个值可以为主机（hosts）的列表。每一个主机通过 | 字符进行分割。如果你想进行更进一步的配置,你可以使用通配符（*）来进行匹配。
例如： -Dhttp.nonProxyHosts=*.foo.com|localhost
I如果你现在正在使用的是 Confluence 6.0 或者更新的版本,同时使用了 Synchrony,你需要传递下面的参数来确定 Confluence 可以直接连接到 Synchrony。替代 localhost|127.0.0.1 为你的 Synchrony IP 地址,如果你使用了 synchrony.host system property 来修改 Synchrony 使用的 IP 地址。

-Dhttp.nonProxyHosts=localhost | 127.0 . 0.1 -Dhttps.nonProxyHosts=localhost | 127.0 . 0.1

备注：你可能需要在命令行中忽略 | 字符串。
如果 http.nonProxyHosts 属性没有被配置的话,所有的 web 请求将会发送到代理上。
请注意,所有从处理列表中设置的任何命令行参数和和任何人通过适当的访问来访问代理的信息可能为空。为了避免这个问题,你可以设置这些属性在 catalina.properties 文件中。这个文件位于 confluence-install/conf/ 目录中。添加配置参数到这个文件的末尾：

http.proxyHost=yourProxyURL http.proxyPort=yourProxyPort http.proxyUser=yourUserName http.proxyPassword=yourPassword https.proxyHost=yourProxyURL https.proxyPort=yourProxyPort https.proxyUser=yourUserName https.proxyPassword=yourPassword

配置 HTTP 代理授权
代理授权同时也通过提供 system properties 进行配置,这个配置文件是在你的应用程序配置文件中进行配置的。主要是通过下面 2 个参数进行配置： http.proxyUser – username http.proxyPassword – secret
HTTP 代理（Microsoft ISA）NTLM 授权
当 Confluence 运行在 Window 服务器环境下的时候,Confluence 能够支持 NTLM 授权为你的外部访问流量（outbound ）HTTP 提供代理支持。
这个意思是如果你的 Confluence 服务器是可以通过 Windows 收取的方式访问外部数据,例如可以访问外部数据的宏 {rss} 和 {jiraissues} 。这个支持与与 Confluence 用户登录授权自动使用 NTLM 是不同的。这个授权是通过用户贡献授权使用的。
为了你的 HTTP 代理授权配置配置 NTLM,你需要定义一个域名属性,在 system property 中, http.auth.ntlm.domain,你可能还需要配置更多的一些配置包括有用户名,端口等。 -Dhttp.auth.ntlm.domain=MYDOMAIN
配置授权序列
有些时候在 HTTP 代理中需要提供多授权模式。如果你收到了授权失败的错误信息,你应该首先检查的是你的用户名和密码,然后在检查代理失败的 HTTP headers 信息（本文档对如何进行调试不进行说明,请搜索参考其他的文章）。
希望对多授权模式的授权序列进行测试,你可以设置 system property 中的 http.proxyAuth 参数,使用逗号分隔授权方法。可以用的授权方法为：ntlm,digest 和 basic；这些方法也是默认的授权方法使用的授权序列。
例如：希望尝试在 NTLM 收取之前尝试基本的收取,同时避免对整个授权方法进行诊断。你可以设置 http.proxyAuth 属性为下面的值： -Dhttp.proxyAuth=basic,ntlm -Dhttps.proxyAuth=basic,ntlm
问题解决 这里有一个诊断使用的 JSP 文件,在 CONF-9719 定义了连接使用的参数。 ' Status Code [407]' 错误在 APR-160 中描述。 不支持 Autoproxies。请参考 CONF-16941 。

https://www.cwiki.us/display/CONF6ZH/Configuring+Web+Proxy+Support+for+Confluence

「深度学习福利」大神带你进阶工程师,立即查看>>>
操作系统：Mac OSX
列选择 鼠标中键 //方式一 alt + 鼠标左键 //方式二
加 command 键后,可以实现并联列选择 command + 鼠标中键 //方式一 command + alt + 鼠标左键 //方式二
快速查找下一项 command + D
替换
启动替换快捷键 command + shift + F
带正则的替换
如下图配置所示：
带参数的替换
如下图配置所示：

「深度学习福利」大神带你进阶工程师,立即查看>>>
云智慧压测实战分享之JMeter工具使用初探

「深度学习福利」大神带你进阶工程师,立即查看>>>
这个文档是针对 Confluence 的系统管理员希望对 Confluence Web应用程序安全性进行评估而设计的。这个页面将对系统的安全进行大致的描述,同时也会对 Confluence 的安全配置提供建议。作为一个向公众开放的 Web 应用程序,Confluence 的应用程序级别的安全是非常重要的。这个页面同时也对使用我们产品的用户经常可能会问到的一些安全问题进行说明。
你可能希望参考的一些其他的主题： 有关用户管理,用户组,用户权限的更多信息,请参考 Permissions and restrictions 页面中的内容。 针对有关你的 Confluence 站点安全配置的指导指南,请参考 Configuring Confluence Security 页面中的内容。
应用程序安全概述
密码存储
当 Confluence 的内部用户管理被使用以后,从 Confluence 3.5 版本开始,用户的密码将会使用 PKCS5S2 implementation provided by Embedded Crowd 哈希加密算法加密后存储到数据库中。 在 Confluence 中将会没有其他机制能够获得用户的密码——除了通过密码重置的方法,一个重置密码的电子邮件链接将会发送到用户注册使用的电子邮件地址中。
当外部的用户管理被启用后,用户的密码将会存储在外部用户管理系统中。
换从区溢出
Confluence 100% 的纯 Java 应用程序而没有使用本地组件。因此应用程序对缓冲区溢出有比较强抵抗力——可能的缓冲区溢出将会被限制在 Java 运行环境（Java Runtime Environment）本身。
SQL 注入
Confluence 是通过 Hibernate Object-Relational 映射进行交互的。数据库的查询使用标准的 APIs 来生成,是使用参数进行替换的,而不是使用字符串连接的的。因此,Confluence 能够具有很高的 SQL 注入攻击抵抗性。
脚本（Script ）注入
Confluence 是一个自容器的 Java 应用程序,并不能运行在外部的进程中。因此 Confluence 能够对脚本注入攻击具有很高的抵抗性。
跨站点脚本
作为一个内容管理系统,允许用户能够在系统中创建内容,并且将创建的内容发布在网络上。我们将会对跨站点脚本攻击进行更多的关注： Confluence 中的 Wiki 标记语言不支持危险 HTML 标记 在默认的情况下,你不能向宏中插入 原生 HTML 标记 HTML 作为附件上传到服务器上话,这个文件将会在下载的时候保存为 content-type 类型,而不是在浏览器中显示。 只有系统管理员级别的用户才可以对应用程序进行 HTML-level 级别的自定义
当跨平台脚本安全漏洞在 Confluence 被发现后,我们将会以最快的速度对这个漏洞进行修复。
传输层安全
Confluence 并不直接支持 SSL/TLS。Confluence 的管理员如果对传输层安全性有所顾虑的话,应该考虑在 Java 应用服务器级别设置 SSL/TLS 或者在 Confluence 应用服务器前面使用 HTTP 方向代理。
有关如何在 Confluence 中配置 SSL 的信息,请参考 Running Confluence Over SSL or HTTPS 页面中的内容。
会话管理
Confluence 使用 Java 应用服务器的会话管理。在现有的情况下,我们并没有获得任何有关会话劫持针对 Confluence 的攻击。如果你现在正在将 Confluence 部署到其他的一些应用服务器上,你应该确保会话不会被劫持。
插件安全
管理员在 Confluence 安装第三方插件所带来的风险为 自负风险（ at their own risk）。 安装的插件将会与 Confluence 在相同的虚拟机上运行,同时也能够访问所有的 Java Runtime 环境,包括 Confluence 服务器 API。
管理员在 Confluence 安装插件的时候应该对插件的来源进行校验,确保安装的插件来源。
管理员信任模型
Confluence 是基于所有具有 System Administrator privileges 都是可以被信任的。系统管理员可以直接安装插件,对 Confluence 的性能和配置进行调整。
与其他任何应用程序一样,你不应该将 Confluence 在 root/Administrator 用户权限运行。如果你希望你的 Confluence 监听私有的网络端口,你应该配置 Confluence 使用端口转移（port forwarding）或者使用反向代理,而不是给 Confluence 添加其他的权限。当你考虑让 Confluence 在 chroot 下运行的话,你需要非常小心。
堆栈跟踪
希望对 Confluence 的问题进行调试,当出现问题的时候 Confluence 将会在界面中提供错误的堆栈信息。这些堆栈的信息包括了 Confluence 在运行的时候的信息,同时还包括了有关你开发服务器的一些信息。
只有非个人信息在堆栈中显示,例如操作系统的版本和 Java 的版本。针对正确的网络设置,这些信息将会不足够对错误的问题进行诊断。用户的用户名和密码将不会显示出来。
https://www.cwiki.us/display/CONF6ZH/Confluence+Security+Overview+and+Advisories

「深度学习福利」大神带你进阶工程师,立即查看>>>
详细配置指南
更多有关连接器示例,我们提供了一些按步骤配置的指南来帮助你启用 HTTPS 并正确配置你的代理。
HTTPS： Running Confluence Over SSL or HTTPS （在 Tomcat 中配置 HTTPS） Running Confluence behind NGINX with SSL （在你的代理中配置 HTTPS） Securing your Atlassian applications with Apache using SSL （在你的代理中配置 HTTPS）
反向代理： Using Apache with mod_proxy （Confluence） Running Confluence behind NGINX with SSL （Confluence） Proxying Atlassian server applications with Apache HTTP Server (mod_proxy_http) （任何 Atlassian 产品） Proxying Atlassian server applications with Microsoft Internet Information Services (IIS) （任何 Atlassian 产品）
对外的代理： Configuring Web Proxy Support for Confluence （Confluence） How to Configure Outbound HTTP and HTTPS Proxy for your Atlassian application （任何 Atlassian 产品）
尽管我们也提供了一些第三方的解决方案,并且在 server.xml 文件中提到了 Apache 和 Nginx。你也可以选择你自己的代理解决方案。
Atlassian Support 不能提供有关第三方工具的配置帮助指南,比如 NGINX,Apache, 或者 IIS。如果你在配置上遇到了什么问题,请检查你的的代理服务器文档。或者到 Atlassian Community 社区中进行提问,或者从我们的 合作伙伴（Solution Partner） 中寻求帮助。
https://www.cwiki.us/display/CONF6ZH/Proxy+and+HTTPS+setup+for+Confluence

「深度学习福利」大神带你进阶工程师,立即查看>>>
很多用户选择将 Confluence 运行在反向代理的后面,同时还启用了 HTTPS。将你的的 Confluence 反向代理配置正确就显得非常必要了,并且能够避免后期在使用 Confluence 遇到的很多问题。
代理和 HTTPS 访问都已经在 Tomcat 中配置了,Tomcat 是 Confluence 使用的应用服务器。
简单连接器
对 Confluence 进行配置和设置,越简单越好,我们会尽可能的让配置简单。我们已经在 Tomcat 中提供了一系列的连接器样本。这些样本在 /conf/server.xml 文件中。
连接器示例 描述 DEFAULT - 直接连接,不使用代理,针对不使用代理的 HTTP 访问 Confluence 这个是默认的选项。当你没有使用反向代理并且 没有 启用 HTTPS,启用这个选项。

HTTP - 代理访问 Confluence ,通过 Apache 或者 Nginx 通过 HTTP 访问	当你使用了反向代理,并且 没有 启用 HTTPS,选择这个选项。 HTTPS - 直接连接,不使用代理,针对不使用代理的 HTTPS 访问 Confluence	HTTPS - 代理访问 Confluence ,通过 Apache 或者 Nginx 通过 HTTPS 访问 如果你希望使用 HTTPS,但是不配置反向代理,选择这个选项。HTTPS 将会在 Tomcat 中进行配置。	如果你希望使用反向代理,并且还启用 HTTPS。请使用这个选项,同时这个也是最常用的配置。

我们仅提供 HTTP/HTTPS 连接器的示例。如果你不能使用 AJP 连接器（例如,使用 Apache mod_jk）为 Synchrony。 Synchrony 在配置在协同编辑使用,不能接受 AJP 连接。
如果你计划使用协同编辑,这里有一系列的基于代理和 SSL 连接的考虑。请参考 proxy and SSL considerations 页面中的内容。当你决定何种配置最适合你配置反向代理,你需要考虑这些因素。
https://www.cwiki.us/display/CONF6ZH/Proxy+and+HTTPS+setup+for+Confluence

「深度学习福利」大神带你进阶工程师,立即查看>>>
策略模式： 定义了算法族（就是鸭子的飞和叫的行为组）,分别封装起来,让它们之间可以互相替换, 此模式让算法的变化独立于使用算法的客户。
设计一个不同鸭子叫和飞的行为:
飞行为的抽象类： public interface FlyBehavior { public void fly(); }
叫行为的抽象类： public interface QuackBehavior { public void quack(); }
实现多个飞行为： // 会飞 public class FlyWithWings implements FlyBehavior { public void fly() { System.out.println(“I’m flying!!”); } } // 不会飞 public class FlyNoWay implements FlyBehavior { public void fly() { System.out.println(“I can’t fly”); } }
实现多个叫的行为实例： public class Quack implements QuackBehavior { public void quack() { System.out.println(“Quack”); } } public class MuteQuack implements QuackBehavior { public void quack() { System.out.println(“<< Silence >>”); } } public class Squeak implements QuackBehavior { public void quack() { System.out.println(“Squeak”); } }
鸭子的父类： public abstract class Duck { FlyBehavior flyBehavior; QuackBehavior quackBehavior; public Duck() {} public abstract void display(); public void performFly() { // 委托给行为类 flyBehavior.fly(); } public void performQuack() { // 委托给行为类 quackBehavior.quack(); } public void swim() { System.out.println(“All ducks float, even decoys!”); } }
开始创建一只鸭子： public class MallardDuck extends Duck { // 在构造函数中设定行为不易扩展,使用set方式动态创建/改变不同行为的鸭子 public MallardDuck() { quackBehavior = new Quack(); flyBehavior = new FlyWithWings(); } public void display() { System.out.println(“I’m a real Mallard duck”); } public void setFlyBehavior(FlyBehavior fb) { flyBehavior = fb; } public void setQuackBehavior(QuackBehavior qb) { quackBehavior = qb; } }
让鸭子飞起来、叫起来 public class MiniDuckSimulator { public static void main(String[] args) { Duck mallard = new MallardDuck(); mallard.performQuack(); // 进行委托 mallard.performFly(); // 随意改变鸭子行为 mallard.setFlyBehavior(new FlyNoWay()); mallard.setQuackBehavior(new MuteQuack()); mallard.performQuack(); // 进行委托 mallard.performFly(); } }

「深度学习福利」大神带你进阶工程师,立即查看>>>
在默认的情况下,所有的 Confluence 计划任务都是默认启用的。
使用 启用（Disable ）/ 禁用（Enable ） 连接操作来启用和禁用每一个计划任务。
不是所有的加护任务都可以被禁用的。
https://www.cwiki.us/display/CONF6ZH/Scheduled+Jobs

「深度学习福利」大神带你进阶工程师,立即查看>>>
手动运行一个任务
希望手动运行一个计划任务,进入计划任务的列表中,找到你希望手动运行的计划任务,在这个计划任务的边上选择 运行（Run） 。这个计划任务将会马上执行。
不是所有的计划任务都可以手动运行的。
修改任务的计划
希望修改计划任务的计划时间： 找到你希望修改的计划任务边上的 编辑（ Edit ）。 使用 Cron 表达式输入你希望这个计划任务运行的新日期和时间——关 Cron 表达式的相关信息,请参考 下面 的内容。 保存（Save ） 你对计划任务的修改,或者 重置（Revert ） 为默认设置。
不是所有的计划任务都可以配置时间的。
屏幕截图：配置一个计划任务
https://www.cwiki.us/display/CONF6ZH/Scheduled+Jobs

「深度学习福利」大神带你进阶工程师,立即查看>>>
希望访问 Confluence 计划任务配置界面： 进入 > 基本配置（ General Configuration） > 计划任务（Scheduled Jobs） 所有的计划任务将会按照下面的格式列出来： 状态（Status ） - 这个计划任务的状态。这个状态为 'Scheduled' （当前这个计划任务是启用的）或者 'Disabled'。 上次执行（Last Execution） - 这个计划任务上次执行的日期和时间。如果这个计划任务没有执行的话,这个字段为空。 下次执行（Next Execution） - 这个计划任务下次执行的日期和时间。如果任务被禁用的话,这个字段将会显示符号（-）。 平均执行时间（Avg. Duration） - 计划任务的执行时间（毫秒）这个时间表示的是这个计划任务执行完成所消耗的世界（上次任务完成所需要的时间）。 操作（Actions） - 对计划任务可以进行操作,包括编辑,手动运行,查看历史或者禁用这个任务。
屏幕截图：计划任务
https://www.cwiki.us/display/CONF6ZH/Scheduled+Jobs

「深度学习福利」大神带你进阶工程师,立即查看>>>
管理员控制台能够允许你对 Confluence 运行的计划任务进行计划的调整,这些计划任务将会按照你的调整按时执行。可以按照计划执行的任务如下： Confluence 站点备份 存储优化任务,清理 Confluence 的临时目录中的文件和缓存 索引优化任务,确定 Confluence 的索引能够保持与数据库同步是最新的索引 邮件队列优化任务,确保 Confluence 的邮件任务能够处理邮件队列并且所有的邮件都能发送出去。
你需要具有 系统管理员权限 才能对计划任务进行编辑和手动运行。

https://www.cwiki.us/display/CONF6ZH/Scheduled+Jobs

「深度学习福利」大神带你进阶工程师,立即查看>>>
ZooKeeper典型应用场景一览
数据发布与订阅（配置中心）
发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到ZK节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新。例如全局的配置信息,服务式服务框架的服务地址列表等就非常适合使用。
应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置,同时,在节点上注册一个Watcher,这样一来,以后每次配置有更新的时候,都会实时通知到订阅的客户端,从来达到获取最新配置信息的目的。
分布式搜索服务中,索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点,供各个客户端订阅使用。
分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元,因此需要在ZK上创建一个以应用名作为path的节点P,并将这个应用的所有机器ip,以子节点的形式注册到节点P上,这样一来就能够实现机器变动的时候,能够实时通知到收集器调整任务分配。
系统中有些信息需要动态获取,并且还会存在人工手动去修改这个信息的发问。通常是暴露出接口,例如JMX接口,来获取一些运行时的信息。引入ZK之后,就不用自己实现一套方案了,只要将这些信息存放到指定的ZK节点上即可。
注意：在上面提到的应用场景中,有个默认前提是：数据量很小,但是数据更新可能会比较快的场景。
负载均衡
这里说的负载均衡是指软负载均衡。在分布式环境中,为了保证高可用性,通常同一个应用或同一个服务的提供方都会部署多份,达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑,其中比较典型的是消息中间件中的生产者,消费者负载均衡。
消息中间件中发布者和订阅者的负载均衡,linkedin开源的KafkaMQ和阿里开源的 metaq 都是通过zookeeper来做到生产者、消费者的负载均衡。这里以metaq为例如讲下：
生产者负载均衡：metaq发送消息的时候,生产者在发送消息的时候必须选择一台broker上的一个分区来发送消息,因此metaq在运行过程中,会把所有broker和对应的分区信息全部注册到ZK指定节点上,默认的策略是一个依次轮询的过程,生产者在通过ZK获取分区列表之后,会按照brokerId和partition的顺序排列组织成一个有序的分区列表,发送的时候按照从头到尾循环往复的方式选择一个分区来发送消息。
消费负载均衡：
在消费过程中,一个消费者会消费一个或多个分区中的消息,但是一个分区只会由一个消费者来消费。MetaQ的消费策略是：
每个分区针对同一个group只挂载一个消费者。
如果同一个group的消费者数目大于分区数目,则多出来的消费者将不参与消费。
如果同一个group的消费者数目小于分区数目,则有部分消费者需要额外承担消费任务。
在某个消费者故障或者重启等情况下,其他消费者会感知到这一变化（通过 zookeeper watch消费者列表）,然后重新进行负载均衡,保证所有的分区都有消费者进行消费。
命名服务(Naming Service)
命名服务也是分布式系统中比较常见的一类场景。在分布式系统中,通过使用命名服务,客户端应用能够根据指定名字来获取资源或服务的地址,提供者等信息。被命名的实体通常可以是集群中的机器,提供的服务地址,远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API,能够很容易创建一个全局唯一的path,这个path就可以作为一个名称。
阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务,维护全局的服务地址列表, 点击这里 查看Dubbo开源项目。在Dubbo实现中：
服务提供者在启动的时候,向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址,这个操作就完成了服务的发布。
服务消费者启动的时候,订阅/dubbo/${serviceName}/providers目录下的提供者URL地址, 并向/dubbo/${serviceName} /consumers目录下写入自己的URL地址。
注意,所有向ZK上注册的地址都是临时节点,这样就能够保证服务提供者和消费者能够自动感应资源的变化。
另外,Dubbo还有针对服务粒度的监控,方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息。
分布式通知/协调
ZooKeeper中特有watcher注册与异步通知机制,能够很好的实现分布式环境下不同系统之间的通知与协调,实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册,监听znode的变化（包括znode本身内容及子节点的）,其中一个系统update了znode,那么另一个系统能够收到通知,并作出相应处理
另一种心跳检测机制：检测系统和被检测系统之间并不直接关联起来,而是通过zk上某个节点关联,大大减少系统耦合。
另一种系统调度模式：某系统有控制台和推送系统两部分组成,控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作,实际上是修改了ZK上某些节点的状态,而ZK就把这些变化通知给他们注册Watcher的客户端,即推送系统,于是,作出相应的推送任务。
另一种工作汇报模式：一些类似于任务分发系统,子任务启动后,到zk来注册一个临时节点,并且定时将自己的进度进行汇报（将进度写回这个临时节点）,这样任务管理者就能够实时知道任务进度。
总之,使用zookeeper来进行分布式通知和协调能够大大降低系统之间的耦合
集群管理与Master选举
集群机器监控：这通常用于那种对集群中机器状态,机器在线率有较高要求的场景,能够快速对集群中机器变化作出响应。这样的场景中,往往有一个监控系统,实时检测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时检测每个机器,或者每个机器自己定时向监控系统汇报“我还活着”。 这种做法可行,但是存在两个比较明显的问题：
集群中机器有变动的时候,牵连修改的东西比较多。
有一定的延时。
利用ZooKeeper有两个特性,就可以实时另一种集群机器存活性监控系统：
客户端在节点 x 上注册一个Watcher,那么如果 x?的子节点变化了,会通知该客户端。
创建EPHEMERAL类型的节点,一旦客户端和服务器的会话结束或过期,那么该节点就会消失。
例如,监控系统在 /clusterServers 节点上注册一个Watcher,以后每动态加机器,那么就往 /clusterServers 下创建一个 EPHEMERAL类型的节点：/clusterServers/{hostname}. 这样,监控系统就能够实时知道机器的增减情况,至于后续处理就是监控系统的业务了。
Master选举则是zookeeper中最为经典的应用场景了。
在分布式环境中,相同的业务应用分布在不同的机器上,有些业务逻辑（例如一些耗时的计算,网络I/O处理）,往往只需要让整个集群中的某一台机器进行执行,其余机器可以共享这个结果,这样可以大大减少重复劳动,提高性能,于是这个master选举便是这种场景下的碰到的主要问题。
利用ZooKeeper的强一致性,能够保证在分布式高并发情况下节点创建的全局唯一性,即：同时有多个客户端请求创建 /currentMaster 节点,最终一定只有一个客户端请求能够创建成功。利用这个特性,就能很轻易的在分布式环境中进行集群选取了。
另外,这种场景演化一下,就是动态Master选举。这就要用到?EPHEMERAL_SEQUENTIAL类型节点的特性了。
上文中提到,所有客户端创建请求,最终只有一个能够创建成功。在这里稍微变化下,就是允许所有请求都能够创建成功,但是得有个创建顺序,于是所有的请求最终在ZK上创建结果的一种可能情况是这样： /currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2 ,?/currentMaster/{sessionId}-3 ….. 每次选取序列号最小的那个机器作为Master,如果这个机器挂了,由于他创建的节点会马上小时,那么之后最小的那个机器就是Master了。
在搜索系统中,如果集群中每个机器都生成一份全量索引,不仅耗时,而且不能保证彼此之间索引数据一致。因此让集群中的Master来进行全量索引的生成,然后同步到集群中其它机器。另外,Master选举的容灾措施是,可以随时进行手动指定master,就是说应用在zk在无法获取master信息时,可以通过比如http方式,向一个地方获取master。
在Hbase中,也是使用ZooKeeper来实现动态HMaster的选举。在Hbase实现中,会在ZK上存储一些ROOT表的地址和HMaster的地址,HRegionServer也会把自己以临时节点（Ephemeral）的方式注册到Zookeeper中,使得HMaster可以随时感知到各个HRegionServer的存活状态,同时,一旦HMaster出现问题,会重新选举出一个HMaster来运行,从而避免了HMaster的单点问题
分布式锁
分布式锁,这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类,一个是保持独占,另一个是控制时序。
所谓保持独占,就是所有试图来获取这个锁的客户端,最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁,通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点,最终成功创建的那个客户端也即拥有了这把锁。
控制时序,就是所有视图来获取这个锁的客户端,最终都是会被安排执行,只是有个全局时序了。做法和上面基本类似,只是这里 /distribute_lock 已经预先存在,客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。Zk的父节点（/distribute_lock）维持一份sequence,保证子节点创建的时序性,从而也形成了每个客户端的全局时序。
分布式队列
队列方面,简单地讲有两种,一种是常规的先进先出队列,另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列,和分布式锁服务中的控制时序场景基本原理一致,这里不再赘述。
第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在 /queue 这个znode下预先建立一个/queue/num 节点,并且赋值为n（或者直接给/queue赋值n）,表示队列大小,之后每次有队列成员加入后,就判断下是否已经到达队列大小,决定是否可以开始执行了。这种用法的典型场景是,分布式环境中,一个大任务Task A,需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候,凡是其中一个子任务完成（就绪）,那么就去 /taskList 下建立自己的临时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL）,当 /taskList 发现自己下面的子节点满足指定个数,就可以进行下一步按序进行处理了。最后一句,分享点我 Redis缓存技术交流组： 1903832579

「深度学习福利」大神带你进阶工程师,立即查看>>>
1.修改server.xml文件,如下：


注意： 这里使用的是https的认证方式,需要将这个配置放开,并做如下修改：
port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="D:/sso-cas/caskey/keycard"
keystorePass="minglisoft"
/>
注意： keystoreFile="D:/sso-cas/caskey/keycard" --证书了路径
keystorePass="minglisoft" --证书密码
2.测试https的8443端口是否可以访问：https://localhost:8443


配置没有问题
3.可以配置只通过域名访问,还是修改server.xml文件,将localhost的配置修改为jeesz.cn如下：
unpackWARs="true" autoDeploy="true">
unpackWARs="true" autoDeploy="true">
重启tomcat容器,访问如下：http://jeesz.cn:8080
4.将cas-server-webapp-4.2.7.war包拷贝到tomcat容器中,并命名为cas.war如下:


5.重启启动tomcat容器,访问cas, https://jeesz.cn:8443/cas
默认用户名为：casuser
默认密码为：Mellon



以下是所有的cas sso单点登录交付件和源码

「深度学习福利」大神带你进阶工程师,立即查看>>>
前面几篇我们已经介绍了Spring Cloud和oauth2的知识点,今天我们要利用Spring Cloud和oauth2进行commonservice-sso服务搭建,本节我们只是搭建commonservice-sso的基础平台,闲话少说,直接将步骤记录下来：
1. 创建maven项目commonservice-sso,其中pom.xml文件配置如下： 4.0.0 com.ml.honghu commonservice 0.0.1-SNAPSHOT commonservice-sso jar org.springframework.cloud spring-cloud-starter-eureka org.springframework.cloud spring-cloud-starter-config org.springframework.boot spring-boot-starter-actuator org.springframework.boot spring-boot-starter-data-rest org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-security org.springframework.security.oauth spring-security-oauth2 org.springframework.boot spring-boot-starter-test org.springframework.hateoas spring-hateoas org.springframework.boot spring-boot-starter-data-rest com.ml.honghu.common.framework common-framework-dao 1.0.0-SNAPSHOT org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-freemarker com.ml.honghu component-base org.springframework.boot spring-boot-maven-plugin 1 repackage 2 build-info
2. 配置bootstrap.yml文件 spring: application: name: commonservice-sso profiles: active: dev,discoveryClient cloud: config: discovery: enabled: true service-id: commonservice-config-server eureka: client: service-url: defaultZone: http://honghu:123456@localhost:8761/eureka instance: prefer-ip-address: true
3. 配置项目启动文件 package com.ml.honghu; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.eureka.EnableEurekaClient; @SpringBootApplication @EnableEurekaClient public class SSOApplication { public static void main(String[] args) { SpringApplication.run(SSOApplication.class, args); } }
4. 创建sso相关表： oauth_access_token、oauth_approvals、 oauth_client_details、oauth_client_token、 oauth_code、oauth_refresh_token /* Navicat MySQL Data Transfer Source Server : localhost Source Server Version : 50621 Source Host : localhost:3306 Source Database : honghu Target Server Type : MYSQL Target Server Version : 50621 File Encoding : 65001 Date: 2017-10-26 20:12:56 */ SET FOREIGN_KEY_CHECKS=0; -- ---------------------------- -- Table structure for `oauth_access_token` -- ---------------------------- DROP TABLE IF EXISTS `oauth_access_token`; CREATE TABLE `oauth_access_token` ( `token_id` varchar(256) DEFAULT NULL, `token` blob, `authentication_id` varchar(128) NOT NULL, `user_name` varchar(256) DEFAULT NULL, `client_id` varchar(256) DEFAULT NULL, `authentication` blob, `refresh_token` varchar(256) DEFAULT NULL, PRIMARY KEY (`authentication_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- ---------------------------- -- Table structure for `oauth_approvals` -- ---------------------------- DROP TABLE IF EXISTS `oauth_approvals`; CREATE TABLE `oauth_approvals` ( `userId` varchar(256) DEFAULT NULL, `clientId` varchar(256) DEFAULT NULL, `scope` varchar(256) DEFAULT NULL, `status` varchar(10) DEFAULT NULL, `expiresAt` datetime DEFAULT NULL, `lastModifiedAt` datetime DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- ---------------------------- -- Records of oauth_approvals -- ---------------------------- -- ---------------------------- -- Table structure for `oauth_client_details` -- ---------------------------- DROP TABLE IF EXISTS `oauth_client_details`; CREATE TABLE `oauth_client_details` ( `client_id` varchar(128) NOT NULL, `resource_ids` varchar(256) DEFAULT NULL, `client_secret` varchar(256) DEFAULT NULL, `scope` varchar(256) DEFAULT NULL, `authorized_grant_types` varchar(256) DEFAULT NULL, `web_server_redirect_uri` varchar(256) DEFAULT NULL, `authorities` varchar(256) DEFAULT NULL, `access_token_validity` int(11) DEFAULT NULL, `refresh_token_validity` int(11) DEFAULT NULL, `additional_information` varchar(4096) DEFAULT NULL, `autoapprove` varchar(256) DEFAULT NULL, PRIMARY KEY (`client_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- ---------------------------- -- Table structure for `oauth_client_token` -- ---------------------------- DROP TABLE IF EXISTS `oauth_client_token`; CREATE TABLE `oauth_client_token` ( `token_id` varchar(256) DEFAULT NULL, `token` blob, `authentication_id` varchar(128) NOT NULL, `user_name` varchar(256) DEFAULT NULL, `client_id` varchar(256) DEFAULT NULL, PRIMARY KEY (`authentication_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- ---------------------------- -- Records of oauth_client_token -- ---------------------------- -- ---------------------------- -- Table structure for `oauth_code` -- ---------------------------- DROP TABLE IF EXISTS `oauth_code`; CREATE TABLE `oauth_code` ( `code` varchar(256) DEFAULT NULL, `authentication` blob ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- ---------------------------- -- Records of oauth_code -- ---------------------------- -- ---------------------------- -- Table structure for `oauth_refresh_token` -- ---------------------------- DROP TABLE IF EXISTS `oauth_refresh_token`; CREATE TABLE `oauth_refresh_token` ( `token_id` varchar(256) DEFAULT NULL, `token` blob, `authentication` blob ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
备注： oauth的相关表是用来存储用户的token信息和认证信息的。
本节搭建先搭建那么多,后面的业务代码太多,我们会在后面的章节中放出来。
从现在开始,我这边会将近期研发的spring cloud微服务云架构的搭建过程和精髓记录下来,帮助更多有兴趣研发spring cloud框架的朋友,大家来一起探讨spring cloud架构的搭建过程及如何运用于企业项目。完整项目的源码来源 技术支持1791743380

「深度学习福利」大神带你进阶工程师,立即查看>>>
cd /usr/local/tomcat/tomcat-pm
bin/shutdown.sh
ps -ef|grep tomcat
kill -9 进程号
bin/startup.sh
tail -f logs/catalina.out (bin同级目录)
Ctrl+c

「深度学习福利」大神带你进阶工程师,立即查看>>>
[root @bogon ~]# cd /usr/local/tomcat/apache-tomcat-8.5.8/bin/
[root @bogon bin]# vi startup.sh
在最后一行增加jpda,注意前后有空格
保存退出
[root @bogon bin]# vi catalina.sh
/jpda 搜索 如果查找下一个,按“n”即可
保存退出
注意防火墙要开放5005端口
如果是jar,则：
#!/bin/bash
nohup java -jar -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 /data/sharksucker/workspace/resource/sharksucker-admin.jar
idea连接调试


打断点即可调试

「深度学习福利」大神带你进阶工程师,立即查看>>>
想来想去,这个文章的名字还是叫理性看待性能测试更为妥当。今天在微博上看到有人@到我提到一个关于性能测试的问题,我在回复了之后,感觉意犹未尽。由于微博上打字太费劲了,想说的话还没说完就不让输入了。只能回来自己写一个文章以平复一下想说未说完的憋闷。
我们总是会听到这样的话：性能测试工程师应该会操作系统、数据库、网络、应用、代码等等。这样的话,大部分是从有经验的性能测试所谓的前辈的嘴里说出来,让一些人觉得说这样的话的人牛B而且非常值得膜拜。可气的是没有说明白这个程度到底是什么样的,其实从我个人从业这么多年的角度来看,没有哪一个人可以把这些东西,全都精通到不可一世的程度的。要是说完全不知道,那也不太可能,哪个IT行业的人一生不得总是接触这些东西呢。接触并不代表可以掌握和控制它,这种完全不同的视角会在含糊其词之间被无视。所以,我觉得对性能测试工程师,没有必要这么苛刻。要求可以,但是要理智的要求。要求懂操作系统、数据库、网络、应用？没有关系,正常的操作是可以做的,和性能有关的常用的判断手段是可以做的,和性能有关的常用的参数配置是可以知道的。（其他亦如此）。我觉得这样的要求对中级性能测试工程师就可以了。至少可以做大部分的工作了。也许会有人接着问了,高级性能测试工程师又要求什么呢？我觉得：性能测试的思维是高级性能测试工程师必须修炼的内功心法。面对一个未做过的系统,如果出现性能问题,从自己的经验教训中去判断寻找一些蛛丝马迹,配合整体的团队寻找解决问题的方法,这才是要体现出来的价值。
同时,我们还会听到另一种声音：性能测试不就是拿着工具录个脚本,加些用户跑一下就行了吗？于是乎,经常会有一些人提出一些比较苛刻的性能测试需求：很短的时间内出一个性能测试的结果,并且要说出性能瓶颈在哪里。这种性能需求大部分来自于一些对性能测试并不十分了解的人群,但是这部分人群又有足够的能量影响着性能测试的方向。比如说,客户方的某个领导。在这样的情形之下,做为性能测试的行内人,就有引导客户需求、说服客户的职责了。当然,在现在这种利益驱动的市场模式之下,花个大价钱做个完整的性能测试,可能还没有给某些关键人物来点贿赂更为有效。毕竟系统上线就死的也不是很多嘛,哪有那么多的系统都像某订票网站那么悲摧呢。只有实际的损失才能有切肤之痛。
说到性能测试产生的实际的损失,我记得我在一次测试沙龙上说过一句话：在某些感受不到性能测试价值的企业里,性能测试是在谩骂和鄙视中被从踏得满是灰尘的地上捡起来的。在一些实际的利益损失之后,那些各相关部门才会捡起这个大海中救命的木头。可惜的是,这个时候各种动作都是亡羊补牢,损失的再也不会回来。那些被终端用户的嘲笑也被记录在企业的发展历史中。话说,前一阵子,一个金融行业巨头的某系统由于参数配置的问题一上线就死了,幸好产生的社会影响并不大；还有某证券公司的渠道总线因为性能不达标导致停了半个小时,损失了1个亿；还有某互联网公司的系统上线之后,因为数据库承受不了压力而出现了大量的用户失败的现象,等等。这样的情况举不胜举,我都不用众所周知的某订票网站做例子。
不管是在什么样的行业中,我觉得都要正视行业的处境,也需要明白自己的能力在行业中的位置。在自己的岗位上,就要明白自己的职责。我们不应该给性能测试相关的岗位太多的压力,也不应该报有过高的期望。同时,我们也要知道性能测试的岗位能做到什么样的事情。做为一个性能测试工程师,本身就要明白性能测试的工作职责。我看到很多个招聘性能测试职位的要求,有些要求招的不是人,而是神。由于神不多,所以只能抱怨现在这个行业真是整体能力太差了。性能测试的整个过程中确实应该包括完整的性能分析、优化工作,也需要给足够的时间、资源和支持。
一个性能项目,如果想做到完整的性能分析,必须要有其他团队的支持。我们可以定位到一个具体的函数,但是如果我们也把函数改了,是不是更能体现我们强大呢？显然这不符合逻辑。这不是我们该干的事情,除非把开发的工资也发给我们。所以,我的观点是：性能分析是性能测试过程中的一个必然的环节；性能分析需要各个相关团队的支持。当然有些团队可能因为时间比较紧,最后留给系统性能测试的只有一点点可怜的时间。在这样的情况之下,就不要再指望性能测试能带来多大的强心剂了,最多也就是安慰安慰领导或者客户罢了。
还是总结一下：认清楚性能测试职位能做到的事情,明确性能测试工作中需要的支持。不要有无谓的天马行空的论调和不切实际的需求。真正的理性的看待性能测试,才能让性能测试发挥它本应该发挥的也可以发挥的最大的价值。
后记：希望行内人和行外人都给一个合理的空间。

「深度学习福利」大神带你进阶工程师,立即查看>>>
如果你得到了与下面显示内容类似的信息话,那么你最好考虑修改 Confluence 的日志级别输出更多的信息。如果你考虑通过 Atlassian support 获得帮助,那么这些详细的错误信息能够更好的帮助我们找到问题的原因。
增加日志的级别将会让我们能够对下面的问题进行诊断：

org.springframework.dao.DataIntegrityViolationException: (HibernateTemplate): data integrity violated by SQL '' ; nested exception is java.sql.BatchUpdateException: Duplicate entry '1234' for key 1 at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.translate(SQLStateSQLExceptionTranslator.java: 88 ) caused by: java.sql.BatchUpdateException: Duplicate entry '1234' for key 1 at com.mysql.jdbc.ServerPreparedStatement.executeBatch(ServerPreparedStatement.java: 647 )

或者

(HibernateTemplate): data integrity violated by SQL '' ; nested exception is java.sql.BatchUpdateException: ORA- 00001 : unique constraint ( CONFLUENCE.SYS_C0012345) violated

这个文档对如果在你的系统中增加日志级别,并让日志输出更多详细信息进行了说明。
Changing the logging levels via the Administration Console
从 Confluence 2.7 开始,你可以在你的 Confluence 管理员控制台中调整日志的级别——请阅读 Working with Confluence Logs 页面中的相关内容。下面我们将会告诉你如何直接编辑 log4j 文件。 打开 confluence/WEB-INF/classes/log4j.properties 然后取消注释下面的行。 ## 行是注释,请保持这行的完整。

## log hibernate prepared statements/SQL queries (equivalent to setting ' hibernate.show_sql' to 'true' ) # log4j.logger.net.sf.hibernate.SQL=DEBUG ## log hibernate prepared statement parameter values # log4j.logger.net.sf.hibernate.type=DEBUG

如果你不能在你的 log4j.properties 文件中找到上面的内容的话,请在文件的最后添加上这些内容。 重启 Confluence。 重新操作你出现错误的的步骤。 压缩你的日志目录然后添加到你的支持请求工单中。 如果你使用的是 Oracle 数据库同时你收到了一个 constraint error ,请询问你的数据库管理员是哪个一个数据库表和列有约束（例如： CONFLUENCE.SYS_C0012345 ）,获得相关信息后将这些内容添加到你的工单中。 打开 confluence/WEB-INF/classes/log4j.properties 文件,删除在第一步中添加的上面 4 行（让 Confluence 输出更多的日志信息将会影响 Confluence 的性能,在生产环境中,你应该不输出这些信息）。
相关主题
Enabling Detailed SQL Logging
Working with Confluence Logs
Troubleshooting failed XML site backups
https://www.cwiki.us/display/CONF6ZH/Troubleshooting+SQL+Exceptions

「深度学习福利」大神带你进阶工程师,立即查看>>>
日志级别 DEBUG - 被设计为用来获得最多的信息和事件,在对应用程序进行调试的时候,这个日志级别通常能够提供最多的有效信息（查看应用程序怎么了） INFO - 有关系统正常运行-计划任务运行,服务器开始和结束的世界,用户触发的进程和操作的一些有关声明和输出 WARN - 有关这方面的内容并不是表示系统本身出错了,而是表示系统本身有优化的空间 ERROR - 有关这个的输出表示的是系统在运行的时候遇到了一些错误 FATAL - 有关这个级别的输出表示系统进入了一个非常糟糕的状态并且已经不能从这个状态中恢复了。 TRACE - 没有在 Confluence 中输出
有 2 个方法能够对 Confluence 的日志输出进行调整,相关的方法描述在 log4j Logging Levels 中。 通过 管理员控制台（Administration Console） 修改运行日志的级别（这个修改将会在系统重启后失效,不是一个永久的修改）。 手动修改 \confluence\WEB-INF\classes\log4j.properties 文件。
默认日志级别
标准的 Confluence 日志级别 WARN 被保留在 Confluence 服务器中与 Confluence 管理员进行通信。 WARN 及其更高的日志级别应该在 Confluence 保留使用为某些特定的用途,这些能够提醒系统管理员关注这些错误的日志信息,然后对出现的问题进行纠正。
请参考 log4j manual 来获得更多的信息。
https://www.cwiki.us/display/CONF6ZH/log4j+Logging+Levels

「深度学习福利」大神带你进阶工程师,立即查看>>>
我们推荐你根据你的需求来配置你自己的 Confluence 日志。你可以有下面 2 种方法来修改你的日志： 通过 Confluence 管理员控制台进行配置 – 你的修改仅在本次修改有效,下次重启后将会把所有修改重置。 编辑属性文件 – 你的修改将会在下次重启后生效同时针对所有的会话。
这 2 种方式的修改的方法将在下面的章节中描述。在一些很不常见的情况下,你可能同时还需要修改 logging.properties 文件。
术语： 在 log4j 中,一个 'logger' 就是一个命名的实体。日志名是大小写敏感的,这些命名还遵循分段命名的结构。例如一个 logger 被命名为 com.foo ,那这个名是 com.foo.Bar 的上级名称。
在 Confluence 管理员控制台中配置日志
你可以通过 Confluence 管理员控制台（Administration Console） 来修改 Confluence 的一些日志的表现。任何按照这个方法修改的的内容只会在当前 Confluence 的运行实例阶段有效（重启 Confluence 后,你修改的配置将失效）。这里修改的配置内容将不会写入到 log4j.properties 文件中,同时当你在下一次停止 Confluence 的时候修改的内容将会被丢弃。
Confluence 的管理员控制台不能修改所有的日志表现。如果你不能在下面的描述的内容中找到修改的对象,那么你需要停止 Confluence 后 编辑日志属性文件 。
Confluence 管理员控制台中的 日志和属性（ Logging and Profiling ）界面显示了当前定义的所有日志列表。在这个界面中你可以： 打开或者关闭 page profiling 。 打开或者关闭 SQL 语句日志。 为一个类或者包添加一个新的日志。 为一个类或者包删除一个新的日志。 为一个类或者包设置日志的级别（INFO, WARN, FATAL, ERROR 或者 DEBUG）。 重置所有的日志级别到 predefined 属性。
修改日志配置 在屏幕的右上角单击 控制台按钮 ,然后选择 General Configuration 链接。 在左侧面板中 管理（Administration） 的界面下面选择 日志和配置（Logging and Profiling） 。
你需要具有 System Administrator 权限才可以进行这个操作。 日志和配置（Logging and Profiling） 界面将会显示,如下图显示,使用下面的的指南来记录 Confluence 的日志表现： 性能属性（Performance Profiling） — 请参考页面 Troubleshooting Slow Performance Using Page Request Profiling 中的内容 SQL 日志（ SQL Logging ）' — 单击 启用 SQL 日志（ Enable SQL Logging ）按钮来启用记录系统运行的 SQL 脚本。
如果你需要启用日志 SQL 参数变量,你需要修改 properties file 文件中的设置。这个配置的修改在管理员控制台界面中不可用。 Log4j 日志（ Log4j Logging ） — 单击下面的的属性按钮来重置你的日志定义为默认的初始化定义： 'Production ' 属性定义了标准的属性,推荐你在生产环境中使用。 ' Diagnostic ' 属性定义了更多的属性配置,能够为你提供更多的日志信息。这个配置将会降低你系统的性能并且让你日志文件更快的填充满。 ' Add New Entry ' — 输入类或者包的名字到边上的文本输入框中,然后单击 添加实体（ Add Entry ）按钮。这个新的日志将会显示 已存在的级别（Existing Levels） 在下面的界面中。 ' Existing Levels ' - 这个是当前你 Confluence 实例中的操作。 你可以通过选择 New Level 的下拉列表来修改日志级别。请阅读 Apache documentation 页面中的内容来定义每一个级别。 单击 ' Remove ' 链接来停止日志记录你选择的类和包的名称。 单击 保存（ Save ）按钮来保存你在 ' Existing Levels ' 部分所做的任何修改。
屏幕截图：修改日志级别和参数
编辑属性文件
希望配置日志级别和其他基础参数的设置,你需要停止 Confluence 然后修改 log4j.properties 文件的设置,如果 上面 的描述。
这个属性文件包括了一系列的不同日志并且可以被你取消备注,如果你希望记录一些特定的组件。请参考 Apache log4j documentation 页面中的内容。
请参考 Working with Confluence Logs 页面中的的内容来获得一些配置的指南,你可能会发现这些指南对你对问题的诊断会比较有用。
针对 logging.properties 中的 java.util.logging 配置级别
一些库在 Confluence 中被用来使用 java.util.logging 而不是 log4j 或者 slf4j。这些库包括： com.sun.jersey org.apache.shindig net.sf.ehcache
Confluence 的 logging.properties 文件设置将 java.util.logging 重定向为 log4j 的特定级别,这个重定向是通过 slf4j 操作的。
为了增加这些库的日志级别,你必须首先配置 logging.properties 文件中的 /confluence/WEB-INF/classes/ 。这些日志级别与 Logj 的级别不同,如 这里 列出来的。
例如,为了让 shindig 增加在日志中输出的内容信息,需要修改 in the logging.properties 文件： org.apache.shindig.level = INFO
为 org.apache.shindig.level = FINE
然后需要使用上面提供的 2 中方式中的一种来配置 log4j 级别。
https://www.cwiki.us/display/CONF6ZH/Configuring+Logging

「深度学习福利」大神带你进阶工程师,立即查看>>>

1.centos7版本对防火墙进行 加强,不再使用原来的iptables,启用firewall
1.查看已开放的端口(默认不开放任何端口)
firewall-cmd --list-ports
2.开启80端口
firewall-cmd --zone=public(作用域) --add-port=80/tcp(端口和访问类型) --permanent(永久生效)
3.重启防火墙
firewall-cmd --reload
4.停止防火墙
systemctl stop firewalld.service
5.禁止防火墙开机启动
systemctl disable firewalld.service
6.删除
firewall-cmd --zone= public --remove-port=80/tcp --permanent
2.centos7以下版本
1.开放80,22,8080 端口
/sbin/iptables -I INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -I INPUT -p tcp --dport 22 -j ACCEPT
/sbin/iptables -I INPUT -p tcp --dport 8080 -j ACCEPT
2.保存
/etc/rc.d/init.d/iptables save
3.查看打开的端口
/etc/init.d/iptables status
4.关闭防火墙
1） 永久性生效,重启后不会复原
开启： chkconfig iptables on
关闭： chkconfig iptables off
2） 即时生效,重启后复原
开启： service iptables start
关闭： service iptables stop

「深度学习福利」大神带你进阶工程师,立即查看>>>
1. 项目核心代码结构截图




jeesz-utils
jeesz-config
jeesz-framework
jeesz-core-cmsjeesz-core-gen
jeesz-core-bookmark
jeesz-core-act

jeesz-core-oa
jeesz-core-test
jeesz-core-scheduler
jeesz-core-task

jeesz-web-admin

jeesz-web-service

jeesz-web-scheduler

jeesz-web-task

jeesz-web-bookmark

jeesz-facade-bookmark

jeesz-service-bookmark

jeesz-facade-task

jeesz-service-task

jeesz-web-mq-task

提醒：
开发人员在开发的时候可以将自己的业务 REST服务化或者 Dubbo服务化
2. 项目依赖介绍
2.1. 后台管理系统、Rest 服务系统、Scheculer 定时调度系统依赖如下图：
2.2. Dubbo 独立服务项目依赖如下图：

3. 平台简介

Jeesz 是一个分布式的框架,提供项目模块化、服务化、热插拔的思想,高度封装安全性的 Java EE 快速开发平台。
Jeesz 本身集成 Dubbo 服务管控、Zookeeper 注册中心、Redis 分布式缓存技术 、FastDFS 分布式文件系统、ActiveMQ 异步消息中间件、Nginx 负载均衡等分布式技术,使用 Maven 做项目管理,项目模块化,提高项目的易开发性、扩展性 ,以 Spring Framework 为核心容器,Spring MVC 为模型视图控制器,MyBatis为数据访问层,Apache Shiro 为权限授权层,Ehcahe 对常用数据进行缓存,Activit为工作流引擎等。前端集成 Bootstrap4 metronic 框架,UI 响应式、扁平化布局,适应所有 PC、Pad、Anroid、ios 移动设备等。Jeesz 主要定位于互联网企业架构,已内置企业信息化系统的基础功能和高效的代码生成工具,包括：系统权限组件、数据权限组件、数据字典组件、核心工具组件、视图操作组件、工作流组件、代码生成等。采用分层设计、双重验证、提交数据安全编码、密码加密、访问验证、数据权限验证。
Jeesz 目前包括以下模块项目,后台系统管理系统,RestFul 独立服务系统、Scheduler 定时调度系统、内容管理（CMS）系统、在线办公（OA）系统、我的待办（Task 服务）、我的收藏（Bookmark 服务）。 后台管理系统包括企业组织架构（用户管理、机构管理、区域管理）、菜单管理、角色权限管理、字典管理等功能；RestFul 独立提供标准 Rest 服务 API,您可以快速实现自己的业务,提供需要的服务；Quartz 定时调度系统可以动态配置您的任务规则等；内容管理（CMS）系统,包括内容管理,栏目管理、站点管理、公共留言、文件管理、前端网站展示等功能；在线办公（OA）系统,主要提供简单的流程实例。
Jeesz 提供了常用工具进行封装,包括日志工具、缓存工具、服务器端验证、数据字典、当前组织机构数据（用户、机构、区域）以及其它常用小工具等。另外还提供一个强大的在线 代码生成 工具,此工具提供简单的单表、一对多、树结构功能的生成,如果对外观要求不是很高,生成的功能就可以用了。使用了Jeesz 基础框架,可以提高快速开发效率。
4. 内置功能(只列了一部分功能)
1. 用户管理：用户是系统操作者,该功能主要完成系统用户配置。
2. 机构管理：配置系统组织机构（公司、部门、小组）,树结构展现,可
随意调整上下级。
3. 区域管理：系统城市区域模型,如：国家、省市、地市、区县的维护。
4. 菜单管理：配置系统菜单,操作权限,按钮权限标识等。
5. 角色管理：角色菜单权限分配、设置角色按机构进行数据范围权限划分。
6. 字典管理：对系统中经常使用的一些较为固定的数据进行维护,如：是否、男女、类别、级别等。
7. 操作日志：系统正常操作日志记录和查询；系统异常信息日志记录和查询。
8. 连接池监视：监视当期系统数据库连接池状态,可进行分析 SQL 找出系统性能瓶颈。
9. 工作流引擎：实现业务工单流转、在线流程设计器。
5. 开发工具
1. Eclipse IDE：采用 Maven 项目管理,模块化。
2. 代码生成：通过界面方式简单配置,自动生成相应代码,目前包括三种生成方式（增删改改查）：单表、一对多、树结构。生成后的代码如果不需要注意美观程度,生成后即可用。
6. 技术选型（只列了一部分技术）
1、后端
➢ 服务框架：Dubbo、zookeeper、Rest 服务
➢缓存：Redis、ehcache
➢ 消息中间件：ActiveMQ,KAFKA
➢ 负载均衡：Nginx
➢ 分布式文件：FastDFS
➢ 数据库连接池：Alibaba Druid 1.0
➢ 核心框架：Spring framework
➢ 安全框架：Apache Shiro 1.2
➢ 视图框架：Spring MVC 4.0
➢ 服务端验证：Hibernate Validator 5.1
➢ 布局框架：SiteMesh 2.4
➢ 工作流引擎：Activiti 5.15
➢ 任务调度：quartz 1.8.5
➢ 持久层框架：MyBatis 3.2
➢ 日志管理：SLF4J 1.7、Log4j
➢ 工具类：Apache Commons、Jackson 2.2、Xstream 1.4、Dozer 5.3、POI
2、前端
➢ JS 框架：JQuery 1.9。
➢ CSS 框架： Bootstrap 4 metronic
➢ 客户端验证：JQuery Validation Plugin。
➢ 富文本：CKEcitor
➢ 文件管理：CKFinder
➢ 动态页签：Jerichotab
➢ 数据表格：jqGrid
➢ 对话框：jQuery jBox
➢ 树结构控件：jQuery zTree
➢ 其他组件：Bootstrap 4 metronic
3、支持
➢ 服务器中间件：Tomcat 6、7、Jboss 7、WebLogic 10、WebSphere 8
➢ 数据库支持：目前仅提供 mysql 数据库的支持,但不限于数据库,下个版本升级多数据源切换和数据库读写分离： 如：Oracle、SqlServer、H2 等
➢ 支持开发环境：Eclipse、MyEclipse、Ras、Idea 等

「深度学习福利」大神带你进阶工程师,立即查看>>>
以电子商务系统配置管理为实例,手把手教你搭建 jeesz 模块项目

1、 创建表
1.1、 创建电子商务系统配置 jeesz_eb_global_config 表
SET FOREIGN_KEY_CHECKS=0;
-- ----------------------------
-- Table structure for `jeesz_eb_global_config`
-- ----------------------------
DROP TABLE IF EXISTS `jeesz_eb_global_config`;
CREATE TABLE `jeesz_eb_global_config` (
`id` varchar(64) NOT NULL COMMENT '编号',
`context_path` varchar(20) DEFAULT NULL COMMENT '部署路径',
`port` int(11) DEFAULT NULL COMMENT '端口号',
`treaty` longtext COMMENT '用户协议',
`activescore` int(11) NOT NULL COMMENT '激活积分',
`def_img` varchar(255) NOT NULL DEFAULT '/r/eb/u/no_picture.gif' COMMENT '图片不存
在时默认图片',
`create_by` varchar(64) NOT NULL COMMENT '创建者',
`create_date` datetime NOT NULL COMMENT '创建时间',
`update_by` varchar(64) NOT NULL COMMENT '更新者',
`update_date` datetime NOT NULL COMMENT '更新时间',
`remarks` varchar(255) DEFAULT NULL COMMENT '备注信息',
`del_flag` char(1) NOT NULL DEFAULT '0' COMMENT '删除标记',
PRIMARY KEY (`id`),
KEY `jeesz_eb_global_config` (`del_flag`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='jeesz 电子商务系统配置表';
-- ----------------------------
-- Records of jeesz_eb_global_config
-- ----------------------------
注意：
1. 表名的修改
2. `create_by`、`create_date`、`update_by`、`update_date`、`remarks`、`del_flag` 是不可缺少的,大家在创建表的时候请勿忽略这些字段。

1.2、 驱动式方案添加业务表配置
点击下一步进行业务表配置（主要针对于 sql 查询条件、页面元素进行设置）
最后进行保存
1.3、 生成方案添加
保存并生成代码（我代码生成在 D:/src 目录下）
2、 创建模块项目
2.1、 根据自己的业务创建模块项目（我以 EB 为实例）

2.2、 对 module 项目进行修改、配置
因为考虑到项目的完整和一致性,通过工具生成的 maven 项目缺少一些源文件,故需要手动创建如下：
点击 ok 后对新创建的文件目录进行顺序调整：
调整后的结果：
修改模块项目 jeesz-core-eb 的 pom.xml 文件：
具体内容如下：



com.alibaba
druid
${druid.version}



mysql
mysql-connector-java
${mysql.driver.version}
runtime


com.oracle
ojdbc14
${oracle.driver.version}
runtime


net.sourceforge.jtds
jtds
${mssql.driver.version}
runtime



org.aspectj
aspectjrt
1.7.4


org.aspectj
aspectjweaver
1.7.4


cglib
cglib
3.1




com.sml.sz
jeesz-config





com.sml.sz
jeesz-framework



2.3、 将生的代码 copy 到指定目录 com.sml.sz.eb
修改 jeesz-project 的 pom.xml 文件,添加模块依赖
代码如下


com.sml.sz
jeesz-core-eb
${project.version}

修改 jeesz-web-admin 的 pom.xml 文件,添加模块依赖
代码如下


com.sml.sz
jeesz-core-eb

将生成的 controller 文件 copy 到 web 项目中

将生成的界面文件 copy 到 web 项目中：

3、 新建菜单并配置权限
具体配置请看我的收藏配置
功能截图：

「深度学习福利」大神带你进阶工程师,立即查看>>>
介绍
意图 ：避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。
主要解决 ：职责链上的处理者负责处理请求,客户只需要将请求发送到职责链上即可,无须关心请求的处理细节和请求的传递,所以职责链将请求的发送者和请求的处理者解耦了。
何时使用 ：在处理消息的时候以过滤很多道。
如何解决 ：拦截的类都实现统一接口。
实现
实现一
创建抽象类 AbstractLogger,带有详细的日志记录级别。然后我们创建三种类型的记录器,都扩展了 AbstractLogger。每个记录器消息的级别是否属于自己的级别,如果是则相应地打印出来,否则将不打印并把消息传给下一个记录器。
public abstract class AbstractLogger { public static int INFO = 1; public static int DEBUG = 2; public static int ERROR = 3; protected int level; // 责任链中的下一个元素 protected AbstractLogger nextLogger; public void setNextLogger(AbstractLogger nextLogger) { this.nextLogger = nextLogger; } public void logMessage(int level, String message) { if (this.level <= level) { write(message); } if (nextLogger != null) { nextLogger.logMessage(level, message); } } abstract protected void write(String message); } public class ConsoleLogger extends AbstractLogger { public ConsoleLogger(int level) { this.level = level; } [@Override](https://my.oschina.net/u/1162528) protected void write(String message) { System.out.println("Standard Console::Logger: " + message); } } public class ErrorLogger extends AbstractLogger { public ErrorLogger(int level) { this.level = level; } [@Override](https://my.oschina.net/u/1162528) protected void write(String message) { System.out.println("Error Console::Logger: " + message); } } public class FileLogger extends AbstractLogger { public FileLogger(int level) { this.level = level; } [@Override](https://my.oschina.net/u/1162528) protected void write(String message) { System.out.println("File::Logger: " + message); } } public class ChainPatternDemo { private static AbstractLogger getChainOfLoggers() { AbstractLogger errorLogger = new ErrorLogger(AbstractLogger.ERROR); AbstractLogger fileLogger = new FileLogger(AbstractLogger.DEBUG); AbstractLogger consoleLogger = new ConsoleLogger(AbstractLogger.INFO); errorLogger.setNextLogger(fileLogger); fileLogger.setNextLogger(consoleLogger); return errorLogger; } public static void main(String[] args) { AbstractLogger loggerChain = getChainOfLoggers(); loggerChain.logMessage(AbstractLogger.INFO, "This is an information."); System.out.println(); loggerChain.logMessage(AbstractLogger.DEBUG, "This is an debug level information."); System.out.println(); loggerChain.logMessage(AbstractLogger.ERROR, "This is an error information."); System.out.println(); } }
运行结果 Standard Console::Logger: This is an information. File::Logger: This is an debug level information. Standard Console::Logger: This is an debug level information. Error Console::Logger: This is an error information. File::Logger: This is an error information. Standard Console::Logger: This is an error information.
实现二
模拟Mail邮件处理 以及 Enum 的运用来演示责任链模式 public class Enums { private static Random rand = new Random(47); public static > T random(Class ec) { return random(ec.getEnumConstants()); } public static T random(T[] values) { return values[rand.nextInt(values.length)]; } } class Mail { // The NO's lower the probability of random selection: enum GeneralDelivery { YES, NO1, NO2, NO3, NO4, NO5 } enum Scannability { UNSCANNABLE, YES1, YES2, YES3, YES4 } enum Readability { ILLEGIBLE, YES1, YES2, YES3, YES4 } enum Address { INCORRECT, OK1, OK2, OK3, OK4, OK5, OK6 } enum ReturnAddress { MISSING, OK1, OK2, OK3, OK4, OK5 } GeneralDelivery generalDelivery; Scannability scannability; Readability readability; Address address; ReturnAddress returnAddress; static long counter = 0; long id = counter++; public String toString() { return "Mail " + id; } public String details() { return toString() + ", General Delivery: " + generalDelivery + ", Address Scanability: " + scannability + ", Address Readability: " + readability + ", Address Address: " + address + ", Return address: " + returnAddress; } // Generate test Mail: public static Mail randomMail() { Mail m = new Mail(); m.generalDelivery = Enums.random(GeneralDelivery.class); m.scannability = Enums.random(Scannability.class); m.readability = Enums.random(Readability.class); m.address = Enums.random(Address.class); m.returnAddress = Enums.random(ReturnAddress.class); return m; } public static Iterable generator(final int count) { return new Iterable() { int n = count; public Iterator iterator() { return new Iterator() { public boolean hasNext() { return n-- > 0; } public Mail next() { return randomMail(); } public void remove() { // Not implemented throw new UnsupportedOperationException(); } }; } }; } } public class PostOffice { enum MailHandler { GENERAL_DELIVERY { boolean handle(Mail m) { switch (m.generalDelivery) { case YES: System.out.println("Using general delivery for " + m); return true; default: return false; } } }, MACHINE_SCAN { boolean handle(Mail m) { switch (m.scannability) { case UNSCANNABLE: return false; default: switch (m.address) { case INCORRECT: return false; default: System.out.println("Delivering " + m + " automatically"); return true; } } } }, VISUAL_INSPECTION { boolean handle(Mail m) { switch (m.readability) { case ILLEGIBLE: return false; default: switch (m.address) { case INCORRECT: return false; default: System.out.println("Delivering " + m + " normally"); return true; } } } }, RETURN_TO_SENDER { boolean handle(Mail m) { switch (m.returnAddress) { case MISSING: return false; default: System.out.println("Returning " + m + " to sender"); return true; } } }; abstract boolean handle(Mail m); } static void handle(Mail m) { for (MailHandler handler : MailHandler.values()) if (handler.handle(m)) return; System.out.println(m + " is a dead letter"); } public static void main(String[] args) { for (Mail mail : Mail.generator(10)) { System.out.println(mail.details()); handle(mail); System.out.println("*****"); } } }
运行结果： Mail 0, General Delivery: NO2, Address Scanability: UNSCANNABLE, Address Readability: YES3, Address Address: OK1, Return address: OK1 Delivering Mail 0 normally ***** Mail 1, General Delivery: NO5, Address Scanability: YES3, Address Readability: ILLEGIBLE, Address Address: OK5, Return address: OK1 Delivering Mail 1 automatically ***** Mail 2, General Delivery: YES, Address Scanability: YES3, Address Readability: YES1, Address Address: OK1, Return address: OK5 Using general delivery for Mail 2 ***** Mail 3, General Delivery: NO4, Address Scanability: YES3, Address Readability: YES1, Address Address: INCORRECT, Return address: OK4 Returning Mail 3 to sender ***** Mail 4, General Delivery: NO4, Address Scanability: UNSCANNABLE, Address Readability: YES1, Address Address: INCORRECT, Return address: OK2 Returning Mail 4 to sender ***** Mail 5, General Delivery: NO3, Address Scanability: YES1, Address Readability: ILLEGIBLE, Address Address: OK4, Return address: OK2 Delivering Mail 5 automatically ***** Mail 6, General Delivery: YES, Address Scanability: YES4, Address Readability: ILLEGIBLE, Address Address: OK4, Return address: OK4 Using general delivery for Mail 6 ***** Mail 7, General Delivery: YES, Address Scanability: YES3, Address Readability: YES4, Address Address: OK2, Return address: MISSING Using general delivery for Mail 7 ***** Mail 8, General Delivery: NO3, Address Scanability: YES1, Address Readability: YES3, Address Address: INCORRECT, Return address: MISSING Mail 8 is a dead letter ***** Mail 9, General Delivery: NO1, Address Scanability: UNSCANNABLE, Address Readability: YES2, Address Address: OK1, Return address: OK4 Delivering Mail 9 normally *****
参考及引用
1.《Java编程思想（第四版）》
2.责任链模式

「深度学习福利」大神带你进阶工程师,立即查看>>>
一个 cron 表达式是以 6-7 时间字段来定义一个计划任务是如何按照时间被执行的。每一个字段中的数据库而已为数字或者是一些特定的字符串来进行表达。每一个字段是使用空格或者 tab 进行分隔的。
下面的表格中显示了每一字段中可以被使用的字符和被允许的值。
你可以为这些字段指定一些特殊的值在 cron 表达式中,能够为你提供更多的世界控制和计划任务的频率控制。最常用的字符包括有： '*' — 一个通配符,表示的是所有允许的值。 '?' — 表达的是忽略这个字段的意思。当这个字段被设置后,这个字段表示的是计划任务在这个时间点没边际（例如： 'Month', 'Day of week' 或者'Year'）。
有关更多 Confluence 的表达式,请参考 Cron Trigger tutorial on the Quartz website 页面中的内容。

一个 cron 表达式是以 6-7 时间字段来定义一个计划任务是如何按照时间被执行的。每一个字段中的数据库而已为数字或者是一些特定的字符串来进行表达。每一个字段是使用空格或者 tab 进行分隔的。 下面的表格中显示了每一字段中可以被使用的字符和被允许的值。 你可以为这些字段指定一些特殊的值在 cron 表达式中,能够为你提供更多的世界控制和计划任务的频率控制。最常用的字符包括有： '*' — 一个通配符,表示的是所有允许的值。 '?' — 表达的是忽略这个字段的意思。当这个字段被设置后,这个字段表示的是计划任务在这个时间点没边际（例如： 'Month', 'Day of week' 或者'Year'）。 有关更多 Confluence 的表达式,请参考 Cron Trigger tutorial on the Quartz website 页面中的内容。

1	秒（Seconds）	0-59	是（Yes）
2	分钟（Minutes）	0-59	是（Yes）
3	小时（Hours）	0-23	是（Yes）
4	每月中的天（Day of month）	1-31	是（Yes） 5	6	7 月（Month）	每周中的天（Day of week）	年（Year） 1-12 or JAN-DEC	1-7 or SUN-SAT	1970-2099 是（Yes）	是（Yes）	否（No）

* 包括有特殊字符
https://www.cwiki.us/display/CONF6ZH/Scheduled+Jobs 秒（Seconds） 0-59 是（Yes）

2	分钟（Minutes）	0-59	是（Yes）
3	小时（Hours）	0-23	是（Yes）
4	每月中的天（Day of month）	1-31	是（Yes） 5	6	7 月（Month）	每周中的天（Day of week）	年（Year） 1-12 or JAN-DEC	1-7 or SUN-SAT	1970-2099 是（Yes）	是（Yes）	否（No）

* 包括有特殊字符
https://www.cwiki.us/display/CONF6ZH/Scheduled+Jobs

「深度学习福利」大神带你进阶工程师,立即查看>>>
下面是有关你可以调整的计划任务列表。

Confluence 备份（Back Up Confluence）	对 Confluence 站点执行 备份 操作。	每集群（Per cluster）	At 2am every day
检查集群安全（Check Cluster Safety）	针对集群方式的 Confluence 安装,这个计划任务将会保证在集群中只有一个 Confluence 节点向数据库中写入信息。 针对标准方式（非集群方式）版本的 Confluence,这个任务被用来警告用户,谁错误的连接到第二个 Confluence 数据库实例,这个数据库已经被一个 Confluence 使用了。in use.	每集群（Per cluster）	Every 30 seconds
清理 Journal 实体（Clean Journal Entries）	周期化的清理 journal 实体,这个能够保证数据的大小能够保持正常的增长速度而避免过度膨胀。	每节点（Per node）	每天的 2 AM
清理临时目录（Clean Temporary Directory）	清理 /temp 目录中的临时文件。这个目录被导出任务或其他一些任务创建。 这个清理不包括 Confluence 安装目录中文件的清理。	每节点（Per node）	每天的 4 AM
清理过期的邮件错误（Clear Expired Mail Errors）	清理 The Mail Queue 队列中的通知错误。当一个邮件因为某个原因而发送失败没有发送成功的话,一个通知错误将会被发送到邮件错误队列中。	每集群（Per cluster）	每天的 3 AM
清理过期的记住我令牌（Clear Expired Remember Me Tokens）	清理所有过期的记住我（Remember Me）令牌。记住我这个令牌超过两周后就会过期。	每集群（Per cluster）	每个月的 20 号
邮件每日报表（Email Daily Reports）	针对 Confluence 的内容的修改,为 所有订阅者 发送每天的更新通知。 所有有关 Confluence 的内容修改记录将会只记录最后 24 小时的修改。这个推荐你只能修改任务发送邮件的时间为每 24 个小时中的某一个时间、	每集群（Per cluster）	每天的 12 AM
刷新边际索引队列（Flush Edge Index Queue）	刷新边际索引队列,能够保证 Confluence 的索引是最新的索引。	每节点（Per node）	每 30 秒
刷新本地任务队列（Flush Local Task Queue）	刷新本地任务队列。（Confluence 的内部任务通常具有很高的刷新频率）。	每节点（Per node）	每分钟
刷新邮件队列（Flush Mail Queue）	发送 mail queue 队列中已经队列的邮件通知。这并不包括批量的通知。编辑 发送批量的通知（ Send batched notifications ）任务,如果你同时希望修改通知的发送频率包括页面或者博客的更新。	每集群（Per cluster）	每分钟
发送批量通知（Send batched notifications）	从有关上次任务运行后,发送有关页面或者博客更新的邮件通知。如果邮件并不是很多的话,可以增加这个发送的频率,如果你有很多邮件通知的话,你可以减少发送邮件的频率。这个设置对 Confluence 的性能提升会有很大的影响。	每集群（Per cluster）	每 10 分钟 刷新任务队列（Flush Task Queue）	发送推荐更新邮件（Send Recommended Updates Email）	清理老的计划任务运行信息（Purge Old Job Run Details） 刷新任务队列（Confluence 的内部任务通常具有很高的刷新频率）。	触发发送推荐更新邮件给用户。这个任务是每个小时运行一次的,但是用户可以收到每周更新或者每日更新,这个是根据用户自己属性的设置不同而不同的。这个时间与时区是对应的。	Confluence 存储每一个计划任务的运行情况在数据库表 scheduler_run_details 中。为了保持数据库中保存有足够的信息,但是又不至于扩大数据库的存储,清理老的计划任务细节（ Purge Old Job Run Details ）任务将会日常运行删除细节： 超过 90 的天成功任务。 超过 7 天的未成功的任务。 有可以重置 system properties 中的一些设置； jobs.limit.per.purge , all.jobs.ttl.hours and unsuccessful.jobs.ttl.hours 。 每节点（Per node）	每集群（Per cluster）	每集群（Per cluster） 每分钟	每小时	每天的 11 PM

https://www.cwiki.us/display/CONF6ZH/Scheduled+Jobs

「深度学习福利」大神带你进阶工程师,立即查看>>>
希望查看一个计划任务最后运行的时间和这个计划任务最后一次运行花费了多长时间。单击计划任务边上的 历史（History ） 连接。
如果一个计划任务从来没有运行的胡啊,那么这个历史的链接是不会显示的。
屏幕截图：任务执行历史
https://www.cwiki.us/display/CONF6ZH/Scheduled+Jobs

「深度学习福利」大神带你进阶工程师,立即查看>>>
结合Dubbo官方文档,我们分别理解一下各个层次的设计要点：
服务接口层（Service）：该层是与实际业务逻辑相关的,根据服务提供方和服务消费方的业务设计对应的接口和实现。
配置层（Config）：对外配置接口,以ServiceConfig和ReferenceConfig为中心,可以直接new配置类,也可以通过spring解析配置生成配置类。
服务代理层（Proxy）：服务接口透明代理,生成服务的客户端Stub和服务器端Skeleton,以ServiceProxy为中心,扩展接口为ProxyFactory。
服务注册层（Registry）：封装服务地址的注册与发现,以服务URL为中心,扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心,此时服务提供方直接暴露服务。
集群层（Cluster）：封装多个提供者的路由及负载均衡,并桥接注册中心,以Invoker为中心,扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方,实现对服务消费方来透明,只需要与一个服务提供方进行交互。
监控层（Monitor）：RPC调用次数和调用时间监控,以Statistics为中心,扩展接口为MonitorFactory、Monitor和MonitorService。
远程调用层（Protocol）：封将RPC调用,以Invocation和Result为中心,扩展接口为Protocol、Invoker和Exporter。Protocol是服务域,它是Invoker暴露和引用的主功能入口,它负责Invoker的生命周期管理。Invoker是实体域,它是Dubbo的核心模型,其它模型都向它靠扰,或转换成它,它代表一个可执行体,可向它发起invoke调用,它有可能是一个本地的实现,也可能是一个远程的实现,也可能一个集群实现。
信息交换层（Exchange）：封装请求响应模式,同步转异步,以Request和Response为中心,扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
网络传输层（Transport）：抽象mina和netty为统一接口,以Message为中心,扩展接口为Channel、Transporter、Client、Server和Codec。
数据序列化层（Serialize）：可复用的一些工具,扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。
根据官方提供的,对于上述各层之间关系的描述,如下所示：
在RPC中,Protocol是核心层,也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用,然后在Invoker的主过程上Filter拦截点。
图中的Consumer和Provider是抽象概念,只是想让看图者更直观的了解哪些类分属于客户端与服务器端,不用Client和Server的原因是Dubbo在很多场景下都使用Provider、Consumer、Registry、Monitor划分逻辑拓普节点,保持统一概念。
而Cluster是外围概念,所以Cluster的目的是将多个Invoker伪装成一个Invoker,这样其它人只要关注Protocol层Invoker即可,加上Cluster或者去掉Cluster对其它层都不会造成影响,因为只有一个提供者时,是不需要Cluster的。
Proxy层封装了所有接口的透明化代理,而在其它层都以Invoker为中心,只有到了暴露给用户使用时,才用Proxy将Invoker转成接口,或将接口实现转成Invoker,也就是去掉Proxy层RPC是可以Run的,只是不那么透明,不那么看起来像调本地服务一样调远程服务。
而Remoting实现是Dubbo协议的实现,如果你选择RMI协议,整个Remoting都不会用上,Remoting内部再划为Transport传输层和Exchange信息交换层,Transport层只负责单向消息传输,是对Mina、Netty、Grizzly的抽象,它也可以扩展UDP传输,而Exchange层是在传输层之上封装了Request-Response语义。
Registry和Monitor实际上不算一层,而是一个独立的节点,只是为了全局概览,用层的方式画在一起。
服务定义
服务是围绕服务提供方和服务消费方的,服务提供方实现服务,而服务消费方调用服务。
服务注册
对于服务提供方,它需要发布服务,而且由于应用系统的复杂性,服务的数量、类型也不断膨胀；对于服务消费方,它最关心如何获取到它所需要的服务,而面对复杂的应用系统,需要管理大量的服务调用。而且,对于服务提供方和服务消费方来说,他们还有可能兼具这两种角色,即既需要提供服务,有需要消费服务。
通过将服务统一管理起来,可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。Dubbo提供的注册中心有如下几种类型可供选择：
Multicast注册中心
Zookeeper注册中心
Redis注册中心
Simple注册中心
服务监控
无论是服务提供方,还是服务消费方,他们都需要对服务调用的实际状态进行有效的监控,从而改进服务质量。
远程通信与信息交换
远程通信需要指定通信双方所约定的协议,在保证通信双方理解协议语义的基础上,还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通信框架,主要包括如下几个：
Mina
Netty
Grizzly

「深度学习福利」大神带你进阶工程师,立即查看>>>
spring 是一个开源框架,是为了解决企业应用程序开发,功能如下
◆目的：解决企业应用开发的复杂性
◆功能：使用基本的JavaBean代替EJB,并提供了更多的企业应用功能
◆范围：任何Java应用
简单来说,Spring是一个轻量级的控制反转（IoC）和面向切面（AOP）的容器框架。
◆轻量——从大小与开销两方面而言Spring都是轻量的。完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布。并且Spring所需的处理开销也是微不足道的。此外,Spring是非侵入式的：典型地,Spring应用中的对象不依赖于Spring的特定类。
◆控制反转——Spring通过一种称作控制反转（IoC）的技术促进了松耦合。当应用了IoC,一个对象依赖的其它对象会通过被动的方式传递进来,而不是这个对象自己创建或者查找依赖对象。你可以认为IoC与JNDI相反——不是对象从容器中查找依赖,而是容器在对象初始化时不等对象请求就主动将依赖传递给它。
◆面向切面——Spring提供了面向切面编程的丰富支持,允许通过分离应用的业务逻辑与系统级服务（例如审计（auditing）和事务（transaction）管理）进行内聚性的开发。应用对象只实现它们应该做的——完成业务逻辑——仅此而已。它们并不负责（甚至是意识）其它的系统级关注点,例如日志或事务支持。
◆容器——Spring包含并管理应用对象的配置和生命周期,在这个意义上它是一种容器,你可以配置你的每个bean如何被创建——基于一个可配置原型（prototype）,你的bean可以创建一个单独的实例或者每次需要时都生成一个新的实例——以及它们是如何相互关联的。然而,Spring不应该被混同于传统的重量级的EJB容器,它们经常是庞大与笨重的,难以使用。
◆框架——Spring可以将简单的组件配置、组合成为复杂的应用。在Spring中,应用对象被声明式地组合,典型地是在一个XML文件里。Spring也提供了很多基础功能（事务管理、持久化框架集成等等）,将应用逻辑的开发留给了你。
所有Spring的这些特征使你能够编写更干净、更可管理、并且更易于测试的代码。它们也为Spring中的各种模块提供了基础支持。
Spring的两大核心AOP与IOC,可以单独用于任何应用,包括与Struts等MVC框架与Hibernate等ORM框架的集成,目前很多公司所谓的轻量级开发就是用 Spring + Struts(2)+Hibernate。
Spring MVC就是一个MVC框架,个人觉得Spring MVC annotation式的开发比Struts2方便,可以直接代替上面的Struts（当然Struts的做为一个非常成熟的MVC,功能上感觉还是比Spring强一点,不过Spring MVC已经足够用了）。当然spring mvc的执行效率比struts高,是因为struts的值栈影响效率
spring mvc类似于struts的一个MVC开框架,其实都是属于spring,spring mvc需要有spring的架包作为支撑才能跑起来。

「深度学习福利」大神带你进阶工程师,立即查看>>>
Spring Cloud是一系列框架的有序集合。利用Spring Boot的开发模式简化了分布式系统基础设施的开发,如服务发现、注册、配置中心、消息总线、负载均衡、断路器、数据监控等（这里只简单的列了一部分）,都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud将目前比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装,屏蔽掉了复杂的配置和实现原理,最终整合出一套简单易懂、易部署和易维护的分布式系统架构平台。
Spring Cloud的子项目,大致可分成两类：
一类是对现有成熟框架Spring Boot的封装和抽象,也是数量最多的项目；
第二类是开发了一部分分布式系统的基础设施的实现,如Spring Cloud Stream就是kafka, ActiveMQ这样的角色。开发人员进行微服务的实践,第一类子项目就已经足够使用,如：
Spring Cloud Netflix
　　是对Netflix开发的一套分布式服务框架的封装,包括服务的发现和注册,负载均衡、断路器、REST客户端、请求路由等。
Spring Cloud Config
　　将配置信息中央化保存, 配置Spring Cloud Bus可以实现动态修改配置文件。
Spring Cloud Bus
　　分布式消息队列,是对Kafka, MQ的封装。
Spring Cloud Security
　　对Spring Security的封装,并能配合Netflix使用。
Spring Cloud Zookeeper
　　对Zookeeper的封装,使之能配置其它Spring Cloud的子项目使用。
Spring Cloud Eureka
Spring Cloud Eureka 是 Spring Cloud Netflix 微服务套件中的一部分,它基于Netflix Eureka 做了二次分装,主要负责完成微服务架构中的服务治理功能。

Spring Cloud为未来互联网企业提供分布式基础设施解决方案。同时,随着近几年微服务架构和Docker容器概念的火爆,也会让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地,尤其是在目前五花八门的分布式解决方案中提供了标准化的、全站式的技术方案,有效推进服务端软件系统技术水平提升。
从现在开始,我这边会将近期研发的spring cloud微服务云架构的搭建过程和精髓记录下来,帮助更多有兴趣研发spring cloud框架的朋友,大家来一起探讨spring cloud架构的搭建过程及如何运用于企业项目.完整项目的源码来源 技术支持1791743380

「深度学习福利」大神带你进阶工程师,立即查看>>>
Confluence 支持一些可以从 Java 系统属性中配置的配置参数和调试（debugging ）设置。系统属性通常是使用 -D 为参数选项,这个选项是 Confluence 在运行后设置到 JVM 虚拟机中的。请参考： Configuring System Properties 页面中的内容来获得更多的信息。
开始版本 默认值 模块... 作用和影响

atlassian.forceSchemaUpdate
1.0	false	atlassian-config	在默认的情况下,Confluence 只会在侦测到数据库更新后才会运行数据库 schema 更新。这个标志位将会强制 Confluence 在启动的时候对 schema 进行更新。
confluence.home
1.0	任何文件系统路径	Confluence and atlassian-config	如果这个属性被设置,Confluence 将会忽略 confluence-init.properties 属性文件中配置的信息,使用你在启动的时候指定的路径为 Confluence Home 目录。
confluence.dev.mode
1.0	false	Confluence	针对 Confluence 开发人员,启用更多的 debugging 选项（这个也可能会修改 spring bean 的默认 lazy 初始化方式,将会增加启动时间）。请不要在生产环境中启用这个选项。
confluence.disable.mailpolling
2.4	false	Confluence	如果设置为 "true",将会阻止 Confluence 从已经归档的空间中获得邮件。通过 WEB 界面的 "check for new mail" 进行手动操作依然可用。这个配置将不会影响发送邮件。
confluence.i18n.reloadbundles
1.0	true	Confluence	设置这个属性将会导致 Confluence 在每次国际化（internationalized ）字符查找的时候载入 i18n 资源。这个在对翻译进行测试的时候会非常有用,但是会导致 Confluence 实例 运行缓慢 （ insanely slowly ）。
confluence.ignore.debug.logging
1.0	true	Confluence	当 Confluence 检测到 DEBUG 级别的日志被启用了,Confluence 将会输出服务器的错误信息（DEBUG 级别的日志将会显著的降低服务器性能）。设置这个选项将会输出所有的错误信息。
confluence.jmx.disabled
3.0	false	Confluence	如果被设置为 "true",将会禁用 Confluence 的 JMX 监控。这个与在 WEB-INF/classes/jmxContext.xml 设置 "enabled" 属性是一样的。
confluence.optimize.index.modulo
2.2	20	Confluence	在索引进行优化之前刷新索引的次数。
confluence.plugins.bundled.disable
2.9	false	Confluence	启动 Confluence 的时候不绑定插件。在 Confluence 开发环境中进行快速启动会显得很有效,能够加快启动速度,但是启动的时候绑定插件是 Confluence 一些核心功能所需要的。这个属性不应该在 Confluence 生产环境中设置。
atlassian.indexing.contentbody.maxsize
3.0	1048576	atlassian	当文件上传后,文件的内容被解压并且进行索引,这个功能允许用户不但可以对文件名进行搜索还可以对文件内容进行搜索。 如果解压的内容文件大小超过了设定的值（默认为 1 MB）,文件的内容还是会被索引和查找,但是文件将不会显示在查找结果中。增加这个限制值,将会是查询结果的显示变得缓慢。请参考 Configuring Attachment Size 页面中的更多信息。
atlassian.mail.fetchdisabled
3.5	false	Confluence	为 IMAP 和 POP 禁用邮件过滤服务
atlassian.mail.senddisabled
3.5	false	Confluence and atlassian-mail	禁用发送邮件
atlassian.disable.caches
2.4	true	atlassian-plugins, atlassian-cache-servlet	设置这个属性将会禁用 conditional get 和 expires：一些 WEB 资源的头部（headers ）。这个将会显著降低用户的使用体验,但是在开发环境中就显得非常有用,如果你经常修改一些静态资源但是你又不想持续的刷新你浏览器的缓存。
confluence.html.encode.automatic
2.9		Confluence	设置这个属性将会强制 antixss 编码打开或关闭,将会覆盖 settings 中的设置。默认的表现针对 Confluence 的版本不同而不同。
org.osgi.framework.bootdelegation
2.10	empty	atlassian-plugins	Comma-separated 为 OSGi 插件提供包的的列表名。基本上当 Confluence 进行 profiling 的时候是需要的。例如："com.jprofiler. ,com.yourkit. "。
confluence.diff.pool.size
3.1	20	Confluence	当前最大不同的数量。如果超过了这个值,其他通过 RSS 创建的 diffs 将会忽略和日志（RSS 请求还是会显示成功,但是将会丢失 diffs 信息）。
confluence.diff.timeout
3.1	1000	Confluence	在比较 2 个页面版本的时候,diff 操作王朝等待的时间（毫秒）。在这个时间内完成否则将会显示错误信息。
confluence.html.diff.timeout
4.0	10000	Confluence	在比较 2 个页面版本的时候,diff 操作完成等待的时间（毫秒）。在这个时间内完成否则将会显示取消并显示错误信息。
atlassian.user.experimentalMapping
2.10	false	Confluence	设置这个属性将会修改本地用户和本地用户组之间的关系来避免在向本地系统中导入大量用户产生的性能问题。请注意,设置这个选项为启用的话将会降低其他用户管理功能的速度。我们建议仅仅在向系统中大量导入用户和用户组出现性能出现问题的时候才启用这个选项。请参考 CONF-12319 ,针对这个问题在 Confluence 3.1.1 中我们已经修复了。
confluence.import.use-experimental-importer
3.2	false	Confluence	设置这个属性来修改 Confluence 使用 测试 XML 导入器（Experimental XML Importer）。这个被设置为能更稳定的导入数据到 Confluence 中,但是在 Confluence 3.2 发布的时候,这个导入功能未测试大数据量的导入,所以也不提供支持。
atlassian.webresource.disable.minification
3.3	false	atlassian-plugins	禁用 Confluence 服务器的 JavaScript 和 CSS 资源自动压缩。
index.queue.thread.count
3.3	See "Effect"	Confluence	设置重新索引可以使用的线程数量大小。这个值可以被设置为从 1 到 50 （包括 50）。例如,最小一个线程但是最多不超过 50 个线程。这个配置没有默认值。例如： 如果你没有设置 index.queue.thread.count ,这个线程值被用来计算需要的线程,基于需要重新索引的对象和可用的进程（最多可用设置 50 可用的线程）。 如果设置 index.queue.thread.count=2 ,那么只有 2 个线程被在重新索引的时候使用（与被重新索引的对象和可用的进程的数量无关）。 如果设置 index.queue.thread.count=200 ,那么 10 个进程（最多允许的数量）将会被在重新索引的时候使用。 注意：从 Confluence 3.3 到 5.6 最多进程的数量是 10。
index.queue.batch.size
3.3	1500	Confluence	索引可以使用的批次。减少这个值将会降低索引时候的系统消耗,但是会增加索引所需要的系统时间让索引将会花费更多的时间。增加这个值将会让索引更快的完成,但是也会增加系统的复杂,降低系统性能。通常的情况下,这个设置不需要进行修改。
password.confirmation.disabled
3.4	false	Confluence	这个属性将会禁用密码校验功能,这个功能能够为 Confluence 提供额外的安全性。当这个参数不设置的时候,Confluence 将会对下面的操作 不进行 密码校验： administrative actions ,修改电子邮件地址和 Captcha for failed logins 。如果你使用的是用户授权的话,禁用这个密码校验功能就比较有用。
confluence.browser.language.enabled
3.5	true	Confluence	如果设置这个属性为 "false",将会禁用侦测浏览器头部（headers）的语言配置,在早期 Confluence 的发行版本中被用来重置 Confluence 的表现。设置这个属性为 "true" 的话,将会启用侦测浏览器使用的语言。Confluence 将会根据侦测到的语言来设置 Confluence 的 UI 表现。请参考 Edit Your User Settings 文档中的内容来了解用户语言是如何设置的。
upm.pac.disable
Universal Plugin Manager 1.5	false	Universal Plugin Manager (UPM)	当这个属性设置为 ture 的话 UPM 将不会尝试访问 The Atlassian Marketplace 。这个配置在你的 Confluence 服务器不能访问互联网的时候比较重要。请参考 UPM documentation 页面获得更多的有效信息。
confluence.reindex.documents.to .pop
3.5.9	20	Confluence	在进行全部重索引的时候确定一个线程可以索引多少对象。请注意,这个参数不包括附件。
confluence.reindex.attachments.to .pop
3.5.9	10	Confluence	在进行全部重索引的时候确定一个线程可以索引多少附件。
confluence.upgrade.active.directory
3.5.11	false	Confluence	强制 Confluence 将任何 LDAP 目录都合并为 AD（Active Directory）,而不是紧急依赖查找用户属性中的 sAMAccountName 。如果你是从 Confluence 3.5 之前的版本进行升级的话就非常有用,需要使用一个属性而不是 sAMAccountName 来定义你的用户,同时查找 LDAP: error code 4 - Sizelimit Exceeded 在你日志中的错误。请参考 Unable to Log In with Confluence 3.5 or Later Due to 'LDAP error code 4 - Sizelimit Exceeded 页面中的内容来获得更多的信息。
confluence.context.batching.disable
4.0	false	Confluence	为在上下文（contexts ）中的 Web 资源（例如,编辑者,主页,管理员）禁用批量。如果你需要对 javascript 或 CSS 中的错误进行调试,这个参数非常有用。
com.atlassian.logout.disable.session.invalidation
4.0	false	Confluence	在退出登录的时候禁用会话校验。在 4.0 的时候,默认我们定义的是校验 JSession 被指派给客户端的会话,在用户退出登录的时候。如果这个参数被设置为 true,那么会话将会保持激活（但是用户已经退出登录了）。如果你使用的是外部授权系统,这个设置可能会保持系统的正常工作,但是基本上这个应该是不需要的。
officeconnector.spreadsheet.xlsxmaxsize
4.0.5	2097152	Office Connector	当使用 viewxls 宏的时候,确定 Excel 文件中识别的最大字节。如果设置为 null 的话,默认的参数为 2 MB。请参考 CONF-21043 页面中的内容。
com.atlassian.confluence.extra.calendar3.display.events.calendar.maxpercalendar
	200	Team Calendars	确定没一个日历中可以存储的最多的事件数量。这个参数只在 Team Calendars 插件安装在你 Confluence 站点后有效。
com.atlassian.confluence.allow.downgrade
4.3.2, 5.0-OD-10	false	Confluence	允许你的 Confluence 在新版本的 home 目录配置下启动。请注意,Confluence 不支持在这个配置下运行。你应该明白这个配置将会导致严重的问题,有可能会导致 Confluence 无法启动。请参考 After Downgrading, Confluence Will No Longer Run 页面获得详细信息。ils.
confluence.skip.reindex
	false		当这个参数设置为 true 的时候,允许 Confluence 在 Confluence 升级的时候跳过重构搜索索引。当你的站点很大,内容很多的时候,这个配置很有用。你可以在升级的时候不对索引进行重构,在升级完成后才对索引进行重构。
reindex.thread.count
5.2		Confluence	针对 one-off reindex 设置使用的线程数量。这个值可以设置数量为 1 到 50（包括 50）,例如最少 1 个线程,最多不超过 50 线程被使用。这里没有默认值的设置。这个系统配置不影响 Confluence 增加的索引。
reindex.attachments.thread.count
5.2	4	Confluence	针对附件的重新索引,设置可以使用的线程数量,这个设置运行你降低系统资源在对内容进行索引的时候的消耗。
atlassian.confluence.export.word.max.embedded.images
5.2	50		这个属性限制你在将 Confluence 页面导出为 Word 文档的时候包含图片的数量。当你导出的页面有大量的图片的时候,这些图片将会首先被载入到内存中,可能会导致你系统出现内存溢出的错误。如果你需要导出的页面有大量图片的话,你可以使用这个系统参数临时增加导出数量大小的限制。
confluence.mbox.directory
5.4.1		Confluence	在你 Confluence 中设置 mailboxes 可以导入到 Confluence 中的路径（针对使用 Confluence Mail Archiving 插件）。Mailboxes 不能从其他位置中导入。我们推荐 Confluence 管理在 Confluence 的 Home 目录中创建一个特殊的目录来针对这个操作。在你对这个参数正确设置之前,Mail 是不能导入到系统中的。
confluence.search.max.results
5.5	1000	Confluence	设置这个参数将会设置 Confluence 查找将要返回的最大数量。
confluence.upgrade.recovery.file.enabled
5.5	true	Confluence	在默认的情况,Confluence 将会在升级之前创建一个备份文件。如果你的 Confluence 站点的数据库数量比较庞大,同时你又是使用的是数据库备份的方式来对你的 Confluence 备份的话,这个功能可以安全的关闭。将这个属性设置为 false 的话,Confluence 将会在升级之前不会创建一个系统的备份。
confluence.junit.report.directory
5.5		Confluence	这个属性将会设置 Confluence 服务器的 JUnit 报表从哪个目录导入（针对使用 JUnit Report 宏）。如果这个属性不设置的话,不会使用其他的目录进行导入。我们推荐 Confluence 管理在 Confluence 的 Home 目录中创建一个特殊的目录来针对这个操作。在你对这个参数正确设置之前,JUnit 的测试结果文件不能导入到系统中的。
officeconnector.textextract.word.docxmaxsize
5.5.3	16777216	Confluence	当一个文件被上传,这个文件将会被解压后索引。这个允许人们不仅仅可以对文件名进行查找还可以对文件里面的内容进行查找。 Confluence 将会对 Word 文档中的内容进行解压,但是可以解压的 Word 文档大小有限制（默认限制为 16MB）。这样的设置可能导致你只有部分文件内容可以检索到。请参考页面 Configuring Attachment Size 来获得更多的信息。
cluster.login.rememberme.enabled
5.6	False		在集群环境下,设置这个属性为 True 后,将会在登录界面中启用 'Remember Me' 选择对话框。这个选择不推荐在集群的环境下使用,所以在默认的情况下这里设置为禁用的（例如： 'Remember me' 启用的话,用户可以在不同节点之间进行转换）。 这个设置不对对独立进程安装的 Confluence 产生影响。
confluence.cluster.hazelcast.listenPort
5.6	5801		在集群环境下,这个属性仅仅被用于重置 Hazelcast 将要绑定的默认端口。例如,如果这个端口不可用或者你需要在同一个主机上运行多个节点（不推荐这样做）。默认设置为 5801。
confluence.document.conversion.threads
5.7		Confluence	在文件转换服务中可以使用的线程数量,这个数量是动态计算的,基于实例支票的内存数量的大小和 CPU 内核的数量（通常是 4 到 6 个内核）。这个属性可以被用来修改默认的线程数量。减少这个线程数量可以解决OOME 问题,增加线程数量能够缓解文档在队列中等待的时间过长的问题。
confluence.document.conversion.threads.wait
5.7	1000	Confluence	设置这个属性可以设置转换队列中的最大数量。当达到最大转换数量的时候,任何文件转换的请求将会被丢弃。
confluence.cluster.node.name
5.7		Confluence	设置这个属性可以在数据中心集群模式下的每一个节点一个可读的名字（在页脚显示电子邮件通知）。如果这个属性不设置,Confluence 将会自己为每一个节点指定一个 ID。
confluence.document.conversion.fontpath
5.8.7		Confluence	当你添加其其他使用的字体然后准备读取文件的时候,设置这个属性来定义目录（在预览和缩略图中）。 当你打算使用特定的字体或者在多字节字符中（例如 日文,中文）预览文件的时候比较有用。
confluence.document.conversion.words.defaultfontname
5.8.7		Confluence	设置这个属性来设置在 Confluence 中生成 Word 文档使用的默认字体（ .doc 和 .docx ）。 仅仅指定字体的名字（不是路径）。
confluence.document.conversion.slides.defaultfontname.regular
5.8.7		Confluence	设置这个属性来设置在 Confluence 中生成 Powerpoint 文档使用的默认字体（ .ppt 和 .pptx ）。 仅仅指定字体的名字（不是路径）。
confluence.document.conversion.slides.defaultfontname.asian
5.8.7	TakaoPGothic	Confluence	设置这个属性来设置在 Confluence 中生成 Powerpoint 文档有关亚洲字体使用的默认字体（ .ppt 和 .pptx ）。 仅仅指定字体的名字（不是路径）。
confluence.document.conversion.slides.defaultfontname.symbol
5.8.7		Confluence	设置这个属性来设置在 Confluence 中生成 Powerpoint 文档有关符号字体使用的默认字体（ .ppt 和 .pptx ）。 这个将会用于 bullets 和其他符号,当 Symbol 没有找到的时候。 仅仅指定字体的名字（不是路径）。
confluence.clickjacking.protection.disable
5.8.15	false	Confluence	安全特性将会阻止 Confluence 被嵌入到