第 6 周学习心得

用户头像
子豪sirius
关注
发布于: 2020 年 07 月 15 日

MySQL复制



MySQL主从复制

读写分离,应用在有大量读操作场景,可以一主多从:分摊负载、专机专用、高可用

MySQL主主复制

解决当主数据库失效不可用的问题:当发现失效时,进行失效转移,将写操作发送到第二个服务器,开始重建失效服务器数据,当失效机器完全恢复时,继续保持主服务器间复制机制。

  • 主主复制的两个数据库不能并发写入

  • 复制只是增加数据的读并发处理能力,并不能解决写并发的处理和存储能力

  • 更新表结构会导致巨大的同步延迟



数据分片

解决写并发的存储能力

硬编码实现数据分片

根据key映射服务器编号

根据key通过外部存储来映射服务器编号

挑战:

  • 需要额外代码

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

  • 无法使用数据库事务

  • 增加更多服务器改动大

采用数据库中间件

  • Amoeba

  • Cobar

SQL解析 -> SQL路由 -> SQL执行 -> 后端通讯模块 -> 数据库

集群伸缩

同一张表进行分片,分成多个schema,以schema为单位计算在哪个节点。当要扩展节点时,schema不用划分,只需要重新安排schema归属的节点,进行schema迁移



CAP

CAP原理

  • Consistency

  • Availability

  • Partition tolarence

CAP P是前提集成,必须保证。C和A不能同时满足

最终一致性

  • 简单冲突处理策略:根据时间戳,最后写入覆盖

  • 客户端冲突解决

  • 投票解决冲突(Cassandra):客户端连接到任意一节点,按照投票一致性写入一个节点,该节点计算要存储的分区范围,查询发送给存有数据的其他节点进行投票,当过半数通过时,数据写入更新所有存有数据的节点。

HBase结构

LogStructed Merge Tree

(待补充)

ACID与BASE

原子性、隔离性、持久性、一致性

BA:基本可用

S:弱状态

E:最终一致



Zookeeper

分布式一致性算法Paxos

(待补充)

Zookeeper架构

(待补充)



Doris - 海量KV Engine

(待补充)



用户头像

子豪sirius

关注

还未添加个人签名 2018.05.03 加入

还未添加个人简介

评论

发布
暂无评论
第6周学习心得