企业官网建设流程全解析

腾讯云注册域名后怎么做网站,网站建设氺金手指排名14,任县网站建设网络公司,网站上的vr全景是怎么做的前言随着业务规模的增长#xff0c;单机 MySQL 在 并发能力、数据容量、可用性 等方面都会逐渐遇到瓶颈。为了支撑更高的 QPS、更大的数据量以及更稳定的服务#xff0c;MySQL 架构会不断演进#xff0c;从 单库 → 主从复制 → 读写分离 → 分库分表。本文将从三个核心维度…前言随着业务规模的增长单机 MySQL 在并发能力、数据容量、可用性等方面都会逐渐遇到瓶颈。为了支撑更高的 QPS、更大的数据量以及更稳定的服务MySQL 架构会不断演进从单库 → 主从复制 → 读写分离 → 分库分表。本文将从三个核心维度系统性拆解 MySQL 的常见架构设计MySQL 主从复制架构基于 binlog主从延迟产生原因与治理方案分库分表设计以订单系统为例一、MySQL 主从复制架构详解1. 为什么需要主从复制主从复制Master-Slave Replication是 MySQL 最经典、最基础的高可用与扩展方案主要解决三个问题读性能扩展主库写从库读读写分离数据冗余备份从库作为数据副本高可用基础主库故障时可切换从库主从复制的核心依赖binlog二进制日志2. binlog 是什么binlog 是 MySQL Server 层产生的日志用于记录对数据产生变更的操作如INSERT / UPDATE / DELETE / DDLbinlog 具备以下特性追加写顺序 IO逻辑日志不是物理页变化主从复制、数据恢复的基础3. 主从复制的整体流程MySQL 主从复制本质上是把主库的 binlog “传输 重放” 到从库整个流程可以拆解为三个核心阶段阶段一主库写入 binlog当主库执行一条事务时执行 SQL修改内存中的数据页生成 binlog event将 binlog 顺序写入 binlog 文件事务提交成功注意binlog 是在事务提交阶段写入先写 binlog再提交事务两阶段提交的一部分阶段二binlog 同步到从库从库会启动一个IO ThreadIO Thread 与主库建立连接主库启动Binlog Dump Thread主库不断将 binlog event 推送给从库从库将接收到的 binlog 写入本地的Relay Log中继日志此阶段本质是网络 IO 顺序写磁盘阶段三从库回放 binlog重放数据从库启动SQL Thread读取 Relay Log按顺序解析 binlog event在从库执行对应的 SQL 或行变更最终与主库数据保持一致4. 主从复制的特点总结默认是异步复制主库事务提交不等待从库完成存在主从延迟风险复制是单线程回放MySQL 5.6 之后支持并行二、主从延迟为什么会发生如何治理1. 什么是主从延迟主从延迟指的是主库已经提交成功的数据从库还未完成回放常见表现刚写入的数据从库查询不到读写分离后出现“读到旧数据”2. 主从延迟产生的常见原因1从库 SQL 回放能力不足单线程回放 binlog主库写入速度 从库回放速度2大事务 / 批量操作一个大事务必须完整回放完成阻塞后续 binlog3从库硬件性能较弱IO、CPU、内存瓶颈4网络抖动binlog 传输不稳定3. 主从延迟的治理方案方案一强制走主库最常见适用场景写后立即读下单后查订单做法关键读请求不走从库通过代码或中间件控制写操作 → 主库 强一致性读 → 主库 非关键读 → 从库方案二基于 binlog 位点判断记录写入时的 binlog position从库读取到该 position 后再读优点一致性强缺点实现复杂成本高方案三半同步复制Semi-sync主库至少等待一个从库 ACK减少数据丢失风险不能完全消除延迟方案四并行复制MySQL 5.7基于库级 / 组提交的并行回放明显提升从库吞吐能力三、分库分表设计以订单系统为例当单库单表的数据量和 QPS 达到瓶颈时仅靠主从复制已经不够就需要引入分库分表。1. 什么是分库分表本质把一张大表拆成多张小表目标降低单表数据量提升查询和写入性能降低锁冲突2. 订单系统为什么需要分库分表订单表通常具备以下特点数据量极大千万 / 亿级写多读多按用户、订单号频繁查询如果全部放在一张表索引巨大查询变慢写入锁冲突严重3. 分库分表的三种核心方式垂直分表按字段拆思想把字段多、访问频率低的列拆出去示例order_base 表 order_id, user_id, status, create_time order_ext 表 order_id, address, remark, invoice_info优点减少热表字段提高缓存命中率垂直分库按业务拆思想不同业务模块使用不同数据库示例订单库 支付库 用户库优点降低库级耦合易于团队拆分水平分库分表最核心思想按某个规则把同一张表的数据拆到多个库 / 表常见分片键user_idorder_id示例按 user_idorder_db_0.order_0 order_db_0.order_1 order_db_1.order_0 order_db_1.order_1路由规则db_index user_id % 2 table_index user_id % 24. 分库分表带来的挑战跨库 JOIN 不可用全局唯一 ID 生成分页、排序复杂运维成本上升因此通常会配合分布式 ID雪花算法中间件ShardingSphere业务层聚合总结MySQL 的架构演进本质是围绕性能、容量、可用性三个目标不断拆解主从复制解决读扩展与数据冗余延迟治理保证一致性与用户体验分库分表突破单机与单表瓶颈理解这些设计不只是为了“会用 MySQL”而是为了在真实业务中设计出可扩展、可演进的系统架构。