架构设计系列二（高性能数据库集群）
2024-06-21 17:18:53 0 举报AI智能生成
内容整理自极客时间-从0开始学架构
作者其他创作
大纲/内容
对于写后读，直读主库
读从机失败后再读一次主机（又叫二次读取）
关键业务读写操作全部指向主机，非关键业务采用读写分离
解决读写一致性问题
主从复制延迟
优：简单，自由定制
缺：若有多种语言，每种都要实现
缺：若发生主从切换，所有系统要重启
程序代码封装
独立一套系统出来，实现读写操作分离和数据库服务器连接的管理
中间件对业务服务器提供 SQL 兼容的协议
对于业务服务器来说，访问中间件和访问数据库没有区别
解释
能够支持多种编程语言
支持完整的 SQL 语法和数据库服务器的协议
实现比较复杂，很容易出现 bug，需要较长的时间才能稳定
所有的数据库操作请求都要经过中间件，中间件的性能要求也很高
数据库主从切换对业务服务器无感知，数据库中间件可以探测数据库服务器的主从状态
只有大公司有能力开发和维护，价值也会更高
特点
MySQL 官方推荐 MySQL Router
中间件封装
最简单！
手动处理
实现读写请求分离
分配机制
复杂度
读写分离（提高读写性能）
读写性能大幅下降
数据文件会变得很大，数据库备份和恢复需要耗费很长时间
数据文件越大，极端情况下丢失数据的风险越高
解决问题：海量数据存储的情况下，单机存储成为瓶颈
解决：合并同步到OLAP数据库进行查询，如TiDB/Clickhouse/阿里云ADB等
不同库的表无法JOIN查询
解决：定时任务+人工补偿
自带事务不支持跨库，而XA协议性能低
解决：评估业务量短期是否发展迅速，是再使用此方案
一台机变成了多台机，成本增加
新的问题
按照业务模块将数据分散到不同的数据库服务器（单机无法提高连接数）
能够支撑百万甚至千万用户规模的业务
分库
解决单表海量数据的问题，例如淘宝的几亿用户数据
查询完整信息需要JOIN（还能接受）
引入复杂度
将部分字段分离到另一张表
垂直分表
解释：表结构不变，拆分部分数据量到多个表
对特定字段进行路由计算，拼接出结果表名
首先尽量选择分布均匀的整数列作为路由字段
优：可以平滑地扩充新的表
缺：可能分布不均
根据ID范围确定表名
范围路由
优：分布均匀
缺：扩新表导致所有数据重分布，所以一般开始时确定了表数量就不会变（准确评估数据量）
对列值进行Hash后再取模
Hash路由
优：设计简单，使用起来非常灵活，方便扩充新表
缺：多查询一次，会影响整体性能
缺：若路由表本身如果太大，又成为瓶颈
新增一个路由表包含路由列和表id，读写数据时先通过路由表查表id，再查数据
配置路由
路由算法
需要依次JOIN每张表再合并结果
Join查询
需要单独查询每张表行数再求和
或者：在增删行后，将表行数单独维护到一张表中，在这张表中离线维护总行数。缺点是可能不准确
Count查询
需要SQL汇总查询结果后再排序
OrderBy查询
实现：也可以通过程序封装和中间件封装实现。
水平分表
分表
分库分表（提高读写性能同时分散存储压力）
架构设计系列二（高性能数据库集群）
0 条评论
回复 删除
下一页
