第六周总结

发布于: 2020 年 07 月 15 日

分布式数据库

数据库分片

在业务数据量巨大,单一表数据量过大,需要进行数据分片。

  1. 使用硬编码实现数据分片。(不够灵活)

  2. 映射表外部存储。(外部映射表的数据量会很大)

  3. 分布式数据库中间件:MyCat

分片所面对的问题:

  • 需要大量的额外代码,处理逻辑更加复杂。

  • 无法执行多分片的联合查询。

  • 无法使用数据库的事务。

  • 随着数据增长,如何横向扩容。

数据库部署方案

  • 单一服务器与单一数据库。(简单的应用,MVP)

  • 主从复制实现伸缩。(读取压力较大的场景)

  • 多个Web服务器对应多个数据库。(业务规模增大,需要低耦合实现业务拆分)

  • 综合部署。(针对性的对压力较大的业务服务模块进行优化)

NOSQL

CAP原则

  1. 如果选择可用性(A) + 分区容错性(P), 就要放弃一致性(C)。

  2. 如果选择一致性(C) + 分区容错性(P), 就得放弃可用性(A)。

  3. 如果选择一致性(C) + 可用性(A), 就得放弃分区容错性(P)。

弱一致性:在以写入数据成功后,在数据副本上可能读不出来,也不能保证多长时间后每个副本上的数据都是一直的。

最终一致性:写入数据成功后,虽然在其他副本可能读不到该最新的值,但是在某个时间窗口之后能保证最终能读到该最新的值。

最终写一致冲突的解决方式:

1. 根据时间戳,最后写入覆盖。

2. 客户端冲突解决。(根据具体的业务)

3. 投票解决冲突(Cassandra)

强一致性:数据一旦写入成功,在任意的副本上都能读到该最新数据。

有的为了保证严格一致性会按照GPS时钟以保证时间一致性。

HBASE架构

ZooKeeper

分布式一致性算法Paxos

三个角色:

  • Propose

  • Acceptor

  • Leaner

Zab协议

  • 领导者(Leader): 作为主节点,在同一时间集群只会有一个领导者。需要你注意的是,所有的写请求都必须在领导者节点上执行。

  • 跟随者(Follower):作为备份节点, 集群可以有多个跟随者,它们会响应领导者的心跳,并参与领导者选举和提案提交的投票。需要你注意的是,跟随者可以直接处理并响应来自客户端的读请求,但对于写请求,跟随者需要将它转发给领导者处理。

  • 观察者(Observer):作为备份节点,类似跟随者,但是没有投票权,也就是说,观察者不参与领导者选举和提案提交的投票。

Zab相较于Paxos算法最大的区别在于引入了ZXID,每个事务有一个全局单调递增的id,所以能够按序提交,解决了事务操作如何保证全局有序的难题。

用户头像

Acker飏

关注

还未添加个人签名 2018.05.03 加入

还未添加个人简介

评论

发布
暂无评论
第六周总结