你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
数据持久性功能设计为复制系统的补充机制。 虽然中转站跨多个节点复制数据,但群集范围的关闭仍可能导致数据丢失。
为了缓解此风险,MQTT 中转站支持持久性存储,这样关键数据就可以写入磁盘并在重启时保留。 此数据持久性功能不同于 磁盘支持的消息缓冲区,该缓冲区使用磁盘作为内存的扩展,但暂时性,不提供持久性保证。
在磁盘上存储数据会产生性能成本。 影响因基础存储介质的类型和速度而异。
可以使用 Azure 门户或 Azure CLI 在初始部署期间配置数据持久性。 还可以在部署后更改一些持久性选项。
配置方法
使用以下方法之一为 MQTT 中转站配置数据暂留:
- Azure 门户:在 IoT作部署期间通过图形用户界面配置持久性设置。
-
Azure CLI:使用
az iot ops create
命令部署 IoT作时,使用带有标志的--broker-config-file
JSON 配置文件。
有关可用设置的完整列表,请参阅 Azure IoT作 API 文档。
部署时配置选项
必须在部署期间设置这些选项,以后不能更改它们。
重要
在部署期间设置持久性,之后无法将其关闭。 部署后,可以更改一些与持久性相关的选项。
卷和卷大小
MQTT 代理使用永久性卷(PV)将数据存储在磁盘上。 两个设置控制如何预配此卷:
maxSize
(必需):设置存储中转站数据的最大永久性卷大小。 即使提供自定义卷声明,此字段也始终是必需的。 该值必须大于 100 MB。示例:
10GiB
persistentVolumeClaimSpec
(可选):允许定义自定义 PersistentVolumeClaim (PVC) 模板来控制永久性卷的预配方式。 如果未设置此选项,代理将使用指定的maxSize
默认存储类和默认存储类创建默认 PVC,如果默认类不受本地路径预配器支持,则可能会导致性能欠佳。
重要
指定 persistentVolumeClaimSpec
时,访问模式必须设置为 ReadWriteOncePod
。
- Azure 门户
- Azure CLI
若要在 Azure 门户中配置卷设置,请执行以下作:
在 IoT作部署期间,导航到 MQTT Broker 配置部分。
在 “数据持久性 ”设置中:
- 设置永久性卷 的最大大小 (必需)。
- (可选)为自定义存储类要求配置 永久性卷声明规范 设置。
加密
为了保护数据,MQTT 中转站默认使用强 AES-256-GCM 加密加密磁盘上的所有持久性数据。 这可确保即使攻击者获得对基础卷的访问权限,敏感中转站状态或会话数据仍然受到保护。
加密是可选的,默认情况下处于打开状态。 如果需要,可以关闭加密。 加密仅保护静态数据;内存中的数据未加密。 使用加密的性能成本最低,但尚不支持密钥轮换。
- Azure 门户
- Azure CLI
使用 Azure 门户进行部署时,默认启用加密。 如果使用 Azure CLI 进行部署,则可以在中转站配置文件中禁用加密。
运行时配置选项
部署 Azure IoT Operations MQTT 中转站后,可以更新这些选项。
保留的消息持久性
保留的消息是中转站在连接到主题时存储并传送给新订阅者的 MQTT 消息。 即使订阅者最初发布消息时未连接,这些消息也有助于确保订阅者接收最新数据。 这对于新订阅服务器在连接时立即需要的状态更新、配置数据或最后已知值特别有用。
将保留的消息保存到磁盘可确保这些重要消息在中转站重启后幸存下来,并且不会在维护或意外关闭期间丢失。 如果没有持久性,保留的消息仅存在于内存中,并在中转站重新启动时丢失。 这会使新订阅者没有关键的初始数据。
此设置控制将保留的消息保存到磁盘。
mode
(如果retain
已设置):选项为None
、All
或Custom
。-
None
:不会保留任何保留的消息。 -
All
:所有保留的消息都保留。 -
Custom
:仅保留中列出的retainSettings.topics
主题。
-
如果选择
Custom
:retainSettings.topics
(可选):要保留的主题模式列表。 支持#
和+
通配符。retainSettings.dynamic.mode
(可选,默认值:Enabled
)允许 MQTT 客户端使用 MQTT v5 用户属性请求保留消息的磁盘持久性。
- Azure 门户
- Azure CLI
若要在 Azure 门户中配置保留的消息持久性,请执行以下作:
导航到 IoT作实例。
转到 MQTT Broker>数据持久性。
在 “保留消息 ”部分中:
- 选择 模式:“无”、“全部”或“自定义”。
- 如果选择“自定义”,请指定主题模式和动态模式设置。
订阅服务器队列持久性
订阅服务器队列保存等待传送到具有服务质量(QoS)1 订阅的 MQTT 客户端的消息。 当客户端使用 QoS 1 订阅时,代理会通过排队消息来保证消息传递,直到客户端确认接收为止。 对于可能暂时断开连接或处理消息缓慢的客户端,这些队列尤其重要。
将订阅服务器队列保存到磁盘可确保在代理重启期间不会丢失等待传递的消息。 此功能对于 IoT 方案至关重要,即设备可以在代理重启期间保持消息传送保证的间歇性连接性、处理速度缓慢或持续会话。 如果没有持久性,排队消息将丢失,这可能会导致重要设备通信数据丢失。
有关订阅服务器队列和消息传递的详细信息,请参阅 “配置中转站 MQTT 客户端选项”。
此设置控制将哪些订阅服务器消息队列保存到磁盘。 无论这些设置如何,会话状态元数据始终保留。
mode
(如果subscriberQueue
已设置):选项为None
、All
或Custom
。如果选择
Custom
:subscriberQueueSettings.subscriberClientIds
(可选):要保留的订阅者客户端 ID 的列表。 支持通配符*
。subscriberQueueSettings.dynamic.mode
(可选,默认值:Enabled
):允许 MQTT 客户端动态请求持久性。
- Azure 门户
- Azure CLI
若要在 Azure 门户中配置订阅服务器队列持久性,请执行以下作:
导航到 IoT作实例。
转到 MQTT Broker>数据持久性。
在 “订阅服务器队列 ”部分中:
- 选择 模式:“无”、“全部”或“自定义”。
- 如果选择“自定义”,请指定订阅者客户端 ID 和动态模式设置。
重要
以前未持久保存的客户端可以随时保持。 但是,只有为该特定客户端启用持久性后收到的已发布消息才会存储在磁盘上。 如果客户端稍后禁用持久性,则在客户端重新与 MQTT 清理启动 = true 标志重新连接之前,该更改才会生效。
会话过期和订阅服务器队列持久性
若要将订阅服务器消息队列保存到磁盘,会话到期间隔和代理的持久性配置都需要保持一致。 具体说来:
MQTTv5 客户端:可以使用 CONNECT 或 DISCONNECT 数据包的会话过期间隔属性指定会话到期间隔。 他们还可以使用指定的用户属性请求磁盘持久性行为。
MQTTv3 客户端:如果“清理会话”标志为 true,则会话到期间隔设置为 0。 否则,将使用中转站中的配置值
maxSessionExpirySeconds
。
代理根据配置模式和会话过期间隔以不同的方式处理订阅服务器队列暂留:
当模式设置为 None
:
- 无论会话到期间隔如何,所有订阅服务器队列都仅保留在内存中
当模式设置为 All
:
- 如果会话到期间隔 = 0:队列保留在内存中
- 如果会话到期间隔 > 0:队列在间隔的持续时间内持久保存到磁盘
当模式设置为 Custom
:
- 如果会话到期间隔 = 0:队列保留在内存中
- 如果会话到期间隔 > 0:队列在间隔期间保留到磁盘,前提是:
- 客户端 ID 与配置
subscriberQueueSettings.subscriberClientIds
的列表匹配,或 - 已启用动态模式,MQTTv5 客户端在其 CONNECT 数据包中提供了匹配的用户属性
- 客户端 ID 与配置
若要确保订阅服务器队列保存到磁盘,请记住以下要点:
- 仅当会话到期间隔大于 0 时,订阅服务器队列才会保留
- 对于
Custom
模式,必须显式列出客户端 ID,或者必须使用正确的用户属性启用动态持久性 - MQTTv5 客户端可以通过在其 CONNECT 数据包中包含配置的用户属性(默认值:
aio-persistence=true
) 来使用动态持久性
状态存储持久性
状态存储是 MQTT 中转站的内部组件,用于维护各种类型的作数据和元数据(超出标准 MQTT 消息)。 这包括中转站配置状态、会话信息、订阅详细信息和其他内部数据结构,代理使用该结构高效管理客户端连接和消息路由。
将状态存储数据存储到磁盘可确保中转站可以在重启时保持作连续性。 对于复杂的 IoT 部署来说,这一点尤其重要,因为当中转站从头开始重新生成内部数据结构时,丢失内部状态可能会导致连接问题、订阅损失或性能下降。
状态存储持久性在生产环境中特别有价值,可以最大程度地缩短恢复时间和保持服务一致性。 如果没有持久性,代理必须在重启时重新生成所有内部状态,这可能会导致临时服务中断和性能影响。
有关状态存储的详细信息,请参阅 了解 MQTT 中转站状态存储协议。
此设置控制内部状态存储中的键持久化。
mode
(如果设置了 stateStore,则为必需):选项为None
、All
或Custom
。如果选择
Custom
:stateStoreSettings.stateStoreResources
(可选):要保留的密钥类型和密钥的列表。keyType
:模式、字符串或二进制keys
:要保留的键/模式的列表。
stateStoreSettings.dynamic.mode
(可选,默认值:Enabled
):允许 MQTT 客户端动态请求持久性。
- Azure 门户
- Azure CLI
若要在 Azure 门户中配置状态存储持久性,请执行以下作:
- 导航到 IoT作实例。
- 转到 MQTT Broker>数据持久性。
- 在 “状态存储 ”部分中:
- 选择 模式:“无”、“全部”或“自定义”。
- 如果选择“自定义”,请使用密钥类型、密钥和动态模式设置指定状态存储资源。
使用动态持久性设置从客户端请求持久性
客户端可以通过在其消息中发送 MQTT v5 用户属性来请求对其数据的持久性。 这样,客户端就可以动态启用其消息、订阅者队列或状态存储条目的持久性,而无需更改代理配置。
当客户端请求持久性时,中转站会检查其当前的持久性设置并应用它们。 如果启用了请求的持久性模式并设置为允许动态请求,则中转站将保留客户端在配置中指定的数据。
可以通过在相应的配置部分中设置dynamic.mode
Enabled
来启用或禁用每种数据类型(保留的消息、订阅服务器队列和状态存储条目)的动态持久性设置。 用于动态持久性请求的 MQTT 用户属性密钥和值在中转站级别单独配置。
- Azure 门户
- Azure CLI
若要在 Azure 门户中配置动态持久性设置,请执行以下作:
导航到 IoT作实例。
转到 MQTT Broker>数据持久性。
配置全局 MQTT 用户属性设置:
- 设置 User 属性键 (默认值:
aio-persistence
) - 设置 User 属性值 (默认值:
true
)
- 设置 User 属性键 (默认值:
在每个持久性部分中(保留的消息、订阅服务器队列、状态存储):
- 将 动态持久性 设置为启用,以允许客户端请求该数据类型的持久性。
若要了解有关高级 MQTT 代理配置的 Azure CLI 支持的详细信息,请参阅 Azure CLI 对高级 MQTT 代理配置的支持。