一、权限与认证相关
1. 项目中RBAC模型的权限设计
我在项目中基于RBAC（基于角色的访问控制）模型，设计了**"用户-角色-权限-资源"四层权限架构**，核心实现如下：
（1）权限粒度划分
- 功能权限：控制接口是否可访问（如订单查询、创建），关联具体接口路径与HTTP方法；
- 数据权限：控制可访问的数据范围（如仅查看自己的订单、查看部门所有订单），基于用户属性/角色做数据过滤。
（2）四层映射关系
| 层级 | 映射关系 | 实现方式 |
|---|---|---|
| 用户与角色 | 多对多（1用户可绑定多角色，1角色可分配给多用户） | 用户-角色关联表 |
| 角色与权限 | 多对多（1角色绑定多权限，1权限可归属多角色） | 角色-权限关联表 |
| 权限与资源 | 一对一/多对一（1权限对应1个资源+HTTP方法，如"订单查询"对应/api/v1/orders+GET） |
权限-资源映射表 |
（3）权限校验流程
- 用户请求接口时，通过JWT解析用户身份，获取绑定的角色列表；
- 基于角色查询对应权限列表，校验当前接口（资源+HTTP方法）是否在权限范围内；
- 功能权限校验通过后，结合数据权限规则过滤返回结果（如仅返回当前用户创建的订单）。
（4）动态调整机制
支持后台手动调整用户角色、角色权限，变更后实时同步至Redis缓存，无需重启服务，保证权限变更即时生效。
2. JWT的核心原理
JWT（JSON Web Token）是无状态身份认证令牌，核心通过加密令牌实现跨服务身份校验，分为结构、签发、验证三大环节：
（1）JWT结构（三部分以.分隔，均为Base64编码）
| 组成部分 | 核心内容 | 作用 |
|---|---|---|
| Header | 声明令牌类型（typ:JWT）、加密算法（如alg:HS256） |
定义令牌解析/加密规则 |
| Payload | 存储非敏感信息：标准字段（exp过期时间、iss签发者）+ 自定义字段（用户ID、角色） | 携带身份/业务标识 |
| Signature | 服务器用Header指定算法+专属密钥，加密Header编码.Payload编码生成签名 |
防止令牌篡改，核心安全层 |
（2）签发流程
用户登录成功 → 服务器生成Payload → 拼接Header+Payload并加密生成Signature → 返回完整JWT令牌。
（3）验证流程
用户携带令牌请求 → 服务器拆分三部分 → 重新计算Signature并比对 → 校验Payload过期时间 → 一致则认证通过（无状态，无需查库）。
二、数据库相关
1. EXPLAIN中type字段的含义
EXPLAIN的type字段表示MySQL查询的访问类型，即数据库查找数据的方式，是判断查询性能的核心指标。从差到优的核心级别如下：
| 级别 | 含义 | 性能 | 典型场景 |
|---|---|---|---|
| ALL | 全表扫描，遍历整张表找数据 | 最差 | 未建索引、索引失效 |
| index | 索引全扫描，遍历整个索引树（无需回表） | 较差 | select count(*) from table |
| range | 索引范围扫描（如></BETWEEN/IN） |
较好 | where id between 1 and 100 |
| ref | 非唯一索引等值扫描 | 良好 | where name = '张三' |
| eq_ref | 唯一索引等值扫描（主键/唯一索引） | 优秀 | where id = 1 |
| const/system | 查询条件为常量，结果缓存为常量 | 最优 | where id = 1（id为主键） |
优化目标 ：尽量将type从ALL/index提升至range/ref/eq_ref，减少全量扫描。
2. MySQL意向锁
意向锁是InnoDB的表级锁 ，核心作用是协调行锁与表锁的关系，避免加表锁时逐行检查行锁状态，提升锁校验效率：
（1）核心类型
- 意向共享锁（IS）：事务获取某行共享锁（S锁）前，需先获取表的IS锁；
- 意向排他锁（IX）：事务获取某行排他锁（X锁）前，需先获取表的IX锁。
（2）核心价值
当事务申请表级锁时，只需判断表的意向锁状态：
- 申请表级S锁：需表无IX锁；
- 申请表级X锁：需表无IS/IX锁；
无需逐行检查行锁，大幅降低锁校验开销。
3. MySQL索引及B+树选型原因
（1）索引核心概念
| 索引类型 | 核心特征 |
|---|---|
| 聚簇索引 | 主键索引，叶子节点存储整行数据，一张表仅1个 |
| 二级索引 | 非主键索引，叶子节点存储主键值，查询需回表 |
| 联合索引 | 多字段组合索引，遵循"最左前缀原则"，仅前缀匹配可触发索引 |
（2）索引选择B+树的原因
B+树适配数据库磁盘IO密集型场景，核心优势：
- 多叉树结构：树高更低（3-4层可存百万级数据），减少磁盘IO次数；
- 数据存储优化：仅叶子节点存储数据（聚簇索引存整行、二级索引存主键），非叶子节点仅存索引键，存储更多索引项；
- 范围查询高效 ：叶子节点通过双向链表连接，支持快速范围遍历（如
ORDER BY/BETWEEN）； - 对比B树：B树非叶子节点存数据，索引键数量少、树高更高，范围查询效率低；
- 对比哈希表：仅支持等值查询，无法支持范围/排序查询，不适用数据库主流场景。
4. MVCC（多版本并发控制）
MVCC是InnoDB实现"可重复读"隔离级别的核心机制，通过存储数据多版本实现无锁并发访问：
（1）核心组件
| 组件 | 作用 |
|---|---|
| 隐藏字段 | DB_TRX_ID（数据最后更新事务ID）、DB_ROLL_PTR（回滚指针，指向undo日志） |
| undo日志 | 存储数据历史版本，用于事务回滚/读取历史版本 |
| read view | 事务启动时生成的快照，包含当前活跃事务ID列表，判断数据版本可见性 |
（2）版本可见性判断规则
- 若
DB_TRX_ID < read view最小活跃事务ID：数据已提交，可见； - 若
DB_TRX_ID > read view最大活跃事务ID：数据未提交，不可见； - 若
DB_TRX_ID在活跃ID范围内且不在活跃列表：数据已提交，可见；否则不可见，通过回滚指针读取undo日志历史版本。
三、中间件相关
1. Kafka Consumer Group（消费者组）
消费者组是一组消费者的集合，核心作用是负载均衡+消费隔离：
（1）核心功能
| 功能 | 具体说明 |
|---|---|
| 负载均衡 | Topic的分区均匀分配给组内消费者，1个分区仅被组内1个消费者消费 |
| 消费隔离 | 不同消费者组独立消费同一Topic，互不干扰（如订单Topic可被物流/财务组同时消费） |
| 故障容错 | 组内消费者数量变化时触发重平衡，重新分配分区，保证消费不中断 |
2. 消费者组内某Consumer挂掉后的处理逻辑
当消费者组内1个Consumer挂掉，剩余Consumer可接管分区，但不会重复消费，流程如下：
- 故障检测：Kafka通过心跳机制（默认3秒）检测消费者状态，心跳超时（默认10秒）判定节点下线；
- 分区重分配：组协调器将故障节点的分区均匀分配给剩余Consumer；
- 消费续跑：接管的Consumer从故障节点最后提交的offset开始消费，无重复（若未提交offset，可能少量重复，通过业务幂等性兜底）。
3. Elasticsearch（ES）核心问题
（1）ES核心用途
| 应用场景 | 具体说明 |
|---|---|
| 日志检索 | 收集系统/业务日志，支持多维度模糊查询，快速定位问题 |
| 全文检索 | 电商商品搜索、文档检索，支持分词/同义词匹配 |
| 数据聚合分析 | 实时统计用户行为、订单数据，生成可视化报表 |
| 时序数据存储 | 结合ELK/EFK栈，存储监控指标、链路追踪数据 |
（2）Keyword与Text字段区别
| 字段类型 | 分词策略 | 检索方式 | 适用场景 | 示例 |
|---|---|---|---|---|
| Keyword | 不分词，按完整字符串存储 | 精确匹配 | 结构化数据（订单号、用户ID） | 检索"无线耳机"仅匹配完全一致值 |
| Text | 按分词器（如IK）拆分词语 | 全文检索/模糊匹配 | 非结构化文本（商品描述、日志） | 检索"无线耳机"可匹配"蓝牙无线耳机" |
4. Redis分布式锁设计
基于Redis实现分布式锁，解决多服务实例并发操作同一资源问题，核心设计：
（1）核心操作
| 操作 | 命令/逻辑 | 说明 |
|---|---|---|
| 加锁 | SET lock_key {唯一标识} NX PX {过期时间} |
NX保证互斥，PX防止死锁 |
| 解锁 | Lua脚本原子操作： if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end |
防止误删其他客户端锁 |
| 续约 | 定时协程在锁过期前执行EXPIRE lock_key {新过期时间} |
适配长耗时任务 |
（2）异常处理
- 服务宕机：锁过期自动释放，无死锁；
- Redis单点故障：引入哨兵机制实现高可用，避免锁服务不可用。
5. Redis防止重复消费
通过"Redis原子校验+业务幂等性"解决重复消费问题，流程如下：
- 生成唯一标识：消息发送时，基于雪花算法生成全局唯一msg_id；
- 消费前校验 ：调用
SET msg_id 1 NX EX 86400，成功则未消费，失败则已消费（直接丢弃）； - 业务幂等兜底：即使Redis校验失效，业务层通过订单号/用户ID做幂等校验（如支付接口先查订单状态）。
6. Kafka消费者分组优化
针对消费者分组负载不均、消息堆积问题，优化方案如下：
| 优化方向 | 具体措施 |
|---|---|
| 分区均匀分配 | 调整消费者数量与Topic分区数一致，采用RangeAssignor策略均分分区 |
| 消费能力监控 | 接入监控系统，实时监控消费速度/堆积量，异常时自动触发分区重分配 |
| 批量/异步消费 | 开启批量拉取（fetch.min.bytes），异步处理消息，提升消费吞吐量 |
四、容器化相关
1. Docker核心认知
Docker是轻量级容器化技术，核心价值是"一次构建、处处运行"：
（1）核心优势
- 隔离性：基于namespace实现资源隔离，容器间互不干扰；
- 轻量性：基于cgroups限制资源，无虚拟化层，资源占用低；
- 便捷性：镜像打包应用+依赖，部署无需适配环境。
（2）核心应用
将Go微服务打包为Docker镜像，通过Docker Compose实现多服务本地编排。
2. Kubernetes（K8s）核心认知
K8s是容器编排平台，用于管理大规模Docker集群，核心组件与能力：
（1）核心组件
| 组件类型 | 核心组件 | 作用 |
|---|---|---|
| 控制平面 | API Server | 集群统一入口，处理所有请求 |
| Scheduler | 负责Pod调度，分配至合适节点 | |
| Controller Manager | 管理控制器（如Deployment/StatefulSet），保障集群状态 | |
| etcd | 集群数据存储（配置、状态） | |
| 节点组件 | kubelet | 管理节点上的Pod，与控制平面交互 |
| kube-proxy | 实现Service网络代理，转发请求至Pod |
（2）核心能力
- Pod调度：基于节点资源自动分配Pod；
- 服务发现：通过Service为Pod提供稳定访问入口；
- 自动扩缩容：基于监控指标调整Pod数量；
- 故障自愈：Pod/节点故障时自动重启/迁移。
3. Docker常用命令（分类整理）
（1）镜像操作
| 命令 | 用途 | 示例 |
|---|---|---|
docker pull [image]:[tag] |
拉取镜像 | docker pull nginx:1.25 |
docker build -t [name]:[tag] . |
构建镜像 | docker build -t myapp:v1 . |
docker images |
查看本地镜像 | - |
docker rmi [image_id] |
删除镜像 | docker rmi 123456 |
（2）容器操作
| 命令 | 用途 | 示例 |
|---|---|---|
docker run -d -p 主机端口:容器端口 --name 名称 镜像 |
启动容器 | docker run -d -p 8080:80 --name nginx nginx:1.25 |
docker ps |
查看运行中容器 | - |
docker exec -it [容器ID] /bin/bash |
进入容器终端 | docker exec -it 123456 /bin/bash |
docker logs -f [容器ID] |
实时查看容器日志 | docker logs -f 123456 |
docker stop [容器ID] |
停止容器 | docker stop 123456 |
docker rm [容器ID] |
删除容器 | docker rm 123456 |
（3）其他常用
| 命令 | 用途 |
|---|---|
docker-compose up -d |
启动多容器应用 |
docker network ls |
查看Docker网络 |
docker stats |
查看容器资源占用 |