Firebase是否总是保证按顺序添加事件?

时间:2018-11-13 12:23:30

标签: ios firebase firebase-realtime-database

我正在基于Firebase实时数据库开发Messenger IOS应用程序。 我希望所有消息都基于时间戳进行排序。

有一种如下情况。

有3个客户。 A,B和C。

1)

所有客户端都注册了“ figure-1”侦听器,以接收来自其他客户端的消息。

<figure-1>

ref.queryOrdered(byChild: "timestamp").queryStarting(atValue: startTime).observe(.childAdded, with:
{
    ....
    // do work for the messages, print, save to storage, etc.
    ....

    // save startTime to storage for next open.     
    startTime = max(timeOfSnapshot, startTime)
    saveToStorage(startTime)
}

2)

Client A write  message 1 to server with ServerValue.timestamp().
Client B write  message 2 to server with ServerValue.timestamp().
Client C write  message 3 to server with ServerValue.timestamp().

他们在同一时间发送邮件。

所有客户端均具有良好的高速wifi。

所以,最后。服务器数据保存为“ figure-2”

<figure-2>

text : "Message 1",  timestamp : 100000001
text : "Message 2",  timestamp : 100000002
text : "Message 3",  timestamp : 100000003

作为我听众的代码,我将消息存储在存储器中,并保留下一个监听时间戳,以防止下载重复的消息。

在这种情况下。

Firebase是否始终保证按如下所示顺序触发回调?

Message 1
Message 2
Message 3

如果不能保证,我的策略绝对是错误的。

例如,某些客户端收到如下消息。

Message 3  // the highest timestamp.

// app crash or out of storage

Message 1
Message 2

客户端不再有机会收到消息1、2。

我认为,如果已经有一些节点,则Firebase可能会依次触发这些节点。因为,这就是“ queryOrdered”功能的作用。

但是,在注册侦听器之前没有节点,之后又添加了新节点。会发生什么?

我想Firebase可能会向客户端发送3个数据包。 (无论消息到达的速度有多快,Firebase都必须在消息到达后立即将其发送出去。)

Packet1 for message1
Packet2 for message2
Packet3 for message3

ClientA fail to receive for packet 1,2 
ClientA success to receive for packet 3
Firebase re-send packet 1,2 again. 
ClientA success to receive for packet 1,2 

最终,所有数据都是一致的。但是订购已损坏。

Firebase是否保证按顺序发生事件?

我搜索了堆栈溢出和Google,并阅读了许多官方文档。但是,我找不到明确的答案。

我差不多花了一个星期的时间。请给我一些建议。

1 个答案:

答案 0 :(得分:2)

The order in which the data for a query is returns is consistent, and determined by the server. So all clients are guaranteed to get the results in the same order.

For new data that is sent to the database after the listeners are attached, all remote clients will receive it in the same order. The local client will see events for it's write operation right away though, before the data even reaches the database server.

In figure 2, it is actually quite simple: since each node has a unique timestamp, and they will be returned in the order of that timestamp. But even if they'd have the same timestamp, they'd be returned in the same order (timestamp first, then key) for each client.