本篇文档系统梳理 ThingsBoard 平台 HTTP 设备接入的整体实现方式，重点详解 HTTP 自动注册（provision）机制的完整调用链、核心模块及消息流转机制，并补充核心注册逻辑代码说明，帮助理解其分层解耦与分布式架构设计。

Thingsboard 启用 OAuth2 功能

使用 [email protected] / sysadmin 账号登录 Thingsboard 系统之后，在安全 -> OAuth2.0 页面，点击OAuth2.0客户端，先创建一个客户端，这里我创建的是 Github 客户端。

Uuids

UUID uuid = Uuids.timeBased();
Uuids.unixTimestamp(uuid)

UUID NULL_UUID = Uuids.startOf(0);

UUIDConverter

安装 Gitea

创建目录：

rm -rf /data/gitea
mkdir -p /data/gitea/{data,config}
sudo chown 1000:1000 /data/gitea/config/ /data/gitea/data/

使用 docker 命令安装：

Canal 是阿里巴巴开源的一款分布式增量数据同步工具，主要用于基于 MySQL 数据库的增量日志 Binlog 解析，提供增量数据的订阅和消费。

分布式 ID 的生成是分布式系统中的一个核心问题，需要确保生成的 ID 全局唯一、性能高效，并且能够适应高并发和大规模的场景。以下是一些常见的分布式 ID 生成方案：

以下是一个基于本地缓存 + Redis ZSet + 定时任务的榜单方案，适用于高并发场景：

在互联网领域，限流是指对进入系统的请求数量或频率进行控制的一种机制，以防止系统因流量暴增而过载，从而保障系统的稳定性和可用性。

在实际项目中，区分偶发性超时和频繁超时的重试策略非常重要。偶发性超时可能是由于网络抖动或临时负载过高引起的，适合立即重试；而频繁超时则可能是系统过载或下游服务不可用，此时应避免重试，以免加剧问题。

在实际面试的过程中，经常会遇到类似的面试题目，这时候可以这样回答：

在处理大量请求时，我们经常会遇到超时的情况。为了合理控制重试行为，避免所谓的“重试风暴”，我设计了一个基于时间窗口的算法。在这个算法中，我们维护了一个滑动窗口，窗口内记录了每个请求的时间戳以及该请求是否超时。每当一个请求超时后，我们会统计窗口内超时的请求数量。如果超时请求的数量超过了设定的阈值，我们就认为当前系统压力较大，不适合进行重试；否则，我们认为可以安全地进行重试。

然而，随着并发量的增加，普通版的滑动窗口算法暴露出了一些问题。特别是在高并发场景下，窗口内需要维护的请求数量可能非常大，这不仅占用了大量内存，而且在判定是否需要重试时还需要遍历整个窗口，这大大增加了算法的时间复杂度。

为了解决这个问题，我们进一步设计了进阶版的算法。在这个版本中，我们引入了ring buffer 来优化滑动窗口的实现。具体来说，我们不再以时间为窗口大小，而是使用固定数量的比特位来记录请求的超时信息。每个比特位对应一个请求，用1表示超时，用0表示未超时。当所有比特位都被标记后，我们从头开始再次标记。

2024 年的付费软件：

• TablePlus：

• Typora：

• ICloud：每月 6 元