Recomendados
Más contenido relacionado
Similar a 李战怀：大数据背景下分布式系统的数据一致性策略
Similar a 李战怀：大数据背景下分布式系统的数据一致性策略 (20)
Más de hdhappy001
Más de hdhappy001 (20)
李战怀：大数据背景下分布式系统的数据一致性策略
- 4. 数据一致性 什么是数据一致性? Data consistency summarizes the validity, accuracy, usability and integrity of related data between applications and across an (IT) enterprise - Wikipedia
- 5. 大数据对一致性的影响—硬件基础的变化 • 新型存储器件的出现使计算机存储结构发生了变化 • 相变存储器（PCM），磁阻式随机存储器（MRAM）和电阻式随 机存储器（RRAM） 等新型存储级内存(storage class memory, SCM ) ，SSD等 • 新的机遇与挑战 • 内容容量大幅增长，具有了存储和管理海量数据的能力，使得基于 内存进行事务处理成为可能 • 数据访问特征的变化：并发性大幅提高，维护一致性的并发控制难 度增大 • 存储特性的变化：如 SSD读写代价不对称 • 多级缓存持久化引发 更复杂的一致性问题 内存墙导致多级缓存的引入
- 6. 大数据对一致性的影响—硬件基础的变化 Useful Work 4% • 芯片的发展 • 芯片发展遇到功耗墙、频率墙等问题；处理器 也在经历单核到多核众核的发展，并出现 多核/多处理器共享缓存的新架构 功率墙导致众核处理器的出现 Latching 24% Recovery 24% Locking 24% Buffer Pool 24% MySQL在多核上的吞吐量 • 问题与挑战 • 多核导致共享数据结构访问竞争的可能性增大，传统的锁、日志、 事务管理器在多核上的扩展性不佳，维护一致性的开销更昂贵，需 要设计针对多核的并发控制机制，减少lock或latch contention
- 7. 大数据对一致性的影响—应用需求的变化 Web 2.0 高可用/扩展性对一 致性的影响 事务低响应时间 非关系型数据 移动设备网络 数据处理新需求 OLAP & OLTP 实时分析 事务与分析的融合对 一致性的影响 无线通信的不可靠性对 一致性的影响 随时，随地事务处理 事务处理量增加 数据实时、多样 云计算 大数据时代阶石 传统事务原则矛盾 廉价集群环境对一致性 的影响
- 8. 回顾：RDBMS中的一致性 • 一致性是数据最关键的属性之一 • 关系数据库建立之初就是为应对“大数据”的管 理问题，特别是并发操作的数据一致性问题。 • 强一致性是传统关系数据库提供的一致性模型， 也是关系数据库成功应用在多个关键领域的重要 原因，关系数据库通过事务机制保证强一致性。 All or Nothing Action Action 增加销售者账户里资金 减少购物者账户里资金
- 9. RDBMS中维护强一致性的事务机制 • 单事务执行 • 所有数据库都有一致性约束，需要事务能够保证数据库的一致性 • 事务的ACID特性：AID->C • 多事务并发 • 事务并发执行有破坏数据库一致状态的风险，需寻找保证一致性 的并行执行序列 • 冲突可串行化或视图可串行化且的调度可保证一致性 • 需要通过多种并发控制机制（调度器）保证调度的可串行化
- 10. 维护强一致性的代价 • RDBMS采取强一致性策略具有较高的开销 • 对一致性要求较弱的应用支付了不必要的开销 论坛需要强一致吗？ 微博需要强一致吗？ 图书描述信息需要强一致吗？ 火车票库存信息需要强一致吗？ … OLTP Through the Looking Glass, and What We Found There. S. Harizopoulos, D. Abadi, etc. ACM SIGMOD 2008.
- 11. RDBMS在大数据背景下的掣肘 • 大数据的新挑战和RDBMS的掣肘： 可扩展性问题：大数据的Volume维度对系统的可扩展 性提出了更高的要求（ scale-up VS. scale-out） 有限的数据支持类型： 大数据的Variety维度极大增加 了数据分析处理的难度（半结构乃至非结构化数据） 较低的处理速度：大数据的Velocity维度使数据产生速 度与分析结果产生速度两者之间不匹配的矛盾加剧 硬件依赖问题：昂贵的高性能大机(中小规模专用集群) VS. 廉价的大规模普通PC集群
- 13. 分布式系统中副本的一致性问题 • 分布式系统使用副本的主要原因 提供高可靠性/可用性：避免单点失效 提供高性能：避免单节点过载成为瓶颈 提供基于本地副本的快速访问：避免通信延迟与失败 (注：同时副本也带来了更复杂的一致性问题）
- 14. 数据一致性模型 • 常见的几种一致性模型 • 强一致性：数据被成功更新后（无论是在哪个副本上 ），后续任何对该数据的读取操作都得到最新的值 • 弱一致性： 存在”不一致性时间窗口”概念，且能容 忍后续的部分或者全部访问不到更新过的数据 • 最终一致性：属于弱一致性的一种特例，系统确保最 终所有访问都将得到更新后的数据 • 客户端关注：多并发访问时如何获取更新过的数据 • 服务端关注：如何在小的时间窗口内将更新传播到整个系统中 • 最终一致性的其他变体 • • • • • 因果一致性Causal consistency 会话一致性Session consistency 读自写一致性Read-your-writes consistency 单调读一致性Monotonic Read consistency …
- 15. 倾向最终一致的模型—BASE模型 • BASE模型（思想） • ACID的反模型，牺牲高一致性，获得高可用性扩展性 • ACID强制保证每一个操作完毕后的一致性，而BASE接 受该数据库的一致性可能在一定时间内处在不确定的 状态中 • Basically Available：基本可用，容忍分区失败 • Soft state：软（柔性）状态，状态可以有一段时间不 同步，异步 • Eventually consistent：最终一致 ACID BASE
- 16. 一致性控制技术概览 • 本地（集中）并发控制 • • • • 锁技术：两阶段封锁协议 时标（Timestamping）技术：时间戳排序协议 有效性检查机制 多版本机制 • 分布式并发控制 中心化协议 代表：Primary-Copy机制 优点：简单，将问题转化为对主副本的集中并发控制问题 缺点：单点故障、高延迟 去中心化协议 代表：Paxos协议（实现：ZooKeeper Chubby ） 优点：灵活 缺点：控制复杂
- 17. 一致性相关技术和策略—NWR策略 • NWR模型 [Werner Vogels] • • • • N：数据复制的份数 W：数据更新完成前需要到达的节点数 R：为了读取正确数据需要读取的节点数 为保证不同副本中的数据一致性采用类似Quorum系 统的一致性协议 • 若满足W+R > N，那么读写节点有重叠，读总是能够得到最 新的数据，系统可保证强一致性 • 若满足R + W ≤ N，这时读取和写入操作是不重叠的，系统只 能保证最终一致性 • R和W的设置直接影响系统的性能、扩展性与一致性 • R和W的值如较小会影响一致性，较大则会影响性能，这两个值的设置需 要权衡 Eventually Consistent - Revisited, By Werner Vogels on Decembe
- 18. 一致性相关技术和策略—Paxos算法 Google Chubby 的作者Mike Burrows：“There is only one consensus protocol, and that's Paxos”-all other approaches are just broken versions of Paxos • Lamport提出的Paxos是一种基于消息传递的一致性算法 ，主要解决分布式环境下的“一致性”问题 • 在不同的上下文中“一致性”有不同的解读 ① 数据库领域：强调系统中所有的数据的状态一致 ② NoSQL领域：强调读写一致性（能读到最后写入的数据） ③ 状态机：强调在初始状态一致的状态机上执行相同的序列操作 后，每个状态机的状态须保持一致，即顺序一致性 • Paxos算法中的“一致性”对应第③种含义 Lamport, The part-time parliament,1998、Paxos made simple, 2001.
- 19. 一致性相关技术和策略—Paxos算法(续) • Paxos算法在分布式存储系统中的应用 • 分布式存储系统的一致性 • 采用多副本（高容错）进行可更改数据的存储 • 多个副本须执行相同的更新操作序列[op1, op2, …, opm] • Paxos算法用来确定一个变量(opi )的取值 • 取值可以是任意binary • 取值具有不可变性和可读取性 • 以此保证副本执行完全相同的操作序列进而维护一致性 • Google的Chubby，Megastore，Spanner，以及 Yahoo的Zookeeper中都采用了此算法对副本更新序 列达成一致 • Paxos算法不仅可在分布式系统中应用，凡是多个过程 需要达成某种一致性的情况都可以使用Paxos算法 Lamport, The part-time parliament,1998、Paxos made simple, 2001.
- 20. 一致性相关技术和策略—两阶段提交 • 两段提交协议（2 Phase Commit，2PC） 2 2 准备提交/准 备废弃 预提交 1 3 全部提交/全 部废弃 废弃 3 1 4 决定阶段 Ack 1 4 执行阶段 协调者 参与者
- 21. 一致性相关技术和策略—其他 • 时间戳策略 • 时间戳策略可用于SNA架构或并行架构系统中时间及 数据的同步（便于区分不同节点中数据的版本信息） • 向量时钟 • 是一种在分布式环境中为各种操作或事件产生偏序值 的技术，它可以检测操作或事件的并行冲突，用来保 持系统的一致性 • … 注：很多系统甚至采用多种策略结合的方式来维护 数据一致性 Lamport, The part-time parliament,1998、Paxos made simple, 2001.
- 23. CAP原理与一致性 • 关系数据库领域 -ACID • • • • • 分布式领域 -CAP 原子性(Atomicity ) 一致性(Consistency ) 隔离性(Isolation) 持久性(Durability) • 一致性 (Consistency) • 高可用性 (Availability ) • 分区容忍性 (Tolerance of network Partition ) 前提：对于分布式系统，P 是必须满足的限制条件 “ CAP theorem, which states that of three properties one can only achieve two at any given time. ” CP：提供一致性保证 AP：提供可用性保证 Consistency Safty Availability Liveness 注：单点运行的RDBMS是 典型的CA系统 三选二：实现原子性读写服务的存在分区倾向的系统不能同时保证系统的安全性和活性 Ref: Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”
- 24. CAP的权衡思考 • 在分区必然存在的前提下，系统设计只能在数据 一致性和可用性间进行不同程度的权衡 • 即在限定P的条件下，选择PC或PA • C和A是对系统服务的要求，而P是系统的客观状态 P是系统常态还是少数发生的情况 C与A的取舍是架构级的还系统内部的 P、C与A是互斥还是合力 More?
- 25. CAP原理的反思 • 不同的声音1 • Errors in Database Systems, Eventual Consistency, and the CAP Theorem. Michael Stonebraker. • CAP/BASE理论中牺牲C来换取AP是不可取的，原 因在于导致P问题发生的场景并不常见 • 且在某些情况下，牺牲C也还是很难保证AP • • • • 1. Repeatable DBMS errors 2. hardware failure 3. Disaster etc. 注： 1和3会导致系统始终处于错误状态，系统必然不可用 3会导致节点失效并可以视为产生分区的特例
- 26. CAP原理的反思 • 不同的声音2 • Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story. [IEEE Computer] Daniel Abadi. • CAP没有将Latency考虑进来 • 换个角度，P可以视为对通信的时限（ Latency ） 要求，即系统如果不能在时限内达成数据一致性， 就意味着产生了分区 • 新的推论 • 分区并不是整个系统的一种例外（仅部分节点检测到了分区） • 检测到分区的节点可进入分区模式，其他节点保持可用与一致 • 因此，除了在C和Ａ之间权衡，还须在 Consistency 和 Latency 之间权衡（PACELC）
- 27. CAP原理的反思—PACELC It is not merely the partition tolerance that necessitates a tradeoff between consistency and availability; rather, it is the combination of · partition tolerance and · the existence of a network partition itself As soon as a DDBS replicates data, a tradeoff between consistency and latency arises. Ignoring the consistency/latency tradeoff of replicated systems is a major oversight, as it is present at all times during system operation. From: Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story PA/EL Dynamo, SimpleDB, Cassandra,CouchDB PC/EC ACID compliant database systems PA/EC GenieDB others … 系统设计的时候需要进 行各式各样的权衡，这 并不是一个简单的CAP 或者PACELC就能够解 决的，需要按需决策。
- 28. 有关于“P”的新观点和策略 • 新观点 • 大规模集群中P是常态；中小规模集群中P发生概率很小 • 不发生或者发生P概率很小的集群可视为CA cluster（理想环境， 视分区出现的可能性要比其他的系统性错误（如自然灾难、并发 故障）还要低），但构建CA cluster并不是一件容易的事情 • 更好的策略 • 当分区很少出现时：系统允许完美的C和A • 当分区存在或可感知其影响的情况下：预备一种策略去探知分区 并显式处理其影响（典型处理步骤如下） • 步骤1：探知分区发生 • 步骤2：进入显式的分区模式以限制某些操作 • 步骤3：启动恢复过程以恢复数据一致性并补偿分区期间发生的错误 Ref. cap twelve years later: how the rules have changed
- 30. 系统设计时的一致性权衡 • CAP在12年前被提出，大数据背景下各种环境发生了极大 的变化，系统设计的权衡因素也越发复杂 • 一致性与可用性 高可扩展性 一致性 高可用性 • 一致性与扩展性 高度容错性 ... • 一致性与延迟 • 一致性与持久化 • 一致性与故障转移、恶意攻击、… We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions. --from: http://www.infoq.com/news/2012/10/google-spanner
- 31. 设计策略概览 • Best-effort availability • 保持一致性 • 典型技术：分布式锁（chubby） • Best-effort consistency • 保持高可用性 • 典型技术： Web caches • Balancing consistency and availability • 动态的平衡系统的一致性与可用性 • 典型技术： TACT（ Tunable Availability and Consistency Tradeoffs ） • Segmenting consistency and availability • 系统没有单个统一的需求，不同组件使用不同的可用性和一致性，策略与给定应 用和分区方式有关 • Data partitioning：不同数据有不同的需求（如购物车数据、账单数据） • Operational partitioning：不同操作有不同需求（如浏览、购买） • Functional partitioning：不同功能有不同需求（如结算、DNS、内容分发） • User partitioning：不同区域的用户有不同需求（如大众点评、 Craigslist ） • Hierarchical partitioning：不同层级有不同需求（如root， leaves）
- 32. VoltDB • VoltDB是一个支持ACID特性的、高可扩展的，share nothing架构 的分布式内存数据库，是最具代表性的NewSQL数据库产品（兼具传 统RDBMS的ACID模型和NoSQL所需的高可扩展性） • 保持数据一致性的基本思想 所有修改操作在每一个副本上单独更新 • 如何保证副本上更新次序的一致性? 依赖于集群内所有节点具有一致的时间（节点间时间差<节点间Round Trip） 系统为每次事务的调用分配一个全局有序的时间戳 服务器需要等待Round Trip时间后，确认没有其他机器执行比自己更早 的事务时，才开始执行自己的事务 这种方式保证了集群内多台节点间事务的有序，因此多个副本的更新操 作也是以相同顺序进行修改的，也即所有副本之间保证了一致性 D. J. Abadi, "H-Store: a High-Performance, Distributed Main Memory Transaction Processing System,"
- 33. FoundationDB • FoundationDB也是一个保证了ACID，同时还具有通常只有NoSQL 数据库才有的高性能和可用性的NewSQL类数据库 • FoundationDB维护一致性的方式： • 构建一个分布式的、完全一致的数据库非常困难，因此其采用了对 NoSQL而言非传统的方式在网络分区间维护一致性 • 其使用不同的服务器担当不同的角色简化了处理，主要是：事务服务器 和存储服务器 • 事务服务器负责检测冲突，以保证ACID。存储服务器负责存储大量的有 序键-值对，并为事务服务器批准的读写请求提供服务 • 核心思想：其将事务处理分解为独立的可扩展的子功能 • batching incoming transactions • checking transaction conflicts • logging transactions • durably storing the data
- 34. OceanBase [taobao] • 动机 • 源于淘宝自身数据的特点和应用需求 • 数据量大但修改量较小，一千亿 * 1%* 100B = 100G • 需要有效的区分最新修改的增量数据和以前的基准数据 • 查询事务较多，写事务相对较少，但要求一致性强和高实时性 • 特点 • OceanBase = transactionality + scalability • 数据 = 基准数据+增量数据（数据分类并分离） • 增量数据(增删改)：单机，内存+SSD • 基准数据：多机，分布式B+树（类似BigTable） • 读写分离的偏向于CA特性的高可用性高扩展性的系统 • 支持跨行跨表事务：集中化单机写事务+分布式读事务（读写事务 分开） • 支持强一致性：本地实时同步，异地准实时同步
- 36. 系统设计的一致性philosophy • 不同领域对不一致性的容忍程度是不同的，容忍程度是系 统设计时的重要考量因素 • 有很多场景甚至也可以用优雅的外部方式处理不一致性带 来的问题（与领域相关并需要领域知识） • 典型用例1：旅店预订 • 有overbooking的需求（防止退订） • 有非技术上的解决机制：upgrade maneuvering room… • 典型用例2：ATM • 风险可控情况下可用性可能比一致性重要：高可用性意味高收益 • 存在违反不变性约束的可能：余额应大于或等于零 • 有非技术上的解决机制：限制净取款额度补偿性处理法律行动…
- 38. 大数据环境下数据库技术的发展趋势 Hierarch DB/ Network DB RDBMS Object Databases RDBMS OLAP and Cubes RDBMS NoSQL NewSQL RDBMS today New Voice Always be there time
- 40. Consistency or not：is up to you • 数据处理系统对一致性的需求始终存在 • 多样化的需求，多样化的选择 • 大数据背景下一致性存在多种选择，不同的应用场景 适用不同的一致性，没有最好只有最适合 • 企业级应用对于强一致性的需要将长期存在 • 未来甚至可以会出现混合一致性（多种一致性共存， 甚至存在于一个应用中） William Shakespeare：People‘s controllable and own destiny，if our under the yoke of person, that doesn't in the destiny is wrong and is at ourselves Consistency Is Key