你常用的linux命令是多少

##

ps的用法

       To get info about threads:
          ps -eLf
          ps axms

       To get security info:
          ps -eo euser,ruser,suser,fuser,f,comm,label
          ps axZ
          ps -eM

       To see every process running as root (real & effective ID) in user format:
          ps -U root -u root u

       To see every process with a user-defined format:
          ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm
          ps axo stat,euid,ruid,tty,tpgid,sess,pgrp,ppid,pid,pcpu,comm
          ps -Ao pid,tt,user,fname,tmout,f,wchan

       Print only the process IDs of syslogd:
          ps -C syslogd -o pid=

       Print only the name of PID 42:
          ps -q 42 -o comm=

一、Linux基础篇
1）常用的Linux基础命令：
文件类
cd、pwd、ls、touch、mkdir、vim、cat、more、less、tail、head、cp、mv、chmod、chown
系统类
top、free、ps、uname、kill、ifconfig
网络类
netstat、ss、telnet、ping、tcpdump、ssh、scp
压缩
unzip、zip、tar
磁盘类
du、df、lsblk、fdisk、mount、mkfs、vgcreate、lvcreate
2) 磁盘挂载的详细步骤
检查当前系统磁盘挂载情况，使用命令lsblk或者fdisk ;
分区fdisk /dev/sdb;
创建挂载点，创建空闲的目录；
格式化磁盘，mkfs.xfs 格式自己选择根据要求（ext2\ext3\ext4\xfs）
挂载磁盘，临时挂载mount /dev/sdb1 /opt/disk ；永久挂载写入文件/etc/fstab
如果需要做lv的话

常见的几种raid

3) 系统卡顿如何排查
使用的命令
free查看内存使用情况
free 命令用于查看系统内存的使用情况。它提供了以下字段来描述系统的内存状态：
total（总内存）：表示系统总共的物理内存大小。
used（已使用内存）：表示当前已被系统和应用程序使用的内存大小。
free（空闲内存）：表示当前未被使用的内存大小，即可供系统和应用程序使用的内存。
shared（共享内存）：表示被多个进程共享的内存大小，例如共享库或映射文件。
buff/cache（缓存和缓冲区内存）：表示被系统用作文件缓存的内存大小，包括文件系统的缓存和磁盘 I/O 缓冲区等。
available（可用内存）：表示系统当前可供新进程使用的内存大小，包括空闲内存和缓存内存。
需要注意的是，在解读 free 命令的输出时，关注的主要是可用内存字段（available），它可以帮助确定系统当前是否有足够的内存可供使用。其他字段的值可能会随着系统和应用程序的运行而变化，因此单独关注它们可能并不能完全反映系统的内存情况。
top查看cpu负载情况
在 top 命令的默认视图中，前五行表示系统的总体性能指标和资源使用情况。以下是这些字段的解释：

1. 第一行：显示了系统的运行时间以及平均负载。

• top表示从启动到现在经过的时间。
• up表示系统已运行的时间。
• load average表示系统负荷的平均值，分别对应最近 1 分钟、5 分钟和 15 分钟的负载值。一般来说，负载值小于 CPU 核心数的两倍比较理想。

2. 第二行：显示了任务队列的情况。

• Tasks表示当前正在运行、等待或睡眠的进程数量。
• total表示总进程数。
• running表示正在运行的任务数量。
• sleeping表示正在休眠的任务数量。
• stopped表示被停止的任务数量。
• zombie表示僵尸进程数量。

3. 第三行：显示了 CPU 的使用情况。

• %Cpu(s)表示 CPU 使用率的统计信息。
• us表示用户空间进程占用 CPU 时间的百分比。
• sy表示核心空间进程占用 CPU 时间的百分比。
• ni表示被调整过优先级的进程占用 CPU 时间的百分比。
• id表示空闲 CPU 时间的百分比。
• wa表示等待 I/O 完成的 CPU 时间的百分比。
• hi表示硬中断（Hardware Interrupts）占用 CPU 时间的百分比。
• si表示软中断（Software Interrupts）占用 CPU 时间的百分比。
• st表示被虚拟化环境偷取的 CPU 时间的百分比。

4. 第四行：显示了物理内存的使用情况。

• KiB Mem表示物理内存的统计信息。
• total表示总内存大小。
• used表示已使用的内存大小。
• free表示空闲的内存大小。
• shared表示共享内存大小。
• buff/cache表示缓存和缓冲区的内存大小。
• available表示可用的内存大小。

5. 第五行：显示了交换空间（Swap）的使用情况。

• KiB Swap表示交换空间的统计信息。
• total表示总交换空间大小。
• used表示已使用的交换空间大小。
• free表示空闲的交换空间大小。
• cached表示被缓存的交换空间大小。
  按照cpu排序，shift+p
  按照内存排序，shift+m

用ps查看对应的进程
使用命令 netstat -tupn 查看当前的网络连接和监听端口。检查是否有异常连接或者网络流量过大导致卡顿。
最后看日志，是否是磁盘或者硬件之类坏掉
4) find命令

• -name pattern 按名称查找文件或目录，pattern 是一个匹配模式，支持使用通配符 * 和 `
• -type type 按类型查找文件或目录，type 可以为 f 表示普通文件，d 表示目录，l 表示符号链接等。
• -mtime n 按文件修改时间查找文件或目录，n 为天数，表示查找最近 n 天内修改过的文件。
• -mmin n 按文件修改时间查找文件或目录，n 为分钟数，表示查找最近 n 分钟内修改过的文件。
• -ctime n 按文件状态改变时间查找文件或目录，n 为天数，表示查找最近 n 天内状态改变过的文件。
• -cmin n 按文件状态改变时间查找文件或目录，n 为分钟数，表示查找最近 n 分钟内状态改变过的文件。
• -size n 按文件大小查找文件或目录，n 为文件大小，可以使用 k 表示 KB，M 表示 MB 等单位。
• -user username 按所有者查找文件或目录，username 可以为用户名或用户 ID。
• -group groupname 按所属组查找文件或目录，groupname 可以为组名或组 ID。
• -perm mode 按文件权限查找文件或目录，mode 是一个三位数的八进制数，表示文件权限（如 755）。
  查找出/test目录下，7天前的日志文件并将其删除掉，用find命令
  find /test -type f -mtime +7 -exec rm {} ;
  5) grep
• -i忽略大小写，进行不区分大小写的搜索。
• -v反转匹配，只打印不匹配模式的行。
• -r 或 -R递归地在目录及其子目录下搜索匹配的模式。
• -l仅打印包含匹配模式的文件名，而不打印匹配的行。
• -n显示匹配行的行号。
• -c仅显示匹配的行数统计。
• -w精确匹配整个单词，而不是部分匹配。
• -A num打印匹配行及其后面的 num 行。
• -B num打印匹配行及其前面的 num 行。
• -C num 或 --context=num打印匹配行及其前后各 num 行。
• -e pattern指定要搜索的模式，可以多次使用来搜索多个模式。
• -f file从文件中读取模式，每行一个模式。
  6) sed
  -i直接修改文件内容
  -n 只显示经过处理的行
  s/g替换
  /d删除
  a、i插入
  7) awk
  -F分隔符
  最后一列$NF
  第一行NR==1
  8) Linux开机系统的启动顺序
  加载BIOS–〉读取MBR–>Boot Loader–〉加载内核–〉用户层init以及inittab文件来设定系统运行的等级（一般3或者5，3是多用户命令行，5是界面）–>init进程执行rc.syninit–〉启动内核模块–〉执行不同级别运行的脚本程序–〉执行/etc/rc.d/rc.local（本地运行服务）–〉执行/bin/login，就可以登录了。
  9) 软硬链接的区别
  ln -s软链接
  ln 硬连接
  我们可以把软连接 当作是 windows系统里的快捷方式。
  硬链接 就好像是又复制了一份.
  ln 3.txt 4.txt 这是硬链接，相当于复制，不可以跨分区，但修改3,4会跟着变，若删除3,4不受任何影响。
  ln -s 3.txt 4.txt 这是软连接，相当于快捷方式。修改4,3也会跟着变，若删除3,4就坏掉了。不可以用了。
  Linux系统通过inode管理文件，inode存储着文件字节数、文件权限、链接数、数据block位置等信息。
  硬链接与源文件共用inode，除了文件名不同，其他与源文件一样。不能对文件夹创建硬链接，不能对不同的文件系统的文件创建硬链接。
  软链接类似于windows的快捷方式，有独立的inode。可以对文件夹或不同文件系统的文件创建软链接。
  硬链接和软链接修改文件内容都会同步到源文件，因为本质上它们都是指向源文件的数据block。
  10) linux下常见的压缩格式
  tar、zip
  tar -xvzf 解压 -C
  tar -cvzf 压缩
  zip 压缩
  unzip 解压 -d
  11) 如何修改权限
  chmod
  chown修改属组属主
  常见权限读写执行 rwx—–421
  755 用户所有者可读可写可执行 用户所属组可读可执行 其他用户可读可执行
  12) 查找出nginx日志里访问前十的ip地址
  awk ‘{print $1}’ access.log | sort | uniq -c | sort -nr | head -n 10
  13) 统计100以内所有奇数的和
  #!bin/bash
  sum=0
  for ((i=1; i<=100; i+=2))
  do
  sum=$((sum + i))
  done
  echo “100以内所有奇数的和为： $sum”
  14) TCP/ip七层模型
  TCP/IP（Transmission Control Protocol/Internet Protocol）是互联网通信的基础协议。它并没有严格遵循七层模型，而是参考了 OSI（Open Systems Interconnection）七层模型的概念。

下面是 TCP/IP 协议栈的常见分层模型：

1. 物理层：负责传输比特流，将数据转换为电信号，在物理媒介上进行传输，如以太网、无线电等。

2. 数据链路层：负责在物理连接中传输数据包。它将比特流组装成帧，并通过物理地址（MAC 地址）进行寻址和传输。以太网、Wi-Fi 等工作在此层。

3. 网络层：负责网络互联，通过 IP 协议进行寻址和路由选择。它将数据包从源主机发送到目标主机，如 IPv4 或 IPv6 协议。

4. 传输层：提供端到端的可靠数据传输服务。常用的传输层协议是 TCP（Transmission Control Protocol）和 UDP（User Datagram Protocol）。TCP 提供可靠的、面向连接的数据传输，UDP 提供不可靠的、无连接的数据传输。

5. 会话层：负责建立、管理和终止应用程序之间的通信会话。它处理会话的创建、同步和结束等问题。

6. 表示层：负责数据的格式化、加密和压缩等。它将数据从应用程序格式转换为网络格式，或者从网络格式转换为应用程序格式。

7. 应用层：提供常用的应用程序和服务，如 HTTP、FTP、SMTP 等。这些应用程序使用 TCP 或 UDP 协议与其他主机通信。
   15）域名解析的详细过程
   域名解析是将一个可读的域名（如 www.example.com）转换为 IP 地址的过程，这样服务器才能找到对应的网站并返回数据。

以下是域名解析的详细过程：

1. 浏览器缓存查询：浏览器首先会在自己的 DNS 缓存中查找目标域名是否已经解析过了。如果有，则直接返回缓存的 IP 地址。

2. 操作系统缓存查询：如果浏览器没有找到缓存的 IP 地址，那么它会向操作系统发出请求。操作系统也会在自己的 DNS 缓存中查找目标域名是否已经解析过了。如果有，则直接返回缓存的 IP 地址。

3. 路由器缓存查询：如果操作系统也没有找到缓存的 IP 地址，那么它会向路由器发出请求。路由器也会在自己的 DNS 缓存中查找目标域名是否已经解析过了。如果有，则直接返回缓存的 IP 地址。

4. ISP DNS 服务器查询：如果以上步骤都没有找到缓存的 IP 地址，那么操作系统会向本地 ISP（Internet Service Provider）的 DNS 服务器发出请求。ISP DNS 服务器会查询它的缓存，如果有则直接返回缓存的 IP 地址，没有则继续往下进行。

5. 顶级域名服务器查询：如果本地 ISP 的 DNS 服务器也没有缓存，那么它会向根域名服务器发送请求。根域名服务器只有一部分，分散在全球各地，它存储了所有顶级域名（如 .com、org、net 等）的 DNS 服务器地址。根域名服务器返回对应顶级域名的 DNS 服务器地址。

6. 二级域名服务器查询：ISP DNS 服务器向顶级域名服务器返回的 DNS 服务器发送请求，该 DNS 服务器存储了目标域名的 IP 地址或者下一级 DNS 服务器地址。如果有 IP 地址，则直接返回给 ISP DNS 服务器；如果是下一级 DNS 服务器地址，则 ISP DNS 服务器继续向下进行查询。

7. 递归查询：如果最后一级 DNS 服务器也无法解析目标域名，那么它会返回一个错误响应。此时，ISP DNS 服务器会向其他 DNS 服务器发出请求，进行递归查询，直到找到目标域名的 IP 地址为止。

8. 返回结果：ISP DNS 服务器将查询到的 IP 地址返回给操作系统，操作系统再将其返回给浏览器。浏览器在得到 IP 地址后，就可以向目标网站发送请求，获取数据了。

总结来说，域名解析的过程就是一个从低到高、由缓存到递归的查询过程，直到找到目标域名的 IP 地址为止。
15) 如何优化Linux操作系统
在 Linux 操作系统中，可以通过一些配置文件进行系统优化。以下是一些常见的配置文件和它们所对应的优化内容：

1. /etc/sysctl.conf：该文件用于配置内核参数。通过修改该文件，可以调整系统的网络、存储等性能参数，以及提升系统的安全性和稳定性。

2. /etc/security/limits.conf：该文件用于设置用户资源限制。通过适当调整该文件中的参数，可以限制用户对系统资源（如 CPU、内存、文件句柄等）的使用，从而提高系统的稳定性和安全性。

3. /etc/fstab：该文件定义了系统的文件系统表。通过对该文件进行优化，可以调整文件系统的挂载选项，如启用磁盘读写缓存、设置文件系统的访问权限、调整文件系统的块大小等。

4. /etc/nsswitch.conf：该文件指定了系统用于名称解析的规则。通过修改该文件，可以优化系统的名称解析性能，如使用本地缓存、调整名称解析的顺序等。

5. /etc/rsyslog.conf：该文件用于配置系统日志服务。通过适当调整该文件中的参数，可以控制系统日志的级别、存储方式以及日志的转发等，以减轻磁盘负载并提高日志管理效率。

16) TCP三次握手四次挥手过程
三次握手（Three-Way Handshake）是建立 TCP 连接的过程，用于确保客户端和服务器之间的通信能够正常进行。以下是三次握手的过程：

1. 第一步（SYN）：客户端向服务器发送一个 SYN（同步）包，其中设置了一个初始序列号（ISN）作为起始点。此时客户端进入 SYN_SENT 状态。

2. 第二步（SYN + ACK）：服务器收到客户端的 SYN 包后，会回复一个 SYN+ACK 包作为响应。该包中确认了客户端发来的 SYN，同时也设置了服务器的初始序列号。此时服务器进入 SYN_RCVD 状态。

3. 第三步（ACK）：客户端收到服务器的 SYN+ACK 包后，会发送一个确认包 ACK 给服务器，确认收到了服务器的响应。同时，客户端的序列号也被设置为服务器的初始序列号加 1。此时客户端进入 ESTABLISHED 状态，服务器也进入 ESTABLISHED 状态，完成三次握手。

四次挥手（Four-Way Handshake）是关闭 TCP 连接的过程，用于确保客户端和服务器之间的连接能够正确终止。以下是四次挥手的过程：

1. 第一步（FIN）：当客户端决定关闭连接时，发送一个 FIN（结束）包给服务器，并进入 FIN_WAIT_1 状态。

2. 第二步（ACK）：服务器收到客户端的 FIN 包后，向客户端发送一个确认包 ACK，确认收到了客户端的 FIN。同时，服务器进入 CLOSE_WAIT 状态。

3. 第三步（FIN）：当服务器也决定关闭连接时，发送一个 FIN 包给客户端，并进入 LAST_ACK 状态。

4. 第四步（ACK）：客户端收到服务器的 FIN 包后，发送一个确认包 ACK 给服务器，确认收到了服务器的 FIN。客户端进入 TIME_WAIT 状态，等待一段时间后关闭连接，服务器收到 ACK 后也关闭连接。

在四次挥手过程中，客户端等待一段时间再关闭连接的原因是为了确保服务器收到了最后的 ACK 包，并且防止已经关闭的连接被误认为是新的连接。

需要注意的是，三次握手和四次挥手是 TCP 协议在建立和关闭连接时的标准流程，用于保证数据的可靠传输和连接的正常建立与关闭。

17) 定时任务
crontab
分 时 日 月 周
18) 如何在后台运行一个命令
在运行命令的末尾加上一个符号&
19) 如何在Linux重启服务
systemctl restart 服务
20) 如何在Linux里查看磁盘空间使用情况
df -h

21) 服务器上面的服务突然无法访问怎么排查？

1. 确认服务是否正在运行：检查服务的进程是否在运行中。您可以使用命令 `ps aux | grep 〈服务名称> 来查找与该服务关联的进程。如果进程不存在，可能是服务崩溃或停止了。

2. 检查服务日志：查看服务的日志文件，通常位于 var/log 目录下。查找任何错误或异常信息，这些信息可能会指示问题所在。

3. 检查网络连接：确认服务器是否能够正常连接到网络，并且端口是否打开。您可以使用 ping 命令来测试服务器的网络连通性，例如 ping 〈服务器IP地址>同时，您还可以使用telnet命令来检查指定端口是否开放，例如telnet 〈服务器IP地址〉 〈端口号>

4. 检查防火墙设置：确认防火墙是否允许对该服务的访问。如果您的服务器有启用防火墙，确保相关端口已经被允许通过防火墙。您可以查看防火墙规则，例如使用 iptables -L 命令。

5. 检查配置文件：检查服务的配置文件是否存在任何错误或不一致之处。特别是检查服务的监听地址、端口和其他关键配置参数。

6. 重启服务：尝试重启服务，有时候简单地重启可以解决一些临时问题。使用适当的命令重启服务，例如 `systemctl restart 〈服务名称>

7. 检查资源占用情况：检查服务器的资源使用情况，包括 CPU、内存和磁盘空间。如果资源不足，可能会导致服务无法正常运行。

22) 什么是僵尸进程？如何处理僵尸进程？
在Linux中，僵尸进程（Zombie Process）是一种特殊的进程状态。当一个子进程终止时，但其父进程尚未调用wait(）或waitpid(）系统调用来获取子进程的退出状态时，子进程就会变成僵尸进程。僵尸进程占用系统资源，但不会执行任何操作。

处理僵尸进程的方法如下：

1. 杀死父进程：如果僵尸进程的父进程终止，操作系统会将僵尸进程的父进程ID更改为1号进程（init进程），并由init进程负责清理僵尸进程。

2. 重新编写父进程代码：在父进程中，通过调用wait(）或waitpid(）系统调用来获取子进程的退出状态，并及时处理。

3. 使用信号处理：父进程可以使用SIGCHLD信号的处理程序来接收并处理子进程的终止状态。在信号处理程序中，调用wait(）或waitpid(）来处理僵尸进程。

4. 父进程忽略SIGCHLD信号：父进程可以选择忽略SIGCHLD信号，让操作系统处理僵尸进程。这样，操作系统会自动将僵尸进程转交给init进程处理。

23) 进程和线程的区别？
进程和线程是操作系统中两个重要的概念，它们之间的主要区别如下：

1. 资源分配：进程是操作系统中分配资源的基本单位，每个进程拥有自己独立的地址空间、内存、文件描述符等系统资源。而线程是进程中执行任务的实体，多个线程共享同一个进程的资源。

2. 执行开销：创建和销毁进程的开销比较大，因为需要为每个进程分配独立的资源。而线程的创建和销毁比较快，因为它们共享进程的资源，只需分配少量的栈空间即可。

3. 并发性：不同的进程之间是相互独立的，它们可以并发执行。而线程是进程内部的执行单位，线程之间共享进程的资源，可以实现更细粒度的并发性，提高程序的效率。

4. 通信方式：进程之间的通信需要使用操作系统提供的IPC（Inter-Process Communication）机制，如管道、消息队列、共享内存等。而线程之间可以通过共享内存、信号量、条件变量等方式进行通信。

5. 同步方式：进程之间的同步需要使用系统调用来实现，如fork()、wait()、kill(）等。而线程之间可以通过互斥锁、条件变量等方式进行同步，实现更高效的并发控制。

二、运维自动化-ansible

1. 常用的模块有哪些？
   cmmand在远程主机上执行命令。
   shell模块：在远程主机上执行shell脚本。
   copy模块：将文件从控制机复制到远程主机。
   fetch模块：从远程主机复制文件到控制机。
   file模块：管理远程主机上的文件和目录。
   yum模块：使用yum包管理器在远程主机上安装、升级和删除软件包。
   lineinfile：在文件中查找特定行，并对其进行修改、添加或删除。
   service：管理系统服务（如启动、停止、重启等）。
2. 要想使用root权限在ansible剧本里怎么办？
   ansible_become 和 ansible_become_pass：用于在远程主机上提升权限（例如使用sudo）以执行特权操作。ansible_become指定是否启用提权，ansible_become_pass指定提权密码。

• name: Execute privileged command
  command: some_command
  become: yes
  become_user: root
  become_method: sudo
  become_pass: “{{ sudo_password }}”

3. 使用ansible的基本命令格式
   ansible -i host all -m 模块 -a ‘参数’
4. 使用剧本的基本格式
   ansible-playbook -i host xxx.yaml
5. 讲述一个你写过的剧本？
   安装nginx
   以下是一个简单地部署Nginx的Ansible剧本（Playbook）示例：

`yaml

• name: Deploy Nginx
  hosts: web_servers
  become: true

  tasks:

  • name: Install Nginx
    yum:
    name: nginx
    state: present

  • name: Copy Nginx configuration file
    copy:
    src: nginx.conf
    dest: /etc/nginx/nginx.conf
    notify:

    • restart nginx

  handlers:

  • name: restart nginx
    service:
    name: nginx
    state: restarted
    `

解析：

• name指定Playbook的名称。
• hosts指定要部署到的目标主机组，这里使用｀web_servers｀表示目标主机组名。
• become: true使用sudo提升权限，以便在远程主机上安装和配置Nginx。
• tasks定义任务列表，每个任务都是一个模块操作。
• `apt｀模块：通过apt包管理器安装Nginx。
• copy｀模块：将本地的｀nginx.conf｀文件复制到远程主机的etc/nginx/nginx.conf｀路径下。
• notify当｀copy｀任务完成后，触发｀restart nginx｀处理程序。
• handlers定义处理程序列表，用于处理通知。
• `service｀模块：重启Nginx服务。

请确保在运行此Playbook之前，已经在Ansible的Inventory文件中正确定义了目标主机组，并设置了适当的连接参数（用户名、密码等）。

这个剧本将通过｀apt｀模块安装Nginx，并使用｀copy｀模块复制配置文件到远程主机。当配置文件复制完成后，notify｀将触发｀restart nginx｀处理程序，使用｀service｀模块来重启Nginx服务。

6. 角色是用来干什么的？
   在Ansible中，角色（Role）是一种组织和管理Playbook的机制，用于将相关的任务、变量和文件组织在一起，以便更好地复用和维护。一个角色通常包含以下常用的工作目录及作用：

7. `roles/

   • 该目录是所有角色的父目录，用于存放所有的角色。
   • 在该目录下，每个角色通常有一个单独的子目录，用于命名和组织该角色的相关文件。

8. `roles/

   • 这是一个特定角色的目录，其中｀是角色的名称。
   • 每个角色应该有一个单独的目录，以便管理和组织相关文件。
   • 可以根据实际需要创建多个角色目录。

9. `roles/tasks/

   • 该目录包含与角色相关的任务文件（`yml｀格式），定义要在主机上执行的操作。
   • 这些任务文件按顺序执行，以实现所需的配置和管理。

10. `roles/handlers/

    • 该目录包含与角色相关的处理程序文件（`yml｀格式），定义在任务执行期间触发的处理程序。
    • 处理程序通常用于重启服务或执行其他操作来应对配置的更改。

11. `roles/templates/

    • 该目录包含与角色相关的模板文件，用于生成配置文件。
    • 模板文件可以使用Jinja2模板语言，根据变量和条件生成动态配置文件。

12. `roles/files/

    • 该目录包含与角色相关的静态文件，例如脚本、配置文件等。
    • 这些文件在部署过程中会被复制到目标主机上。

13. `roles/vars/

    • 该目录包含与角色相关的变量文件（`yml｀格式），用于定义角色的默认变量。
    • 可以在变量文件中定义各种配置选项和值，以便在任务中引用。

14. `roles/defaults/

    • 该目录包含与角色相关的默认变量文件（`yml｀格式），用于定义角色的默认变量，可以被用户覆盖。
    • 默认变量通常在角色中使用，但可以在Playbook或Inventory中覆盖。

15. `roles/meta/

    • 该目录包含与角色相关的元数据文件（`yml｀格式），用于描述角色的依赖关系和其他元数据信息。
    • 元数据文件可以包含依赖角色的列表、作者信息、角色版本等。

16. 将本机/opt/test/a.txt文件传给其他主机
    ansible -i host all -m copy -a ‘src=/opt/test/a.txt dest=/opt/test’

三、中间件
nginx

1. nginx的作用？
   web服务器、正向代理、反向代理、负载均衡

2. 正向代理与反向代理的区别？
   正向代理（Forward Proxy）和反向代理（Reverse Proxy）是两种常见的代理服务器类型，它们的作用和特点有所不同。
   正向代理是指客户端通过代理服务器访问目标服务器。客户端向代理服务器发出请求，代理服务器再将请求转发给目标服务器，最终将响应返回给客户端。在这种情况下，客户端无法直接访问目标服务器，而是需要通过代理服务器进行访问。正向代理通常用于翻墙、加速访问等场景。
   反向代理是指客户端通过代理服务器间接访问多个目标服务器中的某一个。客户端向代理服务器发出请求，代理服务器将请求转发给目标服务器，目标服务器处理请求并返回响应，代理服务器再将响应返回给客户端。在这种情况下，客户端无法直接访问目标服务器，而是需要通过代理服务器进行访问。反向代理通常用于负载均衡、缓存、安全过滤等场景。
   主要区别：

3. 功能不同：正向代理是帮助客户端访问外部网络资源，而反向代理是帮助服务器处理客户端的请求。

4. 位置不同：正向代理位于客户端和目标服务器之间，反向代理位于客户端和多个目标服务器之间。

5. 配置方式不同：正向代理需要在客户端配置代理服务器地址，而反向代理需要在目标服务器上配置反向代理服务器地址。

6. 负载均衡如何配置的？
   通过upstream模块
   upstream backend{
   server ip ;
   }
   涉及的策略
   权重、轮询、ip_hash、最小连接数

location {
proxy_pass http://backend;
}
通过stream模块
stream {
upstream backend_server {
server backend1.example.com:80;
server backend2.example.com:80;
server backend3.example.com:80;
}

server {
    listen 80;
    proxy_pass backend_server;
}

}

max_fails：设置后端服务器的最大失败次数。当该服务器连续失败次数达到设定值时，将被认为是不可用的，暂时从服务池中剔除。

fail_timeout：设置后端服务器在被标记为不可用之后的失败超时时间。在此时间内，Nginx会暂时停止向该服务器发送请求，以允许服务器恢复。

backup：将该服务器标记为备份服务器。备份服务器只有在其他所有服务器都不可用时才会被使用。

4. 配置安全证书
   server {
   listen 443 ssl;
   server_name yourdomain.com;

   ssl_certificate /path/to/your/certificate.crt;
   ssl_certificate_key /path/to/your/private/key.key;

   其他配置项…

   }

5. nginx如何配置虚拟主机
   server {
   listen 80;
   server_name example1.com;

   location / {
   root /path/to/example1.com;
   index index.html;
   }
   }

server {
listen 80;
server_name example2.com;

location / {
    root /path/to/example2.com;
    index index.html;
}

}
不同的server_name

6. 如何优化nginx
   Nginx 作为一款高性能的 Web 服务器和反向代理服务器，可以通过一些优化来进一步提高其性能。以下是一些常见的 Nginx 性能优化方法：

7. 增加工作进程数：默认情况下，Nginx 只使用一个工作进程处理请求。如果你的服务器具有多个 CPU 和大量的内存，可以增加工作进程的数量以提高并发处理能力。

8. 启用文件缓存：Nginx 可以将静态文件缓存在内存中，以避免频繁的磁盘读写操作。可以使用 open_file_cache 指令来启用文件缓存。

9. 启用 Gzip 压缩：启用 Gzip 压缩可以大幅减少传输数据量，从而提高页面加载速度。可以使用 gzip 指令来启用 Gzip 压缩。

10. 避免使用正则表达式：在 Nginx 中，使用正则表达式会导致性能下降。如果可以使用其他方式，就尽量避免使用正则表达式。

11. 减少文件 I/O 操作：文件 I/O 操作是 Web 服务器性能瓶颈之一。可以通过将 Web 根目录移动到 RAM Disk 或 SSD 等快速存储设备上，避免磁盘 I/O 操作带来的性能损失。

12. 优化 TCP 参数：可以通过调整 Nginx 的 TCP 参数，如 tcp_nodelaytcp_nopush` 等来进一步提高性能。

13. 启用缓存：如果你的 Web 网站内容较为稳定，可以启用缓存功能以减少后端服务器的负载。Nginx 可以使用 proxy_cache 指令来启用反向代理缓存。

14. 使用 CDN：使用 CDN（内容分发网络）可以将静态资源缓存在 CDN 节点上，从而减轻后端服务器的负载并加速网站访问速度。

15. 生成证书的工具
    openssl

16. nginx默认使用的端口
    80

17. 常见的nginx报错
    nginx常见的HTTP状态码包括：

18. 200 OK：表示请求成功，服务器成功处理了请求。

19. 301 Moved Permanently：永久重定向，请求的资源已经被永久移动到新的位置。

20. 302 Found：临时重定向，请求的资源暂时被移动到新的位置。

21. 400 Bad Request：客户端发送的请求有语法错误，服务器无法理解。

22. 401 Unauthorized：请求要求用户身份验证。

23. 403 Forbidden：服务器拒绝请求，没有权限访问资源。

24. 404 Not Found：请求的资源不存在。

25. 500 Internal Server Error：服务器内部错误，无法完成请求。

26. 502 Bad Gateway：作为网关或代理服务器的服务器从上游服务器接收到无效的响应。

27. 503 Service Unavailable：服务器暂时不可用，通常是由于过载或维护导致。

当出现404错误时，表示请求的资源未找到。以下是一些排查404错误的常见步骤：

1. 检查请求的URL：确保请求的URL正确，包括路径、文件名和扩展名等。特别注意大小写是否匹配，URL是否包含特殊字符或空格。

2. 检查文件路径：确认请求的文件路径是否正确，特别是在配置文件中指定的根目录或者别名路径。

3. 检查文件权限：确保请求的文件或目录具有读权限，如果没有权限可能导致无法访问。

4. 检查文件是否存在：确认请求的文件或目录是否真实存在，可以通过命令行或文件管理器检查目标文件是否存在。

5. 检查nginx配置：查看nginx配置文件中的location或alias等指令，确保文件路径、正则表达式等配置正确。

6. 检查重写规则：如果使用了rewrite模块进行URL重写，确保重写规则正确，没有导致请求重定向到错误的位置。

7. 检查日志文件：查看nginx的错误日志文件，可以提供更详细的错误信息，有助于定位问题所在。

8. 检查代理设置：如果nginx作为反向代理，请求的目标服务器是否正常工作，并且响应正确。

当出现502 Bad Gateway错误时，表示nginx作为网关或代理服务器无法从上游服务器获取有效的响应。以下是一些排查502错误的常见步骤：

1. 检查上游服务器状态：确保上游服务器正常运行，并且能够提供请求的资源。可以通过ping命令或者访问上游服务器特定端口来确认连接是否正常。

2. 检查上游服务器配置：确认上游服务器的配置是否正确，包括IP地址、端口号、协议等。确保nginx能够正确连接到上游服务器。

3. 检查上游服务器负载：如果上游服务器过载或响应缓慢，可能导致nginx无法及时获取响应，进而引发502错误。可以检查上游服务器的负载情况，如CPU、内存使用率等。

4. 检查网络连接：确认网络连接是否正常，包括网络设备、防火墙、路由器等。可能存在网络故障或者阻塞导致无法正常访问上游服务器。

5. 检查nginx配置：查看nginx配置文件中的upstream配置，确保上游服务器的IP地址、端口号等配置正确。还可以检查proxy_pass指令的配置是否正确。

6. 检查缓存设置：如果在nginx中启用了缓存，确保缓存设置正确，不会导致502错误。可以尝试清除缓存并重启nginx。

7. 检查日志文件：查看nginx的错误日志文件，可以提供更详细的错误信息，有助于定位问题所在。

8. nginx常用的模块
   nginx具有许多可扩展的模块，以下是一些常用的nginx模块：

9. ngx_http_rewrite_module：提供URL重写功能，可以根据规则修改请求的URL。

10. ngx_http_proxy_module：作为反向代理服务器，将客户端请求转发给上游服务器，并将响应返回给客户端。

11. ngx_http_ssl_module：支持SSL/TLS协议，提供HTTPS安全连接。

12. ngx_http_gzip_module：对响应进行压缩，减少传输数据量，提高性能。

13. ngx_http_access_module：控制对资源的访问权限，可以基于IP地址、用户名等条件进行访问控制。

14. ngx_http_log_module：记录请求和响应的日志，用于分析和故障排除。

15. ngx_http_headers_module：修改HTTP请求和响应的头部信息，如添加、删除或修改头部字段。

16. ngx_http_limit_req_module：限制请求的速率，防止恶意请求或过载导致的性能问题。

17. ngx_http_upstream_module：定义上游服务器组，实现负载均衡和故障转移。

18. ngx_http_geoip_module：使用GeoIP数据库根据客户端IP地址获取地理位置信息。

19. 四层负载均衡和七层负载均衡的区别？
    四层负载均衡和七层负载均衡是两种不同的负载均衡技术，它们在处理网络流量时的重点和方式有所不同。

四层负载均衡（Layer 4 Load Balancing）：
四层负载均衡是在传输层（Transport Layer）对网络流量进行负载均衡。它基于传输层协议信息（如TCP、UDP端口号）来决定如何分配流量。四层负载均衡主要关注连接的源IP地址、目的IP地址、源端口和目的端口等信息来实现负载均衡。它可以将流量分发到多个服务器上，以提高系统的可扩展性和可用性。

七层负载均衡（Layer 7 Load Balancing）：
七层负载均衡是在应用层（Application Layer）对网络流量进行负载均衡。它能够解析应用层协议（如HTTP、HTTPS）中的更多细节，例如URL、HTTP头部等内容。七层负载均衡不仅可以根据传输层信息进行负载均衡，还可以根据应用层的特性和策略来进行智能的请求分发，如基于会话持久性、请求内容、用户身份等因素进行流量调度。

综上所述，四层负载均衡主要基于传输层协议信息进行负载均衡，而七层负载均衡则更加智能地基于应用层的特性进行负载均衡。选择使用哪种负载均衡方式取决于具体的应用需求和系统设计。

四、keepalived

1. 工作原理
   利用vrrp虚拟冗余路由协议生成vip，再根据配置文件内的优先级及脚本检测，检测对应的服务，当发现服务无法探测，vip就会飘移到备用机器上，就完成了故障转移。

2. keepalived内部监测nginx的脚本
   #!bin/bash

定义Nginx的监听地址和端口

nginx_address=”localhost” # 替换为实际的Nginx监听地址
nginx_port=80 # 替换为实际的Nginx监听端口

发送HTTP请求检查Nginx服务是否正常响应

response_code=$(curl -s -o /dev/null -w “%{http_code}” http://$nginx_address:$nginx_port)

if [ $response_code -eq 200 ]; then
echo “OK: Nginx is responding with HTTP status code 200.”
exit 0
else
echo “CRITICAL: Nginx is not responding with HTTP status code 200. Response code: $response_code”
exit 1
fi

3.
什么是Keepalived？它的作用是什么？
Keepalived是如何实现高可用性和负载均衡的？
Keepalived的配置文件有哪些重要的参数？请解释其中几个参数的作用。
Keepalived如何进行健康检查来确定服务器的可用性？
在Keepalived中，VRRP和LVS分别是什么？它们之间有何区别和联系？
如何在Keepalived中配置主备模式（Master/Backup）和共享虚拟IP地址？
Keepalived如何处理故障转移和故障恢复？
Keepalived的优点和局限性是什么？
你有使用Keepalived的经验吗？可以分享一个实际案例吗？
在Keepalived中，如果主节点失效后发生了故障恢复，会发生什么？

1. Keepalived是一种基于VRRP协议实现的高可用性解决方案，它可以确保在服务器故障时自动切换到备份服务器，从而保证服务的持续可用性。
2. Keepalived通过VRRP协议实现了主备模式的切换，同时结合LVS（Linux Virtual Server）实现了负载均衡和高可用性。当主节点失效时，备份节点会自动接管服务，并使用LVS进行负载均衡，从而保证服务的可用性和性能。
3. Keepalived的配置文件主要包括全局设置、VRRP实例和LVS虚拟服务器等部分。其中，重要的参数包括｀vrrp_instancestateinterfacevirtual_router_idpriorityadvert_intvirtual_ipaddress`real_server｀等。这些参数分别用于定义VRRP实例、配置服务器状态、指定网络接口、设置虚拟路由ID、设置优先级、配置广告间隔时间、指定虚拟IP地址和配置实际服务器等。
4. Keepalived可以通过健康检查来确定服务器的可用性，常见的健康检查方式包括PING、TCP端口、HTTP请求等。例如，我们可以设置Keepalived每隔一段时间向服务器发送一个HTTP请求，如果服务器正常响应该请求，则表示服务器可用，否则表示服务器不可用。
5. VRRP是一种协议，用于实现多个设备之间的主备切换和冗余备份。LVS是一种软件负载均衡器，可以将请求分发到多个后端服务器中，从而提高服务可用性和性能。Keepalived结合了VRRP和LVS两种技术，可以实现自动切换和负载均衡的高可用性解决方案。
6. 在Keepalived中，我们可以使用｀vrrp_instance｀定义VRRP实例，并设置｀state｀为MASTER或BACKUP来指定当前服务器的角色。同时，我们还需要配置｀interfacevirtual_router_idpriorityadvert_intvirtual_ipaddress｀等参数来指定网络接口、虚拟路由ID、优先级、广告间隔时间和虚拟IP地址。这样，我们就可以在主备节点之间实现自动切换和共享虚拟IP地址。
7. 当主节点失效时，备份节点会自动接管服务，并发送Gratuitous ARP消息告知其他设备虚拟IP地址已经切换到备份节点。同时，备份节点也会启动LVS，将请求分发到实际服务器上。当主节点恢复时，它会成为新的备份节点，并等待下一次故障发生。
8. Keepalived的优点包括易于配置、高可用性、支持多种负载均衡算法和健康检查方式等。它的局限性包括可能存在单点故障、对网络性能有一定影响、不适合大规模部署等。
9. 对于实际案例，一个典型的应用场景是使用Keepalived实现Web服务器的高可用性和负载均衡。在这个案例中，我们可以将多个Web服务器组成一个LVS集群，并使用Keepalived实现主备切换和负载均衡。这样，即使其中一个Web服务器出现故障，其他服务器仍然可以继续提供服务。
10. 当主节点失效后，备份节点会自动接管服务，并发送Gratuitous ARP消息告知其他设备虚拟IP地址已经切换到备份节点。当主节点恢复时，它会尝试重新接管服务，但只有当它的优先级高于当前备份节点时，才能成功接管服务。否则，备份节点将继续提供服务，直到主节点再次失效或者手动切换回主节点。

五、mysql

1. 主从复制的原理
   用户将数据写入主服务器上，主服务器上的dump线程会记录写操作的日志并存储到binlog日志中。从机上的i/o线程会读取master上的binlog日志，并将其重新记录在自己的中继日志里，从机上的sql线程会在本机上执行中继日志里的相关sql操作语句，从而保证从服务器上的数据与主服务器上的数据保持一致。

2. 数据不同步的原因？
   网络故障：主从服务器之间的网络连接丢包、延迟之类的
   时间不同步
   主服务器的负载过高，写请求的日志还没来得及更新，从服务器无法读取
   配置文件配置错误，比如设置了权限之类的

3. 什么是同步什么是异步？
   在数据库复制中，同步复制和异步复制是两种常见的复制方式。

4. 同步复制（Synchronous Replication）：
   同步复制是指主服务器在执行写操作后，必须等待至少一个从服务器将数据写入完成并确认成功后，才会向客户端返回成功。这意味着主服务器和从服务器之间的写操作是同步进行的。同步复制确保了主从服务器之间的数据一致性，但也会增加延迟和系统负担，因为主服务器需要等待确认。如果从服务器无法及时响应或出现故障，主服务器可能会出现阻塞。

5. 异步复制（Asynchronous Replication）：
   异步复制是指主服务器在执行写操作后，不需要等待任何从服务器的确认，就会向客户端返回成功。主服务器只需将数据变更记录到二进制日志中，并通过网络传输给从服务器。从服务器在接收到二进制日志后会异步地应用这些变更。异步复制可以降低延迟和系统负担，但也可能导致主从之间的数据稍有不一致，因为从服务器的应用速度可能会慢于主服务器的写操作。

同步复制和异步复制各有优劣，适用于不同的场景：

• 同步复制适用于对数据一致性要求较高且能承受一定延迟的场景，如关键业务、金融交易等。它提供了较高的数据保证性和一致性，但可能会对系统性能产生较大影响。

• 异步复制适用于对延迟要求较低且可以容忍数据稍有不一致的场景，如数据备份、报表查询等。它可以降低主服务器的负载和延迟，并提升系统的吞吐量。

4. 数据库可以做哪些优化？
   对于MySQL的配置文件，可以进行一些优化以提升性能和安全性。以下是一些常见的优化选项：

5. 内存配置：

   • 将｀innodb_buffer_pool_size｀参数设置为适当的值，以确保InnoDB缓冲池可以容纳常用数据，提高读取性能。
   • 调整｀key_buffer_size｀参数，用于MyISAM表索引缓冲区的大小。
   • 根据系统内存情况，适当调整其他缓冲区的大小，如｀innodb_log_buffer_size`query_cache_size｀等。

6. 线程配置：

   • 根据数据库连接数，适当调整｀max_connections｀参数。
   • 调整｀thread_cache_size`以减少创建和销毁线程的开销。

7. 查询性能优化：

   • 启用查询缓存，通过设置｀query_cache_type｀为1，并适当调整｀query_cache_size｀参数。
   • 针对具体的查询，使用索引、优化查询语句和表结构，以提高查询性能。

8. 日志配置：

   • 根据需要启用或禁用慢查询日志（｀slow_query_log）和错误日志（｀log_error），并设置合适的路径和级别。
   • 调整日志文件大小和数量，以避免日志过大导致磁盘空间不足。

9. 安全配置：

   • 确保设置了合适的密码策略，包括密码复杂度要求和定期更改密码。
   • 限制远程访问权限，只允许信任的IP地址连接MySQL服务器。
   • 启用SSL加密来保护数据传输的安全性。

10. 其他性能优化：

    • 定期优化和维护数据库表，使用｀ANALYZE TABLE｀和｀OPTIMIZE TABLE｀命令。
    • 配置适当的并发控制参数，如｀innodb_thread_concurrency｀和｀innodb_read_io_threads｀等。
    • 根据具体应用需求，调整其他相关参数，如｀max_allowed_packet`innodb_flush_log_at_trx_commit｀等。

以下是一个常用的MySQL配置文件模板（my.cnf）供您参考：

`
[mysqld]

设置数据库字符集为UTF-8

character-set-server=utf8mb4

设置数据库默认存储引擎为InnoDB

default-storage-engine=InnoDB

配置MySQL端口号，可以根据实际情况修改

port=3306

设置MySQL绑定的IP地址，可以根据需要指定具体的IP地址或者使用0.0.0.0监听所有地址

bind-address=0.0.0.0

配置InnoDB缓冲池大小，根据可用内存进行适当调整，如8GB内存可设置为6GB

innodb_buffer_pool_size=6G

配置InnoDB日志文件大小，根据实际情况进行调整

innodb_log_file_size=1G

配置查询缓存，可以根据实际情况启用或禁用，以及设置合适的缓存大小

query_cache_type=1
query_cache_size=256M

配置最大连接数，根据实际需求进行调整

max_connections=1000

配置慢查询日志，可以根据需要启用或禁用，并设置合适的路径和阈值

slow_query_log=1
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=2

配置错误日志，可以根据需要启用或禁用，并设置合适的路径

log_error=/var/log/mysql/error.log

配置最大包大小，根据需要进行调整

max_allowed_packet=64M

配置其他性能参数，可以根据实际情况进行调整

innodb_file_per_table=1
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
`

5. 如何设置忽略大小写的？
   编辑MySQL的配置文件 my.cnf
   在 [mysqld] 部分添加以下行：
   lower_case_table_names=1
   保存并关闭配置文件。
   重启MySQL服务以使更改生效。

6. mysql如何临时忽略密码？
   停止MySQL服务。
   在MySQL配置文件 my.cnf 中的 [mysqld] 部分添加以下一行：
   skip-grant-tables
   这会让MySQL忽略密码验证，并允许任何人以任何用户名登录。

7. 发生死锁的原因及解决办法？
   死锁是指两个或多个事务相互等待对方释放资源而无法继续执行的情况。这种情况可能发生在并发环境中，涉及数据库中的锁定机制。下面是造成死锁的常见原因和解决方法：
   SHOW ENGINE INNODB STATUS

造成死锁的原因：

1. 互斥条件：每个锁只能被一个事务持有。
2. 请求与保持条件：事务在等待其他资源的同时，保持自己已经获取的资源。
3. 不可剥夺条件：已经获得的资源只能由持有者主动释放，其他事务不能强制抢占。
4. 循环等待条件：存在一个事务等待链，其中每个事务都在等待下一个事务持有的资源。

解决死锁的方法：

1. 超时回滚：设置事务超时时间，在超过一定时间后，如果事务仍然处于等待状态，则强制回滚该事务。
2. 死锁检测和解除：通过周期性地检测死锁的存在，并采取相应措施进行解锁。例如，MySQL使用死锁检测算法来检测和解除死锁。
3. 锁定力度优化：减少事务持有锁的时间和范围，尽量缩小事务操作的锁定范围，以减少死锁的概率。
4. 事务重试：如果发生死锁，可以尝试重新执行事务，并希望这次执行不会出现死锁。

8.MySQL：

1. 什么是MySQL？MySQL是一种开源的关系型数据库管理系统（RDBMS），它使用SQL语言进行数据管理。

2. 什么是主键和外键？主键是一列或一组列，用于唯一标识表中的每一行。外键是一个字段或一组字段，用于在一个表中创建对另一个表的引用关系。

3. 数据库索引是什么？索引是一种数据结构，用于加快对数据库表中数据的访问速度。它允许数据库系统快速检索特定值，并提高查询性能。

4. 使用SELECT语句查询数据库时，如何限制返回的行数？可以使用LIMIT子句来限制返回的行数。例如，SELECT * FROM table_name LIMIT 10; 将返回表中的前10行数据。

5. 如何对结果进行排序？使用ORDER BY子句来对查询结果按照指定的列进行排序。例如：SELECT * FROM table_name ORDER BY column_name ASC（升序）/DESC（降序）；

6. 如何备份和恢复MySQL数据库？可以使用mysqldump命令来备份MySQL数据库，例如：mysqldump -u username -p database_name > backup.sql。要恢复数据库，可以使用mysql命令，例如：mysql -u username -p database_name < backup.sql。

7. 什么是事务？事务是一系列数据库操作的集合，这些操作要么全部成功执行，要么全部回滚。事务可以保证数据库的一致性和完整性。

8. 如何优化MySQL查询性能？可以通过以下方式来优化MySQL查询性能：创建合适的索引、优化查询语句、使用适当的存储引擎、调整系统缓冲区大小等。

9. 什么是连接（JOIN）操作？连接操作是将两个或多个表中的数据按照指定的条件进行关联，以获取更丰富的查询结果。

10. 什么是触发器（Trigger）？触发器是一种存储在数据库中的特殊类型的程序，它在数据库表上的特定事件（如插入、更新、删除）发生时被自动执行。

六、zk与kafka

1. 什么是zk？zk用来干嘛的？
   分布式协调服务，用来存储和管理各类数据
   以下是Zookeeper常见的使用场景和功能：
   分布式锁：Zookeeper提供了一种可重入的、临时性的分布式锁，可以确保在分布式环境中对共享资源的互斥访问。
   配置管理：Zookeeper可以作为配置中心，集中管理分布式系统的配置信息，并实时通知各个节点进行配置更新。
   命名服务：Zookeeper可以用来注册和发现分布式系统中的服务，提供服务的动态发现和负载均衡。
   分布式协调：Zookeeper提供了一些原语，如临时顺序节点、观察者机制等，可以实现分布式系统中的一致性协议、选举等功能。
   分布式队列：Zookeeper可以实现分布式环境下的队列和任务调度，保证任务的顺序执行和可靠性。

2. zk搭配kafka是起到什么样的作用？
   Zookeeper和Kafka是常见的搭配使用的组件，它们在分布式消息队列系统中起到了以下作用：

3. 配置管理：Zookeeper可以用作Kafka集群的配置管理工具。Kafka的各个节点可以通过Zookeeper共享配置信息，包括Broker的列表、Topic的分区分配等。当配置发生变化时，Zookeeper会通知Kafka节点进行相应的更新。

4. 高可用性：Kafka使用Zookeeper来实现集群的高可用性。Zookeeper可以监测Kafka Broker的状态，并在Broker故障时进行自动的主从切换。通过Zookeeper的选举机制，选出新的Leader Broker来继续提供服务，确保系统的可靠性。

5. Topic和分区管理：Kafka中的Topic和分区信息也通过Zookeeper进行管理和存储。Zookeeper负责记录每个Topic的分区数量和分区的Leader Brokers。当新增或删除Topic或分区时，Zookeeper会通知Kafka节点进行相应的调整。

6. 消费者协调：Kafka的消费者组协调器也依赖于Zookeeper。消费者组的注册、消费者的加入和离开、消费者偏移量的提交等操作都需要通过Zookeeper进行协调。Zookeeper会帮助Kafka消费者组来管理消费者的状态和消费进度。

总之，Zookeeper和Kafka的搭配使用可以实现Kafka集群的配置管理、高可用性、Topic和分区的管理，以及消费者组的协调。Zookeeper作为Kafka的重要组件，提供了可靠的分布式协调服务，保证了Kafka系统的稳定运行和数据一致性。

3. zk里面涉及到的角色？
   leader follower observer
   参与投票的：leader follower
   在ZooKeeper中，Leader、Follower和Observer是ZooKeeper集群中的三种角色。

Leader是ZooKeeper集群中的核心，负责处理所有客户端请求并维护系统状态。当客户端向ZooKeeper发送写操作时，Leader将该请求转发给所有的Follower和Observer，一旦大多数（即超过半数）的Follower和Observer都执行了该操作，并将结果通知Leader之后，Leader才会认为该操作执行成功，并将结果告知客户端。

Follower是ZooKeeper集群中的从属角色，它与Leader保持同步，接受Leader的指令并执行。在ZooKeeper集群中，Follower数量可以很多，它们主要用于提高系统的读取性能和容错性。

Observer也是ZooKeeper集群中的从属角色，但与Follower不同的是，Observer不参与任何写操作，只接受Leader的数据同步。Observer可以提高读取性能，同时还可以分担Follower的负载，从而使得ZooKeeper集群更加稳定。

4. zk里面有脏数据怎么处理？
   在ZooKeeper中，脏数据通常指的是在集群中某些节点上存在过期或无效的数据。这可能是由于网络故障、节点崩溃或其他异常情况导致的。

ZooKeeper提供了一种称为”数据版本”（data version）的机制来处理脏数据。每个数据节点都有一个与其关联的数据版本号，当该节点上的数据发生变化时，版本号将自动递增。当客户端想要更新某个节点的数据时，必须提供节点的当前版本号，以确保数据的一致性。

如果出现脏数据，可以通过以下步骤进行处理：

1. 使用getData方法获取节点的数据和版本号。
2. 检查获取到的数据是否有效。可以根据业务逻辑判断数据是否过期或无效。
3. 如果数据有效，则使用setData方法更新节点的数据，并提供当前的版本号。
4. 如果数据无效或过期，可以选择忽略该数据或执行其他相应的处理逻辑。

另外，ZooKeeper还提供了”临时节点”（ephemeral node）的特性，这些节点在创建它们的客户端断开连接后会自动删除。通过合理地使用临时节点，可以降低脏数据的产生和处理的复杂度。

5. zk发生脑裂的原因以及排查解决办法？
   脑裂（Split-Brain）是指在ZooKeeper集群中发生网络分区或故障，导致集群内的节点无法相互通信，从而导致集群分裂成多个独立的子集。这种情况下，每个子集都可能认为自己是有效的主节点，导致数据不一致和服务不可用。

脑裂可能的原因包括：

1. 网络故障：例如网络分区、网络延迟或丢包等问题。
2. 节点故障：如果集群中的某些节点崩溃或无法正常工作，可能会导致脑裂情况。

要解决和排查脑裂问题，可以考虑以下方法：

1. 配置合理的集群规模：确保集群中的节点数量足够，并且节点分布在不同的物理服务器上，以减少单点故障的影响。

2. 检查网络配置和健康状况：检查集群节点之间的网络连接是否正常，并确保网络延迟和丢包率较低。

3. 使用Quorum机制：在ZooKeeper集群中，通过配置合适的投票数（quorum），可以确保只有大多数节点存活和通信时，集群才能正常工作。这可以减少脑裂的可能性。

4. 监控节点健康状态：使用监控工具检测集群节点的健康状况，及时发现并处理故障节点。可以使用ZooKeeper提供的四字命令（Four-letter Words）或其他监控工具进行检查。

5. 配置适当的超时和重试机制：在ZooKeeper客户端和应用程序中设置适当的超时和重试策略，以应对网络故障和节点故障。

6. 使用分区隔离技术：可以将ZooKeeper集群部署在不同的子网或数据中心中，使用网络分区隔离来减少脑裂问题的发生。

7. 定期备份和恢复：定期备份ZooKeeper数据，并确保有可靠的恢复机制，以便在发生脑裂或其他数据丢失情况时能够快速恢复。

6. zk的选主机制
   ZooKeeper的选主机制在首次选主和非首次选主时有一些差异。

首次选主：

1. 当ZooKeeper集群中没有任何节点时，首次启动的节点会自动成为Leader节点。
2. Leader节点开始等待其他节点加入集群并进行选举。

非首次选主：

1. 当新的节点加入已经存在的ZooKeeper集群时，它会向集群中的其他节点发送投票请求，并等待其他节点的投票。
2. 其他节点检查投票请求中的版本号和ZXID是否有效，如果有效则将投票返回给请求节点。
3. 请求节点收到过半数的投票后，成为新的Leader节点。

无论是首次选主还是非首次选主，选主过程都需要满足以下条件：

• 新节点的ZXID必须大于集群中最大的ZXID，以确保新节点具有最新的数据。
• 新节点的epoch必须大于集群中最大的epoch，以确保新节点的投票请求有效。

需要注意的是，在非首次选主中，如果已经存在一个Leader节点，新节点必须通过投票获得过半数的支持才能成为新的Leader。这样可以确保选出的Leader节点具有广泛的支持，从而保证集群的稳定性和一致性。

7. kafka内的僵尸数据如何处理？
   在Kafka中，僵尸数据指的是已经过期但仍然保存在topic中的消息。这可能是由于消费者组没有及时消费这些消息或者消息的过期时间设置不合理导致的。

处理Kafka中的僵尸数据可以采取以下几种方法：

1. 调整消费者组的消费速率：如果消费者组无法及时消费消息，可以增加消费者的数量或者优化消费者代码逻辑，提高消费速率，以减少僵尸数据的产生。

2. 设置合理的消息过期时间：在创建topic时，可以设置消息的过期时间（TTL），超过该时间后，消息将被自动删除。通过合理设置过期时间，可以避免长时间保留不需要的数据。

3. 定期清理僵尸数据：可以定期使用Kafka提供的工具，如kafka-delete-records.sh或kafka-topics.sh，针对特定的topic或分区删除已过期的消息。

4. 使用日志压缩功能：Kafka提供了日志压缩功能，可以将过期的消息进行压缩，从而减少存储空间的占用。可以根据实际需求启用相应的日志压缩配置。

5. 监控和告警机制：建议设置监控和告警机制，及时发现并处理产生僵尸数据的问题。可以使用Kafka自带的监控工具，如Kafka Metrics和Kafka Connect监控等，或者结合第三方监控工具进行监控。

6. kafka中常见的一些名词概念

7. Broker（代理）：Kafka集群中的每个服务器节点称为Broker，它们负责存储和处理消息。

8. Topic（主题）：消息在Kafka中被发布到指定的主题中，主题是消息的逻辑分类单元。生产者将消息发布到主题，消费者从主题订阅并消费消息。

9. Partition（分区）：每个主题可以分为多个分区，分区是消息的物理存储单元。分区可以在不同的Broker节点上分布，以实现数据的并行处理和负载均衡。

10. Producer（生产者）：生产者负责将消息发布到指定的主题中，可以选择将消息发送到特定分区，也可以让Kafka自动进行分区选择。

11. Consumer（消费者）：消费者从指定的主题中订阅消息，并进行消费处理。每个消费者都属于一个消费者组，消费者组内的消费者共同消费主题的消息。

12. Consumer Group（消费者组）：多个消费者可以组成一个消费者组，消费者组内的消费者共同消费一个主题的消息。每个分区只能由同一个消费者组内的一个消费者进行消费。

13. Offset（偏移量）：在每个分区中，消息通过偏移量进行顺序编号。消费者可以通过指定偏移量来消费特定位置的消息，Kafka会记录每个消费者组的偏移量信息。

14. Replication（复制）：为了提高数据的可靠性和容错性，Kafka使用副本机制将分区的数据复制到多个Broker节点上。每个分区都有一个Leader副本和多个Follower副本。

15. Leader（领导者）：每个分区中的一个副本被选举为Leader，负责处理读写请求。其他副本是Follower，用于备份数据和提供冗余。

16. ZooKeeper：Kafka使用ZooKeeper来进行集群管理、协调和元数据存储。ZooKeeper维护了Broker的状态信息、分区的分配和消费者组的偏移量等。

17. kafka中积压大量数据怎么办

18. 增加消费者数量：如果积压是由于消费者无法及时处理消息导致的，可以通过增加消费者的数量来提高整体消费能力。这样可以将负载均衡到更多的消费者上，加快消息的处理速度。

19. 扩展Kafka集群：如果积压是由于Kafka集群无法处理高吞吐量的请求导致的，可以考虑扩展集群规模。增加Broker节点和分区数量，以提高整个集群的处理能力。

20. 调整分区和副本配置：根据实际情况，调整主题的分区数量和副本数量，以适应更高的消息处理需求。可以增加分区数量来提高并行性，或增加副本数量来提高可靠性和读取能力。

21. 提高硬件配置：对于Kafka服务器节点，可以考虑提升硬件配置，如CPU、内存、磁盘等，以增加系统的处理能力和存储能力。

22. 调整Kafka参数配置：根据实际情况，可以调整Kafka的一些参数配置来优化性能。例如，调整消息的压缩方式、批处理大小、网络缓冲区等参数，以提高整体的吞吐量和处理效率。

23. 模拟消费生产的过程
    bin/kafka-topics.sh –create –zookeeper localhost:2181 –replication-factor 1 –partitions 1 –topic my-topic
    ./bin/kafka-console-producer.sh –broker-list localhost:9092,middle2:9092,middle3:9092 –topic my-topic
    ./kafka-console-consumer.sh –bootstrap-server 192.168.211.163:9092,192.168.211.164:9092,192.168.211.165:9092 –topic my-topic –from-beginning

24. kafka中某个数据分片丢失怎么办？
    当 Kafka 中的某个分片（partition）丢失时，可以考虑以下几种处理方法：

25. 确认是否有备份：首先需要确认是否有备份的分片数据可用。如果有备份，可以尝试恢复丢失的分片数据。

26. 重新平衡分区：Kafka 提供了分区重新平衡的机制，可以通过重新分配分片的副本来恢复丢失的分片。可以使用 Kafka 提供的命令行工具或编程接口来执行分区重新平衡操作。

27. 重新同步数据：如果没有备份且无法进行分区重新平衡，可以尝试重新同步数据。可以将其他正常的分片作为参考，使用消费者从其他分片中读取数据，并将数据写入丢失的分片中，以尽可能地恢复数据。

28. 恢复丢失的数据：如果丢失的数据无法通过以上方法恢复，可能需要考虑其他手段，如从其他系统或数据源重新生成数据，或者与相关业务方协商处理。
    七、redis

29. 你们使用redis的那种模式？
    Redis常见的几种模式包括：

30. 单机模式（Standalone Mode）：最简单的Redis部署方式，数据存储在单个Redis实例中。这种模式适合于开发和测试环境，但缺乏高可用性和容错能力。

31. 主从复制模式（Master-Slave Replication）：该模式通过将一个Redis实例配置为主节点（master），并将其他实例配置为从节点（slave），实现数据的复制和备份。主节点负责写操作，从节点负责读操作。主从复制提供了一定的冗余和故障恢复能力。

32. 哨兵模式（Sentinel Mode）：哨兵模式是基于主从复制的高可用性解决方案。它引入了一个哨兵进程，用于监控主节点和从节点的状态。当主节点宕机时，哨兵会自动将一个从节点晋升为新的主节点，并通知其他从节点更新配置。

33. 集群模式（Cluster Mode）：Redis集群模式用于处理大规模数据集的高可用性和横向扩展。它将数据分布在多个节点上，并自动管理数据的分片、数据迁移和故障转移等操作。集群模式提供了更高的吞吐量和可扩展性。

34. 你用redis来做什么的？主要在什么场景？
    主要用来做数据缓存，将频繁访问的数据存储在内存中，以加快读取速度。它可以显著降低数据库负载，并提高应用程序的性能和响应速度。
    Redis的高性能、低延迟和丰富的功能使其在许多场景中得到广泛应用，包括Web应用、电子商务、游戏、实时通信、日志处理和大数据等领域。

35. redis为什么有这么高的性能？
    Redis之所以具有高性能，主要归功于以下几个方面：

36. 内存数据存储：Redis将数据存储在内存中，而不是磁盘上。相比于传统的磁盘存储，内存存储具有更快的读写速度和更低的访问延迟。

37. 单线程模型：Redis采用单线程的方式处理客户端请求。这意味着不需要进行复杂的线程间同步和锁机制，避免了线程切换的开销和竞争条件的问题。单线程模型简化了代码逻辑，提高了性能。

38. 异步I/O：Redis使用了异步的I/O模型，通过非阻塞的方式处理多个客户端请求。这种方式可以充分利用系统资源，提高并发性能。

39. 基于内存的数据结构：Redis提供了丰富的数据结构，如字符串、哈希表、列表、集合和有序集合等。这些数据结构在内存中进行操作，具有高效的读写性能和复杂数据处理能力。

40. 简单的持久化机制：Redis支持持久化机制，可以将数据保存到磁盘上，以便于数据恢复。Redis提供了两种持久化方式：RDB（快照）和AOF（日志）。相比于传统的关系型数据库，Redis的持久化机制更为简单和高效。

41. 缓存和预热机制：Redis常被用作缓存层，将频繁访问的数据存储在内存中。这减少了对后端存储的访问次数，提高了响应速度和吞吐量。

42. 高度优化的网络通信：Redis使用了自己设计的高性能网络通信框架，可以处理大量的并发连接，并支持高速的数据传输和处理。

43. redis哨兵模式工作的原理？

44. 哨兵节点的选举：在一个Redis哨兵集群中，有多个哨兵节点运行，并选择一个哨兵节点作为领导者（leader），负责监控Redis主节点和从节点的状态。

45. 监控Redis节点：哨兵节点定期向Redis主节点和从节点发送PING命令，以检查它们的可用性。如果一个节点超过了预设的时间没有响应，哨兵节点将认为该节点已经下线。

46. 发现主节点故障：当哨兵节点发现主节点下线时，它会根据预设的故障转移配置，选举一个从节点作为新的主节点。哨兵节点会发送命令通知其他哨兵节点和客户端有关主节点切换的信息。

47. 故障转移过程：在故障转移过程中，哨兵节点会将新的主节点配置信息发送给所有从节点，并将它们设置为新主节点的从节点。同时，哨兵节点还会更新客户端的配置，使其连接到新的主节点。

48. 重新选举领导者：如果哨兵节点中的领导者出现故障，其他哨兵节点会进行重新选举，选择一个新的领导者来监控和管理Redis节点。

49. 哨兵是如何选主的？
    当slave发现自己的master挂了
    将自己记录的currentEpoch加1,并向其他节点请求投票给自己成为master
    其他节点收到请求,只有master会回应,判断请求的合法性,并投票,可能会有多个slave请求,每个master只能投一票
    slave收集master的投票
    当slave收到的投票超过半数后就可以成为master
    广播消息通知其他节点

50. redis里面的数据类型
    Redis支持多种不同的数据类型，包括：

51. 字符串（string）：存储文本或二进制数据，例如用户会话、配置设置等。字符串类型是Redis中最基本的数据类型。

52. 散列（hash）：一种键值对集合，其中每个键都映射到一个值。散列类型常用于表示对象，例如用户信息、文章信息等。

53. 列表（list）：一种有序的字符串集合，其中每个元素都有一个索引。列表类型常用于实现队列、栈、排行榜等功能。

54. 集合（set）：一种无序的字符串集合，其中每个元素都是唯一的。集合类型支持多种集合操作，例如交集、并集、差集等。

55. 有序集合（sorted set）：类似于集合，但每个元素都有一个分数，可以根据分数进行排序。有序集合类型常用于实现排行榜、计数器等功能。

56. redis内部数据的持久化方式？

57. 快照（snapshot）持久化：Redis可以将内存中的数据以二进制文件的形式保存到磁盘上。这个过程称为快照持久化。Redis提供了两种快照持久化的方式：

    • RDB持久化：将数据保存到一个压缩的二进制文件（RDB文件）中。它是通过fork一个子进程来实现的，子进程负责将内存中的数据写入到磁盘上的RDB文件中。RDB持久化是一种非常紧凑和高效的持久化方式，适用于备份数据、全量恢复等场景。

58. 追加日志（append-only file，AOF）持久化：Redis可以将执行的写操作追加到一个持久化文件（AOF文件）的末尾。这个文件包含了重建服务器状态所需的所有写命令。Redis在启动时会读取AOF文件，并将其中的写命令重新执行一遍，从而还原数据。AOF持久化提供了更好的数据安全性，但相对于RDB持久化来说，文件体积会更大，并且恢复速度可能会慢一些。

容器化

1. docker和k8s的区别？
   docker是容器平台，它可以将应用程序及其依赖打包成一个可移植的容器，使得应用在不同环境中运行更加方便
   k8s是容器编排和管理工具，用于自动化部署、扩展和管理容器化应用程序。

2. docker常用的命令？
   docker load -i 加载一个镜像包
   docker tag 更改标签
   docker push 推送镜像到镜像仓库
   docker pull 从镜像仓库拉镜像
   docker run -d 从后台跑一个容器
   docker stop 停止某个容器
   docker rm删除某个容器
   docker rmi 删除镜像
   docker inspect 查看容器的详细信息
   docker commit 创建一个新的镜像来自于一个容器
   docker save 保存镜像成镜像包
   docker build -t 根据dockerfile构建一个镜像
   docker ps 显示正在运行的所有容器
   docker images 列出所有镜像
   docker exec -it 进入某个容器
   docker cp拷贝文件
   docker logs 获取一个容器的日志
   docker top显示一个容器运行的进程
   参数：
   -it分配一个交互式伪终端
   -v 挂载卷
   -p 映射端口

3. dockerfile里面常用的一些字段？
   在编写 Dockerfile 时，常用的一些字段包括：

4. FROM：指定基础镜像，用于构建当前镜像。

5. RUN：在容器中执行命令，可以用于安装软件包、运行脚本等操作。

6. COPY：将文件或目录从主机复制到容器中。

7. ADD：类似于 COPY，但支持更多功能，例如解压缩文件和远程 URL 下载。

8. WORKDIR：设置工作目录，后续的命令将在该目录下执行。

9. ENV：设置环境变量。

10. EXPOSE：声明容器运行时需要监听的端口。

11. CMD：容器启动时执行的命令，只能有一个 CMD 命令，如果有多个，则只有最后一个生效。

12. ENTRYPOINT：容器启动时执行的命令，与 CMD 类似，但可以与 docker run 命令参数结合使用。

13. copy和add的区别？
    在 Dockerfile 中，COPY 和 ADD 都用于将文件从主机复制到容器中，但它们之间有一些区别：

14. COPY：

    • 语法：COPY <源路径> <目标路径>
    • 功能：复制本地文件或目录到容器中。可以复制多个文件或整个目录。
    • 注意事项：源路径必须是相对于 Dockerfile 的路径，不能包含 URL。目标路径可以是绝对路径或相对 WORKDIR 的路径。
    • 不会自动解压缩文件。

15. ADD：

    • 语法：ADD <源路径> <目标路径>
    • 功能：与 COPY 类似，复制文件或目录到容器中。除了复制功能外，还支持更多功能。
    • 额外功能：
      • 如果源路径是一个 tar 压缩文件（如 .tar、.tar.gz、.tgz、.bz2、.tar.xz、.txz），它将自动解压缩到目标路径。
      • 如果源路径是一个 URL，它会自动下载并复制到目标路径。
    • 注意事项：与 COPY 不同，源路径可以是 URL，不仅限于本地文件或目录。

总结：

• 如果只需要简单地复制文件或目录到容器中，通常优先选择使用 COPY 指令。
• 如果需要自动解压缩文件或从 URL 下载文件到容器中，可以使用 ADD 指令。
• 在大多数情况下，使用 COPY 指令更为常见，因为它更简洁明确，并且能够避免一些潜在的问题，比如从不受信任的 URL 下载文件。

5. cmd和entrypoint的区别
   在 Dockerfile 中，CMD 和 ENTRYPOINT 都用于定义容器启动时执行的命令，但它们之间有一些区别：

6. CMD：

   • 语法：CMD <命令>
   • 功能：指定容器默认的执行命令。可以有多个 CMD 命令，但只有最后一个 CMD 命令生效。
   • 特点：
     • 如果在运行容器时指定了其他命令，如 docker run myimage command，CMD 的命令会被覆盖。
     • CMD 的命令可以被 Dockerfile 中的 ENTRYPOINT 指令替换。
   • 例子：CMD [“npm”, “start”]

7. ENTRYPOINT：

   • 语法：ENTRYPOINT <命令>
   • 功能：指定容器启动时执行的命令。可以与 CMD 结合使用，形成一个可执行的命令。
   • 特点：
     • 如果在运行容器时指定了其他命令，如 docker run myimage command，ENTRYPOINT 的命令不会被覆盖，而是作为参数传递给它。
     • ENTRYPOINT 的命令不会被 Dockerfile 中的 CMD 指令替换。
   • 例子：ENTRYPOINT [“npm”, “start”]

总结：

• CMD 用于指定容器默认的执行命令，可以被覆盖。
• ENTRYPOINT 也用于指定容器启动时执行的命令，但不会被覆盖，可以接收额外的命令作为参数。
• 如果想要容器在启动时执行一个固定的命令，可以使用 ENTRYPOINT。如果需要在运行容器时传递不同的参数，可以结合使用 ENTRYPOINT 和 CMD。

6. 给出一个你写过的dockerfile例子？

   使用官方的 MySQL 镜像作为基础镜像

   FROM mysql:latest

设置环境变量

ENV MYSQL_ROOT_PASSWORD=password
ENV MYSQL_DATABASE=mydatabase
ENV MYSQL_USER=myuser
ENV MYSQL_PASSWORD=mypassword

复制自定义的配置文件到容器中

COPY my.cnf /etc/mysql/my.cnf

将数据库初始化脚本复制到容器中的 /docker-entrypoint-initdb.d/ 目录下

COPY init.sql /docker-entrypoint-initdb.d/

指定容器启动时执行的命令

CMD [“mysqld”]

暴露 MySQL 默认的端口

EXPOSE 3306

7. docker镜像和容器有什么关系区别？
   Docker 镜像是一个不可变的文件，包含了运行 Docker 容器所需的所有信息。Docker 容器是 Docker 镜像的运行实例，它可以被启动、停止、删除等操作。

8. 如何让构建的镜像体积最小？
   以下是几种常见的减小 Docker 镜像体积的方法：

9. 使用最小化基础镜像：选择最小化的基础镜像可以减少不必要的软件包和依赖，从而减小镜像的体积。例如，使用 Alpine Linux 或者 Scratch 作为基础镜像。

10. 精简安装包：在安装软件包时，只安装必要的依赖，并尽可能地减少不必要的软件包和文件。可以使用 --no-install-recommends 参数来避免安装不必要的依赖。

11. 按需复制文件：只复制应用程序和配置文件等必要的文件到镜像中，避免复制不必要的文件和目录。

5. 清理无用文件：在构建镜像中，需要清理掉在构建过程中产生的临时文件、无用文件和缓存等，可以使用 RUN apt-get clean && rm -rf /var/lib/apt/lists/* 来实现。

6. 多阶段构建：使用多阶段构建可以减小构建过程中产生的中间层，从而减小镜像的体积。例如，在构建 Java 应用程序时，可以使用 Maven 构建镜像，并将最终生成的 Jar 包复制到一个新的镜像中。

7. 压缩镜像：使用 docker save 命令将镜像保存到一个 tar 包中，并使用 gzip 压缩该 tar 包可以进一步减小镜像的体积。

总之，通过使用最小化基础镜像、精简安装包、按需复制文件、合并多条命令、清理无用文件、多阶段构建和压缩镜像等方式，可以有效地减小 Docker 镜像的体积。

9. docker-compose如何按顺序进行编排容器？
   在 Docker Compose 中，可以使用 depends_on 字段来指定服务之间的依赖关系，从而按顺序进行编排。

10. docker-compose里面如何做数据的持久化？
    在 Docker Compose 中，可以通过挂载数据卷（volume）来实现数据的持久化。数据卷是一个特殊的目录，可以绕过容器文件系统，在容器之外存储和共享数据。

11. docker-compose里面暴露端口如何写？
    在 Docker Compose 中，可以使用 ports 字段来指定要暴露的端口。这样，容器中运行的服务就可以通过主机的端口进行访问。

12. docker的几种网络模式？

13. 桥接网络（Bridge Network）：

    • 默认使用的网络模式，创建一个桥接网络，将容器连接到该网络中。
    • 桥接网络允许容器之间相互通信，并且可以通过端口映射将容器的端口暴露给主机或其他网络。
    • 桥接网络可以通过自定义网络名称来创建。

14. 主机网络（Host Network）：

    • 容器使用主机的网络栈，与主机共享网络命名空间。
    • 容器可以直接使用主机的网络接口，无需进行端口映射或网络地址转换。
    • 主机网络模式适用于需要容器与主机直接共享网络的场景，但可能会导致端口冲突或安全风险。

15. 无网络（None Network）：

    • 容器没有网络接口，与外部网络隔离。
    • 无网络模式适用于不需要网络连接的容器，如批处理作业、系统调试等。

16. k8s里面的几个基本组件？
    kube-apiserver：提供 Kubernetes API 的接口，用于与集群交互。
    kube-controller-manager：负责运行各种控制器，处理集群的状态和工作负载。
    kube-scheduler：负责将 Pod 调度到合适的节点上运行。
    etcd 是一个分布式键值存储系统，用于保存集群的配置数据和状态信息。
    Kubernetes 使用 etcd 来持久化保存集群的各种对象（如 Pod、Service、ConfigMap 等）的状态和配置信息。
    kubelet：负责与 Master 节点通信，管理节点上的容器和 Pod。
    kube-proxy：负责为 Pod 提供网络代理和负载均衡功能。

17. k8s常用的基本命令？
    kubectl cluster-info：显示集群的连接信息。
    kubectl version：显示客户端和服务器的版本信息。
    kubectl get nodes：显示集群中的节点列表。

kubectl create：从配置文件创建资源。例如：kubectl create -f pod.yaml。
kubectl apply：从配置文件创建或更新资源。例如：kubectl apply -f deployment.yaml。
kubectl delete：删除资源。例如：kubectl delete pod my-pod。
kubectl get：获取资源的信息。例如：kubectl get pods。
kubectl describe：显示资源的详细信息。例如：kubectl describe pod my-pod。
kubectl edit：编辑资源的配置。例如：kubectl edit deployment my-deployment。

kubectl scale：扩展或缩减副本数。例如：kubectl scale deployment my-deployment –replicas=3。
kubectl rollout：管理滚动更新。例如：kubectl rollout status deployment my-deployment。
kubectl expose：将 Deployment 暴露为 Service。例如：kubectl expose deployment my-deployment –port=8080。

kubectl logs：查看 Pod 的日志信息。例如：kubectl logs my-pod。
kubectl exec：在容器内执行命令。例如：kubectl exec -it my-pod – /bin/bash。

15. 生产一个pod所经历的过程？
    在 Kubernetes 中，一个 Pod 是最小的部署单元，它可以包含一个或多个容器。在生产中创建一个 Pod 时，以下几个组件协同工作：

16. Kube-apiserver：

    • 用户通过 kubectl 命令行工具或其他方式提交 Pod 的创建请求给 kube-apiserver。
    • kube-apiserver 验证请求的合法性并将其接受。

17. Etcd：

    • kube-apiserver 将 Pod 的创建请求写入 etcd 存储中，持久化保存集群的状态和配置信息。

18. Kube-controller-manager：

    • kube-controller-manager 中的 ReplicaSetController、DeploymentController、StatefulSetController 等控制器会监视 etcd 中的变化。
    • 当发现有新的 Pod 创建请求时，控制器会相应地创建一个新的 Pod。

19. Kube-scheduler：

    • kube-scheduler 负责为新创建的 Pod 选择一个合适的节点进行调度。
    • kube-scheduler 根据一系列调度策略（如资源需求、亲和性、反亲和性等）评估节点，并选择最佳的节点来运行 Pod。

20. Kubelet：

    • kubelet 是运行在每个节点上的代理程序，负责与 kube-apiserver 进行通信。
    • kubelet 接收到 kube-apiserver 发送过来的创建 Pod 的指令后，会在当前节点上启动该 Pod 所需要的容器。

21. Container Runtime：

    • Container Runtime（如 Docker、containerd 等）负责真正地运行容器。
    • kubelet 通过 Container Runtime 在节点上启动和管理容器。

22. Kube-proxy：

    • kube-proxy 是运行在每个节点上的网络代理，负责为 Pod 提供网络代理和负载均衡功能。
    • kube-proxy 会为每个 Pod 创建相应的网络规则，以便能够将流量正确地转发到 Pod 中的容器。

16. pod的生命周期？
    在 Kubernetes 中，Pod 是最小的部署单元，它可以包含一个或多个容器。Pod 的生命周期由以下几个阶段组成：

17. Pending（等待中）：Pod 已经被创建，但尚未被调度到节点上运行。在这个阶段，Kubernetes 将根据资源需求和调度策略选择合适的节点来运行 Pod。

18. Running（运行中）：Pod 已经成功调度到某个节点上并正在运行。在这个阶段，Pod 中的容器处于运行状态，并且可以通过网络访问。

19. Succeeded（已成功）：Pod 中的所有容器都已成功完成任务并退出。例如，一个批处理作业中的所有任务都已经完成。在这个阶段，Pod 的状态被设置为 Succeeded。

20. Failed（已失败）：Pod 中的至少一个容器已经以非正常的方式退出，或者 Pod 无法正常启动。例如，容器的入口命令执行失败或者容器因为资源限制而被终止。在这个阶段，Pod 的状态被设置为 Failed。

21. Unknown（未知）：无法获取到 Pod 的当前状态。这可能是由于与 Pod 所在节点的通信故障导致的。

在以上各个阶段，Kubernetes 控制器会根据 Pod 的定义和当前状态执行相应的操作，如调度、重启、自动伸缩等。除了以上阶段，Pod 还可以进入一些特殊的状态，如 Evicted（被驱逐）和 Terminating（正在终止）。这些状态表示 Pod 正在被 Kubernetes 系统进行管理和处理。

17. k8s中的资源类型？

kvm