4.0 架构设计-面试-笔记思维导图模板_ProcessOn思维导图、流程图

高性能数据库集群

读写分离

主从集群

数据库服务器搭建主从集群，一主一从、一主多从都可以。

数据库主机负责读写操作，从机只负责读操作。

数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据。

业务服务器将写操作发给数据库主机，将读操作发给数据库从机。

复制延迟

1. 写操作后的读操作指定发给数据库主服务器

2. 读从机失败后再读一次主机

3. 关键业务读写操作全部指向主机，非关键业务采用读写分离

分配机制

1. 程序代码封装

2. 中间件封装

分库分表

业务分库

1.join 操作问题

2. 事务问题

3. 成本问题

分表

垂直分表

对应到表的切分就是表记录数相同但包含不同的列。

垂直分表适合将表中某些不常用且占了大量空间的列拆分出去。

水平分表

对应到表的切分就是表的列相同但包含不同的行数据。

路由

范围路由

Hash 路由

配置路由

复杂度

join 操作

count() 操作

count() 相加

增加记录数表

order by 操作

综合解决方案

1.做硬件优化，例如从机械硬盘改成使用固态硬盘，当然固态硬盘不适合服务器使用，只是举个例子

2.先做数据库的调优操作，例如增加索引;

慢sql优化

根据业务特点，对表设计进行优化

多用短查询

3.引入缓存技术、全文检索等，例如Redis，减少数据库压力

4.程序与数据库表优化，重构，例如根据业务逻辑对程序逻辑做优化，减少不必要的查询;

5.在这些操作都不能大幅度优化性能的情况下，不能满足将来的发展，再考虑分库分表。应该优先垂直分表

高性能NoSQL

关系型数据库缺点

关系数据库存储的是行记录，无法存储数据结构

关系数据库的 schema 扩展很不方便

关系数据库在大数据场景下 I/O 较高

关系数据库的全文搜索功能比较弱

常见的 NoSQL 方案

K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。

文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。

优点

1. 新增字段简单

2. 历史数据不会出错

3. 可以很容易存储复杂数据

缺点/复杂度

最主要的代价就是不支持事务

无法实现关系数据库的 join 操作

列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。

全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。

高性能缓存架构

适用场景

需要经过复杂运算后得出的数据，存储系统无能为力

读多写少的数据，存储系统有心无力

复杂性

缓存穿透

缓存穿透是指缓存没有发挥作用，业务系统虽然去缓存查询数据，但缓存中没有数据，业务系统需要再次去存储系统查询数据。

1. 存储数据不存在

2. 缓存数据生成耗费大量时间或者资源

缓存雪崩

缓存雪崩是指当缓存失效（过期）后引起系统性能急剧下降的情况。

解决方案1. 更新锁

解决方案2. 后台更新

后台线程除了定时更新缓存，还要频繁地去读取缓存（例如，1 秒或者 100 毫秒读取一次），如果发现缓存被“踢了”就立刻更新缓存

业务线程发现缓存失效后，通过消息队列发送一条消息通知后台线程更新缓存。

缓存预热

缓存热点

单服务器高性能模式：PPC与TPC

高性能负载均衡

分类及架构

DNS 负载均衡

硬件负载均衡

软件负载均衡

负载均衡典型架构

算法

任务平分类

负载均衡类

性能最优类

Hash 类

接口异常

降级

熔断

限流

排队

架构可扩展模式

拆分方式

面向流程拆分：分层架构

面向服务拆分：SOA、微服务。

面向功能拆分：微内核架构。

概念

架构是顶层设计

框架是面向编程或配置的半成品

组件是从技术维度上的复用

模块是从业务维度上职责的划分

系统是相互协同可运行的实体

架构设计的目的

1 架构是为了应对软件系统复杂度而提出的一个解决方案。

2 架构即(重要)决策

3 需求驱动架构，架起分析与设计实现的桥梁

4 架构与开发成本的关系

架构设计的复杂度

复杂度来源：高性能

性能

伸缩性

单机复杂度

进程

线程是任务调度的最小单元，共用进程内的资源。

线程

进程是资源分配的最小单元，与其他进程资源互相独立。

总结

集群复杂度

垂直拆分

增大内存减少I/O操作 更换为固态硬盘（SSD）提升I/O访问速度 使用RAID增加I/O吞吐能力 置换服务器获得更多的处理器或分配更多的虚拟核 升级网络接口或增加网络接口

水平拆分

集群（多实例副本）：同一组件重复部署到多台不同的服务器

功能分解：基于功能将系统分解为更小的子系统

数据分割：在每台机器上都只部署一部分数据

复杂度来源：高可用

计算高可用

存储高可用

高可用状态决策

1. 独裁式

2. 协商式

3. 民主式

如何做到高可用

核心思想：网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。

从架构角度看可用性：当前网站系统多采用经典的分层模型，从上到下为：应用层、服务层与数据层。应用层主要实现业务逻辑处理；服务层提供可复用的服务；数据层负责数据读写；在部署架构上常采用应用和数据分离部署，应用会部署到不同服务器上，这些服务器被称为应用层的服务器；这些可复用的服务也会各自部署在不同服务器上，称为服务层的服务器；而各类数据库系统、文件柜等数据则部署在数据层的服务器。

不可用的技术解决措施

(1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务（前提是这些服务需要设计为无状态，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应），当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。

(2)服务层服务器。这些服务器被应用层通过分布式服务框架（如Dubbo）访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。

(3)数据服务器。数据同步复制，数据库主从同步

复杂度来源：可扩展性

预测变化

应对变化

一应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。

1. 系统需要拆分出变化层和稳定层

2. 需要设计变化层和稳定层之间的接口

二常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。

1 What：什么是架构的可扩展性？

2 Why：为什么要求架构具备良好的可扩展性？

3 How：如何设计可扩展性好的架构？