程序员必备的十大技能(进阶版)之高性能数据库实战(三)

简介: 教程来源 http://tmywi.cn/ 本文系统梳理数据库架构演进路径:从单库单表→读写分离→分库分表,并详解ShardingSphere实战——含分片键设计、跨分片分页优化、雪花算法全局ID生成;同时深入剖析MySQL主从复制原理、读写分离配置及主从延迟监控与应对策略。

三、数据库架构演进

3.1 单库单表 → 读写分离 → 分库分表

[第一阶段] 单库单表
    ┌─────────────┐
    │   MySQL主库  │
    │   (垂直拆分) │
    └─────────────┘

[第二阶段] 读写分离
    ┌─────────────┐      ┌─────────────┐
    │   MySQL主库  │ ──→  │  MySQL从库1  │
    │    (写入)    │      └─────────────┘
    └─────────────┘      ┌─────────────┐
              └─────────→│  MySQL从库2  │
                         └─────────────┘

[第三阶段] 分库分表
    ┌─────────────┐  ┌─────────────┐  ┌─────────────┐
    │  DB0(orders)│  │  DB1(orders)│  │  DB2(orders)│
    │  表0~表3    │  │  表4~表7    │  │  表8~表11   │
    └─────────────┘  └─────────────┘  └─────────────┘

3.2 分库分表实战(ShardingSphere)
分片键选择原则
均匀性:数据分布均匀,避免热点

查询友好:80%以上的查询都带分片键

不可变:分片键一旦确定不能修改

水平分表示例:订单表按user_id分片

// ShardingSphere配置(application.yml)
spring:
  shardingsphere:
    datasource:
      names: ds0,ds1
      ds0:
        type: com.zaxxer.hikari.HikariDataSource
        url: jdbc:mysql://localhost:3306/db0
      ds1:
        url: jdbc:mysql://localhost:3306/db1
    sharding:
      tables:
        orders:
          actual-data-nodes: ds$->{0..1}.orders_$->{0..3}  # 2库 × 4表 = 8张表
          table-strategy:
            inline:
              sharding-column: user_id
              algorithm-expression: orders_$->{user_id % 4}
          database-strategy:
            inline:
              sharding-column: user_id
              algorithm-expression: ds$->{user_id % 2}
          key-generator:
            column: id
            type: SNOWFLAKE  # 雪花算法生成全局唯一ID

分页跨分片查询优化

// 问题:跨分片分页(需要从所有分片取数据归并)
// 例如:ORDER BY create_time LIMIT 10 OFFSET 100

// 优化方案1:禁止跨分片分页,强制带分片键查询
@GetMapping("/orders")
public Page<Order> getOrders(@RequestParam Long userId, @RequestParam int page) {
    // 查询必须带userId,可以直接路由到特定分片
    return orderService.findByUserId(userId, page);
}

// 优化方案2:使用Elasticsearch作为二级索引
// 主键查询走MySQL分库分表,复杂查询走ES

全局ID生成器:雪花算法(Snowflake)

public class SnowflakeIdGenerator {
    // 64位ID结构:
    // 1位符号位(0) + 41位时间戳(毫秒) + 10位机器ID + 12位序列号

    private final long twepoch = 1288834974657L;  // 起始时间戳(2020-01-01)
    private final long workerIdBits = 5L;         // 机器ID位数
    private final long datacenterIdBits = 5L;      // 数据中心ID位数
    private final long sequenceBits = 12L;         // 序列号位数

    private final long maxWorkerId = ~(-1L << workerIdBits);  // 31
    private final long maxDatacenterId = ~(-1L << datacenterIdBits); // 31
    private final long sequenceMask = ~(-1L << sequenceBits);  // 4095

    private long workerId;
    private long datacenterId;
    private long sequence = 0L;
    private long lastTimestamp = -1L;

    public SnowflakeIdGenerator(long workerId, long datacenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException("workerId范围: 0~31");
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }

    public synchronized long nextId() {
        long timestamp = timeGen();

        // 时钟回拨处理
        if (timestamp < lastTimestamp) {
            long offset = lastTimestamp - timestamp;
            if (offset <= 5) {
                // 回拨在5ms内,等待
                waitUntil(lastTimestamp);
                timestamp = timeGen();
            } else {
                throw new RuntimeException("时钟回拨超过5ms,拒绝生成ID");
            }
        }

        if (timestamp == lastTimestamp) {
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                // 当前毫秒序列号用完,等待下一毫秒
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0L;
        }

        lastTimestamp = timestamp;

        return ((timestamp - twepoch) << (workerIdBits + datacenterIdBits + sequenceBits))
                | (datacenterId << (workerIdBits + sequenceBits))
                | (workerId << sequenceBits)
                | sequence;
    }

    private void waitUntil(long targetTimestamp) {
        while (timeGen() < targetTimestamp) {
            Thread.yield();
        }
    }
}

四、读写分离与主从复制

4.1 MySQL主从复制原理

主库(Writer)                    从库(Reader)
     │                               │
     │ 1. 写操作写入binlog            │
     ▼                               │
┌─────────┐                          │
│ binlog  │                          │
└────┬────┘                          │
     │ 2. dump线程发送binlog          │ 3. I/O线程接收并写入relay_log
     └──────────────────────────────→┌──────────┐
                                      │ relay_log│
                                      └─────┬────┘
                                            │ 4. SQL线程执行relay_log
                                            ▼
                                      ┌─────────┐
                                      │  从库    │
                                      └─────────┘

4.2 Sharding-JDBC读写分离配置

spring:
  shardingsphere:
    masterslave:
      name: ms
      master-data-source-name: master
      slave-data-source-names: slave1,slave2
      load-balance-algorithm-type: ROUND_ROBIN  # 轮询,可选RANDOM
    props:
      sql-show: true  # 显示SQL路由信息

4.3 主从延迟解决方案
延迟监控

-- 主库上执行
SHOW MASTER STATUS;
-- 记录File和Position

-- 从库上执行
SHOW SLAVE STATUS\G
-- 重点看:
-- Seconds_Behind_Master: 延迟秒数(从库落后主库的时间)
-- Master_Log_File / Read_Master_Log_Pos: 从库IO线程读到的位置
-- Relay_Master_Log_File / Exec_Master_Log_Pos: 从库SQL线程执行的位置

延迟应对策略

// 策略1:强制主库读(写后立即读的场景)
@Hint(name = "master", value = "true")
public Order getLatestOrder(Long userId) {
    // 使用Hint强制路由到主库
    return orderMapper.selectByUserId(userId);
}

// 策略2:业务容忍,降级处理
@Retryable(value = {StaleDataException.class}, maxAttempts = 3)
public Order getOrderWithRetry(Long orderId) {
    Order order = orderMapper.selectFromSlave(orderId);
    if (order == null && isRecentlyWritten(orderId)) {
        // 最近写入的数据从库未同步,稍后重试
        throw new StaleDataException("数据同步中");
    }
    return order;
}

// 策略3:缓存最新数据(写操作后更新缓存)
@CachePut(value = "orders", key = "#order.id")
public Order createOrder(Order order) {
    orderMapper.insert(order);
    return order;
}

来源:
http://yyvgt.cn/

相关文章
|
2月前
|
人工智能 安全 API
深度解析 Claude Code 在 Prompt / Context / Harness 的设计与实践
文章内容基于作者个人技术实践与独立思考,旨在分享经验,仅代表个人观点。
3266 75
深度解析 Claude Code 在 Prompt / Context / Harness 的设计与实践
|
21天前
|
人工智能 自然语言处理 数据可视化
【AI 尝鲜实验室】5.22 号上新 | DeepSeek-TUI:终端里 DeepSeek 版的 Claude Code
本实验通过阿里云计算巢快速部署DeepSeek-TUI,配置API Key后即可在云服务器终端中使用命令行与AI编程助手交互,支持代码生成、脚本处理、项目搭建及问题排查等开发任务,全程可视化、低门槛、高效率。
999 25
|
21天前
|
存储 缓存 安全
【Java基础】集合框架: ArrayList vs LinkedList 核心区别、扩容机制(附《思维导图》+《面试高频考点清单》)
本文深入解析ArrayList与LinkedList的核心差异:前者基于动态数组,支持O(1)随机访问、尾部增删高效,但中间/头部操作需移动元素;后者基于双向链表,头部/尾部增删为O(1),但随机访问O(n)且内存开销大4–5倍。重点剖析ArrayList的1.5倍扩容机制及CPU缓存优势,澄清“LinkedList更适合队列”等常见误区。
|
20天前
|
人工智能 Linux API
告别多账号切换!用 9Router 一键把所有 AI 模型变成一个 API,Cursor/Cline 直接起飞
还在为 AI 客户端配置混乱、多账号来回切换、Token 消耗过高而头疼?最近爆火的开源项目 9Router 彻底解决了这些痛点!它能把 OpenAI、Claude、Gemini、Copilot、Ollama 等所有主流 AI 服务,统一成一个标准的 OpenAI API 接口,不管是 Cursor、Cline 还是 Cherry Studio、OpenWebUI,直接用一个地址就能调用所有模型,还自带 Token 压缩,大幅降低成本!本文从 0 开始带你用 Docker 一键部署,全程干货无废话。
420 0
告别多账号切换!用 9Router 一键把所有 AI 模型变成一个 API,Cursor/Cline 直接起飞
|
20天前
|
人工智能 API 开发者
NVIDIA 免费 API 从申请到 Claude Code 接入全攻略:CLIProxyAPI 与 CCR 代理实战
JeecgBoot AI专题研究 NVIDIA 免费 API 申请与 Claude Code 第三方模型接入实战指南 前言Claude Code 已经成了很多开发者日常编程的首选工具,但它的付费门槛让不少人望而却步——尤其是以人民币结算的用户,每月开支不算小。好消息是,NVIDIA 提供了免费
671 0
NVIDIA 免费 API 从申请到 Claude Code 接入全攻略:CLIProxyAPI 与 CCR 代理实战
|
存储 SQL 人工智能
Deepinsight x ChatBI:个人Agent助手养成计划
✨一文详解Deepinsight x ChatBI个人Agent助手养成计划
|
21天前
|
弹性计算 人工智能 数据可视化
零基础必看!Hermes Agent一键部署教程:阿里云轻量应用服务器/无影云电脑/ECS三种方法完整版
2026年,开源AI智能体赛道快速发展,Hermes Agent凭借轻量化、自进化、低成本运行等优势,成为备受关注的主流框架。这款由Nous Research推出的智能体,内置学习闭环,可在执行任务后自动沉淀经验、生成可复用技能,真正实现“越用越聪明”。更友好的是,它对硬件要求极低,低配服务器即可稳定运行,普通用户也能轻松拥有专属AI助手。
301 1
|
21天前
|
人工智能 安全 测试技术
基于Harness + Langgraph + A2A 写一个 Agent Team,实现一支硅基团队自己 写代码
基于Harness + Langgraph + A2A 写一个 Agent Team,实现一支硅基团队自己 写代码
基于Harness + Langgraph + A2A 写一个 Agent Team,实现一支硅基团队自己 写代码
|
26天前
|
程序员 开发工具 git
初级程序员必备的十大技能之 Git 版本控制(三)
教程来源 http://qcycj.cn Git分支是并行开发的核心利器,本质为轻量指针,创建零成本。支持便捷的创建、切换、合并(快进/三方/冲突)、rebase变基及规范工作流,助力团队高效协作与清晰历史管理。
|
21天前
|
监控 安全 BI
厂区人员定位管理系统|管理痛点+技术原理(二)
该系统专为化工厂区设计,融合高精度定位与智能管控,具备五大核心功能:实时厘米级定位、智能电子围栏预警、全程轨迹追溯、SOS一键应急救援、外来人员全周期管控,实现人员管理从“被动应对”到“主动防控”的升级,筑牢本质安全防线。(239字)