简介这份资源面向具备一定信息技术基础、从事系统分析与设计、数据库管理、Web开发及大数据处理的研发人员与架构师尤其适合备考系统分析师或需要系统梳理知识体系的1至3年从业者。内容围绕需求工程、系统运行维护、数据库设计、Web与架构模式、大数据处理等核心考点展开涵盖系统规划步骤、需求获取与验证、软件维护类型、负载均衡与容错、数据库锁协议与反规范化、MVC/MVP/MVVM、微服务与云原生、Lambda/Kappa/IOTA架构等具体知识点并配有案例与记忆逻辑辅助理解。资源包为1个docx文档大小约4.55MB结构清晰便于按章节检索与复习。目前已有165人学习。读者可借助它快速建立系统分析师知识框架掌握可行性分析、净现值与回收期计算等案例解题思路同时获取架构选型与数据库优化的参考依据适合作为备考笔记与日常查阅资料。1. 系统分析师考点整理从零散知识点到可复现的备考路径很多人第一次翻系统分析师的大纲都会有一种“什么都考、什么都不会”的错觉。系统分析、系统设计、数据库、Web 开发、架构模式、大数据处理这几块单拎出来每一块都能写一本书合在一起却只给你一张卷子。真正的问题不是知识点太多而是它们之间没有串成一条线。我见过不少同行工作五六年项目做了不少但一上考场就翻车原因往往不是不会而是不知道考的是“哪一层”的决策。这篇笔记不打算给你一份背诵清单而是把系统分析师考点整理这件事拆成一条能自己走一遍的路径先搞清楚每块知识在考什么决策再落到能动手验证的最小操作最后把容易踩的坑标出来。适合正在备考、或者想用考试大纲反向梳理自己技术体系的人。2. 系统分析到底在考什么从需求到模型的四步拆解系统分析这块很多人背了一堆“结构化分析”“面向对象分析”的名词真到做题还是分不清该用数据流图还是用例图。核心原因是没搞明白系统分析考的不是画图而是“把模糊需求转成可验证模型”的能力。考试里出现的每一张图、每一个模型背后都对应一个具体决策——边界在哪、数据怎么流、状态怎么变、对象怎么协作。2.1 需求工程的三层过滤原始诉求、功能需求、非功能需求需求工程最常见的失分点是把“用户说想要一个报表”直接当成功能需求写进答案。实际考试中你需要先做一层过滤原始诉求是用户嘴里的那句话功能需求是系统必须提供的动作非功能需求是动作执行时的约束。这三层混在一起写阅卷时基本拿不到分。我一般用下面这个判断顺序来拆这句话描述的是“谁做什么”还是“做得怎么样”如果是“谁做什么”继续问触发条件是什么、输入是什么、输出是什么、异常分支是什么。如果是“做得怎么样”归到非功能需求再细分性能、安全、可用性、可维护性。举个具体例子。某模拟项目里业务方说“希望订单查询快一点”。这句话不能直接写。拆完应该是功能需求——系统提供按订单号查询订单详情的接口非功能需求——在 500 并发下95 分位响应时间不超过 800 毫秒。考试答题时功能需求写清楚输入输出非功能需求写清楚指标和测量条件这两条分开写分数就稳了。提示非功能需求一定要带数字和条件没有数字的非功能需求在阅卷里等同于没写。2.2 数据流图与用例图的选择看边界还是看交互数据流图和用例图是系统分析里最容易选错的两种图。选错的代价是整道题的方向偏掉。判断标准其实很简单如果题目强调的是“数据在系统内部怎么加工、存储、流出”选数据流图如果强调的是“外部角色和系统之间有什么交互”选用例图。数据流图分顶层图和逐层分解。顶层图只画一个加工把外部实体和系统之间的数据流标清楚。逐层分解时注意平衡原则父图里出现的输入输出流子图里必须对应出现不能凭空多也不能凭空少。这个平衡检查是考试里高频的扣分点很多人图画得漂亮一查平衡就漏了一条流。用例图的关键是找对参与者。参与者不一定是人外部系统、定时任务都可以是参与者。用例的粒度也要控制一个用例应该是一个对参与者有价值的完整目标不要把“输入用户名”“输入密码”拆成两个用例。我一般会问自己这个用例结束后参与者有没有拿到一个可感知的结果有就是用例没有就是步骤。2.3 结构化分析与面向对象分析的切换时机结构化分析适合数据加工流程清晰、业务规则相对稳定的场景输出的是数据流图和数据字典。面向对象分析适合实体关系复杂、状态变化多的场景输出的是类图、状态图、序列图。考试里经常给你一段描述让你判断该用哪种方法。我的判断习惯是看两个信号第一描述里有没有大量“状态流转”的词比如“待审核→已审核→已发布”有就偏向面向对象第二描述里有没有明显的“输入→加工→输出”链条有就偏向结构化。两者不是互斥的实际答题时可以主用一种另一种作为补充说明。2.4 用最小案例跑一遍分析流程下面用一个虚构的“设备报修管理”场景把分析流程走一遍。注意这里不追求完整只追求每一步都有可验证的输出。场景描述 某实验室有多台设备使用人发现故障后提交报修单。 维修人员接单后上门维修维修完成后填写维修结果。 管理员可以查看所有报修单的状态统计。 第一步识别参与者 - 使用人 - 维修人员 - 管理员 第二步识别用例 - 提交报修单使用人 - 接单维修人员 - 填写维修结果维修人员 - 查看状态统计管理员 第三步识别关键实体 - 报修单单号、设备编号、故障描述、提交时间、状态 - 维修记录报修单号、维修人、维修时间、结果说明 第四步状态流转 待提交 - 待接单 - 维修中 - 已完成这段文本可以直接作为答题草稿。考试时不需要画得多漂亮但参与者、用例、实体、状态这四样必须齐全。缺任何一样后面的设计题就容易断链。3. 系统设计与架构模式从分层到微服务的决策链系统设计这块考试喜欢考“为什么这么分”而不是“怎么画”。分层架构、客户端服务器、微服务、事件驱动这些模式本身不难背难的是在具体约束下选对。选型的依据永远是质量属性性能、可用性、可修改性、安全性、可测试性。脱离质量属性谈架构就是玄学。3.1 分层架构的边界划分什么时候该加一层分层架构最常见的是表现层、业务逻辑层、数据访问层。很多人做设计时习惯性加一层“服务层”但说不清这一层到底解决什么问题。加层的唯一理由是某一类变化被隔离了。比如业务逻辑层里既有纯计算规则又有跨表的事务编排那可以把事务编排抽到应用层让业务逻辑层只保留规则。这样改规则不影响事务改事务不影响规则。考试里如果题目强调“业务规则经常变”你就应该把规则集中到一层并说明这一层不依赖具体存储和界面。如果题目强调“多种客户端接入”你就应该在表现层和业务层之间加一层适配隔离不同客户端的协议差异。3.2 微服务拆分的三个硬指标数据、团队、发布节奏微服务不是越细越好。拆分时我一般看三个硬指标第一数据能不能独立如果两个服务必须共享同一张表写事务拆了就是分布式事务的坑第二团队边界清不清楚一个服务最好由一个小组端到端负责第三发布节奏是否不同如果两个模块总是一起改一起发拆开只会增加联调成本。考试答题时如果题目给的是“某公司业务快速扩张多个团队并行开发”你可以往微服务方向写但一定要补一句“按业务能力拆分每个服务独立数据库”。如果题目给的是“业务稳定、团队规模小”写微服务反而会被扣分因为过度设计。3.3 用配置表对比四种架构模式的适用场景下面这张表是我自己整理用的考试时可以在草稿纸上快速列出来帮助判断。架构模式核心特征适合场景主要代价分层架构按技术职责分层业务规则复杂、需要独立演化层间调用可能变深客户端服务器请求响应集中管理内部工具、并发不高服务端容易成为瓶颈微服务按业务能力独立部署多团队并行、发布节奏不同分布式复杂度高事件驱动通过事件解耦生产消费异步流程、削峰填谷最终一致性难调试这张表不用背理解每一行的“代价”比记住“适合场景”更重要。考试里问“为什么不选某个模式”答代价往往比答优点更得分。3.4 设计题的最小验证用质量属性场景检查方案设计题写完不要急着交用质量属性场景过一遍。一个完整的质量属性场景包含六要素刺激源、刺激、环境、制品、响应、响应度量。比如“在高峰期用户发起查询系统应在 1 秒内返回结果”。如果你的设计里没有任何机制对应这个度量说明设计不完整。我一般会挑两到三个关键场景逐个问这个场景下我的分层/服务/缓存/队列分别起什么作用如果某个组件在这个场景里没有角色要么删掉要么说明它是为别的场景服务的。这样检查一遍设计题的逻辑会紧很多。4. 数据库与 Web 开发考点从范式到接口的落地细节数据库和 Web 开发是系统分析师考试里最容易“看起来会、做起来错”的部分。范式、索引、事务、接口设计这些概念大家都听过但一到具体题目细节上翻车的人特别多。这一章把高频考点拆成可操作的检查项。4.1 范式判断的快速方法看函数依赖而不是背定义范式题不用背 1NF、2NF、3NF 的定义直接找函数依赖。步骤是先找候选键再看非主属性对候选键的依赖关系。如果存在部分依赖就是 1NF 问题存在传递依赖就是 2NF 问题存在非平凡的多值依赖才考虑 4NF。具体操作拿到一个关系模式先标出所有函数依赖然后问三个问题。第一有没有非主属性只依赖候选键的一部分有就拆。第二有没有非主属性依赖另一个非主属性有就拆。第三拆完之后有没有丢失原有的函数依赖如果丢了说明拆过头了需要保留一个关联关系。考试里经常让你判断“是否满足 3NF”你不需要写完整证明只要指出哪条依赖违反了哪条规则然后给出拆分方案即可。4.2 索引设计的取舍选择性、覆盖、写入代价索引不是越多越好。判断一个索引该不该建看三个数选择性、覆盖能力、写入代价。选择性是不同值的比例比例越高越适合建索引。覆盖能力是指查询需要的列是否都在索引里如果在可以避免回表。写入代价是指每次插入更新都要维护索引索引越多写越慢。我一般用下面这个顺序决定找出 where 条件里出现频率最高的列。看这些列的选择性低于 10% 的单独建索引意义不大可以考虑组合索引。看查询是否需要回表如果需要的列少做成覆盖索引。统计这张表的读写比读多写少可以多建写多读少要克制。注意组合索引的列顺序很关键等值条件在前范围条件在后。顺序反了索引可能只用上前缀列。4.3 事务隔离级别的选择从脏读到幻读的对应关系事务隔离级别是必考点但很多人只背了四个级别和三个现象不知道怎么选。实际判断时先看业务能不能容忍哪种异常。如果绝对不能出现脏读至少用读已提交。如果同一事务内多次读同一范围结果必须一致就要可重复读或串行化。下面这张表把现象和级别对应清楚隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不可能可能可能可重复读不可能不可能可能串行化不可能不可能不可能考试答题时如果题目说“某系统要求同一事务内多次查询结果一致”你写可重复读并说明它通过快照实现即可。如果要求“统计结果绝对准确”写串行化但要补一句性能代价。4.4 接口设计的三个检查项幂等、超时、错误码Web 开发部分接口设计是高频考点。我一般用三个检查项过一遍。第一幂等这个接口重复调用会不会产生副作用如果会需要幂等键或去重表。第二超时调用方等多久服务端处理多久两个时间要匹配调用方超时时间必须大于服务端处理时间。第三错误码业务错误和系统错误有没有分开业务错误用明确码值系统错误用统一码值加日志追踪。{ code: ORDER_NOT_FOUND, message: 订单不存在, traceId: abc-123 }上面这个结构里code 是业务错误码message 给人看traceId 给排查用。考试里如果让你设计接口返回把这三样写全基本不会丢分。5. 大数据处理与架构模式批流选择与考点排查大数据处理这块系统分析师考试不会考你写 MapReduce但会考你选批处理还是流处理以及架构模式怎么配合。判断依据是延迟要求和数据完整性要求。延迟要求低、允许近似结果选流处理延迟要求高、要求精确结果选批处理。两者结合就是 Lambda 架构但考试里写 Lambda 要说明批层和流层各自负责什么。5.1 批处理与流处理的判断树我一般用三个问题做判断。第一数据要不要全量重算要就偏批。第二结果能不能接受分钟级延迟能就偏批不能就偏流。第三有没有乱序数据有就偏流因为批处理对乱序不敏感但流处理需要水位线机制。考试里如果题目说“实时监控设备状态并告警”写流处理补一句“使用窗口聚合和状态存储”。如果说“每天生成经营报表”写批处理补一句“按天分区全量计算”。5.2 大数据架构的考点分布存储、计算、调度大数据架构题一般考三层存储层、计算层、调度层。存储层考选型比如按列存储适合分析、按行存储适合事务。计算层考批流和引擎选择。调度层考依赖管理和失败重试。答题时不要只写“用某某组件”要写清楚每一层解决什么问题。比如“存储层使用分布式文件系统保存原始数据计算层使用批处理引擎做全量聚合调度层按依赖关系触发任务并记录执行状态”。这样写层次清楚得分点全。5.3 避坑与常见问题排查这一节列几个我在整理考点和实际做题时反复踩的坑每条按现象、原因、解决写。现象一数据流图逐层分解后父图和子图数据流对不上。原因画子图时凭感觉加了新的输入输出没有回头核对父图。 解决每画完一层把父图的所有流列出来逐条在子图里找对应找不到就补多出来就删。现象二范式判断时把候选键找错导致后续依赖全错。原因只看了明显的唯一列忽略了组合候选键。 解决先把所有函数依赖写出来再从中推导候选键不要凭直觉指认。现象三索引建了但查询没走性能没提升。原因查询条件里对索引列做了函数运算或类型转换。 解决检查 where 条件确保索引列以裸列形式出现必要时改写查询或建函数索引。现象四事务隔离级别选了可重复读但统计结果还是不对。原因可重复读防不住幻读统计范围变了。 解决对统计类查询使用串行化或者在应用层加锁并说明代价。现象五微服务拆分后两个服务频繁联调发布反而更慢。原因拆分时没有按发布节奏切把总是一起改的模块拆开了。 解决重新按业务能力聚合把同步修改的模块合并回一个服务或者改用模块化单体。6. 把考点变成可验证的复习动作我的错题复盘习惯复习到后期最大的问题不是不会而是“以为自己会”。我自己的做法是每整理完一个考点不写总结而是写一个可验证的动作。比如整理完索引设计动作是“给一张虚构的订单表写出三个查询和对应索引并说明每个索引的选择性”。整理完事务隔离动作是“写出两个并发事务分别在不同隔离级别下执行标出可能出现的异常”。这样做的目的是把知识点变成可检查的输出而不是停留在“看过”。具体操作上我一般用下面这个模板来复盘错题错题来源某次模拟练习 考点数据流图平衡 我的答案子图少了一条输入流 正确答案父图的“设备信息”流必须出现在子图 错因画图时只关注了加工逻辑忘了外部实体输入 修正动作以后每画完子图先列父图流清单再逐条核对这个模板的关键是最后一行“修正动作”必须是一个下次可以执行的具体行为不能写“下次注意”。写“下次注意”等于没写。另外我会把每个考点的“最小验证”记在一个单独的文件里考前只看这个文件。比如数据库部分的最小验证是“给一个关系模式判断范式并拆分”架构部分的最小验证是“给三个质量属性场景检查设计是否覆盖”。这样考前不用翻厚书直接跑一遍验证动作心里就有底。最后一个习惯遇到不确定的题不要猜先标记回头用“如果我是出题人我想考哪个决策”来反推。系统分析师考试考的是决策能力不是记忆能力。把每个考点还原成一个决策场景比背十遍定义都管用。希望帮到你。本文还有配套的精品资源点击获取