Cloud Functions同步Realtime Database与Firestore数据不一致排查

开发者阿泽

2026-9-3

根因判定

你推测的「Firestore服务波动+未开重试+日志缺失」的判断不成立，核心问题几乎可以确定是触发器执行乱序导致的旧值覆盖，依据如下：

Firebase Cloud Function 默认会将所有未捕获的Promise异常、运行时错误全量上报到日志，不存在静默失败无记录的情况。如果是Firestore写入侧的服务波动、超时、权限错误，日志中一定会留存明确的错误栈，你没有查到对应记录就可以排除这类原因。
你提到的「无可用实例」报错属于冷启动阶段的调度错误，平台默认会自动重试这类请求，不会造成静默数据丢失，和你遇到的问题无关。
Realtime Database 的onWrite触发器不保证事件执行顺序：同一路径下短时间（哪怕间隔2-3秒）触发的多次事件，受冷启动、调度排队、网络延迟影响，后发生的事件完全可能比早发生的事件先执行完成。你当前的逻辑直接取触发时刻的change.after.val()做覆盖写入，一旦出现乱序，晚到的旧事件就会把已经写入的新值覆盖成脏数据，这类问题触发概率低、无报错日志，完全符合你描述的故障特征。

修复方案

不要开启函数全量重试，重试会放大乱序覆盖的概率，按以下方案改造即可：

核心改造：增加版本号+事务写入校验
这是解决分布式场景下乱序写入的标准方案，实现成本极低：

客户端/业务逻辑写入Realtime Database时，给每个invoice文档维护一个自增的整型字段updateVersion，每次更新文档时将该字段+1
改造云函数逻辑，放弃直接set的写法，改用Firestore事务做写入前校验：只有当前事件携带的版本号大于Firestore中已存储文档的版本号时，才执行写入，否则直接跳过本次旧事件。
改造后的参考代码如下：

const functions = require('firebase-functions');
const admin = require('firebase-admin');
admin.initializeApp();

exports.copyDocument = functions.database.ref('/invoices/{companyId}/{documentId}')
    .onWrite(async (change, context) => {
        const docRef = admin.firestore()
            .collection('companies').doc(context.params.companyId)
            .collection('invoices').doc(context.params.documentId);

        // 处理文档删除场景
        if (!change.after.exists()) {
            return docRef.delete().catch(err => {
                functions.logger.error('删除Firestore文档失败', err);
                throw err;
            });
        }

        const newData = change.after.val();
        const incomingVersion = newData.updateVersion ?? 0;

        return admin.firestore().runTransaction(async (transaction) => {
            const currentSnap = await transaction.get(docRef);
            // 目标文档不存在直接写入
            if (!currentSnap.exists) {
                return transaction.set(docRef, newData);
            }
            const storedVersion = currentSnap.data().updateVersion ?? 0;
            // 仅当传入版本高于存储版本时才覆盖，避免旧值写入
            if (incomingVersion > storedVersion) {
                return transaction.set(docRef, newData);
            }
            // 旧事件直接跳过
            return null;
        }).catch(err => {
            functions.logger.error('同步事务执行失败', err);
            throw err;
        });
    });

日志补全（可选）
如果你还是担心存在未捕获的静默错误，可以给所有Promise链加上显式的错误捕获日志，如上面代码所示。但实际上默认配置下未捕获的异常已经会被自动记录，这一步只是冗余校验。
不建议使用「触发时重新拉取Realtime Database最新值」的方案：拉取操作本身存在时间窗口，拉取完成到写入Firestore的间隙依然可能有新事件产生，无法从根本上解决乱序覆盖问题，可靠性远低于版本号校验方案。

这套方案是生产环境验证过的通用解法，多套RTDB-Firestore同步服务用这套逻辑运行多年，没有再出现过旧值覆盖导致的数据不一致问题。

内容的提问来源于stack exchange，提问作者BlazeFast