• 互斥锁（Mutex）
• 读写锁（Read-Write Lock）
• 自旋锁（Spin Lock）
• 屏障（Barrier）
• 原子操作（Atomic Operations）
• 分布式锁（Distributed Lock）

互斥锁​

互斥锁是最常见的锁机制之一。它允许只有一个线程或进程可以访问共享资源，其他线程或进程必须等待锁的释放才能访问。 互斥锁提供了最基本的线程同步机制，但如果不慎使用不当，可能会导致死锁问题。

读写锁​

读写锁允许多个线程同时读取共享资源，但只有一个线程能够写入。这提高了读取操作的并发性能，但写入操作仍然是互斥的。

自旋锁​

自旋锁（Spin Lock）是一种锁机制，它在尝试获取锁时不会阻塞线程，而是会一直尝试获取锁，如果锁已经被其他线程占用，它会一直忙等（自旋），直到锁变为可用状态。自旋锁的原理可以简单理解为以下几点：

1. 无阻塞等待：自旋锁不会将线程挂起或阻塞，线程会一直尝试获取锁。因此，它适用于短期内锁被占用的情况，以减少线程切换的开销。

2. 忙等待：自旋锁会让线程忙等，也就是不停地检查锁是否可用。这会消耗CPU资源，因此不适用于长时间的等待。

3. 原子操作：为了确保线程在竞争锁时不会产生竞态条件，自旋锁通常使用原子操作来更新锁的状态。原子操作能够保证在多线程环境下的原子性。

4. 公平性：自旋锁通常是非公平的，它不考虑等待时间，只要锁可用就立即获取，不考虑其他线程是否在等待。

使用场景：自旋锁在多核CPU上的性能较好，因为它可以减少线程切换的开销。但在单核CPU上使用自旋锁可能会导致性能下降，因为它会占用CPU时间。

自旋锁的适用场景通常是短期内锁的争用较小的情况，例如在多线程环境下对一些共享资源进行读写操作，或者在初始化阶段的互斥访问。在长时间的等待或大量线程争用的情况下，自旋锁可能不是最佳选择，因为它会浪费大量的CPU时间。

需要谨慎使用自旋锁，确保它在特定的场景中能够提供性能优势，同时避免忙等待时间过长导致的性能问题。

屏障​

屏障（Barrier）是一种同步机制，用于协调多个线程的执行，确保它们在特定点上等待彼此完成，然后再一起继续执行。理解屏障的原理可以分为以下几个关键概念：

1. 同步点：屏障通常在代码中的某个特定位置设置，这个位置被称为同步点。在同步点之前的线程会等待，直到所有线程都到达同步点才会继续执行。同步点可以用来确保多个线程在某个特定的执行阶段或时间点上进行同步。

2. 等待和唤醒：线程在达到屏障之前会等待，一旦所有线程都到达屏障，屏障会唤醒这些线程，使它们可以继续执行。屏障的等待和唤醒通常是由一个计数器来管理的，每个线程到达屏障时会将计数器减一，直到计数器减为零时，所有线程都被唤醒。

3. 线程协调：屏障用于协调多个线程的执行，确保它们在某个关键点上进行同步。这对于某些并发算法和多线程编程场景非常有用，例如并行计算、多阶段任务的协同工作等。

4. 阻塞和解除阻塞：在达到屏障之前，线程会被阻塞，无法继续执行。一旦所有线程都到达屏障，屏障将被解除，所有线程都可以继续执行。

5. 使用场景：屏障通常用于多线程协作的场景，例如在并行计算中，多个线程分别执行不同的计算任务，然后在某个阶段需要合并它们的计算结果，这时可以使用屏障等待所有线程完成各自的计算任务，然后再继续下一阶段的操作。

总之，屏障是一种同步机制，它用于协调多个线程在某个同步点上的等待和继续执行，以确保线程之间的协同工作和同步。屏障的原理包括等待、唤醒、计数器管理等机制，它在多线程编程和并发算法中发挥着重要作用。

原子操作​

原子操作是一种不需要显式锁的同步机制，它通过硬件支持的原子操作指令来确保对共享资源的原子访问。

CAS（Compare-And-Swap）是一种并发编程中常用的原子操作机制，用于实现多线程或多进程环境下的原子操作。 CAS操作是一种乐观锁（optimistic locking）的方式，其基本思想是：

1. 首先，读取共享变量的当前值。
2. 然后，与预期的旧值进行比较。
3. 如果当前值等于预期的旧值，就将新值写入共享变量；否则，认为操作失败，不进行写入。
4. 最后，无论是否写入成功，都会返回操作之前的当前值。

CAS操作的关键在于，它在操作共享变量时，不使用传统的加锁机制，而是通过比较当前值和预期的旧值， 来确定是否可以进行更新操作。这使得CAS操作可以在多线程环境下确保原子性，而无需显式锁定共享资源。

分布式锁​

分布式锁用于多个计算节点之间的同步，以确保在分布式系统中的共享资源或临界区的互斥访问。

1. 用途：

   • Nginx 是一个高性能的反向代理服务器和 Web 服务器。它最初设计用于提供 Web 服务和处理 HTTP 请求，但后来也扩展到处理 TCP 和 UDP 请求。Nginx 被广泛用于提供 Web 内容和负载均衡，以及用作反向代理来处理客户端请求并将它们转发到后端服务器。

   • Kong 是一个开源的 API 网关和微服务管理平台。它专注于管理和保护 API，包括认证、授权、访问控制、流量控制、监控等功能。Kong 提供了一个强大的插件系统，允许用户根据需要自定义和扩展其功能，以满足不同的 API 管理需求。

2. 功能：

   • Nginx 主要用于处理网络请求、反向代理、负载均衡、静态文件服务和 Web 服务器功能。它可以用来提供 HTTP 和 HTTPS 服务，以及 TCP 和 UDP 代理功能。

   • Kong 主要用于 API 管理和微服务架构。它提供了丰富的 API 管理功能，包括路由、认证、授权、限流、监控和日志记录等。Kong 还具备可扩展的插件系统，以支持各种自定义功能。

3. 插件系统：

   • Nginx 有一些可用的模块和插件，但插件生态相对较小，而且定制性有限。

   • Kong 的强大之处在于其插件系统。Kong 具有丰富的官方和社区插件，你可以使用这些插件来扩展 Kong 的功能，以满足特定的 API 管理需求。这使得 Kong 成为一个灵活的、可定制的 API 管理平台。

4. 配置和管理：

   • Nginx 的配置通常以文本文件的形式进行，需要手动编辑配置文件。虽然有一些工具可以帮助简化配置，但仍然需要一定的系统管理技能。

   • Kong 提供了一个基于 REST API 的管理界面，使得配置和管理更加简单和可视化。此外，Kong 也可以通过命令行工具进行配置管理。

一般来说：

• 如果你需要构建一个 API 管理平台或者需要更高级的 API 管理功能，Kong 可能更适合你。
• 如果你只需要一个反向代理服务器和 Web 服务器，那么 Nginx 可能是更常见的选择。

在某些情况下，也可以将它们结合使用，例如使用 Kong 作为 API 网关，同时使用 Nginx 来处理静态文件和负载均衡。

以下是一些配置上的区别和示例，展示了 Kong 和 Nginx 在用途和功能上的不同：

1. Kong 配置示例：

假设你想在 Kong 上创建一个 API，对请求进行认证，并应用速率限制。以下是一个 Kong 的配置示例：

# Kong 配置文件示例（YAML 格式）

admin_listen: 8001
proxy_listen: 8000

services:
  - name: my-api
    url: http://my-backend-service

routes:
  - name: my-api-route
    paths:
      - /api

plugins:
  - name: key-auth
  - name: rate-limit
    config:
      minute: 100

在这个示例中，我们定义了一个名为 my-api 的服务，然后定义了一个路由，将请求路径 /api 与该服务关联。我们还启用了两个插件，一个是 key-auth，用于认证请求，另一个是 rate-limit，用于限制每分钟的请求数。

2. Nginx 配置示例：

假设你想使用 Nginx 来反向代理到后端服务器，并配置 HTTPS 支持。以下是一个 Nginx 的配置示例：

# Nginx 配置文件示例

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    location / {
        proxy_pass http://backend-server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

upstream backend-server {
    server 127.0.0.1:8080;
}

在这个示例中，我们配置了一个 Nginx 服务器来监听 HTTPS 请求，并将它们反向代理到后端服务器（backend-server）。我们还配置了 SSL 证书以启用安全连接。这是一个简单的反向代理配置，Nginx 还支持更多功能，如负载均衡、缓存等。

区别和总结：

• Kong 专注于 API 管理，提供了高级的 API 管理功能，例如路由、认证、限流等。配置通常以 YAML 或 JSON 格式进行。

• Nginx 是一个通用的反向代理服务器和 Web 服务器，可以用于处理 HTTP 请求、负载均衡、反向代理等。配置通常以 Nginx 的专有配置语言进行。

• Kong 提供了一个可视化的管理界面，可以通过 REST API 进行配置管理。

• Nginx 提供了更广泛的用途，包括静态文件服务、负载均衡等，但在配置上可能需要更多的手动设置。

因此，Kong 更适用于 API 管理，而 Nginx 更适用于通用的反向代理和 Web 服务器需求。

/dev​

• /dev 是设备目录，用于存放设备文件，用于与硬件设备进行交互。
• 在 Linux 中，一切设备都被抽象成文件，这些设备文件位于 /dev 目录下。
• 例如：
  • /dev/sda: 硬盘设备的第一个分区。
  • /dev/ttyUSB0: USB 串口设备。
  • /dev/null: 特殊设备文件，用于丢弃数据，类似于黑洞。
• 通过读写这些设备文件，用户和应用程序可以与硬件设备进行交互和通信。

/proc​

• /proc 是虚拟文件系统，提供了对内核和进程信息的访问接口。
• 它不是真正的文件系统，而是运行时内核状态的映射，允许用户和进程通过文件访问内核的信息。
• 例如：
  • /proc/cpuinfo: 包含了 CPU 的信息，比如型号、频率等。
  • /proc/meminfo: 提供了系统内存的信息。
  • /proc/PID/status: 对应特定进程的状态信息。
• 使用 /proc 目录，用户可以动态地监视和配置内核参数，以及查看系统和进程的各种信息。

/bin​

• /bin 是二进制目录，包含了最基本的用户级别的命令和可执行文件。
• 这些文件通常是系统启动过程中所需的基本工具和命令，不依赖于其他目录或文件系统。
• 由于 /bin 目录在系统启动时就被挂载，所以即使出现文件系统问题，基本的系统工具也能够正常使用。
• 例如：
  • /bin/ls: 列出目录内容。
  • /bin/cat: 查看文件内容。
  • /bin/cp: 复制文件或目录。
  • /bin/mkdir: 创建目录。

/etc​

• /etc 是配置文件目录，包含了系统和应用程序的配置文件。
• 这些配置文件用于设置各种系统参数、网络配置、服务的启动脚本等。
• 例如：
  • /etc/passwd: 包含用户账户信息。
  • /etc/hosts: 存放主机名与 IP 地址的映射。
  • /etc/fstab: 挂载文件系统的配置文件。

/home​

• /home 是用户主目录的父目录，每个用户在系统上都有一个对应的子目录，用于存放个人文件和配置。
• 用户主目录通常被表示为 /home/username，其中 username 是用户的登录名。
• 例如：
  • /home/john: 用户 John 的主目录。
  • /home/mary: 用户 Mary 的主目录。

/usr​

• /usr 是 Unix 软件资源目录，包含了大部分用户安装的软件和应用程序。
• 它类似于 / 根目录，但主要用于存放不是系统启动所必需的文件。
• 例如：
  • /usr/bin: 存放用户安装的应用程序可执行文件。
  • /usr/lib: 存放共享库文件。
  • /usr/share: 存放共享数据文件，比如帮助文档、图标等。

/var​

• /var 是变量目录，包含经常变化的文件，如日志文件、邮件、数据库等。
• 它通常包含一些在运行时需要改变大小的文件，以及某些服务的运行时状态。
• 例如：
  • /var/log: 存放系统和应用程序的日志文件。
  • /var/spool: 存放邮件和打印队列等临时文件。
  • /var/www: 存放 web 服务器的网站数据。

/tmp​

• /tmp 是临时目录，用于存放临时文件和临时数据。
• 这些文件在系统重启时通常会被清除。
• 由于它是共享目录，因此所有用户都可以在 /tmp 目录下创建和访问临时文件。

/sbin​

• /sbin 是系统管理员命令目录，包含一些系统管理和维护的命令。
• 这些命令通常用于系统的管理任务，只有管理员才有权限执行这些命令。
• 例如：
  • /sbin/reboot: 重启系统。
  • /sbin/ifconfig: 配置网络接口。

/boot​

• /boot 是启动目录，包含了系统启动所需的文件，如内核文件和启动加载器配置。
• 当系统启动时，系统加载程序 (boot loader) 会从这个目录中找到内核并加载。

/lib​

• /lib 用于存放共享库文件。

/root​

• /root 是超级用户（root）的主目录，也称为 root 主目录。
• 超级用户是系统中拥有最高权限的用户，它的主目录位于 /root。
• 不同于一般用户的主目录（在 /home 目录下），root 主目录的权限只有 root 用户才能访问。

/opt​

• /opt 是可选目录，用于存放第三方软件包或额外安装的软件。
• 当某些软件包不遵循标准的文件系统层次结构时，可以选择将它们安装在 /opt 目录下，以保持整洁性。

/etc/opt​

• /etc/opt 是 /opt 目录的配置文件目录，用于存放与 /opt 目录中安装软件相关的配置文件。

/srv​

• /srv 是服务数据目录，用于存放系统服务（如 Web 服务器、FTP 服务器等）的数据文件。
• 例如，网站的文档根目录和用户上传的文件通常可以放在 /srv 目录下。

/mnt​

• /mnt 是挂载目录，用于手动挂载临时文件系统或其他设备。
• 当需要将外部存储设备（如 USB 驱动器、CD-ROM 等）连接到系统时，可以使用 /mnt 进行挂载。

/media​

• /media 是媒体挂载目录，用于自动挂载可移动媒体设备，如 USB 驱动器和光盘。
• 当插入可移动媒体设备时，系统通常会自动将其挂载到 /media 目录下的适当子目录中。

/run​

• /run 是临时运行时数据目录，用于存放系统启动后产生的临时运行时文件。
• 这个目录中的数据通常在系统重启时会被清理，不同于 /var 目录中的持久性数据。

通过本文，你可以学习并了解以下内容：

• 后端技术框架的重要性和作用
• 后端技术架构的发展趋势
• 常见后端技术框架
• 技术框架选择与评估
• 后端技术框架实践

后端技术框架的重要性和作用​

后端技术框架提供了一个结构化的框架，帮助开发人员构建高效、可靠和可扩展的后端应用程序。 这些框架简化了开发过程，提高了效率，促进了代码的组织和可维护性。

在后端技术框架中，最常见的核心模块之一是对 HTTP 请求处理的封装。一次完整的 HTTP 请求过程包括：

1. 接收请求：框架通过网络监听和接收传入的 HTTP 请求。
2. 请求报文解析：框架负责解析请求报文，提取出请求的方法、URL、请求头和请求体等信息。
3. 业务逻辑处理：框架将请求路由到相应的处理程序或控制器，执行具体的业务逻辑，可能涉及数据库操作、外部服务调用等。
4. 响应报文构建：在业务处理完成后，框架根据处理结果构建响应报文，包括设置响应状态码、响应头和响应体等内容。
5. 发送响应：框架将构建好的响应报文发送回客户端，完成一次完整的请求-响应周期。

GET / HTTP/1.1
Content-Type: text/html
Content-Length: 8
Connection: keep-alive
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

req body

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 9
Connection: keep-alive
Content-Encoding: gzip
Date: Fri, 23 Jun 2023 14:00:49 GMT

resp body

除了对 HTTP 请求的支持之外，技术框架还可以提供对开发流程的规范约束和最佳实践。 框架能够简化技术人员对底层细节的处理，并提供开发过程中所需的工具、库和组件，以加速应用程序的开发。

我们可以总结出现代后端技术框架在web开发过程中发挥的作用：

• 加速开发，提高效率
• 抽象底层细节
• 标准化架构设计和模式
• 丰富的工具/组件库

后端技术架构的发展趋势​

随着业务复杂度以及开发团队规模的不断扩大，后端技术架构呈现以下发展趋势：

• 单体架构
• 分布式架构
• 微服务架构
• 云原生架构
• 无服务器架构

让我们分别了解下每一个阶段架构的特点，以更好地理解它们的优势和适用场景。

单体架构​

单体架构是传统的应用架构模式，它将整个应用作为一个单一的、完整的系统进行开发和部署，具有简单、易于开发和测试的优点。

但随着业务的增长，可能面临扩展和维护的挑战。包括：

• 单点风险：一旦应用服务异常，则可能导致整个服务异常
• 可扩展性有限：单体架构在应对大规模和高并发的需求时存在单机瓶颈限制，难以实现水平扩展

为了解决以上问题，业界衍生出了分布式架构和多服务部署的方式。

分布式架构​

分布式架构将应用程序拆分为多个独立的模块，每个模块可以部署在不同的服务器或计算节点上。 通过分布式架构，可以实现系统的横向扩展和高可用性，并提供更好的性能和容错能力。

在分布式架构中，我们往往容易混淆它和多服务部署之间的关系。

分布式架构虽然解决了单点故障与瓶颈问题，但随着业务的增长，可能面临系统复杂度提升的挑战。主要包括：

• 系统复杂性增加：分布式架构中的各个组件和服务之间需要进行协同和管理，系统的复杂性增加。
• 异常定位困难：分布式架构往往涉及多个组件和服务之间的协同工作。一旦出现异常，跨服务的工作模式可能会给问题定位增加难度。

因此，如何按照一定的业务边界划分系统功能模块，提高模块的可复用性和可维护性就显得很关键了。

微服务架构​

当我们有了按业务拆分应用模块的想法时，做出来的产品就具有了微服务的雏形了。

其实在微服务成为潮流之前，还有一个很热门的阶段，就是我们常说的面向服务的架构（Service-Oriented Architecture，简称SOA）。 因为它们都具有拆的思想，所以很多同学都往往容易混淆。

微服务架构是一种基于分布式架构的设计模式，它将应用程序拆分为一组小型、独立的服务。 每个服务都可以独立开发、部署和扩展。其中，不同程序之间通过轻量级通信机制（SDK）进行互相协作。 微服务架构具有高度可扩展性、灵活性和自治性的特点。

当然，微服务拆多了也是一场运维灾难。实际拆分场景应该综合考虑业务（程序）的独立性、复用性和整体架构复杂度。

云原生架构​

随着容器化技术的兴起，云原生架构得到了广泛应用。

云原生架构是为云环境设计和构建的应用架构，利用云服务提供的弹性、可扩展和自动化特性。 它强调容器化部署、动态编排和自动化管理，以适应云环境的要求。

当前应用市场基本就是 K8S 全家桶了。

无服务器架构​

无服务器架构（Serverless Architecture）是一种以事件驱动和函数计算为核心的架构模式。 在无服务器架构中，开发人员可以编写独立的函数，由云平台自动管理函数的部署和资源分配，无需关心底层的服务器和基础设施。

常见后端技术框架​

后端技术框架的生态圈是非常丰富的。此处仅列举部分有代表性的框架：

极简主义​

所谓极简主义，就是框架本身没有任何限制，它仅仅提供最基础的Web开发能力。开发人员可以自由实现项目架构与内容组织。

Flask 就是典型的极简主义框架。它是一个轻量级且易用的框架，适合作为入门框架。

但这并不意味着 Flask 就没有任何深度了。要想深入学习和进阶一个框架，也是一件不容易的事。 如果你不了解 Flask 的蓝图、钩子、线程本地数据等机制，那你可能还需要再研究研究。

全能战士​

能被称作"全能战士"的框架，一定都是市场占有度非常高的。而 Django 就是典型的"全能战士"框架。

相比于极简主义，Django 在设计上更加全面，它提供了更多的内置功能和约定，旨在为开发人员提供最大的开发效率和生产力。 它包含了诸多功能，例如对象关系映射（ORM）、认证和授权系统、管理界面、表单处理、缓存机制等等。 这些内置功能使得 Django 成为一个完整而强大的框架，适用于大型和复杂的Web应用程序的开发。

微服务框架​

看名字就知道是老潮流了。此处我们以 B 站开源的 Kratos 为例简单介绍下。

Kratos 是一款开源的微服务框架，由 Bilibili 开发并开源。 它是基于 Go 语言构建的，旨在帮助开发人员更轻松地构建高性能、可扩展的微服务应用程序。

相比于我们的"全能战士"，微服务框架还提供了微服务治理的能力。 包括我们常说的服务注册与发现、负载均衡、熔断器等，这些可以帮助开发人员更好地管理和监控微服务应用。

技术框架选择与评估​

那么有这么多技术框架，我们如何选择和评估最合适的技术框架呢？

通常情况下，减少变量是最佳选择。

比如你身处在一个团队中，那么使用团队中已有的技术框架是最佳选择。

因为引入新的技术不仅有一定的学习成本，在某些时候甚至会引入风险。因为"前沿"技术并不一定是"稳定"的。

如果确实需要重新选择技术框架，应优先从业务角度出发进行评估和选择。

• 对于重点交付的项目，可以考虑Java Spring全家桶，它在国内具有广泛的应用。
• 对于高性能云端项目，可以考虑使用Go语言，它在性能和内存占用方面具有优势。
• 对于一次性交付的工具、爬虫等，可以考虑使用Python实现快速交付。

当然，这仅仅只是其中的部分选择。对于具有成熟脚手架的团队来说，可以按照团队的技术栈灵活选择。

后端技术框架实践​

这里主要介绍一下作者的开源项目 Pywss。

Pywss（发音 /piːwaɪz/，类似 p~whys）是一个轻量级的 Python Web 框架，它基于 Python3.6+ 特性构建。

与 Flask、Django 等主流框架不同的是，Pywss 的底层并没有实现 WSGI 接口协议。 其编程风格也更类似于 Gin、Iris 等框架，因此对于熟悉这些框架的开发者来说，Pywss 是一个非常值得探索的项目。

其关键特性有：

• 简单：拒绝海量参数，减少心智负担。了解上下文 pywss.Context 即刻启程。
• 快速：纯手撸 socket，拒绝中间商赚取性能差价。(实在有性能追求的同学，不妨再探索下其他语言~Go~)
• 优雅：ctx.next 真的太优雅了。如果你也和我一样喜欢，那我觉得这件事情，泰裤辣！！
• 标准化：集成了部分 OpenAPI（Swagger）能力，方便开发者快速生成 API 文档并进行调试。
• 支持WebSocket：开箱即用的 WebSocket 能力。
• 接口测试：开箱即用的 API 测试模块，不启动服务也能测试接口功能辣！

在线文档 https://czasg.github.io/pywss/

1. 应用层（Application Layer）：

   • 应用层是用户与网络通信的接口，负责为应用程序提供网络服务。 它包括各种应用协议，例如HTTP、FTP、SMTP等。在这一层上，数据被封装成应用层数据包。

   • 举例：当您使用Web浏览器访问一个网站时，浏览器会使用HTTP协议发送请求，该请求是在应用层上创建的数据包。

2. 表示层（Presentation Layer）：

   • 表示层负责数据的格式转换和加密解密等操作，确保不同系统之间能够正确地解释数据。在TCP/IP协议族中，表示层的功能很少被使用，因为大多数应用程序在应用层处理了数据格式的问题。

3. 会话层（Session Layer）：

   • 会话层负责建立、管理和终止会话连接，确保通信双方之间的通信顺序和数据完整性。在TCP/IP协议族中，会话层的功能也很少被使用，因为这些任务通常由应用层处理。

4. 传输层（Transport Layer）：

   • 传输层提供端到端的数据传输服务。最常用的协议是TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）。

   • 举例：当您在Web浏览器中访问一个网站时，浏览器会使用TCP协议建立一个与服务器的连接，确保数据的可靠传输。而在视频会议或实时游戏等场景中，可能会使用UDP协议，因为它具有较低的延迟，但可靠性较差。

5. 网络层（Network Layer）：

   • 网络层负责数据包的路由和转发，以及IP地址的分配。最常用的协议是IP（Internet Protocol）。

   • 举例：在互联网上，当您的计算机发送一个数据包到目标服务器时，数据包会在网络层被路由器转发，根据目标IP地址找到正确的路径。

6. 数据链路层（Data Link Layer）：

   • 数据链路层负责将数据包封装成数据帧，处理物理地址（MAC地址）和错误检测等。最常用的协议是以太网（Ethernet）。

   • 举例：在局域网中，当您的计算机发送一个数据帧到另一台计算机时，数据帧会在数据链路层添加源MAC地址和目标MAC地址，然后通过交换机或直接连接到目标计算机的设备传输。

7. 物理层（Physical Layer）：

   • 物理层负责数据的物理传输，包括电缆、网卡、光纤等物理设备和接口。

   • 举例：当数据帧在计算机之间通过网线传输时，物理层将数据转换为电信号，并通过网卡的物理接口发送到传输媒介上。

入参是确定的​

func demo() {
    i := 1
    defer fmt.Println(i) // 输出1
    i++
    return i
}

入参在 defer 出现时刻已经确定，因为执行 defer fmt.Println(i) 时已经生成临时变量拷贝了一份参数。

后近先处​

这个通常没有问题，即后面定义的 defer 会先执行，很好理解。

可操作具名参数返回​

func demo() (result int) {
    i := 1
    defer func() {
        result++ // demo函数返回值为2
    }
    return i
}

此处函数 return 实际可以拆解为两步，即：

result = i
return

故 defer 会修改此处实际返回值。

不可操作非具名返回​

同样的函数我们作下适当的调整

func demo() int {
    i := 1
    defer func() {
        i++ // demo函数返回值为1
    }
    return i
}

在执行 return 的时候，已经生成临时变量存储返回值，故延迟函数 defer 无法对返回值做出修改。

作为一个管理者，我们通常从以下几个方面考虑或评价一名员工：

• 工作表现
• 团队合作能力
• 个人素养

对于快要转正的员工，应该针对以上几个方面进行评价，并给出相应的建议。

首先是工作表现。我会考虑员工在工作中的表现，包括完成任务的效率、工作质量、创新能力等。 如果员工在这些方面表现良好，我会积极推荐他转正，并给出具体的工作建议，帮助他进一步提升工作表现。

其次是团队合作能力。一个好的员工应该具备良好的团队合作能力，能够与其他团队成员有效地沟通和协作。 如果员工在这方面表现良好，我会鼓励他在团队中继续发挥作用，并给出一些团队合作方面的建议。

最后是个人素养。一个好的员工应该具备高度的职业素养，包括诚实、守时、自律等。 如果员工在这方面表现良好，我会积极推荐他转正，并给出一些个人素养方面的建议，帮助他进一步提升自己。

综上所述，作为一个管理者，需要从多个方面综合评估员工，并给出积极的评价和建议，帮助他们更好地成长和发展。

import csv

with open("file.csv", "w", encoding="utf-8", newline="") as w:
    csv_w = csv.write(w)
    csv_w.writerow(["中文乱码"])

通过排查，发现改变编码方式可以解决这个问题。即把utf-8变更为utf-8-sig编码。

import csv

with open("file.csv", "w", encoding="utf-8-sig", newline="") as w:
    csv_w = csv.write(w)
    csv_w.writerow(["中文正常展示"])

原因分析：

uft-8-sig 中的 sig 表示 signature，也就是带有签名的 utf-8。

Excel 在读取 csv 文件的时候是通过读取文件头上的 BOM 来识别编码。如果文件头没有 BOM 信息，则默认按照 Unicode 编码读取。

当我们使用 utf-8 编码来生成 csv 文件的时候，由于并没有生成 BOM 信息，Excel 就会自动按照 Unicode 编码读取，从而导致了乱码问题。

JWT 结构组成包括三个部分：

• Header：一般用于指定token类型，包括alg和typ两个字段
• Payload：数据载体，一般需要包含exp表示过期时间
• Signature：摘要，是前面两个部分的摘要运算

组成形式为 Header计算Base64 . Payload计算Base64 . 前两部分哈希运算

import json
import time
import base64
import hashlib


class JWT:

    def __init__(self, secret: str, expire: int = 3600):
        self.secret = secret.encode()
        self.expire = expire
        self.header = base64.b64encode(json.dumps({
            "alg": "HS256",
            "typ": "JWT",
        }, ensure_ascii=False).encode())

    def encrypt(self, **kwargs):
        kwargs.update(exp=int(time.time()) + self.expire)
        payload = base64.b64encode(json.dumps(kwargs, ensure_ascii=False).encode())

        sha256 = hashlib.sha256()
        sha256.update(self.header)
        sha256.update(payload)
        sha256.update(self.secret)
        signature = sha256.hexdigest()

        return f"{self.header.decode()}.{payload.decode()}.{signature}"

    def decrypt(self, token: str) -> dict:
        if token.startswith("Bearer"):
            token = token.replace("Bearer", "", 1).strip()

        tokens = token.split(".")
        if len(tokens) != 3:
            raise Exception("Invalid JWT Token")

        header, payload, signature = tokens  # type: str
        sha256 = hashlib.sha256()
        sha256.update(header.encode())
        sha256.update(payload.encode())
        sha256.update(self.secret)
        if sha256.hexdigest() != signature:
            raise Exception("Invalid JWT Token, Signature Except")

        return json.loads(base64.b64decode(payload))

爬虫服务能够在网络上不知疲倦的获取信息，所以一般会带有某些易于常人的特征

反爬则基于这些特征进行拦截，而反反爬有两个思路：
1、消除爬虫特征，使得自己像正常人一样。比如降低爬取频率就是一个不错的方案~
2、破解反爬技术，即使被识别仍然可以获取

在反反爬的技术领域，有这么一类偏方，就是自动化。
它完全模拟常人操作，从而达到"一力破万法"的效果。

但随着反爬技术的进一步完善，自动化工具也逐渐的被识别并拦截，随之而来的就是一波反反爬技术的升级~

CDP​

CDP 全称为 Chrome Devtools-Protocol

通过执行 CDP 命令，可以在网页加载前运行一段代码，进而改变甚至屏蔽部分浏览器的指纹特征。

由于浏览器特征种类过多，所以可以直接使用现成的工具，直接屏蔽大部分特征。参考： stealth.min.js

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By
import time

chrome_options = Options()

# 无头模式
# chrome_options.add_argument("--headless")

# 添加请求头
chrome_options.add_argument(
    'user-agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36')

s = Service(r"chromedriver.exe路径")

driver = webdriver.Chrome(service=s, options=chrome_options)

# 利用stealth.min.js隐藏浏览器指纹特征
# stealth.min.js下载地址：https://github.com/berstend/puppeteer-extra/tree/stealth-js
with open('./stealth.min.js') as f:
    driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", {
        "source": f.read()
    })

driver.get(url='URL')
# driver.get(url='https://bot.sannysoft.com/')

# 保存图片
driver.save_screenshot('result.png')

time.sleep(200)

undetected_chromedriver​

这是一个防止浏览器指纹特征被识别的依赖库，可以自动下载驱动配置再运行

pip install undetected-chromedriver

from selenium.webdriver.chrome.options import Options
from selenium.webdriver.chrome.service import Service
import time
import undetected_chromedriver as uc

chrome_options = Options()
# chrome_options.add_argument("--headless")

s = Service(r"chromedriver.exe")

driver = uc.Chrome(service=s, options=chrome_options)

driver.get(url='URL')
# driver.get(url='https://bot.sannysoft.com/')

driver.save_screenshot('result.png')
time.sleep(100)

操作已开启的浏览器​

操作的原理是先单独开启一个浏览器，并开启远程调试能力，如：

import subprocess

# 1、打开浏览器
# 指定端口号为：1234
# 配置用户数据路径：--user-data-dir
cmd = 'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe --remote-debugging-port=1234 --user-data-dir="C:\\selenum\\user_data"'

subprocess.run(cmd)

然后调整代码，远程加入调试：

import time
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.chrome.service import Service

# 操作上面已经打开的浏览器，进行百度搜索
chrome_options = Options()

# 指定已经打开浏览器的地址及端口号
chrome_options.add_experimental_option("debuggerAddress", "127.0.0.1:1234")

# 注意：chrome版本与chromedirver驱动要保持一致
# 下载地址：http://chromedriver.storage.googleapis.com/index.html
s = Service(r"chromedriver.exe")

driver = webdriver.Chrome(service=s, options=chrome_options)

# 打开目标网站
driver.get(url="URL")

time.sleep(200)

整理下结构化思考中捋清事务脉络的方式。

说话时，适当减慢语速。不要让思维跟不上表达。

自我介绍​

• 给自己绑定少量标签
• 我为什么来这里
• 我能带来什么价值

祝辞​

• 自我简介
• 感谢
• 回顾
• 愿景

谈话​

• 表扬
• 批评
• 表扬

复盘​

• 回顾目标
• 结果对比
• 亮点介绍

排错​

• 找到问题
• 分析原因
• 解决方案
• 达成结果

因为列表是按主键排序的，所以显示是没有问题的。

问题就在于，为什么最新的数据，主键会小于前几天的数据。

之后，我们通过阅读官方文档，发现这似乎并不是一个异常。

::: info TiDB 的自增 ID (AUTO_INCREMENT) 只保证自增且唯一，并不保证连续分配。
TiDB 目前采用批量分配的方式，所以如果在多台 TiDB 上同时插入数据，分配的自增 ID 会不连续。
当多个线程并发往不同的 tidb-server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。 此外，TiDB允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 AUTO_INCREMENT 的字段。 :::

文档参考：

• https://docs.pingcap.com/zh/tidb/v4.0/auto-increment
• https://docs.pingcap.com/zh/tidb/v4.0/mysql-compatibility

• 检测

python setup.py check

• 构建

python setup.py sdist

• 上传

pip install twine
twine upload dist/__packages__-__version__.tar.gz

文件管理​

在正常构建过程中，打包程序可能会索引到一些测试、缓存文件，比如：

• pycache
• *.pyc
• *_test.py

此时，我们可以通过引入MANIFEST.in文件，来对构建过程中的文件进行简单管理。相关指令有：

文件或者目录，可以提供精确名字，也可以提供正则匹配。如：

include LICENSE
include MANIFEST.in
include requirements.txt

exclude README.md

global-exclude __pycache__
global-exclude *.py[cod]
global-exclude *_test.py
global-exclude test_*.py

prune test
prune demo

• inline-block
• flex + flex-wrap
• grid

inline-block​

在子元素中增加inline-block属性

.block {
    display: inline-block;
}

flex​

在父元素中使用，此时不能设置高度。

.block {
    display: flex;
    flex-wrap: wrap;
}

因为flex-wrap属性指定flex元素单行显示还是多行显示，设置了高度将会平铺。

grid​

在父元素中使用，此时不根据大小平铺，而是强制平铺

.block {
    display: grid;
    grid-template-columns: 1fr 1fr 1fr; /*横向排布时，宽度均分为三等分*/
}

比如你只是想简单的 Head 请求，但当对方响应 302 时，实际最后获取到的就是 Location 的结果。

实际我们可以通过自定义 http client 实现非跳转请求：

var client = http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        return http.ErrUseLastResponse
    },
}

然后同事开发的（Go）程序是先创建一个文件，然后写入下载数据。再没有关闭文件的前提下，重新又开启了一个新的文件流来计算MD5。

由此引发了一些争执...

为此我据理力争：

文件IO在write的过程，是不保证落盘的，即有一部分数据会暂存在内存中。
在这种情况下，重新创建一个只读的文件流，可能读不到在内存中的数据...

但是同事用实际证明了，这段代码再实际计算过程，并没有任何问题...

我自己也无法复现...

之后用Python测试了下，发现确实读不到，但Go就是可以读取到...

with open("tmpfile", "w", encoding="utf-8) as w:
    w.write("hello world")
    
    with open("tmpfile", "r", encoding="utf-8") as r:
        assert r.read() == "hello world"

最后总结：

Go 文件句柄调用 Write 时是直接调用的系统接口，故可以读取到未落盘。

Python 则是自己实现了缓存机制。在 Go 中也有 bufio 库可以实现类似的机制

Paas: Platform as a service 平台即服务

Saas: Software as a service 软件即服务

以个人搭建服务为例：

当我们开发好一个服务，需要进行部署时，我们可以直接购买物理机进行部署，但这样我们就需要直接面对物理机的维护，还有网络维护等问题。
为了避免这些繁琐的问题，我们更简单的方法是直接去云服务厂商租一台云服务器，然后将我们的程序部署在此服务器上。
该云服务器为我们提供了计算、存储、网络等硬件基础能力，这种租硬件设备的服务就是Iaas。

所以如果你有过购买过服务器的精力经历，那其实你就已经购买过Iaas服务了~

如果我们开发的服务，涉及类似支付等三方能力时，我们几乎不可能自己写一套支付交易系统，更多的是对接微信、支付宝等三方支付接口。
这类服务就是Paas，平台即服务。

以上服务都是自己开发的，市面上还有很多服务是通过提供软件服务，如果购物系统、物流系统、采购系统等，这些就是Saas服务了。

SELECT
    proname 
FROM
    pg_proc 
WHERE
    prosrc LIKE'%table_name%';

需求说明：在众多函数中，找到与目标表相关的函数。

实现说明：

• pg_proc：pg存储函数的表
• prosrc：是函数源码，通过模糊匹配查询所有源码中，与目标表有关的函数
• proname：函数名

SELECT 
    SUBSTRING( ( table.key -> 0- > 'rule' -> 0 ) :: TEXT, '=*([0-9a-zA-Z]*);' ) AS hash 
FROM
    table;

需求说明：table.key是一个JSONB字段，存储数据为：[{"rule": ["hash=hashstring;"]}]，现需要解析此数据， 并截取出此数据结构中的哈希数据。

参考：9.15. JSON 函数和操作符
参考：9.4. 字符串函数和操作符

我个人理解，引擎更多用于定义一种经过高度抽象的业务执行逻辑。

mysql.connector.errors.OperationalError: 2055: Lost connection to MySQL server

排查与定位​

从连接信息可以快速看出，是数据库连接丢失了，我们首先做了简单的服务重启，并重试请求，期间同步观察数据库状态，确保数据库服务持续可用。

神奇的是，这是一个必现的错误。

File "/usr/local/lib/python3.6/site-packages/mysql/connector/network.py", line 140, in send_plain 
    self.sock.sendall(packet) 
BrokenPipeError: [Errno 32] Broken pipe 

继续排查日志，我们看到是在推送数据的过程，连接损坏了。由于是必现，所以网络不稳定基本可以排除。
我们怀疑这可能是数据库侧的主动行为，即触发了某些机制，导致数据库强制关闭了连接。

我们拿到了待执行的SQL，直接在Navicat上进行复现，发现了新的错误信息：

Got a packet bigger than 'max_allowed_packet' bytes

这明显就是单次请求大小超过了数据库的限制，所以导致连接被强制关闭。但是被SQLAlchemy封装了一层，导致错误信息有部分偏差。

修复​

通过查询得知当前数据库单次请求体积不能查超过4M

show variables like 'max_allowed_packet';

调大即可，这里我调到了64M，满足当前业务述求。

set global max_allowed_packet = 67108864;

我们常说的web服务，通常是指的HTTP WEB服务。

在不了解web服务之前，我一直很好奇一件事情。
我在浏览器里输入一个地址，他会返回一些内容给我。 我一直困惑于他实现的原理是什么？我是不是也可以自己搭建一个这样的服务？以前梦想就是想自己搭建一个web服务。

如果你学过python，那你一定用过requests库，我们用它来发起一次HTTP请求

import requests  # pip install requests

resp = requests.get("http://www.baidu.com")
print(resp.text)

这是一段非常简单的代码，但不知道你们有没有想过，它最底层是怎么实现的，为什么这么简单的几行代码，就可以发起一次HTTP请求。

import socket

sock = socket.socket()
sock.connect(("www.baidu.com", 80))  # 建立TCP连接

sock.sendall("GET / HTTP/1.1\r\n\r\n".encode())  # 自己构造请求，发送给服务端
print(sock.recv(1024*1024).decode())

HTTP请求报文

• 请求行
• 请求头
• 请求体

HTTP响应报文

• 响应行
• 响应头
• 响应体

抛开所有的业务，所有的实现，我们来看一下HTTP的请求，或者说web服务的本质，其实就是我给你一段文本，你给我一段文本。

框架使用多了，特别是一些集成度很高的框架，可能会使我们失去一些基础的能力、判断力。

如何实现一个web服务​

我们先来看看flask框架如何实现一个web服务

import flask

app = flask.Flask(__name__)
app.route("/hello", methods=["GET"])(lambda: "hello world")
app.run()

通过route注册一个路由，然后绑定一个匿名函数，最后启动服务。

这是我们能看到的框架，那么框架帮我们做了什么事情呢？
首先，第一件事肯定是帮我们解析HTTP请求报文，然后你觉得他们会做什么事情。
他会去匹配路由，然后执行对应的处理函数。

接着，我们来看下如何基于socket实现方式。
基于socket，我们可以非常轻松的实现一个简陋的web服务，这个服务接收任何请求，然后响应hello world

import socket

sock = socket.socket()
sock.bind(("localhost", 8080))
sock.listen()

while True:
    s, addr = sock.accept()
    print(s.recv(1024*1024).decode())
    s.sendall("HTTP/1.1 200 ok\r\nContent-Length: 11\r\n\r\nhello world".encode())
    s.close()

如何实现一个web框架​

框架的目的，是为了减少重复性工作。那么我们实现这个框架的目的，就是为了不在自己解析HTTP请求和构造HTTP响应。

结构化日志的最大好处就是简化日志解析，便于日志分类、聚合。

定义标准​

在开始编程前，需要先设计好项目的整体架构。

日志基础信息​

首先，日志格式我们选择JSON格式。
此外，还需要附带基础日志信息，这里我们选择时间和日志级别。

import json, datetime

def log(msg):
    print(json.dumps(dict(
        time=f"{datetime.datetime.now()}",
        level="info",
        msg=msg,
    )))
log("hello world")

这样，一个简单的结构化日志雏形就已经出现了。

项目结构​

• Logger: 日志实体
  • Level: 日志级别
  • Format: 日志格式
  • Hook: 日志钩子
• Entry: 数据实体
  • Data: 数据

ServiceMesh：服务网格 是致力于解决服务间通讯的基础设施层。负责现代云原生应用程序的复杂服务拓扑来可靠的传递请求。 本质是一组轻量级的网络代理。和服务应用部署在一起但是对程序透明。 特点： 1、应用程序间通讯的中间层 2、轻量级的网络代理 3、应用程序无感知 4、解耦应用程序的监控、追踪与服务发现

微服务框架-服务治理技术演进：
第一阶段：服务治理能力抽象到统一的SDK实现
优点：

• 代码重复少
• 治理逻辑代码与业务代码隔离 缺点：
• SDK语言绑定
• 代码侵入
• 基于SDK有学习成本

第二阶段：服务治理能力归一到服务网格
优点：

• 独立进程，用户业务非侵入
• 语言无关
• 既有服务无需改造直接使用 缺点：
• 服务治理代理的性能和资源开销

微服务： 1、实现上，把一个大系统，按照业务功能分解为多个职责相对单一的小系统。并利用简单的方法使多个系统之间相互协作，组成一个大系统。
2、本质上，把相同领域或者因相同原因而变化的功能聚合到一起，把不同业务领域或因不同原因而变化的功能拆离开，并使用轻量化机制（HTTP RESTful API）实现通信。

正文在此处

ACL 是 Access Control List 的缩写，表示访问控制列表。

资源列表:
- 核心资产页面:
  - 用户: 员工A
    权限: 无权限
  - 用户: 员工B
    权限: 查询权限
  - 用户: 员工C
    权限: 增话、删除、修改、查询权限

ACL 的设计思想主要是围绕资源来设计的权限管理

从维护角度来看，每新增一名用户时，需要赋予初始化权限，会比较繁琐。但针对员工的权限修改，会显得比较容易。

RBAC​

RBAC 是 Role Base Access Control 的缩写，表示基于角色的访问控制，

用户表:
- 用户: A
  角色: [研发]
- 用户: B
  角色: [测试]
---
角色表:
- 角色: 研发
  权限: [修复BGU]
- 角色: 测试
  权限: [创建BUG]
---
权限表:
- 权限: 创建BUG
  资源表:
  - 资源: BUG单
    权限: [创建、修改]
- 权限: 修复BGU
  资源表:
  - 资源:: BUG单
    权限: [修改、完成]

RBAC 的思想，来源于现实世界中的企业结构，不同的角色设计有不同的权限，而不用的主体将拥有一个至多个角色。

从维护角度来看，在相对静态的情况下，是比较容易维护的。相对静态的意思就是说，每个角色拥有的权限是相对固定的。
比如一名刚入职的员工，他的角色可能就是未转正员工，此时该名员工所拥有的权限将是非常小的一部分。 但是由于某些特殊情况，这名员工又需要申请更高权限时，就会比较难处理。因为不能直接修改角色的权限，这样会破坏这名角色的原生属性。
在这种场景下，一般只能创建新的角色并赋予此名员工，这样就会降低系统的可维护性。

一把合格的分布式锁，应该至少具备以下特征：

• 互斥性：任意时刻，只有一个客户端持有。
• 超时机制：持有锁并超时时，可以自动释放，避免死锁。
• 安全性：在未超时场景下，锁只能被持有者释放。

单节点分分布式锁​

SET 是 redis 关键字指令，属于原子操作，其作用是给指定 key 赋值 value。并且支持 NX 和 PX 参数：

• NX：if not exists 缩写，当 key 不存在时才允许赋值成功。
• PX：表示过期时间。

SET key uniqueValue NX PX 1000

具体的场景如下：
1、用户一：创建随机值，使用 set 赋值，赋值成功，持有分布式锁。
2、用户二：创建随机值，使用 set 赋值，赋值失败。
3、用户一：执行任务超过1秒，自动释放锁。
4、用户二：创建随机值，使用 set 赋值，赋值成功，持有分布式锁。
5、用户一：任务结束，获取锁，对比当前锁是否属于自己，不属于则忽略。

多节点分布式锁​

单节点 redis 可以基于 SET key uniqueValue NX PX 1000 实现分布式锁，但存在宕机的风险。
所以 redis 作者提出了 redlock 算法，用于支持多节点下的分布式锁。

其算法步骤（以5个节点为例）：
1、获取当前时间戳 和 UUID值。
2、基于过期时间选择毫秒级的网络连接和响应时间。
3、客户端逐一去申请锁，申请方式和单节点一样，当从 N/2 + 1 个节点都获取到锁，且使用时间小于当前锁失效时间，才算获取成功。
4、真正的执行时间，时过期时间-获取锁的时间-时钟偏移时间。
5、释放锁时需要每一个节点都尝试释放锁。

PEP8 则表示其中第8条提案，这是针对编码规范的提案。其中包括：命名规范、编排规范、注释规范、代码规范等。

换句话说，gitlab-runner和我们的代码仓是完全解耦的。是可以部署在其他服务器上，并且可以部署多个的。

1、创建 volume​

首先需要为 gitlab-runner 创建一个公共配置存在路径，目的是为了共享配置。

可以是具体的文件路径，也可以使用 docker volume create 创建一个公共挂载，后续其他的 runner 都挂载此目录，即可实现共享配置。

docker volume create gitlab-runner-config

2、注册 runner​

首先需要获取 gitlab 基础信息。

然后注册 runner

docker run --rm -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner register \
  --non-interactive \
  --url "Gitlab 的 URL 复制过来" \
  --registration-token "Gitlab 的 Token 复制过来" \
  --executor "docker" \
  --docker-image "要运行的镜像，eg: python:3.6.8" \
  --description "docker-runner-test" \
  --tag-list "docker,test" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected" \
  --docker-pull-policy="if-not-present"

注册完成后，在 gitlab 界面会出现你注册的 runner 信息。没有可以刷新看看，实在没有，应该是注册失败了。

3、启动 runner​

docker run -it --name gitlab-runner --rm \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v gitlab-runner-config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest help

docker run -it --name gitlab-runner --rm \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v gitlab-runner-config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest help unregister

docker run -it --name gitlab-runner --rm \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v gitlab-runner-config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest list

docker run -it --name gitlab-runner --rm \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v gitlab-runner-config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest unregister -t=GIRLAB_TOKEN

KPI 指 Key Performance Indicator，即关键绩效指标。

对于公司来讲，他可以将公司的目标从上至下地分解，然后通过相关的关键绩效指标来衡量实际的执行效果。

KPI 存在的问题​

经过大量实践证明，KPI 只适合标准化的、目标稳定的工作。

比如某标准的工业流水线中，KPI 可以制定流水线中转化效率、转化比率等，这些都是可以定量的。
但是对于创新类技术来说，它存在比较大的不确定性。这种类型就不适合用 KPI 来衡量了。

其次，KPI 会给团队带来不良风气，比如：
1、追求低指标：如果制定指标过高，完不成，那就是搬起石头砸自己的脚，所以大家会更倾向于制定低指标。
2、追求短视：一些需要长期投入的事情会被人嫌弃，大家更加关注短期获益的KPI。
3、工作和考核本末倒置：在制定和把控严格的KPI管理上，投入了大量的时间和精力。等真正到了具体执行上，却敷衍了事。这类现象比比皆是。

什么 OKR​

OKR 是 Objectives and Key Results，即目标与关键成果。

它的实施步骤是：
1、首先制定业务目标 Objectives。比如：提升某系统稳定性。
2、然后为每个目标设定关键结果 Key Results。比如：为了实现 提升系统稳定性 这个目标，计划引入数据库主备机制、异地多活方案等。

OKR 和 KPI 之间的区别与联系​

我们会发现 OKR 和 KPI 很像，整体看下来甚至都没有什么区别。因为 OKR 中的一个 KR，似乎就是一个 KPI 指标。

其实区别很简单，KPI 中的关键词是 Indicators，而 OKR 中的关键词是 Objectives。
换句话说，KPI 关注的是数据指标，OKR 关注的是业务目标。

为了更好的理解，可以举个简单的例子，以某场比赛为例：
如果从 KPI 的角度看，我们则更关注拿到几分、赢了几场等。
如果从 OKR 的角度看，我们更关注夺冠、进四强、保级等。

关键区别点就是指标和目标这两个词，虽然只是简单的两个词，却反映了两种截然不同的思维方式。

当我们使用 KPI 规划法时，更关注数据指标，第一思维就是：我要做什么事。在这种思维下我们更关注当下已有的工作。
当我们使用 OKR 规划法时，更关注业务目标，第一思维就是：我要做成什么事。在这种思维下我们全局定位方向，再指定KR。

除此之外，OKR 和 KPI 也有很强的内在联系。
OKR 的 KR 就有两种表现形式，一种就是 KPI，一种就是里程碑。

两类数据库各有高低，本文主要学习总结下二者之间的特点，以及各自的优势。

PG相较于MySQL优势​

首先 PG 完全开源，相较于 MySQL 来说，拥有更迅速的功能迭代。

更丰富的数据类型​

除了常规的数据类型外，PG 的数据类型更加丰富，且完善了部分 MySQL 数据类型的一些槽点。

支持json、jsonb类型​

随着json格式的流行，越来越多的数据存储和传输，采用json格式。

但存储这类半结构化数据，对于关系型数据库来说并不友好。往往只能先将json数据序列化为成字符串，然后存储字符串。
这也是 MongoDB 等非关系型数据库逐渐流行的原因之一。

PG 支持 json、jsonb 两类数据类型：

• json：存储文本数据，每次读取都会对其进行json解析。不支持索引。
• jsonb：存储二进制数据，相对于json类型来说，避免了重复解析，并且支持索引。

所以当数据库字段设计时，仅仅有部分字段数据类型是半结构化的，数据库选型时 PG 将是非常优秀的选择。

text无长度限制，支持全文索引​

一般关系型数据库的字符串有长度限制，大小在8k左右，PG 则没有限制。

字符编码支持更友好​

对于 emoji 的存储，MySQL 需要 utf8mb4 编码才能正确显示，在 PG 种遇不到。

更丰富的索引类型​

MySQL 的索引类型取决于底层引擎选型，像 MyISAM、InnoDB 等支持B+树索引类型。
PG 则支持B+数索引、哈希索引、Gist索引等。

更丰富的集群支持​

MySQL 的集群高可用依赖于主从复制（replication），其底层基于 binlog 实现，并且是异步的。
这种同步方案很难实现同步复制，更适合异地复制的场景。当主从节点处理能力不一致时，特别是主节点能力弱于从节点时，可能会存在较大的麻烦。

PG 的主备复制属于物理复制，相较于binlog的逻辑复制，数据的一致性更加可靠，复制性能更高，对主机的影响也更小。
PG 集群有较多的插件：

• slony 支持字段级的同步集群。
• standby 支持WAL文件级或流式的读写分离集群。

MySQL相较于PG优势​

业界主流​

主流就意味着你能找到更多的用户经验、解决方案、文档等。

线程模式比进程模式更占据优势​

MySQL 使用了线程，而 PG 使用的是进程。

进程之间的调度开销要比线程大很多。也是因为这个原因，PG 默认最大连接数只有 100，对于数据库来说，这是非常小的连接数了。
因此，PG 更需要类似 pgbounder 的连接池代理服务来确保数据库稳定。

存储引擎插件化​

MySQL 的存储引擎插件化机制，是的它的应用场景更加广泛，比如 InnoDB 适合事务场景，MyISAM 则更适合静态数据的查询场景。

索引组织表​

以 InnoDB 为例，B+树索引中，主键索引树中叶子节点存储的就是物理数据，普通节点物理索引存储的是主键的索引。

PG 的索引记录的均是物理位置，需要二次查询。

默认 HttpClient 未配置超时​

默认的 http.DefaultClient 不包含请求超时时间。在某些场景会造成程序异常阻塞。

client := &http.Client{
    Timeout: 60 * time.Second,
}

网络IO属于事件驱动型，可以通过注册回调实现异步化。
磁盘IO的 read/write 都是同步IO，是阻塞事件，需要同步等待。

所以，磁盘IO会造成Go的线程阻塞，而Go基于GMP模型，当M阻塞的时候，会重新创建新的M来执行G任务。
所以当类似任务足够多时，会造成Go的M暴涨，超过1w以后，会被杀掉。

为了解决这个问题，引入了go mod。

go mod​

go mod 是一个包依赖管理工具。

git没法拉代码​

go mod vendor拉取代码报错：

The project you were looking for could not be found

这种属于git未配置好导致的，可以再根目录下创建：

https://user:pwd@gitee.com
https://user:pwd@github.com

ptmalloc & tcmalloc​

在tcmalloc之前，还有一个ptmalloc，tcmalloc号称要比它快。
一次malloc和free操作，ptmalloc需要300ns，而tcmalloc只需要50ns。

tcmalloc将内存请求分为了两类：大对象请求和小对象请求。（大于32K的属于大对象）
它会为每个线程分配本地缓存，小对象请求可以直接从本地缓存获取，所以对于小对象的分配基本不存在锁竞争。

性能指标​

redis 作为高性能缓存服务，其性能指标是一个很重要的观测点。

内存指标​

redis 作为常见内存数据库，其内存指标也是一个很重要的观测点。

第一轮分析定位​

redis: connection pool timeout 是连接池超时，这种问题发生的场景一般是由于某个操作过于耗时，导致 redis 阻塞，从而导致其他查询报错。
所以第一步就是去线上查看慢日志 SLOWLOG，我们慢日志阈值为 1s，而连接超时配置为 4s。如果是因为慢操作导致超时，那应该是会被记录下来的。
但实际没有，因为我们业务场景只有简单的 get 和 小量的 mget。所以要从其他角度进行分析。

这个服务当时的并发压力在几千QPS左右，redis 不应该存在抗不住的问题。翻了下报错时间点的上下文日志，确实发现了一些问题：

箭头时间段，即在42分到44分之间，刚好就是 redis 查询报错的时间段。
说明就是42分的同步行为，影响到了 redis 的查询性能。

通过排查发现，这个服务有点特殊，是以 daemon 的形式部署在 k8s 上，且单 pod 独占节点。pod 内又包含 redis 和 postgres 等多个服务。
进一步排查了解到，因为资源有限，所以没加资源配额，避免服务部署不上去。因此，存在某时刻的资源倾斜导致其余服务不可用。

这类问题其实在物理机上经常发生，没想到这次换了种形式发生在了 k8s 上面。
解决方法也比较简单：
1、增加机器资源，建议 4c 升级 8c。
2、增加资源配额。

由于预算不足，暂时只能采用第二种方案，即加上资源配额。
但是资源实在有限，无法具体精确到每一个容器，故暂时仅对 redis 加上资源配额：

resources:
  requests:
    cpu: '1'

第二轮分析定位​

通过几天的观察，发现并没有实际的效果。redis 仍然出现了查询超时的场景。而且还是在更新高峰期时间段发生的。
但是我们已经给 redis 单独申请了 1c 的计算资源，不应该出现类似问题。

我们仔细排查了容器监控，发现各个容器都没有出现明显的高负载场景。情况有点诡异，从内部看不出什么情况，所以我们看了下当前节点的监控：

果然，cpu 利用率没有满，但是 Load 负载已经满了。甚至超了很多。
基本可以石锤是 pg 在高更新场景影响 redis 调度。暂时只能增加 limits 资源限制了。

第三轮分析定位​

突然想起官网的一句话：对于 redis 来说，cpu 往往不会是性能瓶颈，内存大小和网络带宽才可能是 redis 的瓶颈。

之前的分析应该是被带偏了。对于高更新场景，数据库会占用大量的磁盘IO，这一块可能会造成影响？

在其他语言中有不同的解决方法，比如 python 就支持默认参数，可以很好的处理这个问题。
在 golang 中也有一种选项模式，可以比较友好的处理这类问题。

选项模式​

选项模式的主要流程是：初始化一个默认参数，然后提供可变参数，这些参数可以针对性的修改此默认参数，最终得到目标参数。

type MyFuncOption func(options *MyFuncOptions)

func WithOptionStr1(str1 string) MyFuncOption {
    return func(options *MyFuncOptions) {
        options.optionStr1 = str1
    }
}

func WithOptionInt1(int1 int) MyFuncOption {
    return func(options *MyFuncOptions) {
        options.optionInt1 = int1
    }
}

func WithOptionStr2AndInt2(str2 string, int2 int) MyFuncOption {
    return func(options *MyFuncOptions) {
        options.optionStr2 = str2
        options.optionInt2 = int2
    }
}

func NewIns(options ...MyFuncOption) {
    defaultOptions := Options{}
    for _, f := range options {
        f(&defaultOptions)
    }
}

常见方法​

这类参数的选择起始比较自由，一般选项模式适用于参数量较多的场景，当参数较少时，不妨直接匹配选项

type Opt int

const (
    OptEnv Opt = 1 << iota
    OptDefault
    OptSilent // ignore err and iterate over all fields.
)

func NewIns(opts ...Opt) {
    var opt Opt = 0
    for _, o := range opts {
        opt = opt | o
    }
}

CSP（communicating sequential processes），是 golang 推崇的一种并发模式，其中有一句比较经典的话是：
不要以共享内存的方式来通信，相反，应该以通信的方式来共享内存。

在常见的多线程共享内存的模式中，当涉及到多线程操作共享数据时，一般需要通过加锁来保证数据和线程安全。
go 则引入了 chan 信道，可以用于多 goroutine 之间的通信。

GMP​

golang 执行多任务时，会创建多个线程，然后有调度器会将任务单元分配给线程执行，这种方式是一种典型的生产者消费者模式。

• G：goroutine，此处指协程。它相当于操作系统的进程控制块，包含：寄存器、线程上下文、函数执行指令等。
• M：machine，此处指实际的内核线程，用于执行 G。
• P：processor，此处指调度器，是 M 所需要的上下文环境，内部维护有一个本地队列。当 P 中有任务时，会创建或者唤醒 M 去处理任务。
• 本地队列：P 维护一个本地队列来存放 G，新创建的 G 会优先存放在 P 的本地队列，当本地队列满后，会放入到全局队列。
• 全局队列：M 执行时会先从本地队列获取 G，本地没有则去全局队列获取，如果全局队列也没有，则尝试去其他 P 的本地队列去偷取一些任务。
• M0：程序启动后第一个线程，负责启动起一个 G0 并执行初始化操作，包含初始化本地队列、全局队列等，启动 G0 之后 M0 就和普通 M 一样了。
• G0：每创建一个 M，都会创建一个 G0，这里的 G0 仅用于负责调度其他的 G。比如当 M 从 G1 切换至 G2，首先应该切到 G0，然后由 G0 干掉 G1，再把 G2 加载进来。

1、go 创建 G。
2、将 G 保存在本地队列，若本地队列满了，则保存到全局队列。
3、P 与 M 绑定，M 执行本地队列任务 G，若本地队列任务执行完成，则从全局队列获取任务，若全局队列也没有，则从其他 P 的本地队列中偷取一半任务来执行。
4、若 M 执行期间发生系统阻塞，此时 M 与 P 解绑，P 将申请创建新的 M 或者唤醒休眠的 M 重新绑定与执行。
5、当 M 恢复时，会尝试获取一个空闲的 P，如果没有 P 空闲，M 则进入休眠，G 会放入到全局队列。

go 初始化流程​

1、创建 M0
2、创建 G0
3、绑定 M0 与 G0
4、执行初始化操作
5、M0 投入使用，尝试与空闲 P 绑定

1.14 基于信号的抢占式调度​

当有大量 G 任务，为了让每个任务都有时间运行，runtime.main 会创建一个额外的 M 来运行 sysmon 函数，来实现监控与抢占。

func main() {
    runtime.GOMAXPROCS(1)
    go func() {
        fmt.Println("pass")
    }
    for {
    }
}

在 1.14 之前上面这段代码将不会输出任何结果，因为 main 会占用全部的计算资源。

有台物理机部署了 postgres 数据库，现在要把这个数据库迁移至 k8s。

第一次迁移，我们首先关闭了数据库，把文件直接挪到了 k8s 上，配上对应的 pg 镜像。
测试时，服务正常运行了，但是没有办法提供数据服务，甚至连数据库也连接不上。

zh_CN.UTF-8:initdb: error: locale “zh_CN.UTF-8“ requires unsupported encoding "en_CN.UTF-8"

我们没有深究，就感觉可能是数据库文件不兼容，不能直接暴力迁移文件。

第二次迁移，我们使用 pg_dumps 和 pg_restore 工具进行迁移。数据量有点大，等待迁移完成后，我们再次进行了测试。

zh_CN.UTF-8:initdb: error: locale “zh_CN.UTF-8“ requires unsupported encoding "en_CN.UTF-8"

仍然报字符集不兼容的问题。这着实有点让人费解。

咨询了运维大佬后，给的建议是安装下依赖，即：

yum install -y langpacks-zh_CN

这种方式需要在编译镜像时安装，影响比较小。

后面又查询到一种方式，在编译镜像时，使用 localedef 指定编码并设置环境变量为 LANG 为 zh_CN.utf8：

FROM postgres
RUN localedef -i zh_CN -c -f UTF-8 -A /usr/share/locale/locale.alias zh_CN.UTF-8
ENV LANG zh_CN.utf8

但是用了这种方法，日志似乎会变成中文😂😂😂

new​

// The new built-in function allocates memory. The first argument is a type,
// not a value, and the value returned is a pointer to a newly
// allocated zero value of that type.
func new(Type) *Type

在源码注释中我们可以看出 new 的功能：输入一个类型，不能是值，返回一个指向该类型零值的指针。

make​

// The make built-in function allocates and initializes an object of type
// slice, map, or chan (only). Like new, the first argument is a type, not a
// value. Unlike new, make's return type is the same as the type of its
// argument, not a pointer to it. The specification of the result depends on
// the type:
//  Slice: The size specifies the length. The capacity of the slice is
//  equal to its length. A second integer argument may be provided to
//  specify a different capacity; it must be no smaller than the
//  length. For example, make([]int, 0, 10) allocates an underlying array
//  of size 10 and returns a slice of length 0 and capacity 10 that is
//  backed by this underlying array.
//  Map: An empty map is allocated with enough space to hold the
//  specified number of elements. The size may be omitted, in which case
//  a small starting size is allocated.
//  Channel: The channel's buffer is initialized with the specified
//  buffer capacity. If zero, or the size is omitted, the channel is
//  unbuffered.
func make(t Type, size ...IntegerType) Type

在源码注释中我们可以看出 make 的功能：输入一个类型（必须是slice、map、chan），返回一个按指定条件初始化后的类型对象。

主要区别​

其实感觉没什么太大关系，都是内置的初始化函数，new 返回指针，make 只能用于特定类型。

-bench regexp​

执行基准测试，后面可以接正则表达式，如果需要执行全部的基准测试，可以使用 -bench=.

func Benchmark(b *testing.B) {
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
    }
}