写点什么

周 6 总结 + 作业

用户头像
林毋梦
关注
发布于: 2020 年 07 月 15 日

总结



本周继续分布式系统架构的话题,涵盖分布式数据库(MySQL)和NoSQL(Cassadra,HBase),最后以Doris为例讨论了海量分布式KV存储的技术点。



分布式数据库



复制



MySQL主从复制



MySQL的主从复制是将binlog 从主服务器同步到从服务器的relay log, 然后从服务器再重做,使得主从同步。从原理上看,从服务器只能读而不能写。



优点



  • 读写分离

  • 专机专用

  • 便于冷备



缺点



  • 只有一个主,容易单点失效

  • 可能有同步延时



MySQL主主复制



MySQL的主主复制实现方式是主从之间双向binlogrelay log同步。



  1. 主1/2写入binlog,并同步到主2/1的relay log

  2. 主2/1重做relay log



两个主不能同时写。在切换时,可能有短时间数据丢失或不同步。



优点



  • 避免了写单点



缺点



  • 不能并发写入

  • 增加了同步延时



数据分片



复制并没有增加存储能力。数据分片正是为了实现存储的水平扩展——更多的机器带来更多的存储。



硬编码数据分片



应用程序中按某一个或多个维度实现硬编码数据分片。应用程序中实现数据分片路由算法。



映射表



应用程序中使用映射表而不是算法路由。映射表一般更灵活,但是对海量数据任然是个极大的负担。



挑战



数据分片一般会导致额外代码和复杂的处理逻辑,并且基本无法直接使用数据库的原生联合查询与事务。



分布式数据库中间件



中间件负责原应用中要硬编码的分片路由,连接池等职责,简化应用开发。可以分为客户端中间件和独立的中间件服务器两种方式。



数据库部署方案



  • 单一服务器

  • 一主多从

  • 分业务的一主多从

  • 分业务的一主多从和数据分片



NoSQL



CAP原理



分布式系统中一致性,可用性和分区容忍性三者不可能同时兼得,在必需分区容忍性的前提下,一致性与可用性只能二选其一。



一致性



从系统中读数据,要么返回最近一次写入的数据,要么返回一个错误,不能返回过期脏数据。



可用性



系统必须可读写,不能返回错误或不响应,但返回的数据不必是最近写入的数据,可以是过期脏数据。



分区容忍性



即使因网络原因,部分服务器节点间的消息延迟或丢失,系统任然可操作。



证明



一个分布式系统肯定会出现网络分区,任何网络的抖动和终端都可以造成节点间的通信延时和数据丢失,网络总是不可靠的,所有只能接受分区容忍性。因此,在出现分区后,只能在一致性和可用性之间二选一。因为,选择一致性,只能有一个分区是主,接受读写,而其他的分区不能再接受读写以免返回过期数据;选择可用性,那数据无法在节点间同步,于是部分分区是最新数据,而其他是过期数据,这就造成不一致了。总之,在分区存在的前提下,一致性和可用性的矛盾使得只有一个可以成立。



一个重要的事实是,并不是牺牲一个就自动获取另一个。就是说,不是所放弃一致性,就自然有可用性,或者放弃可用性就自动获得一致性。相反,常常是一荣俱荣的关系,都比较好,或都不好,只是不能同时全部完美。



冲突解决



CAP原理下,为保证一致性,常常要解决数据冲突。常见方式有两种。



数据冗余



数据写入时同时写入多个节点,当部分节点不可用时,采信多数节点的数据。



最终一致



数据通过消息队列,relay log,客户端合并等达到最终一致。



ZooKeeper



脑裂



在分布式系统中,服务器间的冲突会导致脑裂,即出现分区并各自决策,保持不一致无法调和。



共识算法



共识算法保证分布式系统中的服务器可以达成一致的共识,即对同一个请求给出相同的返回值。最初,也是唯一经数学证明的共识算法是Paxos算法,以及原作者在微软完成的Fast Paxos。后来相继出现了Raft和ZAB算法,是对Paxos的简化,经多年实践检验可行,但没有数学证明。另一共识算法,就是区块链用的POW共识算法,但是POW是去中心化的算法,要极大代价。



Paxos



也成为三阶段共识算法,在分布式系统中解决拜占庭将军问题,即在节点通信可能出现重复,丢失,和篡改的条件下达成共识。Paxos算法中弱化了篡改条件,即通信可能重复和丢失,但不会被篡改。



  1. 发起者提出提案

  2. 多数决策者接受提案

  3. 确认,并强制所有学习者接受提案



Raft



三状态机共识算法。任何一个节点总是flower, candidate, leader三者之一。leader负责发送心跳,当follow一段时间没有收到心跳就转换成candidate,然后发起提案,当收到多数确认后转成leader,或是选取更高编号的节点做新leader,自己转成follower。



ZAB



ZooKeeper的共识算法。leader发起提案,follower入队并应答,若多数同意,leader就要求commit,而follower收到commit后,只有ID是等待队列中最小一个时才执行,不然就入队并等待条件成立。



作业



CAP原理



见前面CAP原理一节



Doris临时失效处理



发布于: 2020 年 07 月 15 日阅读数: 52
用户头像

林毋梦

关注

还未添加个人签名 2018.08.25 加入

还未添加个人简介

评论

发布
暂无评论
周6总结+作业