一 说说整理初衷
最近有一些网友问我要考试套路，我确实有，但是比较散乱，借此重新整理一下发出来。
欢迎加微信沟通交流，专门建了个软考架构的群，欢迎加我微信拉进群沟通交流。
二 系统设计考察要点
- 软件架构风格（****）
- 质量属性与架构评估（*****）
- Web架构综合考察（*****）
软件架构风格（****）
考察方式一般是架构风格对比，所以需要掌握五大架构风格及子风格及特点等（建议记忆书中内容，以下是这五种架构风格的概述）。
- 数据流风格将前一步处理的结果作为后一步的输入内容，主要包含批处理序列与管道-过滤器两种风格，批处理序列强调的是大量整体的数据一起处理，而管道过滤器强调的是流式数据的处理；
- 调用返回风格主要包含主程序/子程序、面向对象风格、层次结构三种风格，主程序/子程序是面向过程的调用，面向对象风格主要是对象方法的调用，层次结构则是层与层的方法调用；
- 独立构件风格强调的是构件之间不直接交互从而降低系统的耦合性，主要包含进程通信与事件驱动两种风格；
- 虚拟机风格的特点是可以灵活的自定义场景，主要包含解释器风格与规则系统，而规则系统其实是在解释器的基础之上增加了经验规则；
- 仓库风格强调的是以数据为中心，主要包含数据库系统、黑板系统、超文本系统三种风格
质量属性与架构评估（*****）
这块是最重要的，基本年年必考质量属性。
质量属性主要是四种（性能、可用性、安全性、可修改性），考察方式一般是罗列质量属性让你识别是哪种质量属性，考察时可能还会额外有其他质量属性。
- 性能是指系统的响应能力，即要多长时间才能对某个事件做出响应或者在某段时间内系统所能处理的事件的个数；
- 可用性是指系统正常运行的时间比例，经常用两次故障之间的时间长度或出现故障时系统能够恢复正常的速度来表示；
- 安全性是指系统能够向合法用户提供服务的同时可以阻止非授权用户访问的企图或拒绝服务的能力；
- 可修改性是指系统能够快速地以较高的性能价格比对系统进行变更的能力，通常以某些具体的变更为基准，通过评估这些变更的代价衡量可修改性。
如2020年案例真题
请分析题干中的需求描述，填写图1-2中(1)～(6)处的空白。
偶尔可能会考察架构评估的一些概念如下：
架构评估方法：
- 1 软件架构分析法（SAAM）
最初仅仅是用于分析架构可修改性，后面扩展到其他质量属性。 - 2 架构权衡分析法（ATAM）
从软件架构分析法发展而来，主要是针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。 - 3 成本效益分析法（CBAM）
成本效益分析是通过比较项目的全部成本和效益来评估项目价值的一种方法，成本—效益分析作为一种经济决策方法，以寻求在投资决策上如何以最小的成本获得最大的收益。
系统架构风险（风险点）：是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
敏感点：是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
Web架构综合考察（*****）
Web架构综合题也是年年必然会考察的，考察的方式多种多样，按往年一般从以下方面考察：
从架构来看：
MVC、MVP、MVVM、REST、Webservice、微服务
| 角度 | 考察点 |
|---|---|
| 从并发分流来看 | 集群（负载均衡），CDN |
| 从缓存来看 | MemCache、Redis、Squid |
| 从数据来看 | 主从库（主从复制）、内存数据库、反规范化技术、NoSQL、分区（分表）技术、视图与物化视图 |
| 从持久化来看 | Hibernate、Mybatis |
| 从分布存储来看 | Hadoop、FastDFS、区块链 |
| 从数据编码来看 | XML、JSON |
| 从Web应用服务器来看 | Apache、WebSphere、WebLogic、Tomcat、JBOSS、IIS |
| 从安全性来看 | SQL注入攻击 |
| 其他 | 静态化、有状态与无状态、响应式Web设计、中台 |
一些相关概念：
应用层负载均衡：
- Http重定向，特点：实现简单，但性能较差。
- 反向代理服务器，特点：部署简单，但代理服务器可能成为性能瓶颈。
传输层负载均衡：
- DNS域名解析负载均衡，特点：效率比HTTP重定向高，减少维护负载均衡服务器成本。但一个应用服务器故障，不能及时通知DNS，而且DNS负载均衡的控制权在域名服务器商那里，网站无法做更多的改善和更强大的管理。
- 基于NAT的负载均衡，特点：技术较为成熟，一般在网关位置，可以通过硬件实现。像四层交换机一般就采用了这种技术。
负载均衡算法 - 静态算法（不考虑动态负载）
- 轮转算法：轮流将服务请求调度给不同的节点。
- 加权轮转算法：考虑不同节点处理能力的差异。
- 源地址哈希散列算法：根据请求的源IP地址，作为散列键从静态分配的散列表找出对应的节点。
- 目标地址哈希散列算法：根据请求目标IP做散列找出对应节点。
- 随机算法：随机分配，简单，但不可控
负载均衡算法 - 动态算法（考虑动态负载）
- 最小连接数算法：新请求分配给当前活动请求数量最少的节点，每个节点处理能力相同的情况下。
- 加权最小连接数算法：考虑节点处理能力不同，按最小连接数分配。
- 加权百分比算法：考虑了节点的利用率、硬盘速率、进程个数等，使用利用率来表现剩余处理能力。
负责均衡算法 - 硬件负载均衡：F5
软件负载均衡：LVS、Nginx、HAproxy
Session共享机制：
- 方案一：客户端Cookie携带Session
- 方案二：服务间同步Session
- 方案三：将Session存入Redis
Hibernate与Mybatis的技术不同维度技术对比：
- 简单对比：Hibernate强大、复杂、间接、SQL无关；Mybatis小巧、简单、直接、SQL相关
- 可移植性：Hibernate好（不关心具体数据库）；Mybatis差（根据数据库SQL编写）
- 复杂多表关联：Hibernate不支持；Mybatis支持
数据库读写分离化-主从数据库结构特点：
- 一般：一主多从，也可以多主多从。
- 主库做写操作，从库做读操作。
数据库读写分离化-主从复制步骤：
- 1 主库更新数据完成前，将操作写binlog日志文件。
- 2 从库打开I/O线程与主库连接，做binlog dump process，并将事件写入中继日志。
- 3 从库执行中继日志事件，保持与主库一致。
缓存与数据库协作-数据读取：
- 1 根据key从缓存读取
- 2 若缓存没有，则根据key在数据库中查找
- 3 读取到“值”之后，更新缓存
缓存与数据库协作-数据写入：
- 1 根据key值写数据库
- 2 根据key更新缓存
Redis与Memcache的能力比较
| 对比维度 | Redis | Memcache |
|---|---|---|
| 持久性 | 支持 | 不支持 |
| 分布式存储 | 多种方式，主从、Sentinel、Cluster等 | 客户端哈希分片/一致性哈希 |
| 多线程支持 | 不支持（Redis6.0开始支持） | 支持 |
| 内存管理 | 无 | 私有内存池/内存池 |
| 事务支持 | 有限支持 | 不支持 |
| 数据容灾 | 支持，可以在灾难发生时恢复数据 | 不支持，不能做数据恢复 |
2018年真题如下
表4-1中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善表 4-1中的空（1）~ （6）。
Redis集群切片的常见方式
- 客户端分片：在客户端通过key的hash值对应到不同的服务器
- 中间件分片：在应用软件和redis中间，例如：Twemproxy，Codis等，由中间件实现服务到后台Redis节点的路由分派。
- 客户端服务端协作分片：Redis Cluster模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务slot上。不同的slot对应到不同的服务器。
Redis分布式存储方案
- 主从（Master/Slave）模式，核心特点：一主多从，故障时手动切换。
- 哨兵（Sentinel）模式，核心特点：有哨兵的一主多从，主节点故障自动选择新的主节点。
- 集群（Cluster）模式，核心特点：分节点对等集群，分slots，不同slots的信息存储到不同节点。
Redis数据分片方案：
- 范围分片：按数据范围值做分片
- 哈希分片：通过对key进行hash运算分片，可以把数据分配到不同实例，这类似于取余操作，余数相同的，放在一个实例上。
- 一致性哈希分片：哈希分片的改进，可以有效解决重新分配节点带来的无法命中的问题。
Redis的持久化方式：
- RDB：传统数据库中快照的思想。指定时间间隔将数据进行快照存储。
- AOF：传统数据库中的日志思想，把每条改变数据集的命令追加到AOF文件末尾，这样出问题了，可以重新执行AOF文件中的命令来重建数据集。
Redis两种持久化方式对比：
| RDB | AOF | |
|---|---|---|
| 备份量 | 重量级的全量备份，保存整个数据库 | 轻量级增量备份，一次只保存一个修改命令 |
| 保存间隔时间 | 保存间隔时间长 | 保存间隔时间短，默认1秒 |
| 还原速度 | 数据还原速度快 | 数据还原速度慢 |
| 阻塞情况 | save会阻塞，但bgsave或则自动不会阻塞 | 无论是平时还是AOF重写，都不会阻塞 |
| 数据体积 | 同等数据体积小 | 同等数据体积大 |
| 安全性 | 数据安全性低，容易丢数据 | 数据安全性高，根据策略决定 |
Redis缓存的数据淘汰策略：
- 不淘汰（noeviction）：进制驱逐数据，内存不足以容纳新数据时，新写入操作会报错。系统默认的一种淘汰策略。
- 设置了过期时间的键空间：
- volatile-random：随机移除某个key
- volatile-lru：优先移除最近最少使用的key
- volatile-ttl：ttl值小的key优先移除
- 全键空间：
- allkeys-random：随机移除某个key
- allkeys-lru：优先移除最近最少使用的key
Redis的缓存雪崩解决方案：（大部分缓存失效 -> 数据库崩溃）
- 使用锁或队列：保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
- 为key设置不同的缓存失效时间：在固定的一个缓存时间基础上+随机一个时间作为缓存失效时间。
- 二级缓存：设置一个有时间限制的缓存+一个无时间限制的缓存。避免大规模访问数据库。
Redis缓存穿透解决方案：（查询无数据返回 -> 直接查数据库）
- 如果查询结果为空，直接设置一个默认值放到缓存，这样第二次到缓存中获取就有值了。设置一个不超过5分钟的过期时间，以便能正常更新缓存。
- 设置布隆过滤器，将所有可能存在数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
Redis缓存预热解决方案：（系统上线后，将相关需要缓存数据直接加到缓存系统中）
- 直接写个缓存刷新页面，上线时手工操作。
- 数据量不大时，可以再项目启动的时候自动进行加载。
- 定时刷新缓存。
Redis缓存更新常见的两种方式
- 1 定时清理过期的缓存
- 2 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到数据并更新缓存
Redis缓存降级：
- 目的是保证核心服务可用，即使是有损的，而且有些服务是无法降级的（如电商的购物流程等）；在进行降级之前要对系统进行梳理，从而梳理出哪些必须保护，哪些可以降级。