用户对实时数字体验的需求稳步上升，刺激了全球实时数据的增加--从虚拟事件、新闻、金融信息到物联网设备。Ably平台提供实时基础设施已经超过5年了，我们亲眼看到并帮助了需求的增长。 几年前，我们的客户只对一两个特定的功能有实时需求，通常是围绕发射更新和通知。随着时间的推移，他们对实时性的应用越来越多，也越来越多样化，跨越了整个平台和服务。我们的功能开发也随之调整，以满足不断增长的用户需求。

对信息历史的需求导致了渠道倒退

最初，我们大多数客户的核心用例是简单地接收实时发生的消息。在客户暂时断开连接的情况下，存储在我们服务器上的60-120秒的消息缓冲区，并通过历史API请求返回，就足以确保他们在回到网络上时能收到消息。

但随着使用情况的多样化，许多用户需要访问更长的时间跨度的消息。例如，多人游戏中的公共聊天需要提供玩家加入前5分钟的消息，因此他们对游戏中的行动有更多了解。为了提供这样的用例，Ably允许将一个频道的所有消息持续72小时--作为一个可以打开和关闭的功能。

持续72小时的消息最初也是通过历史API返回的，但该API确实增加了一些额外的延迟和复杂性，特别是对于没有使用Ably客户端库SDK的用户。为了解决这个问题，我们开发了Channel Rewind，它允许用户在连接请求中传递一个参数，指定他们想在连接时看到以前的信息。客户端收到的实时事件就像他们在100个消息之前连接的一样，这意味着更少的API调用，更低的延迟和更低的带宽使用。

对状态持久性的需求

我们的用户喜欢这样的能力，即附加到一个频道，获得最后的状态，然后通过频道回溯订阅从该点开始的更新。在某种程度上，这个功能使Ably有点像一个实时数据库--你可以连接并获得最近的更新，就像你从数据库中获得的那样，然后实时获得更新。Channel Rewind也很适合Message Delta Compression，它通过每次有更新时只向订阅者发送前一条信息的变化来节省带宽。

然而，还有另一个子集的用例需要考虑。在分布式系统中，你经常需要对状态进行建模。状态可以是：

• 零星更新；通常有时间上的持久性要求--如系统配置
• 周期性更新，如传感器读数或车辆的位置
• 缓存的值，只有在改变时才会更新，如电子商务的购物车

当涉及到与状态有关的用例时，消息持久化有两个不足之处：它通常仅限于过去的72小时，而且当只需要最后一条消息时，将所有的消息存储在一个通道上是浪费和昂贵的。我们的解决方案是开发状态持久性。

状态持久性允许用户在典型的倒带和历史API保留期之后，继续保留频道上的最后一条信息，最长可达1年。要在一个频道上存储最后发布的信息365天，你首先需要启用持久化最后一条信息作为频道命名空间属性。然后，你可以使用频道回溯或历史API检索频道上的最后一条消息。

状态持久性的用武之地

状态持久性可以使你不必在服务器中建立额外的功能，它可以帮助你实现无服务器架构。

想象一下，你拥有一家电子商务商店。客户经常放弃他们的购物车并关闭商店窗口，只是在几天后，有时是几周后才回到你的网站。当他们返回时，他们希望发现他们的购物车处于离开时的状态，这样他们就能轻松完成交易。

购物篮的状态将存储在你的后台服务器上，但你不希望查询它，并使你的服务器过载，直到终端用户真正做一些事情。更有效的做法是将购物篮的状态作为Ably通道上的一个消息，一旦对方连接，就立即加载。他们的购物车的最后状态将通过Ably加载，远离你的后台服务器，甚至不需要他们创建一个账户。

或者说，你正在运行大量的无服务器函数，而它们的配置是通过另一个无服务器函数来管理的。为了动态地改变你的配置，经理函数会查询Ably通道上的最后一条消息。当你想改变你的配置时，你只需改变你在通道上发送的消息。随着你的无服务器函数开始运行，你可以建立起精心设计的基于状态的功能，这些功能可以随时改变。

通过状态持久化，Ably允许你为零星更新并有时间持久性要求的状态建模，但又具有真实的数据流的灵活性。如果你想尝试一下状态持久化，你可以使用Ably Hub上的免费数据源作为消息进行尝试，例如，天气数据。