数据库集群：读写分离

• 原理：将数据库读写操作分散到不同的节点上。

  • 数据库服务器搭建主从集群，一主一从、一主多从都可以
  • 数据库主机负责读写操作，从机只负责读操作
  • 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据
  • 业务服务器将写操作发给数据库主机，将读操作发给数据库从机

• 存在问题：复制延迟

  • 解决方式1：写操作后的读操作指定发给数据库主服务器

    • 存在问题：和业务强绑定，对业务的侵入和影响较大

  • 解决方式2：读从机失败后再读一次主机

    • 优点：与业务无绑定，只需要在底层访问数据API接口做封装
    • 存在问题：要读两次，增加主机的访问压力

  • 解决方式3：关键业务读写操作全部指向主机，非关键业务采用读写分离

    • 存在问题：还是和业务强绑定，即要对业务做分级，关键业务不走读写分离

• 具体实现：分配机制

  • 实现1：程序代码封装

    • 在代码里面抽出一个数据访问层，实现读写操作分离和数据库服务器连接的管理。
    • 优点：实现简单，且可以做定制。
    • 缺点：每个编程语言都要实现一次；如果要做主从切换，则需要改代码或者配置，然后重启
    • 已有产品：TDDL

  • 实现2：中间件封装

    • 独立一套系统出来，实现读写操作分离和数据库服务器连接的管理。
    • 优点：支持多编程语言；主从切换等操作，业务服务器无感知
    • 缺点：实现复杂，容易出BUG；所有请求都走中间件系统，性能要求高；
    • 已有产品：MySQL Router（官方）、Atlas（360）

数据库集群：分库分表

• 业务分库

  • 定义：指的是按照业务模块将数据分散到不同的数据库服务器

  • 存在问题

    • join操作问题——无法使用join，只能业务层面分别查询
    • 事务问题——无法支持本地事务，而分布式事务性能又太差
    • 成本问题——需增加数据库机器

• 分表

  • 垂直分表

    • 定义：表记录数不变，但按照列切成多张表（例如原有A、B、C三列，切成A、B和A、C两张表）
    • 适用于将不常用的列单独切出去存储
    • 缺点：可以会涉及多次读写操作

  • 水平分表

    • 定义：列不变，将数据切成多份放在不同表里面

    • 路由算法

      • 范围路由：选取有序的数据列（例如整形）作为路由的条件，不同分段分散到不同的数据库表中

        • 优点：可以随着数据的增加平滑地扩充新的表
        • 不足：可能数据分布不均匀

      • Hash路由：将某一列或多列，按照hash分布在不同分表内

        • 优点：数据分布均匀
        • 不足：扩充新表麻烦，需要数据重新分布

      • 配置路由：新增一张路由表，记录原表每行数据对应的分表id

        • 优点：设计简单，需要扩充的时候只要迁移数据再修改路由表数据即可
        • 不足：需要多查询一次，切路由表本身会成为性能瓶颈

    • 分表后问题

      • join操作、count、order by等，都需要业务层面代码支持

  • 实现方式

    • 程序代码封装、中间件封装

高性能NoSQL

• 关系数据库存在的不足

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

• K-V存储

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

• 文档数据库

  • 解决关系数据库强 schema 约束的问题，以 MongoDB 为代表
  • 目前绝大部分文档数据库存储的数据格式是 JSON
  • 优点：新增字段简单、历史数据不会出错、很容易存储复杂数据
  • 不足：不支持事务、无法实现join操作

• 列式数据库

  • 解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表
  • 按照列来存储数据的数据库，与之对应的传统关系数据库被称为“行式数据库”
  • 优点：节省I/O、存储压缩比更大
  • 不足：频率更新多个列性能较差

• 全文搜索引擎

  • 解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表
  • 基本原理：倒排索引
  • 使用方式：关系型数据库的数据，转换成JSON，再输入全文搜索引擎做索引

高性能缓存

• 适用场景

  • 需要经过复杂运算后得出的数据
  • 读多写少的数据

• 缓存存在的问题

  • 缓存穿透

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

    • 出现该问题的两种情况

      • 存储数据确实不存在。解决方式是若不存在，也提供一个默认值存在缓存当中
      • 缓存数据生成耗费大量时间或者资源。当缓存失效时，由于生成缓存数据的时间较长，因此这段时间内的请求都会打到存储系统上。

  • 缓存雪崩

    • 定义：是指当缓存失效（过期）后引起系统性能急剧下降的情况。在生成新缓存的这段时间内，所有请求仍然会打到存储系统上。

    • 解决方式

      • 更新锁机制。对缓存更新操作进行加分布式锁保护，保证只有一个线程能够进行缓存更新，未能获取更新锁的线程要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

      • 后台更新机制。缓存本身的有效期设置为永久，后台线程定时更新缓存。

        • 注意存在内存不够，缓存数据被踢出的问题。此时两种解决方式：要么更新缓存的线程还要频繁读缓存，若发现被踢了则再写进去；或者业务线程发现缓存数据不存在，发消息通知，然后更新缓存线程收到消息来重新写缓存。

  • 缓存热点

    • 定义：对于一些特别热点的数据，如果大部分甚至所有的业务请求都命中同一份缓存数据，则这份数据所在的缓存服务器的压力也很大
    • 解决方式：复制多份缓存副本，将请求分散到多个缓存服务器上，减轻缓存热点导致的单台缓存服务器压力。

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

• PPC（Process Per Connection）

  • 定义：每次有新的连接就新建一个进程去专门处理这个连接的请求
  • 父进程流程：socket->bind->listen->accept->fork->close
  • 子进程流程：read->业务处理->write->close
  • 适用场景：服务器的访问量和并发量并没有那么大

  • 存在问题

    • fork代价高（要创建进程）、父子进程通信复杂（适用IPC等方案通信）、支持的并发连接数量有限（一般最大几百个）

• prefork

  • 定义：prefork 就是提前创建进程（pre-fork）。系统在启动的时候就预先创建好进程，然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去 fork 进程的操作
  • 父进程流程：socket->bind->listen->fork
  • 子进程流程：accept->read->业务处理->write->close
  • 实现关键就是多个子进程都accept同一个socket，当有新连接进入时，保证只有一个进程能最后accept成功

• TPC（Thread Per Connection）

  • 定义：每次有新的连接就新建一个线程去专门处理这个连接的请求
  • 优势：创建线程的消耗比进程要少得多；线程通信相比进程通信更简单
  • 主进程流程：socket->bind->listen->accept->pthread
  • 子线程流程：read->业务处理->write->close

  • 存在问题

    • 创建线程仍然有代价、可能出现死锁、多线程互相影响可能导致整个进程退出

• prethread

  • 定义：预先创建线程，然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去创建线程的操作
  • 主进程流程：socket->bind->listen->pthread
  • 子线程流程：accept->read->业务处理->write->close

单服务器高性能模式：Reactor与Proactor

• Reactor

  • 使用I/O多路复用技术

    • 当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待，而无须再轮询所有连接
    • 当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理
  • 核心组成：Reactor（负责监听和分配事件）、处理资源池（进程池/线程池）（负责处理事件）

  • 具体实现方式

    • 单Reactor单进程/线程

      • Reactor 对象通过 select 监控连接事件，收到事件后通过 dispatch 进行分发。
      • 如果是连接建立的事件，则由 Acceptor 处理，Acceptor 通过 accept 接受连接，并创建一个 Handler 来处理连接后续的各种事件。
      • 如果不是连接建立事件，则 Reactor 会调用连接对应的 Handler（第 2 步中创建的 Handler）来进行响应。
      • Handler 会完成 read-> 业务处理 ->send 的完整业务流程。

    • 单Reactor多线程

      • 主线程中，Reactor 对象通过 select 监控连接事件，收到事件后通过 dispatch 进行分发
      • 如果是连接建立的事件，则由 Acceptor 处理，Acceptor 通过 accept 接受连接，并创建一个 Handler 来处理连接后续的各种事件
      • 如果不是连接建立事件，则 Reactor 会调用连接对应的 Handler（第 2 步中创建的 Handler）来进行响应
      • Handler 只负责响应事件，不进行业务处理；Handler 通过 read 读取到数据后，会发给 Processor 进行业务处理
      • Processor 会在独立的子线程中完成真正的业务处理，然后将响应结果发给主进程的 Handler 处理；Handler 收到响应后通过 send 将响应结果返回给 client

    • 多Reactor多进程/线程

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

• Proactor

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

高性能负载均衡：分类及架构

• 高性能集群的复杂性主要体现在需要增加一个任务分配器，以及为任务选择一个合适的任务分配算法
• 负载均衡不只是为了计算单元的负载达到均衡状态，可以基于性能、负载、业务来考虑

• 负载均衡分类

  • DNS负载均衡

    • 优点：简单、成本低；就近访问，提升访问速度。
    • 不足：更新不及时，有DNS缓存；扩展性差，控制权在域名商；分配策略比较简单

  • 硬件负载均衡

    • 通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似
    • 典型的硬件产品：F5、A10
    • 优点：功能强大；性能强大；稳定性高；支持安全防护
    • 不足：贵；扩展性差

  • 软件负载均衡

    • 通过在普通服务器上运行负载均衡软件来实现负载均衡功能
    • 典型产品：Nginx（7层负载均衡）、LVS（4层负载均衡）
    • 优点：简单；便宜（用普通Linux服务器即可）；灵活可扩展
    • 不足：性能一般；功能没有硬件负载均衡强大；一般不具备防火墙和防 DDoS 攻击等安全功能

• 三种负载均衡可以同时使用

  • 基本原则：DNS 负载均衡用于实现地理级别的负载均衡；硬件负载均衡用于实现集群级别的负载均衡；软件负载均衡用于实现机器级别的负载均衡

高性能负载均衡：算法

• 算法分类

  • 任务平分类。将收到的任务平均分配给服务器进行处理（绝对平均或加权平均）
  • 负载均衡类。根据服务器的负载来进行分配（CPU load、连接数、I/O使用率等）
  • 性能最优类。根据服务器的响应时间来进行任务分配，优先将新任务分配给响应最快的服务器
  • Hash类。根据任务中的某些关键信息进行 Hash 运算，将相同 Hash 值的请求分配到同一台服务器上

• 具体算法

  • 轮询

    • 优点：最简单
    • 不足：不关注服务器本身状态（只要没宕机或断线）；不关心服务器之间性能差异（加权轮询解决了该问题）

  • 负载最低优先

    • 将任务分配给当前负载最低的服务器。具体负载指标可以有多个（CPU load、连接数等）
    • 优点：感知服务器本身状态
    • 不足：复杂

  • 性能最优

    • 性能最优优先类算法是站在客户端的角度来进行分配的，优先将任务分配给处理速度最快的服务器
    • 优点：同样感知服务器本身状态（通过响应时间）
    • 不足：复杂（收集和统计响应时间本身性能有损耗，采样率和统计周期的设置都有讲究）

  • Hash类

    • 常见两种场景：按源地址Hash，按请求ID Hash