Realtime DB技术详解

1. Realtime DB概述

1.1 Realtime DB简介

Realtime DB是一种托管在云端的数据库，数据以JSON格式存储并实时同步到所连接的每个客户端。具有以下特点：

• 使用的不是常见的HTTP请求，而是采用数据同步机制。每当数据发生变化时，任何连接的设备都会实时收到更新
• 提供灵活的基于表达式的规则语言，可以由用户自定义数据结构以及何时可以读取或写入数据
• 基于 MongoDB 的 NoSQL 数据 库，因此具有不同于关系型数据库的优化方向和 功能特点。服务端 API 的设计只支持可以快速执行 的操作，因此需要用户认真考虑存储的数据结构。

1.2 Realtime DB的产生背景及应用场景

基于BaaS的云原生APP的开发，需要一套用于信息存储、即时同步、原子修改、离线 缓存的数据库中间件，远程修改Serverless数据库，实现脱离服务端接口的目的。 为满足以上需求，而设计实现了Realtime DB这样一个中间件。通常应用在以下场景：

2. Realtime DB 技术发展历程

• Local DB:数据本地持久化 优点:稳定可靠，本地持久化 缺点:无法多端共享数据，可玩性较低
• Server Interface:通过服务端接口通信方式进行数据持久化 优点:可多端共享数据，云端可控 缺点:接口需要定制化，通常需要客户端+服务端+运维介入，无法自动伸缩扩容，较依赖网络可用性等
• Remote DB:远程实时数据库，数据云端持久化 优点:可多端共享数据，实时同步，可玩性较高，Serverless化，端侧自由定制数据结构，无需部署和维护服务器 缺点:较依赖网络可用性

3. Realtime DB研究现状

3.1 行业分析

Firebase是一家实时后端数据库创业公司，在2014年被Google收购，用户可以在更方便地使用Firebase的同时，结合Google的云服务。FireBase目前提出了两种支持实时数据同步且可通过客户端访问的云数据库解决方案，实时数据库和Cloud Firestore。

产品原理优点缺点实时数据库将数据存储为一个大型 JSON 树• 简单数据极易存储
• 支持在线状态检测• 复杂的分层数据较难大规模组织
• 查询、排序功能较弱Cloud Firestore将数据存储为文档集合• 简单数据很容易存储在文档中，与JSON非常相似
• 通过在文档中使用子集合，复杂的分层数据较易于大规模组织
• 反规范化和数据平展方面的需求更少使用起来较为复杂

3.2 功能需求及挑战

初步规划Realtime DB要满足以下需求，

• 增删改查语句支持
• 多端实时同步数据支持
• 公有云 or 私有云实现
• 离线缓存支持
• 数据自动伸缩扩容，Serverless化
• 数据安全保障手段
• 自定义增删查改协议，后期可扩展功能

根据需求初步选定技术方案，
1.云端数据库选型，实现Serverless
关系型数据库 VS 非关系型数据库，基于公司自研Serverless级云MongoDB，实现服务端云数据库存储

2.多端实时同步方案
采用 NoSQL 型数据库，数据以多叉树(K-V)方式存储，即JSON化，无须关心节点数据合并问题，服务端根 据操作时间进行数据覆盖即可

3.数据安全保障手段
数据节点定义读写权限，云端赋权【根据账号】，生成权限配置表

4.事务支持和原子操作
自定义远程数据库操作协议，预保留操作符“.”，用于后期实现原子操作等其他指令

5.数据库实时性保障
采用长连接，基于MDP自研长连接SDK-TapConnect，实现稳定的收发，毫秒级响应

3.3 解决方案

客户端侧架构设计分大致分为以下4层

数据扁平简化JSON

叶子结点基本数据类型: Boolean/String/Long/Double
key 值限制:must not contain: ‘/’ ‘.’ ‘#’ ‘$’ ‘[’ ‘]’，保留相关操作符， 用于实现原子性操作等
value 值限制:cannot be: ‘NaN’ ‘Inf’ ‘-Inf’

Client-Server 通信模型

多端同步方案

多端适配方案
Realtime DB的开发，需要适配Android，iOS，Flutter等平台

方案1 单独开发 Android、iOS、flutter 等 Realtime DB SDK 优点:原生级别性能
缺点:维护成本高

方案2 开发 Native 版本，提供 so，分别在各个端进行使用 优点:开发一套代码，可供多端使用
缺点:性能问题比较明显，多了一层native的通信，且使用不方便，各个端需要进行API适配

方案3 采用 Kotlin Multiplatform 框架进行开发 优点:一套代码，运行多端，且代码经由框架编译处理，自动编译多端产物，天然支持原生级别性能，采用Kotlin，编写简单
缺点:目前框架为alpha版本，存在未知的风险

一次编写，适配多端
Common Code:使用Kotlin实现公共逻辑，可依赖官方现有的 multiplatform支持库，实现网络、io、数据库等操作

iOS Code:可通过 CocoaPods 依赖已有的 iOS 原生库，调用原 理:框架编译期间自动根据 Objective-C/Swift 的对外接口，生成 对应的 Kt 类函数，提供外部调用

Android Code:可通过 gradle 依赖已有的 jar/aar 库，调用原理: Kotlin 和 java 的互操作性

如果有平台差异化的代码，无法直接在Common Code中实现， 可通过在Common Code中定义 expect 接口类A，在 iOS Code 和 Android Code中分别实现 actual 类A

3.4 Realtime DB 未来展望

将 Realtime DB SDK 建设成一个覆盖 iOS、Android、Flutter，甚至 JS 的中间件，采用Kotlin Multiplatform Mobile 框架，实现一套代码，处处运行的目的，为后期带来持续增益。

Realtime DB允许从客户端代码中直接安全地访问数据库，得益于此，能够构建功能丰富的协作式应用，数据会永久性地保留在客户端，即使处于离线状态，实时事件仍会继续触发，给最终用户提供良好的即时性体验。Realtime DB还处于研发阶段，对于方案选择和实现的不足之处，欢迎交流沟通或者提出优化意见或建议。

Yijun OPPO应用工程师
关注移动平台开发领域，实时数据库，Severless，Quic等技术。

获取更多精彩内容，请扫码关注[OPPO互联网技术]公众号