示范校建设验收网站,个人可以做社区网站有哪些,网站开发前端好还是后端好,如何建设教育信息网站三、读写分离和分库分表
1.读写分离
1.1 概述
将数据库的读写操作分散到不同的数据库节点上 通常一主多从一台主数据库负责写#xff0c;多台从数据库负责读。 主库和从库之间会进行数据同步#xff0c;以保证从库中数据的准确性。
1.2 问题及解决
1.2.1 问题
主从同…三、读写分离和分库分表
1.读写分离
1.1 概述
将数据库的读写操作分散到不同的数据库节点上 通常一主多从一台主数据库负责写多台从数据库负责读。 主库和从库之间会进行数据同步以保证从库中数据的准确性。
1.2 问题及解决
1.2.1 问题
主从同步延迟
主库写完数据后同步到从库之前主从数据不一致
1.2.2 解决
1强制将读请求路由到主库处理 适合将必须获取最新数据的读请求都交给主库处理 方案Sharding-JDBC 通过Sharding-JDBC的HintManager分片键值管理器强制使用主库
HintManager hintManager HintManager.getInstance();
hintManager.setMasterRouteOnly();
// 继续JDBC操作2延迟读取
适合对数据比较敏感的场景在写请求后避免立即读操作 如支付成功后跳转到一个支付成功页面点击返回后才返回自己的账户。
1.3 如何实现读写分离
1.3.1 常规步骤
1部署一主多从数据库
2主从复制
保证主从数据库之间的数据是实时同步的
3主库处理写请求从库处理读请求
1.3.2 项目实现方式
1代理方式 应用和数据中间加一个代理层并处理应用程序所有的数据请求 代理层负责读写请求将他们路由到对应的数据库中 中间件 MySQL Router官方、Atlas基于 MySQL Proxy、Maxscale、MyCat。
2组件方式
引入第三方组件处理读写请求推荐
如sharding-jdbc引入jar包即可使用非常方便且节省很多运维成本
官方链接 sharding-jdbc 关于读写分离的操作
1.4 主从复制原理
1.4.1 概述 MySQL binlog(binary log 即二进制日志文件)主要记录了MySQL数据库中数据的所有变化数据库执行的所有 DDL 和 DML 语句 根据主库的 MySQL binlog 日志就能够将主库的数据同步到从库中。
备注 binlog 还能帮助我们实现数据恢复。
1.4.2 步骤 1主库将数据库中变化写入到binlog中
2从库链接主库
3从库创建一个I/O线程向主库请求更新的binlog
4主库会创建一个binlog dump线程来发送binlog从库的I/O线程负责接收
5从库的I/O线程将接收的binlog写入到relay log中
6从库的SQL线程读取relay log同步到本地数据库执行SQL
1.4.3 延伸
1阿里开源canal 实现MySQL数据库之间或与其他数据源如elasticsearch之间的数据同步底层也是依赖binlog原理模拟MySQL主从复制过程
2Redis也是通过主从复制实现读写分离
详见我另一篇博客链接 数据库及缓存之Redis一 2.分库分表
解决数据库存储数据量过大问题
2.1 分库
2.1.1 概念
将数据库中的数据分散 到不同的数据库中
2.1.2 分类
1垂直分库 把单一数据库按照业务划分不同业务使用不同的数据库 举例 将数据库中的用户表、订单表、商品表分别单独拆分为用户数据库、订单数据库、商品数据库 2水平分库 把同一个表按一定规则拆分到不同的数据库中每个库可以位于不同的服务器上实现水平扩展解决单表的存储和性能瓶颈问题 举例 订单表数据量太大订单表水平切分后的2张表分别放在不同数据库 2.2 分表
对单表的数据进行拆分 2.2.1 垂直拆分
1对数据列拆分把一张列比较多的表拆分为多张表
2举例
将用户信息表中一些单独列抽出来作为一张表
2.2.2 水平拆分
1对数据行拆分把一张行比较多的表拆分为多张表解决单一表数据量过大的问题。
2举例
将用户信息表拆分为多个用户信息表避免单一表数据量过大造成性能下降
备注 为了提升性能通常会选择拆分后的多张表放在不同数据库中即水平分表和水平分库结合
2.3 分库分表的场景
1单表的数据达到千万级别以上数据库读写速度比较缓慢。
2数据库中的数据占用的空间越来越大备份时间越来越长。
3应用的并发量太大
2.4 常见的分片算法
分片算法主要解决了数据被水平分片之后数据究竟该存放哪个表的问题。
2.4.1 哈希分片
求指定key如id的哈希然后根据哈希值确定数据应被放置在哪个表中。
适合随机读写而不适合经常需要范围查询的场景
2.4.2 范围分片
按照特性的范围区间如时间、ID区间来分配数据 适合经常进行范围查找而不适合随机读写的场景 因为数据未被分散容易出现热点数据的问题 举例 如将id 为 1~299999 的记录分到第一个库300000~599999 的分到第二个库。
2.4.3 地理位置分片
根据地理位置城市、地域来分配数据
很多 NOSQL数据库都支持
2.4.4 融合算法
灵活组合多种分片算法
如将哈希分片和范围分片组合
2.5 分库分表问题
2.5.1 无法join操作 同一个数据库中的表分布在不同的数据库中无法使用join操作 需要在一个数据库中查询到一个数据再去另外一个数据库汇总查询对应的数据
2.5.2 事务问题
同一个数据库中的表分布在不同的数据库中单个操作涉及到多个数据库数据库自带的事务无法解决
2.5.3 分布式ID 分库后数据遍布在不同服务器上的数据库中数据库的自增主键已经没办法满足生成的主键唯一。 需要引入分布式ID
2.5.4 其他
需要更多的数据库服务器成本上升了
2.6 分库分表方案
ShardingSphere 项目 1包括 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar由京东数科巨佬维护
2功能完善
支持读写分离和分库分表、分布式事务、数据库治理等功能。
3生态体系完善
社区活跃文档完善更新和发布比较频繁
入门可以看看下面这篇文章 《芋道 Spring Boot 分库分表入门》
2.7 分库分表数据迁移
2.7.1 停机迁移 系统使用的人数非常少的时候如凌晨 2 点挂公告系统要维护升级预计 1 小时。 再写个脚本老库的数据写到新库中
2.7.2 双写方案
针对不能停机迁移场景
原理如下
1对老库的更新操作增删改同时也要写入新库双写
2还需要自己写脚本将老库中的数据和新库的数据做比对 在迁移过程双写只会让被更新操作过的老库中的数据同步到新库 如果新库中没有那咱们就把数据插入到新库 如果新库有旧库没有就把新库对应的数据删除冗余数据清理
3重复上一步的操作直到老库和新库的数据一致为止
备注 项目中实施双写很麻烦很容易会出现问题建议使用数据库同步工具 Canal 做增量数据迁移还是依赖 binlog开发和维护成本较低。 上一篇跳转—高性能一 下一篇跳转—高性能三 本篇文章主要参考链接如下 参考链接1-JavaGuide 持续更新中…
随心所往看见未来。Follow your heartsee light
欢迎点赞、关注、留言一起学习、交流
