从零开始学架构 - 高性能架构

存储高性能

  • 关系数据库

    • 读写分离：将访问压力分散到集群中的多个节点，但是并没有分散存储压力。

    • 分库分表：既可以分散访问压力，又可以分散存储压力。

      • 业务分库：分散存储和访问压力

          - 引入问题

  	- join操作问题

  		- 原本在同一数据库的表分散到不同数据库中，导致无法使用SQL的join查询。

  	- 事务问题

  		- 原本在同一数据库中不同的表可以在同一个事务中修改，业务分库后，表分散到不同的数据库中，无法通过事务统一修改。

  	- 成本问题

  		- 原来只需要1台服务器就能处理的事情，可能需要扩展为3台或者更多。

      • 分表

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

  	- 引入问题

  		- 因为表信息被分散到多个表中，导致原来一次查询，现在可能需要2次或者更多。

  - 水平分表：适合表行数据特别大的表，例如单表行记录超过5000万条。

  	- 引入问题

  		- 路由：水平分表后，某条数据具体属于哪个切分后的子表，需要增加路由算法进行计算

  			- 范围路由
  			- Hash路由
  			- 配置路由

  		- count()操作

  			- 原始对表进行count()操作，切分后需要 表个数 * count(*) 

  		- 记录数表

  			- 新建一张表，记录每次插入或删除子表数据后，表的记录数。

    • 实现方法

      • 程序代码封装：在代码中抽象一个数据访问层来实现读写分离、分库分表

      • 中间件封装：独立一套系统出来，实现读写分离和分库分表操作

      • 实现复杂度：分库分表比读写分离要复杂的多。

          - 读写分离实现时，只需识别SQL操作是读操作还是写操作接口，即通过关键字SELECT、UPDATE、INSERT、DELETE就可以判断。
  - 分库分表除了要判断操作类型，还需要判断SQL中具体要操作的表、操作函数（count、order by、group by），然后根据不同的操作进行不同的处理。

    • 存在缺点

      • 关系数据库存储的是行记录，无法存储数据结构
      • 关系数据库的表结构schema扩展很不方便
      • 关系数据库在大数据场景下I/O较高
      • 关系数据库的全文搜索功能比较弱

  • NoSQL

    • 关系数据库

    • NoSQL的本质是牺牲ACID特性中的某个或某些特性，作为关系数据库的补偿。

    • 常用的NoSQL方案有如下4类

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

      • 文档数据库：解决关系数据库强schema约束的问题，以MongoDB为代表。 文档数据库最大特点是no-schema,可以存储和读取任意的数据，数据格式一般为JSON.

        优势：

新增字段简单；

历史数据不会出错；

可以很容器存储复杂数据。

      • 列式数据库：解决关系数据库大数据场景下I/O问题，以HBase为代表。 例如，统一某城市超重人员的数量，只需读取体重这一列的数据即可。

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

  • 缓存

    • 基本原理：将可能重复使用的数据放到内存中，一次生成，多次使用，避免每次使用都去访问存储系统。

    • 面临的问题

      • 缓存穿透：访问了缓存中不存在的数据，导致业务系统需要再次访问数据库，导致对数据库服务器造成压力。
      • 缓存击穿：单个高热数据过期的瞬间，数据访问量较大，未命中缓存后，发起了大量对同一数据的数据库访问，导致对数据库服务器造成压力
      • 缓存预热：系统启动前，提前将相关的缓存数据直接加载到缓存系统。
      • 缓存雪崩：由于大量的热数据设置了相同或接近的过期时间，导致缓存在某一时刻密集失效，大量请求全部转发到DB，导致存储系统受到巨大压力，最终导致系统崩溃

计算高性能

  • 单服务器高性能

    • PPC(Process per Connection)，每次有新的连接就新建一个进程专门处理这个连接的请求。

    • prefork：提前创建进程，便于后续直接使用

    • TPC(Thread per Connection)，每次有新的连接就新建一个线程专门处理这个连接的请求。

    • prethread：提前创建线程，便于后续直接使用

    • Reactor(非阻塞同步网络模型)：核心组件包括Reactor和处理资源池，其中Reactor负责监听和分配事件，处理资源池负责处理事件。

      • 1.父进程中mainReactor对象通过select监控连接建立事件，收到事件后通过Acceptor接收，将新的连接分配给某个子进程。
      • 2.子进程subReactor将mainReactor分配的连接加入连接队列进行监听，并创建一个Handler用于处理连接的各种事件。
      • 3.当有新的事件发生时，subReactor会调用连接对应的Handler来进行响应。
      • 4.Handler完成 read ——> 业务处理 ——> send的完整业务流程。
      • 图片

    • Proactor(异步网络模型)：核心组件包括Proactor和异步操作处理器。

      • 1.Proactor Initiator 负责创建 Proactor 和 Handler，并将Proactor 和 Handler 都通过Asynchronous Operation Processor 注册到内核。
      • 2.Asynchronous Operation Processor 负责处理注册请求，并完成I/O操作。
      • 3.Asynchronous Operation Processor 完成I/O操作后通知Proactor。
      • 4.Proactor根据不同的事件类型回调不同的Handler进行业务处理。
      • 5.Handler完成业务处理，Handler也可以注册新的Handler到内核进程。
      • 图片

  • 集群高性能

    • 本质：通过增加更多的服务器来提升系统整体的计算能力

    • 复杂性：增加任务分配器，以及选择一个合适的任务分配算法。(任务分配器，更通俗的叫法是 负载均衡器)

    • 负责均衡分类

      • DNS负载均衡：实现地理级别的负载均衡。例如北方用户访问北京的机房；南方用户访问深圳的机房。
      • 硬件负载均衡：通过单独的硬件设备来实现集群级别的负载均衡。这类设备和路由器交换机类似，可以理解为一个用于负载均衡的基础网络设备。
      • 软件负载均衡：通过负载均衡软件实现机器级别的负载均衡。

    • 负载均衡架构

      • 实际使用的时候，可以灵活地使用上述三种负载均衡方法，首先通过DNS负载均衡找到最近城市的服务器ip,通过硬件负载均衡找到城市对应的集群组，最后通过软件负载均衡在集群组内找到所需的集群。

    • 负载均衡的算法

      • 任务平分类：轮询、加权轮询
      • 负载均衡类：负载最低优先
      • 性能最优类：响应时间最短优先
      • Hash类：根据任务的某些关键信息进行hash运算，从而映射到指定主机
Last Updated:
Contributors: klc407073648