1. 软链接和硬链接特性及区别

Linux链接分两种，一种被称为硬链接（Hard Link），另一种被称为软链接，即符号链接（Symbolic Link）。

在Linux的文件系统中，保存在磁盘分区中的文件不管是什么类型都给它分配一个编号，这个编号被称之为索引节点号（Inode Index），也就是常说的inode号。Inode号上与文件名关联，下与用户数据库（data block）关联。

硬链接指文件名与索引节点号（即inode号）的链接（所以创建一个新的文件,该文件使用stat命令查看时，links显示的是1），索引节点号（inode号）可以对应一个或多个文件名，并且这些文件名可以在同一或不同目录。

由于硬链接是直接将文件名与索引节点号（即inode号）链接，因此硬链接存在以下几个特点： 1、文件有相同的inode号及data block，这使得修改其中一个硬链接文件属性或文件数据时，其他硬链接文件都会发生相应修改；2、只能对已存在的文件进行创建；3、不能跨文件系统（即分区）进行创建；4、不能对目录文件进行创建；5、删除其中一个硬链接文件时，不会对其他硬链接文件产生影响。

image.png

软链接类似于Windows的快捷方式。它实际上是一个特殊的文件，有着自己的索引节点号（即inode号）以及用户数据块（data block），但用户数据块（data block）中包含的是另一个文件的位置信息。

由于软链接有着自己的索引节点号（即inode号）以及用户数据块（data block），因此没有硬链接的诸多限制，它的特性如下：1、软链接有自己的文件属性、inode号和data block，但是编辑文件其实就是编辑源文件；2、可以对不存在的文件或目录进行创建；3、可以跨文件系统（即分区）进行创建，使用ln命令跨文件系统创建时，源文件必须是绝对路径，否则为死链接；4、可以对文件或目录文件进行创建；5、删除软链接并不影响源文件，但源文件被删除，则相关软链接文件变为死链接（dangling link），若源文件（原地址原文件名）重新被创建，则死链接恢复为正常软链接。

实例：如果源文件没有给others读写权限，软链接显示的是有权限，但实际不能读写。

image.png

符号（或软）链接 
1、⼀个符号链接的内容是另一个文件的路径名的指向。 
2、其⼤⼩为指向的路径字符串的长度；
3、软连接文件不仅可以对已存在的文件和⽬录进⾏创建软连接，软链接还可对不存在的文件或目录创建软链接。
4、能跨文件系统创建(即能跨分区创建)
5、不增加或减少⽬标⽂件inode的引⽤计数。
6、符号链接文件与源文件inode的节点号不同

硬链接 
1、 硬链接就是同一个文件使用了多个别名（他们有共同的 inode）。
2、硬链接只能对已存在的文件进行创建（不能对目录创建硬链接文件）。
3、不能跨文件系统创建(即不能跨分区创建)
4、硬链接不能对目录进行创建，只可对文件创建
5、每个文件引⽤相同的inode号 
6、创建时链接数递增 
7、删除⽂件时： rm命令递减计数的链接⽂件要存在，⾄少有⼀
个链接数，当链接数为零时，该⽂件被删除 。

2. find命令了解

1. 实时查找工具，通过遍历指定路径完成文件查找
2. 工作特点：
 • 查找速度略慢
 • 精确查找
 • 实时查找
 • 可能只搜索用户具备读取和执行权限的目录
3. 语法
find [OPTION]... [查找路径] [查找条件] [处理动作]

3. 磁盘为什么要分区

1. 优化I/O性能
2. 实现磁盘空间配额限制
3. 提高修复速度
4. 隔离系统和程序
5. 安装多个os
6. 采用不同文件系统

4. buffer和cache区别

cache实现了读的速度更快（cache将磁盘的数据缓存到内存中，当下次读取该数据的时候，如果命中该数据，将直接在内存缓存中去读取数据）
buffer实现了写的速度更快（将内存中修改的数据先存到到内存缓冲区，在将内存缓冲区数据写入到磁盘中）

5. 简述raid0、raid1、raid5、raid10、raid01的区别？

image.png

raid0: 连续分割数据并行的读/写于多个磁盘上，因此具有很高的数据传输率，读写性能都提
       升，但是没有冗余能力，因此RAID0不可用于数据高可用性的关键应用，没有提供数据的可
       靠性，如果一块磁盘失效，将影响整个数据，最少磁盘数为2+，可用空间为N*min{s1,s2,s3....}

raid1: 通过数据镜像实现数据冗余，在2对分离的磁盘上产生互为备份的数据，读性能提升，
       写性能略有下降，是磁盘阵列中费用最高的，但提供了最好的数据可用性，当一块磁盘
       失效，系统可以自动地交换到镜像磁盘上。最少由2块磁盘组成，只有一半的磁盘能存
       储数据，即可用空间为n/2*min(s1,s2......)

raid5： 所有磁盘轮流充当校验盘，读写性能都提升，有容错能力，最多准许1块磁盘损
        坏，最少由3块磁盘组成，实际存储空间为（n-1）/n*总磁盘容量。

raid10:先两两组成raid1,再组合成raid0,每组镜像最多损坏一个磁盘，有容错能力，读写性能
       都提升，最少由4块磁盘组成，只有一半的磁盘能存储数据。

raid01: 先两两组成raid0,再组合成raid1,最多损坏一个磁盘，有容错能力，读写性能
       都提升，最少由4块磁盘组成，只有一半的磁盘能存储数据。

6. 简述raid5,raid1,raid0的使用优势与使用场景？

   raid5,可损失一块盘，数据安全保障程度比raid1低而磁盘空间利用率比raid1高。raid5可
以理解为是raid0和raid1的折中方案，适合对性能和冗余都有一定要求，又不是十分高的情
况，mysql的主从库都可以，存储也可以，普通的服务器为了减少维护成本，又保存一定冗
余和读写性能都可以做raid5

  raid1,通过磁盘数据镜像实现数据的冗余，保护数据安全，在两块磁盘上产生互为备份的数
据，当元帅数据繁忙时，可直接从镜像备份数据中读取数据，因此raid1可以提升读性能，
raid1是硬盘中单位成本最高的，但是提供了很高的数据安全性和可用性，当一个硬盘失效时
系统可以自动切换到镜像硬盘上读/写，并且不需要重组失效的数据。

raid0,无任何冗余，坏1块磁盘，整个raid就不能用了，整个raid就不能用了。适合于大规模
并发读写，但是对数据安全性要求不高的情况，如mysql slave（数据库从库），集群的节
点rs(服务员)。

一. 文本处理工具

1. 生成随机口令（包括数字字母标点符号）

tr -dc '[:alnum:][:punct:]' < /dev/urandom | head -c16
cat /dev/urandom | tr -dc '[:alnum:][:punct:]' | head -c16
除了字母数字标点符号都不要，并且取前面16个字符。
openssl rand -base64 16 | head -c16

2.

二. 网络协议和管理

1. TCP协议特性

1. 工作在传输层
2. 面向连接协议
3. 全双工协议（双向同时传输）
4. 半关闭
5. 错误检查
6. 将数据打包成段，排序
7. 确认机制
8. 数据恢复，重传
9. 流量控制，滑动窗口
10. 拥塞控制，慢启动和拥塞避免算法

2. UDP特性

1. 工作在传输层
2. 提供不可靠的网络访问
3. 非面向连接协议
4. 有限的错误检查
5. 传输性能提高
6. 无数据恢复性

3. 描述tcp三次握手和四次挥手过程

3.1 三次握手

1. 客户端向服务器端发送SYN包，客户端进入SYN_SENT状态。
2. 服务器端收到客户端发送的包返回ACK+SYN包，服务器端进入SYN_RECV状态。
3. 客户端收到服务器端返回的包再发回ACK包，客户端进入ESTABLISHED状态，服务器端收到包也进入ESTABLISHED状态。

image.png

3.2 四次挥手

1. 客户端发送FIN包询问服务器端是否能断开，客户端进入FIN_WAIT_1状态。
2. 服务器端收到客户端发送的包并返回ACK包，服务器端进入CLOSE_WAIT状态，客户端进入FIN_WAIT_2状态
3. 服务器端准备好断开后，发送FIN包给客户端，服务器端进入LAST_ACK状态。
4. 客户端收到服务器端发送的包后返回ACK包，客户端进入TIME_WAIT状态，服务器端收到包后进入CLOSED状态。

image.png

注：扩展客户端打开浏览器，发生了什么，及http运行过程原理,见下

三. linux进程管理

1. 根据端口号查询被那个进程所占用

方法一
语法： lsof -i :port
[root@s8 ~]#lsof -i :22
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
sshd    6522 root    3u  IPv4  35777      0t0  TCP *:ssh (LISTEN)
sshd    6522 root    4u  IPv6  35780      0t0  TCP *:ssh (LISTEN)

方法二
ss -tnlp | grep 22

四 系统启动和内核管理

1. linux的启动流程

Linux启动流程.jpg

2. centos6和centos7破解root口令

五. awk

2. 将文件里面的内容去重

[root@s8 data]#cat dupfile 
aa
bbb
ccc
aaaa
bbbb
ccc
aa
bbb

[root@s8 data]#awk '!line[$0]++' dupfile 
aa
bbb
ccc
aaaa
bbbb
注：注：1. line[$0]没有值，为假（0）；
2. !line[$0]取反为真(1)， 就把待处理的这行打印出来了
3. 打印完之后line[$0]经过++，line[$0]=1即line[aa]=1，到达第
6行ccc时，此时的line[ccc]=1,在上面处理第三行时已经赋值了，
此时的!line[ccc]取反为假，则不打印，而line[ccc]++之后line[ccc]=2了，下面依次类推

方法二
[root@s8 data]#sort dupfile | uniq
aa
aaaa
bbb
bbbb
ccc

六. 加密与安全

1. 详解https 加密完整工作过程

image.png

1. 客户端向服务端发送https请求
3. 服务端将自己的数字证书发送给客户端
4. 客户端用ca的公钥解密服务器端发送过来数字签名证书，得到服务器端的公钥
5. 客户端随机生产一个对称秘钥，并且用服务端的公钥加密对称秘钥，发送给服务端，服务端得到对称秘钥
6-7. 服务端得到对称秘钥加密需要传输的数据，加密数据后发送给客户端
8. 客户端得到数据，用对称秘钥进行解密得到数据
通过以上步骤事先了数据的加密传输 

六. dhcp

1. Dhcp服务器分配地址的过程原理

image.png

1. 客户端发送dhcp discover广播包在网络上寻找dhcp服务器
2. DHCP Server接收到DHCP Client发送的DHCP Discover报文，
DHCP服务器向主机发送DHCP OFFER单播数据包，包含ip地址、mac地址、域
名信息以及地址租期
3. 客户端收到dhcp服务端发送的offer数据包之后，发送DHCPREQUEST广播
包，正式向服务器请求分配已提供的ip地址
4. DHCP Server收到DHCP Request报文后，DHCP服务器向主机发送
DHCPACK单播包，确认主机的请求。

七. dns

1. dns域名解析过程

Client -->hosts文件 -->DNS Service Local Cache -->
 DNS Server (递归recursion) --> Server Cache --> iteration(迭代)
 --> 根--> 顶级域名DNS-->二级域名DNS…

1. 客户机首先查看本地的hosts文件，如果有则返回，否则进行下一步
2. 客户机查看本地缓存，是否存在本条目的缓存，如果有则直接返回，否则进行下一步
   首先，客户端向DNS发出域名解析请求,DNS服务器在收到客户机的请求后
（1）检查DNS服务器的缓存，若查到请求的地址或名字，即向客户机发出应答信息； 
（2）若没有查到，则在数据库中查找，若查到请求的地址或名字，即向客户机发出应答信息； 
（3）若没有查到，则将请求发给根域DNS服务器，并依序从根域查找顶级域，
     由顶级查找二级域，二级域查找三级，直至找到要解析的地址或名字，即向
     客户机所在网络的DNS服务器发出应答信息，DNS服务器收到应答后先在缓
     存中存储，然后，将解析结果发给客户机。
（4）若没有找到，则返回错误信息

2. 什么是递归查询和迭代查询

递归查询：服务器和客户机之间的查询过程。由主DNS服务器直接将域名对应的IP地址告诉给客户机。

迭代查询：DNS服务器和服务器之间的查询过程。由DNS服务器向互联网中的根域、顶级域、二级域依次发出查询请求，最终获取到域名所对应的IP地址的过程。

八. mysql

1. myisam innodb存储引擎区别

MyISAM引擎特点：
  1> 不支持事务    注：事务由多个不同动作组成，具有原子性，例如：取钱的动作
  2> 表级锁定  注：用户不能同时修改同一张表，就算修改表的记录不同，也不能同时修改
  3> 读写互相阻塞，写入不能读，读时不能写
  4> 只缓存索引（只缓存索引，不缓存数据）
  5> 崩溃恢复性较差   注：由于不支持事务，所有崩溃恢复性差
  6> 不支持外键约束
  7> 不支持聚簇索引
  8> 读取数据较快，占用资源较少
  9> 不支持MVCC（多版本并发控制机制）高并发
MyISAM存储引擎使用场景如下：
  只读（或者写较少），表较小（可以接受长时间进行修复操作）

InnoDB引擎特点：
  1> 支持事务，适合处理大量短期事务
  2> 行级锁
  3> 读写阻塞与事务隔离界别相关
  4> 可缓存数据和索引
  5> 支持聚簇索引
  6> 崩溃恢复性更好
  7> 支持MVCC高并发
  8> 从MySQL5.5后支持全文索引
  9> 从MySQL5.5开始为默认的数据库引擎

2. 忘记root口令怎么解决

1） 启动mysql进程。
2）修改my.cnf配置文件，在[mysqld]下面区域添加
[mysqld]
skip-grant-tables  忽略授权表
skip-networking 禁止网络连接
3）重启mysql服务，使用updata命令修改管理员密码
mysql>UPDATE mysql.user SET password=PASSWORD('password') WHERE user='root';
mysql> FLUSH PRIVILEGES;
4）移除上述临时配置的2项，重启mysqld服务。

3. SQL语句优化

1) 查询时，能不要*就不用*，尽量写全字段名
2) 大部分情况连接效率远大于子查询
3) 多表连接时，尽量小表驱动大表，即小表 join 大表
4) 在有大量记录的表分页时使用limit
5) 对于经常使用的查询，可以开启缓存
6) 多使用explain和profile分析查询语句
7) 查看慢查询日志，找出执行时间长的sql语句优化

4. 事务

事务Transactions：一组原子性的SQL语句，或一个独立工作单元。注释：多个操作被当做一个整体对待。

ACID特性：
A：atomicity原子性；整个事务中的所有操作要么全部成功执行，要么全部失败后回滚
C：consistency一致性；数据库总是从一个一致性状态转换为另一个一致性状态；比如：比如几个银行账号转账互相转账，钱的总数不变 

I：Isolation隔离性；一个事务所做出的操作在提交之前，是不能为其它事务所见；隔离有多种隔离级别，实现并发
D：durability持久性；一旦事务提交，其所做的修改会永久保存于数据库中。

5. 事务隔离级别

1. 读未提交（read-uncommitted）-脏读：可读取到未提交数据，产生脏读
2. 不可重复读（read-committed）- 可重复读：提交才能看到记录
3. 可重复读（repeatable-read）- 幻读：可重复读，每次读看到的记录都一样，每次看到的数据都是为初始数据(旧的数据)，提交的数据看不见，因此备份也可以用该事务级别。
4.  串行化（serializable）：未提交的读事务阻塞修改事务，或者未提交的修改事务阻塞读事务。导致并发性能差

6. 数据库设置注意事项

1. innode_file_per_table = on 注：innodb数据引擎默认每个数据库全部存储在一个文件中，开启此项，分表存储数据。
2. skip_name_resolve = on  注：禁止服务器反向解析，不然由于解析导致连着缓慢。
3. 二进制日志记录格式最好设置成基于“行”：row，即：binlog_format = ROW,也可以换成MIXED模式
4.备份数据库的时候mysql数据库也要备份。
5. 一般query_cache_type 在数据库读占主导的时候，查询缓存功能最好的开，而写占主导的时候，最好关闭。
6. 创建索引：在数据库读的多，写的少的情况下，最好创建索引，大大提高查询速度。
7. 事务日志、二进制日志最好和mysql数据库文件分开存放。（最好将事务日志和二进制日志放在一个单独磁盘里面）

8. 开启慢查询日志（记录执行查询时长超出指定时长的操作，优化数据库查询语句提供依据）
9. 进行mysql账户授权的时候不要加级联授权，即不要加上：WITH GRANT OPTION,加上此项不安全
10. 数据库安装过后记得执行安全加固程序。
11. mysql管理员的系统账号千万不能外泄，由于mysql账号密码登录数据库之后，可以更改linux系统账号密码：
system echo password | passwd --stdin username
12. 数据库备份完之后，需要做还原测试，查看备份数据是否可用。

7. mysql主从同步原理

主节点：
dump Thread：为每个Slave的I/O Thread启动一个dump线程，用于向其发送binary log events
从节点：
I/O Thread：向Master请求二进制日志事件，并保存于中继日志中
SQL Thread：从中继日志中读取日志事件，在本地完成重放

master将更改的数据保存到二进制日志文件中，slave通过IO线程读取master的
二进制日志文件，并将其写入到自己的中继日志，slave的sql线程读取中继日志且
转换成SQL语句顺序执行，这样就完成了mysql的主从数据同步

九. httpd

1. 一次完整的http请求过程

1. 首先对网址进行DNS域名解析，得到对应的IP地址
2. 根据这个IP，找到对应的服务器，与服务器三次握手
3. 建立TCP连接后发起HTTP请求
4. httpd服务器接收访问请求（并根据MPM模式决定连接方式，由服务器配置决定）
5. 接收请求并解析请求，对报文中的资源和方法对请求进行处理
6. 访问报文中的请求的资源进行加载
7. 加载完成进行封装构建成响应报文
8. 构建完响应报文向请求者发送报文
9. 发送完成，服务器记录日志
10. 四次挥手断开连接

一次httpd详细请求过程如下

当我们在浏览器中输入类似www.baidu.com的时候，中间经历了什么过程？

1、首先通过域名解析成IP。如果本机没有将请求DNS服务器
    在我们访问一个网站时，通常输入的是一个网站的名字，又叫域名，类似baidu.com，在输入后回车通过网络访问时，网络并
不识别这一串字符串，网络是通过IP来实现通讯的，那么就需要将这个字符串解析成对应的IP地址。
提供解析服务的有以下几种，优先查询的从上到下
    1) 本机的hosts文件，文件中定义的就是IP和各个域名的对应关系
    2) 本区域的DNS服务器，如果本区域有此访问的域名对应的IP地址，则返回给我们，然后我们在通过此IP访问真正要到的网站
    3) 互联网中的DNS服务器，一个网站构成少不了DNS，互联网中的DNS服务器为我们共享解析各种合法的域名的，网站通过
授权证明合法，然后互联网中的DNS服务器为我们解析出对应的IP

2、IP解析完成后与服务器三次握手
IP解析后需要通过网络进行三次握手，证明双方的身份，以确保传输安全

3、握手完成开始进行http访问连接
    握手完后生成请求报文，封装各种报文头部进行网络传输到服务器，服务器拆包并提供一个进程或线程负责为客户端请求提
供服务。
使用进程或进程要根据服务器使用的模式MPM相关：
    prefork：多进程I/O模型，每个进程响应一个请求，默认模型
        一个主进程：生成和回收多个子进程，创建套接字，不响应请求
        多个子进程：工作work进程，每个子进程处理一个请求，系统初始时，预先生成多个空闲进程，等待请求，最大不超过1024个

    worker：复用的多进程I/O模型，多进程多线程，IIS使用此模型
        一个主进程：生成M个子进程，每个子进程负责生成N个线程，每个线程响应一个请求，并发响应请求：M*N

  event：时间驱动模型
        一个主进程：生成M个子进程，每个子进程负责生成N个线程，每个线程响应一个请求，并发响应请求，M*N

4、httpd服务器接收访问请求并根据MPM模式决定连接方式，由服务器配置决定
连接方式有：
    串行连接：访问数据依次进行，每访问一个数据都需要三次握手和四次挥手的过程，占用资源和网络
    并行连接：通过多条TCP连接同时发起并发http请求
    持久连接：长连接，在没有执行完不断开，重用TCP连接，消除连接和关闭的延时，以事务个数和时间来决定是否关闭连接
    管道化连接：通过共享TCP连接发起并发的http请求
    复用的连接：交替传送请求和响应报文，实验阶段

5、接收请求并解析请求，通过报文中的资源和方法对请求处理
    服务器对请求报文进行解析，并获取请求的资源及请求方法等相关信息，根据方法，资源，首部和可选的主体部分对请求进
行处理
http常用的请求方式
    get：从服务器获取一个资源
    head：只从服务器获取文档的响应首部，curl -I就是使用的head方法
    post：向服务器输入数据，通常会再由网关程序继续处理
    put：将请求的主体部分存储在服务器中，如上传文件
    delete：请求删除服务器上指定的文档
    trace：追踪请求到达服务器中间经过的代理服务器
    options：请求服务器返回对指定资源支持试用的请求方法

6、访问报文中请求的资源进行加载
    在解析完得到方法后，判断客户端要请求的资源，然后应用程序通知内核，由内核负责到磁盘加载数据，并返回给应用程序
访问资源路径：
    资源放置于本地文件系统特定的路径：documentroot
    默认：documentroot -> /var/www/html
    web服务器资源路径映射方法：
    documentroot
    alias   # 别名真正指向的路径
    虚拟主机docroot # 自定义虚拟主机后的主目录
    用户家目录docroot    # 用户家目录下的/home/username/public_html

7、加载完成进行封装构成响应报文
    通过指定路径获取资源后，构建响应报文：一旦web服务器识别了资源，就执行请求方法中描述的动作，并返回响应报文，响应报文中包含有响应状态码、响应首部，如果生成了响应主体的话，还包括响应主体。
响应实体：如果事务处理产生了响应主体，就将内容放在响应报文中会送过去
响应报文中通常包括：
    描述了响应主体mime类型的content-type首部
    描述了响应主体长度的content-length
    实际报文的主体内容

8、选路向请求者发送报文
服务器会自动进行计算哪条路线最优，然后返回给用户响应报文

9、完成发送，服务器记录日志
最后当事务结束时，web服务器会在日志文件中添加一个条目，来描述已执行的事务

10、四次挥手断开连接
当整个过程结束后，进行四次挥手断开连接。

2. httpd的MPM工作模式

httpd的工作模式有以下三种：prefork,worker,event三种

Prefork MPM

image.png

Prefork MPM：预派生模式，有一个主控制进程，然后生成多个子进程，每个子进程有一个独立的线程响应处
理用户请求，相对比较占用内存，但是比较稳定，可以设置最大最小进程数，是最古来的一种模式，也是最稳
定的模式，适用于访问量不是很大的场景。最大并发为1024个。
优点：稳定
缺点：慢，占用资源，不适用于高并发场景。

worker MPM

image.png

worker MPM: 是一种多进程和多线程的模型，有一个控制进程，启动多个子进程，每个子进程里面包含固定的
线程，使用线程来处理请求，当线程不够使用的时候会再启动一个新的子进程，然后在进程里面再启动线程处
理请求，由于其使用了线程处理请求，因此可以承受更高的并发。
优点：相比prefork占用的内存更少，可以同时处理更多的请求。
缺点：使用keep-alive的长连接方式，摸个线程会一直被占据，即使没有传输数据，也需要一直等待超时才会
被释放。如果过多的线程被这样占据，也会导致在高并发场景下无服务线程可用。

event MPM

image.png

event MPM: apache中最新的模式，事件驱动模型，是worker模型的变种，升级版。其主要区别是在于，
event模型下，多个线程中有一个专门的监控线程来管理keep-alive类型的线程，当有真实请求时，监听线程
将请求专递给服务线程，执行完毕之后，又允许释放，这样解决了keep-alive场景下，长期被占用的线程的资
源浪费问题（某些线程因为被keep-alive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）
优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keep-alive类
型的线程，当有真实请求过来的时候，将请求专递给服务线程，当执行完毕后，又允许他释放
缺点：没有线程安全控制

3. http协议常用状态码含义

status(状态码)：
1xx：100-101 信息提示
2xx：200-206 成功
3xx：300-305 重定向
4xx：400-415 错误类信息，客户端错误
5xx：500-505 错误类信息，服务器端错误

200： 成功，请求数据通过响应报文的entity-body部分发送;OK
301：永久重定向，请求的URL指向的资源已经被删除；但在响应报文中通过首部Location指明了资源现在
    所处的新位置；Moved Permanently
302：临时重定向，响应报文Location指明资源临时新位置 Moved Temporarily
304： 客户端发出了条件式请求，但服务器上的资源未曾发生改变，则通过响应此响应状态码通知客户端；Not Modified
401： 需要输入账号和密码认证方能访问资源；Unauthorized
403： 请求被禁止；Forbidden
404： 服务器无法找到客户端请求的资源；Not Found
500： 服务器内部错误；Internal Server Error
502： 代理服务器从后端服务器收到了一条伪响应，如无法连接到网关；Bad Gateway
503： 服务不可用，临时服务器维护或过载，服务器无法处理请求
504： 网关超时

十. nginx

1. Nginx中配置CPU亲和性，worker_processes和worker_cpu_affinity有什么好处

Nginx中配置cpu的亲和性，即将Nginx工作进程绑定到指定的cpu上，避免工作进程在不同的cpu的核心上来回跳转，降低了系统对cpu和内存的开销，有效的提升nginx服务器的性能

2.常用的Nginx模块，用来做什么

rewrite模块，重定向模块
access模块：来源控制(基于ip)
ssl模块：安全加密
ngx_http_gzip_module：静态压缩模块
ngx_http_proxy_module 模块实现代理
ngx_http_upstream_module负载均衡模块
ngx_cache_purge实现缓存清除功能
ngx_http_stub_status_module 状态统计模块

3. Nginx性能优化，使用1.10版本

1.  Nginx运行的工作进程数量
2.  Nginx最大文件打开数
3.  Nginx上传文件大小
4.  连接超时时间
5.  Nginx配置cpu的亲和性
工作进程绑定到固定的cpu上，避免工作进程在不同的cpu的核心上来回跳转，减低系统对cpu和内存的开销，以有效的提升nginx服务器的运行效率
6.   Nginx事件处理模型，
nginx采用epoll事件模型,处理效率高
7.  开启高效传输模式 sendfile on
8.  Gzip 采用数据压缩
使用gzip压缩功能，可以为我们节约带宽，加快传输速率，有更好的体验，可以节约成本，但是加大的服务器的计算负荷
9.  Expires缓存调优
10. 设置防盗链策略
10.1    图片加水印
10.2    防火墙，直接控制，前提是指定Ip来源
10.3    防盗链策略下面的方法：直接给与404的错误提示
11. 使用普通用户启动nginx

4. 自签名证书的简单实现方法

1. 进入/etc/pki/tls/certs目录
cd /etc/pki/tls/certs
2. 修改Makefile文件，以免需要创建私钥进行加密
cat -n Makefile
   57 /usr/bin/openssl genrsa $(KEYLEN) > $@注：将此行的-aes128删除,即不加密生成的私钥文件
    
3.  接着可以生成无加密私钥的自签名证书了
make crtname.crt

可能需要安装mod_ssl包

十一. redis相关

1. Redis对比memcached有什么优点

2. radis有那2种数据持久化保存机制

1. redis有RDB和AOF两种数据持久化保存机制
2. RDB模式如下
RDB ：基于时间的快照， 只保留 当前最新的一次快照， 特点 是执行速度比较快，缺点 是可能 会丢失从 上次快照到当 前快照未完成之间的
数据。
RDB 实现 的具体过程 Redis 从主进程先 fork 出一个子进程，使用写时复制机将内存的数据 保存为一个临时文件，比如 dump.rdb.temp ，当
数据保存完成之后再将上一次保存的 RDB 文件替换掉， 然后关闭子进程，这样可以保存每一次做 RDB 快照的时候保存的数据都是完整的，
因为直接替换 RDB 文件的时候可能会出现突然断电等问题而导致 RDB 文件还没有保存完整就突然关 机停止保存而导致数据丢失的 情况，可
以手动将每次生成RDB 文件。
RDB模式的优缺点：
优点：
-RDB 快照 保存了某个时间点的数据，可以通过脚本执行 bgsavebgsave(非阻塞 )或者 save( 阻塞 )命令自定义时
间点北备份，可以保留多个当出现问题恢复到不同时的版本。
-可以最大化Io的性能，因为父进程在保存 RDB 文件的时候唯一要做是 fork 出一个子进程，然后的
操作都会有这个子进程进行，父无需任何的 IO 操作
RDB 在大量数据比如几个 G的数据，恢 复的速度比 AOF快
缺点：
-不能时的保存数据，会丢失自上一次执行 RDB 备份到当前的内存数据。
-数据量非常大的时候，从父进程 fork 的时候需要一点时间，可能是毫秒或者秒。

3. AOF模式：
AOF：按照 操作顺序依次 将操作 添加 到指定 的日志文件当中，特点是数据安全性相对 较高 ，缺点 是即使有些操作 是重复的也会全部记录。
AOF和 RDB 一样使用了写时复制机制， AOF 默认为每秒钟 fsync 一次，即将执行的命令保存到 AOF 文
件当中，这样即使 redis 服务器发生故障的话顶多也就丢失 1 秒钟之内的数据，也可以 设置不同的 fsync
策略，或者设置每次执行命令的时候执行 fsync fsync 会在后台执行线程，所以主线程可以继续处理
用户的正常请求而不受到写入 AOF 文件的 IO 影响
AOF 模式优缺点：
AOF的文件大小要大于 RDB 格式的文件。
根据所使用的fsync 策略 (fsync 是同步内存中 redis 所有已经修改的文件到存储设备 ))，默认是
appendfsync everysec 即每秒执行一次 fsync

3. Redis对比memcached有什么优点

1、  支持数据的持久化：可以将内存中的数据保持在磁盘中，重启redis服务或者服务器之后可以从备份文件中恢复数据到内存继续使用。
2、  支持更多的数据类型：支持string(字符串)、hash(哈希数据)、list(列表)、set(集合)、zet(有序集合)
3、  支持数据的备份：可以实现类似于数据的master-slave模式的数据备份，另外也支持使用快照+AOF。
4、  支持更大的value数据：memcache单个key value最大只支持1MB，而redis最大支持512MB。
5、  Redis是单线程，而memcache是多线程，所以单机情况下没有memcache并发高，但redis 支持分布式集群以实现更高的并发，单Redis实例可以实现数万并发。
6、  支持集群横向扩展：基于redis cluster的横向扩展，可以实现分布式集群，大幅提升性能和数据安全性

4. redis各种架构升级

1. redis主从同步
redis主从同步实现数据的数据的备份。
虽然Redis 可以实现单机的数据持久化， 但 无论是 RDB 也好或者AOF 也好， 都 解决 不了 单点 宕机问题，即一旦 redis 服务器 本身 出现 系
统故障、硬件故障 等 问题 后， 就会直接造成数据的丢失 因此需要使用另外的技术来 解决 单点 问题。

2. redis哨兵机制
让master和slave角色的无缝切换，让业务无感知从而不影响业务使用，因此在主从架构中引入了Sentinel机制以解决master和slave角色的自动
切换问题,从而实现redis的高可用。

3. redis集群
以上redis哨兵机制，虽然可以解决redis高可用的问题，但是还是无法解决单机写入的瓶颈问题，因此引入redis cluster架构，同事解决了redis
高可用和横向扩展redis服务器，从而实现多台服务器并行写入以实现更高并发的目的

十二. 网络文件共享服务

1. ftp文件传输协议有几种模式

从服务器（数据通道）角度看：主动模式和被动模式2中
主动模式：服务器主动连接客户端

命令（控制）：客户端：随机port --->> 服务器：tcp21
数据：客户端：随机port <<---服务器：tcp20

注：命令通道，客户端通过命令通道将数据通道的随机端口号发送给服务端

被动模式：客户端主动连接服务端

命令（控制）：客户端：随机port --->> 服务器：tcp21
数据：客户端：随机port --->>服务器：随机port

注：命令通道，服务器端通过此通道将数据通道的随机端口号发送给客户端，

十三 linux 防火墙

1. REDIRECT端口转发

NAT表
可用于：PREROUTING OUTPUT 自定义链
通过改变目标IP和端口，将接受的包转发至不同端口
--to-ports port[-port]

iptables -t nat -A PREROUTING -d 172.16.100.10 -p tcp --dport 80 -j REDIRECT --to-ports 8080   
将来自访问本机莫服务的80端口，但是本机只有8080，需要将80端口转发到8080端口

2. SNAT

SNAT: 让本地网络中的主机通过某一特定地址访问外部网络，实现地址伪装
请求报文：修改源IP。
（请求报文转换了源地址，响应报文转换了目标地址）
例如：iptables -t nat -A POSTROUTING -s 192.168.18.0/24 ! -d 192.168.18.0/24 -j SNAT --to-source 172.22.18.17

3. DNAT

把本地网络中的主机上的某服务开放给外部网络访问(发布服务和端口映射)，但隐藏真实IP
请求报文：修改目标IP
（请求报文转换了目标地址，响应报文转换了源地址）
例如：iptables -t nat -A PREROUTING -d 172.22.18.17 -p tcp --dport 80 -j DNAT --to-destination 192.168.18.27

十四 lvs

1. lvs四种模式，10种调度算法

四种模型：LVS-NAT、LVS-DR、LVS-TUN、LVS-FULLNAT、
10种调度算法：

4种静态调度算法：RR(轮询),WRR(加权轮询),SH（源地址hash）,DH(目标地址hash)
6种动态调度算法：LC,WLC,SED,NQ,LBLC,LBLCR
LC：根据最少连接进行调度
WLC:默认调度算法

四种模式原理如下
比较常用的是nat和dr模式

lvs-nat：本质是多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改
为某挑出的RS的RIP和PORT实现转发
（1）RIP和DIP应在同一个IP网络，且应使用私网地址；RS的网关要指向DIP
（2）请求报文和响应报文都必须经由Director转发，Director易于成为系统瓶颈
（3）支持端口映射，可修改请求报文的目标PORT
（4）VS必须是Linux系统，RS可以是任意OS系统
    原理：就是把客户端发来的数据包的IP头的目的地址，在负载均衡器上换成其中一台RS的IP地址，并发至此RS来处理,RS处理完成后把数据交给经过负载均
衡器,负载均衡器再把数据包的原IP地址改为自己的IP｡期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器｡


    LVS-DR：Direct Routing，直接路由，LVS默认模式,应用最广泛,通过为请求报文重新封装一个MAC首部进
行转发，源MAC是DIP所在的接口的MAC，目标MAC是某挑选出的RS的RIP所在接口的MAC地址；源
IP/PORT，以及目标IP/PORT均保持不变
    转发方式：不修改请求报文的IP首部（源IP为CIP，目标IP为VIP），而在原IP报文之外再封装一个IP首部
（源IP是DIP，目标IP是RIP），将报文发往挑选出的目标RS；RS直接响应给客户端（源IP是VIP，目标IP
是CIP）
    原理：负载均衡器和RS都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默｡也就是说,网关会把对
这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC（因为IP一致）并将请求分发给这台
RS｡这时RS收到这个数据包,处理完成之后，由于IP一致，可以直接将数据返给客户，则等于直接从客户端收到这个数据包无异,处理后直接返回给客户
端｡由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为在同一台交换机上｡


lvs-fullnat：通过同时修改请求报文的源IP地址和目标IP地址进行转发

十五. keepalived

1. keepalived高可用实现原理

1）  keepalived通过VRRP（Virtual Router Redundancy Protocl即虚拟路由冗余协议）来实现高可用。
2）  在这个协议里会将多台功能相同的路由器组成一个小组，这个小组里会有1个master角色和N（N>=1）个backup角色。
3）  master会通过组播的形式向各个backup发送VRRP协议的数据包，当backup收不到master发来的VRRP数据包时，就会认为master宕机了。
此时就需要根据各个backup的优先级来决定谁成为新的mater,此时新的master继续对外提供服务。而当老的master节点恢复时，备用backup节点
又会释放主节点故障时接管的IP资源及服务，恢复到原来的备用角色。

2. 目前使用较多的高可用服装均衡组合如下

keeplaived+nignx < keepalived+haproxy <keepalived+lvs
并发量依次递增

十六 nginx、haproxy、lvs负载均衡的优缺点

1. 四层负载均衡和七层负载均衡

image.png

      四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。以常见的TCP
为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服
务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。
在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。 
      四层，客户端和Real Server仅仅只建立了一条连接，负载均衡器仅仅只起着转发这样的一个功能，只不过在转发的过程当中将IP报文头做个修改。
但是连接始终还是一条连接。这就是四层和七层负载均衡最大的不同地方。
      四层就是ISO参考模型中的第四层。四层负载均衡也称为四层交换机,它主要是通过分析 IP层及TCP/UDP层的流量实现的基于IP加端口的负载均
衡。常见的基于四层的负载均衡器有 LVS、F5等。

      所谓七层负载均衡，也称为“内容交换”，还称为七层交换机，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服
务器选择方式，决定最终选择的内部服务器。位于OSI的最高层（即应用层）此时负载均衡器支持多种应用协议,常见的有HTTP、FTP、SMIP等。
七层负载均衡器可以根据报文内容,再配合负载均衡算法来选择后端服务器,因此也称为"内容交换器"。比如,对于Web服务器的负载均衡,七层负载均衡
器不但可以根据"IP+端口"的方式进行负载分流。还可以根据网站的 URL、访问域名、浏览器类别、语言等决定负载均衡的策略，常见的七层负载均
衡器有nginx、haproxy。而且nginx和haproxy还可以进行四层负载均衡。
      七层负载均衡模式下，客户端和负载均衡器，负载均衡器和后端的real server分别建立TCP连接，即建立两条TCP连接。

      综合可以看到七层负载均衡器对负载均衡要求更加高，因为一个正常连接都会建立两条独立的TCP连接。由于建立了两条TCP连接，那么在一个
大并发的负载均衡模式下面很显然七层的这种负载均衡处理能力肯定是低于四层的。

2. 三大主流负载均衡器LVS、Nginx、HAproxy区别及优缺点

2.1 lvs、nginx、haproxy简单介绍

LVS的是Linux Virtual Server的简写，翻译为Linux虚拟服务器，企业界调度器即一个虚拟的服务器集群系统，是由我国章文嵩博士在1998年5月所研究成
立，也是中国国内最早出现的自由软件项目之一。
LVS由2部分程序组成，包括 ipvs 和 ipvsadm
1. ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。
2. ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)

Nginx是一款轻量级的Web服务器、代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强。
国内使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

HAProxy是一个使用C语言编写的自由及开放源代码软件，它提供高可用性、负载均衡，以及基于TCP(第四层)和HTTP（第七层）的应用程序代理。
HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发
连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。

2.2 lvs优缺点

优点：
1.抗负载能力强,工作在网络4层之上,仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。
2.配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。
3.工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。
4.无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会收到大流量的影响。
5.应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。

缺点：
1.软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
2.如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过
程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。

2.3 nginx优缺点

优点：
1. 支持两种代理模式：TCP（四层是在nginx1.9版本之后，也可以进行四层转发）和HTTP（七层）
2.工作在网络的7层之上时，可以针对http应用做一些分流的策略，比如针对域名、目录结构。它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。
3.对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能。
4.安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。
5.抗高并发且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。
6.可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。
7.不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。
8.作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。
9.可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有lighttpd了，不过lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。
10.可作为静态网页和图片服务器，这方面的性能也无对手。
11.Nginx社区非常活跃，第三方模块也很多。


缺点：
1.对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。不支持Session的直接保持，但能通过ip_hash来解决

2.4 haproxy优缺点

优点：
1.支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
2.支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。能够补充Nginx的一些缺点。
3.HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。
4.HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。
5.HAProxy负载均衡策略非常多，比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)
6.免费开源，稳定性也是非常好，可以与LVS相媲美；
7.自带强大的监控服务器状态的页面，实际环境中我们结合Nagios进行邮件或短信报警；

缺点：
1. 不能做Web服务器，即不支持HTTP cache功能；
2. 重载配置的功能需要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好；

2.5 使用场景

1.网站建设初期，可以选用Nigix/HAproxy作为反向代理负载均衡（或者流量不大都可以不选用负载均衡），因为其配置简单，性能也能满足一般的业务场景。
如果考虑到负载均衡器是有单点问题，可以采用Nginx/HAproxy+Keepalived来避免。
2.网站并发达到一定程度之后，为了提高稳定性和转发效率，可以使用LVS、毕竟LVS比Nginx/HAproxy要更稳定，转发效率也更高。不过维护LVS对维护人
员的要求也会更高，投入成本也更大。

2.6 lvs、haproxy、nginx调动策略各有哪些

1. lvs: 根据其调度时是否考虑各RS当前的负载状态,有静态和动态两种方法
      1.1 静态调动策略：仅根据算法本身进行调度
          RR(轮询)、WRR(加权轮询)、SH(源地址hash，可以实现回话绑定)、DH(目标地址hash)
      1.2 动态调动策略：：主要根据每RS当前的负载状态及调度算法进行调度Overhead=value 较小的RS将被调度
         LC(最小链接调度算法)、WLC、SED、NQ、LBLC(动态DH算法)等

2. haproxy：
    2.1. roundrobin：基于权重的轮询动态调度算法
    2.2. static-rr：权重轮询
    2.3. leastconn：加权的最少连接者优先
    2.4. source：根据请求源IP,这个跟Nginx的ip_hash机制类似
    2.5. uri：根据请求的URI
    2.6 hash：一致性hash算法
    2.6 url_param：表示根据请求的URI参数‘balance url_param’requires an URL parameter name;
    2.7. hdr(name)：根据HTTP请求头来锁定每一次HTTP请求
    2.8. rdp-cookie(name)：根据cookie来锁定并哈希每一次TCP请求

3. nginx:
    3.1 ip_hash: 源地址hash调动算法
    3.2 least_conn：最少链接调动算法
    3.3 rr: 轮询
    3.4 加权轮询weight
    3.5 url_hash： 按访问的url的hash结果分配请求，是每个url定向到同一后端服务器上
    3.5. hash关键值

十七 java和tomcat相关

1. 有状态和无状态的区别

http请求无状态，多次请求之间没有依赖关系
有状态就是多次访问之间有关联关系，需要记录多次之间的访问关系

2. http的无状态，通过什么办法可以http的无状态？

    无状态：指的是服务器端无法知道2次请求之间的联系，即使是前后2次请求来自同一个浏览器，也没有
任何数据能够判断出是同一个浏览器的请求。后来可以通过cookie、session机制来判断。
    浏览器端第一次HTTP请求服务器端时，在服务器端使用session这种技术，就可以在服务器端产生一个
随机值即SessionID发给浏览器端，浏览器端收到后会保持这个SessionID在Cookie当中，这个Cookie值
不能持久存储，浏览器关闭就消失。浏览器在每一次提交HTTP请求的时候会把这个SessionID传给服务
器端，服务器端就可以通过比对知道是谁了。
    Session通常会保存在服务器端内存中，如果没有持久化，则易丢失。
    Session会定时过期。过期后浏览器如果再访问，服务端发现没有此ID，将重新获得新的SessionID
更换浏览器也将重新获得新的SessionID
    Session和cookie都是服务器产生的,cookie存放在客户端，session存放在服务端。

3. 后端并行部署多个tomcat服务，前端通过负载均衡器进行负载调动，如何实现session共享呢？

  如果使用HAProxy或者Nginx等做负载均衡器，调度到了不同的Tomcat上，那么也会出现找不到SessionID的情况。
  实现会话保持的方法有如下几种：
    1. Session sticky会话粘性
        session绑定
        1.1 nginx: source ip
        1.2 Haproxy：cookie
         优点：简单易配置
         缺点：如果目标服务器故障后，如果没有做sessoin持久化，就会丢失session
    
    2.  session复制集群
       Tomcat自己的提供的多播集群，通过多播将任何一台的session同步到其它节点。
        缺点：
         Tomcat的同步节点不宜过多，互相及时通信同步session需要太多带宽。
         每一台都拥有全部session，内存损耗太多。
    3. session server
        session 共享服务器，使用memcached、redis做共享的Session服务器。

总结：
   1. session绑定，基于IP或session cookie的。其部署简单，尤其基于session黏性的方式，粒度小，对负载
 均衡影响小。但一旦后端服务器有故障，其上的session丢失。
   2. session复制集群，基于tomcat实现多个服务器内共享同步所有session。此方法可以保证任意一台后端服 
务器故障，其余各服务器上还都存有全部session，对业务无影响。但是它基于多播实现心跳，TCP单播实现
复制，当设备节点过多，这种复制机制不是很好的解决方案。且并发连接多的时候，单机上的所有session
占 据的内存空间非常巨大，甚至耗尽内存。
   3. session服务器，将所有的session存储到一个共享的内存空间中，使用多个冗余节点保存session，这样 
做到session存储服务器的高可用，且占据业务服务器内存较小。是一种比较好的解决session持久的解决方案。

4. tomcat优化

十八 docker与k8s

1. docker对比虚拟机

使用虚拟机是为了更好的实现服务运行环境隔离，每个虚拟机都有独立的内核，虚拟化可以实现不同操作系统的虚拟机，但是通常一个
虚拟机只运行一个服务，很明显资源利用率比较低且造成不必要的性能损耗，我们创建虚拟机的目的是为了运行应用程序，比如 Nginx、
PHP、Tomcat 等 web 程序，使用虚拟机无疑带来了一些不必要的资源开销，但是容器技术则基于减少中间运行环节，带来较大的性能提升。

1. 资源利用率更高：一台物理机可以运行数百个容器，但是一般只能运行数十个虚拟机。
2. 开销更小：不需要启动单独的虚拟机占用硬件资源。
3. 启动速度更快：可以在数秒内完成启动

docker的优点：
1. 快速部署：短时间内可以部署成百上千个应用，更快速交付到线上。
2. 高效虚拟化：不需要额外的 hypervisor 支持，直接基于 linux 实现应用虚拟化，相比虚拟机大幅提高性能和效率。
3. 节省开支：提高服务器利用率，降低 IT 支出。
4. 简化配置：将运行环境打包保存至容器，使用时直接启动即可。
5. 快速迁移和扩展：可夸平台运行在物理机、虚拟机、公有云等环境，良好的兼容性可以方便将应用从 A 宿主机迁移到 B 宿主机，甚至是 A 平台迁移到 B 平台。

docker的缺点：
隔离性：各应用之间的隔离不如虚拟机彻底

2. namespace和cgroup

namespace 是 Linux 系统的底层概念，在内核层实现，即有一些不同类型的命名空间被部署在内核，各个 docker 容器运行在同一个 docker 主
进程并且共用同一个宿主机系统内核，各docker 容器运行在宿主机的用户空间，每个容器都要有类似于虚拟机一样的相互隔离的运行空间，但
是容器技术是在一个进程内实现运行指定服务的运行环境，并且还可以保护宿主机内核不受其他进程的干扰和影响，如文件系统空间、网络空
间、进程空间等，目前主要通过以下技术实现容器运行空间的相互隔离


MNT Namespace(mount)：提供磁盘挂载点和文件系统的隔离能力
IPC Namespace(Inter-Process Communication)：提供进程间通信的隔离能力
UTS Namespace(UNIX Timesharing System)：提供主机名隔离能力
PID Namespace(Process Identification)   ：提供进程隔离能力
Net Namespace(network)：提供网络隔离能力
Namespace(user)：提供用户隔离能力

MNT Namespace：
每个容器都要有独立的根文件系统有独立的用户空间，以实现在容器里面启动服务并且使用容器的运行环境，即一个宿主机是 ubuntu 的服务器，
可以在里面启动一个 centos 运行环境的容器并且在容器里面启动一个 Nginx 服务，此 Nginx运行时使用的运行环境就是 centos 系统目录的
运行环境，但是在容器里面是不能访问宿主机的资源，宿主机是使用了 chroot 技术把容器锁定到一个指定的运行目录里面。

IPC Namespace：
一个容器内的进程间通信，允许一个容器内的不同进程的(内存、缓存等)数据访问，但是不能夸容器访问其他容器的数据。

UTS Namespace：
UTS namespace（UNIX Timesharing System 包含了运行内核的名称、版本、底层体系结构类型等信息）用于系统标识，其中包含了 hostname和
域名 domainname  ，它使得一个容器拥有属于自己 hostname 标识，这个主机名标识独立于宿主机系统和其他容器

PID Namespace：
Linux 系统中，有一个 PID 为 1 的进程(init/systemd)是其他所有进程的父进程，那么在每个容器内也要有一个父进程来管理其下属的子进程，那么
多个容器的进程同 PID namespace 进程隔离(比如 PID 编号重复、器内的主进程生成与回收子进程等)。

Net Namespace：
每一个容器都类似于虚拟机一样有自己的网卡、监听端口、TCP/IP 协议栈等，Docker 使用 network namespace 启动一个 vethX 接口，这
样你的容器将拥有它自己的桥接 ip 地址，通常是 docker0，而 docker0 实质就是 Linux 的虚拟网桥,网桥是在 OSI 七层模型的数据链路层的网
络设备，通过 mac 地址对网络进行划分，并且在不同网络直接传递数据。

User Namespace：
各个容器内可能会出现重名的用户和用户组名称，或重复的用户 UID 或者GID，那么怎么隔离各个容器内的用户空间呢？
User Namespace 允许在各个宿主机的各个容器空间内创建相同的用户名以及相同的用户 UID 和 GID，只是会把用户的作用范围限制在每个容器
内，即 A 容器和 B 容器可以有相同的用户名称和 ID 的账户，但是此用户的有效范围仅是当前容器内，不能访问另外一个容器内的文件系统，即
相互隔离、互不影响、永不相见。

 Linux Control Groups：
在一个容器，如果不对其做任何资源限制，则宿主机会允许其占用无限大的内存空间，有时候会因为代码 bug 程序会一直申请内存，直到把宿
主机内存占完，为了避免此类的问题出现，宿主机有必要对容器进行资源分配限制，比如CPU、内存等，Linux Cgroups 的全称是 Linux 
Control Groups，它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等。此外，还能够对进程
进行优先级设置，以及将进程挂起和恢复等操作。

3. docker镜像的制作

docker镜像的制作最主要是要熟练的写dockerfile文件，dockerfile文件是制作docker镜像的关键

打镜像最重要的步骤就是写dockerfile文件,通过dockerfile创建docker镜像

FROM centos  定义基础镜像
ENV 设置容器变量
RUN 在打镜像中执行shell命令
COPY/ADD 添加本地文件或目录或压缩包到镜像的指定位置 
 注：ADD能将压缩文件自动解压到指定目录下，在目录路径不存在的情况下，自动镜像内部所需目录，而copy只有复制文件到指定路径下
EXPOSE 80 443暴露端口 注：启动容器，容器内部对外暴露的端口
CMD[“nginx”] 启动的容器指定默认要运行的程序 
##运行的命令，每个 Dockerfile 只能有一条，如果有多条则只有最后一条被执行。
## 如果在从该镜像启动容器的时候也指定了命令，那么指定的命令会覆盖Dockerfile 构建的镜像里面的 CMD 命令，即指定的命令
#优先级更高，Dockerfile 的优先级较低一些

Docker build -t  TagName .

4.

十九、gitlab与jenkins

1. Jenkins上线流程

代码克隆—>代码编译—>代码测试—>代码打包-->haproxy服务器下线后端服务-->停止后端服务—>代码copy-->启动后端服务-->测试—>harproxy服务上线后端服务