分享未来 ^Internet _Technology

MySQL 的复制可以是基于一条语句（Statement Level），也可以是基于一条记录（Rowlevel），可以在MySQL 的配置参数中设定这个复制级别，不同复制级别的设置会影响到Master 端的Binary Log 记录成不同的形式。

1. Row Level：Binary Log 中会记录成每一行数据被修改的形式，然后在Slave 端再对相同的数据进行修改。
优点：在Row Level 模式下，Binary Log 中可以不记录执行的sql 语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以Row Level 的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及trigger 的调用和触发无法被正确复制的问题。
缺点：Row Level 下，所有的执行的语句当记录到Binary Log 中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条update 语句：UPDATE group_message SET group_id = 1 where group_id = 2，执行之后，日志中记录的不是这条update 语句所对应的事件（MySQL 以事件的形式来记录Binary Log 日志），而是这条语句所更新的每一条记录的变化情况，这样就记录成很多条记录被更新的很多个事件。自然，Binary Log 日志的量就会很大。尤其是当执行ALTER TABLE 之类的语句的时候，产生的日志量是惊人的。因为MySQL 对于ALTER TABLE 之类的DDL 变更语句的处理方式是重建整个表的所有数据，也就是说表中的每一条记录都需要变动，那么该表的每一条记录都会被记录到日志中。

2. Statement Level:每一条会修改数据的Query 都会记录到Master 的BinaryLog 中。Slave 在复制的时候SQL 线程会解析成和原来Master 端执行过的相同的Query来再次执行。
优点：Statement Level 下的优点首先就是解决了Row Level 下的缺点，不需要记录每一行数据的变化，减少Binary Log 日志量，节约了IO 成本，提高了性能。因为他只需要记录在Master 上所执行的语句的细节，以及执行语句时候的上下文的信息。
缺点：由于他是记录的执行语句，所以，为了让这些语句在slave 端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master 端执行时候相同的结果。另外就是，由于MySQL现在发展比较快，很多的新功能不断的加入，使MySQL得复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug 也就越容易出现。在statement level 下，目前已经发现的就有不少情况会造成mysql 的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能正确复制，在存储过程中使用了last_insert_id()函数，可能会使slave 和master上得到不一致的id 等等。由于row level 是基于每一行来记录的变化，所以不会出现类似的问题。

Nginx的upstream的四种设置方式

1、轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器 ，如果后端服务器down掉，能自动剔除。

2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 
例如：
[code="plain"]
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
[/code]

2、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session 的问题。
例如：
[code="plain"]
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
[/code]

3、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
[code="plain"]
upstream backend {
server server1;
server server2;
fair;
}
[/code]

4、url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

[code="plain"]
upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
[/code]

Nginx负载均衡设置：

[code="plain"]
upstream bakend{
ip_hash;
#定义负载均衡 设备的Ip及设备状态
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
[/code]
在需要使用负载均衡的server中增加
[code="plain"]
proxy_pass http://bakend/ ;
[/code]

每个设备的状态设置为:
1.down 表示单前的server暂时不参与负载
2.weight 默认为1.weight越大，负载的权重就越大。
3.max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返proxy_next_upstream 模块定义的错误
4.fail_timeout:max_fails次失败后，暂停的时间。
5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。nginx支持同时设置多组的负载均衡，用来给不用的server来使用。

dn：一条记录的位置
dc：一条记录所属区域
ou：一条记录所属组织
cn/uid：一条记录的名字/ID

实际上更多时候我只把它看成数据库。我把它和我非常熟悉的MYSQL数据库做比较，通常会得到更好的理解：

MYSQL用“表”储存数据，LDAP用“树”
MYSQL指定一条记录要3个条件：DB、TABLE、ROW。
LDAP却更自由，为什么呢？因为LDAP数据是“树”状的，而且这棵树是可以无限延伸的，假设你要树上的一个苹果（一条记录），你怎么告诉园丁它的位置呢？当然首先要说明是哪一棵树（dc，相当于MYSQL的DB），然后是从树根到那个苹果所经过的所有“分叉”（ou，呵呵MYSQL里面好象没有这 DD），最后就是这个苹果的名字（uid，记得我们设计MYSQL或其它数据库表时，通常为了方便管理而加上一个‘id’字段吗？）。好了！这时我们可以清晰的指明这个苹果的位置了，就是那棵“歪脖树”的东边那个分叉上的靠西边那个分叉的再靠北边的分叉上的半红半绿的……，晕了！你直接爬上去吧！我还是说说LDAP里要怎么定义一个字段的位置吧，树（dc=waibo,dc=com)，分叉（ou=bei,ou=xi,ou=dong），苹果（cn=honglv），好了！位置出来了：
dn:cn=honglv,ou=bei,ou=xi,ou=dong,dc=waibo,dc=com

一个有名的画家说过：“世上没有相同的2个鸡蛋”。当然也没有相同的2个苹果……，同样，在LDAP里也不可能存在2个相同的dn。

LDAP数据填充原理
一棵树的生长，要循序渐进，如果还没有长出某个分叉，就不可能在那个分叉里长出苹果（问：FT！苹果是长在分叉上的吗？答：为了便于理解，你就当它是吧），同样，LDAP数据库也要一步步的充实，举一个学校数据库的例子，我们将要把一个庞大的学生档案放到LDAP里，大致需要这么做：
---------------------------------------------
1、建立“树根”，这是通过修改“slapd.conf”来实现的，由于现在的目的是理解，所以具体步骤就不说了，反正就是在这一步建立了一个 “dc=ourschool,dc=org”这样一个“树根”。注意：我把它理解成“目录”，或者“容器”，甚至它本身也是文件（苹果）的特殊形式，熟悉 LINUX文件系统的朋友会更容易理解。
2、建立18个系，分别是“dn:ou=computer,dc=ourschool,dc=org”、“dn:ou=film,dc=ourschool,dc=org”……
3、当然是在每个系里面建立专业，比如“dn:ou=linux,ou=computer,dc=ourschool,dc=org”……
4、（开始长苹果吧！）加学生喽——“dn:cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org”……
5、已经完成了吗？对了！学生的详细信息还没有呐！不过先这样吧，反正记录是可以编辑的。

LDAP记录的详细信息
dn:cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org
objectClass：organizationalPerson
cn:stan
cn:小刀
sn:小刀
description:agoodboy
（以上是一条记录的信息，如果把他保存成LDIF文件，可以导入到LDAP数据库中）
上面不是说没有学生详细信息吗？怕你着急，就马上写出来了，只是还没有导入到LDAP里，那是以后的事。这里我先就你可能会产生的疑问做回答。
---------------------------------------------
Q1：“cn”不是在“dn”里定义了吗，怎么又在后面重新定义了？答：你要把“cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org”看成是一个整体，它只是属性dn的值。
Q2：怎么后面有2个“cn”，我以哪个为准？答：区别于普通数据库，LDAP每个属性一般可以具有多个值，这样不好吗？你在学校数据库里找我的时候，只要记得我的一个cn就可以了，用“cn=stan”或“cn=小刀”都可以找到我！
Q3：就这些属性了吗？我都不知道你是男是女。答：先声明，偶是男地。LDAP对记录的属性做了严格的限制（这一点我不太喜欢），也就是说，你可以用哪些属性，哪些属性不能为空，哪些属性最多只能有一个值等，他们都给你规定好了。幸好你有选择的权利，比如这次我们是储存学生信息，那么我们就定义一个 “objectClass：organizationalPerson”，这样“organizationalPerson”这个类所规定的所有属性我们都可以用了，而且确实很适合我们。虽然这个类中没有“sex”这个属性，不过你完全可以用一个“空闲”的属性来顶替。

Apache与Tomcat有三种连接方式：

1. JK(Apache中需要加载的模块包括：mod_jk.so)

通过AJP协议连接

2. http_Proxy(Apache中需要加载的模块包括：mod_proxy.so,mod_proxy_http.so)

通过HTTP协议连接

3. ajp_proxy(Apache中需要加载的模块包括：mod_proxy.so,mod_proxy_ajp.so)

通过AJP协议连接

 

------------------------------------------华丽的分割线----------------------------------------

 

Tomcat优化小记：

1. Tomcat默认是使用128M内存，可以手动在catalina.sh文件中增加内存

设置的参数有：

JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'

最大内存最好是真实机器的内存的80%

2. 关闭Tomcat的lookupdns功能，设置enableLookups=“false”，避免因为Tomcat查询dns而占用网络带宽。

3. 通过修改

maxThreads   #Tomcat 使用线程来处理接收的每个请求。这个值表示Tomcat 可创建的最大的线程数。
acceptCount    #指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。
connnectionTimeout    #网络连接超时，单位：毫秒。设置为0 表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。
minSpareThreads    #Tomcat 初始化时线程池中最小允许空闲的线程数。
maxSpareThreads   #Tomcat线程池最大允许空闲的线程数，如果空余线程数超过最大值那么Tomcat 就会关闭不再需要的线程。

线程池一般有三个重要参数：
a. 最大线程数。在程序运行的任何时候，线程数总数都不会超过这个数。如果请求数量超过最大数时，则会等待其他线程结束后再处理。
b. 最大共享线程数，即最大空闲线程数。如果当前的空闲线程数超过该值，则多余的线程会被杀掉。
c. 最小共享线程数，即最小空闲线程数。如果当前的空闲数小于该值，则一次性创建这个数量的空闲线程，所以它本身也是一个创建线程的步长。

4.  加速JSP 编译速度
当第一次访问一个JSP 文件时，它会被转换为Java serverlet 源码，接着被编译成Java字节码。你可以控制使用哪个编译器，默认情况下，Tomcat 使用使用命令行javac 进行使用的编译器。也可以使用更快的编译器，但是这里我们将介绍如何优化它们。