2019年饿了么自研分布式KV数据库的架构与实践.pdf

《2019年饿了么自研分布式KV数据库的架构与实践.pdf》由会员分享，可在线阅读，更多相关《2019年饿了么自研分布式KV数据库的架构与实践.pdf（29页珍藏版）》请在三个皮匠报告上搜索。

1、饿了么自研分布式KV数据库的架构与实践Agenda历史与需求核心特性选择和对比架构简介架构设计中的权衡未来的规划历史MySQL+RedisMySQLNoSQL(Redis,Cassandra,MongoDB,Hbase)MySQLNoSQL(Redis,EKV)需求 痛点 海量的、持久化的数据存储 对于我们自己 统一NoSQL使用、统一运营、降低成本、适用多种场景 对于我们的使用者 简单易用 其他需求点 数据可靠、服务稳定、高性能、低维护成本Agenda历史与需求核心特性选择和对比架构简介架构设计中的权衡未来的规划小调查 什么是强一致性？你认为数据库需要强一致性吗？What is EKV我们我

2、们EKV是一个强一致性数据库是一个强一致性数据库选择强一致 未来的方向 MySQL 从v5.7开始，支持Group Replication，采用Paxos MongoDB 从v3.4开始，支持类Raft复制协议 Hbase 类似于BigTable/GFS*NewSQL Spanner,TiDB,CockroachDB等数据库采用Paxos或Raft 除元数据存储以外，越来越多的数据库采用类Paxos算法 越来越多的数据库采用强一致性*从 GFS 失败的架构设计来看一致性的重要性，陈东明，https:/ 对比三个典型系统 MySQL Redis CassandraMySQL MySQL 主备异步

3、复制 非强一致性的（在出现故障时）Lost data 使用建议 Strong DBA for failover Carefully programming with slave node 架构经验异步复制不能保证强一致异步复制不能保证强一致Redis Redis 异步复制 WAIT指令，同步复制 副本不一致（即便使用WAIT）非原子 使用建议 WAIT不应该成为一个对外暴露的API Carefully programming with WAIT 架构经验同步复制不能保证强一致同步复制不能保证强一致Cassandra/Dynamo WRN策略 Quorum(W+RN)副本不一致 Stale Re

4、ad 并发冲突 如何解决副本不一致？再读一次（试试运气）Read Repair Replica synchronizationCassandra/Dynamo 冲突解决 Last Write Win Clock skew（或者叫时钟不同步）Cassandra/Dynamo-最终”正确”一致性 Cassandra/Dynamo 最终一致性（任何情况下，即便W+RN）使用建议 放在无需数据正确性的场景 或者做好补偿措施 架构经验 W+RN不能保证强一致性不能保证强一致性 在并发或者故障时最终一致性最终一致性保证最终正确的一致性保证最终正确的一致性使用强一致的原因 数据正确性 一致性本质上是并发问题

5、和故障处理问题 低开发成本 易懂 易用 易维护 让开发这个事更方便，解放开发者Agenda历史与需求核心特性选择和对比架构简介架构设计中的权衡未来的规划架构 分片(Sharding)海量数据存储海量数据存储Paxos多副本（高可靠高可靠）大多数原则Fault-tolerant（高可用高可用）强一致性强一致性其他功能 多数据模型 Structured KV模型 Integer String Sorted Hash(稀疏大表)Redis模型 异地多活 水平扩容Agenda历史与需求核心特性选择和对比架构简介架构设计中的权衡未来的规划是否有这样的疑虑 强一致性的系统可用性不好？强一致性的系统性能不好

6、？强一致vs.可用性 CAP定理 Availability，指的是100%绝对可用（任何时间，哪怕只剩一个节点）CAP定理不适用Paxos Paxos容忍少数宕机，虽然没有达到完全可用，但仍然很高的可用性 需要绝对可用的架构设计吗？不,需要是实际的高可用实际的高可用,Effectively CA*，*Google的强一致系统达到99.99958%的实际可用性 网络分区并是不可用的主要原因，架构选择可用性架构选择可用性实际获得高可用实际获得高可用*Spanner,TrueTim