数据安全保障之二：容灾备份
• 规避分布式文件系统失败带来的风险 • 备份方式：整体拷贝 增量备份 • 增量备份：
– 原理：Snapshot + 增量change log – 优点：数据连续传输 – 优点：可实现异地备份 – 优点：可回溯版本的连续性
数据安全保障之二：容灾备份
WALogs Table Snapshot t0 Replay by MapReduce New Table Snapshot t t time
数据结构设计：功能需求
• 文本和附件 • 内容可随时编辑 • 支持历史版本 • 笔记可与人分享
数据结构设计：切块存储
• 基本数据结构：数据切块
文件切块 修改后 A A B B C X D Y E D F E F
– 只需要上传chunk X、Y – 回收chunk C
数据结构设计：三级索引
Entry … … userA/a:3 … … a_3: meta Meta … … a_A: <bytes> a_B: <bytes> a_C: <bytes> a_D: <bytes> a_E: <bytes> a_F: <bytes> Chunk
• 文件系统直接存取数据
(1)“冷”文件dump到文件系统 (2) 文件直接存取 (3)逐步取消chunk
性能改进计划
• 传输协议的改进调研
– HTTPS UDT – SPDY, http pipeline – CDN上传加速
• API协议改进
– 优化协议表达能力 – 批量获取API
• 改进Push机制，彻底消除轮询
大纲
• 数据与存储结构设计 • 云端基础架构设计 • 云端架构的演进 • 架构相关的特色设计 • 总结
云端架构1.0版
• 1.0版架构图
云端架构1.0版
• 1.0版特点
– 共用存储逻辑代码 – 跨进程共享锁 – 两套API直接存取数据
• 缺点和问题
– 共享锁的逻辑非常脆弱 – 异步流程导致数据一致性问题 – 架构层次不清晰
存储结构设计：性能需求
• 最频繁的操作请求？
– 同步：查新 – 列取目录 – 获取内容摘要 – 读取内容 – 修改上传
10M 1M 100K
访问次数
存储结构设计：性能需求
1G
性能优化
100B cache
1K
10K
1M 流式存取
数据结构/大小
存储结构设计:类似于SVN的版本管理机制
Entry / : 12 /notebook1 : 8 /notebook1/note11 : 7 /notebook1/note12 : 8 /notebook2 : 4 /notebook2/note21 : 4 /notebook3 : 12 /notebook3/note31 : 11 /notebook3/note32 : 12 / : 13 /notebook1 : 13 /notebook1/note11 : 7 /notebook1/note12 : 13 /notebook2 : 4 /notebook2/note21 : 4 /notebook3 : 12 /notebook3/note31 : 11 /notebook3/note32 : 12 Entry
笔记的实时数据处理能力
• 笔记内容XSS过滤 • 笔记格式的版本兼容 • 笔记发微博
基于MapReduce的后台数据处理框架
• 定义一个任务，只需实现三个接口：
– UserFilter：定义和筛选要处理的用户 – UserData Handler：选择要处理的数据 – Reducer(s)：数据处理、整合、统计
Conflict Pull(Version) Pull数据 Conflict 版本 更新 Finished
Read Lock Write Lock
用户数据回收逻辑
• 用户任何操作都不能直接删除数据
– 删除操作：增加一个“已删除”版本
• 后台异步数据回收
– 过期的历史版本 – 用户回收站的过期数据 – 没有被引用的meta/chunk
良好的可运维性
自动化测试 不停服上线 上线模拟
丰富的外围可视化工具
• 集群监控：Ganglia（/） • BI系统 • 实时监控：Vaquero • 性能监控服务
大纲
• 数据与存储结构设计 • 云端基础架构设计 • 云端架构的演进 • 架构相关的特色设计 • 总结
RPC Service Impl
RPC Service Impl
RPC Service Impl
RPC Service Impl
框架：鲁棒易用的分布式调用框架
• 实现方式：
– Java reflect – Java annotation
• 优缺点：
– 实现容易 – 使用方便 – 对使用者完全透明 – 无法支持java以外的语言
存储结构设计：切块后文件的流式读取
Chunk … a_A: <bytes> a_B: <bytes> a_C: <bytes> a_D: <bytes> a_E: <bytes> a_F: <bytes> a_X: <bytes> a_Y: <bytes>
• 切块存储破坏了文件整体结构 • 以存储序下载chunk • 客户端做数据拼接
框架：可扩展的云端架构
框架：鲁棒易用的分布式调用框架
分 布 式 调 用 框 架
RPC调用
Distribute RPC Service proxy RPC Call Switch RPC Proxy RPC Proxy RPC Proxy RPC Proxy Distribute Strategy
“存储模块”层的操作 W
W 时间轴
“数据库”层的操作 W W W
同步锁：笔记的并行修改与操作隔离
• 解决方案一：数据库的事务支持
“存储模块”层的操作 W W 时间轴 “数据库”层的操作 W W W
• 问题：
– 分布式系统事务模型复杂，逻辑脆弱 – 带来性能的损耗
同步锁：笔记的并行修改与操作隔离
• 解决方案二：在“存储逻辑”层操作上加“锁”
云端架构2.0版
• 2.0版架构图
云端架构2.0版
• 2.0版特点
– 引入RPC模块，屏蔽分布式细节 – 将存储逻辑包装成RPC服务 – API通过RPC存取数据
• 优势
– 逻辑层次清晰 – 底层对上层透明 – API轻量级
云端架构2.0版
• 云端架构2.0存在的问题
– 切块逻辑的尴尬
• 小文件切块效果不佳 • 大文件基本不修改
“存储模块”层的操作 W W 时间轴 “数据库”层操作 W W W
• 详细：
– 通过一致性哈希和分布式调用框架，分发请求到逻辑存储模块 – 保证对同一个数据的操作分发到同一个逻辑存储模块 – 在这个模块上加本地“锁”
用户级的事务支持
• 事务的实现方式：同步锁，用户版本号
Push(Version) 版本 检查 No conflict Push数据
– 存取性能的限制 – 性能瓶颈：出现在没有想到的地方
类BigTable数据库的逻辑结构
云端架构3.0版
• 异构存储，支持非切块存储
Entry … … /a:4 … … a_3: meta a_4: meta Meta … … a_3: a_4: File
分布式KV数据库
分布式文件系统
云端架构3.0版
存储结构设计：笔记存储结构
数据结构大小 User Version Entry Meta Chunk Data 100B 100B 1K 0~25M 总大小 2G 20G 400G 100T 每天访问次数 1G 0.5G 0.2G 20M Cache命中率 100% 100% 83% 0%
大纲
• 数据与存储结构设计 • 云端基础架构设计 • 云端架构的演进 • 架构相关的特色设计 • 总结
有道云笔记的特色云架构介绍
有道云笔记简介
• 多平台支持 • 自动同步，安全可靠 • 用户数已超过1500万
大纲
• 数据与存储结构设计 • 云端基础架构设计 • 云端架构的演进 • 架构相关的特色设计 • 总结
数据与存储结构设计
• 设计时要考虑的因素
– 数据结构设计：功能需求 – 存储结构设计：性能需求
Method: public abstract void Protocol.foo(ng.String,int) args: [Haha, 1001]
•使用Annotation的方式支持分布式逻辑
•指定特殊的策略支持
•此外，还可以带点AOP的味道
API：对桌面客户端的API支持
API：对桌面客户端的API支持
笔记的后台数据处理能力
• 笔记的空间回收 • 笔记图片的OCR识别 • 笔记附件的搜索支持 • 笔记内容建索引
满足数据智能化的需求
• 手写笔记的支持
– 屏幕适配与排版 – 手写笔记的二次编辑
• 自动标签服务
– 根据内容为用户推荐标签 – 根据用户行为优化推荐算法
良好的可运维性
• 上线提出 • 审批 • 准备上线 • 上线 • 回测 • 完成
总结
• 数据与存储结构设计
– 考虑功能和性能需求
• 云端基础架构设计
– 云端架构，API，同步与事务，回收
• 云端架构的演进
– 三个版本的演进
• 架构相关的特色设计
– 备份、数据处理、可运维性、可视化
谢谢！
基础设施：优质云服务的先决条件
附录