根据Firestore documentation：
交易是对一个或多个文档的一组读写操作。
也：
客户端离线时，交易将失败。
现在，firestore中的限制是：
在Cloud Firestore中，您只能每秒更新一次文档，这对于某些高流量应用程序可能太低了。
因此，在流量较高时使用云功能并运行事务来增加/减少计数器将失败。
因此，他们讨论了使用distributed counters的方法。
根据分散计数器的算法：
场景：
考虑您有一个计数器，当添加文档并且该计数器正在UI中显示时，该计数器将被更新。现在，为了获得良好的用户体验，当网络处于脱机状态时，我无法阻止UI。因此，即使客户端处于脱机状态，我也必须允许文档的创建/更新，并且一旦客户端在线，就必须同步这些更改，以便其他所有听这些更改的人都能收到计数器的正确值。
现在，当客户端离线时，事务失败。 因此，我的问题以获得最佳用户体验（即使处于脱机状态）是：
您是否真的需要交易才能增加计数器？我知道 事务确保写入是原子的并且是 成功/不成功，并防止部分写入。那是什么 他们何时离线失败？我在想，也许将它们写入本地缓存，并在网络恢复联机后对其进行同步。
是否应通过云功能的客户端SDK来完成？
答案 0 :(得分：1)
您真的需要交易来增加计数器吗？
绝对可以！因为我们正在创建可在多用户环境中使用的应用程序，所以交易是强制性的，因此我们可以提供一致的数据。
但是当他们脱机失败时又有什么意义呢？
如果网络连接丢失（用户设备上没有网络连接），则不支持脱机使用事务。这是因为事务绝对需要与服务器进行往返通信，以确保事务内的代码成功完成。因此，交易只能在您在线时执行。
是否应该通过云功能的客户端SDK来完成？
请注意，Android版Firestore SDK的local cache已默认启用。根据有关Firestore offline persistence的官方文档：
对于Android和iOS，默认情况下启用离线持久性。要禁用持久性，请将PersistenceEnabled选项设置为false。
因此，如果服务器上没有更新，则所有读取操作都将来自缓存。因此，Firestore提供了此功能来处理离线数据。
您还可以在Cloud Function中编写一个函数，该函数将在添加新文档时增加计数器，或在删除文档时减少计数器。
我还建议您看看：
因此，您还可以考虑为此使用Firebase实时数据库。 Cloud Firestore和Firebase实时数据库可以很好地协同工作。
编辑：
即使设备处于离线状态，它也可以使答案增加。网络联机后，它将同步到服务器并更新计数器。设备离线时，是否可以在Firestore中执行此操作？
默认情况下也会发生这种情况。因此，如果用户尝试在脱机时添加/删除文档，则每个操作都会添加到队列中。一旦用户重新建立连接，脱机时所做的每个更改都将在Firebase服务器上更新。换句话说，所有查询都将在服务器上提交。
仅当收到更改时才触发云功能，并且只有在设备在线时才会发生。
是的，没错。设备重新建立网络连接后，将在数据库中添加/删除文档，函数将在该时刻触发并增加/减少计数器。
编辑2：
假设我已离线进行约100次操作，那么当设备联机时，这是否不会给云功能带来负担？您对此有何想法？
脱机时，尚未同步到服务器的挂起写入将保留在队列中。如果您没有在线同步就执行太多写操作，则该队列将快速增长，并且不仅会减慢写操作的速度，还会减慢您的读操作的速度。因此，我建议将此数据库用于在线功能。
关于这100个脱机操作的云功能，将没有问题。 Firebase服务器在并发操作中可以很好地工作。