# 软考软件设计师题目总结（第64期·大数据架构与中间件深度实战版）

原创于 2026-08-23 00:00:00 发布 · 245 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

PaaS(Platform as a Service)

IO(Input/Output InputStream)

ABSD(Software Architecture)

软考软件设计师题目总结（第64期·大数据架构与中间件深度实战版）

生成时间: 2026年8月14日 13:42 | 随机编号: 5338
距下半年考试: 约71天（10月24-27日·机考）
本期主题: 大数据计算框架Spark与Flink + 分布式缓存Redis与一致性 + 消息队列Kafka深度 + 考前综合冲刺模拟

一、2026下半年考情速递（第64期·71天冲刺版）

1.1 关键考试信息

项目	详情
考试时间	2026年10月24-27日（机考·科目连考240分钟）
合格标准	两科均≥45分，一次性通过，无单科保留
备考倒计时	约71天
报名窗口	8月中旬至9月中旬，属地原则报考
教材大纲	沿用2025版大纲，2026年5月已考过一次
上机环境	全国统一上机，VS Code类编辑器+考试系统

1.2 本期四大主题锁定方向

主题	解决痛点	适合人群
大数据计算框架Spark与Flink	MapReduce/Spark/Flink辨析不清、RDD/DStream/DataStream概念混淆	大数据/后端方向考生
分布式缓存Redis与一致性	Redis数据类型混淆、持久化RDB/AOF区别、缓存三大问题不会分析	后端/架构方向考生
消息队列Kafka深度	分区/副本/ISR概念模糊、消费者组与消费语义不清	分布式/中间件方向考生
考前综合冲刺模拟	知识点零散、下午案例答题模板不熟、计算题步骤不清晰	全体考生

1.3 五大命题新趋势（71天冲刺研判）

大数据生态成为架构设计必考背景：MapReduce→Spark→Flink演进路线、批处理与流处理辨析、RDD弹性分布式数据集概念是高频考点
Redis缓存模式与一致性：缓存穿透/击穿/雪崩三连问、Cache-Aside vs Write-Through、CAP定理在缓存选型中的应用是2026热门方向
Kafka作为分布式消息系统：分区副本机制、ISR同步副本、消费者组Rebalance、Exactly-Once语义是中间件深度考察核心
数据一致性与分布式事务：两阶段提交2PC、三阶段提交3PC、Saga补偿、TCC模式在消息系统中的应用是综合案例高频
考前综合模拟：近5年真题高频考点回炉、下午案例六大题型模板化训练、计算题八大类型步骤化速解

二、大数据计算框架Spark与Flink ⭐⭐⭐⭐⭐

2.1 大数据处理范式演进

MapReduce（2004 Google）
    ↓ 痛点：磁盘IO密集、迭代慢
Spark（2010 UC Berkeley）
    ↓ 痛点：批处理为主、流处理微批延迟
Flink（2014 Apache）
    → 真正流优先（Streaming First）

批处理 vs 流处理：

维度	批处理（Batch）	流处理（Stream）
数据	有界数据集（静态）	无界数据流（实时）
延迟	分钟~小时级	毫秒~秒级
模型	Map→Shuffle→Reduce	事件驱动、窗口聚合
代表	Hadoop MapReduce、Spark Batch	Flink、Spark Streaming
场景	ETL、离线报表	实时风控、实时推荐

2.2 Hadoop MapReduce核心

MapReduce两阶段：

Map阶段：输入分片→并行处理→输出键值对→分区排序
Reduce阶段：Shuffle汇总→聚合计算→输出结果

[Input Split] → [Map] → [Shuffle & Sort] → [Reduce] → [Output]
     128MB        并行        网络传输         聚合       HDFS

核心概念：

InputFormat：定义输入分片（默认TextInputFormat，128MB/片）
Mapper：每条记录调用一次map()
Partitioner：决定键发往哪个Reducer（默认HashPartitioner）
Combiner：Map端本地预聚合（减少Shuffle数据量）
Reducer：Shuffle后按键聚合

Shuffle代价：MapReduce最大瓶颈是Shuffle阶段的磁盘IO和网络传输。

2.3 Spark核心架构

Spark vs MapReduce核心优势：

内存计算：中间结果存内存，比MapReduce快10~100倍
RDD弹性分布式数据集：不可变、分区、容错、惰性求值
DAG调度：任务编排为有向无环图，避免多阶段磁盘IO

Spark架构组件：

┌──────────────────────────────────────┐
│            Driver（驱动器）            │
│  ┌─ SparkContext                     │
│  └─ DAGScheduler → TaskScheduler     │
└───────────┬──────────────────────────┘
            │ 分发任务
    ┌───────┼───────┐
    ↓       ↓       ↓
┌──────┐┌──────┐┌──────┐
│Worker││Worker││Worker│  (Executor中运行Task)
│Exec  ││Exec  ││Exec  │
└──────┘└──────┘└──────┘

RDD（Resilient Distributed Dataset）五大特性：

分区列表（Partitions）：数据分布在多个节点
计算函数（Compute）：每个分区的计算逻辑
依赖关系（Dependencies）：RDD之间的 lineage
分区器（Partitioner）：可选，决定数据分布
首选位置（Preferred Locations）：数据本地性优化

RDD依赖类型：

窄依赖（Narrow）：父分区一一对应子分区（map、filter）
宽依赖（Wide/Shuffle）：父分区被多个子分区依赖（groupByKey、reduceByKey）

Spark算子分类：

类型	特点	代表算子
Transformation（转换）	惰性求值，不立即执行	map、filter、flatMap、reduceByKey、join
Action（行动）	触发DAG执行	collect、count、saveAsTextFile、take

WordCount示例（Spark）：

sc.textFile("hdfs://input")
  .flatMap(lambda line: line.split(" "))
  .map(lambda word: (word, 1))
  .reduceByKey(lambda a, b: a + b)
  .saveAsTextFile("hdfs://output")

2.4 Spark Streaming vs Flink

Spark Streaming（微批处理）：

将流数据切分为小批次（batch interval，如1秒）
每批用Spark Core处理
DStream（Discretized Stream）：连续RDD序列
延迟：秒级

Structured Streaming（Spark 2.x+）：

基于DataFrame/SQL的流处理API
将流视为无界表，持续追加查询
支持事件时间窗口、水位线

Flink（真流处理）：

事件驱动：逐条事件处理，延迟毫秒级
DataStream API：底层流处理API
Table API/SQL：声明式流批统一
状态管理：内置状态后端（MemoryStateBackend、FsStateBackend、RocksDBStateBackend）
Checkpoint机制：基于Chandy-Lamport算法的分布式快照

核心对比：

维度	Spark Streaming	Flink
模型	微批（Mini-Batch）	事件驱动（Event-by-Event）
延迟	秒级	毫秒级
API	DStream/Structured	DataStream/Table/SQL
状态	有限	原生强大（Operator State/Keyed State）
时间语义	处理时间为主	事件时间+水位线+处理时间
容错	WAL/Checkpoint	Checkpoint（Chandy-Lamport）
窗口	滚动/滑动	滚动/滑动/会话/全局

2.5 Flink核心概念深度

时间语义（Time Semantics）：

类型	定义	场景
Event Time	事件实际发生时间（数据自带时间戳）	最准确，推荐使用
Ingestion Time	数据进入Flink的时间	折中方案
Processing Time	处理该事件的系统时间	最简单，但不确定

Watermark（水位线）：

机制：表示"此时间戳之前的所有数据都应该已到达"
作用：解决事件时间窗口中的乱序数据问题
公式：Watermark = MaxTimestamp - AllowedLateness

窗口类型：

窗口	行为	场景
Tumbling Window（滚动）	不重叠、不间隔	每分钟统计PV
Sliding Window（滑动）	可重叠	最近5分钟每1分钟统计
Session Window（会话）	基于活跃间隔	用户会话分析
Global Window（全局）	全局，需自定义Trigger	自定义触发

Checkpoint容错机制：

1. JobManager周期性向Source注入Checkpoint Barrier
2. Barrier随数据流向下传播
3. 算子收到Barrier后对齐（Aligned Checkpoint）
4. 将状态快照持久化到StateBackend
5. 全部完成后JobManager确认Checkpoint完成

Exactly-Once语义实现：

Source支持可重放（Kafka offset记录在Checkpoint中）
Sink支持两阶段提交（Two-Phase Commit）
Checkpoint成功后提交事务，保证端到端精确一次

2.6 大数据框架精选真题（5道）

Q1：Spark的核心数据结构RDD是（）
A. Resilient Distributed Dataset
B. Relational Data Dictionary
C. Remote Data Daemon
D. Replicated Data Disk
答案：A | RDD=弹性分布式数据集。

Q2：下列关于Spark和MapReduce的说法，错误的是（）
A. Spark基于内存计算，比MapReduce快
B. Spark使用DAG调度，MapReduce只有Map和Reduce两阶段
C. MapReduce的Shuffle比Spark更高效
D. Spark支持迭代计算，适合机器学习
答案：C | MapReduce的Shuffle是磁盘IO密集的瓶颈，Spark更高效。

Q3：Flink与Spark Streaming的核心区别是（）
A. Flink用Java，Spark用Scala
B. Flink是真流处理（事件驱动），Spark Streaming是微批处理
C. Flink不支持SQL
D. Spark不支持状态管理
答案：B | Flink逐条事件处理，Spark Streaming切批处理。

Q4：Flink中处理乱序事件使用的时间语义是（）
A. Processing Time
B. Ingestion Time
C. Event Time + Watermark
D. System Time
答案：C | Event Time + Watermark解决乱序问题。

Q5：Spark中触发DAG执行的算子类型是（）
A. Transformation
B. Action
C. Cache
D. Persist
答案：B | Action算子（如collect、count）触发执行。

三、分布式缓存Redis与一致性 ⭐⭐⭐⭐⭐

3.1 Redis核心数据结构

五大基础类型 + 三大扩展类型：

类型	说明	典型场景	底层实现
String	字符串/数字	缓存、计数器、分布式锁	SDS（Simple Dynamic String）
List	有序列表	消息队列、最新动态	QuickList（ZipList + LinkedList）
Hash	哈希表	对象存储	ListPack / HashTable
Set	无序集合	标签、去重	IntSet / HashTable
ZSet	有序集合	排行榜、延迟队列	ListPack + SkipList
Stream	流（5.0+）	消息队列（消费者组）	Radix Tree
Bitmap	位图	布隆过滤器、签到	String扩展
GeoHash	地理位置	附近搜索	ZSet扩展

3.2 Redis持久化机制

RDB（Redis Database）vs AOF（Append Only File）：

维度	RDB	AOF
原理	定时快照，二进制dump	追加写入每条命令
文件	compact .rdb文件	.aof文本文件
恢复速度	快（直接加载）	慢（重放命令）
数据安全	可能丢失最后一次快照后的数据	最多丢1秒（everysec策略）
触发	save/bgsave（fork子进程）	always/everysec/no
适合	备份、灾难恢复	数据安全性要求高

AOF三种刷盘策略：

always：每条命令都刷盘，最安全但最慢
everysec（默认）：每秒刷盘，平衡安全与性能
no：由OS决定，最快但最不安全

AOF重写（Rewrite）：当AOF文件过大时，fork子进程将当前内存状态重新生成最小命令集，减少文件体积。

Redis 4.0+ 混合持久化：RDB快照 + 增量AOF命令，兼顾恢复速度与数据安全。

3.3 Redis内存管理与淘汰策略

最大内存配置：maxmemory 参数限制Redis可用内存。

8种淘汰策略：

策略	范围	规则
noeviction	-	不淘汰，写入报错（默认）
allkeys-lru	所有键	淘汰最久未使用
allkeys-lfu	所有键	淘汰最少使用（4.0+）
allkeys-random	所有键	随机淘汰
volatile-lru	设了TTL的键	淘汰最久未使用
volatile-lfu	设了TTL的键	淘汰最少使用
volatile-random	设了TTL的键	随机淘汰
volatile-ttl	设了TTL的键	淘汰最快过期的

3.4 Redis集群架构

主从复制（Master-Slave）：

[Master] ──(全量+增量)──→ [Slave1]
         ──(全量+增量)──→ [Slave2]

全量同步：Master执行BGSAVE生成RDB，发送给Slave
增量同步：通过offset和replid复制积压缓冲区

哨兵模式（Sentinel）：

监控Master/Slave存活状态
Master宕机时自动选举新Master
通知客户端新Master地址

Redis Cluster（分片集群）：

16384个哈希槽（Hash Slot）：slot = CRC16(key) % 16384
每个节点负责一部分槽
去中心化：Gossip协议节点间通信
容错：每个主节点配至少1个从节点，主节点宕机由从节点接管

3.5 缓存三大经典问题

缓存穿透（Cache Penetration）：

现象：查询不存在的数据，缓存和DB都没有，每次都打到DB
原因：恶意攻击查询不存在的ID
解决：
- 缓存空值（NULL，设短TTL）
- 布隆过滤器（Bloom Filter）拦截不存在的key

缓存击穿（Cache Breakdown）：

现象：热点key过期瞬间，大量并发请求打到DB
原因：热点数据过期 + 高并发
解决：
- 互斥锁（Mutex Lock）：只允许一个线程回源DB
- 热点key永不过期（逻辑过期 + 异步刷新）

缓存雪崩（Cache Avalanche）：

现象：大量key同时过期，DB瞬间压力暴增
原因：批量缓存同时失效 / Redis宕机
解决：
- TTL加随机值避免同时过期
- 多级缓存（L1本地 + L2 Redis）
- 熔断降级保护DB

三问题对比：

问题	本质	触发条件	核心解法
穿透	查不存在的	数据不存在	空值/布隆过滤器
击穿	热点过期	热点key过期	互斥锁/永不过期
雪崩	大量过期	批量key同时过期	TTL随机+多级缓存

3.6 缓存一致性策略

Cache-Aside（旁路缓存，最常用）：

读：先查缓存 → 命中返回 / 未命中查DB → 写入缓存 → 返回
写：更新DB → 删除缓存（而非更新缓存）

Write-Through（穿透写入）：

写操作同时写缓存和DB（缓存层负责同步）
数据强一致，但写入延迟高

Write-Behind（异步写入）：

写操作只写缓存，异步刷入DB
写入快，但有一致性窗口

为什么删缓存而非更新缓存？

避免并发写导致缓存与DB不一致
有些缓存值计算复杂，更新代价大
懒加载：下次读时再加载最新值

延迟双删策略：

1. 删除缓存
2. 更新DB
3. 延迟N毫秒后再次删除缓存

解决"先删缓存再更新DB"期间有读请求把旧值写回缓存的问题。

3.7 CAP定理与BASE理论

CAP定理：分布式系统最多同时满足两个：

C（Consistency）一致性：所有节点同一时刻数据一致
A（Availability）可用性：每个请求都能收到响应
P（Partition Tolerance）分区容错：网络分区时系统仍能运行

选择：P必选（网络分区不可避免），所以只能在CP和AP之间选择：

CP：Redis Cluster（写一致性优先）
AP：Cassandra、DynamoDB（可用性优先）

BASE理论（CAP的AP延伸）：

B（Basically Available）基本可用：允许损失部分可用性
S（Soft State）软状态：允许中间状态存在
E（Eventually Consistent）最终一致性：不要求强一致，最终一致即可

3.8 Redis精选真题（5道）

Q1：Redis中用于排行榜的数据结构是（）
A. List
B. Hash
C. Set
D. ZSet（Sorted Set）
答案：D | ZSet有序集合自带排序，排行榜首选。

Q2：缓存穿透的常见解决方案是（）
A. 增大TTL
B. 缓存空值或布隆过滤器
C. 使用多级缓存
D. 关闭缓存
答案：B | 空值缓存和布隆过滤器是穿透标准解法。

Q3：Redis Cluster的哈希槽数量是（）
A. 1024
B. 4096
C. 16384
D. 65536
答案：C | Redis Cluster有16384个Hash Slot。

Q4：Redis持久化中，RDB相比AOF的主要优势是（）
A. 数据更安全
B. 恢复速度更快
C. 文件更大
D. 支持更多数据类型
答案：B | RDB是二进制快照，恢复速度远快于AOF命令重放。

Q5：Cache-Aside模式中，更新数据后应该（）
A. 更新缓存
B. 删除缓存
C. 不操作缓存
D. 刷新缓存TTL
答案：B | 删除缓存避免并发不一致，下次读时懒加载。

四、消息队列Kafka深度 ⭐⭐⭐⭐⭐

4.1 Kafka核心架构

┌─────────────────────────────────────────────────────┐
│                  Kafka Cluster                       │
│                                                      │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐             │
│  │ Broker0 │  │ Broker1 │  │ Broker2 │   ...        │
│  │ (P0-Lead│  │ (P1-Lead│  │ (P2-Lead│             │
│  │  er)    │  │  er)    │  │  er)    │             │
│  │ (P1-Foll│  │ (P2-Foll│  │ (P0-Foll│             │
│  │  ower)  │  │  ower)  │  │  ower)  │             │
│  └─────────┘  └─────────┘  └─────────┘             │
│       ↑            ↑            ↑                    │
│       └────── ZooKeeper / KRaft ──────┘             │
│              (集群元数据管理)                         │
└─────────────────────────────────────────────────────┘
     ↑ Producer                    ↓ Consumer Group
     (生产者)                      (消费者组)

核心概念：

概念	说明
Broker	Kafka服务器节点
Topic	消息主题，逻辑分类
Partition	分区，Topic的物理分片，并行单位
Replica	副本，每个Partition有多个副本
Producer	生产者，发布消息
Consumer	消费者，订阅消息
Consumer Group	消费者组，组内每分区只被一个消费者消费
Offset	消费位移，消费者在分区中的位置
ZooKeeper/KRaft	集群协调与元数据管理

4.2 分区（Partition）机制

为什么分区？

水平扩展：多Broker分担数据
并行消费：每个分区可被独立消费
有序性保证：单分区内消息有序

分区策略：

指定Partition：直接发送到指定分区
指定Key：hash(key) % partitionCount，相同Key到同一分区
无Key轮询：Round-Robin轮询分配（默认）
Sticky：黏性分区，尽量复用同一批次分区

分区数量选择：

经验值：Broker数 × 消费者数（保证负载均衡）
过少：并行度不足
过多：元数据开销大，Leader选举慢

4.3 副本（Replica）与ISR

副本类型：

Leader Replica：处理所有读写请求
Follower Replica：从Leader同步数据，不直接服务客户端

ISR（In-Sync Replicas）：

与Leader保持同步的副本集合
Follower延迟超过replica.lag.time.max.ms会被踢出ISR
只有ISR中的副本才有资格被选为新Leader

HW（High Watermark）与LEO：

LEO（Log End Offset）：每个副本的日志末端位移（下一条写入位置）
HW（High Watermark）：所有ISR中最小的LEO，即已安全复制的位移
消费者只能消费HW之前的消息（保证一致性）

Leader:   [0] [1] [2] [3] [4] [5]    LEO=6
Follower1:[0] [1] [2] [3] [4]        LEO=5
Follower2:[0] [1] [2] [3]            LEO=4
                     ↑
                    HW=4（ISR中最小LEO）
          消费者可消费范围: [0]~[3]

4.4 消费者组与Rebalance

消费者组（Consumer Group）：

同一组内：一个分区只被一个消费者消费（保证不重复）
不同组间：各自独立消费全量消息（广播模式）

Rebalance触发条件：

消费者加入组（新实例启动）
消费者离开组（宕机/主动退出）
订阅的Topic分区数变化
消费者心跳超时（session.timeout.ms）

Rebalance分区分配策略：

策略	说明
RangeAssignor	按分区范围分配（默认）
RoundRobinAssignor	轮询分配
StickyAssignor	黏性分配，尽量保持原有分配不变
CooperativeStickyAssignor	协作式黏性（增量Rebalance，Kafka 2.4+）

Rebalance问题：

Stop-The-World：Rebalance期间所有消费者暂停消费
频繁Rebalance：导致消费延迟
优化：合理设置心跳间隔、使用CooperativeStickyAssignor

4.5 消息投递语义

三种语义：

语义	说明	实现方式
At-Most-Once	最多一次，可能丢	发后不管，自动提交offset
At-Least-Once	至少一次，可能重复	手动提交offset + 重试
Exactly-Once	精确一次	幂等Producer + 事务

幂等Producer（Idempotent Producer）：

Producer分配PID（Producer ID）
每条消息带Sequence Number
Broker根据<PID, Partition, SeqNum>去重
配置：enable.idempotence=true

Kafka事务：

跨分区原子写入
配置：transactional.id=xxx
API：beginTransaction() → send() → commitTransaction()

消费者端Exactly-Once：

消费offset与业务处理在同一事务中提交
Kafka Connect Sink + 事务性Sink（如数据库事务）

4.6 Kafka高吞吐设计

设计	说明
顺序写磁盘	追加写入，磁盘顺序写速度≈内存随机写
PageCache	利用OS页缓存，减少磁盘IO
Zero-Copy	sendfile系统调用，数据从内核态直接到网卡
批量发送	Producer批量累积后发送，减少网络请求
压缩	Snappy/LZ4/Gzip/Zstd，减少网络传输量
分区并行	多分区并行读写

4.7 Kafka vs RabbitMQ vs RocketMQ

维度	Kafka	RabbitMQ	RocketMQ
模型	Partition+Log	Queue+Exchange	Topic+Queue
吞吐	百万级/秒	万级/秒	十万级/秒
延迟	毫秒级	微秒级	毫秒级
顺序	分区内有序	队列内有序	分区内有序
持久化	日志文件	内存/磁盘	CommitLog
事务	支持	不支持	支持
场景	日志/大数据	企业应用	金融/电商

4.8 Kafka精选真题（5道）

Q1：Kafka中，一个消费者组内的消费者数量超过分区数量时（）
A. 所有消费者都能消费
B. 多余的消费者空闲
C. 分区会被重新分配
D. 报错
答案：B | 一个分区只能被组内一个消费者消费，多余消费者空闲。

Q2：Kafka的ISR是指（）
A. 消息索引
B. 与Leader保持同步的副本集合
C. 消费者组
D. 分区分配器
答案：B | ISR=In-Sync Replicas，同步副本集。

Q3：Kafka消费者只能消费到HW之前的消息，HW是（）
A. 分区最大offset
B. 所有ISR中最小的LEO
C. 消费者最大offset
D. 日志文件大小
答案：B | HW=High Watermark=ISR中最小LEO。

Q4：Kafka实现Exactly-Once语义依赖（）
A. 自动提交offset
B. 幂等Producer + 事务
C. 增加副本数
D. 压缩消息
答案：B | 幂等Producer去重 + 事务保证原子写入。

Q5：Kafka高吞吐的核心设计不包括（）
A. 顺序写磁盘
B. Zero-Copy
C. 批量发送
D. 强一致性同步复制
答案：D | Kafka用异步复制（ISR机制），非强一致性同步复制。

五、考前综合冲刺模拟（第64期）

5.1 20道上午精选真题（全科目覆盖）

Q1：Spark RDD的依赖关系中，groupByKey产生的是（）
A. 窄依赖
B. 宽依赖
C. 无依赖
D. 循环依赖
答案：B | groupByKey需要Shuffle，产生宽依赖。

Q2：Redis默认的AOF刷盘策略是（）
A. always
B. everysec
C. no
D. never
答案：B | everysec每秒刷盘，平衡性能与安全。

Q3：Kafka中，相同Key的消息会被发送到（）
A. 随机分区
B. 同一分区
C. 所有分区
D. 指定分区
答案：B | hash(key)%partitionCount，相同Key到同一分区。

Q4：下列不属于Redis缓存三大问题的是（）
A. 缓存穿透
B. 缓存击穿
C. 缓存雪崩
D. 缓存溢出
答案：D | 三大问题是穿透/击穿/雪崩。

Q5：Flink的Checkpoint机制基于的算法是（）
A. Paxos
B. Raft
C. Chandy-Lamport
D. Two-Phase Commit
答案：C | Chandy-Lamport分布式快照算法。

Q6：MapReduce的Shuffle阶段发生在（）
A. Map之前
B. Map之后、Reduce之前
C. Reduce之后
D. 整个过程
答案：B | Shuffle连接Map输出和Reduce输入。

Q7：Redis中，SETNX命令的核心用途是（）
A. 设置过期时间
B. 分布式锁
C. 发布订阅
D. 事务
答案：B | SETNX=Set if Not eXists，用于实现分布式锁。

Q8：Kafka的Zero-Copy使用了哪个系统调用（）
A. read + write
B. mmap
C. sendfile
D. splice
答案：C | Kafka用sendfile实现Zero-Copy。

Q9：CAP定理中，Redis Cluster的选择是（）
A. CP
B. AP
C. CA
D. CAP都满足
答案：A | Redis Cluster优先一致性（CP）。

Q10：Spark的惰性求值意味着（）
A. Transformation不立即执行
B. Action不立即执行
C. 所有操作都延迟执行
D. 不支持缓存
答案：A | Transformation惰性求值，Action触发执行。

Q11：布隆过滤器可以用于解决（）
A. 缓存击穿
B. 缓存穿透
C. 缓存雪崩
D. 缓存预热
答案：B | 布隆过滤器拦截不存在的key，解决穿透。

Q12：Kafka消费者提交offset的方式中，可能导致重复消费的是（）
A. 自动提交
B. 手动同步提交
C. 手动异步提交，在处理完成后提交
D. 不提交
答案：A | 自动提交可能在处理完成前提交，重启后重复消费。

Q13：Flink中Session Window的特点是（）
A. 固定大小
B. 基于活跃间隔动态创建
C. 可重叠
D. 不关闭
答案：B | Session Window基于会话活跃间隔动态创建和关闭。

Q14：Redis的过期键删除策略是（）
A. 定时删除
B. 惰性删除
C. 定期删除 + 惰性删除
D. 不删除
答案：C | Redis采用定期删除+惰性删除组合策略。

Q15：下列关于BASE理论的说法，正确的是（）
A. 要求强一致性
B. 最终一致性即可
C. 不允许中间状态
D. 与CAP矛盾
答案：B | BASE是AP延伸，允许最终一致性。

Q16：Kafka中，当Leader副本所在Broker宕机时（）
A. 所有消息丢失
B. 从ISR中选举新Leader
C. 分区不可用
D. 消费者报错
答案：B | 从ISR中选举新Leader，保证可用性。

Q17：Spark Standalone模式中，Worker的作用是（）
A. 提交作业
B. 管理Executor进程
C. 存储数据
D. 调度任务
答案：B | Worker负责管理节点上的Executor。

Q18：Redis Sentinel的功能是（）
A. 数据分片
B. 自动故障转移
C. 持久化
D. 发布订阅
答案：B | Sentinel监控+自动故障转移。

Q19：Kafka消息的存储方式是（）
A. 关系型数据库
B. 追加写日志文件
C. 内存队列
D. 哈希表
答案：B | Kafka消息以追加写方式存储在日志文件中。

Q20：下列关于分布式事务2PC的说法，错误的是（）
A. 存在阻塞问题
B. 协调者宕机可能导致参与者阻塞
C. 能保证最终一致性
D. 两阶段：准备+提交
答案：C | 2PC保证强一致性，非最终一致性；且存在同步阻塞问题。

5.2 20大可能考点预测（第64期押题）

#	考点	重要度	出现形式
1	MapReduce vs Spark vs Flink辨析	⭐⭐⭐⭐⭐	选择题
2	RDD五大特性+窄/宽依赖	⭐⭐⭐⭐⭐	选择题
3	Spark Transformation vs Action	⭐⭐⭐⭐⭐	选择题
4	Flink Event Time + Watermark	⭐⭐⭐⭐	选择题
5	Flink Checkpoint容错机制	⭐⭐⭐⭐	选择题
6	Redis五大数据类型+场景	⭐⭐⭐⭐⭐	选择+案例
7	Redis RDB vs AOF持久化	⭐⭐⭐⭐⭐	选择题
8	Redis 8种淘汰策略	⭐⭐⭐⭐	选择题
9	缓存穿透/击穿/雪崩三连问	⭐⭐⭐⭐⭐	选择+案例
10	Cache-Aside一致性策略	⭐⭐⭐⭐⭐	选择题
11	Redis Cluster哈希槽	⭐⭐⭐⭐	选择题
12	CAP定理+BASE理论	⭐⭐⭐⭐⭐	选择题
13	Kafka分区+副本机制	⭐⭐⭐⭐⭐	选择题
14	ISR + HW + LEO	⭐⭐⭐⭐⭐	选择题
15	消费者组+Rebalance	⭐⭐⭐⭐	选择题
16	Kafka三种投递语义	⭐⭐⭐⭐⭐	选择题
17	幂等Producer+事务	⭐⭐⭐⭐	选择题
18	Kafka高吞吐设计	⭐⭐⭐⭐	选择题
19	2PC/3PC/Saga/TCC分布式事务	⭐⭐⭐⭐	选择+案例
20	Kafka vs RabbitMQ vs RocketMQ	⭐⭐⭐	选择题

5.3 下午案例综合模拟：电商订单实时处理系统

场景描述：
某电商平台需要构建实时订单处理系统，要求：

订单消息通过Kafka传输
使用Flink进行实时流处理（计算每分钟订单量、异常检测）
使用Redis缓存热门商品信息和用户会话
使用Spark进行离线T+1报表分析

问题1：Kafka Topic分区设计

订单量约10万/秒，需要多少分区？
如何保证同一用户的订单到同一分区？

参考答案：

分区数 = min(预期吞吐/单分区吞吐, Broker数×消费者数)
单分区写入约10MB/s，10万订单×200B=20MB/s → 至少2~3分区
考虑消费者并行度，设8~16分区
以userId为Key，hash(userId)%partitionCount保证同用户同分区

问题2：Redis缓存设计

热门商品信息如何缓存？TTL如何设置？
如何防止缓存击穿？

参考答案：

使用Hash结构存储商品信息，TTL设30分钟
防击穿：热点商品用互斥锁（SETNX+过期时间），只允许一个请求回源DB
布隆过滤器防穿透

问题3：Flink实时处理设计

如何处理乱序到达的订单？
如何保证Exactly-Once？

参考答案：

使用Event Time + Watermark（允许延迟5秒）处理乱序
Checkpoint间隔1秒，状态存RocksDB
Sink使用两阶段提交（Kafka事务或数据库事务）

5.4 计算题速解模板

1. Kafka分区吞吐计算

总吞吐 = 单分区吞吐 × 分区数
单分区写入吞吐 ≈ 10MB/s（经验值）
需求：100MB/s → 分区数 = 100/10 = 10个

2. Redis内存估算

单条KV：key(20B) + value(200B) + 元数据(50B) ≈ 270B
1亿条：270B × 10^8 = 27GB
加20%碎片：27 × 1.2 = 32.4GB

3. Spark Shuffle数据量

Map输出 = 输入数据量 × 选择率
Shuffle数据量 = Map输出 × (1 - Combiner压缩率)

4. Flink Watermark计算

Watermark = MaxEventTime - MaxOutOfOrderness
例：最大事件时间=10:00:05，允许乱序=5s
Watermark = 10:00:00
窗口[10:00:00, 10:00:10)在Watermark≥10:00:10时触发

5. Kafka消费者延迟计算

消费延迟 = 最新Offset - 已提交Offset
滞后量 = Lag
消费速率 = (处理Offset差 / 时间差)
预计追上时间 = Lag / 消费速率

六、25个专业英语高频术语（第64期）

#	术语	中文	简释
1	RDD	弹性分布式数据集	Spark核心数据抽象
2	DAG	有向无环图	Spark任务调度模型
3	Shuffle	洗牌	Map到Reduce的数据传输
4	Watermark	水位线	Flink处理乱序事件
5	Checkpoint	检查点	分布式状态快照
6	Event Time	事件时间	数据实际发生时间
7	Processing Time	处理时间	系统处理时间
8	Partition	分区	Kafka并行单位
9	Replica	副本	分区数据副本
10	ISR	同步副本集	与Leader同步的副本
11	Offset	位移	消费位置标记
12	Consumer Group	消费者组	组内分区唯一消费
13	Leader	主副本	处理读写的副本
14	Follower	从副本	同步Leader的副本
15	LEO	日志末端位移	下一条写入位置
16	HW	高水位	ISR最小LEO
17	Rebalance	再均衡	消费者组分区重分配
18	Exactly-Once	精确一次	投递语义
19	Zero-Copy	零拷贝	内核态直接传输
20	PageCache	页缓存	OS文件缓存
21	Cache-Aside	旁路缓存	读缓存模式
22	Penetration	穿透	查不存在的数据
23	Avalanche	雪崩	大量key同时过期
24	CAP	CAP定理	一致性/可用性/分区容错
25	BASE	BASE理论	基本可用/软状态/最终一致

七、公式速记卡（12条）

#	公式	含义
1	slot = CRC16(key) % 16384	Redis Cluster哈希槽
2	HW = min(LEO of ISR)	Kafka高水位
3	Watermark = MaxEventTime - MaxLateness	Flink水位线
4	消费延迟 = LatestOffset - CommittedOffset	Kafka Lag
5	吞吐 = 单分区吞吐 × 分区数	Kafka总吞吐
6	Error Budget = 1 - SLO	错误预算
7	hash(key) % partitionCount	Kafka分区路由
8	单条KV内存 ≈ key + value + 元数据	Redis内存估算
9	LEO = 最后一条消息Offset + 1	Kafka日志末端
10	Rebalance时间 ≀ 消费者数 × 分区数	Rebalance耗时
11	Checkpoint间隔 × 状态大小 = 恢复时间	Flink恢复估算
12	缓存命中率 = 命中次数 / 查询次数 × 100%	缓存效率

八、考前30秒速记清单（25条）

Spark核心：RDD（弹性分布式数据集）+ DAG调度 + 内存计算
RDD窄依赖：map/filter（无Shuffle）；宽依赖：groupByKey/reduceByKey（有Shuffle）
Transformation惰性求值，Action触发执行
MapReduce瓶颈在Shuffle（磁盘IO+网络）
Flink=真流处理（事件驱动），Spark Streaming=微批处理
Flink三时间：Event Time（推荐）> Ingestion Time > Processing Time
Watermark = MaxEventTime - AllowedLateness，解决乱序
Checkpoint基于Chandy-Lamport分布式快照算法
Redis五大类型：String/List/Hash/Set/ZSet
Redis持久化：RDB（快恢复）vs AOF（更安全），4.0+混合持久化
Redis淘汰策略默认noeviction（不淘汰，写入报错）
Redis Cluster有16384个Hash Slot，CRC16路由
缓存穿透=查不存在（空值/布隆），击穿=热点过期（互斥锁），雪崩=批量过期（TTL随机）
Cache-Aside：读先查缓存，写先更新DB再删缓存
CAP：C一致性 + A可用性 + P分区容错，三选二
BASE：基本可用 + 软状态 + 最终一致性（AP延伸）
Kafka核心：Topic→Partition→Replica(Leader/Follower)
ISR=与Leader同步的副本集，只有ISR能选Leader
HW=ISR最小LEO，消费者只能消费HW之前
消费者组：组内一分区一消费者，组间各自独立
Kafka投递语义：At-Most-Once / At-Least-Once / Exactly-Once
Exactly-Once = 幂等Producer + 事务
Kafka高吞吐：顺序写 + PageCache + Zero-Copy + 批量 + 压缩
分布式事务：2PC（强一致阻塞）/ Saga（补偿）/ TCC（Try-Confirm-Cancel）
2PC两阶段：Prepare（准备）→ Commit/Rollback（提交/回滚）

九、3道自测练习（第64期·冲刺版）

自测1：Spark与Flink辨析（10分）

题目：下列关于Spark和Flink的说法，正确的有几个？
(1) Spark基于内存计算，MapReduce基于磁盘
(2) Spark Streaming是微批处理，Flink是真流处理
(3) RDD是不可变的，可以并行操作
(4) Flink的Checkpoint基于Paxos算法
(5) Spark的Action算子触发DAG执行
A. 2个 B. 3个 C. 4个 D. 5个

答案：C（4个正确：1、2、3、5）

(1)✓ Spark内存计算，MapReduce磁盘IO密集
(2)✓ Spark Streaming微批，Flink事件驱动
(3)✓ RDD不可变、分区、可并行
(4)✗ Checkpoint基于Chandy-Lamport算法，非Paxos
(5)✓ Action算子触发执行

自测2：Redis缓存设计（10分）

题目：某电商系统使用Redis缓存商品信息，某天大促期间出现DB被打满的问题。经排查发现大量热点商品缓存同时过期。该问题的类型和解决方案是（）。

A. 缓存穿透，缓存空值
B. 缓存击穿，互斥锁
C. 缓存雪崩，TTL加随机值
D. 缓存溢出，增加内存

答案：C

大量key同时过期 → 缓存雪崩
TTL加随机值避免同时过期
多级缓存+熔断降级也是补充方案

自测3：Kafka综合（10分）

题目：判断下列说法的对错。
(1) Kafka消费者组内一个分区只能被一个消费者消费
(2) Kafka消息删除是自动的，基于时间或大小
(3) ISR中的所有副本都可以处理客户端读写
(4) 增加分区数不影响消息顺序性
(5) Kafka支持事务性跨分区原子写入

答案：✓✓✗✗✓

(1)✓ 组内一分区一消费者
(2)✓ Kafka基于时间/大小自动删除旧消息
(3)✗ 只有Leader处理读写，Follower仅同步
(4)✗ 增加分区会破坏全Topic消息顺序性（单分区内有序）
(5)✓ Kafka事务支持跨分区原子写入

十、71天四阶段冲刺计划 + 本周任务

第一阶段：基础夯实（17天）

任务1：通读教材 + 划重点（计算题/概念题/综合题分布）
任务2：刷近5年真题3套计时（120分钟/套）
任务3：整理错题本（按主题分类）

第二阶段：专题突破（21天）

任务4：下午案例六大题型分别刷5道
任务5：大数据/缓存/消息队列专题精练
任务6：设计模式23种识别（情景化练习）

第三阶段：综合提升（17天）

任务7：模拟考3套（仿真环境，含草稿）
任务8：易混淆概念对比表（Spark vs Flink、RDB vs AOF、三种投递语义）
任务9：考前高频考点回炉（结合本期押题）

第四阶段：临考冲刺（16天）

任务10：考前5套真题精做（评分+复盘）
任务11：考前一周：错题清单再过一遍
任务12：考前两天：看30秒速记清单、考场策略

本周（每周7任务清单）

完成一套真题全真模拟（120+240分钟计时）
上午选择题75题错题归类整理（重点：本期大数据/Redis/Kafka）
下午案例题6题型各1道
整理本周新增的15个考点速记卡
算法代码填空实战（DP+回溯各2题）
设计模式代码识别（10段代码）
周日完整复盘（错题+薄弱点+下周计划）

十一、考场终极策略（10条）

拿到试卷先通览：用30秒浏览全卷，标注熟悉题和难题
上午75题节奏：120分钟÷75≈1.6分钟/题，难题超2分钟先跳过
下午6选5原则：选最有把握的5题（每题15分），剩1题再回头
先易后难：刷完一遍后回头补难题，避免纠结
代码填空逆向思考：从上下文推断应填值
DFD/ER/UML题拿稳：这三大题型共30分，送分保底
英语题最后30分钟：擅长者先做，不擅长者最后蒙C
草稿纸四分区：题号/计算/作图/检查，分区使用高效
答题卡不留空：不会的也蒙一个（C选项正确率约25%）
检查重点：计算题单位、姓名准考证号涂写、答题卡对齐

十二、考前心理调适时间线（71天版）

时间节点	心理状态	调适方法
71天~30天	焦虑期，怕来不及	制定详细计划，按节点完成
30天~15天	疲惫期，刷题没进步	调整方法，复盘错题比刷新题重要
15天~7天	紧张期，怕考砸	适度减少刷题量，回归基础
7天~3天	焦虑峰值	散步+音乐+和家人倾诉
3天~1天	失眠常见	热水泡脚+远离社交媒体+早睡
考前1天	紧张+兴奋	看速记清单、准备好证件、按时睡觉
当天早上	紧张峰值	腹式呼吸4-4-6（吸4秒-屏4秒-呼6秒）
进考场前	手心出汗	主动和同学聊天分散注意力
开考15分钟	略紧张	通览全卷，找熟悉的题先做

结语：第64期冲刺寄语

“剩下71天，大数据Spark/Flink之流批统一+Redis缓存之一致性博弈+Kafka消息之高吞吐奥秘+综合冲刺之查漏补缺，构成你考试前最后的弹药库。”

同学你好，71天不长，但足够你完成蜕变。本期四大主题（大数据计算框架Spark与Flink + 分布式缓存Redis与一致性 + 消息队列Kafka深度 + 考前综合冲刺模拟）覆盖了2026考纲最可能涉及的大数据与中间件深度方向，同时把高频基础考点（分布式系统/CAP/一致性/缓存模式/消息语义）做成保分速记卡。

记住三件事：