主库: 打开binlog日志，每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。 对于每一个即将发送给从库的sql事件，binlog输出线程会将其锁住。一旦该事件被线程读取完之后，该锁会被释放，即使在该事件完全发送到从库的时候，该锁也会被释放。
从库: 当复制开始时，从库就会创建从库I/O线程和从库的SQL线程进行复制处理。
从库I/O线程：当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。 从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。
从库的SQL线程：从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。
mysql存储引擎：
1.2 Innodb
支持事务，提供行级锁与外键约束，有缓冲池，用于缓冲数据和索引
适用场景：用于事务处理，具有ACID事物支持，应用于执行大量的insert和update操作的表
1.3 MyISAM
不支持事务，不支持外键约束，不支持行级锁，操作时需要锁定整张表，不过会保存表的行数，所以当执行select count(*) from tablename时执行特别快
适用场景：用于管理非事务表，提供高速检索及全文检索能力，适用于有大量的select操作的表，如 日志表。
1.4 MEMORY
使用存在于内存中的内容创建表，每一个memory只实际对应一个磁盘文件。因为是存在内存中的，所以memory访问速度非常快，而且该引擎使用hash索引，可以一次定位，不需要像B树一样从根节点查找到支节点，所以精确查询时访问速度特别快，但是非精确查找时，比如like，这种范围查找，hash就起不到作用了。另外一旦服务关闭，表中的数据就会丢失，因为没有存到磁盘中。
适用场景：主要用于内容变化不频繁的表，或者作为中间的查找表。对表的更新要谨慎因为数据没有被写入到磁盘中，服务关闭前要考虑好数据的存储
1.5 MERGE
MERGE存储引擎把一组MyISAM数据表当做一个逻辑单元来对待，让我们可以同时对他们进行查询。构成一个MERGE数据表结构的各成员MyISAM数据表必须具有完全一样的结构。每一个成员数据表的数据列必须按照同样的顺序定义同样的名字和类型，索引也必须按照同样的顺序和同样的方式定义。
优点： PXC最大的优势就是强一致性，无同步延迟，数据安全可靠，PXC中每一个节点都可以读写，PXC一个节点写完后就用箱子(DatePage)推送给Group里所有的成员，就是一个写结果，类似于Oracle中数据块复制
缺点： 写入量太大，需要等待所有节点写入数据之后，算本事件写入成功。（优化，主节点写入过大，apply_cb会跟不上，可以将wsrep_slave_threads配置成和CPU的个数相等或者1.5倍。）
mongodb副本集原理：
3.1 在MongoDB副本集中，主节点负责处理客户端的读写请求，备份节点则负责映射主节点的数据。
3.2 备份节点的工作原理过程可以大致描述为，备份节点定期轮询主节点上的数据操作，然后对自己的数据副本进行这些操作，从而保证跟主节点的数据同步。
3.3 至于主节点上的所有数据库状态改变的操作，都会存放在一张特定的系统表中。备份节点则是根据这些数据进行自己的数据更新。
mongodb分片原理：
4.1 实现分片集群时，MongoDB 引入 Config Server 来存储集群的元数据，引入 mongos 作为应用访问的入口，mongos 从 Config Server 读取路由信息，并将请求路由到后端对应的 Shard 上。
4.2 分片就是把mongo单个表的数据，分到多个chunk上，从而横向提升mongo的读写能力。
redis-cluster集群原理：
5.1 Redis3.0加入了Redis的集群模式，实现了数据的分布式存储，对数据进行分片，将不同的数据存储在不同的master节点上面，从而解决了海量数据的存储问题。
5.2 Redis集群采用去中心化的思想，没有中心节点的说法，对于客户端来说，整个集群可以看成一个整体，可以连接任意一个节点进行操作，就像操作单一Redis实例一样，不需要任何代理中间件，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node。
5.3 Redis也内置了高可用机制，支持N个master节点，每个master节点都可以挂载多个slave节点，当master节点挂掉时，集群会提升它的某个slave节点作为新的master节点。
5.4 Redis集群的数据分布算法：哈希槽算法
5.4.1 Redis集群采用的算法是哈希槽分区算法。Redis集群中有16384个哈希槽（槽的范围是 0 -16383，哈希槽），将不同的哈希槽分布在不同的Redis节点上面进行管理，也就是说每个Redis节点只负责一部分的哈希槽。在对数据进行操作的时候，集群会对使用CRC16算法对key进行计算并对16384取模（slot = CRC16(key)%16383），得到的结果就是 Key-Value 所放入的槽，通过这个值，去找到对应的槽所对应的Redis节点，然后直接到这个对应的节点上进行存取操作。
5.4.2 哈希槽数据分区算法特点：
5.4.2.1 解耦数据和节点之间的关系，简化了扩容和收缩难度。
5.4.2.2 节点自身维护槽的映射关系，不需要客户端代理服务维护槽分区元数据。
5.4.2.3 支持节点、槽、键之间的映射查询，用于数据路由，在线伸缩等场景。
linux系统启动顺序
6.1 通电
6.2 bios初始化
6.3 grub2磁盘引导阶段（mbr）
6.4 指定boot分区所在分区
6.5 grub2文件引导阶段
6.6 启动内核，只读挂载 / 设备
6.7 启动init程序进入初始化阶段（rhel6）
6.8 启动systemd初始化进程
6.9 取 /etc/systemd/ 中的文件（之后都是并行的）
6.10 执行/etc/rc.d/rc.local
6.11 启动程序
6.12 启动登陆环境
docker网络模式：
7.1 bridge：这是 Docker 默认使用的网络模式，可以将容器与主机上的其他容器和网络隔离开。适用于简单的单机部署场景。
7.2 host：这种模式将容器直接连接到主机的网络上，可以访问主机上的网络资源。适用于需要访问主机网络资源的场景。
7.3 none：这种模式不为容器配置网络接口，适用于需要手动配置网络的场景。
7.4 overlay：这种模式可以在多个 Docker 主机之间创建一个分布式网络，适用于分布式系统和微服务架构。
7.5 macvlan：这种模式可以给容器分配独立的 MAC 地址，使容器像物理主机一样参与网络中。适用于需要容器和物理主机共享网络的场景。
copy 和add 区别 支持和不支持远程
cmd 和ENTRYPOINT 区别
CMD #指定这个容器启动时候需要运行的命令，只有最后一个生效，可以被替代
#比如ls -a docker run -l ,会用-l替换ls -a
ENTRYPOINT #指定这个容器启动时候需要运行的命令，可以追加命令
#比如ls -a docker run -l ,会在ls -a后面追加成 ls -a -l
lvs三种模式：
8.1 Virtual Server via NAT(VS-NAT):用地址翻译实现虚拟服务器｡地址转换器有能被外界访问到的合法IP地址,它修改来自专有网络的流出包的地址｡外界看起来包是来自地址转换器本身,当外界包送到转换器时,它能判断出应该将包送到内部网的哪个节点｡优点是节省IP 地址,能对内部进行伪装;缺点是效率低,因为返回给请求方的数据包经过调度器｡
8.2 LVS-DR 模式，Director Server 作为群集的访问入口，不作为网关使用，节点 Director Server 与 Real Server 需要在同一个网络中，返回给客户端的数据不需要经过 Director Server。为了响应对整个群集的访问，Director Server 与 Real Server 都需要配置 VIP 地址。(请求不走原路返回，减轻负载压力。)
8.3 TUN 是IP Tunneling ，IP隧道的简称，它将调度器收到的IP数据包封装在一个新的IP数据包中，转交给应用服务器，然后实际服务器的返回数据会直接返回给用户。
k8s组件：
9.1 Master节点主要包括API Server、Scheduler、Controller manager、etcd几大组件。
9.1.1 API Server（提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接和etcd进行交互）
9.2 Scheduler（负责对集群内部的资源进行调度，相当于“调度室”。）
9.2.1 Scheduler负责节点资源管理，接收来自kube-apiserver创建Pods的任务，收到任务后它会检索出所有符合该Pod要求的Node节点（通过预选策略和优选策略），开始执行Pod调度逻辑。调度成功后将Pod绑定到目标节点上。
9.3 Controller manager
9.3.1 controller-manager 作为 k8s 集群的管理控制中心，负责集群内 Node、Namespace、Service、Token、Replication 等资源对象的管理，使集群内的资源对象维持在预期的工作状态。
每一个 controller 通过 api-server 提供的 restful 接口实时监控集群内每个资源对象的状态，当发生故障，导致资源对象的工作状态发生变化，就进行干预，尝试将资源对象从当前状态恢复为预期的工作状态，常见的 controller 有 Namespace Controller、Node Controller、Service Controller、ServiceAccount Controller、Token Controller、ResourceQuote Controller、Replication Controller等。
9.4 Etcd
9.4.1 etcd在kubernetes集群是用来存放数据并通知变动的。
Kubernetes中没有用到数据库，它把关键数据都存放在etcd中，这使kubernetes的整体结构变得非常简单。在kubernetes中，数据是随时发生变化的，比如说用户提交了新任务、增加了新的Node、Node宕机了、容器死掉了等等，都会触发状态数据的变更。状态数据变更之后呢，Master上的kube-scheduler和kube-controller-manager，就会重新安排工作，它们的工作安排结果也是数据。这些变化，都需要及时地通知给每一个组件。etcd有一个特别好用的特性，可以调用它的api监听其中的数据，一旦数据发生变化了，就会收到通知。有了这个特性之后，kubernetes中的每个组件只需要监听etcd中数据，就可以知道自己应该做什么。kube-scheduler和kube-controller-manager呢，也只需要把最新的工作安排写入到etcd中就可以了，不用自己费心去逐个通知了。
9.5 Node节点主要包括kubelet、kube-proxy模块和pod对象
9.5.1 Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。
9.5.2 Kubelet运行在每个计算节点上
9.5.3 kubelet 组件通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器。
9.5.4 同时监视分配给该Node节点的 pods，周期性获取容器状态，再通过api-server通知各个组件。
9.5.5 kube-proxy首先k8s 里所有资源都存在 etcd 中，各个组件通过 apiserver 的接口进行访问etcd来获取资源信息kube-proxy 会作为 daemon（守护进程） 跑在每个节点上通过watch的方式监控着etcd中关于Pod的最新状态信息,它一旦检查到一个Pod资源被删除了或新建或ip变化了等一系列变动，它就立即将这些变动，反应在iptables 或 ipvs规则中，以便之后 再有请求发到service时，service可以通过ipvs最新的规则将请求的分发到pod上。
总结：kube-proxy和service的关系：
Kube-proxy负责制定数据包的转发策略，并以守护进程的模式对各个节点的pod信息实时监控并更新转发规则，service收到请求后会根据kube-proxy制定好的策略来进行请求的转发，从而实现负载均衡。
1. etcd保存了整个集群的状态。
2. apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。
3. controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。
4. scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。
5. kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理。
6. kube-proxy负责为Service提供cluster内部的服务发现和负载均衡。
网络区别：
flannel vxlan和calico ipip模式都是隧道方案，但是calico的封装协议IPIP的header更小，所以性能比flannel vxlan要好一点点。
常见的路由方案包括了flannel的host-gw模式，以及calico的bgp模式。但是需要宿主机连接在同一个交换机，缺点，路由表太大。
10. RAID
RAID，可以把硬盘整合成一个大磁盘，还可以在大磁盘上再分区，放数据还有一个大功能，多块盘放在一起可以有冗余（备份）RAID整合方式有很多，常用的：0 1 5 10
RAID 0，可以是一块盘和N个盘组合
其优点读写快，是RAID中最好的
缺点：没有冗余，一块坏了数据就全没有了
RAID 1，只能2块盘，盘的大小可以不一样，以小的为准
10G+10G只有10G，另一个做备份。它有100%的冗余，缺点：浪费资源，成本高
RAID 5 ，3块盘，容量计算10*（n-1）,损失一块盘
特点，读写性能一般，读还好一点，写不好
冗余从好到坏：RAID1 RAID10 RAID 5 RAID0
性能从好到坏：RAID0 RAID10 RAID5 RAID1
成本从低到高：RAID0 RAID5 RAID1 RAID10
RAID10 是先做镜象,然后再做条带
RAID01 则是先做条带,然后再做镜象
CDN
即内容分发网络，其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络边缘，使用户可就近取得所需的内容，提高用户访问网站的速度。
DNS请求原理
用户要访问http://www.baidu.com，会先找本机的host文件，再找本地设置的DNS服务器，如果也没有的话，就去网络中找根服务器，根服务器反馈结果，说只能提供一级域名服务器.cn，就去找一级域名服务器，一级域名服务器说只能提供二级域名服务器.com.cn,就去找二级域名服务器，二级域服务器只能提供三级域名服务器.http://baidu.com.cn，就去找三级域名服务器，三级域名服务器正好有这个网站http://www.baidu.com，然后发给请求的服务器，保存一份之后，再发给客户端。
CICD
gitlab/svn+jenkins\gocd+harbor+helm(k8s)
gitlab/svn代码仓库，jenkins这边配置好相关的流程线（推荐jenkinsfile）jenkins可以指定相应的node节点去操作。
jenkins流水线大致情况：
指定node
代码拉取
maven打包项目
dockerfile制作镜像
版本控制
上传harbor仓库
helm配置项目参数
项目发布
测试接口是否正常
消息推送成功与否(钉钉，企业微信等)
指定项目版本回退
消息推送成功与否(钉钉，企业微信等)
14.nginx正反向代理
正向代理:
正向代理，意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从 原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原 始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。 如dns，vpn等
反向代理 ：
反向代理（Reverse Proxy）方式是指以代理服务器来接受 internet 上的连接请求，然 后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 internet 上请求连 接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
15.存储
分部署存储：
1.对象存储（oss）读写快，文件共享，是文件存储和块存储的整合。
2.文件存储（FTP、NFS）文件共享 使用场景不是海量数据并要共享
3.块存储 （典型设备：磁盘阵列，硬盘）读写快 使用场景mysql数据存储
NAS存储多适用于文件服务器，用户通过TCP/IP协议访问数据，采用业界标准文件共享协议如：NFS、HTTP、CIFS实现共享。
SAN则适用于大型应用或数据库系统，通过专用光纤通道交换机访问数据，采用SCSI、FC-AL接口。
16.OSI七层协议模型
17.tcp三次握手，四次断开
18.iptables三表五链
三表
Filter：过滤、防火墙、过滤数据包
Nat：用于网络地址转换（IP、端口）
Mangle:解析报文，做出修改，等装报文
五链
Prerouting链：数据包进入路由器之前
Input链：目的地址本机
Forword链：实现转发
Output链：原地址为本机，向外发送
Postrouting链：发送到网卡之前