我們有一個使用base64編碼內容將附件傳輸到後端的應用程序。後端在經過一些操作後將內容移動到存儲。這樣我們就可以享受世界級的離線支持和同步，並同時使用更便宜的存儲來存儲文件。我們使用updateChildren來設置內容。這很合適，但隨後用戶開始同時上傳更大和更多的文件，導致終端用戶設備中的數據庫無提示凍結。Firebase是否保證使用updateValues或setValue的數據集作爲一個原子單位在後端可用？
然後，我們更改了代碼，使用FirebaseDatabase.getInstance().getReference("/full/uri").setValue(base64stuff)逐個寫入文件，然後使用updateChildren僅設置元數據。
這允許看似無盡的文件數量（假設它被切成最大9兆大塊），但現在我們正面臨另一個問題。
我們的後端在新內容可用時使用Firebase偵聽器開始工作。觸發器等待元數據，然後開始處理附件。看起來，即使客戶端設備在之前寫入文件我們設置了元數據，但後端通常在文件中的內容可用之前接收元數據。這迫使我們更改後端代碼以停止處理，並在以後再次檢查附件base64數據是否可用。
這個工作，但不是優雅，浪費CPU週期和增加延遲。
我還沒有發現文檔中的任何內容Firebase保證任何關於後端接收數據的順序。似乎所有寫在一起的東西（使用setValue或updateChildren）在後端都可用作一個原子單元。
這是正確的嗎？我可以依靠這一事實作爲未來不會改變的事實嗎？
我要去這個（如果假設是正確以上）的方式是先在客戶端使用updateChildren這樣
"/uri/of/metadata/uid/attachments/attachment_uid1" = "per attachment metadata"
"/uri/of/metadata/uid/attachments/attachment_uid2" = "per attachment metadata"
，然後將元數據寫入使用updateChildren每個塊的base64以下有效載荷：
"/uri/of/metadata/uid/uploaded_attachments/attachment_uid2" = true
"/uri/of/base64/content/attachment_uid" = "base64content"
我不能使用的setValue任何數據，以防止依賴於在其中寫入將在年底發生的順序意外覆蓋。
這將允許我傾聽/uri/of/base64/content，並嘗試在每次新附件完成加載時開始處理元數據包。確定所有文件是否已經上傳所需的唯一東西是獲取元數據並查看從/ attachments /中找到的所有附件uid也存在/ uploaded_attachments /。
*這裏firebaser *從單一的火力地堡數據庫客戶端寫交付以與在客戶端上執行的順序相同的順序向服務器發送。它們也以相同的順序被廣播給任何聽取的客戶。除此之外，很難解析正在發生的事情。有什麼辦法可以將問題提煉到[MCVE]（http://stackoverflow.com/help/mcve）？ –
嗨！感謝您的輸入！我發現這個：https：//stackoverflow.com/questions/29100656/firebase-event-guarantee-event-order 雖然現在我已經重新設計我們的後端（這是一個Firebase客戶端）應對Firebase的最終一致性質 要重新說明問題：「Firebase是否在內部同步事件順序，以便不會發生從一個客戶端發送的事件在另一個客戶端中以不同於寫入順序的順序第一個）？」答案是「沒有這樣的保證。」如果我理解正確？ – anotherdev
不，你剛纔的陳述是錯誤的。來自單個客戶端的寫入按順序執行。沒有看到寫入A的結果（除非A被安全規則拒絕），否則另一個客戶端不會看到寫入B的結果。 –