TCP向上层提供⾯向连接的可靠服务,UDP向上层提供无连接不可靠服务。虽然UDP并没有TCP传输来的准确,但是也能在很多实时性要求⾼的地⽅有所作为对数据准确性要求⾼,速度可以相对较慢的,可以选⽤TCP
三次握手的过程
step1:第一次握手
建立连接时,客户端发送SYN包到服务器,其中包含客户端的初始序号seq=x,并进入SYNSENT状态,等待服务器确认。(其中, SYN=1, ACK-0,表示这是一个TCP连接请求数据报文;序号seq=x,表明传输数据时的第一个数据字节的序号是x)。
step2:第二次握手
服务器收到请求后,必须确认客户的数据包。同时自己也发送一个SYN包,即SYN+ACK包,此时服务器进入SYN-RECV状态。(其中确认报文段中,标识位SYN=1, ACK-1,表示这是一个TCP连接响应数据报文,并含服务端的初始序号seq(服务器)-y,以及服务器对客户端初始序号的确认号ack (服务器)-seq (客户端)+1=x+1)。
step3:第三次握手
客户端收到服务器的SYN+ACK包,向服务器发送一个序列号(seq=x+1),确认号为ack(客户端) =y+1,此包发送完毕,客户端和服务器进入BSTAB-LISHED (TCP连接成功)状态,完成三次握手。未连接队列在三次握手协议中,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设-个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包时,删除该条目,服务器进入ESTAB LISHED状态。
四次挥手过程(关闭客户端到服务器的连接)
stepl:第一次挥手
首先,客户端发送一个FIN,用来关闭客户端到服务器的数据传送,然后等待服务器的确认。其中终止标志位PIN=1,序列号seq=u。
step2:第二次挥手
服务器收到这个FIN,它发送一个ACK,确认ack为收到的序号加一。
step3:第三次挥手
关闭服务器到客户端的连接,发送一个FIN给客户端。
step4:第四次挥手
客户端收到FIN后,并发回一个ACK报文确认,并将确认序号seq设置为收到序号加一。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
IP地址:是IP协议提供的一种统一的地址格式,它为互联网上的每一个网络和每一台主机分配一个逻辑地址,以此来屏蔽物理地址,是一种逻辑地地址,用来标识网络中一个个主机,在本地局域网上是惟一的。
子网掩码:将某个IP地址划分成网络地址和主机地址两部分
网关地址:是一个网络连接到另一个网络的“关口”,网关地址实质上是一个网络通向其他网络的IP地址,主要用于不同网络间数据传输。网关在网段内的可用ip中选一个,一般选择是第一个或最后一个。
端口:端口包括物理端口和逻辑端口。物理端口是用于连接物理设备之间的接口,逻辑端口是逻辑上用于区分服务的端口。TCP/IP协议中的端口就是逻辑端口,通过不同的逻辑端口来区分不同的服务。
物理层,数据链路层,网络层,传输层,会话层,表示层,应用层
访问域名查看返回码
1、配置反向代理
2、proxy 缓存使用
3、页面压缩
4、连接超时时间
5、fastcgi 调优
6、expires 缓存调优
7、防盗链
工作进程数量
单个worker进程允许客户端最大连接数
修改Nginx配置文件,增加并发量
worker_processes 2; //与CPU核心数量一致
events {
worker_connections 65535; //每个worker最大并发连接数
multi_accept on; //打开同时接受多个新网络连接请求的功能。
use epoll;
}
[root@proxy ~]# vim /etc/security/limits.conf
.. ..
* soft nofile 100000
* hard nofile 100000
#该配置文件分4列,分别如下:
#用户或组 硬限制或软限制 需要限制的项目 限制的值
修改Nginx配置文件,增加数据包头部缓存大小
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
.. ..
http {
client_header_buffer_size 1k; //默认请求包头信息的缓存
large_client_header_buffers 4 4k; //大请求包头部信息的缓存个数与容量
.. ..
}
gzip压缩模块
[root@proxy ~]# cat /usr/local/nginx/conf/nginx.conf
http {
.. ..
gzip on; //开启压缩
gzip_min_length 1000; //小文件不压缩
gzip_comp_level 4; //压缩比率
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
//对特定文件压缩,类型参考mime.types
.. ..
http {
open_file_cache max=2000 inactive=20s;
open_file_cache_valid 60s;
open_file_cache_min_uses 5;
open_file_cache_errors off;
//设置服务器最大缓存2000个文件句柄,关闭20秒内无请求的文件句柄
//文件句柄的有效时间是60秒,60秒后过期
//只有访问次数超过5次会被缓存
}
expires缓存模块
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
expires 30d; //定义客户端缓存时间为30天
}
}
301 redirect: 301 代表永久性转移
302 redirect: 302 代表暂时性转移
连接超时
清除浏览器缓存
增加缓冲区容量大小
增加nginx等待时间
轻量级,同样起web 服务,比apache
占用更少的内存及资源
抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能
一个连接请求过来,每个进程都有可能处理这个连接.worker进程是从master进程fork出来的,在master进程里,先建立好需要listen的socket(listenfd)后,然后再fork出多个worker进程.所有worker进程的listenfd会在新连接来时变得可读,为了保证只有一个进程处理该连接,所有worker进程在注册listenfd读事件前抢accept_mutex,抢到互斥锁的那个进程注册listenfd读事件,在读事件里调用accept接受该连接.当一个worker进程在accept这个连接之后,开始读取请求,解析请求,产生数据后,再返回客户端,最后才断开连接,这就是一个完整的请求处理.一个请求,完全由worker处理,且只在一个worker里处理.
正向代理:类似一个跳板机,代理访问外部资源。设定我是一个用户(客户端)现在要请求一个web站点,我的电脑配置了正向代理,客户端先请求代理服务器,由代理服务器去访问指定的网页(或者地址),代理服务器接收到返回,再把结果发生给客户端
反向代理:对于客户端而言代理的对象就是本身服务器端。假设某个用户访问某个web站点,先经过nginx的反向代理,然后再由nginx判定转发给某个服务处理;最后返回结果给客用户(客户端)
虚拟主机,也叫“网站空间”,就是把一台运行在互联网上的物理服务器划分成多个“虚拟”服务器。虚拟主机技术极大的促进了网络技术的应用和普及。同时虚拟主机的租用服务也成了网络时代的一种新型经济形式。
虚拟主机的类型:
基于域名的虚拟主机:通过域名来区分虚拟主机,应用于外部网站
基于端口的虚拟主机:通过端口来区分虚拟主机,应用于公司内部网站,网站后台
基于IP的虚拟主机:几乎不使用,不支持ifconfig别名,配置文件可以
结合 proxy 和 upstream 模块实现后端 web 负载均衡
使用 proxy 模块实现静态文件缓存
结合 nginx 默认自带的 ngx_http_proxy_module 模块 和 ngx_http_upstream_module 模块实现后端服务器的健康检查,也可以使用第三方模块 nginx_upstream_check_module
使用 nginx-sticky-module 扩展模块实现 Cookie 会话黏贴(保持会话)
使用 ngx_cache_purge 实现更强大的缓存清除功能
nginx -t
nginx -s reload
服务器端处理的时间过长
服务器作为网关或代理,从上游服务器收到无效响应。
后端主机当机,连接超时,我们向服务器发送请求 由于服务器当前链接太多,导致服务器方面无法给于正常的响应,产生此类报错
fastcgi:fastcgi的方式是,web服务器收到一个请求时,他不会重新fork一个进程(因为这个进程在web服务器启动时就开启了,而且不会退出),web服务器直接把内容传递给这个进程(进程间通信,但fastcgi使用了别的方式,tcp方式通信),这个进程收到请求后进行处理,把结果返回给web服务器,最后自己接着等待下一个请求的到来,而不是退出.
cgi:cgi在2000年或更早的时候用得比较多,以前web服务器一般只处理静态的请求,如果碰到一个动态请求怎么办呢?web服务器会根据这次请求的内容,然后会fork一个新进程来运行外部c程序(或perl脚本…), 这个进程会把处理完的数据返回给web服务器,最后web服务器把内容发送给用户,刚才fork的进程也随之退出。 如果下次用户还请求改动态脚本,那么web服务器又再次fork一个新进程,周而复始的进行。
轮训、ip_hash、最少连接、权重算法
Stickey Session 粘带Session------配置简单、无入侵、存在单点故障问题。
Session Replication Session复制------较小分布式环境首选、无入侵、健壮无单点故障问题
Shared Session Session共享------大型分布式环境首选、可扩展性强、健壮
首先需要将资源动态分离,在http块下的server块下添加valid_referers指令来配置防盗链,配置只允许指定服务器访问静态资源
tomcat在处理静态资源时效率不高,默认情况下所有资源都由tomcat处理,
会导致Web应用响应慢,占用系统资源,
tomcat还存在是因为其对动态资源处理性能很好,nginx处理静态很好。
基于IP创建,基于域名创建、基于端口创建
当日志分析系统处理大日志包时,需要的分析时间过长,而且如分析过程中出错,要清空数据后再分析
master-worker模式和单进程模式。在master-worker模式下,有一个master进程和至少一个的worker进程,单进程模式顾名思义只有一个进程
shell实现nginx日志自动切割
1、获取昨天的日期(date -d yesterday +%Y%m%d),用来作为分割后日志的名称
2、将源日志文件移动到新的nohuplogs文件夹里,并按时间重命名
3、在源日志文件夹(logs)里新建默认日志文件(access.log)
4、给nginx一个信号量,重新打开日志
5、设置一个定时任务,定时执行日志切割的脚本
Nginx 是一个 web 服务器和反向代理服务器,用于 HTTP、HTTPS、SMTP、POP3和 IMAP 协议。
Nginx 服务器的特性包括:
反向代理/L7 负载均衡器、嵌入式 Perl 解释器、动态二进制升级、可用于重新编写 URL,具有非常好的 PCRE 支持
LAMP构架中PHP作为apache的模块来处理PHP请求;而在LNMP中,有独立的php-fpm服务,Nginx把php的请求通过代理的形式给php-fpm处理。由于apache和Nginx构架设计不同,Nginx对于静态文件的处理能力相对apache来说更强
http {
server_tokens off;
}
经常会有针对某个版本的nginx安全漏洞出现,隐藏nginx版本号就成了主要的安全优化手段之一,当然最重要的是及时升级修复漏洞
server {
listen 443;
server_name ops-coffee.cn;
ssl on;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
}
ssl on: 开启https
ssl_certificate: 配置nginx ssl证书的路径
ssl_certificate_key: 配置nginx ssl证书key的路径
ssl_protocols: 指定客户端建立连接时使用的ssl协议版本,如果不需要兼容TSLv1,直接去掉即可
ssl_ciphers: 指定客户端连接时所使用的加密算法,你可以再这里配置更高安全的算法
白名单配置
location /admin/ {
allow 192.168.1.0/24;
deny all;
}
上边表示只允许192.168.1.0/24网段的主机访问,拒绝其他所有
也可以写成黑名单的方式禁止某些地址访问,允许其他所有,例如
location /ops-coffee/ {
deny 192.168.1.0/24;
allow all;
}
更多的时候客户端请求会经过层层代理,我们需要通过$http_x_forwarded_for
来进行限制,可以这样写
set $allow false;
if ($http_x_forwarded_for = "211.144.204.2") { set $allow true; }
if ($http_x_forwarded_for ~ "108.2.66.[89]") { set $allow true; }
if ($allow = false) { return 404; }
server {
location / {
auth_basic "please input user&passwd";
auth_basic_user_file key/auth.key;
}
}
if ($request_method !~ ^(GET|POST)$ ) {
return 405;
}
$request_method
能够获取到请求nginx的method
配置只允许GET\POST方法访问,其他的method返回405
if ($http_user_agent ~* LWP::Simple|BBBike|wget|curl) {
return 444;
}
可能有一些不法者会利用wget/curl等工具扫描我们的网站,我们可以通过禁止相应的user-agent来简单的防范
Nginx的444状态比较特殊,如果返回444那么客户端将不会收到服务端返回的信息,就像是网站无法连接一样
location /images/ {
valid_referers none blocked www.ops-coffee.cn ops-coffee.cn;
if ($invalid_referer) {
return 403;
}
}
valid_referers: 验证referer,其中none
允许referer为空,blocked
允许不带协议的请求,除了以上两类外仅允许referer为www.ops-coffee.cn或ops-coffee.cn时访问images下的图片资源,否则返回403
当然你也可以给不符合referer规则的请求重定向到一个默认的图片,比如下边这样
location /images/ {
valid_referers blocked www.ops-coffee.cn ops-coffee.cn
if ($invalid_referer) {
rewrite ^/images/.*\.(gif|jpg|jpeg|png)$ /static/qrcode.jpg last;
}
}
可以通过ngx_http_limit_conn_module
模块限制一个IP的并发连接数
http {
limit_conn_zone $binary_remote_addr zone=ops:10m;
server {
listen 80;
server_name ops-coffee.cn;
root /home/project/webapp;
index index.html;
location / {
limit_conn ops 10;
}
access_log /tmp/nginx_access.log main;
}
}
limit_conn_zone: 设定保存各个键(例如$binary_remote_addr
)状态的共享内存空间的参数,zone=空间名字:大小
大小的计算与变量有关,例如$binary_remote_addr
变量的大小对于记录IPV4地址是固定的4 bytes,而记录IPV6地址时固定的16 bytes,存储状态在32位平台中占用32或者64 bytes,在64位平台中占用64 bytes。1m的共享内存空间可以保存大约3.2万个32位的状态,1.6万个64位的状态
limit_conn: 指定一块已经设定的共享内存空间(例如name为ops
的空间),以及每个给定键值的最大连接数
上边的例子表示同一IP同一时间只允许10个连接
当有多个limit_conn
指令被配置时,所有的连接数限制都会生效
http {
limit_conn_zone $binary_remote_addr zone=ops:10m;
limit_conn_zone $server_name zone=coffee:10m;
server {
listen 80;
server_name ops-coffee.cn;
root /home/project/webapp;
index index.html;
location / {
limit_conn ops 10;
limit_conn coffee 2000;
}
}
}
上边的配置不仅会限制单一IP来源的连接数为10,同时也会限制单一虚拟服务器的总连接数为2000
缓冲区溢出攻击 是通过将数据写入缓冲区并超出缓冲区边界和重写内存片段来实现的,限制缓冲区大小可有效防止
client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;
client_body_buffer_size: 默认8k或16k,表示客户端请求body占用缓冲区大小。如果连接请求超过缓存区指定的值,那么这些请求实体的整体或部分将尝试写入一个临时文件。
client_header_buffer_size: 表示客户端请求头部的缓冲区大小。绝大多数情况下一个请求头不会大于1k,不过如果有来自于wap客户端的较大的cookie它可能会大于 1k,Nginx将分配给它一个更大的缓冲区,这个值可以在large_client_header_buffers
里面设置
client_max_body_size: 表示客户端请求的最大可接受body大小,它出现在请求头部的Content-Length字段, 如果请求大于指定的值,客户端将收到一个"Request Entity Too Large" (413)错误,通常在上传文件到服务器时会受到限制
large_client_header_buffers 表示一些比较大的请求头使用的缓冲区数量和大小,默认一个缓冲区大小为操作系统中分页文件大小,通常是4k或8k,请求字段不能大于一个缓冲区大小,如果客户端发送一个比较大的头,nginx将返回"Request URI too large" (414),请求的头部最长字段不能大于一个缓冲区,否则服务器将返回"Bad request" (400)
同时需要修改几个超时时间的配置
client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 5 5;
send_timeout 10;
client_body_timeout: 表示读取请求body的超时时间,如果连接超过这个时间而客户端没有任何响应,Nginx将返回"Request time out" (408)错误
client_header_timeout: 表示读取客户端请求头的超时时间,如果连接超过这个时间而客户端没有任何响应,Nginx将返回"Request time out" (408)错误
keepalive_timeout: 参数的第一个值表示客户端与服务器长连接的超时时间,超过这个时间,服务器将关闭连接,可选的第二个参数参数表示Response头中Keep-Alive: timeout=time的time值,这个值可以使一些浏览器知道什么时候关闭连接,以便服务器不用重复关闭,如果不指定这个参数,nginx不会在应Response头中发送Keep-Alive信息
send_timeout: 表示发送给客户端应答后的超时时间,Timeout是指没有进入完整established状态,只完成了两次握手,如果超过这个时间客户端没有任何响应,nginx将关闭连接
通过以下设置可有效防止XSS攻击
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
X-Frame-Options: 响应头表示是否允许浏览器加载frame等属性,有三个配置DENY
禁止任何网页被嵌入,SAMEORIGIN
只允许本网站的嵌套,ALLOW-FROM
允许指定地址的嵌套
X-XSS-Protection: 表示启用XSS过滤(禁用过滤为X-XSS-Protection: 0
),mode=block
表示若检查到XSS攻击则停止渲染页面
X-Content-Type-Options: 响应头用来指定浏览器对未指定或错误指定Content-Type
资源真正类型的猜测行为,nosniff 表示不允许任何猜测
在通常的请求响应中,浏览器会根据Content-Type
来分辨响应的类型,但当响应类型未指定或错误指定时,浏览会尝试启用MIME-sniffing来猜测资源的响应类型,这是非常危险的
例如一个.jpg的图片文件被恶意嵌入了可执行的js代码,在开启资源类型猜测的情况下,浏览器将执行嵌入的js代码,可能会有意想不到的后果
另外还有几个关于请求头的安全配置需要注意
Content-Security-Policy: 定义页面可以加载哪些资源,
add_header Content-Security-Policy "default-src 'self'";
上边的配置会限制所有的外部资源,都只能从当前域名加载,其中default-src
定义针对所有类型资源的默认加载策略,self
允许来自相同来源的内容
Strict-Transport-Security: 会告诉浏览器用HTTPS协议代替HTTP来访问目标站点
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
上边的配置表示当用户第一次访问后,会返回一个包含了Strict-Transport-Security
响应头的字段,这个字段会告诉浏览器,在接下来的31536000秒内,当前网站的所有请求都使用https协议访问,参数includeSubDomains
是可选的,表示所有子域名也将采用同样的规则
打开\tomcat\bin\catalina.sh
export JAVA_OPTS="-server -Xms1400M -Xmx1400M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true "
上述这样的配置,基本上可以达到:
系统响应时间增快
JVM回收速度增快同时又不影响系统的响应率
JVM内存最大化利用
线程阻塞情况最小化
参数解释:
-server Tomcat以server模式运行,将拥有更大、更高的并发处理能力,更快更强捷的JVM垃圾回收机制,可以获得更多的负载与吞吐量,生产环境必须加上。
-Xms –Xmx 一般设置这里两个值相等
–Xmn 年轻代[Sun官方推荐配置为整个堆的3/8]
-Xss 指设定每个线程的堆栈大小 一般是128k或者256k
-XX:+AggressiveOpts 启用这个参数,则每当JDK版本升级时,你的JVM都会使用最新加入的优化技术(如果有的话)
-XX:+UseBiasedLocking 启用一个优化了的线程锁,我们知道在我们的appserver,每个http请求就是一个线程,有的请求短有的请求长,就会有请求排队的现象,甚至还会出现线程阻塞,这个优化了的线程锁使得你的appserver内对线程处理自动进行最优调配。
-XX:PermSize=128M 非堆的初始值[物理内存的1/64]
-XX:MaxPermSize=256M 非堆的最大值[物理内存的1/4]
-XX:+DisableExplicitGC 程序代码中不允许有显示的调用”System.gc()”
-XX:+UseParNewGC 对年轻代采用多线程并行回收,这样收得快。
-XX:+UseConcMarkSweepGC 即CMS gc 我们知道频频繁的GC会造面JVM的大起大落从而影响到系统的效率,因此使用了CMS GC后可以在GC次数增多的情况下,每次GC的响应时间却很短,比如说使用了CMS GC后经过jprofiler的观察,GC被触发次数非常多,而每次GC耗时仅为几毫秒。
-XX:MaxTenuringThreshold 设置垃圾最大年龄
-XX:+CMSParallelRemarkEnabled 在使用UseParNewGC 的情况下, 尽量减少 mark 的时间
-XX:+UseCMSCompactAtFullCollection 在使用concurrent gc 的情况下, 防止 memoryfragmention, 对live object 进行整理, 使 memory 碎片减少
-XX:+UseFastAccessorMethods get,set 方法转成本地代码
-XX:LargePageSizeInBytes 指定 Java heap的分页页面大小
打开tomcat安装目录\conf\server.xml文件,定位到这一行:
#URIEncoding="UTF-8" 使得 tomcat 可以解析含有中文名的文件的 url
#maxSpareThreads 如果空闲状态的线程数多于设置的数目,则将这些线程中止,减少这个池中的线程总数
#minSpareThreads : 最小备用线程数,tomcat 启动时的初始化的线程数
URIEncoding="UTF-8" minSpareThreads="25" maxSpareThreads="75"
# enableLookups="false" 消除DNS查询对性能的影响我们可以关闭DNS查询
# connectionTimeout 为网络连接超时时间毫秒数
enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000"
# maxThreads : Tomcat可创建的最大的线程数,即最大并发数
#acceptCount是当线程数达到maxThreads后,后续请求会被放入一个等待队列,这个acceptCount是这个队列的大小,如果这个队列也满了,就直接refuse connection
#maxProcessors="2000"一般设置为2000
acceptCount="300" maxThreads="300" maxProcessors="2000" minProcessors="5"
#可以减少它对一些url的不必要的检查从而减省开销。
useURIValidationHack="false"
# compression="on" 给Tomcat配置gzip压缩(HTTP压缩)功能
# compressionMinSize="2048" 启用压缩的输出内容大小,这里面默认为2KB
# noCompressionUserAgents=”gozilla, traviata” 对于以下的浏览器,不启用压缩
# compressableMimeType=”text/html,text/xml” 压缩类型
compression="on" compressionMinSize="2048"
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"
# 最后8443端口建议也设置成此配置,因为https会走8443端口
redirectPort="8443"
/>
垃圾回收的设置也是在 catalina.sh 中,调整 JAVA_OPTS 变量。
具体设置如下:
JAVA_OPTS=“$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100”
具体的垃圾回收策略及相应策略的各项参数如下:
串行收集器(JDK1.5 以前主要的回收方式)
-XX:+UseSerialGC:设置串行收集器并行收集器(吞吐量优先)
示例:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -
XX:MaxGCPauseMillis=100
-XX:+UseParallelGC:选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=20:配置并行收集器的线程数,即:同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
-XX:+UseParallelOldGC:配置年老代垃圾收集方式为并行收集。JDK6.0 支持对年老代并行收集
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间,如果无法满足此时间,JVM 会自动调整年轻代大小,以满足此值。
-XX:+UseAdaptiveSizePolicy:设置此选项后,并行收集器会自动选择年轻代区大小和相应的 Survivor 区比例,以达到目标系统规定的最低相应时间或者收集频率等,此值建议使用并行收集器时,一直打开。
并发收集器(响应时间优先)
示例:java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -
XX:+UseConcMarkSweepGC
-XX:+UseConcMarkSweepGC:设置年老代为并发收集。测试中配置这个以后,-XX:NewRatio=4 的配置失效了,原因不明。所以,此时年轻代大小最好用-Xmn 设置。
-XX:+UseParNewGC: 设置年轻代为并行收集。可与 CMS 收集同时使用。
JDK5.0 以上,JVM 会根据系统配置自行设置,所以无需再设置此值。
-XX:CMSFullGCsBeforeCompaction:由于并发收集器不对内存空间进行压缩、整理,所以运行一段时间以后会产生“碎片”,使得运行效率降低。此值设置运行多少次 GC 以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection:打开对年老代的压缩。可能会影响性能,但是可以消除碎片
直接把 Web 项目放在 webapps 下,Tomcat 会自动将其部署
在 server.xml 文件上配置节点,设置相关的属性即可
通过 Catalina 来进行配置:进入到 conf\Catalina\localhost 文件下,创建一个xml 文件,该文件的名字就是站点的名字。编写 XML 的方式来进行设置。
对于部署在局域网内其它机器上的 Tomcat,可以打开 JMX 监控端口,局域网其它机器就可以通过这个端口查看一些常用的参数(但一些比较复杂的功能不支持),同样是在 JVM 启动参数中配置即可,配置如下:
-Dcom.sun.management.jmxremote.ssl=false -
Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=192.168.71.38 设置 JVM 的 JMS 监控监听的 IP地址,主要是为了防止错误的监听成 127.0.0.1 这个内网地址
-Dcom.sun.management.jmxremote.port=1090 设置 JVM 的 JMS 监控的端口
-Dcom.sun.management.jmxremote.ssl=false 设置 JVM 的 JMS 监控不实用SSL
-Dcom.sun.management.jmxremote.authenticate=false 设置 JVM 的 JMS 监控不需要认证
Tomcat 是一个 JSP/Servlet 容器。其作为 Servlet 容器,有三种工作模式:独立的 Servlet 容器、进程内的 Servlet 容器和进程外的 Servlet 容器。
进入 Tomcat 的请求可以根据 Tomcat 的工作模式分为如下两类:
Tomcat 作为应用程序服务器:请求来自于前端的 web 服务器,这可能是Apache, IIS, Nginx 等;
Tomcat 作为独立服务器:请求来自于 web 浏览器;
安装完tomcat后,删除$CATALINA_HOME/webapps下默认的所有目录文件 rm -rf /srv/apache-tomcat/webapps/
修改$CATALINA_HOME/conf/server.xml,在Connector节点添加server字段,示例如下
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
server="WVS1.1"
<!-- A "Connector" using the shared thread pool-->
修改tomcat/ conf/web.xml,自定义40x、50x等容错页面,防止信息泄露。
(1)配置tomcat/conf/web.xml文件:在最后一行之前加入以下内容:
<error-page> <error-code>404</error-code><location>/noFile.htm</location> </error-page>……………<error-page><exception-type>java.lang.NullPointerException</exception-type><location>/ error.jsp</location> </error-page>
第一个之间的配置实现了将404未找到jsp网页的错误导向noFile.htm页面,也可以用类似方法添加其多的错误代码导向页面,如403,500等。
第二个之间的配置实现了当jsp网页出现java.lang.NullPointerException导常时,转向error.jsp错误页面,还需要在第个jsp网页中加入以下内容:
<%@ page errorPage="/error.jsp" %>
典型的error.jsp错误页面的程序写法如下:
<%@ page contentType="text/html;charset=GB2312"%>
<%@ page isErrorPage="true"%>
<html>
<head><title>错误页面</title></head>
<body>出错了:</p> 错误信息: <%= exception.getMessage() %><br>
Stack Trace is : <pre><font color="red"><%
java.io.CharArrayWriter cw = new java.io.CharArrayWriter();
java.io.PrintWriter pw = new java.io.PrintWriter(cw,true);
exception.printStackTrace(pw);
out.println(cw.toString());
%></font></pre>
</body>
</html>
当出现NullPointerException异常时tomcat会把网页导入到error.jsp,且会打印出出错信息。
(2)重新启动tomcat服务
1、参考配置操作
(1)修改tomcat/conf/server.xml配置文件,更改默认管理端口到8800
<Connector
port="8888" maxHttpHeaderSize="8192" maxThreads="150"
minSpareThreads="25" maxSpareThreads="75"、
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="300" disableUploadTimeout="true" />
(2)重启tomcat服务
2、补充操作说明
② 备注事项,登陆http://127.0.0.1:8888 ,进行验证配置。
在服务器设备权限配置范围内,根据我们的业务需要,配置其所需的最小权限。同时应删除或锁定与设备运行、维护等工作无关的账号。例如admin, 666等。还有使用单独的账号允许,不能使用与系统账号一样的账号密码。
① 建议配置
编辑tomcat/conf/tomcat-user.xml配置文件,修改用户角色权限 ,例如
<tomcat-users>
<!--
<role rolename="tomcat"/>
<role rolename="role1"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
<user username="both" password="tomcat" roles="tomcat,role1"/>
<user username="role1" password="tomcat" roles="role1"/>
-->
</tomcat-users>
② 登陆http://ip:8080/manager/html页面,使用tomcat账号进行本地登录,进行验证配置。
对于采用静态口令认证技术的设备,口令长度至少8位,并包括数字、小写字母、大写字母和特殊符号4类中至少2类。
① 建议配置
在tomcat/conf/tomcat-user.xml配置文件中设置密码
<user username="root" password="root123456" roles="admin">
② 备注事项
检查tomcat/conf/tomcat-user.xml配置文件中的帐号口令是否符合移动通过配置口令复杂度要求。
(1)人工检查配置文件中帐号口令是否符合;
(2)使用tomcat弱口令扫描工具定期对Tomcat Web服务器进行远程扫描,检查是否存在弱口令帐号。
对于类似web具备字符交互界面的设备,应支持定时账户自动登出。登出后用户需再次登录才能进入系统。
① 建议配置
编辑tomcat/conf/server.xml配置文件,修改为30秒
<Connector
port="8080" maxHttpHeaderSize="8192" maxThreads="150"
minSpareThreads="25" maxSpareThreads="75"、
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="6000" disableUploadTimeout="true" />
② 备注事项
登陆tomcat默认页面http://ip:8080/manager/html ,使用管理账号登陆,10分钟无操作或者关闭浏览器自动退出。
修改$CATALINA_HOME/conf/context.xml,添加
配置cookie的secure属性,在web.xml中sesion-config节点配置cooker-config,此配置只允许cookie在加密方式下传输。
<session-config>
<session-timeout>30</session-timeout>
<cookie-config>
<secure> true</secure>
</cookie-config>
</session-config>
AJP是为 Tomcat 与 HTTP 服务器之间通信而定制的协议,能提供较高的通信速度和效率。如果tomcat前端放的是apache的时候,会使用到AJP这个连接器。前端如果是由nginx做的反向代理的话可以不使用此连接器,因此需要注销掉该连接器。
应配置日志功能,对用户登录进行记录,记录内容包括用户登录使用的账号,登录是否成功,登录时间,以及远程登录时,用户使用的IP地址。
① 建议配置
编辑server.xml配置文件,在标签中增加记录日志功能
将以下内容的注释标记< ! – – >取消
<valve classname="org.apache.catalina.valves.AccessLogValve"
Directory="logs" prefix="localhost_access_log." Suffix=".txt"
Pattern="common" resloveHosts="false"/>
② 备注事项
classname:This MUST be set to
org.apache.catalina.valves.AccessLogValve touse the default access log valve. &<60
Directory:日志文件放置的目录,在tomcat下面有个logs文件夹,那里面是专门放置日志文件的,也可以修改为其他路径;
Prefix: 这个是日志文件的名称前缀,日志名称为localhost_access_log.2008-10-22.txt,前面的前缀就是这个localhost_access_log
Suffix: 文件后缀名
Pattern: common方式时,将记录访问源IP、本地服务器IP、记录日志服务器IP、访问方式、发送字节数、本地接收端口、访问URL地址等相关信息在日志文件中
resolveHosts:值为true时,tomcat会将这个服务器IP地址通过DNS转换为主机名,如果是false,就直接写服务器IP地址
① 建议配置
(1)使用JDK自带的keytool工具生成一个证书
JAVA_HOME/bin/keytool -genkey –alias tomcat –keyalg RSA -keystore /path/to/my/keystore
(2)修改tomcat/conf/server.xml配置文件,更改为使用https方式,增加如下行:
Connector classname=”org.apache.catalina.http.HttpConnector”
port=”8443” minProcessors=”5” maxprocessors=”100”
enableLookups=”true” acceptCount=”10” debug=”0”
scheme=”https” secure=”true” >
Factory classname=”org.apache.catalina.SSLServerSocketFactory”
clientAuth=”false”
keystoreFile=”/path/to/my/keystore” keystorePass=”runway”
protocol=”TLS”/>
/Connector>
其中keystorePass的值为生成keystore时输入的密码
(3)重新启动tomcat服务
② 备注事项
使用https方式登陆tomcat服务器页面,如果登陆成功,证明配置成功;如果登陆失败,证明配置失败。
首先查看是否存在IO问题,使用vmstat监控内存 cpu资源,
问题:进程太多,show full processlist;杀掉不必要的进程kill IP号;
关注下系统锁情况,show status like ‘%lock%’;
关注慢查询(slow query)日志,告诉开发优化索引,
innoDB 提供事务的支持,回滚,崩溃修复恢复能力,多版本事务并发控制(默认存储引擎) 读写效率较差,占用的数据库空间较大
Memory 内存中对数据创建表,数据全部存储在内存,读写速度非常快,对数据的安全性要求比较低 生命周期短
MYISAM 支持三种存储方式:静态型,动态型,压缩型,占用的空间小,存储的速度快,不支持事务和并发,主要用来插入和查询记录
TokuDB 注重insert性能,压缩比高,数据的插入性能高,限制记录不能太大,不注重update的性能 监控
alter table t1 engine innodb;
查询速度极慢,日常卡死
先考虑表分区 ;然后考虑分表 ;然后考虑分库,不考虑
更换引擎,TokuDB
监控用户:select,process,replication
DBA:all
管理用户:select ,update,insert,delete
grant select,insert,update,delete on db.tb to user@ip;
XBK,脚本备份
MySQL:开源免费的数据库,小型数据库。MySQL已经被Oracle收购;
Oracle:收费的大型数据库,Oracle公司的产品;
DB2:IBM公司的收费数据库产品,常应用在银行系统中;
SQLServer:MicroSoft 公司收费的中型数据库,C#(.net)等语言常使用;
SyBase:Sybase公司的高性能数据库,提供一个非常专业数据建模的工具PowerDesigner,已经淡出历史舞台;
SQLite : 嵌入式的小型数据库,应用在手机端。
显示宽度只是指明MYSQL最大可能显示的数字个数,数值的位数小于指定的宽度时会有空格填充,取决于你的设置
首先程序的请求会通过mysql的connectors与其进行交互,请求到处后,会暂时存放在连接池中并由处理器管理。当该请求从等待队列进入到处理队列,管理器会将该请求丢给SQL接口。SQL接口接收到请求后,它会将请求进行hash处理并与缓存中的结果进行对比,如果完全匹配则通过缓存直接返回处理结果;否则,需要完整的走一趟流程:
(1)由SQL接口丢给后面的解释器(Parser),解释器会判断SQL语句正确与否,若正确则将其转化为数据结构。
(2)解释器处理完,便来到后面的优化器(Optimizer),它会产生多种执行计划,最终数据库会选择最优化的方案去执行,尽快返会结果。
(3)确定最优执行计划后,SQL语句此时便可以交由存储引擎(Engine)处理,存储引擎将会到后端的存储设备中取得相应的数据,并原路返回给程序。
Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置;
Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay Log文件的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”
Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave 端执行了同样的 Query,所以两端的数据是完全一样的。
mysqldump工具
mysqldump是mysql自带的备份工具,目录在bin目录下面:/usr/local/mysql/bin/mysqldump
支持基于innodb的热备份,但是由于是逻辑备份,所以速度不是很快,适合备份数据比较小的场景
Mysqldump完全备份+二进制日志可以实现基于时间点的恢复。
percona提供的xtrabackup工具
支持innodb的物理热备份,支持完全备份,增量备份,而且速度非常快,支持innodb存储引起的数据在不同数据库之间迁移,支持复制模式下的从机备份恢复备份恢复,为了让xtrabackup支持更多的功能扩展可以设立独立表空间,打开 innodb_file_per_table功能,启用之后可以支持单独的表备份
SELECT table_schema “Data Base Name”,
sum( data_length + index_length ) / 1024 / 1024 “Data Base Size in MB”
FROM information_schema.TABLES
GROUP BY table_schema ;
2W
Xtrabackup
slow_query_log
long_query_time = 1
1、MyISAM是非事务安全的,而InnoDB是事务安全的
2、MyISAM锁的粒度是表级的,而InnoDB支持行级锁
3、MyISAM支持全文类型索引,而InnoDB不支持全文索引
4、MyISAM相对简单,效率上要优于InnoDB,小型应用可以考虑使用MyISAM
5、MyISAM表保存成文件形式,跨平台使用更加方便
RU(read uncommited) 读未提交,可脏读,一般部议叙出现
RC(read committed) 读已提交,会出现不可重复读,可能出现幻读,可以防止脏读
RR(repeatable read) 可重复读,功能是防止"幻读"现象,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁),必须索引支持,通过MVCC基础解决了不可重复读(默认)
SR(serializable) 可串行化,可以防止死锁,但是并发事务性能较差
pt-table-checksum
搭建Percona XtraDB Cluster
从执行速度上来说drop > truncate > DELETE
DELETE属于数据库DML操作语言,只删除数据不删除表的结构,会走事务,执行时会触发trigger;
truncate:属于数据库DDL定义语言,不走事务,原数据不放到 rollback segment 中,操作不触发 trigger,执行后立即生效,无法找回
drop:属于数据库DDL定义语言,同Truncate;执行后立即生效,无法找回
可以这么理解,一本书,delete是把目录撕了,truncate是把书的内容撕下来烧了,drop是把书烧了
忽略错误后,继续同步
指定跳过错误代码,继续同步
重新做主从,完全同步(推荐)
程序有可能在 slave 上进行了写操作,也有可能是 slave 机器重启后,事务回滚造成的
STATEMENT默认,ROW行模式,MIXED自动模式
1、互联网公司,使用MySQL的功能相对少(存储过程、触发器、函数,选择默认的语句模式,Statement Level(默认)
2、公司如果用到使用MySQL的特殊功能(存储过程、触发器、函数),则选择Mixed模式
3、公司如果用到使用MySQL的特殊功能(存储过程、触发器、函数)又希望数据最大化一直,此时最好选择Row level模式
查询慢日志
SHOW GLOBAL STATUS LIKE ‘%slow_queries%’;
检查操作系统是否存在IO、CPU、内存问题
mysql连接数少
进程太多
1、通过bin_log恢复数据
2、独立表空间迁移
(1)创建和原表结构一致的空表
(2)将空表的ibd文件删除
mysql> alter table 表名 dicard tablespace;
(3)将原表的ibd拷贝过来,并且修改权限
(4)将原表ibd进行导入
mysql> alter table 表名 import tablespace;
php程序不要使用长连接;java程序调整连接池
设置超时时间
wait_timeout=100
interactive_timeout=100
主库断掉宕机数据库主从关系,从库重新构建主从
Percona XtraDB Cluster(简称PXC集群)
MHA+Atlas
优化:MySQLTuner.pl、tuning-primer、pt-variable-advisor、pt-qurey-digest
表加字段:pt-osc
空值不占空间,null值占空间。
1.主键为一种约束,唯一索引为一种索引,本质上就不同;
2.主键创建后一定包含唯一性索引,而唯一索引不一定就是主键;
3.主键不允许空值,唯一索引可以为空;
4.主键可以被其他表引用,而唯一索引不可以;
5.一个表最多只能创建一个主键,而可以创建多个唯一索引;
6.主键和索引都是键,主键是逻辑键,索引为物理键,即主键不实际存在。
用多个小表代替一个大表,注意不要过度设计
批量插入代替循环单条插入
合理控制缓存空间大小,一般来说其大小设置为几十兆比较合适
可以通过SQL_CACHE和SQL_NO_CACHE来控制某个查询语句是否需要进行缓存
创建高性能索引
对查询进行优化,要尽量避免全表扫描
合理拆分,适度冗余
优化索引,减少不必要的表扫描
ACID 原⼦性,⼀致性,隔离性,永久性
通过预写⽇志⽅式实现的,redo和undo机制是数据库实现事务的基础
redo⽇志⽤来在断电/数据库崩溃等状况发⽣时重演⼀次刷数据的过程,把redo⽇志⾥的数据刷到数据库⾥,保证了事务的持久性(Durability)
undo⽇志是在事务执⾏失败的时候撤销对数据库的操作,保证了事务的原⼦性
2003:mysql服务没有启动,请启动该服务
1005:创建表失败
1006:创建数据库失败
1133:数据库用户不存在
普通索引: 即针对数据库表创建索引
唯一索引: 与普通索引类似,不同的就是:MySQL 数据库索引列的值必须唯一,但允许有空值
主键索引: 它是一种特殊的唯一索引,不允许有空值。一般是在建表的时候同时创建主键索引
组合索引: 为了进一步榨取 MySQL 的效率,就要考虑建立组合索引。即将数据库表中的多个字段联合起来作为一个组合索引。
bgsave做镜像全量持久化,aof做增量持久化。因为bgsave会耗费较⻓时间,不够实时,在停机的时候会导致⼤量丢失数据 ,所以需要aof来配合使⽤。在redis实例重启时,会使⽤bgsave持久化⽂件重新构建内存,再使⽤aof重放近期的操作指令来实现完整恢复重启之前的状态。
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。
RDB 的缺点
如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么 RDB 将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失
由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟
AOF 的缺点
对于相同数量的数据而言,AOF 文件通常要大于 RDB 文件。RDB 在恢复大数据时的速度比 AOF 的恢复速度要快
由于同步策略的不同,AOF 在运行效率上往往会慢于 RDB
总结:二者选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(AOF),还是愿意写操作频繁的时候,不启用备份来换取更高的性能。
官方工具redis-cli --cluster create --cluster-replicas
纯内存操作,单线程操作,避免了频繁的上下文切换,采用了非阻塞I/O多路复用机制,纯ANSI C编写。
部署Redis Cluster集群,一台master,两台slave做主从复制
需要实时更新但是又极其消耗数据库的数据。比如网站上商品销售排行榜,这种数据一天统计一次就可以了,用户不会关注其是否是实时的。
需要实时更新,但是更新频率不高的数据。比如一个用户的订单列表,他肯定希望能够实时看到自己下的订单,但是大部分用户不会频繁下单。
在某个时刻访问量极大而且更新也很频繁的数据。这种数据有一个很典型的例子就是秒杀,在秒杀那一刻,可能有N倍于平时的流量进来,系统压力会很大。但是这种数据使用的缓存不能和普通缓存一样,这种缓存必须保证不丢失,否则会有大问题。
定时删除:在设置键的过期时间的同时,创建一个定时器(Timer),让定时器在键的过期时间来临时,立即执行对键的删除操作。
惰性删除:放任键过期不管,但是每次从键空间中获取键时,都检查取得的键是否过期,如果过期的话,就删除该键;如果没有过期的话就返回该键。
定期删除:每隔一段时间,程序就对数据库进行一次检查,删除里面的过期键。
noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。
allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的key。
allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个key。
volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用的key。
volatile-random:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个key。
volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的key优先移除。
分布式锁+时间戳、利用消息队列
会话缓存、全页缓存、队列、排行榜/计数器、发布/订阅
缓存穿透
一般的缓存系统,都是按照 key 去缓存查询,如果不存在对应的 value,就应该去后端系统查找(比如DB)。一些恶意的请求会故意查询不存在的 key,请求量很大,就会对后端系统造成很大的压力。这就叫做缓存穿透。
如何避免?
1、对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该 key 对应的数据 insert 了之后清理缓存。
2、对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中,查询时通过该 bitmap 过滤。
缓存雪崩
当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,会给后端系统带来很大压力。导致系统崩溃。
如何避免?
1:在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只允许一个线程查询数据和写缓存,其他线程等待。
2:做二级缓存,A1 为原始缓存,A2 为拷贝缓存,A1 失效时,可以访问 A2,A1 缓存失效时间设置为短期,A2 设置为长期
3:不同的 key,设置不同的过期时间,让缓存失效的时间点尽量均匀
bgsave做镜像全量持久化,aof做增量持久化。因为bgsave会耗费较⻓时间,不够实时,在停机的时候会导致⼤量丢失数据 ,所以需要aof来配合使⽤。在redis实例重启时,会使⽤bgsave持久化⽂件重新构建内存,再使⽤aof重放近期的操作指令来实现完整恢复重启之前的状态。
网站数据:Mongo 非常适合实时的插入,更新与查询,并具备网站实时数据存储所需的复制及高度伸缩性。
缓存:由于性能很高,Mongo 也适合作为信息基础设施的缓存层。在系统重启之后,由 Mongo 搭建的持久化缓存层可以避免下层的数据源 过载。
大尺寸,低价值的数据:使用传统的关系型数据库存储一些数据时可能会比较昂贵,在此之前,很多时候程序员往往会选择传统的文件进行存储。
高伸缩性的场景:Mongo 非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce 引擎的内置支持。
用于对象及 JSON 数据的存储:Mongo 的 BSON 数据格式非常适合文档化格式的存储及查询。
mongodb 和 memcached 不是一个范畴内的东西。mongodb 是文档型的非关系型数据库,其优势在于查询功能比较强大,能存储海量数据。
和 memcached 更为接近的是 Redis。它们都是内存型数据库,数据保存在内存中,通过 tcp 直接存取,优势是速度快,并发高,缺点是数据类型有限,查询功能不强,一般用作缓存。
Redis 和 memcache 差不多,要大于 mongodb。
memcache 数据结构单一。
Redis 丰富一些,数据操作方面,Redis 更好一些,较少的网络 IO 次数。
mongodb 支持丰富的数据表达,索引,最类似关系型数据库,支持的查询语言非常丰富。
Redis 在 2.0 版本后增加了自己的 VM 特性,突破物理内存的限制;可以对key value 设置过期时间(类似 memcache)。
memcache 可以修改最大可用内存, 采用 LRU 算法。
mongoDB 适合大数据量的存储,依赖操作系统 VM 做内存管理,吃内存也比较厉害,服务不要和别的服务在一起。
Redis 对于单点问题,依赖客户端来实现分布式读写;主从复制时,每次从节点重新连接主节点都要依赖整个快照, 无增量复制,因性能和效率问题,所以单点问题比较复杂;不支持自动 sharding, 需要依赖程序设定一致 hash 机
制。一种替代方案是,不用 Redis 本身的复制机制,采用自己做主动复制(多份存储),或者改成增量复制的方式(需要自己实现),一致性问题和性能的权衡。
Memcache 本身没有数据冗余机制,也没必要;对于故障预防,采用依赖成熟的 hash 或者环状的算法,解决单点故障引起的抖动问题。
mongoDB 支持 master-slave,replicaset(内部采用 paxos 选举算法,自动故障恢复),auto sharding 机制,对客户端屏蔽了故障转移和切分机制。
对于数据持久化和数据恢复,Redis 支持(快照、AOF):依赖快照进行持久化,aof 增强了可靠性的同时,对性能有所影响。
memcache 不支持,通常用在做缓存, 提升性能;
MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性。
Memcache 在并发场景下,用 cas 保证一致性。
Redis 事务支持比较弱,只能保证事务中的每个操作连续执行。
mongoDB 不支持事务。
mongoDB 内置了数据分析的功能 (mapreduce), 其他不支持。
Redis:数据量较小的更性能操作和运算上。
memcache:用于在动态系统中减少数据库负载,提升性能; 做缓存,提高性能(适合读多写少,对于数据量比较大,可以采用 sharding)。
MongoDB: 主要解决海量数据的访问效率问题。
速度快:使用标准 C 写,所有数据都在内存中完成,读写速度分别达到 10万 / 20 万。
持久化:对数据的更新采用 Copy-on-write 技术,可以异步地保存到磁盘上,主要有两种策略,一是根据时间,更新次数的快照(save 300 10 )二是基于语句追加方式 (Append-only file,aof) 。
自动操作:对不同数据类型的操作都是自动的,很安全。
快速的主从复制,官方提供了一个数据,Slave 在 21 秒即完成了对Amazon 网站 10G key set 的复制。
Sharding 技术: 很容易将数据分布到多个 Redis 实例中,数据库的扩展是个永恒的话题,在关系型数据库中,主要是以添加硬件、以分区为主要技术形式的纵向扩展解决了很多的应用场景,但随着 web2.0、移动互联网、云计算等应用的兴起,这种扩展模式已经不太适合了,所以近年来,像采用主从配置、数据库复制形式的,Sharding 这种技术把负载分布到多个特理节点上去的横向扩展方式用处越来越多。
布隆过滤器(Bloom Filter)大概的思路就是,当你请求的信息来的时候,先检查一下你查询的数据我这有没有,有的话将请求压给数据库,没有的话直接返回
布谷鸟过滤器使用两个 hash 算法将新来的元素映射到数组的两个位置. 如果两个位置中有一个位置位空, 那么就可以将元素直接放进去. 但是如果这两个位置都满了, 它就会随机踢走一个, 然后自己霸占了这个位置,可以增加 hash 函数, 让每个元素不止有两个, 这样可以大大降低碰撞的概率, 将空间利用率提高到 95% 左右.
ELK是三个开源软件的缩写,分别表示:Elasticsearch , Logstash, Kibana , 都是开源软件。新增了一个FileBeat,它是一个轻量级的日志收集处理工具(Agent),Filebeat占用资源少,适合于在各个服务器上搜集日志后传输给Logstash,官方也推荐此工具。
(1)可以作为一个大型分布式集群(数百台服务器)技术,处理PB级数据,服务大公司;也可以运行在单机上,服务小公司
(2)Elasticsearch不是什么新技术,主要是将全文检索、数据分析以及分布式技术,合并在了一起,才形成了独一无二的ES;lucene(全文检索),商用的数据分析软件(也是有的),分布式数据库(mycat)
(3)对用户而言,是开箱即用的,非常简单,作为中小型的应用,直接3分钟部署一下ES,就可以作为生产环境的系统来使用了,数据量不大,操作不是太复杂
(4)数据库的功能面对很多领域是不够用的(事务,还有各种联机事务型的操作);特殊的功能,比如全文检索,同义词处理,相关度排名,复杂数据分析,海量数据的近实时处理;Elasticsearch作为传统数据库的一个补充,提供了数据库所不能提供的很多功能
可视化日志和数据系统,作为WEB前端可以很容易的和elasticsearch系统结合。kibana有版本2和版本3的区分,版本2采用ruby编写,部署起来很麻烦,需要安装很多ruby依赖包(目前网上多是这个版本的部署),版本3采用纯html+css编写,因此部署起来很方便,解压即用。
是一个管理日志和事件的工具,你可以收集它们,解析它们,并存储它们以供以后使用(例如日志搜索),logstash有一个内置的web界面,用来搜索你的所有日志。
分布式的实时文件存储,每个字段都被索引并可被搜索,分布式的实时分析搜索引擎,可以扩展到上百台服务器,处理PB级结构化或非结构化数据
一般大型系统是一个分布式部署的架构,不同的服务模块部署在不同的服务器上,问题出现时,大部分情况需要根据问题暴露的关键信息,定位到具体的服务器和服务模块,构建一套集中式日志系统,可以提高定位问题的效率。
集群:包含多个节点
节点:节点的主要职责是负责集群操作相关的内容,如创建或删除索引,跟踪哪些节点是群集的一部分,并决定哪些分片分配给相关的节点
文档:Elasticsearch是面向文档的,这意味着它可以存储整个对象或文档(document)。在Elasticsearch中,你可以对文档(而非成行成列的数据)进行索引、搜索、排序、过滤。这种理解数据的方式与以往完全不同,这也是Elasticsearch能够执行复杂的全文搜索的原因之一。
索引:在Elasticsearch中存储数据的行为就叫做索引
类型:文档归属于一种类型(type),而这些类型存在于索引(index)中
当有大量的文档时,由于内存的限制、磁盘处理能力不足、无法足够快的响应客户端的请求等,一个节点可能不够。这种情况下,数据可以分为较小的分片。每个分片放到不同的服务器上。
当你查询的索引分布在多个分片上时,ES会把查询发送给每个相关的分片,并将结果组合在一起,而应用程序并不知道分片的存在。即:这个过程对用户来说是透明的。
bulk会把将要处理的数据载入内存中,所以数据量是有限制的,最佳的数据量不是一个确定的数值,它取决于你的硬件,你的文档大小以及复杂性,你的索引以及搜索的负载。
一般建议是1000-5000个文档,如果你的文档很大,可以适当减少队列,大小建议是5-15MB,默认不能超过100M,可以在es的配置文件(即$ES_HOME下的config下的elasticsearch.yml)中。
Azure classic discovery 插件方式,多播
EC2 discovery 插件方式,多播
Google Compute Engine (GCE) discovery 插件方式,多播
Zen discovery 默认实现,多播/单播
上SSD,增加相关cache的配置,为常用字段增加配置,检查分片数量,检查是否禁用_all,检查是否已经批量写
监控预警:Sentinl插件
安全:license,shield
管理和查询:Marvel、BigDesk及Head
Sentinl
input插件:收集数据,文件类型,数据库类型
output插件:输出数据,
简单模式:以logstash作为日志搜索器,logstash采集、处理、转发到elasticsearch存储,在kibana进行展示
安全模式:beats(Filebeat、Metricbeat、Packetbeat、Winlogbeat等)作为日志搜集器
内存使用情况、磁盘适配器、文件系统中的可用空间、CPU使用率、页面空间和页面速度、异步I/O(仅适用于AIX)、网络文件系统(NFS)、磁盘I/O速度和读写比率、服务器详细信息和资源、内核统计信息、消耗资源进程、运行队列
内存、swap空间、磁盘空间、I/O、网络流量、系统信息
查询吞吐量
查询执行性能
连接情况
缓冲池使用情况
agentd需要安装到被监控的主机上,它负责定期收集各项数据,并发送到zabbix server端,zabbix
server将数据存储到数据库中,zabbix web根据数据在前端进行展现和绘图。这里agentd收集数据分为主动和被动两种模式:
主动:agent请求server获取主动的监控项列表,并主动将监控项内需要检测的数据提交给server/proxy
被动:server向agent请求获取监控项的数据,agent返回数据。
1、首先,需要有一个微信企业号。(一个实名认证的[微信号]一个可以使用的[手机号]一个可以登录的[邮箱号]
2、下载并配置微信公众平台私有接口。
3、配置Zabbix告警,(增加示警媒介类型,添加用户报警媒介,添加报警动作)。
1、写一个脚本用于获取待监控服务的一些状态信息。
2、在zabbix客户端的配置文件zabbix_agentd.conf中添加上自定义的“UserParameter”,目的是方便zabbix调用我们上面写的那个脚本去获取待监控服务的信息。
3、在zabbix服务端使用zabbix_get测试是否能够通过第二步定义的参数去获取zabbix客户端收集的数据。
4、在zabbix服务端的web界面中新建模板,同时第一步的脚本能够获取什么信息就添加上什么监控项,“键值”设置成前面配置的“UserParameter”的值。
5、数据显示图表,直接新建图形并选择上一步的监控项来生成动态图表即可。
1、使用命令生成密钥。
2、将公钥发送到所有安装zabbix客户端的主机。
3、安装 ansible 软件,(修改配置文件,将zabbix 客户机添加进组)。
4、创建一个安装zabbix客户端的剧本。
5、执行该剧本。
6、验证。
Docker部署LNMP环境,搭建Prometheus监控,私有仓库
docker pull 拉取或者更新指定镜像
docker push 将镜像推送至远程仓库
docker rm 删除容器
docker rmi 删除镜像
docker images 列出所有镜像
docker ps 列出所有容器
docker ps -a //查看docker创建的所有容器
docker logs -f yufei_01 //查看指定容器的日志记录
docker rm yufei_01 //删除某个容器,若正在运行,需要先停止
docker -v //查看docker版本信息
docker search image_name //检索image
docker history image_name //显示一个镜像的历史
docker top Name/ID 显示一个运行的容器里面的进程信息
docker tag 打标签
docker save 镜像导出
docker load 镜像导入
1、None网络
2、Host网络
3、Bridge: 桥接网络
4、自定义网络(brdige)的两种配置方法
5、Join容器:container(共享网络协议栈)
dcoker:直接运行于宿主机的内核,容器内没有自己的内核,而且也没有进行硬件虚拟,每个容器有自己的文件系统,互不干扰,启动时间块,资源占用少,可灵活分配资源
虚拟机:在宿主机上虚拟出一套硬件后,再运行一个完整操作系统,在该系统上再运行所需应用进程,启动时间长,占用资源多
-c 或 –cpu-shares设置容器使用 CPU 的权重
-m 或 –memory:设置内存的使用限额
Docker Swarm是Docker的本机群集。它将Docker主机池转变为单个虚拟Docker主机。Docker Swarm提供标准的Docker API,任何已经与Docker守护进程通信的工具都可以使用Swarm透明地扩展到多个主机。
Kubernetes(k8s)是自动化容器操作的开源平台。这些容器操作包括:部署,调度和节点集群间扩展。
具体功能:
自动化容器部署和复制。
实时弹性收缩容器规模。
容器编排成组,并提供容器间的负载均衡。
调度:容器在哪个机器上运行。
组成:
kubectl:客户端命令行工具,作为整个系统的操作入口。
kube-apiserver:以REST API服务形式提供接口,作为整个系统的控制入口。
kube-controller-manager:执行整个系统的后台任务,包括节点状态状况、Pod个数、Pods和Service的关联等。
kube-scheduler:负责节点资源管理,接收来自kube-apiserver创建Pods任务,并分配到某个节点。
etcd:负责节点间的服务发现和配置共享。
kube-proxy:运行在每个计算节点上,负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。
kubelet:运行在每个计算节点上,作为agent,接收分配该节点的Pods任务及管理容器,周期性获取容器状态,反馈给kube-apiserver。
docker可以构建容器,但这些容器通过kubernetes来进行跨主机相互通信。我们还可以使用kubernetes手动关联和编排在多个主机上运行容器。
可以将其基础设施分解为微服务,然后采用Kubernetes。这将使公司在不同的云基础架构上运行各种工作负载
k8s集群规模:个人推荐 K8S 集群规模不要超过千台节点
k8s使用版本:比最新版本低一个版本(例:centos8目前推荐使用1.18版本,centos7生产推荐使用 1.15版本)
k8s部署方式:个人推荐使用kubeadm和二进制部署
master,node
批量安装nginx,部署web-nfs-rsync架构
LVS:负载能力强、配置性低、工作稳定、无流量、能支持所有应用
Nginx:工作在第七层,可以针对HTTP应用本身做分流策略、对网络的依赖小、安装配置比较简单,测试起来也很方便、负载均衡和稳定度差了LVS几个等级
LVS:
1、抗负载能力强。抗负载能力强、性能高,能达到F5硬件的60%;对内存和cpu资源消耗比较低
2、工作在网络4层,通过vrrp协议转发(仅作分发之用),具体的流量由linux内核处理,因此没有流量的产生。
3、稳定性、可靠性好,自身有完美的热备方案;(如:LVStKeepalived)
4、应用范围比较广,可以对所有应用做负载均衡;
5、不支持正则处理,不能做动静分离。
6、支持负载均衡算法:rr(轮循)、wrr(带权轮循)、lc(最小连接)、wlc(权重最小连接)
7、配置复杂,对网络依赖比较大,稳定性很高。
Nginx:
1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构;
2、Nginx对网络的依赖比较小,理论上能ping通就能进行负载功能;
3、Nginx安装和配置比较简单,测试起来比较方便;
4、也可以承担高的负载压力且稳定,一般能支撑超过1万次的并发;
5、对后端服务器的健康检查,只支持通过端口来检测,不支持通过url来检测。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载;
7、Nginx仅能支持http、https和Email协议,这样就在适用范围较小。
8、不支持Session的直接保持,但能通过ip-hash来解决。对Big request header的支持不是很好。
9、支持负载均衡算法:Round-robin(轮循)、Weight-round-robin(带权轮循)、Ip-hash(Ip
哈希)
HAProxy的特点是:
1、支持两种代理模式:TCP(四层)和HTTP(七层),支持虚拟主机;
2、能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
3、支持url检测后端的服务器出问题的检测会有很好的帮助。
4、更多的负载均衡策略比如:动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
5、单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
6、HAProxy可以对MySQL进行负载均衡,对后端的DB节点进行检测和负载均衡。
7、支持负载均衡算法: Round-robin(轮循)、Weight-round-robin(带权轮循)、source(原地址保持)、RI(请求URL),rdp-cookie(根据cookie)
负载均衡(Server Load Balancer,下文简称 SLB)的引入,可以降低单台云服务器 ECS(下文简称 ECS)出现异常时对业务的冲击,提升业务的可用性。同时,结合弹性伸缩服务,通过动态调整后端服务器,可以快速对业务进行弹性调整(扩容或缩容),以快速应对业务的发展。
SLB支持四层和七层两种负载均衡协议,四层负载基于lvs+keepalived来做,性能较高;七层在lvs基础上又加上了tengine,性能较低。在选择协议时,如果需要做七层负载,以http协议为例,如果要根据请求的URL做转发那就需要七层;否则就选择四层转发。
rr(轮循)、wrr(带权轮循)、lc(最小连接)、wlc(权重最小连接),使用rr
两台web服务器nginx
两台负载均衡代理 nginx+keepalived
一台运维跳板机+ansible
一台监控zabbix
一台ELK
2台mysql数据库主从MHA高可用
存储服务器NFS
缓存服务器redis
备份服务器rsync+innotify
1台yum仓库服务器
代码托管git2台
1台jenkins
需求分析—原型设计—开发代码—提交测试—内网部署—确认上线—备份数据—外网更新-最终测试,如果发现外网部署的代码有异常,需要及时回滚
对称加密算法: 密钥较短,破译困难,除了数据加密标准(DES),另一个对称密钥加密系统是国际数据加密算法(IDEA),它比DES的加密性好,且对计算机性能要求也没有那么高.
非对称加密算法: 公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。
修改sudo配置文件/etc/sudoers
ps -aux
kill -9 xxx
修改ip地址、网关、主机名、DNS等
关闭selinux,清空iptables
添加普通用户并进行sudo授权管理
更新yum源及必要软件安装
定时自动更新服务器时间
精简开机自启动服务
定时自动清理/var/spool/clientmqueue/目录垃圾文件,防止inode节点被占满
变更默认的ssh服务端口,禁止root用户远程连接
锁定关键文件系统
去除系统及内核版本登录前的屏幕显示
禁止ping
历史记录
内核参数优化
升级具有典型漏洞的软件版本
修改文件:/etc/security/limits.conf
soft nofile 32768 #限制单个进程最大文件句柄数(到达此限制时系统报警)
hard nofile 65536 #限制单个进程最大文件句柄数(到达此限制时系统报错)
修改文件:/etc/sysctl.conf
fs.file-max=655350 #限制整个系统最大文件句柄数
Centos系统启动流程是CentOs主机从开机加电自检到整个系统(包括应用程序)都处于一个正常工作的状态;整个流程从宏观可分为硬件与系统两个层面,而系统又可以分为内核空间和用户空间的启动,每一块都是按照某些规则自动运行。
1、POST开机自检
2、BIOS开机启动设备,读取MBR中的Bootloader
3、通过Bootloader 读取kernel
4、通过挂载临时根目录initramfs加载核心模块(驱动程序. . ),然后卸载临时根目录,挂载真正的根目录。
5、启动systemd程序。
(1)使用default. target进入开启流程(假设是multi-user. target)
(2)执行sysinit. target初始化系统(检测硬件,载入所需的核心模组)、 basic. target准备系统(载入硬件驱动和防火墙相关任务)
(3)执行multi-user. target下面的服务(如果启动了etcrc. drc. local,则需要启动里面的命令)
(4)执行multi-user. target下的etcrc. drc. 1ocal
(5)启动tty
(6)如果运行级别是graphical. target则会启动图形桌面;
线程是指进程内的一个执行单元,也是进程内的可调度实体与进程的区别:
(1)地址空间:进程内的一个执行单元:进程至少有一个线程:它们共享进程的地址空间;而进程有自己独立的地址空间;
(2)资源拥有:进程是货源分配和拥有的单位,同一个进程内的线程共享进程的资源
3)线程是处理器调度的基本单位,但进程不是
(4)二者均可并发执行.
进程和线程都是由操作系统所体会的程序运行的基本单元,系统利用该基本单元实现系统对应用的并发性。
进程和线程的区别在于:
简而言之,一个程序至少有一个进程,一个进程至少有一个线程.
线程的划分尺度小于进程,使得多线程程序的并发性高。
另外,进程在执行过程中拥有独立的内存单元,而多个线程共享内存,从而极大地提高了程序的运行效率。
1)默认不带参数情况下,ln命令创建的是硬链接。
2)硬链接文件与源文件的inode节点号相同,而软链接文件的inode节点号与源文件不同。
3)ln命令不能对目录创建硬链接,但可以创建软链接,对目录的软链接会经常被用到。
4)删除软链接文件,对源文件及硬链接文件无任何影响;
5)删除文件的硬链接文件,对源文件及软链接文件无任何影响;
6)删除链接文件的原文件,对硬链接文件无影响,会导致其软链接失效(红底白字闪烁状);
7)同时删除原文件及其硬链接文件,整个文件才会被真正的删除。
8)很多硬件设备中的快照功能,使用的就类似硬链接的原理。
9)软连接可以跨文件系统,硬链接不可以跨文件系统。
1、服务器系统配置初始化
2、批量创建用户并设置密码
3、一键查看服务器利用率
4、找出占用CPU/内存过高的进程
5、查看网卡实时流量
6、监控100台服务器磁盘利用率
7、批量检查网站是否异常
8、监控MySQL主从同步状态是否异常
9、MySQL数据库备份
10、判断网络里当前在线用户的IP
11、解决DOS攻击生产
12、一键安装MySQL
find . -name “[A-Z]*” -print
find . -type f -mtime +7
find . -type f -atime +7
查看状态值,一般指令程序倘若执行成功,其回传值为 0;失败为 1。
-n 读一遍脚本中的命令但不执行,用于检查脚本中的语法错误
-v 一边执行脚本,一边将执行过的脚本命令打印到标准错误输出
-x 提供跟踪执行信息,将执行的每一条命令和结果依次打印出来
查看slave status \G中Slave_IO_Running和I/OSlave_SQL_Running是否为yes
用 ping 的方法。如果服务器能ping通则说明服务器存活
收集单位时间内的可疑ip,然后自动加入到iptables的禁止列表中就可以了
-n 只显示匹配出的行
-r 支持扩展正则表达式
> 覆盖重定向
>> 追加重定向
2> 错误重定向
2>> 错误追加重定向
&& 逻辑与
raid5
RAID 0:通过将连续的数据拆分成 block(块),将数据块的读写请求分散给各个磁盘,达到“同时”读/写的目的。
RAID 1:一个磁盘都有一个或多个冗余的镜像盘,所有磁盘的数据都是一模一样的。RAID 1 读数据时,可以利用所有数据盘的带宽;写数据时,要同时写入数据盘和镜像盘,因此,需要等待最慢的磁盘写完成,写操作才能完成。因此,写性能跟最慢的磁盘相当。
RAID 1+0:先做 RAID 1,再做 RAID 0
RAID 0+1:先做 RAID 0,再做 RAID 1
RAID 5:把数据和相对应的奇偶校验信息存储到组成 RAID 的各个磁盘,并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上,其中任意 N-1 块磁盘上都存储完整的数据,也就是说相当于有一块磁盘容量的空间用于存储奇偶校验信息。因此当 RAID 5 的一个磁盘发生损坏后,不会影响数据的完整性,从而保证了数据安全。当损坏的磁盘被替换后,RAID 还会自动利用剩下的奇偶校验信息去重建此磁盘上的数据,来保持RAID 5 的高可靠性
分区、格式化、挂载
du -hsx * | sort -rh | head -10
block :数据存储的最小单元。
inode: 索引节点,全局唯一编号,除了记录文件的属性外,同时还具有指针功能,指向文件内容放置的块。
/boot分区 200MB
Swap分区 8G
/根分区 60G
/home分区 剩余大小
基于VRRP协议
云服务器ECS,云数据库RDS MySQL版
1、我在之前的工作中享受了乐趣(或者和大家相处得很好,再或者学到了很多东西,等等),但是我希望在这个领域更好地发展,去拓展新的未来,去挑战自我(如果是跨行业跳槽的话,可以说想学习更多领域的知识,或者说在这个新行业更能发挥自己所长等)。
2、个人原因
3、原公司发生了重大客观变化
作为运维人员,需要对公司互联网业务所依赖的基础设施、基础服务、线上业务进行稳定性加强,进行日常巡检发现服务可能存在的隐患,对整体架构进行优化以屏蔽常见的运行故障,多数据中接入提高业务的容灾能力,通过监控、日志分析等技术手段,及时发现和响应服务故障,减少服务中断的时间,使公司的互联网业务符合预期的可用性要求,持续稳定地为用户提供务
基本工资+全勤+节日补助+加班费
目前北京养老保险单位缴费比例为20%,个人缴费比例为8%;医疗保险单位缴费比例为10%,个人为2%+3元;失业保险缴费比例为单位1%,个人0.2%。住房公积金缴费比例单位和个人同为12%,取下限并将各项基金缴费比例加总可得单位“五险一金”缴存比例为44.28%,个人缴存比例为22.2%,这两个比例之和是66.48%。
我非常希望在一个节奏快,挑战性强的工作环境里锻炼我的运维技能。运维是我职业发展的理想行业,因此我认为这个职位比较适合我,如果我被应聘了,我计划加强运维的自动化和可视化,这样做可以使企业更为直观的了解服务运行状态。从长期的来看,我不仅仅是要培养我运维上的能力,也要参与到企业的发展当中去。
k8s,python
Zabbix使用手册
检测服务器CPU、内存、网络、服务、文件系统、磁盘读写、公司网站
三太子敖广、云中飞、民工哥
操作前检查,操作前备份,进行操作过程,操作后确认,操作文档编写