backlog配额和TTL有什么区别
What's the difference between backlog quotas and TTL
来自文档：https://pulsar.apache.org/docs/en/cookbooks-retention-expiry/#get-the-ttl-configuration-for-a-namespace，关于积压配额和 TTL 之间的区别有点令人困惑。
据我所知，消息到达代理，代理将找出关于该主题的所有订阅，并检索他们的积压，并将消息放入这些积压。如果此消息被一个订阅确认，它将从其积压中删除（积压是每个订阅）。如果消息不在任何积压中（意味着所有订阅都已确认），则此消息被视为已确认，然后保留策略生效，以决定是否需要将其删除或保留一段时间。
如果一条消息在一段时间内未在一个积压中得到确认，并且积压配额达到了大小限制，那么积压保留策略就会生效。所以这更多的是关于大小而不是时间。如果我们使用 consumer_backlog_eviction，这条消息将从积压中丢弃，但问题是，这是否被视为已确认？所以第一个保留政策开始生效？
还有 TTL，如果消息在一段时间内未被确认，是否会从所有待办事项列表中删除？然后被视为已确认，然后让第一个保留策略处理它？
更新：
更准确地说这个问题：
在积压配额文档中，它说：
consumer_backlog_eviction: The broker will begin discarding backlog
messages
丢弃手段，使其得到认可？以便全球保留政策可以生效？
producer_request_hold: The broker will hold and not persist produce request payload
它是说，它不会将新消息放入积压中，但是对于那些新来的消息，它们是否会自动确认（比如当时只有一个订阅）？这是否会阻止真正的生产者（我猜不会，只是代理不会再将新消息放入积压中）
(for TTL) If disk space is a concern, you can set a time to live (TTL) that determines how long unacknowledged messages will be retained.
同样，如果超过 TTL，它不会 "retain" 它，意思是，让它被确认？还是直接扔掉？
And if we use consumer_backlog_eviction, this message will be
discarded from the backlog, but question, is that considered
acknowledged or not? so the first retention policy kicks in?
消息将被确认并标记为删除。然后，根据配置，确认消息的保留策略将在某个时候启动。
And the TTL, if a message is not acknowledged for some time, will it
be removed from all backlogs? and then considered as acknowledged and
then let the first retention policy handle it?
TTL 应应用于所有积压工作，过时 未使用的消息将被自动确认。确认消息的保留政策将再次生效。
来自文档：https://pulsar.apache.org/docs/en/cookbooks-retention-expiry/#get-the-ttl-configuration-for-a-namespace，关于积压配额和 TTL 之间的区别有点令人困惑。
据我所知，消息到达代理，代理将找出关于该主题的所有订阅，并检索他们的积压，并将消息放入这些积压。如果此消息被一个订阅确认，它将从其积压中删除（积压是每个订阅）。如果消息不在任何积压中（意味着所有订阅都已确认），则此消息被视为已确认，然后保留策略生效，以决定是否需要将其删除或保留一段时间。
如果一条消息在一段时间内未在一个积压中得到确认，并且积压配额达到了大小限制，那么积压保留策略就会生效。所以这更多的是关于大小而不是时间。如果我们使用 consumer_backlog_eviction，这条消息将从积压中丢弃，但问题是，这是否被视为已确认？所以第一个保留政策开始生效？
还有 TTL，如果消息在一段时间内未被确认，是否会从所有待办事项列表中删除？然后被视为已确认，然后让第一个保留策略处理它？
更新：
更准确地说这个问题：
在积压配额文档中，它说：
consumer_backlog_eviction: The broker will begin discarding backlog messages
丢弃手段，使其得到认可？以便全球保留政策可以生效？
producer_request_hold: The broker will hold and not persist produce request payload
它是说，它不会将新消息放入积压中，但是对于那些新来的消息，它们是否会自动确认（比如当时只有一个订阅）？这是否会阻止真正的生产者（我猜不会，只是代理不会再将新消息放入积压中）
(for TTL) If disk space is a concern, you can set a time to live (TTL) that determines how long unacknowledged messages will be retained.
同样，如果超过 TTL，它不会 "retain" 它，意思是，让它被确认？还是直接扔掉？
And if we use consumer_backlog_eviction, this message will be discarded from the backlog, but question, is that considered acknowledged or not? so the first retention policy kicks in?
消息将被确认并标记为删除。然后，根据配置，确认消息的保留策略将在某个时候启动。
And the TTL, if a message is not acknowledged for some time, will it be removed from all backlogs? and then considered as acknowledged and then let the first retention policy handle it?
TTL 应应用于所有积压工作，过时 未使用的消息将被自动确认。确认消息的保留政策将再次生效。