CFC例会归档 - 枫阿雨's blog

团队协作项目及准备内容 – CFC 例会 2023.2.27

crazyfay — Mon, 27 Feb 2023 06:20:40 +0000

CFC-PPCS

项目流程协作系统

1. 项目参考

开源项目

Pear Project - 梨子项目管理系统 | 轻量级的在线项目/任务协作系统 (vilson.xyz) (本家主站)

Pear Project (vilson.xyz) (功能体验) 官方账号: 18681140825 密码: 123456

a54552239/pearProjectApi: 后端代码 (github.com) (后端源码为php)

a54552239/pearProject: 前端代码 (github.com) (前端源码为Vue2)

2. 服务端架构

go语言实现，采用原生gRPC微服务架构，api层采用Gin框架，ORM层采用Gorm框架，etcd作为注册中心，MinIO作为对象存储，数据库采用MySQL与非关系型数据库Redis，MySQL采用 ProxySQL + MGR 的高可用集群（业务无感知，代码无侵入）。在后续迭代升级中，可进一步采用nacos作为配置中心，引入Jaeger分布式链路追踪与ELK日志采集模块。

3. 项目结构

3.0 go workspace

便于不同模块本地开发相互引用

3.1 api

处理前端发来的http请求，通过etcd发现服务进行grpc调用服务

project-api
├── api
│   ├── api.go              匿名导入其他模块api的依赖
│   ├── middle              Gin中间件目录
│   │   └── middleware.go
│   └── user                按模块将api分组
│       ├── route.go        注册路由，构建路由树
│       ├── rpc.go          初始化rpc客户端
│       └── user.go         api方法实现
├── config
│   ├── config.go           初始化、读取配置
│   └── config.yaml         配置文件
├── go.mod
├── go.sum
├── main.go                 启动方法
├── pkg
│   └── model               数据传输模型（dto）
│       ├── page.go         格式化分页配置
│       └── user            按模块分类
│           └── user.go     用户模块传输模型
└── router                  
    └── router.go           路由注册方法

3.2 common

通用工具模块

3.3 grpc

protoc 生成的pb文件

3.4 mico service

包含具体业务逻辑的服务模块，内部代码结构参考

CFC Studio Golang开发规范项目结构核心部分示例 (kirov7.github.io)

.
├── api                             暂时存放proto文件
│   └── proto
│       ├── gen                     暂时存放proto编译后文件  
│       ├── gen.bat                 编译脚本(仅仅为了方便，下同)
│       ├── gen.sh
│       └── loginService.proto      proto文件，定义grpc服务方法与数据
├── config
│   ├── config.go
│   └── config.yaml
├── go.mod
├── go.sum
├── internal                        数据模型与数据操作，对外不可见
│   ├── dao                         数据访问层，实现repo的接口对数据表进行操作
│   │   ├── member.go               封装对于member表的数据操作的实现
│   │   ├── organization.go
│   │   ├── redis.go                封装redis操作，实现repo.cache的接口
│   │   └── trans.go                实现自定义的事务操作接口，封装事务的操作框架
│   ├── data                        数据库映射结构体与部分模型转换方法
│   │   ├── member                  按数据表划分
│   │   │   └── member.go           member表与结构体的映射
│   │   └── organization
│   │       └── organization.go     organization表与结构体的映射
│   ├── database                    封装数据库连接
│   │   ├── conn.go                 数据库连接的抽象接口
│   │   ├── gorms
│   │   │   └── gorm.go             gorm实现的数据库连接接口
│   │   └── transaction             事务操作的接口
│   │       └── transaction.go
│   ├── domain                      领域层，封装领域的行为操作
│   │   ├── member.go               
│   │   └── organization.go
│   ├── interceptor                 grpc拦截器
│   └── repo                        封装数据查询的接口
│       ├── cache.go                缓存操作的接口
│       ├── member.go               抽象对member数据表的操作
│       └── organization.go
├── main.go                         启动方法，执行各种初始化操作
├── pkg                             服务具体实现与所依赖的常量与全局变量
│   ├── model                       常量与全局变量
│   │   ├── biz.go                  业务逻辑中用到的常量/枚举值
│   │   ├── code.go                 封装的错误代码
│   │   └── redisKey.go             Redis Key的前缀
│   └── service                     grpc方法的实现
│       └── login.service.v1        调用domian整理组合数据实现业务需求
│           └── loginService.go
└── router
    └── router.go                   grpc与etcd注册与路由

3.4.1 user

用户、组织等

3.4.2 project

项目、任务等

4. 项目组件与通用模块介绍

4.1 etcd

作用：用作服务注册，与服务发现

4.2 MinIO

作用：本地部署的对象存储OSS，用在项目附件等需求文件存储的地方

4.3 Redis

作用：部分用户信息存储(缓存token)、验证码存储、缓存优化等

可视化工具：

Another Redis Desktop Manager | 更快、更好、更稳定的Redis桌面(GUI)管理客户端，兼容Windows、Mac、Linux，性能出众，轻松加载海量键值 (goanother.com)

4.4 ProxySQL + MGR

作用：

MGR：MySQL Group Replication（Mysql组复制），基于paxos算法的强一致性的高可用、高拓展、高可靠MySQL集群方案

带你走进MySQL全新高可用解决方案-MGR - 知乎 (zhihu.com)
ProxySQL：灵活强大的MySQL代理层，通过伪装成MySQL服务端，代理执行SQL语句，并负责读写分离、节点探活、故障无感知转移等

【sql】MySQL-ProxySQL中间件的使用 - 知乎 (zhihu.com)

理论上在ProxySQL外层还需加一层keepalived配置VIP，资源有限，暂且忽略

5. 其他内容

5.1 开发规范

参考我整理的规范

Kirov7/cfc-golang-develop-norms: CFC Studio 内部Golang开发规范 (github.com)

5.2 准备环境

服务端所需的中间件环境以在203的内网服务器中部署完成，可放心使用

5.3 代码托管平台

代码托管平台放在实验室私有仓库 gitea 上

团队协作项目及准备内容 – CFC 例会 2023.2.27最先出现在枫阿雨's blog。

WEB服务端系统架构演进概述 – CFC例会2022.9.18

crazyfay — Sun, 18 Sep 2022 06:20:10 +0000

注：本系列内容为个人整理与总结的架构演进的鸟瞰图，其中部分概念的解释由我个人总结得出，仅代表我个人的理解，难免存在纰漏，如有任何问题均可随时提出并指正

服务端 or 客户端

什么是服务端和客户端，它和前端后端有什么关联和区别

认识 “服务”

服务，是根据功能抽象出的概念。比如说，处理用户登录信息的认证服务,负责持久化存储数据的数据库服务，以及为了加快查询速度的缓存服务等

服务、进程、端口？

端口的主要作用是表示一台计算机中的特定进程所提供的服务。网络中的计算机是通过 IP地址 来代表其身份的，它只能表示某台特定的计算机，但是一台计算机上可以同时提供很多个服务，如数据库服务、FTP服务(文件传输)、Web服务等，我们就通过端口号来区别相同计算机所提供的这些不同的服务，如常见的端口号80表示的是HTTP服务端口，端口号3306是MySQL的默认端口号，端口号8080是Java的开源的流行Web应用服务器Tomcat的默认端口号等。一个IP地址的端口通过16bit进行编号，最多可以有65536个端口，即端口号的取值范围是0 ~ 65535，其中0～1023是被规定好了的，被称作“众所周知的端口”(Well Known Ports)，且在同一台计算机上端口号不能重复，否则，就会产生端口号冲突这样的例外

Go语言搭建一个最简单的Web服务器

http://192.168.1.151:9999

package main

import (
    "fmt"
    "net/http"
)

func IndexHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "hello world")
}

func main() {
    http.HandleFunc("/", IndexHandler)
    http.ListenAndServe(":9999", nil)
}

前端后端，分？还是不分？

我们所说的前后端分离到底是什么样的

前后端一体模板引擎渲染方式的架构示例：

现流行的前后端分离式架构示例：CSR

前后端分离的优势与劣势

优势：
1. 以实现真正的前后端解耦，优化开发流程，划分职责界限
2. 减少后端服务器的并发负载压力
3. 更友好的错误提示
  
  ...
劣势：
1. 前端响应较慢，资源消耗严重，在业务复杂的情况下，一个页面可能要发起多次HTTP请求才能将页面渲染完毕，且在Json返回的数据量比较大的情况下，渲染的十分缓慢，会出现页面卡顿的情况
2. 不利于SEO，搜索引擎的爬虫无法爬下JS异步渲染的数据

为了解决不足，后续在前后端分离的基础上衍生出了引入NodeJS作为中间层的进行服务端渲染的架构方案......

服务端与客户端的交互

数据传递主要方式：

form表单
ajax
- Ajax(Asynchronous JavaScript and XML) 异步JavaScript和XML，一种用于创建快速动态网页的异步刷新技术。通过在后台与服务器进行少量数据交换，AJAX 可以使网页实现异步更新。即可以在不重新加载整个网页的情况下，对网页的某部分进行更新。

数据传递主要格式：

XML
JSON
- JSON(JavaScript Object Notation,) 是一种轻量级的数据交换格式，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。易于阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。

前后端 JSON通信API示例

评论列表功能

接口url：/comments/article/{id}

请求方式：GET

请求参数：

参数名称	参数类型	说明
id	long	文章id（路径参数）

返回数据：

{
    "success": true,
    "code": 200,
    "msg": "success",
    "data": [
        {
            "id": 1,
            "author": {
                "nickname": "GodLanBo",
                "avatar": "http://tva1.sinaimg.cn/large/005Uj3w8ly1h68mgfr3bcj31hc0u0mz9.jpg",
                "id": 202
            },
            "content": "很久没和朋友去唱歌了🎤，一下午嗓子都莫得了「=。=」",
            "childrens": [
                {
                    "id": 2,
                    "author": {
                        "nickname": "群垫底",
                        "avatar": "http://tva1.sinaimg.cn/large/005Uj3w8ly1h68mgfr3bcj31hc0u0mz9.jpg",
                        "id": 203
                    },
                    "content": "和朋友一起玩桌游，简简单单四个角色，玩不腻=。=",
                    "childrens": [],
                    "createDate": "2013-01-14 20:30",
                    "level": 2,
                    "toUser": {
                        "nickname": "GodLanBo",
                        "avatar": "http://tva1.sinaimg.cn/large/005Uj3w8ly1h68mgfr3bcj31hc0u0mz9.jpg",
                        "id": 1
                    }
                }
            ],
            "createDate": "2013-01-14 02:03",
            "level": 1,
            "toUser": null
        }
    ]
}

JSON应用示例

http://120.48.87.191:9998

代码实例通过共享屏幕展示

被追认的名号 - 单体架构

“单体”只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已。

什么是单体架构

“单体架构”在整个软件架构演进的历史进程里，是出现时间最早、应用范围最广、使用人数最多、统治历史最长的一种架构风格，但“单体”这个名称，却是在微服务开始流行之后才“事后追认”所形成的概念。

单体架构不可拆分？

说起单体架构、巨石系统的缺点时，在脑海中闪过的第一个特点就是它的“不可拆分”，难以扩展，因此才不能支撑越来越大的软件规模。这种想法看似合理，其实是有失偏颇的，至少不完整。

从纵向角度看，没有哪个系统是不分层的，分层架构（Layered Architecture）已是现在几乎所有信息系统建设中都普遍认可、采用的软件设计方法，无论是单体还是微服务，抑或是其他架构风格，都会对代码进行纵向层次划分，收到的外部请求在各层之间以不同形式的数据结构进行流转传递，触及最末端的数据库后按相反的顺序回馈响应，如图所示。对于这个意义上的“可拆分”，单体架构完全不会展露出丝毫的弱势，反而可能会因更容易开发、部署、测试而获得一些便捷性上的好处。

从横向角度来看，单体架构也可以支持按照技术、功能、职责等维度，将软件拆分为各种模块，以便重用和管理代码。横向扩展（Scale Horizontally）的角度来衡量，在负载均衡器之后同时部署若干个相同的单体系统副本，以达到分摊流量压力的效果。

拓展：三层架构与MVC架构

三层架构

对应上图的Presentation Layer、Business Layer、Persistence Layer

三层架构有时也被称作：表示层(web层)、业务逻辑层(service层)、数据访问层(dao层)

三层架构是从整个业务应用角度对程序的划分，其分层逻辑来源于“高内聚，低耦合”的思想。

1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
MVC架构

MVC模式实现了数据和视图的分离

属于组合设计模式的范畴，就如同其他设计模式一样，模式的出现就是为了对某种功能的优化，而MVC模式可以看做是对三层架构中表现层的一种细分优化。

1、模型（Model）：模型持有所有的数据、状态和程序逻辑。模型独立于视图和控制器。
2、视图（View）：用来呈现模型。视图通常直接从模型中取得它需要显示的状态与数据。对于相同的信息可以有多个不同的显示形式或视图。
3、控制器（Controller）：位于视图和模型中间，负责接受用户的输入，将输入进行解析并反馈给模型。

MVC架构工作流程：

（1）用户通过 View 页面向服务端提出请求，可以是表单请求、超链接请求、AJAX 请求等
（2）服务端 Controller 控制器接收到请求后对请求进行解析，找到相应的 Model 对用户请求进行处理
（3）Model 处理后，将处理结果再交给 Controller
（4）Controller 在接到处理结果后，根据处理结果找到要作为向客户端发回的响应 View 页面。页面经渲染（数据填充）后，再

三层架构和MVC架构的关联

在当下前后端分离的主流趋势下，MVC架构进行不断的改进，但其中数据与视图分离的思想是一直受用的。

可以简单的认为前后端分离将View从后端中分离了出来交给前端处理，即浏览器发送Ajax请求，然后服务端接受该请求并返回JSON数据返回给浏览器，最后在浏览器中进行界面渲染。

即如图所示：

单体架构的优点与瓶颈

对于小型系统——即由单台机器就足以支撑其良好运行的系统，单体不仅易于开发、易于测试、易于部署，且由于系统中各个功能、模块、方法的调用过程都是进程内调用，不会发生进程间通信（Inter-Process Communication，IPC。广义上讲，可以认为 RPC 属于 IPC 的一种特例，这里两个“PC”不是同个单词的缩写），因此也是运行效率最高的一种架构风格。

只有基于软件的性能需求超过了单机，软件的开发人员规模明显超过了“2 Pizza Team的"大型的单体架构系统"才能更明显的体现出单体架构的瓶颈。

在“拆分”这方面，单体系统的真正缺陷不在如何拆分，而在拆分之后的隔离与自治能力上的欠缺。由于所有代码都运行在同一个进程空间之内，所有模块、方法的调用都无须考虑网络分区、对象复制这些麻烦的事和性能损失。获得了进程内调用的简单、高效等好处的同时，也意味着如果任何一部分代码出现了缺陷，过度消耗了进程空间内的资源，所造成的影响也是全局性的、难以隔离的。譬如内存泄漏、线程爆炸、阻塞、死循环等问题，都将会影响整个程序，而不仅仅是影响某一个功能、模块本身的正常运作。如果消耗的是某些更高层次的公共资源，譬如端口号或者数据库连接池泄漏，影响还将会波及整台机器，甚至是集群中其他单体副本的正常工作。

同样，由于所有代码都共享着同一个进程空间，不能隔离，也就很难做到单独停止、更新、升级某一部分代码，因为不可能有“停掉半个进程，重启 1/4 个程序”这样不合逻辑的操作，所以从可维护性来说，单体系统也是不占优势的。程序升级、修改缺陷往往需要制定专门的停机更新计划，做灰度发布、A/B 测试也相对更复杂。

由于隔离能力的缺失，单体除了难以阻断错误传播、不便于动态更新程序以外，还面临难以技术异构的困难，每个模块的代码都通常需要使用一样的程序语言，乃至一样的编程框架去开发。

为了允许程序出错，为了获得隔离、自治的能力，为了可以技术异构等目标，是继为了性能与算力之后，让程序选择分布式又一个理由。

集群与分布式架构

从追求“尽量不出错”，到正视“出错是必然”

集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源，这些单个的计算机系统就是集群的节点（node）。集群提供了以下关键的特性。

可扩展性。集群的性能不限于单一的服务实体，新的服务实体可以动态的加入到集群，从而增强集群的性能。
高可用性。集群通过服务实体冗余使客户端免于轻易遭遇到“out of service”警告。当一台节点服务器发生故障的时候，这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的。
负载均衡。负载均衡能把任务比较均匀的分布到集群环境下的计算和网络资源，以便提高数据吞吐量。
错误恢复。如果集群中的某一台服务器由于故障或者维护需要而无法使用，资源和应用程序将转移到可用的集群节点上。这种由于某个节点中的资源不能工作，另一个可用节点中的资源能够透明的接管并继续完成任务的过程叫做错误恢复。

一个比较典型的例子，由Nginx负载的多web节点集群架构。

分布式系统是一组计算机，透过网络相互连接传递消息与通信后并协调它们的行为而形成的系统。组件之间彼此进行交互以实现一个共同的目标。

分布式与集群的联系与区别如下：

(一) 分布式是指将不同的业务分布在不同的地方。

(二) 而集群指的是将几台服务器集中在一起，实现同一业务。

(三) 分布式的每一个节点，都可以做集群，而集群并不一定就是分布式的。而分布式，从狭义上理解，也与集群差不多，但是它的组织比较松散，不像集群，有一定组织性，一台服务器宕了，其他的服务器可以顶上来。分布式的每一个节点，都完成不同的业务，一个节点宕了，这个业务就不可访问了。

革命性质的探索 - 面向服务的架构(SOA)

面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。

垂直拆分与服务拆分

在前面提到的各种将服务进行拆分方法，最终的效果都是单体的，每个最终运行的服务都是包含了所有功能的整体，这就会导致每个运行的服务中的任意应用出现问题时都会影响到整个服务，也就是前面提到的隔离与自治能力上的欠缺。但是如果当某些应用相对独立，与其他应用没有直接交互的情况下（比如不同的报表生成业务应用），我们可以尝试将其进行垂直拆分，将互不直接影响的应用搬到不同的进程上运行，这样，当某一应用发生问题之后，其爆炸半径不会直接波及到其他独立的正常运行的应用。但是老死不相往来的应用比较稀少，这种垂直拆分并没有太高的工程实践上的可行性。

但是既然可以根据应用把架构做垂直拆分，那么根据模块/职责对架构进行水平拆分并相互建立通信的方式是否有可行性呢？

按照这个思路，可以把原本包含了众多复杂逻辑的模块，按照功能但愿抽象成多个服务，以服务为一等公民，并为服务之间的通信定义标准，随后便演进出了SOA架构的雏形。

再谈服务与通信标准

服务，是根据功能抽象出的概念。比如说，处理用户登录信息的认证服务，负责持久化存储数据的数据库服务，以及为了加快查询速度的缓存服务等
通讯标准，是服务之间通信的基石。没有实现定义好的通信标准，不同服务之间就不能相互调用，难以协作

为了服务之间更好的通信，有两个大的发展方向：中心化和去中心化。在历史的进程中，率先冲锋的便是中心化的模式。

SOA 的野蛮生长

如图所示两种SOA发展中有代表性的SOA架构。当系统演化至事件驱动架构时，远程服务调用协议SOAP诞生了。此时“面向服务的架构”（Service Oriented Architecture，SOA）已经有了它登上软件架构舞台所需要的全部前置条件。许多巨头科技公司一起创立了Open CSA (opens new window)组织（Open Composite Services Architecture），这便是 SOA 的官方管理机构。OpenCAS制定了一系列精密严谨成体系的基础平台与技术组件，从技术可行性上 SOA 成功地解决了分布式环境下出现的主要技术问题。

不同的服务间采用 SOAP 作为远程调用的协议，利用一个被称为企业服务总线 (opens new window)（Enterprise Service Bus，ESB）的消息管道来实现各个子系统之间的通信交互，初次之外还定义了很多其他的组件严谨的解决了多方面的问题。

但是，过于严格的规范定义带来过度的复杂性。而构建在 SOAP 基础之上的 ESB、BPM、SCA、SDO 等诸多上层建筑，进一步加剧了这种复杂性。过于精密的流程和理论也需要懂得复杂概念的专业人员才能够驾驭。最终很难作为一种具有广泛普适性的软件架构风格来推广。

遍地开花的时代 - 微服务架构

当SOA革命以最终无人问津的结局告终之时，去中心化的分布式方案在悄然生长，而去中心化的最终形态，就是微服务架构。

微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

在微服务时代，以服务来划分团队工作，服务对应的开发团队有直接对服务运行质量负责的责任，也应该有着不受外界干预地掌控服务各个方面的权力，譬如选择与其他服务异构的技术来实现自己的服务。

微服务明确地提倡数据应该按领域分散管理、更新、维护、存储，在单体服务中，一个系统的各个功能模块通常会使用同一个数据库，诚然中心化的存储天生就更容易避免一致性问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。譬如，Bookstore 应用中的书本，在销售领域中关注的是价格，在仓储领域中关注的库存数量，在商品展示领域中关注的是书籍的介绍信息，如果作为中心化的存储，所有领域都必须修改和映射到同一个实体之中，这便使得不同的服务很可能会互相产生影响而丧失掉独立性。因此，服务拆分，数据库也进行拆分，松解服务之间的耦合，每个团队可以更专注于自身负责的业务，也分散减轻了数据库的访问压力。

微服务组件

注册中心

注册中心可以说是微服务架构中的地址簿，它记录了服务和服务地址的映射关系，在分布式架构中，服务会注册到这里，当服务需要调用其他服务时，就在这里找到服务的地址，进行调用。

服务注册中心给客户端提供可供调用的服务列表，客户端在进行远程服务调用时，根据服务列表然后选择服务提供方的服务地址进行服务调用。服务注册中心在分布式系统中大量应用，是分布式系统中不可获取的组件。
注册中心是整个服务调用的核心部分，如果服务不存在注册中心，那么通过网关会调用不到，导致失败。

配置中心

管理各个环境的配置文件参数，比如说数据库，缓存，存储，业务应用并且支持管理每个不同的环境的配置。

本地配置在服务启动加载，修改配置不需要重启服务
多个环境（dev，prod，sit，uat）容易混淆，会产生错误，导致服务运行异常
出现配置错误时，不容易回滚到指定的版本

API网关

API网关是微服务架构中提供路由转发与鉴权等功能，首先，它会提供最基本的路由服务，将客户端请求转发后台业务服务；其次，作为一个入口，它还可以进行认证，鉴权，限流等操作。

客户端访问的统一对接接口
防止内部接口直接暴露给外部客户端（隐藏内部服务）
API网关通过提供一个额外的保护层来防止恶意攻击，例如SQL注入，XML解析器漏洞和拒绝服务
服务网关的前置过滤器中，所有请求过来进行权限校验
日志访问与审计

服务限流

服务限流：指当系统资源不够的情况下，不足以应对大量的用户与数据接口请求时，为了保证优先的资源能够正常服务，因此对系统按照预设的规则进行流量限制或功能限制的一种方法。

发生错误或者超时，不让调用接口，调用本地fallback（容错）
解决高并发请求，一旦达到规定请求，熔断，报错

链路跟踪

调用链是整个分布式系统中跟踪一个用户请求的过程，包括数据采集，数据传输，数据存储，数据分析和数据可视化展示工具，也是微服务中代码的调试和服务监控的性能分析工具。

分布式web系统中，客户端的一次请求操作，可能需要经过系统中多个模块，多个中间件，多台机器的相互协作才能完成，并且这一系列调用请求中，有些是串行处理的，有些是并发执行的，那么如何确定客户端的一次操作背后调用了哪些应用，哪些模块，经过了哪些节点，每个模块的调用先后顺序是怎样的，每个模块的性能问题如何？随着业务系统模型的日趋复杂化，分布式系统中继续一套链路追踪（trace）系统来解决这些问题（快速定位）。

RPC调用

RPC就是从一台机器（客户端）上通过参数传递的方式调用另一台机器（服务器）上的一个函数或方法（可以统称为服务）并得到返回的结果。
RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯） RPC 是一个请求响应模型。
客户端发起请求，服务器返回响应（类似于Http的工作方式） RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。

微服务架构实例

烂大街的谷粒商城项目

云计算与云原生

如今被炒的火热的云计算和云原生到底是什么

虚拟化与容器技术

因为不同的应用或者程序可能并不适用于同一个系统中，理想状态下可以每台服务器用于一个特定的任务或者应用程序，但问题是，但多数服务器在运行计算时只会使用他们整体处理能力的一小部分，不能充分利用服务器的处理能力。

虚拟化就解决了这个问题，将多台服务器整合到一台服务器中，运行多个虚拟环境，每个VM都有自己的操作系统（这些操作系统可以是不同的），可以在其上安装应用程序。

虚拟机的设计原理彼此间是隔离的，并且与虚拟主机隔离，这意味着一个应用程序中的安全问题不会影响在另一个虚拟机中运行的另一个应用程序。同样，如果一个应用程序崩溃并需要重新启动服务器，那么可以重新启动它的VM，而不影响任何其他VM的运行。此外虚拟化还有利于可扩展性，VM是以计算机文件的形式存在的，因此这个文件可以很容易地通过网络(甚至通过存储介质)复制或移动到新的虚拟主机上，也就有了更强的可移植性。

但是虚拟机模拟了整个操作系统，而这层操作系统往往都是可以通用的，即VM的操作相对更重，将操作系统复制了多份造成了一些不必要的开销，一台服务器中可以运行的虚拟机数量比较有限。

于是，可以共享操作系统的容器技术登上了舞台

与虚拟化相反，容器主机需要运行自己的操作系统以及容器系统。容器由单个应用程序（或微服务）以及需要运行的其他重要文件组成，利用容器主机的操作系统内核、二进制文件和库来运行。这些共享文件作为只读文件公开给容器。在容器主机上运行的其他容器也共享主机的内核、二进制文件和库。容器技术的核心（以Docker为例），主要基于Linux内核提供资源操作，进行资源隔离(namespace)、资源分配控制(Cgroup)、镜像的制作与加载(UnionFS)。

由于容器比虚拟机“轻”得多，并且启动速度也快得多，这也使得它们成为运行微服务的理想工具，当对微服务的需求扩大时，可以启用容器，当需求减少时可以删除。它们也可以在公有云和私有云以及传统数据中心之间轻松移动。

虚拟机与容器

由于多个容器之间使用的还是同一个宿主机的操作系统内核，因此导致了容器与虚拟机之间存在一些重要区别：

容器比虚拟机小得多或“轻”得多，通常由几兆字节组成，并且所需的硬件资源也少得多。这意味着一台物理服务器可以承载的容器比虚拟机要多得多。
容器可以在几秒甚至几毫秒内启动。相比之下，虚拟机的启动时间比较长。
由于容器都共享其主机的操作系统，因此所有应用程序都必须在同一操作系统上运行。相比之下，运行在虚拟主机上的虚拟机可以运行不同的操作系统（例如Linux，Unix和Windows）。
使用容器时，只需要对容器主机的操作系统进行补丁和更新。而虚拟机则需对每个操作系统都进行补丁和更新。
如果一个容器导致容器主机的操作系统崩溃，则在该主机上运行的所有容器都将失败。
容器主机的操作系统内核中的安全漏洞将影响其所托管的所有容器。

容器技术也是虚拟化技术的子类

容器编排工具

当应用服务的数量不断增加，部署的容器数量开始变的庞大，一个应用数十乃至数百个松散结合的容器式组件构成，而这些组件需要通过相互间的协同合作。这时对单独组件和应用层的工作进行组织的流程的容器编排管理系统也有了存在的必要。Docker Swarm、Apache Mesos 和 Kubernetes 也随之登上舞台。

云计算的蓬勃

云计算：即通过网络按需提供可动态伸缩的廉价计算资源服务。

计算资源的层次划分

第一层次，是最底层的硬件资源，主要包括CPU（计算资源），硬盘（存储资源），还有网卡（网络资源）等。
第二层次，要高级一些，用户不直接使用硬件资源，而是使用云厂商直接提供配置好底层环境的各类中间服务，如负载均衡服务、数据库服务、对象存储服务、缓存服务等
第三层次，更高级一些，用户直接使用厂商提供的专门的垂直软件应用服务，不需要关注底层的架构与实现细节，做到真正开箱即用的软件服务

以上三个层次的划分，对应了云计算中的三个重要概念

IaaS: Infrastructure-as-a-Service（基础设施即服务）
PaaS: Platform-as-a-Service（平台即服务）
SaaS: Software-as-a-Service（软件即服务）

云原生时代的到来

云原生，实际是云原生计算的简称，它是云计算发展到现在的这一种形态。

云原生技术可以为企业在公有云、私有云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。

云原生主要涉及四个大方面：

弹性资源：基于虚拟化容器以及灵活的编排调度机制，可以为云服务体哦概念股快速扩缩容能力，而且极大程度地提高了物理资源的利用率。在这方面。Kubernetes（k8s）技术已经成为了行业的标准。
微服务架构：微服务也是云原生的重要基石之一。依托于功能单元解构，使得云服务具备了快速迭代的可能，业务得以循序发展；统一的通信标准能够帮助越来越多的组件加入到云原生的生态中，同时使得各组件之间的交互变得更容易。
DevOps：设计 => 开发 => 测试 => 交付 => 开发 => 测试 => 交付，自动化的流程使得软件的工作流程更高效，将微服务架构的优势进一步发挥。
服务网格：如果说微服务架构中最重要的进步，是将庞大的单体服务按照业务功能解耦开来，那么，服务网格的重要进步就是将业务逻辑于网络通信和治理解耦开来。业务不再需要关心异构系统中RPC中间件治理能力的不统一，这样使得复杂的治理能力成为可能

后微服务时代 - 云原生架构

从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代，此即为云原生所引领的“后微服务时代”。

All-in-Kubernetes ？

微服务时代所取得的成就，本身就离不开以 Docker 为代表的早期容器化技术的巨大贡献。在早期的容时候器只被简单地视为一种可快速启动的服务运行环境，目的是方便程序的分发部署，这个阶段针对单个应用进行封装的容器并未真正参与到分布式问题的解决之中。

这个状况一直持续到2017 年，各个容器技术的公司，都主动或被迫纷纷支持起了 k8s 的集成， Kubernetes 赢得容器战争的胜利正式宣告结束。

在以往的架构演进中，许多软件解决的问题都有对应的硬件解决方案，如负载均衡问题可以不知负载均衡器，服务发现问题可以设置DNS服务器。通过配置硬件的方式，业务开发人员就可以不必过多关心由硬件直接解决的问题。但在微服务时代，人们选择在软件的代码层面而不是硬件的基础设施层面去解决复杂分布式问题，很大程度上是因为由硬件构成的基础设施，跟不上由软件构成的应用服务的灵活性的无奈之举。

在容器技术的发展之下，构建在Linux操作系统之上的K8S将底层的操作系统中的概念进一步封装，已经能够被看做一个可对容器调度分配控制的“云操作系统”，在这个“云操作系统”的平台上，可以对服务发现、配置中心、服务网关、负载均衡、服务安全、跟踪监控提供的”基础设施层面“的解决方案。至此软件与硬件的界限便已经模糊。一旦虚拟化的硬件能够跟上软件的灵活性，那些与业务无关的技术性问题便有可能从软件层面剥离，悄无声息地解决于硬件基础设施之内，让软件得以只专注业务。

服务网格(Service Mesh)

Kubernetes 成为容器战争胜利者标志着后微服务时代的开端，但是 k8s 基础设施的解决方案仍有缺陷，甚至单从功能性上来看，全部依托于k8s 还不如基于Spring Cloud这些微服务框架的提供的方案，基础设施是针对整个容器来管理的，粒度相对粗旷，只能到容器层面，对单个远程服务就很难有效管控。

举个例子，微服务 A 调用了微服务 B 的两个服务，称为 B1和 B2，假设 B1表现正常但 B2出现了持续的 500 错，那在达到一定阈值之后就应该对 B2进行熔断，以避免产生雪崩效应。如果仅在基础设施层面来处理，这会遇到一个两难问题，切断 A 到 B 的网络通路则会影响到 B1的正常调用，不切断的话则持续受 B2的错误影响。

为了解决这一类问题，虚拟化的基础设施很快完成了第二次进化，引入了今天被称为“服务网格”（Service Mesh）的“边车代理模式”（Sidecar Proxy）

这个场景里指的具体含义是由系统自动在服务容器（通常是指 Kubernetes 的 Pod）中注入一个通信代理服务器，相当于那个挎斗，以类似网络安全里中间人攻击的方式进行流量劫持，在应用毫无感知的情况下，悄然接管应用所有对外通信。这个代理除了实现正常的服务间通信外（称为数据平面通信），还接收来自控制器的指令（称为控制平面通信），根据控制平面中的配置，对数据平面通信的内容进行分析处理，以实现熔断、认证、度量、监控、负载均衡等各种附加功能。这样便实现了既不需要在应用层面加入额外的处理代码，也提供了几乎不亚于程序代码的精细管理能力。

探索中的Serverless架构

如果说微服务架构是分布式系统这条路的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。

人们研究分布式架构，最初是由于单台机器的性能无法满足系统的运行需要，尽管在后来架构演进过程中，容错能力、技术异构、职责划分等各方面因素都成为架构需要考虑的问题，但其中获得更好性能的需求在架构设计中依然占很大的比重。对软件研发而言，不去做分布式无疑才是最简单的，如果单台服务器的性能可以是无限的，那架构演进的结果肯定会与今天有很大的差别，分布式也好，容器化也好，微服务也好，恐怕都未必会如期出现，最起码不必一定是像今天这个样子。

真正的无限性能是肯定无法做到的，但是相对意义的无限性能已经成为了现实，依靠云原生提供的快速扩缩容能力，云厂商可以向我们提供一种我们可以认为是可靠的服务，让我们不去关心服务的性能问题。开发人员就可以专心于业务，只需要写好代码上传到云厂商提供的平台。这便是Serverless架构（无服务），无服务指的更多的是一种不需要关注服务器的思维角度，专业的事”让专业的人做“，服务性能的保障完全交给云厂商。

除此之外无服务的架构还为云厂商和使用者提供了一种新的商业收费模式，即按量付费，可以根据资源占用量和占用时间进行收费，实现使用多少资源花多少钱。这使得资源的利用效率可以得到明显的提升。

无服务现在还没有一个特别权威的“官方”定义，但它的概念并没有前面各种架构那么复杂，本来无服务也是以“简单”为主要卖点的，它只涉及两块内容：后端设施（Backend）和函数（Function）。

后端设施是指数据库、消息队列、日志、存储，等等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件，这些后端设施都运行在云中，无服务中称其为“后端即服务”（Backend as a Service，BaaS）。
函数是指业务逻辑代码，这里函数的概念与粒度，都已经很接近于程序编码角度的函数了，其区别是无服务中的函数运行在云端，不必考虑算力问题，不必考虑容量规划（从技术角度可以不考虑，从计费的角度你的钱包够不够用还是要掂量一下的），无服务中称其为“函数即服务”（Function as a Service，FaaS）。

无服务的愿景是让开发者只需要纯粹地关注业务，不需要考虑技术组件，后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；不需要考虑如何部署，部署过程完全是托管到云端的，工作由云端自动完成；不需要考虑算力，有整个数据中心支撑，算力可以认为是无限的；也不需要操心运维，维护系统持续平稳运行是云计算服务商的责任而不再是开发者的责任。

在当前阶段来看，无服务天生“无限算力”的假设决定了它必须要按使用量（函数运算的时间和占用的内存）计费以控制消耗算力的规模，因而函数不会一直以活动状态常驻服务器，请求到了才会开始运行，这导致了函数不便依赖服务端状态，也导致了函数会有冷启动时间，响应的性能不可能太好（目前无服务的冷启动过程大概是在数十到百毫秒级别，对于 Java 这类启动性能差的应用，甚至能到接近秒的级别）。

serverless与”微服务“和”云原生“并不是迭代演进的关系，并不是说serverless就比前几种架构更先进，serverless目前还在发展的阶段，对无服务未来的发展仍应持谨慎乐观的态度。在未来也许分布式与非分布式的界限也会变得模糊，两条看似不同路线最终在云端的数据中心交汇。

We can only see a short distance ahead, but we can see plenty there that needs to be done.

尽管目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。

—— Alan Turing ，1950

~END~

WEB服务端系统架构演进概述 – CFC例会2022.9.18最先出现在枫阿雨's blog。

MySQL索引及其优化总结 – CFC例会2022.4.17

crazyfay — Sun, 17 Apr 2022 09:56:30 +0000

MySQL索引及其优化

MySQL的基础架构

Server层：核心服务功能与跨引擎功能的实现（如所有的内置函数、存储过程、触发器等）
- 连接器：管理连接，权限验证
- 命中缓存：命中缓存则直接返回结果（8.0版本后删除）
- 分析器：词法分析，语法分析
- 优化器：执行计划生成，索引选择
- 执行器：操作引擎返回结果
存储引擎：数据的存储与提取，插件式的架构模式
- InnoDB *
- MyISMA

SQL语句的执行流程

一条SQL查询语句是怎么执行的

SELECT * FROM student WHERE id = 12004030124;

在整体架构层面分析此条语句的执行过程

连接器

连接器负责跟客户端建立连接、获取权限、维持和管理连接。并负责校验用户身份。

mysql [-h$ip -p$port] -u$user -p [password 不建议把密码写在此条语句]

命令行中的mysql是客户端工具，在执行完词条语句之后将会与服务器进行连接，即通过TCP三次握手建立连接之后会校验用户身份

连接器会验证用户输入的用户名和密码，若存在问题则会返回错误并且客户端程序结束执行

在通过身份登录验证之后，连接器会查询该用户的权限并保存，接下来所有的操作权限都基于此次查询，即使用户权限发生了更改，在此次连接没有重新的建立的情况下，用户的权限不会直接更改。

查询缓存

在建立好连接之后就可以进行sql语句的执行了。

执行逻辑将会来到第二部：查询缓存

在拿到查询请求的适合，会先去查询缓存，缓存中以key-value的形式存储查询操作和查询结果，如果缓存中记录了执行过此查询操作，则直接返回该查询操作所对用的结果，即不需要再向下执行复杂的查询工作，可以直接返回查询操作的结果大大的简化了执行时间，如果说没有命中缓存，则向下执行通过IO过程查询，在返回时将查询结果返回到查询缓存中存储。使用缓存是需要代价的，而且往往弊大于利，因为每次表更新都会将查询结果清空，所以对于更新压力大的业务数据库来说，缓存命中率极低，在很多情况下查询缓存甚至是一种性能负担，所以在非表更新极少的静态表之外，不建议使用查询缓存。

注：在mysql8.0之后查询缓存被彻底的删除

分析器

在没有命中缓存的情况下，就到了分析器

先进行 "词法分析"，mysql需要知道sql语句中的内容，识别关键字，例如识别到select关键字，并分析出student为表名，id为列名。在完成"词法分析"后，分析器将进行"语法分析"，分析sql语句是否存在语法问题，若存在则返回错误提示并终止执行。

优化器

在分析完执行内容之后，优化器会进行相应的优化

优化器会选择如何使用索引和如何进行表连接顺序，并选择执行效率最高的方案执行语句。

执行器

在优化器选择好执行方案之后，执行器就开始执行sql语句

首先执行器会判断当前用户是否拥有查询此表的权限啊，若无权限在返回错误并终止执行。若有权限打开表使用存储引擎的接口进行操作。例如在此条语句中，因为表中没有定义索引，执行过程大致如下：

调用存储引擎接口读取表的第一行，判断是否与条件匹配，即id是否等于0
调用存储引擎接口读取下一行，判断是否匹配，重复执行直到读取完最后一行
将查询到的结果集返回给客户端

如果表中存在索引，查询方式也大致相同，调用的是满足条件的第一行和下一行

索引

什么是索引

在关系数据库中，索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构，它是表中一列或多列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。

索引（Index）是帮助MySQL⾼效获取数据的数据结构。提取句⼦主⼲，就可以得到索引的本质：索引是数据结构

索引的作用

保证数据的准确性
提高检索速度
提高系统性能

索引的类型

system > const > eq_ref > ref > range > index > all

InnoDB索引的数据结构

⼀般来说，索引本身也很⼤，不可能全部存储在内存中，因此索引往往以索引⽂件的形式存储的磁盘上。这样的话，索引查找过程中就要产⽣磁盘I/O消耗，相对于内存存取，I/O存取的消耗要⾼⼏个数量级，所以评价⼀个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。

分析: 有哪些数据结构可以用来作为索引的存储容器

HashTable

优点：HashTable是字典（dict）的一种经典实现，通过对Key进行散列值计算，我们可以直接得到对应数据的存放位置，可以实现时间复杂度为O(1)的极快的查找速度。
缺点：
1. 不支持模糊匹配，由于哈希计算没有局部特性，例如hash(枫阿雨)跟hash(枫阿)没有关系
  1. 不支持范围匹配，没有顺序性
  2. 不支持组合索引，因为hash值需要合在一起计算，所以不能支持最左匹配原则
  3. 哈希冲突问题

跳表

优点：跳表基于链式结构，可以多点之间的直接连接，每个节点可以有多个指针指向不同的next节点，查询的时间复杂度为O(n)，但如果节点指针设计的好，可以跳过某些不需要查询的节点，直接定位到数据，可以让n的值变小，从而带来比较大的性能提升
缺点：
1. MySQL数据库的存储介质在磁盘当中，而链式结构的结构体存放在内存当中，而且MySLQL进行数据索引的时候是以块的形式，即每个块为16KB的内存页，然后在内存页中进行数据的定位，而跳表所使用的是我们所谓的链表中的Node节点，而且指针管理非常复杂，不适用于磁盘存储介质
2. MySQL中涉及的查询较多且复杂，如果使用联合索引在跳表的数据结构下，假设有两个字段做联合索引，首先我们需要按首字段进行排序，基于此基础上再对第二个字段进行排序，如果在查询过程中使用跳表，除了要维护第一个的多个节点的跳跃指针，还要想办法维护第二个节点的跳跃指针，指针的管理将会非常的困难，而且还要分别进行不同列的标记。如果多个字段的联合索引则更复杂。
3. 客观上，跳表这种数据结构的出现并应用的时间较晚，此时MySQL已有了自己的实现方式

红黑树

优点：红黑树是一种近似平衡（不完全平衡），结点非黑即红的树，它的树高最高不会超过 2logn，因此查找的时间复杂度为 O(logn)，无论是增删改查，它的性能都十分稳定。
缺点：
1. 因为二叉树的只有两个子节点，相同存储容量时，树的高度太高，每次节点的访问都对应着一次磁盘IO，红黑树属于一种二叉树，虽然拥有稳定平衡的功能，但是大量的磁盘IO在应用程序中是灾难性的，即若红黑树的高度为20，那么最坏情况下读取一个数据需要进行20次磁盘IO这显然是无法接受的

B-树

优点：B-树是一种专门为磁盘数据读取设计的一种度为n的多路平衡查找树。既然二叉树因为每个结点最多只有两个子结点，最终在存储大量数据时导致树高太高，因此不适合当做 MySQL 的索引，那么让树的每个结点尽可能多的拥有多个子结点，这样在大量储存数据时，树高就相对低很多了，磁盘IO的次数也就大大减少
缺点：
1. 每个节点中既要存索引信息，又要存其对应的数据，如果数据很大，那么当树的体量很大时，每次读到内存中的树的信息就会不太够。
2. B树遍历整个树的过程和二叉树本质上是一样的，仍需要中序遍历，B树相对二叉树虽然提高了磁盘IO性能，但并没有解决遍历元素效率低下的问题。

B+树

优点：B+树相比B树，本质上是一样的，区别就在与B+树的所有根节点都不带有任何数据信息，只有索引信息，所有数据信息全部存储在叶子节点里，这样，整个树的每个节点所占的内存空间就变小了，读到内存中的索引信息就会更多一些，相当于减少了磁盘IO次数，且所有叶子节点都会在同一层，B+树会以一个链表的形式将所有叶子节点的信息全部串联起来，这样，遍历所有数据信息只需要顺序遍历叶子节点就可以了。不仅如此，B+树还有一个相应的优质特性，就是B+树的查询效率是非常稳定的，因为所有信息都存储在了叶子节点里面，从根节点到所有叶子节点的路径是相同的。
缺点：B+树在非叶子节点上不存储数据，有些时候会相对B树有更多的磁盘IO

索引组织表

相比于正常存储方式。优化了遍历搜索的性能损失。

聚集索引

辅助索引（非聚集索引）

回表

通过辅助索引定位到聚集索引

索引的优化

使用层面

索引列选择

选择适当的索引，索引应有区分度。如果某个字段的取值范围很广，几乎没有重复，即属于高选择性 的字段适合作为索引

最左前缀原则

如果进行模糊查询，查找 name 的第一个字为”孙“开头的所有人的id，即SQL语句为

SELECT id FROM student WHERE name like '孙%';

由于在B+ 树结构的索引中，索引项时按照索引定义里面出现的字段顺序排序的，索引在查找的时候，可以快速定位到ID为 100 的 “孙a” ，然后直接向右遍历所有姓名为 “孙” 开头的人，直到条件不满足位置。也就是说，我们找到第一个满足条件的之后，直接向右遍历就可以了，由于索引是有序的，所有满足条件的人都会聚集到一起。

而这种定位到最左边，然后向右遍历寻找，就是我们所说的最左前缀原则。

联合索引

联合索引时指对表上的多个列进行索引

ALTER TABLE buy_log ADD KEY(user_id);
ALTER TABLE buy_log ADD KEY(user_id, buy_date);
ALTER TABLE buy_log ADD KEY(user_id, buy_date, price);

情况1：如果只对于userid进行查询

SELECT * FROM buy_log WHERE user_id = 2;

索引选择：优化器的最终选择是索引userid，因为该索引的叶子节点包含单个键值，所以理论上一个页能存放的记录应该更多。

情况2：对于userid查询并根据buy_date排序，或对于userid和buy_date查询并根据price排序

SELECT * FROM buy_log WHERE user_id = 1 ORDER BY buy_date DESC LIMIT 3;
SELECT * FROM buy_log WHERE user_id = 1 AND buy_date = 2020 ORDER BY price DESC LIMIT 3;

索引选择：优化器最终选择的是联合索引(user_id, buy_date)，因为在联合索引中buy_date已经排序好了。根据该联合索引去除数据，无须再对buy_date做一次额外的排序操作。

情况三：对于userid查询并根据price排序

SELECT * FROM buy_log WHERE user_id = 1 ORDER BY price DESC LIMIT 3;

此时联合索引不能直接得到结果，其还需要执行一次排序操作，因为索引（user_id，price）并未排序

覆盖索引

即从辅助索引中就可以得到查询的记录（此时不能够使用select * 操作，只能对特定的索引字段进行select），而不需要查询聚集索引的记录。使用覆盖索引的一个好处是辅助索引不包含整行记录的所有信息，故其大小要远小于聚集索引，因此可以减少大量的IO操作。

SELECT COUNT(*) FROM buy_log;

InnoDB存储引擎并不会选择通过查询聚集索引来进行统计。由于buy_log表上还有辅助索引，而辅助索引远小于聚集索引，而辅助索引远小于聚集索引，选择辅助索引可以减少IO操作。

用一句人话概括：直接从辅助索引拿数据

避免索引失效

Like 开头以%开头导致失效

SELECT id FROM student WHERE name = ‘%三’;

OR 前后有任意一项不是索引字段则失效

-- age 为索引字段
SELECT id FROM student WHERE age > 10 OR age < 20；-- 索引正常使用
SELECT id FROM student WHERE age > 10 OR score > 80；-- 索引失效
SELECT id FROM student WHERE score > 80 OR age > 10；-- 索引失效

联合查询

-- 联合索引（age，score）id为主键
SELECT id FROM student WHERE age > 10 AND score > 80; -- 索引正常使用
SELECT id FROM student WHERE score > 80; -- 索引失效
-- 没有从联合索引的首元素开始进行索引，则索引失效

索引字段进行算数运算导致索引失效

SELECT id FROM student WHERE age = 10; -- 索引正常使用
SELECT id FROM student WHERE age - 1 = 10; -- 索引失效

NOT 取负面（取非）的结果集导致索引失效

SELECT id FROM student WHERE age != 10; -- 索引失效
SELECT id FROM student WHERE age <> 10; -- 索引失效
SELECT id FROM student WHERE age IS NOT 10; -- 索引失效

NULL 可能导致索引失效

-- 并不会百分百造成索引失效，
-- MySQL不会对NULL值创建索引，即NULL值在创建索引时会被抛弃
-- （所以逻辑上永远不会为空的字段应加上非空约束，如有逻辑上为空的情况，建议设置默认值约束）
SELECT id FROM student WHERE age IS NULL; -- 索引失效
SELECT id FROM student WHERE age IS NOT NULL; -- 索引失效

方法函数索引列使用内置函数时可能导致索引失效

--
SELECT birth_date FROM student WHERE DATE_ADD(birth_date, -1) = CURRENT_DATE(); -- 索引失效
SELECT birth_date FROM student WHERE birth_date = CURRENT_DATE() + 1; -- 正常使用

类型转换导致索引失效

-- phone varchar(11)
-- MySQL中的内置函数默认自动把字段值数字类型转换为字符，以匹配phone的类型
-- 因为字符串转整型会出现很多种情况，如"111" " 111" "111a"都会转换为整型的 111，故此时不使用索引
SELECT phone FROM student WHERE phone = 12345678901; -- 索引失效
SELECT phone FROM student WHERE phone = '12345678901'; -- 索引正常使用
-- 注：当隐式转换时 整型 转 字符串 则不受影响，因为整型转字符串的结果是唯一的

同一语句在某些版本可能导致索引失效
```
-- age 为索引字段
SELECT * FROM student age > 3;
```
是否使用索引？

首先，age是辅助索引，根据age查找到的是主键，仍需回表去查询聚簇索引来获得整行的数据。所以有两种可能。
1. 因为age已经排好序，通过索引查找 age > 3 效率很高。所以有使用age索引的必要。
2. 因为有回表的过程，排好序对应的主键id未必是排好序的，仍需多次额外的io查找，不如直接遍历聚簇索引
两种理由都有道理。MySQL在 5.6版本前后有不同的选择。
- 5.6版本之前，无论是否有age的辅助索引，都要走全表扫描，即遍历聚簇索引，不会使用辅助索引。
  
  如果直接回表的话会有3次IO多次查询，如果有n条数据需要回表，即额外需要 n* 3 = 3n 次IO，代价较大（这其实就是离散读的概念），
  
  如果直接全表扫描的话就是聚簇索引3次IO定位到叶子节点，然后根据叶子节点的链表遍历，可能也有多次IO，也并非轻松
  
  所以MySQL设置了一个阈值，当需要查询的数据占到总数据的一定量的时候就会全表扫描，没有到达阈值的时候就根据辅助索引回表多次查询。所以可能失效也可能不失效。
- 5.6版本之后，引入了 Multi-Range Read (MRR)优化，专门为解决离散读的问题。
  
  执行上述查询语句的时候会进行3次IO使用辅助索引找到所有 age > 3 的主键id，然后将这些数据放在缓存中，并将这些id进行了排序（在InnoDB引擎层面进行这些操作）。然后根据这些排序的主键id进行查询，省略了多次回表的过程。在支持MRR优化后，针对离散读的场景，能够优化10倍以上的效率。

存储引擎层面

MRR优化（针对离散读）

离散读：

假设表：t_index。其中 id 为主键；c1 与 c2 组成了联合索引（c1，c2）；此外 c1 还是一个 单独索引。

进行如下查找操作：

SELECT * FROM t_index WHERE c1 > 1 AND c1 < 100000;

在最后的索引使用中，优化器选择了 PRIMARY id 聚集索引，也就是表扫描（table scan），而非 c1 辅助索引扫描（index scan）。

因为如果强制使用c1索引，就会造成离散读。具体原因在于用户要选取的数据是整行信息，而c1作为辅助索引不能覆盖到我们要查询的信息，因此在对c1索引查询到指定数据后，还需要一次书签访问来查找整行数据的信息。虽然c1索引中数据是顺序存放的，但是再进行聚簇索引查找的数据是无序的，因此变味了磁盘上的离散读操作。如果要求访问的数据量很小，则优化器还会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是20%左右），优化器会选择通过聚簇索引来查找数据。

MRR：

在MySQL 5.6之后开始支持Multi-Range Read（MRR）优化。MRR 优化的目的就是为了减少磁盘的随机访问，并且将随机访问转化为较为顺序的数据访问，这对于IO-bound类型的SQL查询语句可带来性能极大的提升。MRR可适用于eq_ref、ref、range级别的索引

索引的级别：system > const > eq_ref > ref > range > index > all

MRR优化的执行过程：

将查询得到的辅助索引键值存放于一个缓存中，这时缓存中的数据时根据辅助索引键值排序的。
将缓存中的键值根据RowID进行排序
根据RowID的排序顺序来访问实际的数据文件

MRR 还可以将某些范围查询拆分为键值对，以此来进行批量的数据查询。这样的好处是可以在拆分过程中，直接过过滤一些不符合条件的数据

SELECT * FROM student WHERE id >= 1000 AND id < 2000 AND age = 1000;

表 student 有（id, age）的联合索引，因此索引根据id、age的位置关系进行排序。若没有MRR，此时查询类型为Range，SQL优化器会先将id大于1000且小于2000的数据都去除，即使age不等于1000。待取出行数据后再根据age条件进行过滤。这会导致无用的数据被取出。如果有大量的数据且其age不等于1000，则启用MRR优化会使性能有巨大的提升。

若启用MRR优化，优化器会先将查询条件进行拆分，然后再进行数据查询。久上述查询语句而言。优化器会将查询条件拆分为 (1000, 1000), (1001, 1000), (1002, 1000) , ..., (1999, 1000)，最后再根据这些拆分出的条件进行数据的查询。

优化策略：在非必要的情况，拒绝使用 select ，在必须 select 的情况下，尽量使用MySQL 5.6 以后的版本并开启MRR

ICP优化

和MRR优化一样，Index Condition Pushdown (ICP) 同样是MySQL 5.6开始支持的一种根据索引进行查询的优化方式。在之前的版本中，当进行索引查询时，首先根据索引来查找记录，然后再根据WHERE条件来过滤记录。在支持ICP后。MySQL数据库会在取出索引的同时，判断是否可以进行WHERE条件的过滤，也就是将WHERE的部分过滤操作放在了存储引擎层。在某些查询下，可以大大减少上层SQL层对记录的索取（fetch），从而提高数据库的整体性能

FIC（快速索引创建）优化

在5.5版本之前，MySQL数据库对于索引的添加或者删除的DDL操作，MySQL数据库的操作过程为以下几步：

首先创建一张新的临时表，表结构为通过命令ALTER TABLE新定义的结构
然后把原表中的数据导入到临时表
接着删除原表
最后把临时表重命名为原来的表名

如果对于一张大表进行索引的添加和删除操作，那么会需要很长的时间。更关键的是若有大量事务需要访问正在被修改的表，这意味着数据库服务不可用。

从InnoDB 1.0.x 版本开始支持一宗称为 FIC （Fast Index Creation）的索引创建方式

对于辅助索引的创建，InnoDB存储引擎会对创建索引的表加上一个 S锁。在创建的过程中，不需要重建表，因此速度较之前提高很多，并且数据库的可用性也得到了提高。删除辅助索引操作就更难了，InnoDB存储引擎只需要更新内部视图，并将辅助索引的空间标记为可用（不影响辅助索引的使用，因为可读），同时删除MySQL数据库内部视图上对该表的索引定义即可

但是，由于FIC在索引的创建过程中对表加上了S锁，因此在创建的过程中只能对该表进行读操作，若有大量的事务需要对目标表进行写操作，那么数据库的服务同样不可用。此外，FIC反射光hi只限定于辅助索引，对于主键的创建和删除通用需要重建一张表

Online DDL（在线数据定义）

在MySQL5.6版本开始支持Online DDL操作，其允许辅助索引创建的同时，还允许其他诸如INSERT、UPDATE、DELETE这类DML操作，极大地提高了MySQL数据库在生产环境中的可用性

不仅是辅助索引，以下几类DDL操作东可以通过“在线”的方式进行操作：

辅助索引的创建与删除
改变子增值
添加或删除外键约束
列的重命名

使用语法：

ALTER TABLE tbl_name
| ADD{INDEX | KEY} [index_name]
[index_type] (index_col_name,...) [index_option]...
ALGORITHM [=] {DEFAULT | INPLACE | COPY}
LOCK [=] {DEFAULT | NONE |SHARED | EXCLUSIVE}

ALGORITHM 制定了创建或删除索引的算法，COPY 表示按照MySQL 5.1版本之前的工作方式，即创建临时表的方式。INPLACE 表示索引创建或删除操作不需要创建临时表。 DEFAULT 表示根据参数 old_alter_table 来判断是通过 INPLACE 还是 COPY的算法，该参数的默认值为OFF，表示采用个INPLACE的方式

LOCK 部分索引创建或删除时对表添加锁的情况：

NONE

执行索引创建或者删除操作时，对目标表不添加任何的锁，即事务仍然可以进行读写操作，不会受到阻塞。因此这种模式可以获得最大的并发度。
SHARE

和之前的FIC类似，执行索引创建或删除操作时，对目标表加上一个S锁，对于并发地读事务，依然可以执行，但是遇到写事务，就会发生等待操作。
EXCULSIVE

在EXCULSIVE模式下，执行索引创建或删除操作时，对目标表加上一个X锁。读写事务都不能进行，因此会阻塞所有的线程，这和COPY方式运行得到的状态类似，但是不需要像COPY方式那也创建一张临时表。
DEFAULT

DEFAULT模式会先判断当前操作是否可以使用NONE模式，若不能，则判断是否可以使用SHARE模式，最后判断是否可以使用EXCLUSIVE模式，也就是说DEFAULT会通过判断事务的最大并发性来判断执行DDL的模式。

InnoDB存储引擎实现Online DDL 的原理是在执行创建或者删除操作的同时，将INSERT、UPDATE、DELETE这类DML操作日志写入到一个缓存中，待完成索引创建后再将重做应用到表上，以此达到数据的一致性。

由于Online DDL 在创建索引完成后再通过重做日志达到数据库的最终一致性，这意味着再索引创建过程中，SQL优化器不会选择正在创建中的索引。

MySQL表设计与索引调优

表的设计阶段

单行数据量的要求，MySQL底层的内存页的大小为16KB，所以一条数据如果是16KB，则一个内存页只能存储一条数据，这是不可接受的，如果1条数据为1KB则能存储16条数据。之所以提到内存页，因为MySQL的每次IO就是读取一个内存页的数据，所以要保证单行数据量的值要尽量的小。为此，在初期需求分析的时候就要做到数据尽量的小，比如存放一个UUID，如果要存放32位的UUID，则直接定死为32位，不要浪费存储空间，否则当数据达到一定规模的时候会影响到B+树的整体结构，B+树拥有高扇出性，每一个节点对应着16KB的内存页，对于3层高的B+树，根节点存放着16KB的主键与指针，假设主键为bigint8个字节，指针固定为6个字节，所有对应着有16KB / 14B 约等于 1170 个指针，每个指针指向一个节点，第二层的每个节点的结构与根节点均相似，所以第二层则总共扇出1170 1170 个页子节点，若每条数据长1KB，则一个三层高的B+树能够存储 1170 1170 * 16 条数据，约等于两千万多条，如果一个数据大小为16KB则存储容量就大打折扣了。所以在设计阶段就要保证数据大小。在做设计的时候也应该或用枚举，比如性别男女分别用0和1来表示，一可以保证检索快速二可以控制数据量的大小，就能增加相同高度的B+树的数据容纳量。

数据操作时索引的设计

MySQL中的三种索引，聚簇索引、辅助索引、覆盖索引。

聚簇索引，每张表只有一个，即 PRIMARY KEY；辅助索引，是开发时额外增加的索引，每个辅助索引对应着一颗B+树；覆盖索引，本质是没有树的。在SQL的设计的时候首先要确保一点，不要使用SELECT ，它必须要走聚集索引，也就是要全表扫描，只有在聚集索引中才有全部的数据。如果要使用的话尽量使用5.6以后的版本，因为5.6以后有了针对离散读的MRR优化和ICP优化，这样 SELECT 的查询速度会更快。着重提一下覆盖索引，在对于索引进行设计的时候，如果需要查询n个字段，如果保证这个n个字段都可以作为索引的话就尽量设置索引，因为在辅助索引中储存索引的值和主键的值，就可以避免回表查询。在书写SQL的时候，多使用执行计划查看索引是否失效，因为在特定的场景和函数下，MySQL的索引可能会失效

MySQL索引及其优化总结 – CFC例会2022.4.17最先出现在枫阿雨's blog。

从BST、AVL树、2-3树杀到BLT(红黑树)，常见树状数据结构解读 – CFC例会2021.10.10

crazyfay — Sun, 10 Oct 2021 15:36:07 +0000

让我们开始吃树~

提起树状数据结构的家族，我们不得不从二叉树开始说起。

在学二叉树的时候，我们知道，二叉树是指每个结点最多只有两个子结点的树。

二叉树，是指树中每个结点最多只有两个结点的树。当然，二叉树本身好像没有什么太大的作用。我们平时所说的二叉树，基本上就是指二叉排序树(二叉查找树)。

二叉查找树（BST）

二叉查找树就是在二叉树的基础上增加有序性，这个有序性一般是指自然顺序，有了有序性，我们就可以使用二叉树来快速的查找、删除、插入元素了。

但是，二叉查找树有个非常严重的问题，试想，还是这三个元素，如果按照A、B、C的顺序插入元素会怎样？

那么如果按照顺序插入，就会变成一个单链表。没错，当按照元素的自然顺序插入元素的时候，二叉查找树就退化成单链表了，单链表的插入、删除、查找元素的时间复杂度是多少？？

所以，在极限状态下，二叉查找树的时间复杂度是非常差的。

既然，插入元素后有可能导致二叉查找树的性能变差，我们是不是增加了一些手段，让插入后的二叉查找树依然性能良好？

这种手段，就叫做平衡。可以做到自平衡的树就叫做平衡树。

平衡树

平衡树，是指插入、删除元素后可以自平衡的二叉查找树。我们平衡的手段，就是旋转。

平衡这个概念一直都有，直到62年，发明了第一种平衡树—-AVL树。

严格来说，平衡树是指可以自平衡的二叉查找树，关键词就是：自平衡、二叉、查找（有序）。

AVL树

AVL树是指任意节点的两个子树的高度差不超过1的平衡树。

当数据量非常多的时候，你会非常难以判断这是否是一颗AVL树，比如

如果把上面看成一颗二叉排序树，他是一颗AVL树，其实你很难一眼就看出来他是一颗AVL树，这就是AVL树的第一个缺点，不够直观，特别是当结点特别多的时候。

第二个缺点就是，在插入和删除的时候自平衡的过程非常的复杂。

基于这些缺点，所以，后来又发展出来了各种各样的神奇的平衡树。

多路平衡二叉树

索引

一般来说，我们操作的数据都是存储在内存（CPU）中的，但如若我们要操作的数据集非常大，大到内存已经没办法处理了怎么办呢？如数据库中的上千万条记录的数据表、硬盘中的上万个文件等，他们必然不能都存储在内存中，而是存储在外存中的。

对于外存中的数据，常见如数据库，我们通常通过索引表来进行数据查找和交互，一般来说，索引表本身也很大，因为数据库的数据非常多，因此索引也不可能全部存储在内存中，因此索引表往往也是以索引文件的形式存储的磁盘上。Mysql的MyISAM引擎的索引文件和数据文件是分离的，一张数据库表就有它对应的索引表，索引表中一个索引对应一条数据库记录的磁盘地址，内存中发起请求通过指定索引的查找索引表即可定位唯一的一条数据；当然Mysql的InnoDB引擎的索引表也是数据表，即索引表保存了索引和完整的数据记录。但是不管怎么说数据的查找都会依赖索引，并且建议通过索引查找，因为如果没有走索引，那就会走全表扫描，使得查找效率大大降低。因为索引文件同样存储在磁盘上，这样的话，索引查找过程中每查找一次就要产生一次磁盘I/O消耗，相对于CPU存取，I/O存取的消耗要高几个数量级，访问磁盘的成本大概是访问内存的十万倍左右。

实际上，考虑到磁盘IO是非常高昂的操作，计算机操作已经系统做了一些优化，当一次IO时，不光把当前磁盘地址的数据，而是把相邻的数据也都读取到内存缓冲区内，局部预读性原理告诉我们，当计算机访问一个地址的数据的时候，与其相邻的数据也会很快被访问到。

每一次IO读取的数据我们称之为一页(page)。具体一页有多大数据跟操作系统有关，一般为4k或8k大小的连续磁盘块，也就是我们读取一页内的数据时候，实际上才发生了一次IO，这个理论对于索引的数据结构设计非常有帮助，通常，索引节点的大小被设计为一页的大小。

多路平衡查找树

对于一旦涉及到这样的外部存储设备（外存），关于时间复杂度的计算就会发生变化，访问某个表/集合元素的时间已经不仅仅是寻找该元素所需比较次数的函数，我们必须考虑对硬盘IO进行操作的时间。由于IO耗时远大于CPU耗时，所以此处评价一个数据结构作为索引的优劣最重要的指标就是要尽量减少查找过程中磁盘IO的存取次数。

我们之前谈的树，都是一个节点可以有多个孩子，但是它自身只存储一个元素。二叉树限制更多，节点最多只能有两个孩子。一个节点只能存储一个元素，在元素非常多的时候，就使得要么树的度非常大（节点拥有子树的个数的最大值），要么树的高度非常大，甚至两者都必须足够大才行，这就使得IO次数非常多，这显然成了时间效率上的瓶颈，并且由于一次IO读取一个节点的数据，普通二叉树并不能容纳更多的数据，这样又造成了磁盘块空间的浪费。

以上种种限制迫使我们设计出每一个节点可以存储多个元素，并且数据结构的高度可控的数据结构，为此引入了多路查找树的概念。一颗平衡多路查找树同样可以使得数据的查找效率保证在O(logN)这样的对数级别上，此时底数为叉数或者阶。

多路查找树（muitl-way search tree），其每一个节点的孩子数可以多于两个，且每一个节点处可以存储多个元素。由于它是一颗平衡查找树，所有元素之间存在某种特定的排序关系。在这里，每一个节点可以存储多少个元素，以及它的孩子数的多少是非常关键的。

2-3树

因为AVL树所带来的搜索性能的提升，不足以弥补平衡树所带来的性能损耗。所以，就开始思考，有没有一种绝对平衡的树。没有高度差，没有高度差就没有平衡因子，没有平衡因子就没有旋转操作。

随着这种思考，衍生出了2-3树。也就是二叉-三叉树。

2-3树就是一种绝对平衡的树，任意节点到它所有的叶子结点的深度都是相等的。

定义

一颗2-3树或为一颗空树，或有以下结点组成：

2-节点：含有一个元素和两个子树，左子树的所有元素的值均小于它的父结点，右子树所有元素的值均大于它的父结点。

3-节点：还有两个元素和三个子树（左中右子树），左子树所有元素的值均小于它的父结点，中子树所有元素的值都位于父结点两个元素之间，右子树所有元素的值均大于它的父结点。

2-3树查找元素

2-3树的查找类似于二分，根据元素的大小来决定来决定查找的方向。要判断一个元素是否存在，我们就要先将待查找元素和根元素比较，如果他和任意一个相等，那查找命中，否则根据比较结果来选择查找方向。

2-3树插入元素

插入元素首先进行查找命中。若查找命中则不插此元素。如果需要支持重复的元素则将这个元素对象添加一个属性count。若查找未命中，则在叶子结点中插入这个元素。

空树的插入很简单，创建一个结点就可以了。如果不是空树，插入又分成了四种情况：

1、向2-结点中插入元素

2、向一颗只含有一个3-节点的树中插入元素

如果命中查找结束于3-节点，先临时将其成为4-节点，把待插入元素添加到其中，然后将4-节点转化为3个2-节点，中间的节点成为左右节点的父节点。如果之前临时4-节点有父节点，就会变成向一个父节点为2-节点的3-节点中插入元素，中间节点与父节点为2-节点的合并。

3、向一个父结点为2-节点的3-节点中插入元素

同前者

4、向一个父结点为3-节点的3-节点中插入元素

插入元素后一直向上分解临时的4-节点，直到遇到2-节点的父节点变成3-节点不再分解。如果达到树根节点还是4-节点，则进行分解根节点，此时树高+1（只有分解根节点才会增加树高），下面动画2-3树插入会出这个例子。

2-3树的删除操作

2-3树的删除也分为三种情况，与插入相反。

1、当删除元素为于3-节点的叶子结点上

只需要删除该元素即可，不会影响到整棵树的其他结点结构。

2、当删除元素位于非叶子结点

使用中序遍历找到待删除节点的后继节点，然后将后继节点与待删除节点位置互换，此时就将问题转化为删除节点为叶子节点（平衡树的非叶子节点中序遍历后继节点肯定是叶子节点），如果该叶子是3-节点，则跟情况（1）一样，如果该节点是2-节点，则跟后面的情况（3）一样；

3、当删除元素位于2-结点的叶子结点上

删除元素2-结点的叶子结点的步骤相对很复杂，删除后需要做出相应的判断。并根据判断结果调整树的结构。

1、删除结点为2结点，父结点为2结点，兄弟结点为3结点。

操作步骤：当前待删除节点的父节点是2-节点、兄弟节点是3-节点，将父节点移动到当前待删除节点位置，再将兄弟节点中最接近当前位置的key移动到父节点中。

2、删除结点为2-结点，父结点为2-结点，兄弟结点为2-结点

操作步骤：当前待删除节点的父节点是2-节点、兄弟节点也是2-节点，先通过移动兄弟节点的中序遍历直接后驱到兄弟节点，以使兄弟节点变为3-节点；

删除结点4位2-结点，兄弟结点7也为2结点，需要中序遍历得到兄弟结点7的直接后继8，然后结点7和8构成3-结点。

重复1情况

3、删除结点为2-结点，父结点为3-结点

操作步骤：当前待删除节点的父节点是3-节点，拆分父节点使其成为2-节点，再将再将父节点中最接近的一个拆分key与中孩子合并，将合并后的节点作为当前节点。

2-3树为满二叉树，删除叶子结点

2-3 树作为一种平衡查找树，查询效率比普通的二叉排序树要稳定许多。但是2-3树需要维护两种不同类型的结点，查找和插入操作的实现需要大量的代码，而且它们所产生的额外开销可能会使算法比标准的二叉查找树更慢。

可以看到，上面自平衡的过程中，出现了一种节点，它具有四个子节点和三个数据元素，这个节点可以称作4节点，如果把4节点当作是可以允许存在的，那么，就出现了另一种树：2-3-4树。

2-3-4树

2-3-4树，它的每个非叶子节点，要么是2节点，要么是3节点，要么是4节点，且可以自平衡，所以称作2-3-4树。

2节点、3节点、4节点的定义在上面已经提及，我们再重申一下：

2节点：包含两个子节点和一个数据元素；

3节点：包含三个子节点和两个数据元素；

4节点：包含四个子节点和三个数据元素；

插入M，依旧符合2-3-4树的规则。在插入N呢？

插入N，L上移。

F上移

是不是挺简单的，至少比AVL树那种左旋右旋简单得多。同样地，在2-3-4树自平衡的过程中出现了临时的5节点，所以，如果允许5节点的存在呢？嗯，2-3-4-5树由此诞生！同样地，还有2-3-4-5-6树、2-3-4-5-6-7树……子子孙孙，无穷尽也~所以，有人就把这一类树归纳为一个新的名字：B树。

B树

B树，表示的是一类树，它允许一个节点可以有多于两个子节点，同时，也是自平衡的，叶子节点的高度都是相同的。所以，为了更好地区分一颗B树到底属于哪一类树，我们给它一个新的属性：度（Degree）。具有度为3的B树，表示一个节点最多有三个子节点，也就是2-3树的定义。具有度为4的B树，表示一个节点最多有四个子节点，也就是2-3-4树的定义。

B树，一个节点可以存储多个元素，有利于缓存磁盘数据，整体的时间复杂度趋向于O(log n)，原理也比较简单，所以，经常用于数据库的索引，包括早期的mysql也是使用B树来作为索引的。但是，B树有个大缺陷，比如，我要按范围查找元素，以上面的2-3-4树为例，查找大于B且小于K的所有元素，该怎么实现呢？很难，几乎无解，所以，后面又出现替代B树的方案：B+树。当然了，B+树不是本节的重点，本节的重点是红黑树。来了来了，有意思的红黑树来了~~

红黑树

我们先用图来体会

我可以跟大家说，这棵树，就是一颗红黑树。红黑树就是2-3-4树。

我们知道2-3-4的插入、删除、查找元素的原理是相当简单的，那么，我们是不是可以利用2-3-4树来记忆红黑树呢？答案是肯定的，我们就来看看如何利用2-3-4树来快速掌握红黑树，再也不用死记硬背了~~

现在，我们来看一看红黑树的精髓所在，我们来看一看，什么是红黑树的黑高，为什么要有红黑树，红黑树的旋转跟AVL有什么区别，如何去选择？红黑树是如何保持平衡的？直接进入正题

什么是红黑树

红黑树是一颗自平衡的二叉排序树，树上的每一个结点都遵循下面的规则（特别注意，这里的自平衡和平衡二叉树AVL的高度有区别）。我们再来看一看红黑树的定义：

1、每一个结点都有一个颜色，要么是红色，要么是黑色。

2、树的根结点为黑色

3、树中不存在两个相邻的红色节点（红色节点的父结点和孩子结点均不为黑色）

4、从任意一个结点出发，包括根结点，到其任何后代NULL结点（默认都是黑色啊）的每条路径都具有相同数量的黑色结点。

这就是一颗典型的红黑树，树中的每个结点的颜色要么是黑色，要么是红色；根结点 6 为黑色结点；树中不存在两个相邻的红色结点，比如结点 15 为红色结点，其父亲节点 6 与两个孩子结点就一定是黑色，而不能是红色；从结点到其后代的 NUll结点的每条路径上具有相同数目的黑色结点，比如根结点 6 到其左子树的 NULL结点包含三个黑色结点，到其右子树所有的 NULL 结点也包含三个黑色结点。可能还不够清晰，为此我对上图做了修改为所有默认为黑色的 NULL 结点给了一个标记。

现在解释规则的第四条简直不能再清晰了！比如根结点 6 到 NULL结点 a 的路径 6→2→a 上的黑色结点为 3 个，从根结点 6 到结点 c 的路径 6→15→10→9→c 中包含的黑色结点个数也是 3 个，同理从根结点 6 到其他所有 NULL结点的黑色结点数都是 3 。再举个栗子，从红色结点 15 到NULL结点 d 的路径 15→18→g 包含 2 个黑色结点，到NULL结点 c 的路径 15→10→9→c 也包含黑色结点 2 个，从结点 15 到其所有后代的 NULL结点的黑色结点数目都是 2 。

为什么要有红黑树

大多数二叉排序树BST的操作（查找、最大值、最小值、插入、删除等等）都是O（h）的时间复杂度，h 为树的高度。但是对于斜树而言（BST极端情况下出现），BST的这些操作的时间复杂度将达到O（n），n就是结点数。为了保证BST的所有操作的时间复杂度的上限为O（logn），就要想办法把一颗BST树的高度一直维持在logn，而红黑树就做到了这一点，红黑树的高度始终都维持在logn，n 为树中的顶点数目。

这个时候就有一个疑问，不对啊。AVL树不也始终是一个均值么？

红黑树RBT与平衡二叉树AVL的比较

AVL 树比红黑树更加平衡，但AVL树在插入和删除的时候也会存在大量的旋转操作。所以当你的应用涉及到频繁的插入和删除操作，切记放弃AVL树，选择性能更好的红黑树；当然，如果你的应用中涉及的插入和删除操作并不频繁，而是查找操作相对更频繁，那么就优先选择 AVL 树进行实现。

一颗红黑树到底是如何保持平衡的呢？

举一个很简单但是很经典的例子，包含三个结点的单链是不可能出现在红黑树当中的。关于这一点，我们可以自己绘制一条单链，然后尝试为其着色，来判断。

从上图中可以发现，将根结点 9 涂黑色，其他结点分四种情况着色，结果都不满足红黑树的性质要求。唯一的办法就是调整树的高度

这就算我们对于红黑树的初探，然后我们来看两个重要的概念。

什么是一颗红黑树的黑高？

在一颗红黑树中，从某个结点 x 出发（不包含该结点）到达一个叶结点的任意一条简单路径上包含的黑色结点的数目称为黑高，记为 bh(x) 。所以我们发现，其实6和15的黑高是一样的，都是2。

计算结点 6 的黑高，从结点 6 到结点 c 的路径是 6→15→10→9→c ，其中黑色结点为 6、10、c ，但是在计算黑高时，并不包含结点本身，所以从结点 6 到结点 c 的路径上的黑色结点个数为 2 ，那么 bh(6)=2 ；从结点 15 到结点 c 的路径为 15→10→9→c ，其中黑色结点为 10、c ，所以从结点 15 到结点 c 的路径上黑色结点数目为 2 ，bh(15)=2 。

因为红黑树的黑高为其根结点的黑高。所以根据红黑树的性质3和性质4，一颗红黑树的黑高bh一定>= h/2。

`1 2 3`	`Number of nodes from a node to its farthest descendant leaf is no more than twice as the number of nodes to the nearest descendant leaf. 从一个结点到其最远的后代叶结点的顶点数目不会超过从该结点到其最近的叶结点的结点数目的两倍。`

Copy

其中黑高 bh 就表示从根结点 6 到离它最近的叶结点 2 包含的结点数 2 ，而 h 则表示从根结点 6 到其最远的叶结点 9 所包含的结点数目 4 ，显然这一公式是合理的。

引出来一个道理：一颗有n个结点的红黑树的高度h<=2lg(n+1)。

这就合并成了一颗2-3-4树，这棵树中的每一个结点有2、3、4个孩子结点，而一颗2-3-4树的叶结点有着相同的深度h‘。

也正是基于这个，所以对于有n个结点的红黑树而言，不论查找、删除、最大值、最小值等等的时间复杂都平均下来了，也就是O（logn）。

红黑树的插入

其实红黑树的操作也很简单，就是比AVL多了一个着色的操作。

在AVL中，我们通过左旋和右旋来调整由于插入和删除所造成的不平衡的问题。在红黑树中，我们使用两种方式：

1、重新着色

2、旋转

当红黑树中出现不平衡的状态，我们首先会考虑重新着色，如果重新着色依旧不能使红黑树平衡，那么就考虑旋转。插入操作主要有两种情况，具体取决于叔叔结点的颜色。如果叔叔结点是红色的，我们会重新着色。如果叔叔结点是黑色的，我们会旋转或者重新着色，或者两者都考虑。

假设x是新插入的一个结点。

1、进行标准的BST插入并将新插入的结点设置为红色

2、如果x是根结点，将x的颜色转化为黑色（整棵树的黑高增加1）

3、如果x的父结点p不是黑色并且x不是根结点，则：

1）、如果x的叔叔结点u是红色；

2）、如果x的叔叔结点u是黑色，则对于x、x的父结点p和x的爷爷结点g有四种情况：

`1 2 3 4 5 6 7 8 9 10 11 12 13`	`LL（p是g的左孩子且x是p的左孩子） LR（P是g的右孩子且x是p的右孩子） RR（p是g的右孩子且x是p的右孩子） RL（p是g的右孩子且x是p的左孩子）将插入结点x的父结点p和叔叔结点u的颜色变成黑色将x的爷爷结点g设置为红色将g看作是x，对于新的x重复2、3两步`

Copy

插入结点x的叔叔结点u是红色

对于新插入结点 x，我们执行标准的 BST 插入之后，将插入结点 x 着色为红色；如果插入结点不是根结点，且x的父结点 p 为红色结点，分为 1) 和 2) 两种情况处理，我们先看的是 1) 的情况：x 的叔叔结点 u 为红色，如下图所示：

第一步：将父亲结点p和叔叔结点u都设置为黑色

第二步：将g的颜色设置为红色

第三步：针对于g结点，在执行第二，第三步。

插入结点x的叔叔结点u为黑色

当插入结点x的叔叔结点为黑色的时候，根据插入接待你x、x的父结点p和x的爷爷结点g可能出现的位置关系，分为四种情况。

LL

LR

首先通过左旋p转化为LL的情况：

然后按照LL的情况处理：

RR

RL

先右旋转化成RR的情况

然后按照RR的情况处理

到这里，插入排序就全部讲完了。但我也知道很多人可能会有疑惑，那就让我们来构造一颗红黑树，看看运用上述规则到底是否适用。

红黑树插入操作示例

下面就带大家构造一颗稍微复杂一点儿的红黑树：

初始时，我们已知的插入依次插入：

第一步：插入结点2，结点2就是根结点，设置为黑色：

第二步：插入结点6，首先执行标准的BST插入操作并将结点6设置为红色，但6号结点的父结点为2的颜色为黑色，所以什么都不用做。

第三步：插入结点9，执行BST插入，设置为红色。其父结点6颜色为红色，且叔叔结点null为黑色，属于RR的情况。故对其爷爷结点2进行左旋操作，并交换g和p的颜色。

第四步：插入结点 10，执行标准的 BST 插入操作并设置为红色，其父结点 9为红色，其叔叔结点 2为红色结点，将其父结点 9 和叔叔结点涂黑色，并将其爷爷结点涂红色并设置为新的x，判断其爷爷结点 6 ，发现为根结点，重新更新为黑色。

第五步：插入结点 12，执行标准的BST插入操作并设置为红色，其父结点 10为红色，其叔叔结点为黑色，其爷爷结点 9为红色，RR 的情况，则左旋 g ，交换 g 和 p 的颜色。

第六步：插入结点15

第七步：插入20

第八步：插入18

第九步：插入结点1

第十步：插入结点5

第十一步：插入结点13

红黑树的删除

说起红黑树的删除操作，就不得不提我们讲的红黑树的插入。与红黑树的插入操作类似，红黑树的删除也是重新着色和旋转来保证每一次删除操作后依旧满足红黑树的属性。

在插入操作中，通过判断插入结点 x 的叔叔结点 u 的颜色来确定恰当的平衡操作。而删除操作中，是通过检查兄弟结点的颜色来决定恰当的平衡操作。红黑树中插入一个结点最容易出现两个连续的红色结点，违背红黑树的性质3（红黑树中不存在两个相邻的红色结点）。而删除操作，最容易造成子树黑高（Black Height）的变化（删除黑色结点可能导致根结点到叶结点黑色结点的数目减少，即黑高降低）。与插入操作相比，红黑树的删除操作相对复杂一点，但多点儿耐心，还是没有问题的。为了理解删除操作，我们先来看一个双黑（Double Black）的概念。

当删除结点 v 是黑色结点，且其被其黑色子节点替换时，其子结点就被标记为双黑。

所以说，删除操作最主要的任务就是将转化为双黑结点转换为我们普通的黑色结点。

删除操作总纲

删除操作总体上分为三步，我们先提高挈领地看一下，有个宏观概念，然后步步为营，攻陷删除。

首先我们假定要删除的结点为 v ，u 是用来替换 v 的孩子结点（注意，当 v 是叶结点时， u 是 NULL结点，且NULL结点我们还是当做黑色结点处理）。

删除操作总纲：

1、执行标准的BST的删除操作

2、简单情况：u或者v时红色

3、复杂情况：u和v都是黑色

1）u是双黑结点

2）当前结点u是双黑结点且不是根结点

a）u的兄弟结点s是黑色且s的孩子结点至少有一个是红色（LL、LR、RR、RL）

b）u的兄弟结点s是黑色且它的两个孩子都是黑色

c）u的兄弟结点s是红色（s是其父结点p的左孩子、s是其父结点的右孩子）

3）当前结点u是双黑结点且是根结点

1、执行标准的BST删除操作

在标准的 BST 删除操作中，我们最终都会以删除一个叶子结点或者只有一个孩子的结点而结束（对于内部节点，就是要删除结点左右孩子都存在的情况，最终都会退化到删除结点是叶子结点或者是只有一个孩子的情况）。所以我们仅需要处理被删除结点是叶结点或者仅有一个孩子的情况。

2、简单情况：u或者v是红色

如果 u 或者 v 是红色，我们将替换结点 v 的结点 u 标记为黑色结点（这样黑高就不会变化）。注意这里是 u 或者 v 是红色结点，因为在一棵红黑树中，是不允许有两个相邻的红色结点的，而结点 v 是结点 u 的父结点，因此只能是 u 或者 v 是红色结点。

删除结点 v 为黑色结点 10 ，替换结点 v 的结点 u 为红色结点 9 的情况：

删除结点v为红色结点20，替换结点v的结点u为黑色NULL结点的情况：

3、复杂情况 u和v都是黑色结点

3.1 结点u是双黑结点

当要删除结点 v 和孩子结点 u 都是黑色结点，删除结点 v ，导致结点 u 变为双黑结点。当 u 变成双黑结点时，我们的主要任务将变成将该双黑结点 u 变成普通的单黑结点。一定要特别注意，我们在上篇就提到的，NULL结点为黑色结点，所以删除黑色的叶子结点就会产生一个双黑结点。

3.2 当前结点u是双黑结点且不是根结点

当前结点 u 是双黑结点且不是根结点，又包含三种情况进行处理。我们约定结点 u 的兄弟结点为 s .

u的兄弟结点s是黑色且s的孩子结点至少有一个是红色

对于这种情况，需要对 u 的兄弟结点 s 进行旋转操作，我们将 s 的一个红色子结点用 r 表示，u 和 s 的父结点用 p 表示，那么结点 p 、s 和 r 的位置将出现以下四种情况（LL、LR、RR、RL）。

LL（s 是 p 的左孩子，r 是 s 的左孩子，或者 s 的两个孩子都是红色结点）：

我们删除下图中的结点 25 为例进行说明：

删除结点 25 ，用结点 25 的NULL结点替换结点 25 ，产生一个双黑结点 u ，双黑结点 u 的兄弟结点 s 为 15 ，结点 s 是其父结点 20（p）的左孩子，其左孩子 10（r）正好是红色结点。即为 LL 情况。

s 的左孩子 r 颜色设置为 s 的颜色，s 的颜色设置为父结点 p 的颜色，然后右旋p结点。

LR（s是p的左孩子，r是s的右孩子，或者s的两个孩子都是红色）

删除结点25，不过结点25的兄弟结点15只有一个右孩子18

将结点r的颜色设置为p的颜色。

左旋结点15（s）

右旋结点20（p），p的颜色设置为黑色，双黑变单黑

RR（s 是 p 的右孩子，r 是 s 的右孩子，或者 s 的两个孩子都是红色结点）：删除结点 2 ，用结点 2 的NULL结点 a 替换结点 2 ，产生一个双黑结点 u ，双黑结点 u 的兄弟结点 s 为 15 ，结点 s 是其父结点 6（p）的右孩子，其右孩子 18（r）正好是红色结点。即为 RR 情况（仔细观察其实和 LL 情况是对称的）。

r的颜色变为s的颜色，s的颜色变为p的颜色。

左旋p，p的颜色设置为黑色，双黑变单黑

RL情况（s 是 p 的右孩子，r 是 s 的左孩子，或者 s 的两个孩子都是红色结点）：该情况与 LR情况是对称的

结点r的颜色变为p的颜色

右旋结点15

左旋结点6（p），p的颜色设置为黑色，双黑变单黑

u 的兄弟结点 s 是黑色且 s 的两个孩子结点都是黑色

对于这种情况需要递归地进行处理，如果删除结点后得到的双黑结点的父结点此时为黑色，则结点 u 变单黑，且结点 u 的父结点 p 变双黑，然后对结点 u 的父结点 p 继续进行处理，直到当前处理的双黑结点的父结点为红色结点，此时将双黑结点的父结点设置为黑色，双黑结点变为单黑结点（红色 + 双黑 = 单黑）。

假设以 10 为根结点的子树为整棵树的左子树，删除结点 9 ，产生双黑结点 c 且其兄弟结点 12（s）为黑色，兄弟结点的左右孩子均为黑色。

此时双黑结点的兄弟结点 12 变为红色结点，然后将 u 的父结点 10 变为双黑结点，一直向上判断。

那么这个过程什么时候结束呢？

如下图，删除结点12，得到一个双黑结点u，双黑结点的兄弟结点31及兄弟结点的孩子结点均为黑色，且双黑结点的父结点19为红色结点，刚好是不再继续向上判断的情况：

此时只需要将结点 u 的兄弟结点 31 的颜色变为红色，双黑结点 u 的父结点 19 由红色变为黑色结点，双黑结点 u 变为单黑结点。

u的兄弟结点s是红色结点

当前 u 的兄弟结点 s 是红色结点时，通过旋转操作将 u 当前的兄弟结点向上移动，并对 u 的父结点和其旋转前的兄弟结点重新着色，接着继续对结点 u 旋转后的兄弟结点 s 进行判断，确定相应的平衡操作。旋转操作将 u 的兄弟结点情况又会转换为前面刚提到的3.2（a）和（b）的情况。根据兄弟结点 s 是父结点 p 的左右孩子又分为两种情况。

情况一：u 的兄弟结点 s 是父结点 p 的左孩子 ,对结点 p 进行右旋操作。

删除结点 18 ，产生一个双黑结点 u ，且 u 的兄弟结点 s 是红色，兄弟结点 s 是其父结点的左孩子，接着就是对其父结点 15 进行右旋操作。

对结点 15 进行右旋操作，并且对旋转前的 p 和 s 进行重新着色后，继续对双黑结点旋转后的兄弟结点进行判断，发现此时正好和 3.2（b）的情况是一样，进行相应处理，如下图所示。

情况二：u 的兄弟结点 s 是父结点 p 的左孩子 ,对结点 p 进行左旋操作（这种情况与上面的是对称的）。

删除结点 6 ，产生一个双黑结点 u ，且 u 的兄弟结点 10（s）为红色，s 是父结点 p 的右孩子，左旋P

对双黑结点 u 旋转后的兄弟结点继续判断：

3.3 当前结点u是双黑结点且是根结点

当前结点 u 是双黑结点且是根结点时，直接将双黑结点变为单黑结点，整颗红黑树的黑高减 1.

红黑树与AVL树的比较

红黑树中的每个结点需要一个存储位表示结点的颜色，可以是红或黑。通过对任何一条从根到叶子的路径上各个结点着色方式的限制，红黑树确保对于每一个结点其到叶子结点的最长路径不会超过最短路径的两倍，因此，红黑树是一种弱平衡二叉树（由于是弱平衡，可以看到，在相同结点的情况下，AVL树的高度<=红黑树），相对于要求严格的AVL树来说，它的旋转次数少，所以对于插入，删除操作较多的情况下，使用红黑树。

来自一年后的补充:
红黑树的逻辑操作，第一次啃需要很长时间，啃下来之后长时间不复习，也很容易忘记，真正熟练的理解红黑树的详细逻辑是有一定困难的，而有时候不需要在这些地方上浪费太多的时间。（几乎忘得一干二净的我如此补充到

从BST、AVL树、2-3树杀到BLT(红黑树)，常见树状数据结构解读 – CFC例会2021.10.10最先出现在枫阿雨's blog。