架构师训练营第六周 - 总结

发布于: 19 小时前
架构师训练营第六周-总结

这周主要讲了分布式数据库,NoSQL数据库中的CAP原理,以及ZooKeeper的原理与使用。

分布式数据库

什么分布式数据库呢?

简单的说就是使用时,大于一台数据库服务器在运行,这些服务器可同时对外提供服务(主写从读),也可部分对外提供服务(主备方案)。

我们为什么需要分布式数据库?

单台数据库服务器对外提供服务的能力达到了瓶颈,需要扩大读写能力,或者服务器容量达到瓶颈。

常见的分布式数据库方案有主备,主从,主主,分库分表。

主备,一台主服务器,负责读写,一台备用服务器,同步主服务器数据,不对外提供服务,做数据备份,防止数据丢失,做数据的高可用。

主从方案,主服务器负责写,从负责读,优点有:

  • 分摊负载

  • 专机专用

  • 便于冷备

  • 高可用

缺点是当主服务器挂掉后,无法再写入,且无法自动恢复。

主主方案,主主方案是两套服务器部署,其中一套主服务器挂掉后,自动切换到另一套服务器。一套服务器内部可以做主从。

主主复制,只是提高了数据库写可用性,并没有增加服务器写并发能力和存储能力。两个主服务器不能并发写入。

我们时常听到分库分表,但分库分表包含两层含义。

首先当预测到数据库压力将会比较大时,首先对不同业务进行拆分库。即首先垂直拆分。把关联度不大的业务数据库放到不同的数据库上。

随着业务的持续发展,一张表需要存储上亿条数据的时候,就需要分表。即水平拆分。

拆分表时,有一些技巧。比如,拆分时,预估一张表最终需要存储的数据量,比如,最终差不多有10亿条数据,那我们可以分为12张表。但是,当前数据量比较小,使用12台服务器比较浪费,当前只需要三台服务器就可以够用。随着业务的发展,逐渐加服务器。数据库表在存储时,是以文件的形式保存。当要加机器的时候,移动数据,只需要使用linux命令scp就可以把数据传输过去。

比如:

3台服务器时,服务器1:1,4,7,10;服务器2:2,5,8,11;服务器3:3,6,9,12。

4台服务器时,服务器1:1,5,9;服务器2:2,6,10;服务器3:3,7,11;服务器4:4,8,12。只需要对应调整服务器上文件即可。

分表时,可以客户端决定连接的数据库服务器,也可以在应用和数据库服务器之间加一层库表路由层,在分库分表层配置决定连接哪台服务器。

NoSQL数据库

NoSQL数据库,Not only SQL,NoSQL数据库天生支持分库分表,这对于需要存储大数据量的用户来说是一个好的选择。

NoSQL中,有一个很著名的理论,CAP理论。

C:一致性,Every read receives the most recent write or an error。就是说每次读取的都应该是最近写入的数据或者返回一个错误,数据是一致的。

A:可用性,Every request receives a (non-error) response, without the guarantee that it contains the most recent write。每次请求都会返回一个值,而不是一个错误,但是不保证这个值是最新写入的。

P:分区耐受性,The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes。即使因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然应该是可以操作的。

对于当前网络环境来说,多节点之间一定会出现网络故障问题,故CAP三者中P是一定要满足的。

C与A在分区可用性的前提下,是不可能共存的。所以分布式数据库要选择CP或者AP。

CP满足了数据一致性,但可用性就大打折扣。

AP满足了可用性,但是数据不一致会带来业务上的困扰。

现在,业界主流使用的既不是CP也不是AP,而是CA各自让了一步,是最终一致性。

最终一致性解决数据冲突的方法:

  • 根据时间戳,最终写入覆盖(数据只要最新的,且数据之间无依赖关系)

  • 客户端冲突解决(购物车场景)

  • 投票解决冲突(Cassandra使用方案)

Zookeeper

zookeeper解决的问题是:分布式环境下脑裂问题。

在一个分布式系统中,不同服务器获得了互相冲突的数据信息或者执行指令,导致整个集群陷入混乱,数据损坏,被称作分布式系统脑裂。

如常见的主主备份场景,如何选择一个主服务器为写服务器?

Zookeeper通过paxos协议解决了这个问题。

paxos协议中有三个角色:

  1. proposer

  2. acceptor

  3. learner

决议三阶段:

  1. prepare阶段。proposers向acceptors发出prepare请求,acceptors针对收到的prepare请求进行promise回应。

  2. accepte阶段。proposers收到多数acceptors的promise回应后,向acceptors发出propse请求,acceptor针对收到的propose请求进行accept处理。

  3. learn阶段。proposers在收到多数acceptors的accept之后,标志着本次accept成功,决议达成,将形成的决议发送给所有learners。

Proposer生成全局唯一且递增的proposal ID,向所有acceptor发送prepare请求,这里无需携带提案内容,只携带proposalID即可。Acceptor收到prepare和propose请求后:

  1. 不再接受proposalID小于等于当前请求的prepare请求

  2. 不再接受proposalID小于当前请求的propose请求。

主主备份时,两台主服务器选举,产生一个master节点,今后由master节点来管理集群事务。

Zookeeper使用在多种分布式场景中。

如kafka集群,客户端从zookeeper中获取主节点。

HBase中,使用zookeeper获取HMaster节点。

发布于: 19 小时前 阅读数: 7
用户头像

草原上的奔跑

关注

还未添加个人签名 2018.05.04 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第六周-总结