架构师训练营第 6 周——学习总结

用户头像
在野
关注
发布于: 2020 年 07 月 13 日
架构师训练营第 6 周——学习总结

本周学习了NoSQL、ZooKeeper以及Doris的相关知识。

1、NoSQL

CAP



CAP定理指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

  • Consistency(一致性):读操作一定能读到最新的值。

  • Availability(可用性):一个用户请求一定能收到响应。

  • Partition tolerance(分区容错性):分布式系统分布在多个子网络中,当部分子网络出现故障时,分布式系统依然能提供最初设计的一致性或者可用性服务。

任何分布式系统只可同时满足二点,没法三者兼顾。

BASE

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写。



BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的结论,是基于CAP定理逐步演化而来的,其核心思想是即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

  • 基本可用:指分布式系统在出现不可预知故障的时候,允许损失部分可用性。注意,这绝不等价于系统不可用,以下两个就是“基本可用”的典型例子:

  • 响应时间上的损失:正常情况下,一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果,但由于出现异常(比如系统部分机房发生断电或断网故障),查询结果的响应时间增加到了1~2秒。

  • 功能上的损失:正常情况下,在一个电子商务网站上进行购物,消费者几乎能够顺利地完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面。

  • 弱状态:也称为软状态,和硬状态相对,是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

  • 最终一致性:强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

2、ZooKeeper

ZooKeeper是一个分布式服务协调框架,提供了分布式数据一致性的解决方案。分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

ZK服务器

3种角色

  • Leader

  • 1、事务请求的唯一调度和处理者,保证集群事务处理的顺序性

  • 2、集群内部各服务的调度者

  • Follower

  • 1、处理客户端的非事务请求,转发事务请求给 Leader 服务器

  • 2、参与事务请求 Proposal 的投票

  • 3、参与 Leader 选举投票

  • Observer

  • 1、3.0 版本以后引入的一个服务器角色,在不影响集群事务处理能力的基础上提升集群的非事务处理能力

  • 2、处理客户端的非事务请求,转发事务请求给 Leader 服务器

  • 3、不参与任何形式的投票



四种状态,分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。

  • 1、LOOKING:寻找 Leader 状态。当服务器处于该状态时,它会认为当前集群中没有 Leader,因此需要进入 Leader 选举状态。

  • 2、FOLLOWING:跟随者状态。表明当前服务器角色是 Follower。

  • 3、LEADING:领导者状态。表明当前服务器角色是 Leader。

  • 4、OBSERVING:观察者状态。表明当前服务器角色是 Observer。

会话管理



  1. 客户端会不时地向所连接的ZkServer发送ping消息,ZkServer接收到ping消息,或者任何其它消息的时候,都会将客户端的session_id,session_timeout记录在一个map中。

  2. Leader ZkServer会周期性地向所有的follower发送心跳消息,follower接收到ping消息后,会将记录session信息的map作为返回消息,返回给leader,同时清空follower本地的map。 Leader使用这些信息重新计算客户端的超时时间。

  3. 一旦在session timout的时间到,leader即没有从其它follower上收集到客户端的session信息,也没有直接接收到该客户端的任何请求,那么该客户端的session就会被关闭。

数据模型

每一个节点都是znode(兼具文件和目录两种特点),每一个znode都具有原子操作。znode存储的数据大小有限制(默认1MB),通过绝对路径引用。 znode分为3个部分:

  • stat:状态信息,描述znode的版本和权限等信息。

  • data:与该znode关联的数据。

  • children:该znode下的子节点。

四种形式的目录节点

  • PERSISTENT:持久的节点。

  • EPHEMERAL:暂时的节点。

  • PERSISTENT_SEQUENTIAL:持久化顺序编号目录节点。

  • EPHEMERAL_SEQUENTIAL:暂时化顺序编号目录节点。

ZAB 协议

ZooKeeper 保证分布式系统数据一致性的核心算法就是 ZAB 协议(ZooKeeper Atomic Broadcast,原子消息广播协议)消息广播崩溃恢复数据同步三个过程。

缺点

  • 非高可用:极端情况下zk会丢弃一些请求:机房之间连接出现故障。

  • zookeeper master只能照顾一个机房,其他机房运行的业务模块由于没有master都只能停掉,对网络抖动非常敏感。

  • 选举过程速度很慢且zk选举期间无法对外提供服务。

  • zk的性能有限:典型的zookeeper的tps大概是一万多,无法覆盖系统内部每天动辄几十亿次的调用。因此每次请求都去zookeeper获取业务系统master信息是不可能的。因此zookeeper的client必须自己缓存业务系统的master地址。

  • zk本身的权限控制非常薄弱。

  • 羊群效应: 所有的客户端都尝试对一个临时节点去加锁,当一个锁被占有的时候,其他的客户端都会监听这个临时节点。一旦锁被释放,Zookeeper反向通知添加监听的客户端,然后大量的客户端都尝试去对同一个临时节点创建锁,最后也只有一个客户端能获得锁,但是大量的请求造成了很大的网络开销,加重了网络的负载,影响Zookeeper的性能。

  • 脑裂:由于假死会发起新的leader选举,选举出一个新的leader,但旧的leader网络又通了,导致出现了两个leader ,有的客户端连接到老的leader,而有的客户端则连接到新的leader。

3、Doris

Doris是淘宝内部开发的一个海量分布式KV存储系统,支持线性伸缩能力和更好的用户管理界面。

4、总结

学的知识越多,压力越大。因为面对浩瀚的知识,突感到个人能力的渺小,尤其是学了新的,前面的又忘了很多。



学完这些知识后,等有时间了,还需要好好整理和理解一番。



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

在野

关注

还未添加个人签名 2012.03.11 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第 6 周——学习总结