Flink实时数仓同步：快照表实战详解

一、背景

在大数据领域，初始阶段业务数据通常被存储于关系型数据库，如MySQL。然而，为满足日常分析和报表等需求，大数据平台采用多种同步方式，以适应这些业务数据的不同存储需求。这些同步存储方式包括离线仓库和实时仓库等，选择取决于业务需求和数据特性。

一项常见需求是，业务使用人员需要大数据分析平台中查看历史某一天的表数据，示例如下：

  1. [Mysql] 业务数据 - 用户表全量数据：
idnamephonegendercreate_timeupdate_time
1jack111男2023-06-01 13:00:002023-06-01 13:00:00
2jason222男2023-06-01 13:00:002023-06-01 13:00:00
3tom333男2023-06-01 13:00:002023-06-01 13:00:00
  1. [Mysql] 2023-06-02 业务数据新增了一名用户，且更改了tom的手机号，此时表数据如下：
idnamephonegendercreate_timeupdate_time
1jack111男2023-06-01 13:00:002023-06-01 13:00:00
2jason222男2023-06-01 13:00:002023-06-01 13:00:00
3tom444男2023-06-01 13:00:002023-06-02 09:00:00
4tony555男2023-06-02 10:00:002023-06-02 10:00:00

加粗为更新/新增数据

  1. [大数据平台] 2023-06-03 日业务人员在大数据平台中查看2023-06-02日用户表的历史数据，期望数据如下：
idnamephonegendercreate_timeupdate_time
1jack111男2023-06-01 13:00:002023-06-01 13:00:00
2jason222男2023-06-01 13:00:002023-06-01 13:00:00
3tom333男2023-06-01 13:00:002023-06-01 13:00:00

看到这里，有些同学可能会疑惑为何不采用离线数仓中的快照表，而要选择使用 Flink 实时同步的方式。确实，从需求层面看，离线数仓的快照表似乎是一种合理的选择。然而，我们需要注意离线数仓通常采用凌晨 T+1 执行 SQL 的方式将业务数据筛选后同步至下游，这种操作适用于对业务数据精确度要求不高的场景。

对于对数据精确度要求较高的需求，采用 T+1 的同步方式可能会导致数据不一致的问题。详细的问题分析和解决方案可以参考我另一篇文章：深入数仓离线数据同步：问题分析与优化措施。

那么对于对数据精确度要求较高的场景，我们可以选择实时同步的方式来实现。这是因为实时同步通过读取 binlog 日志，能够获取业务数据的完整变更历史。与离线数仓中的 T+1 执行 SQL 不同，实时同步能够更及时地捕获和应用数据变更，确保数据的高一致性和精确度。

二、技术选型

在实时同步领域，要实现背景中的需求通常有两种常见的解决方式：

  1. 实时同步 + 拉链表：
    • 拉链表完整记录了整个 binlog 的数据流向，并通过 start_date 和 end_date 字段进行天粒度筛选。
    • 可以采用此方式，实现细节可以参考笔者另一篇文章：Flink实时数仓同步：拉链表实战详解。
  2. 实时同步 + 快照表：
    • 本文主要内容。
    • 快照表适用于对数据的历史状态感兴趣，通过实时同步捕获变更事件，并将精确数据写入快照表。

本文主要介绍第二种实现方式：实时同步 + 快照表。

三、技术架构

鉴于业务数据通常存储在关系型数据库中，这里选择采用Flink-CDC持续读取binlog日志进行实时同步。为了保证实时数据能够高效写入下游并支持用户OLAP查询分析，这里选择了企业中常见的MMP库Doris作为实时数仓的存储层。整体架构如下图所示：

在这里插入图片描述

基于上图的设计，引入了一张额外的流水表到 Doris 中。这个设计的目的是为了实现业务的解耦，建立一张专门存储业务数据表的历史变更记录的流水表。这种结构不仅有助于满足当前需求，而且在后续可能出现的其他需求中也更加灵活可扩展。

在实际实现中，可以通过一个 Flink 程序来构建这两张表：流水表和快照表。这种设计模式使得系统更为模块化，同时也方便了后期其他需求的使用。

因此建议读者先阅读笔者另一篇文章：Flink实时数仓同步：流水表实战详解；再回到本文。这样能够更好地理解整个系统设计的背景和实际应用。

四、数据流转过程

Flink实时同步程序负责处理捕获到的MySQL数据变更事件。在处理流程中，首先将全量数据存储到快照表，然后针对新增（INSERT）、修改（UPDATE）、删除（DELETE）等操作，将其同步至流水表。当符合以下任意一个条件便会触发合并任务：

  1. 当binlog数据中的日期为第二天。
  2. 凌晨过了5分钟 [自定义阈值]。

一旦触发合并任务，程序将执行JOIN操作，将流水表前一天数据与快照表中前两天的数据进行整合，最终得到前一天的全量数据，并将其写入至快照表的前一天分区中。这种设计模式既保证了数据的完整性和准确性，又有效地将全量数据存储于快照表中，数据流转过程如下图所示：
在这里插入图片描述

五、实时同步+快照表实现

5.1、快照表设计

  1. 快照表用于存储某个特定时间点的所有数据，通常以天为粒度，相当于对每天的业务数据进行一次全量快照，将当天的全部数据记录下来。举例来说，12号分区中的数据包含了从历史开始一直到11号的全部数据，而13号分区中的数据则包含了从历史一直到12号的全部数据，其余分区以此类推。
  2. 此处只介绍快照表的设计，关于流水表的建表语句请参考笔者另一篇文章：Flink实时数仓同步：流水表实战详解，此快照表采用了Unique数据模型，建表语句如下：
CREATE TABLE `example_user_snapshot`
(`id` largeint(40) NOT NULL COMMENT '用户id',`dt` date NULL COMMENT '流水日期',`name` varchar(50) NOT NULL COMMENT '用户昵称',`phone` largeint(40) NULL COMMENT '手机号',`gender` varchar(5) NULL COMMENT '用户性别',`create_time` datetime NULL COMMENT '用户注册时间',`update_time` datetime NULL COMMENT '用户更新时间'
) ENGINE=OLAP
UNIQUE KEY(`id`, `dt`)
COMMENT '用户流水表'
PARTITION BY RANGE(dt)()
DISTRIBUTED BY HASH(id) BUCKETS 8
PROPERTIES
("dynamic_partition.enable" = "true","dynamic_partition.time_unit" = "DAY","dynamic_partition.start" = "-90","dynamic_partition.end" = "3","dynamic_partition.prefix" = "p","dynamic_partition.buckets" = "8"
);

该表利用了Doris的动态分区功能，将分区粒度设置为天级，并采取了预先建立3天分区的策略，同时设定了90天的过期时间；更多信息可参考Doris动态分区介绍

5.2、实时同步逻辑

5.2.1、前提介绍

  1. 首先，由于实时流水表同步使用Flink-cdc读取关系型数据库，flink-cdc提供了四种模式： “initial”，“earliest-offset”，“latest-offset”，“specific-offset” 和 “timestamp”。本文使用的Flink-connector-mysq是2.3版本，这里简单介绍一下这四种模式：

    • initial （默认）：在第一次启动时对受监视的数据库表执行初始快照，并继续读取最新的 binlog。

    • earliest-offset：跳过快照阶段，从可读取的最早 binlog 位点开始读取

    • latest-offset：首次启动时，从不对受监视的数据库表执行快照， 连接器仅从 binlog 的结尾处开始读取，这意味着连接器只能读取在连接器启动之后的数据更改。

    • specific-offset：跳过快照阶段，从指定的 binlog 位点开始读取。位点可通过 binlog 文件名和位置指定，或者在 GTID 在集群上启用时通过 GTID 集合指定。

    • timestamp：跳过快照阶段，从指定的时间戳开始读取 binlog 事件。

  2. 这里采用initial模式作为实时同步方式，先全量后增量，此外由于实时流水表同步需要对 binlog 数据进行解析及判断更新操作类型，因此，Flink CDC SQL 方式的表建立不再满足我们的要求。为了更好地实现这一功能，我们需要采用 API 方式来构建解决方案，代码如下：

import org.apache.flink.api.common.eventtime.WatermarkStrategy;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import com.ververica.cdc.debezium.JsonDebeziumDeserializationSchema;
import com.ververica.cdc.connectors.mysql.source.MySqlSource;public class MySqlSourceExample {public static void main(String[] args) throws Exception {MySqlSource<String> mySqlSource = MySqlSource.<String>builder().hostname("yourHostname").port(yourPort).databaseList("yourDatabaseName") // 设置捕获的数据库， 如果需要同步整个数据库，请将 tableList 设置为 ".*"..tableList("yourDatabaseName.yourTableName") // 设置捕获的表.username("yourUsername").password("yourPassword").startupOptions(StartupOptions.timestamp(1685548800000L)) // 从2023-06-01零点处读取binlog.deserializer(new JsonDebeziumDeserializationSchema()) // 将 SourceRecord 转换为 JSON 字符串.build();StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();// 设置 3s 的 checkpoint 间隔env.enableCheckpointing(3000);env.fromSource(mySqlSource, WatermarkStrategy.noWatermarks(), "MySQL Source")// 设置 source 节点的并行度为 4.setParallelism(4).print().setParallelism(1); // 设置 sink 节点并行度为 1 env.execute("Print MySQL Snapshot + Binlog");}
}

代码摘自mysql-cdc-connector官网示例

5.2.2、全量同步阶段

  1. 接下来我们将从全量同步开始逐步演示同步过程，这里我们以2023-06-0日的[Mysql]业务数据为例，此时表数据如下：
idnamephonegendercreate_timeupdate_time
1jack111男2023-06-01 13:00:002023-06-01 13:00:00
2jason222男2023-06-01 13:00:002023-06-01 13:00:00
3tom333男2023-06-01 13:00:002023-06-01 13:00:00
  1. 此时Flink应用启动获取到的数据如下：仅展示一条
{"before": null,"after": {		 # 实际数据"id": 1,"name": "jack","phone": "111","gender": "男","create_time": "2023-06-01T05:00:00Z",  # 该日期是UTC时间,只需增加8小时即可转化为北京时间"update_time": "2023-06-01T05:00:00Z"	# 该日期是UTC时间,只需增加8小时即可转化为北京时间},"source": {		 # 元数据"version": "1.6.4.Final","connector": "mysql","name": "mysql_binlog_source","ts_ms": 0,"snapshot": "false","db": "yushu_dds","sequence": null,"table": "user","server_id": 0,"gtid": null,"file": "","pos": 0,"row": 0,"thread": null,"query": null},"op": "r",  	 # 记录每条数据的操作类型[重要]"ts_ms": 1705471382867,"transaction": null
}

  1. 在我们使用 Flink CDC MySQL 同步数据时，默认采用 initial 模式，这意味着首先进行全量同步，然后再进行增量同步。因此，在区分全量和增量同步时，关键在于观察获取到的数据中的 op 字段。op 字段是用来记录每条数据的操作类型的标志。具体的操作类型如下：

    • op=d 代表删除操作

    • op=u 代表更新操作

    • op=c 代表新增操作

    • op=r 代表全量读取，而不是来自 binlog 的增量读取

  2. 在 Flink 程序中，只需要通过 op=r 即可筛选出全量数据。在全量数据同步阶段只需将op=r的业务数据直接同步至快照表，流水表在全量阶段无需同步，导入语句如下：

INSERT INTO example_user_snapshot (id, dt, name, phone, gender, create_time, update_time)
VALUES(1, '2023-06-01', 'jack', 111, '男', '2023-06-01 13:00:00', '2023-06-01 13:00:00'),(2, '2023-06-01', 'jason', 222, '男', '2023-06-01 13:00:00', '2023-06-01 13:00:00'),(3, '2023-06-01', 'tom', 333, '男', '2023-06-01 13:00:00', '2023-06-01 13:00:00');
  1. 此时doris快照表数据如下所示：
iddtnamephonegendercreate_timeupdate_time
12023-06-01jack111男2023-06-01 13:00:002023-06-01 13:00:00
22023-06-01jason222男2023-06-01 13:00:002023-06-01 13:00:00
32023-06-01tom333男2023-06-01 13:00:002023-06-01 13:00:00
  1. 此时doris流水表数据如下所示：全量阶段流水表无需同步
idupdate_timedtcreate_timenamephonegenderopbeforebinlog
NULLNULLNULLNULLNULLNULLNULLNULLNULLNULL

5.2.3、增量同步阶段

  1. 这里我们以2023-06-02日的[Mysql]业务数据为例，新增了一名tony用户，且更改了tom的手机号，此时表数据如下：
idnamephonegendercreate_timeupdate_time
1jack111男2023-06-01 13:00:002023-06-01 13:00:00
2jason222男2023-06-01 13:00:002023-06-01 13:00:00
3tom444男2023-06-01 13:00:002023-06-02 09:00:00
4tony555男2023-06-02 10:00:002023-06-02 10:00:00
  1. 此时Flink应用获取到的数据如下：
# 新增tony变更数据如下
{"before": null,"after": {"id": 4,"name": "tony","phone": "666","gender": "男","create_time": "2023-06-02T02:00:00Z","update_time": "2023-06-02T02:00:00Z"},"source": {# 元数据信息忽略},"op": "c", # 操作类型"ts_ms": 1706768344113,"transaction": null
}
# tom手机号333->444变更数据如下
{"before": {"id": 3,"name": "tom","phone": "333","gender": "男","create_time": "2023-06-01T05:00:00Z","update_time": "2023-06-01T05:00:00Z"},"after": {"id": 3,"name": "tom","phone": "444","gender": "男","create_time": "2023-06-01T05:00:00Z","update_time": "2023-06-01T23:00:00Z"},"source": {# 元数据信息忽略},"op": "u", # 操作类型"ts_ms": 1706768454904,"transaction": null
}
  1. 当 Flink 同步程序接收到 op=c/u/d 表示增量更新数据时，提取其中的 op、before 和 after 数据。接着将这些信息拼装成 Doris 的 INSERT 语句后插入到流水表中，此时流水表数据如下所示：
idupdate_timedtcreate_timenamephonegenderopbeforebinlog
42023-06-02 10:00:002023-06-022023-06-02 10:00:00tony555男cNULL{“before”:null,“after”:{“id”:4,“name”:“tony”,“phone”:“666”,“gender”:“男”,“create_time”:“2023-06-02T02:00:00Z”,“update_time”:“2023-06-02T02:00:00Z”},“source”:{“version”:“1.6.4.Final”,“connector”:“mysql”,“name”:“mysql_binlog_source”,“ts_ms”:1706768344000,“snapshot”:“false”,“db”:“yushu_dds”,“sequence”:null,“table”:“user”,“server_id”:2307031958,“gtid”:“71221bfd-56e8-11ee-8275-fa163e4ecceb:33719321”,“file”:“3509-binlog.000191”,“pos”:643757739,“row”:0,“thread”:null,“query”:null},“op”:“c”,“ts_ms”:1706768344113,“transaction”:null}
32023-06-02 08:00:002023-06-022023-06-02 13:00:00tom444男u{“id”:3,“name”:“tom”,“phone”:“333”,“gender”:“男”,“create_time”:“2023-06-01T05:00:00Z”,“update_time”:“2023-06-01T05:00:00Z”}{“before”:{“id”:3,“name”:“tom”,“phone”:“333”,“gender”:“男”,“create_time”:“2023-06-01T05:00:00Z”,“update_time”:“2023-06-01T05:00:00Z”},“after”:{“id”:3,“name”:“tom”,“phone”:“444”,“gender”:“男”,“create_time”:“2023-06-01T05:00:00Z”,“update_time”:“2023-06-01T23:00:00Z”},“source”:{“version”:“1.6.4.Final”,“connector”:“mysql”,“name”:“mysql_binlog_source”,“ts_ms”:1706768454000,“snapshot”:“false”,“db”:“yushu_dds”,“sequence”:null,“table”:“user”,“server_id”:2307031958,“gtid”:“71221bfd-56e8-11ee-8275-fa163e4ecceb:33719761”,“file”:“3509-binlog.000191”,“pos”:692873739,“row”:0,“thread”:null,“query”:null},“op”:“u”,“ts_ms”:1706768454904,“transaction”:null}
  1. 因增量数据无需同步至快照表，故此时快照表与之前06-01号一样保持不变，快照表数据如下：
iddtnamephonegendercreate_timeupdate_time
12023-06-01jack111男2023-06-01 13:00:002023-06-01 13:00:00
22023-06-01jason222男2023-06-01 13:00:002023-06-01 13:00:00
32023-06-01tom333男2023-06-01 13:00:002023-06-01 13:00:00

5.2.4、合并阶段

在合并阶段，我们将流水表前一天的数据与快照表中前两天的数据进行整合，最终得到前一天的全量数据，并将其写入至快照表的前一天分区。

合并任务会在满足以下任意一个条件时触发：

  1. 当binlog数据中的日期为第二天。
  2. 当凌晨过了5分钟（这是一个自定义的时间阈值）。

第二个条件的存在是因为业务数据很可能在凌晨00:00 ~ 00:05 分之间没有增量数据。因此，即使在没有业务数据同步的情况下，我们仍然可以通过第二个条件触发合并阶段，确保数据的完整性和准确性。

  1. 这里我们假设2023-06-03 00:05:00 触发合并阶段为例，此时业务数据如下所示：
idnamephonegendercreate_timeupdate_time
1jack111男2023-06-01 13:00:002023-06-01 13:00:00
2jason222男2023-06-01 13:00:002023-06-01 13:00:00
3tom444男2023-06-01 13:00:002023-06-02 09:00:00
4tony555男2023-06-02 10:00:002023-06-02 10:00:00
  1. flink程序中无新增数据，但由于满足第二个触发条件，在flink程序中将会触发合并任务[可用单独线程实现]，此时执行的doris合并语句如下：
INSERT INTO example_user_snapshot (id, dt, name, phone, gender, create_time, update_time)
SELECTid,'2023-06-02' as dt, -- 通过固定dt字段值从而写入快照表p20230602分区中name,phone,gender,create_time,update_time
FROM (SELECTsnap.id,snap.name,snap.phone,snap.gender,snap.create_time,snap.update_timeFROM example_user_snapshot PARTITION p20230601 snapLEFT JOIN example_user_stream PARTITION p20230602 stream ON snap.id = stream.idWHERE stream.id IS NULLUNIONSELECTid,name,phone,gender,create_time,update_timeFROM (SELECTid,name,phone,gender,create_time,update_time,-- 使用窗口函数的目的是处理流水表中可能存在多条相同id的记录，例如tom在06-02日更改多次手机号则会有多条相同id的数据，故此窗口函数用于确保选择每个id对应的update_time最大的记录；如果流水表设计的unique key = (id) 则不会出现重复情况无需此处的窗口函数。ROW_NUMBER() OVER (PARTITION BY id ORDER BY update_time DESC) AS row_num FROM example_user_stream PARTITION p20230602) rankedWHERE row_num = 1) AS temp;

该 SQL 查询是先获取两表联接中未更新的数据，与已更新的数据合并，最后写入到快照表中，确保了 2023-06-02 分区的数据是完整的全量数据。

若想详细剖析此sql的运算逻辑可参考笔者另一篇文章：数仓日常维护：剖析每日增量同步的内部机制

  1. 此时快照表的数据如下：
iddtnamephonegendercreate_timeupdate_time
12024-02-02jack111男2023-06-01 13:00:002023-06-01 13:00:00
22024-02-02jason222男2023-06-01 13:00:002023-06-01 13:00:00
32024-02-02tom333男2023-06-01 13:00:002023-06-01 13:00:00
12024-02-03jack111男2023-06-01 13:00:002023-06-01 13:00:00
22024-02-03jason222男2023-06-01 13:00:002023-06-01 13:00:00
32024-02-03tom555男2023-06-02 13:00:002023-06-02 09:00:00
42024-02-03tony555男2023-06-02 10:00:002023-06-02 10:00:00
  1. 用户可以通过如下语句查询2023-06-02全量数据：
SELECT * FROM example_user_snapshot PARTITION p20230602;
12024-02-03jack111男2023-06-01 13:00:002023-06-01 13:00:00
22024-02-03jason222男2023-06-01 13:00:002023-06-01 13:00:00
32024-02-03tom555男2023-06-02 13:00:002023-06-02 09:00:00
42024-02-03tony555男2023-06-02 10:00:002023-06-02 10:00:00

合并阶段的主要压力是Doris，Flink程序只是传递sql执行后获取结果即可；至此实时快照表同步逻辑结束。

5.3、数据一致性设计

在上述快照表同步过程中，如果Flink程序挂掉或者重启，是否会影响数据一致性？由于Flink程序是通过定时执行checkpoint且binlog可重读溯源，因此在数据获取阶段不会出现数据一致性问题。

需要考虑的地方在于合并阶段，如果触发了合并任务，而此时Flink程序还在不断消费业务变更数据，这里是异步还是阻塞？笔者建议使用异步：即Flink程序仍实时同步业务变更数据至流水表，而快照表的合并阶段主要是下沉到Doris库中执行。

需要注意的是如果在合并阶段时Flink程序挂掉，重启后该如何处理？笔者建议在Flink程序中采用有状态的计算，即Rich functions 富函数中的ValueState，用于记录当前合并阶段是否成功，如下：

javaCopy codeimport org.apache.flink.api.common.functions.RichMapFunction;
import org.apache.flink.api.common.state.StateTtlConfig;
import org.apache.flink.api.common.state.ValueState;
import org.apache.flink.api.common.state.ValueStateDescriptor;
import org.apache.flink.api.common.time.Time;
import org.apache.flink.configuration.Configuration;public class TestMapFunction extends RichMapFunction<Tuple2<String, Integer>, Tuple2<String, Integer>>  {// state 用于存放合并后的分区，例如: state=p20230601private transient ValueState<String> state;@Overridepublic Tuple2<String, Integer> map(Tuple2<String, Integer> in) throws Exception {// 业务逻辑}public void open(Configuration parameters) throws Exception {// 初始化 state}
}

通过这种方式，即便Flink在同步过程中宕掉，只要根据checkpoint重启后便可检测到上一个分区任务失败，即state != 20230602，从而再次触发合并阶段！

关于flink有状态的计算可参考Flink官网介绍

五、总结

此设计方式主要面向对数据准确性要求较高的场景。如果对数据准确性要求不高，完全可以考虑采用离线数仓 T+1 的方式构建快照表。

另外，此背景需求也可以通过拉链表实现。值得注意的是，拉链表能够支持更多的需求，例如实时数据查看。相比之下，本文介绍的快照表主要用于查看历史数据，不支持实时数据查看。

六、相关资料

  • Doris 数据模型
  • Flink状态计算
  • MySQL CDC Connector
  • 数仓日常维护：剖析每日增量同步的内部机制
  • Flink实时数仓同步：流水表实战详解
  • Flink实时数仓同步：拉链表实战详解
  • 深入数仓离线数据同步：问题分析与优化措施

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

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

相关文章

MySQL数据库入门

MySQL数据库入门

MySQL数据库概述 1&#xff0c;为什么要使用数据库2&#xff0c;数据库的相关概念3&#xff0c;常见的数据库管理系统4&#xff0c;MySQL介绍5&#xff0c;关系型数据库和非关系型数据库6&#xff0c;关系型数据库的设计规则7&#xff0c;表的关联关系7.1&#xff0c;一对一7.2…
阅读更多...
短剧小程序开发：打造高效、便捷的娱乐体验

短剧小程序开发：打造高效、便捷的娱乐体验

随着移动互联网的普及和用户需求的多样化&#xff0c;短剧小程序作为一种新型的应用形态&#xff0c;逐渐受到了广大用户的青睐。短剧小程序开发旨在为用户提供一种高效、便捷的娱乐体验&#xff0c;让用户在忙碌的生活中轻松享受到精彩的短剧内容。本文将探讨短剧小程序开发的…
阅读更多...
0203-2-输入输出系统

0203-2-输入输出系统

第六章&#xff1a;输入输出系统 I/O系统的功能&#xff0c;模型和接口 I/O系统管理的对象是I/O设备和相应的设备控制器。 I/O系统的基本功能 隐藏物理设备的细节与设备的无关性提高处理机和I/O设备的利用率对I/O设备进行控制确保对设备的正确共享错误处理 I/O软件的层次结…
阅读更多...
【蓝桥杯选拔赛真题87】Scratch多变的太阳 第十五届蓝桥杯scratch图形化编程 少儿编程创意编程选拔赛真题解析

【蓝桥杯选拔赛真题87】Scratch多变的太阳 第十五届蓝桥杯scratch图形化编程 少儿编程创意编程选拔赛真题解析

目录 scratch多变的太阳 一、题目要求 编程实现 二、案例分析 1、角色分析
阅读更多...
Vite与Webpack打包内存溢出问题优雅处理方式

Vite与Webpack打包内存溢出问题优雅处理方式

Vite与Webpack打包内存溢出问题处理 文章目录 Vite与Webpack打包内存溢出问题处理1. Vite1. 打包错误提示2. 命令行方式解决3. 配置环境变量方式解决1. 设置变量2. 配置系统的环境变量 2. Webpack1. 打包错误提示2. 命令行方式解决3. 配置环境变量方式解决1. 设置变量2. 配置系…
阅读更多...
【DDD】学习笔记-什么是模型

【DDD】学习笔记-什么是模型

从领域驱动的战略设计进入战术设计&#xff0c;简单说来&#xff0c;就是跨过系统视角的限界上下文边界进入它的内部&#xff0c;从分层架构的逻辑分层进入到每一层的内部。在思考内部的设计细节时&#xff0c;首先需要思考的问题就是&#xff1a;什么是模型&#xff08;Model&…
阅读更多...
NETX90-多协议通讯芯片

NETX90-多协议通讯芯片

随着作为信息物理系统核心技术的工业物联网的发展&#xff0c;Hilscher 基于 netX 51/52成功开发了新一代网络控制器netX90&#xff0c;其安全性是产品的核心价值。可实现更高性能的集成&#xff0c;并提高功率效率等级&#xff0c;凭借其较小的外形尺寸能够满足规格尺寸更小的…
阅读更多...
css新手教程

css新手教程

css新手教程 课程&#xff1a;14、盒子模型及边框使用_哔哩哔哩_bilibili 一.什么是CSS 1.什么是CSS Cascading Style Sheet 层叠样式表。 CSS&#xff1a;表现&#xff08;美化网页&#xff09; 字体&#xff0c;颜色&#xff0c;边距&#xff0c;高度&#xff0c;宽度&am…
阅读更多...
Linux信号详解~

Linux信号详解~

目录 前言 一、初识信号 二、信号的概念 三、信号的发送与捕捉 3.1 信号的发送 3.1.1 kill 命令 3.1.2 kill 函数 3.1.3 raise函数 3.1.4 abort函数 3.2 信号的捕捉 3.2.1 signal函数 3.2.2 sigaction函数 3.2.3 图示 四、信号的产生 4.1 硬件异常产生信号 4.2 …
阅读更多...
CMake Msys2 搭配vscode

CMake Msys2 搭配vscode

(一)MSYS2介绍 MSYS2&#xff08;Minimal SYStem 2&#xff09;是一个集成了大量的GNU工具链、工具和库的开源软件包集合。它提供了一个类似于Linux的shell环境&#xff0c;可以在Windows系统中编译和运行许多Linux应用程序和工具。 MSYS2基于MinGW-w64平台&#xff0c;提供了…
阅读更多...
Linux---进程间通信 | 管道 | PIPE | MKFIFO | 共享内存 | 消息队列

Linux---进程间通信 | 管道 | PIPE | MKFIFO | 共享内存 | 消息队列

管道 管道是UNIX中最古老的进程间通信的形式&#xff0c;我们把从一个进程连接到另一个进程的数据流称为一个管道。 一个文件&#xff0c;可以被多个进程打开吗&#xff1f;可以&#xff0c;那如果一个进程打开文件&#xff0c;往文件里面写数据&#xff0c;另一个进程打开文…
阅读更多...
MySQL 中 int(1) 和 int(10) 会影响存储的长度吗

MySQL 中 int(1) 和 int(10) 会影响存储的长度吗

一、MySQL 中 int(1) 和 int(10) 在MySQL数据库设计中&#xff0c;经常会遇到 int 类型的字段&#xff0c;并会习惯性的指定长度&#xff0c;比如&#xff1a; int(1) 和int(10)&#xff0c;而一些新手可能会误解它们之间的关系&#xff0c;认为 int(10) 能够存储更多的数据。…
阅读更多...
Android Camera2 API 后台服务

Android Camera2 API 后台服务

最近在搞CameraAPP需要将Camera2弄成一个后台服务&#xff0c;发现跟预览的Activity没多大变动只是加了Service&#xff0c;和一些简单的修改。之前的公司也用到Camera2&#xff0c;发现用到的时候还是蛮多的所以记录一下&#xff0c;代码在文章末尾 camera2的结构如下&#x…
阅读更多...
Peter算法小课堂—Dijkstra最短路算法

Peter算法小课堂—Dijkstra最短路算法

大家好&#xff0c;我们人见人爱、花见花开、车见车爆胎的Peter Pan来啦&#xff0c;hia~hia~hia。今天&#xff0c;我们今天来学习毒瘤的最短路算法啦。啊这……什么是Dijkstra算法&#xff1f;长文警告⚠ 正经点啊 手算样例 大家思考一下&#xff0c;你在手算样例的时候&am…
阅读更多...
企业申请sectigo ip https证书

企业申请sectigo ip https证书

Sectigo&#xff08;原名Comodo&#xff0c;在整合https证书业务后改名为Sectigo&#xff09;是一家知名的数字证书提供商&#xff0c;拥有多种类型的数字证书&#xff0c;例如单域名https证书、多域名https证书、通配符https证书、IP https证书和代码签名证书等满足各类用户的…
阅读更多...
2024022期传足14场胜负前瞻

2024022期传足14场胜负前瞻

2024022期赛事由英超4场&#xff0c;德甲2场、意甲4场、西甲4场组成。售止时间为2月4日&#xff08;周日&#xff09;19点00分&#xff0c;敬请留意&#xff1a; 本期中深盘较多&#xff0c;1.5以下赔率3场&#xff0c;1.5-2.0赔率7场&#xff0c;其他场次是平半盘、平盘。本期…
阅读更多...
TCP 协议的相关特性

TCP 协议的相关特性

1. TCP格式 TCP特性&#xff1a;有连接&#xff0c;全双关&#xff0c;面向字节流&#xff0c;可靠传输。&#xff08;TCP安身立命的本钱&#xff0c;初心就是解决“可靠传输”问题&#xff09; 其实TCP的特征有很多这里我就简单的介绍几个。 2. 确认应答 其实用来确保可靠性&…
阅读更多...
Java并发基础：CountDownLatch全面解析！

Java并发基础：CountDownLatch全面解析！

内容概要 CountDownLatch的优点在于能够简洁高效地协调多个线程的执行顺序&#xff0c;确保一组线程都完成后才触发其他线程的执行&#xff0c;适用于资源加载、任务初始化等场景。它提供了清晰的等待/通知机制&#xff0c;易于理解和使用&#xff0c;是提升多线程程序性能和可…
阅读更多...
面试数据结构与算法总结分类+leetcode题目目录【基础版】

面试数据结构与算法总结分类+leetcode题目目录【基础版】

&#x1f9e1;&#x1f9e1;&#x1f9e1;算法题目总结&#xff1a; 这里为大家总结数据结构与算法的题库目录&#xff0c;如果已经解释过的题目会标注链接更新&#xff0c;方便查看。 数据结构概览 Array & String 大家对这两类肯定比较清楚的&#xff0c;同时这也是面试…
阅读更多...
Java基础—反射

Java基础—反射

Java基础-反射 前置知识动态语言JVM堆Java引用变量类型编译时类型运行时类型举栗特殊情况 RRTI概念为什么需要RTTI例子 Class类对象前置知识类加载器概念作用 Class类对象的概念Class类对象的总结 总结一下前置知识 反射基础概念为什么要学反射我需要学到什么程度 反射的基础内…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023