大厂一般四面，三面技术 + 一面薪资
一面：同事面
（面技术，把简历写到的和工作中要用到的都会问到位，时间至少1小时）

二面：直属TL（领导）面
（TL面，不仅仅面技术，主要贴近项目业务）

三面：总监面
（总监面，一般比第一面和第二面容易，可能主要是大的架构方向和思想，价值是否符合）

  四面：HR面
（HR压薪资，HR是有kpi的，发了几个offer，有几个高级和低级，低级发了高级的薪资这说不过去，岗位有薪资标准，但是我们还是可以争取）
（薪资多轮争取，一个公司中在面试一个岗位的时候，他会面试至少四五十人，然后进入到候选池里面，至少有三到五个人左右，防止发了offer后放鸽子 ，HR要在这三到五个人中权衡薪资和能力，为什么说同样两个人，能力差不多，工作岗位差不多，但是薪资会差几千块，在面试前，自我介绍，面试中回答问题，面试后以及在谈薪阶段，在这些地方差的）

慎入（区别对待！但是门槛低，外包公司经历在简历中尽量包装掉！！）

去公司面试的时候可能有两轮面试或者三轮面试，但是无论那一轮面试百分之百都会让你说一段自我介绍，大概要说一分多钟左右到三分钟，不要太长也不要太短（自己自拍进行练习，回放感觉效果，要自信）

	这个自我介绍就是，基本上从毕业开始，如果没有学历的话，就不要说专业了，就从工作经验说起，说项目，说擅长的技术,所以说面试的原则就是扬长避短，把长处说出来，把短处相对的弱化一下，这个自我介绍一定要多准备点，用文字写出来，不要用脑子空想，今天想的这样，睡一觉之后明天就想的那样了，所以说一定要写出来

	比如说对k8s不熟，但是会虚拟化，那么就划重点在项目上多写擅长的技术，比如监控，这个监控还是比较简单的

	比如在上一家负责监控的，从监控的规划上说起，我们用了分布式的监控，然后是什么主动模式的，包括我们的监控项是怎么定的，触发器的值是怎么定的，告警的方式是通过邮件还是短信还是微信还是钉钉，然后你的模板是怎么做的，以及这个整合的方案都是怎么实施的，一定要多擅长的

	工作经验我们可以把项目着重说一下，而且工作经验一定要和简历对的上，因为我们在说自我介绍的时候，面试官他一般会看我们的简历，你说你的工作经验是什么什么样子，那么面试官会看着简历对一下，不要说的不一样，或者顺序不一样，假如说18年到19年在A公司，结果在自我介绍的时候说18年到19年在另外一个公司，这就麻烦了，所以说工作经验和简历，包括工作年限一定要一模一样，写的什么就是什么

面试过程中面试官大多是顺着自己介绍的项目一直深挖的，比如，我们自己介绍的项目是，日志文件通过flme，kafka然后通过spring boot项目保存到hbase里面去，后续通过spark和mr进行处理

然后面试官问问题：kafka是如何保证excetly once，hbase rowkey是如何设计的。后续使用spark和MapReduce进行处理是map数量和rdd数量是如何控制的

注意：当面试官问完问题之后，在我们的角度上复述一遍，确认一遍，在面试官纠正完之后，或者认可之后，我们在作答，避免回答问题南辕北辙  

面试官对问的问题其实是有自己的心理预期答案，回答的时候要尽量往这方面靠

  回答问题尽量回答全面（使用场景，解决方案，回答问题闭环性），不是很熟悉的点到为止（言多必失！！）

面试官问的问题未必都可以回答上来，面试官对面试者是有一个限度的，比如问了一个问题回答不上来，其实无所谓，问两个回答不上来，还是可以接受，但是问到三个都回答不上来，其实上基本就被pass掉了，尽量将话题往自己熟悉会的领域引导！！！被问到的问题不会，使用自己熟悉的领域，退而求其次帮助其解决，领导仅关系结果，不关心过程

也可以试探性的提问面试官（涨经验，不可能第一次面试就拿到offer了，对自己简历中不完善的情况，直接试探性提问面试官，将结果可以优化到下一次面试中）

一般在面试后，面试官可能会提问
参考回答1：我们当前这部门未来的发展规划大概是什么样子的?
（部门一般都会有目标，比如要上k8s，比如要迁云）

参考回答2：针对我今天的面试有什么有待改进的地方，或者说有什么建议可以给到我！！！			（这是试探，比如我们感觉自己面的不行，或者感觉自己面的可以，但是我们最好了解给面试官留下来的印象，如果面试官说你有哪些方面还有待改进，或者你有那些技术掌握还不是很到位，他这样是不是就是在婉拒你了，那么我们就知道了可以不用在考虑他了，就可以去找下一家了，而且这样也是在涨经验，补齐短板，如果面试官可能说差不多，或者你这个人都还不错，那么我们第一面可能没有什么问题了）

• 主动模式与被动模式的区别（以zabbix agent为参照）

  • 被动模式：也是默认的模式，此模式下zabbix agent需要监听在10050端口，zabbix server端需要像zbabix agent发起数据请求（一般该请求是key，如agent.ping）,并且携带需要监控的key(从数据库种取出)，然后由zabbix agent采集之后，等待zabbix server取数据。该模式只适用于监控主机不多的环境。

  • 主动模式：zabbix agent配置中，会配置zabbix active（zabbix server的地址），以及hostname（定义zabbix agenet服务器地址或域名）。先是zabbix agent打开一个随机端口向zabbix server的10051端口发起连接，获取监控项，然后进行数据采集，采集之后主动发给zabbix server，最后又zabbix server将数据写入数据库（mysql）

• 通过shell脚本获取自定义监控的值，并对脚本赋予执行权限

• 在zabbix agent配置文件中，引用脚本。并重启zabbix agent

• 在zabbix server通过zabbix-get 命令测试监控的值是否能获取成功

  • zabbix-get -s IP p PORT -K ”脚本名称[参数]”

• 创建模板，触发器，图形等，并关联到指定的主机上，稍等几分钟后验证数据

1. 设置work_processes数量，可以增加nginx并发访问量

2. work_cpu_affinity将工作进程和指定cpu做绑定，可以避免nginx的工作进程在不同的cpu做来回切换，避免内存频繁的申请和回收而带来不必要的资源消耗。

• 日志：tail -f

• 文件：grep egrep sed awk

  • cat，vim，nano，less，tail，head，scp， cp， mv， rm， install， sz， rz

• 内存：free -h

• Cpu：top，htop

• 磁盘：df -TH fdisk -l

• 搭建过程 ：

  • 安装神略…

  • 开启二进制日志（bin_log），并设置唯一的server_id

  • 在master节点使用mysqldump命令完全备份数据，并在slaveJ节点导入数据

  • 在master节点创建用于主从复制的用户并授权

  • 在slave节点执行change master to，并执行start slave，观察io线程和sql线程是否为yes

• 主从复制原理：

  • Master节点会开启一个dump线程，用于接受从节点的sync数据请求，slave节点会开启io线程和sql线程。Io线程负责将master发过来的二进制日志写入中继日志中，而sql线程负责从中继日志中读取二进制日志，并执行。

• 默认情况下，MySQL的复制功能是异步的，异步复制可以提供最佳的性能，主库把binlog日志发送给从库即结束，并不验证从库是否接收完毕。这意味着当主服务器或从服务器端发生故障时，有可能从服务器没有接收到主服务器发送过来的binlog日志，这就会造成主服务器和从服务器的数据不一致，甚至在恢复时造成数据的丢失

• 主库执行更改前误设置set sql_log_bin=0,会使主库不记录binlog，从库也无法变更这部分数据

• 主库binlog格式为statement（一般为row），同步到从库执行后可能导致主从不一致

• 主库或从库意外宕机，可能造成binlog（二进制日志）或relaylog（中继日志）出现损坏，导致主从不一致

• 从节点未设置只读，误操作写入数据

• 主从实例版本不一致，将使某些功能有些许变化

• Memory，CVS，myisam，innodb等
  | | Myisam | Innodb |
  |-|-|-|
  | 事务 | 不支持 | 支持 |
  | 聚集索引 | 支持非聚集索引，全文索引 | 支持聚集索引，5.5版本之后支持全文索引 |
  | 外键 | 不支持 | 支持 |
  | 数据备份（热备，温备，冷备） | 不支持热备 | 都支持 |
  | 锁级别 | 表级锁 | 表或行级锁 |
  | MVCC（多版本访问控制） | 不支持 | 支持 |
  | 优点 | 读取数据快，占用资源少 | 崩溃恢复性更好 |

mysqlslap -a --concurrency=50,100 --number-of-queries 1000  -uroot

• mycat：实现读写分离

• mha：实现高可用（自动提升slave为master）

• gelera cluster：实现mysql高可用及高并发（多主，集群模式增加mysql写性能）

• ACID特性：原子性，一致性，隔离性，持久性

• 隔离级别：读未提交（可能出现脏数据）

  • 读提交(不可重复读)

  • 可重复读（可能出现幻读）

  • 序列化：未提交的读事务阻塞修改事务（加读锁，但不阻塞读事务），或者未提交的修改事务阻塞其它事务的读写（加写锁，其它事务的读，写都不可以执行）。会导致并发性能差

• 锁类型：

  • 读锁：共享锁，S锁，只读不可写，多个读互不阻塞

  • 写锁：独享锁，排它锁，X锁，写锁会阻塞其他事务的读和写

• 二叉树（容易瘸腿，不平衡），红黑树，B-（高瘦型），B+（矮胖型）等

• Mysqldump，xtrbackup

mysqldump -uroot -p -A -F -E -R --triggers --single-transaction --master-data=2 --flush-privileges --default-character-set=utf8 --hex-blob >${BACKUP}/fullbak_${BACKUP_TIME}.sql

show master status;

show slave status;

show processlist;

show binlog events;

show binary logs;

max_connections=2000                     会话连接数

open_files_limit= 10240                  所有线程打开表的数量

back_log=300                             操作系统在监听队列中能保持的连接数

max_allowed_packet=32M                   每个连接传输数据大小，最大1G

wait_timeout=10                          指定请求的最大连接时间

query_cache_size= 128M                   指定查询能够使用的缓冲区大小

transaction_isolation=REPEATABLE-READ    事务的隔离级别

log-bin=/data/mysql/log-bin              二进制日志

binlog_format=row                        二进制日志格式

innodb_file_io_threads = 4               用来同步io线程的数量

innodb_log_file_size=512M                在日志组中每个日志文件的大小

long_query_time=2                        慢查询时间

FROM   指定基础镜像

Maintainer   注释信息，作者，日期等

RUN        执行非交互式的shell命令

COPY       将宿主机的文件复制到容器中

ADD        将宿主机的文件复制到容器中，并且会自动解压tar.gz格式的压缩包

ENV         定义容器环境，一般mysql会用到

USER         运行服务的用户

Volume      将宿主机的某目录挂载到容器中，一般是某些配置文件，且宿主机的目录也是挂载到共享存储上

EXPOSE      声明容器中要暴漏的端口（或者说映射到宿主机上的端口）

CMD         启动服务，运行一个占据终端且pid为1的进程。一般是运行一个脚本或某服务的启动[需要关闭后台运行]

• Docker不是虚拟化方法。它依赖于实际实现基于容器的虚拟化或操作系统级虚拟化的其他工具。为此，Docker最初使用LXC驱动程序，然后移动到libcontainer现在重命名为runc。Docker主要专注于在应用程序容器内自动部署应用程序。应用程序容器旨在打包和运行单个服务，而系统容器则设计为运行多个进程，如虚拟机。因此，Docker被视为容器化系统上的容器管理或应用程序部署工具。

  • A 容器不需要引导操作系统内核，因此可以在不到一秒的时间内创建容器。此功能使基于容器的虚拟化比其他虚拟化方法更加独特和可取。
  • B 由于基于容器的虚拟化为主机增加了很少或没有开销，因此基于容器的虚拟化具有接近本机的性能。
  • C 对于基于容器的虚拟化，与其他虚拟化不同，不需要其他软件。
  • D 主机上的所有容器共享主机的调度程序，从而节省了额外资源的需求。
  • E 与虚拟机映像相比，容器状态（Docker或LXC映像）的大小很小，因此容器映像很容易分发。
  • F 容器中的资源管理是通过cgroup实现的。Cgroups不允许容器消耗比分配给它们更多的资源。虽然主机的所有资源都在虚拟机中可见，但无法使用。这可以通过在容器和主机上同时运行top或htop来实现。所有环境的输出看起来都很相似

镜像的导入导出: docker load/save

镜像的上传和下载： docker push/pull

镜像的构建：docker build 

镜像的查看和搜索：docker imgaes/search

镜像的构建过程：docker history

镜像的删除 docker rmi



容器的运行：docker run 

进入正在运行的容器：docker exec 

以测试的方法运行容器：docker run –-rm

查看容器的详细信息：docker inspect    （可以做监控）

查看容器：docker ps [-aq] [-f k=v]

删除容器：docker rm [-f]

宿主机与容器之间进行文件拷贝：docker cp

将宿主机提交为镜像：docker commit [-m]

• none：没有网络信息，只有一个回环地址。适用于数据计算或通过python对数据进行分析等场景。

• host：网络模式中性能最强的，与宿主机共享一个网路空间。适用于mysql,redis,kafka,大数据等场景

• container：寄生模式，与已存在的容器共享一个网络空间，两个容器之间可以通过lo网卡和容器ip地址通信。

• Bridge：桥接模式，默认模式，使用最广泛的模式，此模式会为每个容器分配一个网络空间，并将各个容器的网络通过docker0（虚拟网桥）与宿主机连接

• 单机场景下：

  • 同一网段（自定义网络，默认为bridge）：通过容器名称或自定义别名（--link）
  • 不同网络（自定义网络，默认为bridge）：利用iptables规则[iptables-save/iptables-resotre]

• 跨主机：

  • 各宿主机不在同一个网段，且个宿主机的容器也不再一个网段（容器网段默认为127.17.0.1，修改方法：docker.service --bip 10.10.10.1/24）: 在宿主机上添加路由

• namespace（资源隔离）；

• cgroups（资源限制）

  • 运行容器时通过-m --cpu指定内存和cpu限制

• Resourcequota 实现对命令空间的资源进行限制。

• Limitrange 实现对单个容器使用的资源进行限制。

• 权限：使用rbac，基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对 计算机或网络资源的访问的方法。

• 组件：

  • Kube-apiserver:为集群的共享前端访问入口，为资源对象提供验证并配置数据，kubernetes中的所有组件都与之交互，唯一能与etcd交互

  • Kube-scheduler:kubernetes调度器，负责将pods指派到合法的节点上（及把最终的指派结果通过apiserver存放到etcd中）。 设置策略，亲和与反亲和等规范

  • Kube-controller-manager:集群内部的管理中心，负责集群中的node，pod副本，服务断点，命令空间，服务账户，资源定额的管理。当某个Node意外宕机时，Controller Manager会及时发现并执??动化修复流程，确保集群中的pod副本始终处于预期?作状态。

  • Kube-haproxy:网络代理，调用宿主机内核维护pods网络规则并执行连接转发来实现kubernetes服务访问。以及监听与kube-apiserver发现定义的服务，并能够通过一组后端进行简单的tcp，udp流转发。简单来说：调用宿主机内核，创建iptables或ipvs规则，通过这些规则，我们可以实现对特定的service进行访问

  • Kubelet:运行在node节点上的执行者,它会监视宿主机上的pod资源，并向master汇报node节点的状态信息（健康检查[探针技术实现]）。以及通过paiserver执行kube-scheduler调度分配至etcd中存取的任务

  • etcd:默认的k/v数据存储系统，保存所有集群数据，支持分布式集群功能。

• 访问流程：

  • k8s前面一般有个负载均衡器,当我们访问负载均衡器时，它会转发至那些node节点上那些nodeport，这些nodeport再转发至service，service根据label标签选择器（selector），把请求转发至后端pod，如果后端pod有相互调用，那么pod会根据service（会自动筛选和匹配，把那些符号条件的pod自动添加到当前service的endpoint中）去调用其他pod。

• Probe是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用容器实现的handler（处理程序）。有三种类型的处理程序：
  • ExecAction：在容器内执行指定命令。如果命令退出时的返回码为0，则认为诊断成功。
  • TCPSocketAction：对容器的ip地址上的指定端口执行tcp检查。如果端口打开，则诊断被认为时成功的
  • HTTPGetAction： 对容器的ip地址上指定端口和路径执行HTTP Get请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的。

• LivenessProbe：

  • 告诉kubelet对pod执行探测之后是否对pod进行重启
  • 无论pod探测结果如何，都会把pod地址加入到service的endpoint中

• ReadinessProbe：

  • 即使探针探测失败也不会重启pod
  • 探测失败后不会把pod地址加入到service的endpoint中

• 在第一次通过文件创建资源后，可再次执行apply，如果xx.yml文件发生变化，则apply会根据变化的文件对资源进行更新。而再次create则必须，把第一次创建的资源删除后，才能执行

• Pending（悬决）：正在创建pod但是pod中的容器还没有全部被创建完成，处于此状态的pod应该检查pod依赖的存储是否有权限挂载，镜像是否可以下载，调度是否正常。

• Failed：pod中有容器启动失败而导致pod工作异常。如配置文件错误。

• Unknown：由于某种原因无法获得pod的当前状态，通常是由于与pod所在node节点通信错误或超时。（如当前pod所在的node上的kubelet没有及时汇报当前node的状态）

• Successded：pod中的所有容器都被成功终止，即pod里所有的容器均已被terminated（终止）

• Unschedulable：pod不能被调度，kube-scheduler没有匹配到合适的node节点。一般是由于创建该pod所需要的资源太多。资源不足而导致。

• Podscheduled：pod处于调度中，在kube-shcheduler该开始调度的时候，还没有将pod分配到指定的node，在筛选出合适的节点后就会更新etcd中的数据，将pod分配到指定的node。出现这种原因很可能是创建的pod需求过多而导致（kubescheduler需要一个一个创建）

• Initialized：所有pod中的初始化容器已经完成了。如MySQL主从，需要同步数据；容器的环境初始化

• Imagepullbackoff：pod所在的node节点下载镜像失败。有可能是该节点上没有指定私有仓库的位置（/lib/system/system/docker.service文件--insecure-registry参数）或没有登录

• Running：pod内部的容器已被创建并且启动。

• Ready：表示pod中的容器已经可以提供访问服务

• restartPolicy：

  • always：当容器异常时，k8s自动重启该容器，replicationcontroller/reolicaset/deployment
  • OnFailure: 当容器失败时（容器停止且退出状态码不为0），k8s自动重启该容器
  • Never：不论容器运行状态如何都不会重启该容器

• imagePullPolicy：

  • Always ： 默认值，每次重建pod都会重新拉取镜像
  • Never 从不到镜像中心拉取镜像，只使用本地镜像
  • IfNotPresent node节点没有此镜像就去指定的镜像仓库中拉取，node有就是要node本地镜像。

• UserSpace k8s v1.2及以后就已经淘汰

• IPtables 目前默认方式，1.1开始支持，1.2开始为默认

• IPVS 1.9引入到1.11正式版本，需要安装ipvsadm、ipset工具包和加载ip_vs内核模块

• Userpace： 影响处理效率（报文需要在用户空间和内核空间来回拷贝）

• iptables： 逐行匹配规则，故在iptables中，范围约下的，往前方。

• 使用IPVS模式，Kube-Proxy会监视KubernetesService对象和Endpoints，调用宿主机内核Netlink接口以相应地创建IPVS规则并定期与KubernetesService对象Endpoints对象同步IPVS规则，以确保IPVS状态与期望一致，访问服务时，流量将被重定向到其中一个后端Pod,IPVS使用哈希表作为底层数据结构并在内核空间中工作，这意味着IPVS可以更快地重定向流量，并且在同步代理规则时具有更好的性能，此外，IPVS为负载均衡算法提供了更多选项，例如：rr(轮询调度)、lc(最小连接数)、dh(目标哈希)、sh(源哈希)、sed(最短期望延迟)、nq(不排队调度)等。

• WAL是write ahead log的缩写，顾名思义，也就是在执行真正的写操作之前先写一个日志，预写日志。wal: 存放预写式日志,最大的作用是记录了整个数据变化的全部历程。在etcd中，所有数据的修改在提交前，都要先写入到WAL中。
  • 方法一：

DATE=`date+%Y-%m-%d_%H-%M-%S`  ETCDCTL_API=3  /usr/bin/etcdctl  snapshot   save  /data/etcd-backup-dir/etcd-snapshot-${DATE}.db
ETCDCTL_API=3 etcdctl  snapshot  restore  snapshot.db  --data-dir=/opt/etcd-testdir

- 方法二

./ezctl  backup  k8s-01
./ezctl restore k8s-01

• Calico是一个纯三层的网络解决方案，为容器提供多node间的访问通信，calico将每一个node节点都当做为一个路由器(router)，各节点通过BGP(Border Gateway Protocol) 边界网关协议学习并在node节点生成路由规则，从而将不同node节点上的pod连接起来进行通信

• IPIP可以实现跨不同网段建立路由通信，但是会存在安全性问题，其在内核内置，可以通过Calico的配置文件设置是否启用IPIP，在公司内部如果k8s的node节点没有跨越网段建议关闭IPIP

  • IPIP是一种将各Node的路由之间做一个tunnel，再把两个网络连接起来的模式。启用IPIP模式时，Calico将在各Node上创建一个名为"tunl0"的虚拟网络接口。
  • BGP模式则直接使用物理机作为虚拟路由路（vRouter），不再创建额外的tunnel。

• Prefork：一个主进程生成多个子进程，每个子进程有一个独立的线程处理用户请求。最大支持并发C10K，且占用资源。适用于访问量不是很大的场景。

• Worker：多进程和多线程的混合模型。一个控制进程启动多个子进程，每个子进程里包含固定的线程来处理请求。高并发场进行无线程可用（在开启keepalive的长连接，某个线程会长时间备占据，及时没有数据传输也会等到超时后才会释放）

• Events：多进程和多线程的混合模型。与worker模型相比，event模型会在每个子进程的线程中加入一个专门负责监听的线程。

JVM 和 Tomcat 自身调优两部分。

内存空间优化(catalina.sh )
JAVA_OPTS="-server -Xms4g -Xmx4g -XX:NewSize= -XX:MaxNewSize = -xx:maxnewsize "
-server：服务器模式
-Xms：堆内存初始化大小
-Xmx：堆内存空间上限
-XX:NewSize=：新生代空间初始化大小
-XX:MaxNewSize=：新生代空间最大值


线程池调整（server.xml）
connectionTimeout ：连接超时时长,单位ms
maxThreads="600"       ///最大线程数
minSpareThreads="100"///初始化时创建的线程数
maxSpareThreads="500"///一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。
acceptCount="700"//指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理
URIEncoding：URI 地址编码格式，建议使用 UTF-8

禁用dns查询
server.xml文件中的Connector元素，修改属性enableLookups参数值: enableLookups="false"
如果为true，则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名，若为false则不进行DNS查询，而是返回其ip地址

设置sessino过期时间
\web.xml中通过参数指定：
180

• worker_processes 8; nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数 (如,2个四核的cpu计为8)。

• worker_cpu_affinity 00000001 00000010 为每个进程分配cpu，上例中将8 个进程分配到8 个cpu，当然可以写多个，或者将一个进程分配到多个cpu

• worker_rlimit_nofile 65535 ;这个指令是指当一个nginx 进程打开的最多文件描述符数目 ， 最好与ulimit -n 的值保持一致。

• use epoll; 使用epoll 的I/O 模型

• worker_connections 65535; 每个进程允许的最多连接数，

• keepalive_timeout 60; keepalive 超时时间。

• client_header_buffer_size 4k; 客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小

• open_file_cache max=65535 inactive=60s; 这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。

• open_file_cache_valid 80s; 这个是指多长时间检查一次缓存的有效信息。

• open_file_cache_min_uses 1; open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。

• 分析服务的访问日志，
• 基于第三方的软件，监控宝等

echo > file 或
cat /dev/null > file

df -i

Raid0，Raid1，Raid5，Raid10

• 本质

  • 硬链接：本质是同一个文件
  • 软链接：本质不是同一个文件

• 跨设备

  • 硬链接：不支持
  • 软链接：支持

• inode

  • 硬链接：相同
  • 软链接：不同

• 链接数

  • 硬链接：创建新的硬链接,链接数会增加,删除硬链接,链接数减少
  • 软链接：创建或删除,链接数不会变化

• 文件夹

  • 硬链接：不支持
  • 软链接：支持

• 相对路径

  • 硬链接：原始文件相对路径是相对于当前工作目录
  • 软链接：原始文件的相对路径是相对于链接文件的相对路径

• 删除源文件

  • 硬链接：只是链接数减一,但链接文件的访问不受影响
  • 软链接：链接文件将无法访问

• 文件类型

  • 硬链接：和源文件相同
  • 软链接：链接文件,和源文件无关

• 文件大小

  • 硬链接: 和源文件相同
  • 软链接: 源文件的路径的长度

• 无状态请求对于客户端的单次请求的处理，不依赖于其他请求，处理一次请求的信息都包含在请求里，典型的无状态服务的例子就是http 协议。例如，要实现一个计算求和的服务，每次请求都将求和的两个值传送给服务端，然后服务端计算求和结果，并返回给客户端，服务端不保存任何信息，这样的服务就属于无状态服务。

• 有状态服务像mysql主从等

• 所谓4层转发：也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

  • 以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

• 所谓7层负载均衡：也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

  • 以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式

• LVS：

  • 在lvs/nginx/haproxy当中是性能最强的负载均衡器，尤其是DR模式，??的请求经过LVS后转发给real server进?相应，但是响应报?是web直接通过?关进?响应，但是没有七层的转发功能，因此在七层的URL判断、域名处理功能都不?持，NAT和隧道模式很少使?。

• Haproxy：

  • 同时?持4层和七层，性能没有LVS强，但是官?资料表?单机可以承受100W并发，通常可以达到数?万并发，通常会使?Haproxy 作为4层负载均衡服务器，在访问量较?(100W并发以上)会使?LVS的DR模式。

• Nginx：

  • 早期只?持7层的动静分离，后期(1.9版本)开始?持TCP负载功能但是很少使?nginx作为4层负载均衡服务器，nginx通常?于动态服务(java、PHP、Python)实现动静分离、全站https、以及基于域名的多站点、通过localtion匹配??URL进?rewrite处理等。

• lvs

  • 静态方法仅根据算法本身进行调度

    • 1、RR：roundrobin，轮询,较常用
    • 2、WRR：Weighted RR，加权轮询,较常用
    • 3、SH：Source Hashing，实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定
    • 4、DH：Destination Hashing；目标地址哈希，第一次轮询调度至RS，后续将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡,如: Web缓存

  • 动态方法

    • LC：least connections 适用于长连接应用
    • WLC：Weighted LC，默认调度方法,较常用
    • SED：Shortest Expection Delay，初始连接高权重优先,只检查活动连接,而不考虑非活动连接
    • NQ：Never Queue，第一轮均匀分配，后续SED
    • LBLC：Locality-Based LC，动态的DH算法，使用场景：根据负载状态实现正向代理,实现Web Cache等
    • LBLCR：LBLC with Replication，带复制功能的LBLC，解决LBLC负载不均衡问题，从负载重的复制到负载轻的RS,,实现Web Cache等

• haproxy

  • 静态算法

    • static-rr：static-rr：基于权重的轮询调度，不支持权重的运行时调整及后端服务器慢启动，其后端主机数量没有限制
    • first：根据服务器在列表中的位置，自上而下进行调度，但是其只会当第一台服务器的连接数达到上限，新请求才会分配给下一台服务，因此会忽略服务器的权重设置

  • 动态算法

    • roundrobin：基于权重的轮询动态调度算法，支持权重的运行时调整，不完全等于lvs中的rr轮训模式，HAProxy中的roundrobin支持慢启动(新加的服务器会逐渐增加转发数)，其每个后端backend中最多支持4095个realserver，roundrobin为默认调度算法，且支持对real server权重动态调整
    • leastconn加权的最少连接的动态，支持权重的运行时调整和慢启动，即当前后端服务器连接最少的优先调度(新客戶端连接)，比较适合?连接的场景使用，比如MySQL等场景
    • source 源地址hash，基于用戶源地址hash并将请求转发到后端服务器，默认为静态即取模方式，但是可以通过hash-type支持的选项更改，后续同一个源地址请求将被转发至同一个后端web服务器，比较适用于session保持/缓存业务等场景

• nginx

  • hash KEY consistent；基于指定key做hash计算，使?用consistent参数，将使?用ketama?一致性hash算法，适?用于后端是Cache服务器?（如varnish）时使?用，consistent定义使?用?一致性hash运算，?一致性hash基于取模运算。 （hash $request_uri consistent）
  • ip_hash；#源地址hash调度?方法，基于的客户端的remote_addr(源地址)做hash计算，以实现会话保持
  • least_conn;#最少连接调度算法，优先将客户端请求调度到当前连接最少的后端服务器

• Cookie是服务端返回给客户端字符串，保存于客户端浏览器，是server端在一段时间内保存客户端的信息， 这样客户端使用在有效期内的cookie去访问某网站时，就无需再次登录，以验证客户端身份信息。

• Session：服务器保存，用于在多个服务器是被用户

• 共享：redis

• dns解析

  • 本机缓存-->递归查询-->迭代查询

• 与目标服务器建立tcp连接

• 客户端发送http协议请求

• 某些服务会做永久重定向响应

• 客户端跟踪重定向地址

• 服务端处理请求，并返回一个HTML响应

• 释放tcp连接

• 客户端收到数据，浏览器进行数据解析和渲染并展示

1. 查找浏览器缓存：因为浏览器一般会缓存DNS记录一段时间，不同浏览器的时间可能不一样，一般2-30分钟不等，浏览器去查找这些缓存，如果有缓存，直接返回IP，否则下一步。

2. 查找系统缓存：浏览器缓存中找不到IP之后，浏览器会进行系统调用（windows中是gethostbyname），查找本机的hosts文件，如果找到，直接返回IP，否则下一步。

3. 查找路由器缓存：如果1,2步都查询无果，则需要借助网络，路由器一般都有自己的DNS缓存，将前面的请求发给路由器，查找ISP 服务商缓存 DNS的服务器，如果查找到IP则直接返回，没有的话继续查找。

4. 递归查询：如果以上步骤还找不到，则ISP的DNS服务器就会进行递归查询，所谓递归查询就是如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，而不是让该主机自己进行下一步查询。（本地域名服务器地址是通过DHPC协议获取地址，DHPC是负责分配IP地址的）

   • 迭代查询：本地域名服务器采用迭代查询，它先向一个根域名服务器查询。本地域名服务器向根域名服务器的查询一般都是采用迭代查询。所谓迭代查询就是当根域名服务器收到本地域名服务器发出的查询请求报文后，要么告诉本地域名服务器下一步应该查询哪一个域名服务器，然后本地域名服务器自己进行后续的查询。（而不是替代本地域名服务器进行后续查询）。

• 我们一般是用logstash取收集java app或网络设备的日志，然后将日志写到kafka，然后又logstash从kafka取出数据，最终logstash根据日志类型做区分后写到es的不同索引中，而且再es前面加了loadbanlace，loadbanlace再去转发到不同的es。这样的话我们再去kibana就可以根据不同的索引查看不同业务的不同日志。

• 通过shell或python脚本获取监控项的值
• 配置zabbix agent调用脚本获取监控项的数据，并重启zabbix agent
• 在zabbix server使用zabbix get 测试监控项能否获取数据
  • zabbix_get -s 172.31.0.104 -p 10050 -k "reids_monitor["reids_monitor","6379","bytes"]"
• 在zabbix web创建模板，并在模板中添加监控项，图形，触发器等
• 将模板关联至主机，稍等几分钟，然后验证监控项数据

1. 物理层（Physical Layer） 物理层规定了激活、维持、关闭通信端点之间的机械特性、电气特性、功能特性以及过程特性。该层为上层协议提供了一个传输数据的物理媒体。
   在这一层，数据的单位称为比特（bit）。
   属于物理层定义的典型规范代表包括：EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45等。

2. 数据链路层（Data Link Layer） 数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。
   在这一层，数据的单位称为帧（frame）。
   数据链路层协议的代表包括：SDLC、HDLC、PPP、STP、帧中继等。交换机

3. 网络层（Network Layer） 网络层负责对子网间的数据包进行路由选择。此外，网络层还可以实现拥塞控制、网际互连等功能。
   在这一层，数据的单位称为数据包（packet）。
   网络层协议的代表包括：IP、IPX、RIP、OSPF等。路由器

4. 传输层（Transport Layer） 传输层是第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。
   在这一层，数据的单位称为数据段（segment）。
   传输层协议的代表包括：TCP、UDP、SPX等。

5. 会话层（Session Layer） 会话层管理主机之间的会话进程，即负责建立、管理、终止进程之间的会话。会话层还利用在数据中插入校验点来实现数据的同步。
   会话层协议的代表包括：NetBIOS、ZIP（AppleTalk区域信息协议）等。

6. 表示层（Presentation Layer） 表示层对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机的应用程序理解。表示层的数据转换包括数据的加密、压缩、格式转换等。
   表示层协议的代表包括：ASCII、ASN.1、JPEG、MPEG等。

7. 应用层（Application Layer） 应用层为操作系统或网络应用程序提供访问网络服务的接口。
   应用层协议的代表包括：Telnet、FTP、HTTP、SNMP等

1. 加载BIOS的硬件信息，获取第一个启动设备

2. 读取第一个启动设备MBR的引导加载程序(grub)的启动信息

3. 加载核心操作系统的核心信息，核心开始解压缩，并尝试驱动所有的硬件设备

4. 核心执行init程序，并获取默认的运行信息

5. init程序执行/etc/rc.d/rc.sysinit文件，重新挂载根文件系统

6. 启动核心的外挂模块

7. init执行运行的各个批处理文件(scripts)

8. init执行/etc/rc.d/rc.local

9. 执行/bin/login程序，等待用户登录

10. 登录之后开始以Shell控制主机

• 线程是程序执行的最小单位，而进程是操作系统分配资源的最小单位；

• 一个进程由一个或多个线程组成，线程是一个进程中代码的不同执行路线；

• 进程之间相互独立，但同一进程下的各个线程之间共享程序的内存空间(包括代码段、数据集、堆等)及一些进程级的资源(如打开文件和信号)，某进程内的线程在其它进程不可见；

• 调度和切换：线程上下文切换比进程上下文切换要快得多。

/dev/mapper/ldl--vg-root  /               ext4    errors=remount-ro 0       1


将被加载的文件系统名或文件系统id
文件系统的挂载点
文件系统的类型
设置参数
共备份程序确定上次备份据现在的天数
在系统引导式检测文件系统的顺序

head -n3

sed  -n '1,2p' /etc/passwd

awk 'NR>=1&&NR<=3{print $0}' /etc/passwd

• 在RHEL7里有几种防火墙共存：firewalld、iptables、ebtables，默认是使用firewalld来管理netfilter子系统，不过底层调用的命令仍然是iptables等。

• firewalld跟iptables比起来至少有两大好处：

  1. firewalld可以动态修改单条规则，而不需要像iptables那样，在修改了规则后必须得全部刷新才可以生效；

  2. firewalld在使用上要比iptables人性化很多，即使不明白“五张表五条链”而且对TCP/IP协议也不理解也可以实现大部分功能。

• firewalld跟iptables比起来，不好的地方是每个服务都需要去设置才能放行，因为默认是拒绝。而iptables里默认是每个服务是允许，需要拒绝的才去限制。

• firewalld自身并不具备防火墙的功能，而是和iptables一样需要通过内核的netfilter来实现，也就是说firewalld和 iptables一样，他们的作用都是用于维护规则，而真正使用规则干活的是内核的netfilter，只不过firewalld和iptables的结构以及使用方法不一样罢了。

1. TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2. TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保   证可靠交付

3. TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
    - UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

4. 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5. TCP首部开销20字节;UDP的首部开销小，只有8个字节

6. TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

- Udp
    - 沟通简单，不需要大量的数据结构，处理逻辑和包头字段
    - 轻信他人。它不会建立连接，但是会监听这个地方，谁都可以传给它数据，它也可以传给任何人数据，甚至可以同时传给多个人数据。
    - 愣头青，做事不懂变通。不会根据网络的情况进行拥塞控制，无论是否丢包，它该怎么发还是怎么发

• 2xx （3种）

  • 200 OK：表示从客户端发送给服务器的请求被正常处理并返回；

  • 204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；

  • 206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。

3xx （5种）
- 301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；

- 302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
    - 301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL）

- 303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；
    - 302与303的区别：后者明确表示客户端应当采用GET方式获取资源

- 304 Not Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；

- 307 Temporary Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）；

4xx （4种）
- 400 Bad Request：表示请求报文中存在语法错误；

- 401 Unauthorized：未经许可，需要通过HTTP认证；

- 403 Forbidden：服务器拒绝该次访问（访问权限出现问题）

- 404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；

5xx （2种）
- 500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；

- 503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；

• 分析有哪些方面的因素会导致网站网站访问慢？

  1. 服务器出口带宽不够用

     • 本身服务器购买的出口带宽比较小。一旦并发量大的话，就会造成分给每个用户的出口带宽就小，访问速度自然就会慢。
     • 跨运营商网络导致带宽缩减。例如，公司网站放在电信的网络上，那么客户这边对接是长城宽带或联通，这也可能导致带宽的缩减。

  2. 服务器负载过大，导致响应不过来

     • 可以从两个方面入手分析：
     • 分析系统负载，使用 w 命令或者 uptime 命令查看系统负载。如果负载很高，则使用 top 命令查看 CPU ，MEM 等占用情况，要么是 CPU 繁忙，要么是内存不够。
     • 如果这二者都正常，再去使用 sar 命令分析网卡流量，分析是不是遭到了攻击。一旦分析出问题的原因，采取对应的措施解决，如决定要不要杀死一些进程，或者禁止一些访问等。

  3. 数据库瓶颈

     • 如果慢查询比较多。那么就要开发人员或 DBA 协助进行 SQL 语句的优化。
     • 如果数据库响应慢，考虑可以加一个数据库缓存，如 Redis 等。然后，也可以搭建 MySQL 主从，一台 MySQL 服务器负责写，其他几台从数据库负责读。

  4. 网站开发代码没有优化好

• 针对网站访问慢，怎么去排查？

  1. 首先要确定是用户端还是服务端的问题。当接到用户反馈访问慢，那边自己立即访问网站看看，如果自己这边访问快，基本断定是用户端问题，就需要耐心跟客户解释，协助客户解决问题。

     • 艿艿：不要上来就看服务端的问题。一定要从源头开始，逐步逐步往下。

  2. 如果访问也慢，那么可以利用浏览器的调试功能，看看加载那一项数据消耗时间过多，是图片加载慢，还是某些数据加载慢。

  3. 针对服务器负载情况。查看服务器硬件(网络、CPU、内存)的消耗情况。如果是购买的云主机，比如阿里云，可以登录阿里云平台提供各方面的监控，比如 CPU、内存、带宽的使用情况。

  4. 如果发现硬件资源消耗都不高，那么就需要通过查日志，比如看看 MySQL慢查询的日志，看看是不是某条 SQL 语句查询慢，导致网站访问慢。

• 怎么去解决？

  1. 如果是出口带宽问题，那么久申请加大出口带宽。

  2. 如果慢查询比较多，那么就要开发人员或 DBA 协助进行 SQL 语句的优化。

  3. 如果数据库响应慢，考虑可以加一个数据库缓存，如 Redis 等等。然后也可以搭建MySQL 主从，一台 MySQL 服务器负责写，其他几台从数据库负责读。

  4. 申请购买 CDN 服务，加载用户的访问。

  5. 如果访问还比较慢，那就需要从整体架构上进行优化咯。做到专角色专用，多台服务器提供同一个服务。