grep常用方法

1.将/etc/passwd,有出现 root 的行取出来
# grep root /etc/passwd

2.将/etc/passwd,有出现 root 的行取出来,同时显示这些行在/etc/passwd的行号
# grep -n root /etc/passwd

3.将/etc/passwd,将没有出现 root 的行取出来
# grep -v root /etc/passwd

4.将/etc/passwd,将没有出现 root 和nologin的行取出来
# grep -v root /etc/passwd | grep -v nologin

5.用dmesg 列出核心信息,再以 grep 找出内含 eth 那行,要将捉到的关键字显色,且加上行号来表示:
[root@www ~]# dmesg | grep -n –color=auto ‘eth’

6.用dmesg 列出核心信息,再以 grep 找出内含 eth 那行,在关键字所在行的前两行与后三行也一起捉出来显示
[root@www ~]# dmesg | grep -n -A3 -B2 –color=auto ‘eth’

7.根据文件内容递归查找目录
# grep ‘maxianwei.cn’ *      #在当前目录搜索带’maxianwei.cn’行的文件
# grep -r ‘maxianwei.cn’ *     #在当前目录及其子目录下搜索”行的文件
# grep -l -r ‘maxianwei.cn’ *    #在当前目录及其子目录下搜索’maxianwei.cn’行的文件,但是不显示匹配的行,只显示匹配的文件

具体grep相关参数可以参考:https://www.runoob.com/linux/linux-comm-grep.html

linux sed 批量替换字符串

sed是一种流编编器,它是文本处理中非常中的工具,能够完美的配合正则表达式便用,功物能不同凡响。详细的功能网上很多,这里就不多说了,项目中我要批量替换静态文件的一个域名具体操作如下:

命令如下:

sed -i "s/原字符串/新字符串/g" `grep 原字符串 -rl 所在目录`

例如:我要把 www.maixianwei.cn 替换为 cdn.maxianwei.cn,执行命令:

sed -i "s/www.maxianwei.cn/cnd.maxianwei.cn/g" `grep www.maxianwei.cn -rl /www`

-i 表示inplace edit,就地修改文件

-r 表示搜索子目录

-l 表示输出匹配的文件名

修改前,要注意备份文件。

如果文件太多 可以分批进行 比如:

[root@localhost html]# sed -i “s/maxianwei.cn\/upload/maxianwei.c\/upload/g” `grep admin.maxianwei.cn -rl ./12*.html`

nginx 常用变量

常用变量

$args : #这个变量等于请求行中的参数,同$query_string
$content_length : 请求头中的Content-length字段。
$content_type : 请求头中的Content-Type字段。
$document_root : 当前请求在root指令中指定的值。
$host : 请求主机头字段,否则为服务器名称。
$http_user_agent : 客户端agent信息
$http_cookie : 客户端cookie信息
$limit_rate : 这个变量可以限制连接速率。
$status 请求状态
$body_bytes_sent 发送字节
$request_method : 客户端请求的动作,通常为GET或POST。
$remote_addr : 客户端的IP地址。
$remote_port : 客户端的端口。
$remote_user : 已经经过Auth Basic Module验证的用户名。
$request_filename : 当前请求的文件路径,由root或alias指令与URI请求生成。
$scheme : HTTP方法(如http,https)。
$server_protocol : 请求使用的协议,通常是HTTP/1.0或HTTP/1.1。
$server_addr : 服务器地址,在完成一次系统调用后可以确定这个值。
$server_name : 服务器名称。
$server_port : 请求到达服务器的端口号。
$request_uri : 包含请求参数的原始URI,不包含主机名,如:”/foo/bar.php?arg=baz”。
$uri : 不带请求参数的当前URI,$uri不包含主机名,如”/foo/bar.html”。
$document_uri : 与$uri相同。

Linux启动或禁止SSH用户及IP的登录

1:Linux启动或禁止SSH root用户的登录

2:Linux限制SSH用户

其实这些东西就是修改一个系统的配置文件

[root@rhsde ~]# vi /etc/ssh/sshd_config

我们可以查看

#PermitRootLogin yes

把前面的#号去掉,yes修改为no即可

yes 就是可以使用SSH方式的root登录

no就是禁止使用SSH方式的root登录

另外如果需要限制SSH方式的用户登录 修改如下参数

AllowUsers arcsde

arcsde是我操作系统的用户,如果没有用户可以手动添加AllowUsers

这样的话,只能arcsde登录了

其他用户登录不了了(oracle)

login as: oracle
oracle@192.168.220.165’s password:
Access denied
oracle@192.168.220.165’s password:

以上修改完配置文件,必须重新启动SSH服务才能生效

[root@rhsde ~]# /etc/init.d/sshd restart
Stopping sshd: [ OK ]
Starting sshd: [ OK ]

可能会有人会问到如果我设置了,每次都是Access denied,有没有一些可以进行信息的提示,这肯定可以啊

我们可以修改如下文件

[root@rhsde ~]# vi /etc/issue.net

然后添加如下信息

###############################################################
# Welcome to redhatserver #
# All connections are monitored and recorded #
# Disconnect IMMEDIATELY if you are not an authorized user! #
# Please tel 400-819-2881
###############################################################

我们仍然需要修改sshd_config里面的参数

Banner /etc/issue.net

后面对应的就是相关文件的路径,重启服务即可

然后我们测试一下

login as: root
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Kernel \r on an \m
###############################################################
# Welcome to redhatserver #
# All connections are monitored and recorded

#
# Disconnect IMMEDIATELY if you are not an authorized user! #
#Please tel 400-819-2881
###############################################################
root@192.168.220.165’s password:

当我们输入root用户,系统就自动提示了。另外也可以在输入密码的时候提示,如果是这样的话,我们修改如下文件即可

vi /etc/motd

启动或禁止用户IP登录

除了可以禁止某个用户登录,我们还可以针对固定的IP进行禁止登录,这里面其实就是修改了配置文件

查看 /etc/hosts.allow配置文件,设置允许登录的IP

[root@rhsde ~]# more /etc/hosts.allow
#
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the ‘/usr/sbin/tcpd’ server.
#
sshd:192.168.220.164:allow

查看/etc/hosts.deny文件,设置sshd:ALL

[root@rhsde ~]# more /etc/hosts.deny
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the ‘/usr/sbin/tcpd’ server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!
sshd:ALL

也就是说,我们禁止所有IP,但是允许相关IP登录。

另外,如果对sshd_config文件中的配置参数感兴趣可以参考:http://doc.licess.org/openssh/sshd_config.html

SSHD_CONFIG(5) OpenBSD Programmer’s Manual SSHD_CONFIG(5)
名称
sshd_config – OpenSSH SSH 服务器守护进程配置文件
大纲
/etc/ssh/sshd_config
描述
sshd(8) 默认从 /etc/ssh/sshd_config 文件(或通过 -f 命令行选项指定的文件)读取配置信息。
配置文件是由”指令 值”对组成的,每行一个。空行和以’#’开头的行都将被忽略。
如果值中含有空白符或者其他特殊符号,那么可以通过在两边加上双引号(“)进行界定。
[注意]值是大小写敏感的,但指令是大小写无关的。
当前所有可以使用的配置指令如下:
AcceptEnv
指定客户端发送的哪些环境变量将会被传递到会话环境中。[注意]只有SSH-2协议支持环境变量的传递。
细节可以参考 ssh_config(5) 中的 SendEnv 配置指令。
指令的值是空格分隔的变量名列表(其中可以使用’*’和’?’作为通配符)。也可以使用多个 AcceptEnv 达到同样的目的。
需要注意的是,有些环境变量可能会被用于绕过禁止用户使用的环境变量。由于这个原因,该指令应当小心使用。
默认是不传递任何环境变量。
AddressFamily
指定 sshd(8) 应当使用哪种地址族。取值范围是:”any”(默认)、”inet”(仅IPv4)、”inet6″(仅IPv6)。
AllowGroups
这个指令后面跟着一串用空格分隔的组名列表(其中可以使用”*”和”?”通配符)。默认允许所有组登录。
如果使用了这个指令,那么将仅允许这些组中的成员登录,而拒绝其它所有组。
这里的”组”是指”主组”(primary group),也就是/etc/passwd文件中指定的组。
这里只允许使用组的名字而不允许使用GID。相关的 allow/deny 指令按照下列顺序处理:
DenyUsers, AllowUsers, DenyGroups, AllowGroups
AllowTcpForwarding
是否允许TCP转发,默认值为”yes”。
禁止TCP转发并不能增强安全性,除非禁止了用户对shell的访问,因为用户可以安装他们自己的转发器。
AllowUsers
这个指令后面跟着一串用空格分隔的用户名列表(其中可以使用”*”和”?”通配符)。默认允许所有用户登录。
如果使用了这个指令,那么将仅允许这些用户登录,而拒绝其它所有用户。
如果指定了 USER@HOST 模式的用户,那么 USER 和 HOST 将同时被检查。
这里只允许使用用户的名字而不允许使用UID。相关的 allow/deny 指令按照下列顺序处理:
DenyUsers, AllowUsers, DenyGroups, AllowGroups
AuthorizedKeysFile
存放该用户可以用来登录的 RSA/DSA 公钥。
该指令中可以使用下列根据连接时的实际情况进行展开的符号:
%% 表示’%’、%h 表示用户的主目录、%u 表示该用户的用户名。
经过扩展之后的值必须要么是绝对路径,要么是相对于用户主目录的相对路径。
默认值是”.ssh/authorized_keys”。
Banner
将这个指令指定的文件中的内容在用户进行认证前显示给远程用户。
这个特性仅能用于SSH-2,默认什么内容也不显示。”none”表示禁用这个特性。
ChallengeResponseAuthentication
是否允许质疑-应答(challenge-response)认证。默认值是”yes”。
所有 login.conf(5) 中允许的认证方式都被支持。
Ciphers
指定SSH-2允许使用的加密算法。多个算法之间使用逗号分隔。可以使用的算法如下:
“aes128-cbc”, “aes192-cbc”, “aes256-cbc”, “aes128-ctr”, “aes192-ctr”, “aes256-ctr”,
“3des-cbc”, “arcfour128”, “arcfour256”, “arcfour”, “blowfish-cbc”, “cast128-cbc”
默认值是可以使用上述所有算法。
ClientAliveCountMax
sshd(8) 在未收到任何客户端回应前最多允许发送多少个”alive”消息。默认值是 3 。
到达这个上限后,sshd(8) 将强制断开连接、关闭会话。
需要注意的是,”alive”消息与 TCPKeepAlive 有很大差异。
“alive”消息是通过加密连接发送的,因此不会被欺骗;而 TCPKeepAlive 却是可以被欺骗的。
如果 ClientAliveInterval 被设为 15 并且将 ClientAliveCountMax 保持为默认值,
那么无应答的客户端大约会在45秒后被强制断开。这个指令仅可以用于SSH-2协议。
ClientAliveInterval
设置一个以秒记的时长,如果超过这么长时间没有收到客户端的任何数据,
sshd(8) 将通过安全通道向客户端发送一个”alive”消息,并等候应答。
默认值 0 表示不发送”alive”消息。这个选项仅对SSH-2有效。
Compression
是否对通信数据进行加密,还是延迟到认证成功之后再对通信数据加密。
可用值:”yes”, “delayed”(默认), “no”。
DenyGroups
这个指令后面跟着一串用空格分隔的组名列表(其中可以使用”*”和”?”通配符)。默认允许所有组登录。
如果使用了这个指令,那么这些组中的成员将被拒绝登录。
这里的”组”是指”主组”(primary group),也就是/etc/passwd文件中指定的组。
这里只允许使用组的名字而不允许使用GID。相关的 allow/deny 指令按照下列顺序处理:
DenyUsers, AllowUsers, DenyGroups, AllowGroups
DenyUsers
这个指令后面跟着一串用空格分隔的用户名列表(其中可以使用”*”和”?”通配符)。默认允许所有用户登录。
如果使用了这个指令,那么这些用户将被拒绝登录。
如果指定了 USER@HOST 模式的用户,那么 USER 和 HOST 将同时被检查。
这里只允许使用用户的名字而不允许使用UID。相关的 allow/deny 指令按照下列顺序处理:
DenyUsers, AllowUsers, DenyGroups, AllowGroups
ForceCommand
强制执行这里指定的命令而忽略客户端提供的任何命令。这个命令将使用用户的登录shell执行(shell -c)。
这可以应用于 shell 、命令、子系统的完成,通常用于 Match 块中。
这个命令最初是在客户端通过 SSH_ORIGINAL_COMMAND 环境变量来支持的。
GatewayPorts
是否允许远程主机连接本地的转发端口。默认值是”no”。
sshd(8) 默认将远程端口转发绑定到loopback地址。这样将阻止其它远程主机连接到转发端口。
GatewayPorts 指令可以让 sshd 将远程端口转发绑定到非loopback地址,这样就可以允许远程主机连接了。
“no”表示仅允许本地连接,”yes”表示强制将远程端口转发绑定到统配地址(wildcard address),
“clientspecified”表示允许客户端选择将远程端口转发绑定到哪个地址。
GSSAPIAuthentication
是否允许使用基于 GSSAPI 的用户认证。默认值为”no”。仅用于SSH-2。
GSSAPICleanupCredentials
是否在用户退出登录后自动销毁用户凭证缓存。默认值是”yes”。仅用于SSH-2。
HostbasedAuthentication
这个指令与 RhostsRSAAuthentication 类似,但是仅可以用于SSH-2。推荐使用默认值”no”。
推荐使用默认值”no”禁止这种不安全的认证方式。
HostbasedUsesNameFromPacketOnly
在开启 HostbasedAuthentication 的情况下,
指定服务器在使用 ~/.shosts ~/.rhosts /etc/hosts.equiv 进行远程主机名匹配时,是否进行反向域名查询。
“yes”表示 sshd(8) 信任客户端提供的主机名而不进行反向查询。默认值是”no”。
HostKey
主机私钥文件的位置。如果权限不对,sshd(8) 可能会拒绝启动。
SSH-1默认是 /etc/ssh/ssh_host_key 。
SSH-2默认是 /etc/ssh/ssh_host_rsa_key 和 /etc/ssh/ssh_host_dsa_key 。
一台主机可以拥有多个不同的私钥。”rsa1″仅用于SSH-1,”dsa”和”rsa”仅用于SSH-2。
IgnoreRhosts
是否在 RhostsRSAAuthentication 或 HostbasedAuthentication 过程中忽略 .rhosts 和 .shosts 文件。
不过 /etc/hosts.equiv 和 /etc/shosts.equiv 仍将被使用。推荐设为默认值”yes”。
IgnoreUserKnownHosts
是否在 RhostsRSAAuthentication 或 HostbasedAuthentication 过程中忽略用户的 ~/.ssh/known_hosts 文件。
默认值是”no”。为了提高安全性,可以设为”yes”。
KerberosAuthentication
是否要求用户为 PasswordAuthentication 提供的密码必须通过 Kerberos KDC 认证,也就是是否使用Kerberos认证。
要使用Kerberos认证,服务器需要一个可以校验 KDC identity 的 Kerberos servtab 。默认值是”no”。
KerberosGetAFSToken
如果使用了 AFS 并且该用户有一个 Kerberos 5 TGT,那么开启该指令后,
将会在访问用户的家目录前尝试获取一个 AFS token 。默认为”no”。
KerberosOrLocalPasswd
如果 Kerberos 密码认证失败,那么该密码还将要通过其它的认证机制(比如 /etc/passwd)。
默认值为”yes”。
KerberosTicketCleanup
是否在用户退出登录后自动销毁用户的 ticket 。默认值是”yes”。
KeyRegenerationInterval
在SSH-1协议下,短命的服务器密钥将以此指令设置的时间为周期(秒),不断重新生成。
这个机制可以尽量减小密钥丢失或者黑客攻击造成的损失。
设为 0 表示永不重新生成,默认为 3600(秒)。
ListenAddress
指定 sshd(8) 监听的网络地址,默认监听所有地址。可以使用下面的格式:
ListenAddress host|IPv4_addr|IPv6_addr
ListenAddress host|IPv4_addr:port
ListenAddress [host|IPv6_addr]:port
如果未指定 port ,那么将使用 Port 指令的值。
可以使用多个 ListenAddress 指令监听多个地址。
LoginGraceTime
限制用户必须在指定的时限内认证成功,0 表示无限制。默认值是 120 秒。
LogLevel
指定 sshd(8) 的日志等级(详细程度)。可用值如下:
QUIET, FATAL, ERROR, INFO(默认), VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3
DEBUG 与 DEBUG1 等价;DEBUG2 和 DEBUG3 则分别指定了更详细、更罗嗦的日志输出。
比 DEBUG 更详细的日志可能会泄漏用户的敏感信息,因此反对使用。
MACs
指定允许在SSH-2中使用哪些消息摘要算法来进行数据校验。
可以使用逗号分隔的列表来指定允许使用多个算法。默认值(包含所有可以使用的算法)是:
hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
Match
引入一个条件块。块的结尾标志是另一个 Match 指令或者文件结尾。
如果 Match 行上指定的条件都满足,那么随后的指令将覆盖全局配置中的指令。
Match 的值是一个或多个”条件-模式”对。可用的”条件”是:User, Group, Host, Address 。
只有下列指令可以在 Match 块中使用:AllowTcpForwarding, Banner,
ForceCommand, GatewayPorts, GSSApiAuthentication,
KbdInteractiveAuthentication, KerberosAuthentication,
PasswordAuthentication, PermitOpen, PermitRootLogin,
RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset,
X11Forwarding, X11UseLocalHost
MaxAuthTries
指定每个连接最大允许的认证次数。默认值是 6 。
如果失败认证的次数超过这个数值的一半,连接将被强制断开,且会生成额外的失败日志消息。
MaxStartups
最大允许保持多少个未认证的连接。默认值是 10 。
到达限制后,将不再接受新连接,除非先前的连接认证成功或超出 LoginGraceTime 的限制。
PasswordAuthentication
是否允许使用基于密码的认证。默认为”yes”。
PermitEmptyPasswords
是否允许密码为空的用户远程登录。默认为”no”。
PermitOpen
指定TCP端口转发允许的目的地,可以使用空格分隔多个转发目标。默认允许所有转发请求。
合法的指令格式如下:
PermitOpen host:port
PermitOpen IPv4_addr:port
PermitOpen [IPv6_addr]:port
“any”可以用于移除所有限制并允许一切转发请求。
PermitRootLogin
是否允许 root 登录。可用值如下:
“yes”(默认) 表示允许。”no”表示禁止。
“without-password”表示禁止使用密码认证登录。
“forced-commands-only”表示只有在指定了 command 选项的情况下才允许使用公钥认证登录。
同时其它认证方法全部被禁止。这个值常用于做远程备份之类的事情。
PermitTunnel
是否允许 tun(4) 设备转发。可用值如下:
“yes”, “point-to-point”(layer 3), “ethernet”(layer 2), “no”(默认)。
“yes”同时蕴含着”point-to-point”和”ethernet”。
PermitUserEnvironment
指定是否允许 sshd(8) 处理 ~/.ssh/environment 以及 ~/.ssh/authorized_keys 中的 environment= 选项。
默认值是”no”。如果设为”yes”可能会导致用户有机会使用某些机制(比如 LD_PRELOAD)绕过访问控制,造成安全漏洞。
PidFile
指定在哪个文件中存放SSH守护进程的进程号,默认为 /var/run/sshd.pid 文件。
Port
指定 sshd(8) 守护进程监听的端口号,默认为 22 。可以使用多条指令监听多个端口。
默认将在本机的所有网络接口上监听,但是可以通过 ListenAddress 指定只在某个特定的接口上监听。
PrintLastLog
指定 sshd(8) 是否在每一次交互式登录时打印最后一位用户的登录时间。默认值是”yes”。
PrintMotd
指定 sshd(8) 是否在每一次交互式登录时打印 /etc/motd 文件的内容。默认值是”yes”。
Protocol
指定 sshd(8) 支持的SSH协议的版本号。
‘1’和’2’表示仅仅支持SSH-1和SSH-2协议。”2,1″表示同时支持SSH-1和SSH-2协议。
PubkeyAuthentication
是否允许公钥认证。仅可以用于SSH-2。默认值为”yes”。
RhostsRSAAuthentication
是否使用强可信主机认证(通过检查远程主机名和关联的用户名进行认证)。仅用于SSH-1。
这是通过在RSA认证成功后再检查 ~/.rhosts 或 /etc/hosts.equiv 进行认证的。
出于安全考虑,建议使用默认值”no”。
RSAAuthentication
是否允许使用纯 RSA 公钥认证。仅用于SSH-1。默认值是”yes”。
ServerKeyBits
指定临时服务器密钥的长度。仅用于SSH-1。默认值是 768(位)。最小值是 512 。
StrictModes
指定是否要求 sshd(8) 在接受连接请求前对用户主目录和相关的配置文件进行宿主和权限检查。
强烈建议使用默认值”yes”来预防可能出现的低级错误。
Subsystem
配置一个外部子系统(例如,一个文件传输守护进程)。仅用于SSH-2协议。
值是一个子系统的名字和对应的命令行(含选项和参数)。比如”sft /bin/sftp-server”。
SyslogFacility
指定 sshd(8) 将日志消息通过哪个日志子系统(facility)发送。有效值是:
DAEMON, USER, AUTH(默认), LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7
TCPKeepAlive
指定系统是否向客户端发送 TCP keepalive 消息。默认值是”yes”。
这种消息可以检测到死连接、连接不当关闭、客户端崩溃等异常。
可以设为”no”关闭这个特性。
UseDNS
指定 sshd(8) 是否应该对远程主机名进行反向解析,以检查此主机名是否与其IP地址真实对应。默认值为”yes”。
UseLogin
是否在交互式会话的登录过程中使用 login(1) 。默认值是”no”。
如果开启此指令,那么 X11Forwarding 将会被禁止,因为 login(1) 不知道如何处理 xauth(1) cookies 。
需要注意的是,login(1) 是禁止用于远程执行命令的。
如果指定了 UsePrivilegeSeparation ,那么它将在认证完成后被禁用。
UsePrivilegeSeparation
是否让 sshd(8) 通过创建非特权子进程处理接入请求的方法来进行权限分离。默认值是”yes”。
认证成功后,将以该认证用户的身份创建另一个子进程。
这样做的目的是为了防止通过有缺陷的子进程提升权限,从而使系统更加安全。
X11DisplayOffset
指定 sshd(8) X11 转发的第一个可用的显示区(display)数字。默认值是 10 。
这个可以用于防止 sshd 占用了真实的 X11 服务器显示区,从而发生混淆。
X11Forwarding
是否允许进行 X11 转发。默认值是”no”,设为”yes”表示允许。
如果允许X11转发并且sshd(8)代理的显示区被配置为在含有通配符的地址(X11UseLocalhost)上监听。
那么将可能有额外的信息被泄漏。由于使用X11转发的可能带来的风险,此指令默认值为”no”。
需要注意的是,禁止X11转发并不能禁止用户转发X11通信,因为用户可以安装他们自己的转发器。
如果启用了 UseLogin ,那么X11转发将被自动禁止。
X11UseLocalhost
sshd(8) 是否应当将X11转发服务器绑定到本地loopback地址。默认值是”yes”。
sshd 默认将转发服务器绑定到本地loopback地址并将 DISPLAY 环境变量的主机名部分设为”localhost”。
这可以防止远程主机连接到 proxy display 。不过某些老旧的X11客户端不能在此配置下正常工作。
为了兼容这些老旧的X11客户端,你可以设为”no”。
XAuthLocation
指定 xauth(1) 程序的绝对路径。默认值是 /usr/X11R6/bin/xauth

———————
作者:积思园
来源:CSDN
原文:https://blog.csdn.net/linghe301/article/details/8211305
版权声明:本文为博主原创文章,转载请附上博文链接!

apache & nginx 301重定向

  • apache
    在.htaccess加入如下规则:
    RewriteEngine On
    RewriteCond
    %{HTTP_HOST} !^www.maxianwei.cn$ [NC]

    RewriteRule ^(.*)$ http://www.maxianwei.cn/$1 [L,R=301]
有时候是某个文件或目录重定向,设置如下:
RewriteCond %{HTTP_HOST} ^test.maxianwei.cn$
RewriteRule ^news/lists.php$ http://www.maxianwei.cn/news/all.php [R=301,L]
注意,要使用.htaccess文件,Apache要开启rewirte模块哦。
  • nginx
    在nginx配置文件中server 里面加入
    if ( $host != ‘www.maxianwei.cn’ ) {
    rewrite ^/(.*)$ http://www.maxianwei.cn/$1 permanent;
    }

Nginx+Apache+PHP分布处理访问

Nginx本身不自带PHP处理模块,因此需要配置反向代理,将php请求交给其他的PHP解析器执行,然后返回结果给Nginx。

目前流行的方式是使用fast-cgi的方式配置PHP处理服务。其优点是比较简洁,服务器负载轻。但是缺点也是很明显的:无法查看php处理状态。
比如有时候网站因为负荷过高,php处理线程已经全部阻塞,就会造成网站无法再响应php服务。使用fastcgi方式,无法查看是哪些脚本处理时间过长,阻塞了php处理线程。
而Apache的有点就在于,可以很好的查看哪些php脚本处理时间过长,阻塞了有效进程数。

下面的方式是使用Apache最为Nginx的php处理后台:
1、先安装apache
apt-get install apache
并配置好apache正确运行在8001端口。
2、修改nginx的虚拟主机配置,其他php脚本交由apache解析
location ~ \.php$ {
proxy_pass http://127.0.0.1:8001;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 30;
proxy_send_timeout 30;
proxy_read_timeout 30;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
重启nginx和apache就好了。

注意,如果要查看php的处理状态,安装使用apache的监控模块就可以了。

DNS预解析dns-prefetch提升页面载入速度优化前端性能

当浏览器请求一个URL的时候,通过firebug我们可以发现大概有以下几个过程:阻挡、域名解析、建立连接、发送请求、等待响应、接收数据。后面四个跟用户的网络情况和你的服务器处理速度有关,本文重点说说前两个。

1、阻挡:解决方案——提高浏览器并发连接数

阻挡:不同的浏览器对单个域名的最大并发连接数有一定的限制,HTTP/1.0和HTTP/1.1也不相同。比如HTTP/1.1协议下,IE6的并发连接数限制是2个;而在HTTP/1.0下,IE6的并发连接数可以达到4个。在其它浏览器也有类似的限制,一般是4~8个。这个时候,如果浏览器同时对某一域名发起多个请求,超过了限制就会出现等待,也就是阻挡。

那么为了解决阻挡这一问题,我们可以对某些URL的域名分散处理,比如我们的图片域名,一般用类似img.guoweiwei.com的域名,当一个页面包含20多张图片的时候,那至少有10几个请求会被阻挡,而如果我们分散到img0.guoweiwei.com/img1.guoweiwei.com/img2.guoweiwei.com/…等不同域名的时候,至少这20个图片请求会并发进行,网站打开速度会明显提升很多。类似的,可以对一些css/js的域名同样处理。

2、域名解析:解决方案——DNS预解析

域名解析:从域名查询IP的过程,这个过程一般都很快的,但也会引起延迟。一般浏览器会适当的对解析结果缓存,并对页面中出现的新域名进行预解析,但并不是所有的浏览器都会这么做,为了帮助其它浏览器对某些域名进行预解析,你可以在页面的html标签中添加dns-prefetch告诉浏览器对指定域名预解析,如下:

<link rel="dns-prefetch" href="//domain.com">

如果细心一点,你会在淘宝的网站发现这两个现象,淘宝有很多类似img0.tbcdn.cn这样的域名。

再另外提一点优化,

3、cookie隔离

那就是为什么用img0.tbcdn.cn这个域名,而不是img0.taobao.com呢?这个得从cookie说起,淘宝的cookie已经非常大了,据说曾接近1K,如果用后面的域名,那每次请求图片都会带上长长的cookie,后果可想而知,不仅使得网络请求变慢,而且还浪费了带宽,而淘宝图片服务器并不需要这些cookie。这就是所说的cookie污染,为了解决这一问题,单独的域名是很有必要的。

下面重点介绍下:

4、DNS预解析解决方案

DNS预解析是浏览器试图在用户访问链接之前解析域名,这是计算机的正常DNS解析机制。

域名解析后,如果用户确实访问该域名,那么DNS解析时间将不会有延迟。

最明显的例子,DNS预解析在某个页面中包含非常多的域名非常有效,如搜索结果页。遇到网页中的超链接,DNS prefetching从中提取域名并将其解析为IP地址,这些工作在用户浏览网页时,使用最少的CPU和网络在后台进行解析。当用户点击这些已经预解析的域名,可以平均减少200毫秒耗时(假设用户最近还未访问过该域名),更重要的是用户不会遇到DNS解析最坏的情况(往往超过1秒)。

DNS Prefetch,即DNS预获取,是前端优化的一部分。一般来说,在前端优化中与 DNS 有关的有两点:

一个是减少DNS的请求次数,

  另一个就是进行DNS预获取 。

DNS 作为互联网的基础协议,其解析的速度似乎很容易被网站优化人员忽视。现在大多数新浏览器已经针对DNS解析进行了优化,典型的一次DNS解析需要耗费 20-120 毫秒,减少DNS解析时间和次数是个很好的优化方式。

DNS Prefetching 是让具有此属性的域名不需要用户点击链接就在后台解析,而域名解析和内容载入是串行的网络操作,所以这个方式能 减少用户的等待时间,提升用户体验 。

浏览器对网站第一次的域名DNS解析查找流程依次为:浏览器缓存——系统缓存——路由器缓存——ISP DNS缓存——递归搜索

默认情况下浏览器会对页面中和当前域名(正在浏览网页的域名)不在同一个域的域名进行预获取,并且缓存结果,这就是隐式的 DNS Prefetch。如果想对页面中没有出现的域进行预获取,那么就要使用显示的 DNS Prefetch 了。

目前大多数浏览器已经支持此属性,支持版本如下:

  • – Safari: 5+
  • – Chrome: All
  • – Firefox: 3.5+
  • – Opera: Unknown
  • – IE: 9+ (called “Pre-resolution” on blogs.msdn.com)

其中 Chrome 和 Firefox 3.5+ 内置了 DNS Prefetching 技术并对DNS预解析做了相应优化设置。所以,即使不设置此属性,Chrome 和 Firefox 3.5+ 也能自动在后台进行预解析 。

目前很多大型站点也应用了这一优化,例如:

  淘宝:

  支付宝:

  网易:

  DNS Prefetch 应该尽量的放在网页的前面,推荐放在 <meta charset="UTF-8"> 后面。具体使用方法如下:

<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel="dns-prefetch" href="//www.zhix.net">
<link rel="dns-prefetch" href="//api.share.zhix.net">
<link rel="dns-prefetch" href="//bdimg.share.zhix.net">

预解析的实现:

1、用meta信息来告知浏览器, 当前页面要做DNS预解析:<meta http-equiv=”x-dns-prefetch-control” content=”on” />

  2、在页面header中使用link标签来强制对DNS预解析: <link rel=”dns-prefetch” href=”http://bdimg.share.baidu.com” />

注:dns-prefetch需慎用,多页面重复DNS预解析会增加重复DNS查询次数。

需要注意的是,虽然使用 DNS Prefetch 能够加快页面的解析速度,但是也不能滥用,因为有开发者指出 禁用DNS 预读取能节省每月100亿的DNS查询 。

如果需要禁止隐式的 DNS Prefetch,可以使用以下的标签:

<meta http-equiv="x-dns-prefetch-control" content="off">

ZooKeeper是什么?

本文转自:http://developer.51cto.com/art/201809/583184.htm

相信大家对 ZooKeeper 应该不算陌生,但是你真的了解 ZooKeeper 是什么吗?如果别人/面试官让你讲讲 ZooKeeper 是什么,你能回答到哪个地步呢?

我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心,另外在搭建 Solr 集群的时候,我使用到了 ZooKeeper 作为 Solr 集群的管理工具。

前几天,总结项目经验的时候,我突然问自己 ZooKeeper 到底是个什么东西?

想了半天,脑海中只是简单的能浮现出几句话:

  • Zookeeper 可以被用作注册中心。
  • Zookeeper 是 Hadoop 生态系统的一员。
  • 构建 Zookeeper 集群的时候,使用的服务器最好是奇数台。

可见,我对于 Zookeeper 的理解仅仅是停留在了表面。所以,通过本文,希望带大家稍微详细的了解一下 ZooKeeper 。

如果没有学过 ZooKeeper,那么本文将会是你进入 ZooKeeper 大门的垫脚砖;如果你已经接触过 ZooKeeper ,那么本文将带你回顾一下 ZooKeeper 的一些基础概念。

最后,本文只涉及 ZooKeeper 的一些概念,并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建。

网上有介绍 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章,大家有需要可以自行查阅。

什么是 ZooKeeper

ZooKeeper 的由来

下面这段内容摘自《从 Paxos 到 ZooKeeper 》第四章第一节的某段内容,推荐大家阅读一下:

Zookeeper 最早起源于雅虎研究院的一个研究小组。在当时,研究人员发现,在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调,但是这些系统往往都存在分布式单点问题。

所以,雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架,以便让开发人员将精力集中在处理业务逻辑上。

关于“ZooKeeper”这个项目的名字,其实也有一段趣闻。在立项初期,考虑到之前内部很多项目都是使用动物的名字来命名的(例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。

时任研究院的首席科学家 Raghu Ramakrishnan 开玩笑地说:“在这样下去,我们这儿就变成动物园了!”

此话一出,大家纷纷表示就叫动物园管理员吧,因为各个以动物命名的分布式组件放在一起,雅虎的整个分布式系统看上去就像一个大型的动物园了。

而 Zookeeper 正好要用来进行分布式环境的协调,于是,Zookeeper 的名字也就由此诞生了。

ZooKeeper 概览

ZooKeeper 是一个开源的分布式协调服务,ZooKeeper 框架最初是在“Yahoo!”上构建的,用于以简单而稳健的方式访问他们的应用程序。

后来,Apache ZooKeeper 成为 Hadoop,HBase 和其他分布式框架使用的有组织服务的标准。

例如,Apache HBase 使用 ZooKeeper 跟踪分布式数据的状态。

ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。

原语: 操作系统或计算机网络用语范畴。它是由若干条指令组成的,用于完成一定功能的一个过程。具有不可分割性,即原语的执行必须是连续的,在执行过程中不允许被中断。

ZooKeeper 是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

ZooKeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。

服务生产者将自己提供的服务注册到 ZooKeeper 中心,服务的消费者在进行服务调用的时候先到 ZooKeeper 中查找服务,获取到服务生产者的详细信息之后,再去调用服务生产者的内容与数据。

如下图所示,在 Dubbo 架构中 ZooKeeper 就担任了注册中心这一角色。

Dubbo 架构图

结合个人使用讲一下 ZooKeeper

在我自己做过的项目中,主要使用到了 ZooKeeper 作为 Dubbo 的注册中心(Dubbo 官方推荐使用 ZooKeeper 注册中心)。

另外在搭建 Solr 集群的时候,我使用  ZooKeeper 作为 Solr 集群的管理工具。

这时,ZooKeeper 主要提供下面几个功能:

  • 集群管理:容错、负载均衡。
  • 配置文件的集中管理。
  • 集群的入口。

我个人觉得在使用 ZooKeeper 的时候,最好是使用集群版的 ZooKeeper 而不是单机版的。

官网给出的架构图就描述的是一个集群版的 ZooKeeper 。通常 3 台服务器就可以构成一个  ZooKeeper 集群了。

为什么最好使用奇数台服务器构成 ZooKeeper 集群?

我们知道在 ZooKeeper 中 Leader 选举算法采用了 Zab 协议。Zab 核心思想是当多数 Server 写成功,则任务数据写成功:

  • 如果有 3 个 Server,则最多允许 1 个 Server 挂掉。
  • 如果有 4 个 Server,则同样最多允许 1 个 Server 挂掉。

既然 3 个或者 4 个 Server,同样最多允许 1 个 Server 挂掉,那么它们的可靠性是一样的。

所以选择奇数个 ZooKeeper Server 即可,这里选择 3 个 Server。

关于 ZooKeeper  的一些重要概念

重要概念总结

关于 ZooKeeper  的一些重要概念:

  • ZooKeeper 本身就是一个分布式程序(只要半数以上节点存活,ZooKeeper 就能正常服务)。
  • 为了保证高可用,最好是以集群形态来部署 ZooKeeper,这样只要集群中大部分机器是可用的(能够容忍一定的机器故障),那么 ZooKeeper 本身仍然是可用的。
  • ZooKeeper 将数据保存在内存中,这也就保证了 高吞吐量和低延迟(但是内存限制了能够存储的容量不太大,此限制也是保持 Znode 中存储的数据量较小的进一步原因)。
  • ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其地高性能,因为“写”会导致所有的服务器间同步状态。(“读”多于“写”是协调服务的典型场景。)
  • ZooKeeper 有临时节点的概念。当创建临时节点的客户端会话一直保持活动,瞬时节点就一直存在。

而当会话终结时,瞬时节点被删除。持久节点是指一旦这个 ZNode 被创建了,除非主动进行 ZNode 的移除操作,否则这个 ZNode 将一直保存在 Zookeeper 上。

  • ZooKeeper 底层其实只提供了两个功能:①管理(存储、读取)用户程序提交的数据;②为用户程序提交数据节点监听服务。

下面关于会话(Session)、 Znode、版本、Watcher、ACL 概念的总结都在《从 Paxos 到 ZooKeeper 》第四章第一节以及第七章第八节有提到,感兴趣的可以看看!

会话(Session)

Session 指的是 ZooKeeper  服务器与客户端会话。在 ZooKeeper 中,一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。

客户端启动的时候,首先会与服务器建立一个 TCP 连接,从第一次连接建立开始,客户端会话的生命周期也开始了。

通过这个连接,客户端能够通过心跳检测与服务器保持有效的会话,也能够向 Zookeeper 服务器发送请求并接受响应,同时还能够通过该连接接收来自服务器的 Watch 事件通知。

Session 的 sessionTimeout 值用来设置一个客户端会话的超时时间。

当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时,只要在 sessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器,那么之前创建的会话仍然有效。

在为客户端创建会话之前,服务端首先会为每个客户端都分配一个 sessionID。

由于 sessionID 是 Zookeeper 会话的一个重要标识,许多与会话相关的运行机制都是基于这个 sessionID 的。

因此,无论是哪台服务器为客户端分配的 sessionID,都务必保证全局唯一。

Znode

在谈到分布式的时候,我们通常说的“节点”是指组成集群的每一台机器。

然而,在 ZooKeeper 中,“节点”分为两类:

  • 第一类同样是指构成集群的机器,我们称之为机器节点。
  • 第二类则是指数据模型中的数据单元,我们称之为数据节点一ZNode。

ZooKeeper 将所有数据存储在内存中,数据模型是一棵树(Znode Tree),由斜杠(/)的进行分割的路径,就是一个 Znode,例如/foo/path1。每个上都会保存自己的数据内容,同时还会保存一系列属性信息。

在 Zookeeper 中,Node 可以分为持久节点和临时节点两类。所谓持久节点是指一旦这个 ZNode 被创建了,除非主动进行 ZNode 的移除操作,否则这个 ZNode 将一直保存在 ZooKeeper 上。

而临时节点就不一样了,它的生命周期和客户端会话绑定,一旦客户端会话失效,那么这个客户端创建的所有临时节点都会被移除。

另外,ZooKeeper 还允许用户为每个节点添加一个特殊的属性:SEQUENTIAL。

一旦节点被标记上这个属性,那么在这个节点被创建的时候,ZooKeeper 会自动在其节点名后面追加上一个整型数字,这个整型数字是一个由父节点维护的自增数字。

版本

在前面我们已经提到,Zookeeper 的每个 ZNode 上都会存储数据,对应于每个 ZNode,Zookeeper 都会为其维护一个叫作 Stat 的数据结构。

Stat 中记录了这个 ZNode 的三个数据版本,分别是:

  • version(当前 ZNode 的版本)
  • cversion(当前 ZNode 子节点的版本)
  • aversion(当前 ZNode 的 ACL 版本)

Watcher

Watcher(事件监听器),是 ZooKeeper 中的一个很重要的特性。

ZooKeeper 允许用户在指定节点上注册一些 Watcher,并且在一些特定事件触发的时候,ZooKeeper 服务端会将事件通知到感兴趣的客户端上去,该机制是 ZooKeeper 实现分布式协调服务的重要特性。

ACL

ZooKeeper 采用 ACL(AccessControlLists)策略来进行权限控制,类似于  UNIX 文件系统的权限控制。

ZooKeeper 定义了 5 种权限,如下图:

其中尤其需要注意的是,CREATE 和 DELETE 这两种权限都是针对子节点的权限控制。

ZooKeeper 特点

ZooKeeper 有哪些特点呢?具体如下:

  • 顺序一致性:从同一客户端发起的事务请求,最终将会严格地按照顺序被应用到 ZooKeeper 中去。
  • 原子性:所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,也就是说,要么整个集群中所有的机器都成功应用了某一个事务,要么都没有应用。
  • 单一系统映像:无论客户端连到哪一个 ZooKeeper 服务器上,其看到的服务端数据模型都是一致的。
  • 可靠性:一旦一次更改请求被应用,更改的结果就会被持久化,直到被下一次更改覆盖。

ZooKeeper 设计目标

简单的数据模型

ZooKeeper 允许分布式进程通过共享的层次结构命名空间进行相互协调,这与标准文件系统类似。

名称空间由 ZooKeeper 中的数据寄存器组成,称为 Znode,这些类似于文件和目录。

与为存储设计的典型文件系统不同,ZooKeeper 数据保存在内存中,这意味着 ZooKeeper 可以实现高吞吐量和低延迟。

可构建集群

为了保证高可用,最好是以集群形态来部署 ZooKeeper,这样只要集群中大部分机器是可用的(能够容忍一定的机器故障),那么 ZooKeeper 本身仍然是可用的。

客户端在使用 ZooKeeper 时,需要知道集群机器列表,通过与集群中的某一台机器建立 TCP 连接来使用服务。

客户端使用这个 TCP 链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了,客户端可以连接到另外的机器上。

ZooKeeper 官方提供的架构图:

上图中每一个 Server 代表一个安装 ZooKeeper 服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态,并且每台服务器之间都互相保持着通信。

集群间通过 Zab 协议(Zookeeper Atomic Broadcast)来保持数据的一致性。

顺序访问

对于来自客户端的每个更新请求,ZooKeeper 都会分配一个全局唯一的递增编号。

这个编号反应了所有事务操作的先后顺序,应用程序可以使用 ZooKeeper 这个特性来实现更高层次的同步原语。这个编号也叫做时间戳—zxid(ZooKeeper Transaction Id)。

高性能

ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其地高性能,因为“写”会导致所有的服务器间同步状态。(“读”多于“写”是协调服务的典型场景。)

ZooKeeper 集群角色介绍

最典型集群模式:Master/Slave 模式(主备模式)。在这种模式中,通常 Master 服务器作为主服务器提供写服务,其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。

但是,在 ZooKeeper 中没有选择传统的 Master/Slave 概念,而是引入了Leader、Follower 和 Observer 三种角色。

如下图所示:

ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器。

Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外,Follower 和  Observer 都只能提供读服务。

Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程,也不参与写操作的“过半写成功”策略,因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。

ZooKeeper & ZAB 协议 & Paxos 算法

ZAB 协议 & Paxos 算法

Paxos 算法可以说是  ZooKeeper 的灵魂了。但是,ZooKeeper 并没有完全采用 Paxos 算法 ,而是使用 ZAB 协议作为其保证数据一致性的核心算法。

另外,在 ZooKeeper 的官方文档中也指出,ZAB 协议并不像 Paxos 算法那样,是一种通用的分布式一致性算法,它是一种特别为 ZooKeeper 设计的崩溃可恢复的原子消息广播算法。

ZAB 协议介绍

ZAB(ZooKeeper Atomic Broadcast 原子广播)协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。

在 ZooKeeper 中,主要依赖 ZAB 协议来实现分布式数据一致性,基于该协议,ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

ZAB 协议两种基本的模式

ZAB 协议包括两种基本的模式,分别是崩溃恢复和消息广播。

当整个服务框架在启动过程中,或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时,ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。

当选举产生了新的 Leader 服务器,同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后,ZAB 协议就会退出恢复模式。

其中,所谓的状态同步是指数据同步,用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。

当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步,那么整个服务框架就可以进人消息广播模式了。

当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时,如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播。

那么新加入的服务器就会自觉地进人数据恢复模式:找到 Leader 所在的服务器,并与其进行数据同步,然后一起参与到消息广播流程中去。

正如上文介绍中所说的,ZooKeeper 设计成只允许唯一的一个 Leader 服务器来进行事务请求的处理。

Leader 服务器在接收到客户端的事务请求后,会生成对应的事务提案并发起一轮广播协议。

而如果集群中的其他机器接收到客户端的事务请求,那么这些非 Leader 服务器会首先将这个事务请求转发给 Leader 服务器。

关于 ZAB 协议 & Paxos 算法需要讲和理解的东西太多了,推荐阅读下面两篇文章:

  • 图解 Paxos 一致性协议:

http://blog.xiaohansong.com/2016/09/30/Paxos/

  • Zookeeper ZAB 协议分析:

http://blog.xiaohansong.com/2016/08/25/zab/

关于如何使用 ZooKeeper 实现分布式锁,可以查看下面这篇文章:

  • Zookeeper ZAB 协议分析:

https://blog.csdn.net/qiangcuo6087/article/details/79067136

总结

通过阅读本文,想必大家已从以下这七点了解了 ZooKeeper:

  • ZooKeeper 的由来
  • ZooKeeper 到底是什么
  • ZooKeeper 的一些重要概念(会话(Session)、Znode、版本、Watcher、ACL)
  • ZooKeeper 的特点
  • ZooKeeper 的设计目标
  • ZooKeeper 集群角色介绍(Leader、Follower 和 Observer 三种角色)
  • ZooKeeper & ZAB 协议 & Paxos 算法

参考文章:

  • 《从Paxos到Zookeeper 》
  • https://cwiki.apache.org/confluence/display/ZOOKEEPER/ProjectDescription
  • https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index
  • https://www.cnblogs.com/raphael5200/p/5285583.html
  • https://zhuanlan.zhihu.com/p/30024403