共计 2583 个字符，预计需要花费 7 分钟才能阅读完成。
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 框架，实现一套代码，处处运行的目标，为前期带来继续增益。
4. 总结
Realtime DB 容许从客户端代码中间接平安地拜访数据库，得益于此，可能构建功能丰富的合作式利用，数据会永久性地保留在客户端，即便处于离线状态，实时事件仍会持续触发，给最终用户提供良好的即时性体验。Realtime DB 还处于研发阶段，对于计划抉择和实现的不足之处，欢送交换沟通或者提出优化意见或倡议。
作者简介
Yijun OPPO 利用工程师
关注挪动平台开发畛域，实时数据库，Severless，Quic 等技术。
获取更多精彩内容，请扫码关注 [OPPO 互联网技术] 公众号
