王超 - Bada构建主从去中心混合架构的NoSQL

回雅秀

2018/05/13 发布于 技术 分类

在分布式NoSQL遍地开花的今天,我们为何要自主研发?如何选择从开源软件过渡到自主研发的时机?在设计时,我们参考中心化和去中心架构的特点,根据自身业务场景进行了融合,从延迟、一致性、集群伸缩方面做了权衡;面对新的混合架构,我们遇到了一些前所未有的挑战,又是如何一一解决和优化的?历经三个月的研发,一年多的线上改进,成功解决了当时面对的问题且得到了广泛认可,架构的优劣和可借鉴性由各位思考

文字内容
1. Bada 构建主从/去中心 混合架构的NoSQL
2. 概要 • 背景介绍 - 百亿数据的困惑 • 混合架构设计的考虑 • 新架构?新挑战! • 经验总结
3. 背景介绍 - 业务架构
4. 背景介绍 – 原有方案 • (File / File Block) Deduplication – MongoDB v2.0/2.2/2.4 – Mongos + Mongod(Primary 1 + Secondary 2) – 144G RAM + 300G SSD * 5 – 12 servers / IDC, 20+ IDC
5. 背景介绍 – 原有方案 • 百亿数据面临的问题 – Bson 数据膨胀率高 – 扩展节点周期长 – 延迟不稳定:Thread -> DB锁 – 数据可靠性低, 主从切换数据丢失
6. 混合架构设计的考虑 • 新的方案? – 延迟低、稳定 – 膨胀率低 – 节点伸缩效率高
7. 混合架构设计的考虑 • 延迟低、稳定 – 磁盘介质:SSD – 存储引擎:LevelDB / RocksDB – 网络模型:Erlang OTP – 副本机制:Primary & Secondary
8. 混合架构设计的考虑 • 膨胀率 – LevelDB:snappy – RocksDB:snappy, zlib, bzip2, lz4, lz4_hc
9. 混合架构设计的考虑 • 节点伸缩 – 迁移最小粒度partition – LevelDB Instance/partition
10. 混合架构设计的考虑 • 分布式系统关键要素 – 路由策略 – 副本策略 – 一致性 – 容错
11. 混合架构设计的考虑 • 路由策略 – 两级映射 • 优点: – 算法简单 – 节点伸缩负载均衡
12. 混合架构设计的考虑 App s Hash Function (KEY) Mapping Relation vP1 vP2 vP3 K-V vP4 vP5 vP6 NODE A NODE B NODE C Server 1 Server2
13. 混合架构设计的考虑 • 副本策略: – Primary + Secondary * 2 – 扩容、Binlog复制以 Partition为单位 – partition、主副本均匀 分布在所有Node • 优点 – 读写单副本,延迟低 – 节点伸缩效率高 – Binlog并发复制 – 数据节点负载均衡
14. 混合架构设计的考虑 Partition 5 Partition 4 NODE 1 PRIMARY Partition Partition 5 3 Partition 2 NODE 2 PRIMARY Partition Partition 4 6 Partition 7 NODE 3 PRIMARY Partition Partition 1 8 Partition 9 SECONDARY Partition Partition 4 6 Partition Partition 1 7 Partition Partition 8 9 SECONDARY Partition Partition 9 5 Partition Partition 3 1 Partition Partition 2 9 SECONDARY Partition Partition 7 4 Partition Partition 6 3 Partition Partition 5 2 Partition 1
15. 混合架构设计的考虑 • 一致性 – 最终一致 – 读写主副本,多数情况下一致性强
16. 混合架构设计的考虑 • 容错: – 选举 N/2+1 – 最大 gopid(serverID, opid, timestamp) – 每组partition之间投票
18. 新架构?新挑战! • 问题:主从架构异步复制存在数据丢失 – 网络故障 – 服务器、机柜维护
19. 新架构?新挑战! Secondary Primary Primary 1 2 Primary Secondary 3
20. 新架构?新挑战! • 解决 – Binlog Merge
21. 新架构?新挑战! Secondary Primary Primary 1 2 Primary Secondary Primary Secondary 3 4 +=
22. 新架构?新挑战! • 优化 – 高效的查找同步点 • 批量发送,二分查找 – 如何最快恢复服务 • 对key排序,只回放最后一次操作 – 保持多副本binlog文件一致 • Secondary binlog 删除重做
23. 新架构?新挑战! • 问题:多partition引发的选举风暴 – 无谓的网络、CPU消耗 • 解决: – 广播 -> 多播 – 优化选举时机
24. 新架构?新挑战! • 问题:主副本不均衡 – CPU、网络、I/O倾斜 NODE 1 PRIMARY Partition 5 Partition 3 • 解决: – 自动主平衡算法 – 要求最小步数, changeprimary 最小影 响 Partition 2 Partition 4 Partition 1 Partition 6 SECONDARY Partition 7 Partition 8 Partition 9 NODE 2 PRIMARY Partition 7 SECONDARY Partition 4 Partition 6 Partition 9 Partition 5 Partition 3 Partition 1 Partition 2 Partition 9 NODE 3 PRIMARY Partition 9 Partition 8 SECONDARY Partition 1 Partition 7 Partition 4 Partition 6 Partition 3 Partition 5 Partition 2
25. 经验总结 • 业务需求出发 • 选择开源方案 • 设计尽可能简单 • 小步快跑 • 单元、集成、沙盒测试 • 灰度上线,预案就绪
26. WEIBO: @Chancey MAIL: chanceycn@gmail.com GITHUB: https://github.com/Qihoo360