OceanBase 功能解析之 Binlog Service

前言

MySQL，是在全球广泛应用的开源关系型数据库，除了其稳定性、可靠性和易用性，他早期推出的二进制日志功能，即binlog，也是MySQL广受欢迎的原因。

MySQL binlog，即二进制日志，是 MySQL 中用于记录数据库更改的日志文件。自 MySQL 数据库较早地引入了 binlog，这项功能就为它赢得了开发者和企业用户的青睐。MySQL 的二进制日志以高效、易读的二进制格式存储了所有影响数据库状态变化的 SQL 语句，从而为数据库提供了数据集成、复制等多种强大的能力。多年积累下来，MySQL 生态也基于 binlog 逻辑复制能力做出了一些比较成熟的增量解析系统并被广泛使用在数据集成中，比如 Canal、Debezium 等。

OceanBase 数据库早期就推出了 MySQL 兼容模式，使得一些希望替换 MySQL 的用户能够以较小的成本切换到 OceanBase 数据库。考虑到 MySQL 生态系统中一些成熟的 binlog 增量解析系统已经被广泛使用，当用户从 MySQL 转向 OceanBase 数据库时，可以直接利用现有的 binlog 增量解析系统，这也加快了 OceanBase Binlog Service 的诞生。

OceanBase Binlog Service 提供了类似于 MySQL 的 binlog 功能，可以记录数据库的变更日志。这对于实现数据迁移、同步以及数据一致性检查至关重要。该服务使得 MySQL 用户能够利用熟悉的 binlog 方案来监控、备份，并通过数据复制保持 OceanBase 数据库实时更新。

MySQL binlog 逻辑复制架构

1719456500

MySQL 复制机制基于 binlog 来实现，具体来说，binlog 主要在 SQL 引擎层记录数据的逻辑更改，而非在事务引擎层通过 redo log 进行物理更改的记录。这样的设计思路背后有着明确的目的。

MySQL 旨在支持多种存储引擎，如 InnoDB、MyISAM 等，每种存储引擎都有其独特的特征和优势。通过在 SQL 引擎层以 binlog 形式记录数据变更，MySQL 实现了一种灵活的复制机制，它不仅支持多种存储引擎间的无缝数据复制，还允许不同存储引擎之间进行异构同步复制。换句话说，这种机制为数据的一致性和兼容性带来了极大的便利。

这种设计展现了其在保证数据复制灵活性和系统兼容性方面的优势。通过逻辑而非物理记录数据变更，MySQL 成功地整合了多样化的存储引擎特性，并在全球范围内被广泛应用于需要高度兼容性和灵活性的复制架构中。

另外，在大数据领域，MySQL binlog 起着至关重要的作用，因为它提供一种机制来实现数据变更捕获（Change Data Capture，CDC），这是数据处理和分析的关键组成部分。

以下是 binlog 在大数据环境中的重要作用。

  1. 数据同步：binlog 允许持续地监控和记录 MySQL 数据库中的所有数据更改，包括插入、更新和删除操作。这些实时数据流可以被大数据工具捕获并同步到数据湖、数据仓库或其它任何大数据处理系统中，以进行进一步分析。 
  2. 实时分析：通过从 binlog 中捕获实时变化，企业可以将这些数据推送到流处理引擎（如 Apache Kafka、Apache Flink 或 Apache Storm）进行实时分析，从而实现即时的业务洞察和决策。 
  3. 跨平台数据整合：在多种数据库和存储系统中维护数据的一致性是大数据环境中的一个挑战。binlog 通过CDC 工具，如 Canal 或 Debezium，将数据无缝地同步到 Hadoop、Apache Hive、Elasticsearch 或任何其他目标平台，解决了数据整合的需求。 
  4. 系统解耦：binlog 允许基于事件的数据架构设计，这意味着数据生产者（数据库）和消费者（如大数据处理服务）可以松耦合、独立扩展，既增加了系统的灵活性，也提高了系统的稳定性。 
  5. 历史数据审计和回溯：binlog 为审计过去的数据变更提供了机会，分析历史数据走势和模式对于预测分析以及审计跟踪都是必要的。 

MySQL binlog 特点

MySQL 在处理事务型存储引擎和非事务型存储引擎时 binlog 的行为实际是稍有些差异的，本文仅会讨论事务型存储引擎 InnoDB 的相关 binlog 行为。一是因为 MySQL 虽然支持多种存储引擎，但目前默认的存储引擎以及普遍被用户使用的都是 InnoDB 存储引擎；二是因为 OceanBase 数据库本身支持事务，在设计 OceanBase Binlog Service 兼容 MySQL binlog 时，也需要按 InnoDB 存储引擎的 binlog 行为来进行处理。

MySQL binlog 文件支持两种格式：Statement-Based Replication（SBR）和 Row-Based Replication（RBR）。SBR 格式记录了 SQL 语句本身及其相关上下文信息，其优势在于较低的磁盘空间需求。然而在特定情况下，SBR 可能导致复制的同步问题。相对地，RBR 格式记录了数据变更前后的具体值，无需附加会话上下文信息，避免了 SBR 所面临的问题，并且确保了复制的一致性。

针对如 Canal/Debezium 这类的 binlog 解析系统，仅支持 RBR 格式，考虑到 Canal/Debezium 等系统的兼容性及其在实现数据同步与集成方面的广泛应用，本文将专注于 RBR 格式下的 binlog，目的是实现对 Canal/Debezium 等增量解析系统的全面支持。 

MySQL 的 binlog 由两组文件组成：

  • 一组是 binlog 文件本身，由 1 至多个编号连续的 binlog 文件组成，如上图中的 mysql-bin.000001、mysql-bin.000002、mysql-bin.000003 等。
  • 另一组是 binlog 的索引文件，即上图中的 mysql-bin.index 。该文件仅仅是一个文本文件，记录了当前所有的 binlog 文件名，SHOW BINARY LOGS命令即是通过读取该索引文件而实现。

MySQL 的 binlog 文件是由不同类型的 event 组成，在 5.7 版本中约支持 40 种 event 类型。从 CDC 增量解析的角度来看，主要需关注 Format_desc、Previous_gtids、Gtid, Rotate、Query、Xid、Table_map、Write_rows、Update_rows、Delete_rows 等 event 类型，从事务的角度来说，一个事务的所有相关 binlog events 在 binlog 文件中都是连续的，即不同事务间的 events 不会有交叉，此外一个事务的所有 binlog events 也不会跨 binlog 文件。以下是通过SHOW BINLOG EVENTS列出的 binlog events 示例：

mysql> SHOW BINLOG EVENTS IN 'mysql-bin.000009';
+------------------+------+----------------+------------+-------------+--------------------------------------------------------------------+
| Log_name         | Pos  | Event_type     | Server_id  | End_log_pos | Info                                                               |
+------------------+------+----------------+------------+-------------+--------------------------------------------------------------------+
| mysql-bin.000009 |    4 | Format_desc    | 1147473732 |         123 | Server ver: 5.7.35-log, Binlog ver: 4                              |
| mysql-bin.000009 |  123 | Previous_gtids | 1147473732 |         194 | ebd2d3b0-6399-11ec-86ea-0242ac110004:1-38                          |
| mysql-bin.000009 |  194 | Gtid           | 1147473732 |         259 | SET @@SESSION.GTID_NEXT= 'ebd2d3b0-6399-11ec-86ea-0242ac110004:39' |
| mysql-bin.000009 |  259 | Query          | 1147473732 |         353 | create database test                                               |
| mysql-bin.000009 |  353 | Gtid           | 1147473732 |         418 | SET @@SESSION.GTID_NEXT= 'ebd2d3b0-6399-11ec-86ea-0242ac110004:40' |
| mysql-bin.000009 |  418 | Query          | 1147473732 |         543 | use `test`; CREATE TABLE t1(id int primary key, v varchar(30))    |
| mysql-bin.000009 |  543 | Gtid           | 1147473732 |         608 | SET @@SESSION.GTID_NEXT= 'ebd2d3b0-6399-11ec-86ea-0242ac110004:41' |
| mysql-bin.000009 |  608 | Query          | 1147473732 |         733 | use `test`; CREATE TABLE t2(id int primary key, v varchar(30))    |
| mysql-bin.000009 |  733 | Gtid           | 1147473732 |         798 | SET @@SESSION.GTID_NEXT= 'ebd2d3b0-6399-11ec-86ea-0242ac110004:42' |
| mysql-bin.000009 |  798 | Query          | 1147473732 |         870 | BEGIN                                                              |
| mysql-bin.000009 |  870 | Table_map      | 1147473732 |         918 | table_id: 114 (test.t1)                                            |
| mysql-bin.000009 |  918 | Write_rows     | 1147473732 |         963 | table_id: 114 flags: STMT_END_F                                    |
| mysql-bin.000009 |  963 | Table_map      | 1147473732 |        1011 | table_id: 115 (test.t2)                                            |
| mysql-bin.000009 | 1011 | Write_rows     | 1147473732 |        1056 | table_id: 115 flags: STMT_END_F                                    |
| mysql-bin.000009 | 1056 | Xid            | 1147473732 |        1087 | COMMIT /* xid=57 */                                                |
| mysql-bin.000009 | 1087 | Gtid           | 1147473732 |        1152 | SET @@SESSION.GTID_NEXT= 'ebd2d3b0-6399-11ec-86ea-0242ac110004:43' |
| mysql-bin.000009 | 1152 | Query          | 1147473732 |        1224 | BEGIN                                                              |
| mysql-bin.000009 | 1224 | Table_map      | 1147473732 |        1272 | table_id: 114 (test.t1)                                            |
| mysql-bin.000009 | 1272 | Update_rows    | 1147473732 |        1328 | table_id: 114 flags: STMT_END_F                                    |
| mysql-bin.000009 | 1328 | Table_map      | 1147473732 |        1376 | table_id: 115 (test.t2)                                            |
| mysql-bin.000009 | 1376 | Update_rows    | 1147473732 |        1432 | table_id: 115 flags: STMT_END_F                                    |
| mysql-bin.000009 | 1432 | Xid            | 1147473732 |        1463 | COMMIT /* xid=61 */                                                |
| mysql-bin.000009 | 1463 | Gtid           | 1147473732 |        1528 | SET @@SESSION.GTID_NEXT= 'ebd2d3b0-6399-11ec-86ea-0242ac110004:44' |
| mysql-bin.000009 | 1528 | Query          | 1147473732 |        1600 | BEGIN                                                              |
| mysql-bin.000009 | 1600 | Table_map      | 1147473732 |        1648 | table_id: 114 (test.t1)                                            |
| mysql-bin.000009 | 1648 | Delete_rows    | 1147473732 |        1693 | table_id: 114 flags: STMT_END_F                                    |
| mysql-bin.000009 | 1693 | Xid            | 1147473732 |        1724 | COMMIT /* xid=67 */                                                |
| mysql-bin.000009 | 1724 | Rotate         | 1147473732 |        1771 | mysql-bin.000010;pos=4                                             |
+------------------+------+----------------+------------+-------------+--------------------------------------------------------------------+
28 rows in set (0.00 sec)

Canal/Debezium 的解析原理

Canal/Debezium 都是数据变更捕获（Change Data Capture，简称 CDC）工具，它们的核心作用是监控数据库中的变更并将这些变更以某种方式传播出去。尽管它们为不同的数据库生态系统提供服务（Canal 主要针对 MySQL，而 Debezium 支持多种数据库），但是它们都利用了相似的原理来解析和传递数据变更。

Canal/Debezium 模仿了 MySQL slave 的通信过程，对 MySQL 的 binlog 二进制格式进行解析，提取出数据的增加、删除、更新这些变更，并转换为统一的格式。

  1. 建立连接：Canal/Debezium 连接到 MySQL 主服务器，模拟从服务器的行为。 
  2. 请求 binlog：Canal/Debezium 请求 MySQL 发送 binlog，并指定从特定的位置开始。 
  3. 解析 binlog：Canal/Debezium 从连接中读取 binlog 流并将其解析为可识别的数据变更事件。 
  4. 转换数据：解析后的事件被转换为通用的消息格式，供后续的系统消费。 
  5. 传播变更：变更数据可以被发送到各种中间件或直接被其他系统使用，如消息队列（Kafka 等），监控系统，缓存或搜索引擎。 

Canal/Debezium 会将自己伪装成一个 slave，设置自己的server_id和server_uuid，再通过COM_BINLOG_DUMP或COM_BINLOG_DUMP_GTID协议来定位和拉取 binlog events。另外为了支持对 binlog 的解析，还要求binlog_format和binlog_row_image两个系统变量必须为 ROW 和 FULL。

Canal/Debezium 做 binlog 解析时，主要关注事务本身的 DML 操作及 DDL 操作，所以对 binlog event 类型处理上主要以以下几种 binlog event 类型为主。此外还需要对一些控制类型的 binlog event 类型进行解析处理，比如 Format_desc、Rotate、Previous_gtids、Gtid 等。

event 类型说明
Query即可以表示一个事务的 BEGIN，也可以表示 DDL 操作。
Xid表示一个事务的 COMMIT。
Table_map在一个事务内，一条 DML SQL 会对一到多张表的数据变更，在进行 binlog 记录时，会把涉及到的每张表都产生一个 Table_map event 并将其写到 binlog 文件用于记录内部 table id 和对应的表名。Table_map events 会先于 DML 操作产生的所有 Write_rows/Update_rows/Delete_rows events 出现在该事务的 binlog evens 中。
Write_rowsINSERT 产生的 event 类型：一条 event 可以包含多行插入的记录，但都属于同一 table id。若一条 INSERT 插入了多行，会产生多条连续的该 event 类型。
Update_rowsUPDATE 产生的 event 类型：一条 event 可以包含多行记录的更改，但都属于同一 table id。若一条 UPDATE 更改了多行，会产生多条连续的该 event 类型。
Delete_rowsDELETE 产生的 event 类型：一条 event 可以包含多行记录的删除，但都属于同一 table id。若一条 DELETE 删除了多行，会产生多条连续的该 event 类型。

虽然 Write_rows/Update_rows/Delete_rows 中记录的变更的前、后的值，但其中记录的元信息部分并不包含对应表中的列名，所以 Canal/Debezium 在做 binlog 解析时，还需要在启动初始化时先查询 MySQL 的元信息获取到所有相关表的 schema 定义。另外，MySQL 提供 SQL 服务和 binlog 服务都是相同的地址和端口（默认为 3306 端口）。

OceanBase Binlog Service 兼容 MySQL binlog 技术架构

OceanBase Binlog Service 为兼容 MySQL binlog 而诞生，支持现有的 MySQL binlog 生态工具来同步 OceanBase，现有的 MySQL binlog 生态工具可以平滑切换至 OceanBase 数据库。

技术要点

OceanBase Binlog Service 整套主要包含三部分：OceanBase 数据库、OBProxy 和 OBLogProxy，其中 binlog 服务主要主体为 OBLogProxy。

整套系统的技术要点包括：

  • 按租户级别创建 binlog 服务（OceanBase 数据库为多租户设计，其中每一个“租户”对应一个 MySQL 实例）。
  • OceanBase 数据库 clog 经 obcdc 获取后，需要转换为 ROW 格式、 FULL image 的 binlog events， 然后按 binlog 文件的组织方式存储到 binlog 文件中，支持被多个下游 MySQL binlog 解析系统所共用、支持回拉等，同时支持被 MySQL binlog 工具分析等。
  • 支持 MySQL 通信协议。
    • 用于 binlog dump 的COM_BINLOG_DUMP或COM_BINLOG_DUMP_GTID本身也是 MySQL 通信协议的一部分，OBProxy 和 OBLogProxy 需识别和处理这两个协议指令。
    • Canal/Debezium 做 binlog 解析时。需查询 MySQL 的元信息获取相关表的 schema 定义，也需要检查 binlog 相关系统变量确认 binlog 格式是否符合预期。此外，Debezium 在进行 binlog dump 前，还支持全量基准数据的快照导出。这三类场景会涉及SELECT和SHOW两类 SQL，这些 SQL 将通过 OBProxy 进行转发。
    • MySQL 的 SQL 服务和 binlog 服务都是通过相同的地址进行的（默认为 3306 端口），而 OceanBase 数据库的 SQL 服务是通过 OBProxy 地址进行访问（默认为 2883 端口），为了使 OceanBase 数据库的 binlog 服务和 SQL 服务统一完全兼容 MySQL 的能力，需要 OBProxy 支持 binlog dump 协议并将请求转发给对应的 OBLogProxy 实例。

术语

此处列出相关名词含义，以便更好地理解本文。

  • OceanBase 数据库：OceanBase 数据库集群。
  • OBProxy：OceanBase 的访问代理，SQL 和 binlog 协议及相关命令通过 OBProxy 作为统一入口进行访问。
  • OBLogProxy：OceanBase binlog 服务的主体。
  • MySQL binlog 生态工具：泛指 MySQL binlog 增量解析系统，如常见的 Canal/Debezium 等。
  • BC：OBLogProxy 中 binlog converter 子模块，拉取并解析 clog，再按照 binlog 格式转换为 binlog 文件。
  • BD：OBLogProxy 中 binlog dumper 子模块，对下游（MySQL binlog 生态系统）的订阅请求提供 binlog 订阅服务。
  • BCM：OBLogProxy 中 BC 的管理模块。
  • BDM：OBLogProxy 中 BD 的管理模块。

系统架构

1719456552

上图所示为 OceanBase Binlog Service 兼容 MySQL binlog 系统的整体技术架构。整体的交互流程如下：

  • 需要为 OceanBase 数据库租户创建 binlog 服务：相比于 MySQL 的 binlog 服务，这一步骤是 OceanBase Binlog Service 额外需要的操作，由用户在需要时进行创建。
    • 使用 MySQL Client 连接 OBLogProxy 后，发起CREATE BINLOGSQL 请求。
    • OBLogProxy 收到 CREATE BINLOG请求后，通过 BCM 创建 BC 子模块。
  • BC 子模块初始化完成后，使用 MySQL Client 通过 OBProxy 执行 binlog 相关 SQL 可以查看 binlog 的状态，这类 SQL 包括如下几种。OBProxy 需识别这些 SQL 并转发给对应的 OBLogProxy 实例，由 BCM 返回相关结果集。
    • SHOW MASTER STATUS
    • SHOW BINARY LOGS
    • SHOW BINLOG EVENTS
  • 使用 MySQL Client 通过 OBProxy 执行非 binlog 相关 SQL 查询时，由 OBProxy 直接查询对应 OceanBase 数据库实现。
  • MySQL binlog 生态工具（如 Canal/Debezium 等）向 OBproxy 发起COM_BINLOG_DUMP或COM_BINLOG_DUMP_GTID命令时，OBProxy 识别到这两个命令后，需将请求转发到对应 OBLogProxy 实例。OBLogProxy 收到COM_BINLOG_DUMP或COM_BINLOG_DUMP_GTID请求后，然后通过 BDM 创建一个 BD 子模块提供 binlog dump 服务。

尾声

OceanBase Binlog Service 的出现，是对现代数据库技术和 MySQL 生态兼容性的一次显著进步。随着数据库技术发展，用户需求的扩展，以及对于实时数据处理和分析的迫切需求，OceanBase Binlog Service 的推出不仅拓展了 MySQL 的功能，而且创造了一个适应分布式、多租户数据库环境的灵活解决方案。通过在现有的 MySQL binlog 生态中无缝地整合 OceanBase 数据库，用户能够在享受 OceanBase 数据库高性能、高扩展性、高可用性等优点的同时，还能够无缝地维持与现有基于 MySQL binlog 的应用和工具之间的兼容性，保持以往 MySQL binlog 的使用习惯。

技术角度来看，OceanBase Binlog Service 简化了数据变更捕捉和数据复制流程，使得数据迁移、同步、集成、审核和灾难恢复等流程更加平滑、高效。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/412511.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

爆品是测出来的，不是选出来的

爆品是测出来的，不是选出来的

我在亚马逊摸爬滚打了五年，深深感受到了"七分选品，三分运营"的重要性。不管你的产品图片、描述多么精美，如果不去精选和测试，很难保证能出单。我见过很多跨境新手在选品上卡了几个月，纠结于卖什么。但实际上…
阅读更多...
光敏电阻传感器详解（STM32）

光敏电阻传感器详解（STM32）

目录 一、介绍 二、传感器原理 1.光敏电阻传感器介绍 2.原理图 三、程序设计 main.c文件 ldr.h文件 ldr.c文件 四、实验效果 五、资料获取 项目分享 一、介绍 光敏电阻器是利用半导体的光电导效应制成的一种电阻值随入射光的强弱而改变的电阻器，又称为光…
阅读更多...
上新！Matlab实现基于QRGRU-Attention分位数回归门控循环单元注意力机制的时间序列区间预测模型

上新！Matlab实现基于QRGRU-Attention分位数回归门控循环单元注意力机制的时间序列区间预测模型

目录 效果一览基本介绍程序设计参考资料 效果一览 基本介绍 1.Matlab实现基于QRGRU-Attention分位数回归门控循环单元注意力机制的时间序列区间预测模型； 2.多图输出、多指标输出(MAE、RMSE、MSE、R2)，多输入单输出，含不同置信区间图、概率…
阅读更多...
[000-01-015].第03节：SpringBoot中数据源的自动配置

[000-01-015].第03节：SpringBoot中数据源的自动配置

我的后端学习大纲 SpringBoot学习大纲 1.数据访问流程： 2.搭建数据库开发场景： 2.1.导入JDBC场景： 2.2.分析自动导入的内容： 2.3.分析为何没有导入数据库驱动： 1.因为人家也不知道我要用啥数据库，所以在自…
阅读更多...
衡石科技BI的API如何授权文档解析

衡石科技BI的API如何授权文档解析

授权说明​ 授权模式​ 使用凭证式（client credentials）授权模式。 授权模式流程说明​ 第一步，A 应用在命令行向 B 发出请求。 第二步，B 网站验证通过以后，直接返回令牌。 授权模式结构说明​ 接口说明​ 获取a…
阅读更多...
如何禁止电脑访问网站

如何禁止电脑访问网站

一、修改Hosts文件 找到Hosts文件：在Windows系统中，Hosts文件通常位于C:\Windows\System32\drivers\etc\目录下。 编辑Hosts文件：以管理员身份打开记事本或任意文本编辑器，然后找到并打开Hosts文件。 添加禁止访问的域名&#…
阅读更多...
SSRF漏洞（二）

SSRF漏洞（二）

本文仅作为学习参考使用，本文作者对任何使用本文进行渗透攻击破坏不负任何责任。 前言： 本文主要讲解依靠phpstudy搭建pikachu靶场。 phpstudy下载使用以及搭建本地SQL labs靶场 SSRF漏洞（一） 靶场搭建。 靶场链接&#xff1…
阅读更多...
Linux：NAT等相关问题

Linux：NAT等相关问题

目录 1：NAT背景 2：NAT IP转换过程 3：NATP 4：正向代理 5：反向代理 6：NAT和代理服务器 应用场景 实现方法 1：NAT背景 IPv4地址耗尽：随着互联网的迅速发展，连接到…
阅读更多...
LMDeploy 量化部署实践

LMDeploy 量化部署实践

一、环境配置见：https://github.com/InternLM/Tutorial/blob/camp3/docs/L2/LMDeploy/readme.md 验证LMDeploy启动InternLM2_5-7b-chat conda activate lmdeploy lmdeploy chat /root/models/internlm2_5-7b-chat二、量化显存计算 参数计算： LMDeploy …
阅读更多...
盘点15款工程软件，为制造业选型提供参考！

盘点15款工程软件，为制造业选型提供参考！

本文将盘点15款工程软件，供企业选型参考。 工程软件就如同工程领域的得力助手，能让工程建设的各个环节都变得更加高效、精准。 对于工程企业来说，如果没有合适的工程软件，就像工匠没有趁手的工具，难以打造出精良的作品…
阅读更多...
linux查看系统安装时间命令,找出Linux操作系统（OS）安装日期和时间

linux查看系统安装时间命令,找出Linux操作系统（OS）安装日期和时间

你可能想知道你的计算机上何时安装了Linux操作系统，即OS的安装日期和时间，使用tune2fs、dumpe2fs、ls、basesystem、setup、setuptool命令能出来结果。请注意，如果你从模板安装了操作系统，那么它将显示模板生成日期，而不是实际操作系统安装日期。 方法1：如何使用tune2fs…
阅读更多...
LayerNorm介绍

LayerNorm介绍

简介 Layer Normalization (LayerNorm) 是一种归一化技术，常用于深度学习模型中，特别是在 Transformer 模型中。 Layer normalization 是在特征维度上进行标准化的，而不是在数据批次维度上。 目的 收敛模型数据数值差异，缓解内…
阅读更多...
GD32F4xx---RTC初始化设置及闹钟方式实现秒中断讲解

GD32F4xx---RTC初始化设置及闹钟方式实现秒中断讲解

GD32F4xx—RTC初始化设置及闹钟方式实现秒中断讲解 1、下载链接：源码工程 一、概述 GD32F4x的RTC例程网上资源较少，详细阅读用户手册后做出如下配置。RTC模块提供了一个包含日期（年/月/日）和时间（时/分/秒/亚秒）的日历功能。除亚秒用二进制码显示外，时间和日期都以BC…
阅读更多...
『功能项目』新输入系统【06】

『功能项目』新输入系统【06】

我们打开上一篇04禁止射线穿透行为项目， 本章要做的事情是在Unity编辑器中添加 新输入系统 实现主角在场景中鼠标右键可以使主角 转向。 本次项目需要让Unity引擎重新启动所以先保存当前项目 再次打开项目后， 修改为Both 点击Apply前注意要先保存项目&a…
阅读更多...
JVM上篇：内存与垃圾回收篇-07-方法区

JVM上篇：内存与垃圾回收篇-07-方法区

笔记来源：尚硅谷 JVM 全套教程，百万播放，全网巅峰（宋红康详解 java 虚拟机） 文章目录 7. 方法区7.1. 栈、堆、方法区的交互关系7.2. 方法区的理解7.2.1. 方法区在哪里？7.2.2. 方法区的基本理解7.2.3. HotSp…
阅读更多...
【Linux】命令简介------迅速掌握Linux命令

【Linux】命令简介------迅速掌握Linux命令

目录 Linux 命令 🍔 ls命令 🍔 cd 和 pwd命令 🍔 相对路径和绝对路径 🍔 文件/文件夹的创建以及文件内容的浏览 🍔 文件的复制,移动和删除 🍔 文件的查找 🍔 grep 和管道 &#x1f354…
阅读更多...
@antv/g6 业务场景：流程图

@antv/g6 业务场景：流程图

1、流程图是流经一个系统的信息流、观点流或部件流的图形代表。在企业中，流程图主要用来说明某一过程。这种过程既可以是生产线上的工艺流程，也可以是完成一项任务必需的管理过程。业务场景流程图如下： 2、绘制流程图的 Tips 流程图一般是用…
阅读更多...
奇安信渗透测试岗位三面经验分享

奇安信渗透测试岗位三面经验分享

吉祥知识星球http://mp.weixin.qq.com/s?__bizMzkwNjY1Mzc0Nw&mid2247485367&idx1&sn837891059c360ad60db7e9ac980a3321&chksmc0e47eebf793f7fdb8fcd7eed8ce29160cf79ba303b59858ba3a6660c6dac536774afb2a6330#rd 《网安面试指南》http://mp.weixin.qq.com/s?…
阅读更多...
Python深浅拷贝

Python深浅拷贝

0、前置知识 数据类型：可变类型、不可变类型 不可变类型：一旦创建就不可修改的对象，包括字符串、元组、数值类型（整型、浮点型） 该对象所指向的内存中的值不能被改变。 当改变某个变量时候，由于其所指的…
阅读更多...
【MySQL 12】事务管理 (带思维导图)

【MySQL 12】事务管理 (带思维导图)

文章目录 🌈 一、事务的基本概念⭐ 1. 事务是什么⭐ 2. 事务的特性 🌈 二、事务的版本支持🌈 三、事务的提交方式⭐ 1. 查看事务的提交方式⭐ 2. 设置事务的提交方式 🌈 四、事务的特性证明⭐ 1. 事务的常规操作⭐ 2. 证明事务的原…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023