大数据

Hadoop

  • NameNode和DataNode,在存储数据的时候会将数据进行切块,为了防止产生数据丢失,会将数据进行备份,称为副本-replication在Hadoop中默认的副本数为3
  • 在存储数据过程中会将数据进行切块(分片)每一个块称之为Block
  • Block是HDFS的基本存储单位
  • 可以修改块的大小,在HDFS中会对Block进行编号
  • 将数据切块的意义:便于存储超大的文件、便于进行快速备份
  • 元数据包括:记录数据的虚拟存储路径、记录文件的切块数量、记录数据块的存储位置、记录数据块的副本数量、记录文件的权限
  • 元数据的大小是150B左右
  • NameNode将元数据维护在内存及磁盘中,在内存中是为了快速查询
  • 元数据放在磁盘中是为了崩溃恢复
  • NameNode也是先写磁盘再写内存,同步的操作,修改完之后会给客户端返回ack
  • 在HDFS中会给每一次的写操作分配一个事务ID:txid
  • 当edits文件到达条件的时候会将操作更新到fsimage文件中
  • HDFS的核心是NameNode在后面的版本中允许设置多个NameNode
  • 默认情况下DataNode每隔3s给NameNode发送一条信息
  • 心跳的超时时间是10min,并会维持副本的数量
  • NameNode重启的时候将edits中的更新操作更新到fsimage中将fsimage中的元数据加载到内存中,等待DataNode的心跳,这个过程叫做安全模式,如果所有的校验都成功则HDFS会自动退出安全模式
  • 在伪分布式情况下,副本数量必须为1,如果副本数量不为1则重启NameNode的时候会一致处于安全模式
  • HDFS中默认副本数量为3
  • 分布式带来的问题:节点之间需要沟通,管理节点的单点故障、选主算法、死锁分布式锁

zookeeper

  • zookeeper本身是一个树状结构znode,每个节点称为znode节点
  • znode树维护在内存中以及磁盘中
  • 在zk中有事务的概念,每一次写操作会分配一个全局的递增编号称为zxid
  • 基本命令:

在这里插入图片描述

在这里插入图片描述

  • 选举机制:

当zookeeper集群启动的时候,自动选出一个leader其他节点成为follower

  • 选举细节也是广播一个权重,谁大谁是leader
  • 多个leader称为脑裂问题,存活节点过半集群停止对外服务
  • 一般设置节点为奇数个
  • ZAB:zk自动广播协议,是专门设计的协议,基于2PC算法进行改进又引入了PAXOS算法
  • 功能:原子广播和崩溃恢复
  • 两阶段提交核心思想是先准备阶段再提交阶段有一次失败都回滚
  • 原子广播:少数服从多数
  • 数据之间的共享,做到数据的一致性

Hive

  • 基于Hadoop,类SQL语言转化成MapReduce,这就决定了Hive的效率会比较低
  • HIve是离线分析工具

HBase

  • 分布式数据库:NoSQL,适合存储半结构化或非结构化的数据
  • 通过列来存储很少进行全表查询,往往是指定子段查询,效率元高于行存储
  • 行存储需要分析以列的数据需要全查出来再筛选,列存储直接以列就能拿出来

在这里插入图片描述

分布式一致性:拜占庭将军问题

  • 目标:统一作战计划一起行动(一致性)

  • 在不安全的环境下的安全机制达成共识

  • 拜占庭容错算法更加复杂,不仅有故障节点还有作恶节点

  • 通常的计算机领域只是故障容错算法CFT,可能存在消息丢失和消息重复,但是不存在伪造信息

  • 通常的分布式是信任和协作,区块链是不信和制约

  • Paxos算法,raft算法,zab算法

  • 强一致性是同步的,最终一致性是异步的

  • 可用性是保证能服务,但是不一定是最新的数据

  • 分区容错性:集群的分区故障容错能力

  • CAP的三角

  • NameNode使用PC,DataNode用PA

  • CA模型在分布式系统中不存在,因为不能舍弃P

  • 为了防止数据不一致典型的应用是zk、ETCD、HBase都是CP模式

  • AP模型实现了服务的高可用,但是牺牲了一致性,是最终一致性,典型应用是cassandra

  • Linux查看大文件并清理

sudo du -cks * | sort -rn | head -10

ACID理论:CAP的酸,追求一致性

  • 赵、魏、韩要同时进攻秦组成一个事务,要么全部执行要么全部都不执行

在这里插入图片描述

  • 二阶段提交:

引入协调者:统计问问明天有没有时间啊,就是投票阶段

在这里插入图片描述

  • 由协调者统一判断是否执行

在这里插入图片描述

  • MySQL通过XA实现分布式事务
  • 但是有问题:在提交请求阶段需要预留资源,其他人不能操作,相当于时间给我预留好了,不允干别的
  • 因为无法根据业务特点弹性的调整锁的粒度,这些都会影响数据库的并发性能
  • TCC:try-confirm-cancel预留、确认、撤销
  • TCC是在业务层面实现分布式事务,减少了数据库的压力但是对业务的入侵性也更强,要求确认和撤销的操作是幂等的

BASE理论:CAP的碱,追求可用性

  • 基本可用,最终一致性
  • 从微服务的角度来考虑, 有这些方式能够尽可能地保证系统的基本可用:
  1. 使用消息队列, 对偶然的高并发写操作进行削峰填谷;
  2. 对进程间的服务调用做好熔断保护;
  3. 在系统能力无法支撑高并发访问时, 对非核心业务降级;
  4. 对关键服务做好限流.

Paxos算法(一):如何在多个节点间确定某变量的值?

  • basic-paxos、multi-paxos

Raft算法(一):如何选举领导者?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值