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

用户头像
牛牛
关注
发布于: 2020 年 07 月 15 日
架构师训练营 - 第⑥周总结
分布式数据库
  • 主从复制&一主多从复制(分摊负载、专机专用、便于冷备、高可用)

  • 分离读写,提高读可用性,某从机宕机不影响数据库访问

  • 写操作可用性不变,主机宕机只影响写操作

  • 主主复制

  • 主主复制的两个库不能并发写入,只是提高了数据库写操作的可用性

  • 复制只是增加了数据库的读并发能力,没有增加并写能力和存储能力

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

  • 数据分片

  • 硬编码实现数据分片

  • 映射表外部存储

  • 挑战

  • 大量额外代码,处理逻辑复杂

  • 无法执行多分片联合查询,无法使用数据库事物

  • 随着数据增长,如何扩展是难题

  • 分布式数据库中间件(推荐)

  • 数据库部署方案:

  • 单一服务与单一数据库

  • 主从复制实现伸缩

  • 两个服务与两个数据库

  • 综合部署(分库、主从、主主、分片)

CAP原理:分布式系统必须满足分区容错性的前提下,一致性和可用性无法同时满足

  • 一致性:每次读取到的都是最新数据或者返回失败,而不是过期数据

  • 可用性:每次请求都应该得到相应,而不是返回错误或失去相应,但响应的数据不保证是最新的

  • 分区容错性:部分服务器节点间消息丢失或者超时,系统依然可操作

  • 当节点时效时,我们如果要保持一致性,就需要取消操作导致可用性降低,如果要保持可用性继续操作,一致性就不能保障

  • 对一个分布式系统而言,节点超时或失效必然存在,这时就需要在可用性和一致性上做出选择

  • 可用性相比一致性更重要,系统优先保障可用性,一致性只保证最终一致性,存在一定延迟

  • 最终一致性冲突解决方案:按时间戳最后写入覆盖;客户端解决冲突;投票(Cassandra

ACID:原子性、一致性、隔离性、持久性
BASE
  • 基本可用:系统出现故障时允许出现响应延迟或功能上的损失

  • 软状态:允许数据在节点间同步出现一定延迟

  • 最终一致性:系统所有副本数据在经历一定时间后最终达到一致状态

ZOOKEEPER
  • 分布式一致性算法paxos:提案者、投票者、学习者

  • zk集群节点单数部署

  • 读性能卓越,写性能随着节点数增加性能下降



用户头像

牛牛

关注

还未添加个人签名 2018.02.27 加入

还未添加个人简介

评论

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