每天净瞎搞

关注:CS/AI/数学/自我提升等

0%

《沈剑架构师训练营》第5章 - 数据库架构

21、数据库:读性能要如何提升?

  • no21:数据库工程架构,要设计些什么呢?
    • 1.根据「业务模式」设计库表结构
    • 2.根据「访问模式」设计索引结构
  • no21:数据库工程架构必须要考虑哪 5 个因素?
    • 读性能提升
    • 高可用
    • 一致性保障
    • 扩展性
    • 垂直拆分
  • no21:提升数据的读性能的方案一:建立索引
    • 潜在问题
      • 写性能降低
      • 索引占用内存大,buffer命中率降低, 读性能降低
    • 实践:可以为主实例不建立索引,从实例建立不同的索引
  • no21:提升数据的读性能的方案二:增加从库
    • 分组架构,主要解决的,就是读性能提升的问题,但没有解决数据容量的扩展以及写高可用的问题,分组会引发主从一致性问题,从库越多,同步越慢,主从一致性的问题就越严重
  • no21:提升数据的读性能的方案三:增加缓存
    • 左边是服务化前,右边是服务化后,s 是从库,m 是主库

22、数据库:垂直拆分与高可用

  • no22:数据库垂直拆分的方法论是什么?
    • 1.长度较短
    • 2.访问频率较高
    • 3.经常一起访问
    • 的属性放在主表里,原因是,数据库缓冲池,逻辑上,以 row 为单位缓冲数据
  • no22:数据库的高可用的思路和问题是什么?
    • 数据库的高可用设计,也是冗余+故障自动转移
    • 但是,方法论上:数据库的冗余,会引发一致性问题!因为多个节点数据库没办法同时修改,中间会有个时间差,就有可能引发一致性的问题
  • no22:读库高可用的方案
    • 读库高可用,冗余从库,可一主多从,主库会把主库的写序列通过 binlog 的方式同步给从库,重复执行相同的序列
  • no22:写库高可用的方案
    • 写库高可用,冗余写库,
    • 1.双主同步一个节点对外提供读写服务,另一个节点是备份节点,他们之间使用相同的 vip,通过 keepalived 去检测
    • 2.在分组架构中加入一个双主节点,冗余写库,两边进行相互的同步,两个主库同时对线上提供服务

23、数据库:主从一致性,主主一致性如何保障?

  • no23:主从数据冗余,主从数据不一致的情况是怎样?
    • 应用写一个数据后,在主从数据库同步完成前读同一个数据,造成数据不一致
  • no23:主从数据冗余,主从数据不一致的 3 个解决方案是什么?
    • 方案一:忽略不计
      • 中间时间估计约几百毫秒,业务允许的情况下,可不做处理
    • 方案二:强制读主
      • 都读写主库,然后使用缓存来提升读性能,但主库和缓存间也有一致性问题
    • 方案三:选择性读主(需要缓存协助)
      • 写操作过程
        • 写完后,使用哪个库、哪个表、哪个主键拼接一个 key,设置到缓存里,并将这个 key 的时间记录为主从同步的时延
      • 读操作过程
        • 先读缓存,如果没有,再读从库
        • 如果有,则读主库
  • no23:主主数据冗余,为什么主主数据会不一致?
    • 因为同时对外提供服务,并发的写入可能会造成数据同步失败,这个比主从的同步时延要严重,这个可能会造成数据丢失
  • no23:主主数据冗余,主主数据不一致的 3 种解决方案是什么?
    • 方案一:数据库层面解决,不同初始值,相同递增步长
    • 方案二:数据库上层应用程序控制 id 生成
    • 方案三:主主同时服务,升级为单主服务,影子主不服务
      • 即keepalived+vip

24、数据库:扩展性,要如何解决?

  • no24:数据库扩展性有哪些场景?
    • 1.底层表结构变更
    • 2.水平扩展,分库个数变化
    • 3.底层存储介质变化
  • no24:数据库进行扩展有哪五个方案?
    • 1.停服扩展(离线,非高可用)
    • 2.pt-online-schema-change(在线表结构变更)(平滑)
    • 3.追日志方案(平滑)
    • 4.双写方案(平滑)
    • 5.秒级成倍扩容(平滑)
  • no24:数据库扩展的停服扩展的步骤是怎样的?优缺点是什么?
    • 步骤
      • 1.挂公告
      • 2.离线迁移数据
      • 3.切到新库
    • 优点
      • 直观和简单
    • 缺点
      • 对服务的可用性有影响
      • 必须在指定的时间完成升级,对技术人员压力非常大,一旦出现问题必须在规定时间内解决,否则只能回滚
  • no24:数据库扩展的pt-online-schema-change(在线表结构变更)步骤、注意事项是什么?
    • 步骤
      • 1.创建一个扩展字段后的新表
      • 2.在原表上创建三个触发器,对原表的所有写操作(insert、delete、update)都会对新表进行完全相同的操作
      • 3.工具会分批地将原表中的数据分段地导入到新表
      • 4.删除掉触发器,并将原表移走
      • 5.将新建的新表重命名
      • 整个过程不需要锁表,可以持续对外提供服务,rename 前是旧表,rename 前是新表
    • 注意事项
      • 1.变更过程中最重要的是处理冲突,原则是以触发器的最新数据为准,这要求被迁移的表必须有主键
      • 2.在变更额度过程中,由于写操作要新建触发器,所以如果原表已有非常多的触发器,这个方案就不可行,但通常会禁用触发器
      • 3.触发器的建立会影响原表的性能,这个操作必须在流量的低峰期进行
      • 4.只适合 MySQL,也只适合表结构变更
  • no24:数据库扩展的追日志方案的步骤是什么?
    • 步骤
      • 1.由旧库继续提供服务,并对服务进行一次升级,记录对旧库上的修改的日志,不需记录详细数据,只需记录哪个库哪个表哪个主键在什么时间被修改即可
        • 风险小,写接口的数量有限,改动点较少,升级过程增加了一些日志,对业务功能没有任何的影响
      • 2.研发数据迁移工具,将数据从旧库迁移到新库
      • 3.研发一个读取日志,看哪个库哪个表哪个主键发生了写操作,并将这些 key 从旧库再次覆盖到新库中,来对迁移数据过程里产生的数据差异进行追平,无论如何,当发生冲突时,以旧库中的数据为准,因为旧库的数据在实时更新
      • 4.研发数据比对工具,将旧库和新库的数据进行比对,直到数据完全一致,才能修改配置迁库
      • 5.迁移流量,对旧库进行一次秒级的 readonly,等日志重放程序完全追上之后,秒级的进行一个流量的切换

25、数据库:扩展性,平滑扩容方案?

  • no25:数据库平滑迁移的双写方案的 4 个步骤
    • 1.首先旧库提供服务,先对服务进行升级,对数据修改写接口,并在新库上进行相同的操作
    • 2.研发数据迁移工具,对数据进行迁移
    • 3.数据比对
    • 4.流量迁移

26、数据库:水平切分,数据库秒级扩容!

  • no26:数据库水平切分,秒级成倍扩容的 3 个步骤
    • 前提条件
      • 实施了微服务的分层架构,大数据量进行了水平切分,高可用做了 keepalived 加 vip
    • 步骤
      • 1.修改配置(双虚 IP,微服务数据库路由)
      • 2.服务层 reload 配置,实例增倍完成
        • reload 配置方案
          • 1.重启服务,读新文件
          • 2.配置中心给服务层发信号,重新读取配置文件
      • 3.收尾:解除旧双主同步,新增新的双主同步,删除冗余数据,数据量减半完成