高性能架构

02-29 1117阅读

高性能数据库集群：读写分离

基本实现

数据库服务器搭建主从集群，一主一从、一主多从都可以
数据库主机负责读写操作，从机只负责读操作
- 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储所有的业务数据
- 业务服务器将写操作发给数据库主机，将读操作发送给数据库从机
  注意点
  
  主从复制延迟
  
  解决办法
  - 写操作后的读操作指定发送给数据库主服务器
    - - 对业务的侵入性和影响较大
      - 读从机失败后再读一次主机
        
        如果有很多二次读取，将大大增加主机的读操作压力
        关键业务读写操作全部指向主机，非关键业务采取读写分离
        分配机制
        
        将读写操作区分开，然后访问不同的数据库服务器，一般有两种方式：程序代码封装和中间件封装。
        
        程序代码封装
        
        程序代码封装指在代码中抽象一个数据访问层，实现读写操作分离和数据库服务器连接的管理。
        
        实现简单，而且可以根据业务做较多定制化的功能。
        每个编程语言都需要自己实现一次，无法通用，如果一个业务包含多个编程语言写的多个子系统，则重复开发的工作量比较大。
        故障情况下，如果主从发生切换，则可能需要所有系统都修改配置并重启。
        中间件封装
        
        中间件封装指的是独立一套系统出来，实现读写操作分离和数据库服务器连接的管理。
        
        高性能数据库集群：分库分表
        
        单个数据库服务器存储的数据量不能太大，需要控制在一定的范围内。为了满足业务数据存储的需求，就需要将存储分散到多台数据库服务器上。
        
        业务分库
        
        按照业务模块将数据分散到不同的数据库服务器。
        
        问题：join问题、事务问题、成本问题
        
        分表
        
        垂直分表和水平分表
        
        路由
        
        水平分表后，某条数据具体属于哪个切分后的子表，需要增加路由算法进行计算，这个算法会引入一定的复杂性。
        
        范围路由
        
        选取有序的数据列（例如，整形、时间戳等）作为路由的条件，不同分段分散到不同的数据库表中。
        
        hash路由
        
        选取某个列（或者某几个列组合也可以）的值进行 Hash 运算，然后根据 Hash 结果分散到不同的数据库表中。
        
        配置路由
        
        配置路由就是路由表，用一张独立的表来记录路由信息。
        
        join操作
        
        水平分表后，数据分散在多个表中，如果需要与其他表进行 join 查询，需要在业务代码或者数据库中间件中进行多次 join 查询，然后将结果合并。
        
        count()操作
        
        count() 相加
        记录数表
        order by()操作
        
        水平分表后，数据分散到多个子表中，排序操作无法在数据库中完成，只能由业务代码或者数据库中间件分别查询每个子表中的数据，然后汇总进行排序。
        
        高性能nosql
        
        K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。
        
        事务
        
        文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。
        
        关联查询效率
        
        列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。
        
        针对单列数据的操作
        
        全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。
        
        高性能缓存
        
        缓存穿透
        
        缓存雪崩
        
        数据库缓存和独立缓存的主要区别
        
        可控性和性能
        
        mysql第一种缓存叫sql语句结果缓存，但条件比较苛刻，程序员不可控，我们的dba线上都关闭这个功能，具体实现可以查一下
        mysql第二种缓存是innodb buffer pool，缓存的是磁盘上的分页数据，不是sql的查询结果，sql的执行过程省不了。而mc，redis这些实际上都是缓存sql的结果，两种缓存方式，性能差很远。
        单服务器高性能模式：PPC与TPC
        
        高性能架构设计主要集中在两方面：
        
        尽量提升单服务器的性能，将单服务器的性能发挥到极致
        如果单服务器无法支撑性能，设计服务器集群方案
        服务器的并发模型
        
        服务器如何管理连接
        服务器如何处理请求
        I/O模型：阻塞、非阻塞、同步、异步
        进程模型：单线程、多进程、多线程
        PPC
        
        PPC 是 Process Per Connection 的缩写，其含义是指每次有新的连接就新建一个进程去专门处理这个连接的请求，这是传统的 UNIX 网络服务器所采用的模型。
        
        PPC模式实现简单，比较适合服务器的连接数没那么多的情况，例如数据库服务器。
        
        弊端
        
        fork代价高，创建一个进程的代价很高
        父子进程通信复杂
        支持的并发连接数量有限（几百）
        profork
        
        PPC模式中，当连接进来时才fork新进程来处理连接请求，由于fork进程代价高，用户访问时可能感觉比较慢，prefork模式的出现就是为了解决这个问题。
        
        prefork 就是提前创建进程（pre-fork）。系统在启动的时候就预先创建好进程，然后才开始接受用户的请求，当有新的连接进来的时候，就可以省去 fork 进程的操作，让用户访问更快、体验更好。
        
        prefork 的实现关键就是多个子进程都 accept 同一个 socket，当有新的连接进入时，操作系统保证只有一个进程能最后 accept 成功。但这里也存在一个小小的问题：“惊群”现象，就是指虽然只有一个子进程能 accept 成功，但所有阻塞在 accept 上的子进程都会被唤醒，这样就导致了不必要的进程调度和上下文切换了。幸运的是，操作系统可以解决这个问题，例如 Linux 2.6 版本后内核已经解决了 accept 惊群问题。prefork 模式和 PPC 一样，还是存在父子进程通信复杂、支持的并发连接数量有限的问题，因此目前实际应用也不多。Apache 服务器提供了 MPM prefork 模式，推荐在需要可靠性或者与旧软件兼容的站点时采用这种模式，默认情况下最大支持 256 个并发连接。
        
        TPC
        
        TPC 是 Thread Per Connection 的缩写，其含义是指每次有新的连接就新建一个线程去专门处理这个连接的请求。与进程相比，线程更轻量级，创建线程的消耗比进程要少得多；同时多线程是共享进程内存空间的，线程通信相比进程通信更简单。
        
        和 PPC 相比，主进程不用“close”连接了。原因是在于子线程是共享主进程的进程空间的，连接的文件描述符并没有被复制，因此只需要一次 close 即可。
        
        TPC 方案本质上和 PPC 方案基本类似，在并发几百连接的场景下，反而更多地是采用 PPC 的方案，因为 PPC 方案不会有死锁的风险，也不会多进程互相影响，稳定性更高。
        
        prethread
        
        TPC 模式中，当连接进来时才创建新的线程来处理连接请求，虽然创建线程比创建进程要更加轻量级，但还是有一定的代价，而 prethread 模式就是为了解决这个问题。
        
        单服务器高性能模式：Reactor与Proactor
        
        Reactor
        
        I/O 多路复用技术归纳起来有两个关键实现点
        
        当多条连接共用一个阻塞对象后，进程只需要在一个阻塞对象上等待，而无须再轮询所有连接，常见的实现方式有 select、epoll、kqueue 等。
        
        当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理。
        
        I/O 多路复用结合线程池，完美地解决了 PPC 和 TPC 的问题。
        
        Reactor 模式的核心组成部分包括 Reactor 和处理资源池（进程池或线程池），其中 Reactor 负责监听和分配事件，处理资源池负责处理事件。
        
        Reactor 模式有这三种典型的实现方案：
        
        单 Reactor 单进程 / 线程。
        
        单 Reactor 多线程。
        
        多 Reactor 多进程 / 线程。
        
        Proactor
        
        Reactor 是非阻塞同步网络模型，因为真正的 read 和 send 操作都需要用户进程同步操作。这里的“同步”指用户进程在执行 read 和 send 这类 I/O 操作的时候是同步的，如果把 I/O 操作改为异步就能够进一步提升性能，这就是异步网络模型 Proactor。
        
        总结
        
        IO操作分两个阶段
        1、等待数据准备好(读到内核缓存)
        2、将数据从内核读到用户空间(进程空间)
        一般来说1花费的时间远远大于2。
        1上阻塞2上也阻塞的是同步阻塞IO
        1上非阻塞2阻塞的是同步非阻塞IO，这讲说的Reactor就是这种模型
        1上非阻塞2上非阻塞是异步非阻塞IO，这讲说的Proactor模型就是这种模型
        
        高性能负载均衡：分类及架构
        
        分类
        
        DNS负载均衡
        
        DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。
        
        硬件负载均衡
        
        软件负载均衡
        
        软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS，其中 Nginx 是软件的 7 层负载均衡，LVS 是 Linux 内核的 4 层负载均衡。
        
        典型架构
        
        
        
        高性能负载均衡：算法
        
        任务平分类：负载均衡系统将收到的任务平均分配给服务器进行处理，这里的“平均”可以是绝对数量的平均，也可以是比例或者权重上的平均。
        
        负载均衡类：负载均衡系统根据服务器的负载来进行分配，这里的负载并不一定是通常意义上我们说的“CPU 负载”，而是系统当前的压力，可以用 CPU 负载来衡量，也可以用连接数、I/O 使用率、网卡吞吐量等来衡量系统的压力。
        
        性能最优类：负载均衡系统根据服务器的响应时间来进行任务分配，优先将新任务分配给响应最快的服务器。
        
        Hash 类：负载均衡系统根据任务中的某些关键信息进行 Hash 运算，将相同 Hash 值的请求分配到同一台服务器上。常见的有源地址 Hash、目标地址 Hash、session id hash、用户 ID Hash 等。
        
        轮询
        加权轮询
        负载最低优先
        性能最优
        hash类
        源地址hash、idhash