系统架构设计师常见高频考点总结之案例题

1. 仓库风格vs 管道-过滤器风格在软考系统架构设计师的案例分析中将“数据仓储以数据为中心风格”与“管道-过滤器风格”放在“集成开发环境IDE”场景下进行对比是非常经典的必考题型在2012年和2016年的下午案例分析中均作为核心考点出现过。维度一四大核心机制对比参考2016年案例题不要背长句直接建立左右对照的强映射关系。考试时看到左边的特征直接填右边的词比较维度管道-过滤器 (单向流水线)数据仓储 (共享大白板)交互方式顺序 / 循环星型交互中心结点辐射数据结构数据流文件 /模型核心考词语法树控制结构数据驱动业务功能驱动扩展方法接口适配模型适配维度二IDE 为什么必选“数据仓储”专攻简答默写题抛弃书本上的长篇大论你只需要记住 IDE 的“三大刚需”然后套用“白板赢了流水线”的逻辑1. 刚需一高频互动交互方式大白话逻辑程序员写代码是一边写、一边查错、一边断点调试的动作极度碎片化且来回反复。答题得分点管道风格不支持反复交互数据仓储很好地支持了“交互式”的数据处理。2. 刚需二随意插拔插件扩展性大白话逻辑IDE 里各种代码检查工具、格式化工具经常换如果用流水线抽掉一个环节整条线就断了。答题得分点管道风格处理逻辑僵化数据仓储以“数据格式”解耦了各个工具灵活定义功能顺序易于配置和替换。3. 刚需三格式极其复杂数据管理大白话逻辑IDE 里有纯文本脚本、有可视化的图、还有复杂的底层语法树。流水线只能跑单一格式。答题得分点管道风格支持的格式有限数据仓储的中心存储器能包容“多种复杂数据类型”并强力支持“数据格式转换”。2. 解释器架构 vs 面向对象架构对比维度优劣结论核心理由与话术1. 灵活性与可修改性解释器 面向对象(解释器更优)解释器架构将业务规则定义为独立的脚本或配置文件。规则变更时无需修改源码、无需重新编译部署更新文件即可即时生效。面向对象架构业务逻辑固化在代码中变更需要修改类代码并重新发布维护成本高。2. 个性化与自定义能力解释器 面向对象(解释器更优)解释器架构支持最终用户或业务人员通过编写简单规则如“满100减20”定义逻辑轻松实现业务的“千人千面”。面向对象架构逻辑由开发人员编写非技术人员无法介入难以实现灵活的个性化定制。3. 系统性能解释器 面向对象(解释器较差)解释器架构需要在运行时进行词法分析、语法分析和动态解释存在额外的计算开销执行速度较慢。面向对象架构代码是预编译好的或直接执行机器码/字节码执行效率更高。“解释器”就是“外挂”外挂解释器改起来真快灵活性高玩家业务人员自己就能拽个性化强就是跑起来有点怪性能差。“面向对象”是“原装”原装面向对象固化在代码里灵活性差改个口味要等你个性化弱好在速度杠杠的性能好。3. 主程序-子程序vs管道-过滤器“将两种架构风格放入表格中进行优劣/-对比”是一种非常经典且极具实战指导意义的题型。以下是该对比表格的完整内容及详细的剖析1. 架构方案对比表评价要素共享数据的主程序-子程序管道-过滤器算法变更- 差 优功能变更- 差 优数据表示变更- 差- 差性能 优- 差2. 详细要素解析考场答题依据在应对此类填表对比题时您可以记住一个核心底层逻辑主程序-子程序代表了“紧耦合”好处是性能高坏处是改起来特别麻烦不管是改算法、改功能还是改数据格式都是-。管道-过滤器代表了“松耦合、流程化”好处是改算法、拼装新功能特别灵活坏处是性能有损耗-并且一旦改了数据格式整个流水线都要跟着改也是-。4.Redis 缓存技术1. 缓存架构Cache-Aside (旁路缓存)读策略先读缓存 → 命中返回未命中读DB → 写入缓存 → 返回。写策略先更新数据库 →后删除缓存不是更新缓存。并发一致性问题多线程下可能出现脏数据。解决延时双删、分布式锁、设置过期时间。2. 缓存过期策略缓存中一般存储当前的热点数据Redis 为每个 KEY 值都设置了过期时间并默认采用“定期删除惰性删除”的策略来清除非热点数据。请简要描述该策略的“失效场景”并给出至少三种“内存淘汰机制”来解决内存越来越高的问题。“定期删除惰性删除”的失效场景如果“定期删除”没有扫描并删除到该过期的KEY同时后续系统也没有及时去请求该KEY也就是说“惰性删除”也没有被触发这样Redis默认的过期删除策略就失效了最终会导致Redis的内存使用率越来越高。常见的内存淘汰机制任写三种即可满分当过期策略失效、内存不足时Redis 会启动内存淘汰机制。从已设置过期时间的数据集中淘汰最近最少使用的数据(对应 volatile-lru)。从已设置过期时间的数据集中淘汰将要过期的数据(对应 volatile-ttl)。从已设置过期时间的数据集中任意选择数据淘汰(对应 volatile-random)。从所有数据集中淘汰最近最少使用的数据(对应 allkeys-lru)。从所有数据集中任意选择数据淘汰(对应 allkeys-random)。3.数据类型应用数据类型应用String用于常规计数List用于列表Set用于去重和交集如共同好友Hash用于存储部分变更数据Zset用于带权重的排行榜 。4.持久化对比维度RDB (快照)AOF (日志追加)数据安全性较低。由于是间隔备份如果宕机会丢失最后一次快照后的所有数据。较高。可以配置为每秒同步everysec或每次写入同步always数据丢失通常在秒级。重启恢复速度快。RDB 文件是压缩后的二进制全量数据恢复时直接加载到内存。慢。需要逐条执行日志中的命令数据量大时加载非常耗时。文件体积小。二进制压缩格式存储紧凑。大。记录了所有的操作指令即使数据没变文件也会不断增长虽有 AOF 重写机制。性能损耗周期性高损耗。Fork 子进程进行磁盘 IO在大数据集下 fork 可能会导致秒级的服务停顿。持续性轻微损耗。写操作需要同步到磁盘IO 压力分散在平时但对吞吐量有一定影响。5. 分布式存储和切片数据量太大单台存不下怎么切分到多台机器上1. Redis 分布式存储的 2 种常见方案主从方案Master-Slave也可加上 Sentinel 哨兵模式Cluster 集群方案2. Redis 集群切片Sharding的常见方式客户端切片在应用层客户端通过对 Key 进行 Hash 计算直接将数据映射并路由到对应的不同 Redis 服务器上它的典型代表是ShardedJedis。服务端/数据分片Slot机制对数据根据 Key 散列到不同的 Hash槽Slot上不同的 Slot 分配并对应到不同的 Redis 服务器节点上如 Redis Cluster 的 16384 个槽位代理切片客户端不直接连接 Redis 节点而是连接一个“中间件代理Proxy”。客户端把请求发送给代理代理解析请求计算 Key 的 Hash 值然后路由到后端的某个具体的 Redis 节点。拿回数据后代理再返回给客户端如Twemproxy、Codis。6.Redis vs MemCache比维度MemCacheRedis数据类型只支持简单的 Key/Value 结构支持丰富的数据结构String, List, Set, Hash, ZSet 等持久化数据全在内存掉电即丢不支持持久化支持 RDB 和 AOF 持久化操作线程模型采用多线程机制核心业务逻辑是单线程这是高频考点分布式/集群原生不支持集群不支持分布式存储通常靠客户端实现如一致性哈希支持多种方式如主从Master-Slave、哨兵Sentinel和原生 Cluster 集群