Linux运维/云原生面试核心笔记

一、Redis

1、数据结构(5基础+2高级)

基础5种

  1. String 字符串,最基础
  2. List 列表
  3. Hash 哈希
  4. Set 集合(去重)
  5. ZSet 有序集合(带score分值排序)
    高级2种
  6. HyperLogLog:基数统计,近似值,误差0.81%,适合UV统计,省内存
  7. Stream:消息队列,类似Kafka,持久化、记录消费位点,消息不丢

2、持久化 RDB & AOF + 混合持久化(Redis4.0+)

RDB(快照)

  • 原理:某时间点把内存全量快照存为二进制压缩dump.rdb
  • 触发:手动save/bgsave;自动save 900 1这类配置
save 900 1    #900s至少1个key变更,快照
save 300 10
save 60 10000
  • bgsave流程:
    1. 判断是否已有子进程在做bgsave/bgrewriteaof,有则直接返回
    2. fork子进程(fork阶段主进程阻塞
    3. fork成功后主进程恢复对外服务,子进程生成临时rdb,完成后原子替换旧rdb
    4. 通知主进程更新统计信息
  • ✅优点:文件紧凑、体积小、恢复速度快、适合全量备份迁移
  • ❌缺点:非实时持久化,宕机会丢最近数据;大实例fork阻塞;新旧版本RDB兼容性差

AOF(日志追加)

  • 原理:记录所有写命令,重启重放命令恢复数据;开启优先加载AOF
  • 3种同步策略
appendfsync always    #每次写都刷盘,安全,性能差
appendfsync everysec  #每秒同步,默认,折中方案
appendfsync no        #交给操作系统,性能好,丢数据风险高
  • AOF三阶段:命令追加缓冲区 → 文件写入 → fsync刷盘
  • AOF重写bgrewriteaof:压缩AOF,合并重复命令、剔除过期/无效命令,不读旧AOF,直接基于当前内存生成新AOF
  • ✅优点:秒级持久化、append追加不会损坏已有日志、兼容性好
  • ❌缺点:文件体积大、恢复慢、IO压力更高

持久化选型

  • 高可靠:RDB+AOF+混合持久化
  • 数据可丢失:关闭持久化,性能最高

3、Redis高可用三种方案

  1. 主从复制
    • 作用:数据热备份、读写分离(主写从读)、故障恢复基础
    • 流程:从节点发sync → master生成RDB+缓存增量命令 → 推送RDB给从节点加载 → 推送增量命令同步
    • 缺陷:故障无法自动切换、写不能负载均衡、单机存储上限
  2. 哨兵Sentinel(主从+自动故障转移)
    • 组件:哨兵节点(26379,不存数据)+主从数据节点;至少3个哨兵
    • 能力:监控、自动故障转移、通知客户端
    • 下线机制:
      • 主观下线:单个哨兵ping不通master
      • 客观下线:半数以上哨兵确认故障,触发故障转移
    • 新主选举规则:优先级>复制偏移量>节点ID
    • 缺陷:写无法负载均衡、单机存储上限
  3. Redis Cluster集群
    • 分片:16384个哈希槽,CRC16(key)%16384分配槽位
    • 主从架构:主节点负责读写,从节点备份;支持主节点自动故障转移
    • ✅解决:写负载均衡、突破单机内存限制
    • ❌缺点:最少6台机器、配置复杂

选型:读多写少、预算有限 → 哨兵;需要分片扩容、写量大 → Cluster

4、Redis经典三大问题(缓存雪崩/穿透/击穿)

  1. 缓存雪崩:大量key同时过期 / Redis整体宕机,请求全部打DB,压垮数据库
    • 方案:过期时间加随机值;Redis高可用;本地缓存+限流熔断;持久化快速恢复
  2. 缓存穿透:查询一定不存在的数据,缓存永远不命中,直查DB
    • 方案:布隆过滤器拦截;空值短期缓存
  3. 缓存击穿单个热点key过期瞬间,大量并发请求打到DB
    • 方案:热点key永不过期;互斥锁

一句话区分:雪崩=大批量key失效;穿透=查不存在key;击穿=单个热点key失效

5、Redis vs Memcached

  1. Redis支持多种数据结构,Memcache仅简单K/V
  2. Redis支持持久化、主从、集群;Memcache断电数据全丢
  3. Redis支持虚拟内存,可冷热交换;Memcache数据不能超内存
  4. Redis可expire动态过期;Memcache set时指定过期
  5. Redis单线程模型;Memcache多线程

选型:需要持久化、复杂数据结构 → Redis;简单静态KV缓存 → Memcached

二、MongoDB

MongoDB是文档型NoSQL,BSON存储(二进制JSON,支持date、二进制)
✅优势:面向文档、任意字段建索引、支持分片集群、复制集高可用、查询语法丰富、即时更新
✅适用场景:大数据、内容管理、APP移动端、非结构化数据管理

三、消息队列(Zookeeper + Kafka)

1、MQ作用

解耦、流量削峰、异步处理、消息通讯
两种模型:

  • 点对点:一对一,消费完删除
  • 发布订阅:一对多,多个消费者收到消息

2、Zookeeper

本质:文件系统 + 观察者Watcher通知机制,分布式协调组件,存集群元数据

  • 集群:1Leader + 多个Follower;过半存活集群可用,推荐奇数节点
  • 数据模型:树形ZNode,每个ZNode最多存1MB,支持Watcher监听
  • 核心机制:Zab原子广播协议;ZXID(64位事务ID,高32位Epoch任期,低32位自增序号)、SID服务器ID
  • 典型场景:配置中心、服务注册发现、分布式锁、集群Leader选举、元数据存储

3、Kafka

核心概念

  • Broker:单台kafka服务
  • Topic:消息主题,逻辑队列
  • Partition:分区,Kafka只保证分区内有序,topic全局无序;分区是并行读写单元
  • Replica副本:1个Leader(读写)+若干Follower(仅同步备份)
  • AR=所有副本;ISR=In-Sync Replicas,和Leader正常同步的副本集合;OSR同步滞后副本
  • ConsumerGroup消费者组:组内多个消费者分摊partition,一个分区只能被组内一个消费者消费;组间互不干扰
  • Offset:消息偏移量,0.9后默认存在内置topic _consumer_offsets,不再依赖ZK

写入流程

  1. producer找partition对应的Leader
  2. 发消息给Leader,写入本地日志
  3. Follower拉取同步,写入本地后回复ACK
  4. Leader收到ISR内所有副本ACK,更新HW高水位,回复producer成功

acks参数(消息丢失重点)

  • acks=0:不等待ACK,吞吐量高,易丢消息
  • acks=1:Leader落盘即返回,Leader挂掉、副本未同步会丢数据
  • acks=-1(all):等待ISR全部副本同步完成,可靠性最高

Kafka为什么快?

  1. PageCache页缓存
  2. 磁盘顺序写
  3. ZeroCopy零拷贝
  4. 消息批量打包Batching
  5. 消费者Pull拉模式,匹配消费能力

消息丢失/重复消费

  • 丢失:acks配置不当、生产者缓冲区满;解决:acks=-1、生产者阻塞不丢弃
  • 重复:网络超时重试、offset提交时机;解决:业务幂等(唯一消息id去重)

Kafka不支持读写分离:主从同步有延迟,读从节点会读到旧数据

四、ELK / EFK

ELK

  • Elasticsearch(ES):分布式检索存储引擎,存日志、全文检索
    节点类型:Master节点(集群调度)、Data数据节点、Client协调节点
  • Logstash:日志采集过滤清洗,JVM消耗大
  • Kibana:可视化Web面板,查询绘图

EFK(替代)

Fluentd(Go开发轻量采集,多用于K8s)替代Logstash
Filebeat:轻量采集器,部署在业务主机,替代Logstash做原始日志采集,性能更好

Logstash输入源:文件、Kafka、MySQL、MongoDB、Redis

五、监控:Prometheus & Zabbix

✅ Prometheus(云原生时序监控,CNCF项目)

  • 模式:Pull拉取,Exporter暴露http指标接口,server定时抓取
  • 核心组件:
    Prometheus Server(抓取+存储+PromQL)、Exporter、Pushgateway(短生命周期任务推送)、Alertmanager(告警去重分组、分发钉钉/邮件)、Grafana可视化
  • 4种指标类型
    • Counter:只增不减(请求总数、错误数)
    • Gauge:瞬时值,可升降(CPU/内存使用率)
    • Histogram:直方图,统计分布、分位数(请求耗时)
    • Summary:直接预计算分位数
  • 工作流:拉取指标→时序存储→告警规则检测→Alertmanager分发告警→Grafana展示

✅ Zabbix(传统企业监控)

  • 架构:Server、Database、WebUI、Proxy(分布式代理)、Agent
  • Agent两种模式:被动(server来拉)、主动(agent上报)
  • 采集方式:Agent、SNMP、IPMI等
  • 核心术语:主机、主机组、Item监控项、Trigger触发器、Event事件、Action动作、模板
  • 分布式:Zabbix Proxy,跨机房、大规模集群分担server压力
  • 监控项:服务器CPU/内存/磁盘/网络/进程;MySQL连接、QPS、主从状态;Web可用性、响应时间

六、Docker

  1. 核心底层技术:Namespace隔离、Cgroups资源限制、UnionFS联合文件系统、rootfs
    Namespace6项隔离:UTS主机名、IPC、PID、Network、Mount、User
  2. Dockerfile / Image / Container
    • Dockerfile:镜像构建脚本
    • Image:只读分层模板(UnionFS)
    • Container:镜像运行实例,顶层读写层;删除容器读写层数据丢失,volumes持久化除外
    • COPY vs ADD:复制本地文件;ADD额外支持自动解压tar、拉取url
    • ENTRYPOINT vs CMD:ENTRYPOINT优先执行,CMD可作为ENTRYPOINT参数;docker run传参优先级最高
  3. 网络5种模式
    bridge(默认)、host、none、container、自定义网络
  4. 持久化:-v数据卷挂载
  5. 跨主机网络:Flannel、Calico
    • Flannel:Overlay隧道封装(VxLAN/UDP),封包解包耗CPU
    • Calico:纯三层BGP路由方案,无overlay封装,性能更好,支持网络策略
  6. Docker Compose:单机容器编排,yaml定义多容器依赖、启停顺序
  7. Harbor:企业私有镜像仓库,基于docker registry封装,UI、RBAC、镜像复制、审计日志

七、Kubernetes(K8s)

1、整体架构

  • Master控制平面:
    kube-apiserver(统一入口、认证鉴权)、etcd(分布式KV存集群元数据)、kube-controller-manager(各类控制器)、kube-scheduler(调度器)
  • Node工作节点:
    kubelet(管理Pod生命周期,和容器引擎交互)、kube-proxy(Service网络代理、负载均衡)、容器引擎docker/containerd

2、核心资源

  • Pod:最小调度单元;一个Pod内容器共享网络、存储;底层pause基础容器,共享namespace、回收僵尸进程;支持init容器(前置初始化,成功后才启动业务容器)
  • Label标签 & LabelSelector标签选择器;Annotation注释
  • Service:固定访问入口,屏蔽Pod动态IP;4种类型
    ClusterIP(集群内部)、NodePort、LoadBalancer、ExternalName
    kube-proxy三种模式:userspace(废弃)、iptables、ipvs(高性能推荐)
    port集群service端口、targetPort容器pod端口、containerPort容器内端口、nodePort宿主机端口
  • Ingress:七层HTTP/HTTPS入口,域名、路径路由;依赖Ingress Controller(如nginx-ingress)
  • Namespace:资源逻辑隔离,默认default、kube-system
  • PV/PVC:持久化存储;PV集群存储资源,PVC是用户存储申请;生命周期Available→Bound→Released→Failed

3、Pod控制器

  • Deployment:无状态应用(nginx),滚动更新/回滚,管理ReplicaSet
  • StatefulSet:有状态应用(mysql、zk),稳定网络标识、持久存储
  • DaemonSet:所有/指定节点运行一个Pod(日志采集、node-exporter)
  • Job:一次性任务;CronJob定时任务

4、Pod配置

  • 重启策略RestartPolicy:Always/OnFailure/Never
  • 镜像拉取策略imagePullPolicy:IfNotPresent默认;Always(latest标签默认);Never
  • 探针Probe
    livenessProbe存活探针:失败杀Pod重启
    readinessProbe就绪探针:失败摘除service后端endpoint
    startupProbe启动探针(慢启动应用)
    探测方式:exec命令、tcpSocket、httpGet
  • Resources request(调度预留)、limit(资源上限),防止资源抢占

5、调度器Scheduler

预选Predicate(过滤不满足节点)→优选Priority打分,选最优节点
污点Taint & 容忍Toleration:节点排斥Pod,Pod可配置容忍调度

6、扩容HPA:Pod水平自动扩缩容,依赖metrics-server采集指标

7、网络CNI:容器网络插件标准;常见Calico、Flannel、Cilium(eBPF)

8、安全:RBAC权限、Secret存放密码密钥、准入控制器AdmissionControl

八、阿里云产品

✅四大件:ECS云服务器、RDS云数据库、SLB负载均衡、OSS对象存储

  • VPC专有网络:隔离私有云上网络,自定义网段、路由、网关,支持混合云
  • CDN:就近边缘节点缓存静态资源,加速、减轻源站压力;CNAME接入、回源机制
  • 弹性伸缩:根据负载自动增减ECS,降成本
  • 安全产品:DDoS高防、安骑士主机安全、SSL证书、堡垒机、态势感知

九、GitLab + Jenkins CI/CD

  1. CI持续集成:开发频繁合并代码到主干,自动构建+自动化测试
  2. CD持续交付:CI基础上自动打包,随时可部署到预发
  3. CD持续部署:交付基础上自动上线生产
  4. 流水线:开发push代码 → GitLab WebHook触发Jenkins → Jenkins拉取代码 → Maven编译打包 → Ansible分发部署
  5. GitLab:企业私有Git仓库,支持MR合并请求、权限管控;GitHub适合开源,私有收费
  6. Jenkins:Java开发CI工具,插件生态丰富,支持分布式slave构建

十、堡垒机(Jumpserver开源)

理念4A:认证、授权、账号、审计
作用:统一运维入口、权限管控、全程操作录像/命令审计、事后溯源
部署:旁路部署,不改动原有网络;支持HA主备VIP
Jumpserver组件:Core管理后台、Coco(SSH/Web终端)、Luna前端、Guacamole实现RDP远程桌面

十一、DevOps

DevOps是文化+流程,打通Dev开发和Ops运维,自动化交付流水线

  • 敏捷:侧重开发迭代、小版本快速交付
  • DevOps:打通开发测试运维,自动化发布、监控反馈
  • CI/CD核心:版本控制→持续集成→持续交付→持续部署
上一篇
下一篇