本地优先软件

状态

随着网络的发展，用户交互和显示的元素数量不断增加。这些元素会改变用户看到的屏幕。改变屏幕的事物可以定义为“状态”。

例如，在信息网页（例如登陆页面）的情况下，“状态”是要显示的一条信息。

接下来，在 GitHub 的情况下，有各种信息，例如我的信息、我的存储库信息、星星数量等。由于向用户显示的屏幕因这些而异，因此所有这些都可以被视为“状态” '。

作为一个更复杂的例子，你可以举像Figma这样的例子。屏幕上的所有图形，如点、线、面，都是“状态”。此外，协作功能需要您分享除您自己之外的其他人的状态。

状态与数据

状态都是数据。关于用户的信息、用户定制的信息等都是存储在某处的数据，这些数据很快就成为用户看到的屏幕的状态。通常，这些数据作为单一事实来源存储在服务器上。如果您登录到某个网站，它将作为单行保存在该网站服务器上的用户表中。

数据太远

现在的网络很复杂。一个屏幕上显示着无数的按钮和大量的数据。有很多信息，其时效性很重要。每当这些状态发生变化时，数据必须来回发送到服务器以确保一致性。如果你只需要每分钟接收“下一页”，就像文档一样，那并不是什么大问题。然而，在像Notion这样用户不断修改数据的情况下，这就成了一个大问题。如果我每次在页面上设置类似功能时都必须加载它，我会感到不安

。

乐观更新

想象一下在 Instagram 等社交媒体网站上点击“赞”按钮。当我点赞的时候，我必须去服务器保存我对帖子点赞的信息，将帖子的点赞数加一，然后获取当前帖子的点赞数并显示给我。

但在 Instagram 上，点赞数会在 0.001 秒内随着动画而增加。

这可以通过在信息到达服务器之前更新客户端的状态来实现。这个想法是更新客户端的状态，假设类似的数据会很好地记录在服务器上。大多数情况下，与服务器的通信都会成功，所以我们乐观地判断这是成功的。

当然，也有发送到服务器的请求失败的情况，所以要注意失败时回滚客户端状态。

响应性高于一致性

优化显示我是否点击了点赞按钮是非常合理的。但是当我点击的时候，其他人也点击了，所以点赞数可能增加了一个或多个，我该如何处理？

只要稍微忽略数据一致性就可以轻松解决这个问题。如果该帖子是热门帖子，那么在我查看该帖子期间，点赞数不可能不增加。这只是软件的策略。为了快速响应，牺牲了一些数据一致性

。

CAP定理

在分布式系统研究中，有CAP理论。该理论指出，配置分布式系统时，只能使用 C、A、P 中的两个。

C 代表一致性。无论从哪个节点读取数据，都必须读取相同的数据

。

A是Availability，表示即使某个节点挂掉了，是否所有的请求都能得到响应。

P 是 Partition-tolerance，即网络连接丢失时可以运行多少个节点以及网络连接后是否可以恢复。

根据这个理论，最终可能存在三种系统：CA、AP 和 CP。

CA

理论上，分布式系统可以选择CA，但我们决定不将网络连接丢失时不运行的系统称为分布式系统。

最后，如果是分布式系统，P一定要保证。

美联社

可用性高于一致性

当多个节点与网络断开连接时，即使所有节点对值的最新状态不一致，连接节点的值也会降低。因此，断开连接的节点之间的最新数据可能不匹配。不过，用户可以继续使用该服务，就像收到最新数据一样。

一个代表性的例子是社交媒体。尽管这在现实中不太可能发生，但我们假设 Instagram 欧洲节点和亚洲节点之间的网络连接丢失。在此中断期间，从亚洲访问的用户和从欧洲访问的用户看到的关注者数量、点赞数等略有不同，这是正常的。但该功能仍然有效。

CP

一致性优于可用性

这是一个在网络故障情况下无法保证最新数据的情况下不响应用户请求的系统。

示例通常与金钱（交易）有关。假设酒店只剩下一间有 50% 折扣的房间，但出现网络中断。在AP系统中，预订是假设两个房间都有空的情况下进行的，因此存在超额预订的可能性。 CP 系统不确定该数据的最新状态，因此推迟或拒绝请求。

PACELC定理

CAP理论实际上是一个关于划分的理论。如果发生分区，则必须选择A或C。

但实际上，正常情况下，是不会发生分区的。可以应用于这种情况的理论是PACELC理论。

如果 (P) 则 (AC) 否则 (LC)

也就是说，分区的情况下考虑AC，否则考虑LC。

液相色谱

延迟和一致性

正常情况下，系统会在延迟和一致性之间进行权衡。这是一个宏大的理论，但事实上，它就像整个计算机工程的真理

。

考虑权衡意味着在这两个标准之间找到一定程度的妥协。

延迟可以直观地确定从慢到快，但很难直观地知道什么是一致性。

一致性强

一致性很强，光听名字就感受到了。无论访问哪个节点，都必须看到相同的数据。换句话说，只有所有节点都有相同的数据，一致性才有可能。

我认为你可以考虑一家银行。

最终一致性

这是一种称为

总有一天它会保持一致的一致性。这意味着对于某个更改，并非所有客户端都会同时看到相同的值，但在同步完成后它们最终会看到相同的值。

因此，根据软件的特点，决定是牺牲延迟的同时兼顾一致性，还是为了快速响应而牺牲一致性。

以上是本地优先软件的详细内容。更多信息请关注PHP中文网其他相关文章！