有什么方法可以为 MQTT Broker 中的消息提供 TTL
Is there any way to give TTL for messages in MQTT Broker
在 MQTT 规范中有控制服务器和客户端上的保留和状态的连接标志。
清理会话 specification 建议：
3.1.2.4 Clean Session Position: bit 1 of the Connect Flags byte.
This bit specifies the handling of the Session state. The Client and
Server can store Session state to enable reliable messaging to
continue across a sequence of Network Connections. This bit is used to
control the lifetime of the Session state.
If CleanSession is set to 0, the Server MUST resume communications
with the Client based on state from the current Session (as identified
by the Client identifier). If there is no Session associated with the
Client identifier the Server MUST create a new Session. The Client and
Server MUST store the Session after the Client and Server are
disconnected [MQTT-3.1.2-4].
After the disconnection of a Session that had CleanSession set to 0,
the Server MUST store further QoS 1 and QoS 2 messages that match any
subscriptions that the client had at the time of disconnection as part
of the Session state
因此，只要客户端在断开连接后再次连接，代理就会中继所有未确认的 QoS-1 和 QoS-2 消息。所以，经纪人有一个状态。为了维护每个客户端的状态，服务器将使用一些数据库进行保留。有没有办法为这些消息状态（服务器将存储）提供生存时间。如何告诉代理丢弃（即不中继）任何早于的消息；假设 5 天。
基本上，我们想使用 clean session = 0 和 QoS-1；但是如何用旧消息清除代理状态？不想收到早于 5 天的消息，即使未收到消息也是如此。
简短的回答，你不能（在符合 v3.0 规范的情况下）。
根据规范，客户端的持久状态需要无限期保留。
您没有提到您使用的是哪个代理，但 mosquitto 确实有以下（none 标准）选项：
persistent_client_expiration duration
This option allows persistent clients (those with clean session set to false) to be removed if they do not reconnect within a certain
time frame. This is a non-standard option. As far as the MQTT spec is
concerned, persistent clients persist forever.
Badly designed clients may set clean session to false whilst using a randomly generated client id. This leads to persistent clients that
will never reconnect. This option allows these clients to be removed.
The expiration period should be an integer followed by one of h d w m y for hour, day, week, month and year respectively. For example:
persistent_client_expiration 2m
persistent_client_expiration 14d
persistent_client_expiration 1y
As this is a non-standard option, the default if not set is to never expire persistent clients.
这意味着如果客户端离线的时间超过指定时间，则该客户端的所有排队消息都将被转储（并且不再排队）。
这可能是您最接近您想要的。
MQTT 5.0 允许为发布设置消息过期间隔。
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901112
3.3.2.3.3 Message Expiry Interval
2 (0x02) Byte, Identifier of the Message Expiry Interval.
Followed by the Four Byte Integer representing the Message Expiry
Interval.
If present, the Four Byte value is the lifetime of the Application
Message in seconds. If the Message Expiry Interval has passed and the
Server has not managed to start onward delivery to a matching
subscriber, then it MUST delete the copy of the message for that
subscriber [MQTT-3.3.2-5].
If absent, the Application Message does not expire.
The PUBLISH packet sent to a Client by the Server MUST contain a
Message Expiry Interval set to the received value minus the time that
the Application Message has been waiting in the Server [MQTT-3.3.2-6].
Refer to section 4.1 for details and limitations of stored state.
在 MQTT 规范中有控制服务器和客户端上的保留和状态的连接标志。
清理会话 specification 建议：
3.1.2.4 Clean Session Position: bit 1 of the Connect Flags byte.
This bit specifies the handling of the Session state. The Client and Server can store Session state to enable reliable messaging to continue across a sequence of Network Connections. This bit is used to control the lifetime of the Session state.
If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected [MQTT-3.1.2-4].
After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state
因此，只要客户端在断开连接后再次连接，代理就会中继所有未确认的 QoS-1 和 QoS-2 消息。所以，经纪人有一个状态。为了维护每个客户端的状态，服务器将使用一些数据库进行保留。有没有办法为这些消息状态（服务器将存储）提供生存时间。如何告诉代理丢弃（即不中继）任何早于的消息；假设 5 天。
基本上，我们想使用 clean session = 0 和 QoS-1；但是如何用旧消息清除代理状态？不想收到早于 5 天的消息，即使未收到消息也是如此。
简短的回答，你不能（在符合 v3.0 规范的情况下）。
根据规范，客户端的持久状态需要无限期保留。
您没有提到您使用的是哪个代理，但 mosquitto 确实有以下（none 标准）选项：
persistent_client_expiration duration
This option allows persistent clients (those with clean session set to false) to be removed if they do not reconnect within a certaintime frame. This is a non-standard option. As far as the MQTT spec is concerned, persistent clients persist forever.
Badly designed clients may set clean session to false whilst using a randomly generated client id. This leads to persistent clients thatwill never reconnect. This option allows these clients to be removed.
The expiration period should be an integer followed by one of h d w m y for hour, day, week, month and year respectively. For example: persistent_client_expiration 2m persistent_client_expiration 14d persistent_client_expiration 1y As this is a non-standard option, the default if not set is to never expire persistent clients.
这意味着如果客户端离线的时间超过指定时间，则该客户端的所有排队消息都将被转储（并且不再排队）。
这可能是您最接近您想要的。
MQTT 5.0 允许为发布设置消息过期间隔。
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901112
3.3.2.3.3 Message Expiry Interval
2 (0x02) Byte, Identifier of the Message Expiry Interval.
Followed by the Four Byte Integer representing the Message Expiry Interval.
If present, the Four Byte value is the lifetime of the Application Message in seconds. If the Message Expiry Interval has passed and the Server has not managed to start onward delivery to a matching subscriber, then it MUST delete the copy of the message for that subscriber [MQTT-3.3.2-5].
If absent, the Application Message does not expire.
The PUBLISH packet sent to a Client by the Server MUST contain a Message Expiry Interval set to the received value minus the time that the Application Message has been waiting in the Server [MQTT-3.3.2-6]. Refer to section 4.1 for details and limitations of stored state.