MySQL 分库分表实战之ShardingSpare(分库分表+读写分离)

已于 2023-11-19 10:46:39 修改
阅读量1.5k 收藏 11
点赞数 2
分类专栏： mysql 文章标签： mysql shardingspare 分库分表
于 2023-07-02 18:38:49 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_38597669/article/details/131484053
版权

文章目录

概要

市面上MySQL分库分表中间件还是很多的，主要分为两大类：应用层依赖类中间件（比如shardingsphere-jdbc）、中间层代理类中间件(比如shardingsphere-proxy)。

  • 应用层依赖类中间件
    即中间件在数据库连接库基础之上，增加了一层封装。我们使用时，以shardingsphere-jdbc为例，需要先引入一个jar包。中间件接收持久层产生的sql，同样对sql进行分析等操作，然后才落实到具体的库上。
    库
    优点：性能损耗低（直连数据库），去中心化（每个Application使用各自的分库分表库）。
    缺点：异构语言不是很友好，连接数高（每个Application都要与数据库建立连接）。
  • 中间层代理类中间件
    即把中间件作为一个独立的服务，它将接收到的SQL 语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此 SQL 发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。
    代理
    优点：异构语言友好，连接数低（只需proxy与数据库建立连接）。
    优点：性能损耗略高（需要proxy转发去连数据库），中心化（proxy需要集群部署，运维难度增加）。

市面上常见的分库分表中间件很多，但是国内主要是mycat和shardingsphere，相较而言，shardingsphere已经是Apache顶级项目，维护稳定，功能齐全，支持云原生，更值得学习。

在上一篇分享了MySQL分库分表的一些理论知识，本文主要是分享shardingsphere的实战内容。
官方文档
本文基于 shardingsphere V5.3.1探索

一、安装

根据官方文档提示，主要有两种方式：二进制安装和docker安装；
本人是使用docker的方式，如下：

  1. 拉取镜像
docker pull apache/shardingsphere-proxy
  • 拷贝配置

起一个临时容器 tmp,把配置模板从tmp中拷贝到本地目录下，然后删除tmp。

mkdir -p /etc/shardingsphere-proxy/conf
docker run -d --name tmp --entrypoint=bash apache/shardingsphere-proxy
docker cp tmp:/opt/shardingsphere-proxy/conf /etc/shardingsphere-proxy/conf
docker rm tmp

mkdir -p /etc/shardingsphere-proxy/ext-lib

下载jar包后放入到 /etc/shardingsphere-proxy/ext-lib 目录下

  • 启动容器
docker run -d \
    -v /etc/shardingsphere-proxy/conf:/opt/shardingsphere-proxy/conf \
    -v /etc/shardingsphere-proxy/ext-lib:/opt/shardingsphere-proxy/ext-lib \
    -e PORT=3305 -p 3305:3305 apache/shardingsphere-proxy:latest

如此shardingsphere-proxy容器就起来了，但是配置文件还没调整，放在下一章讲解。

二、配置

我们ll /etc/shardingsphere-proxy/conf/ 可以看到所有的配置文件，如下：

  • config-database-discovery.yaml #高可用。健康检查，db节点没有心跳就不会再转发sql到该节点，保证高可用
  • config-encrypt.yaml #数据加密
  • config-mask.yaml #数据脱敏
  • config-readwrite-splitting.yaml #读写分离
  • config-shadow.yaml #影子库配置
  • config-sharding.yaml #分片配置（分库分表规则）
  • server.yaml #通用配置
2.1、 通用配置

官方文档-模式类型
官方文档-认证和授权
官方文档-属性配置
官方文档-其他配置

######################################################################################################
# If you want to configure governance, authorization and proxy properties, please refer to this file.
######################################################################################################
mode:
  type: Standalone #运行模式类型。可选配置：Standalone、Cluster，个人测试就选择了单机模式
  repository: # 持久化仓库配置
    type: JDBC #持久化仓库类型
    props: # 持久化仓库所需属性
      foo_key: foo_value
      bar_key: bar_value
authority: #认证和授权 
  users:  #账号信息
    - user: root
      password: root
    - user: sharding
      password: sharding
  privilege: #权限
    type: ALL_PERMITTED

props: #属性配置
  max-connections-size-per-query: 1
  kernel-executor-size: 16  # Infinite by default.
  proxy-frontend-flush-threshold: 128  # The default value is 128.
  proxy-hint-enabled: true
  sql-show: true
  check-table-metadata-enabled: false
#其他配置
transaction:  #分布式事务
  defaultType: XA
  providerType: Atomikos

sqlParser: #SQL 解析
  sqlCommentParseEnabled: false
  sqlStatementCache:
    initialCapacity: 2000
    maximumSize: 65535
  parseTreeCache:
    initialCapacity: 128
    maximumSize: 1024
2.2、 分片配置

官方文档-数据源配置
官方文档-分片规则

######################################################################################################
# Here you can configure the rules for the proxy. This example is configuration of sharding rule.
######################################################################################################
#数据源配置
databaseName: order #数据源配置（即对外的数据库名称），可配置多个（即分库）
dataSources: #测试就用了一个MySQL实例
  ds_0:
    url: jdbc:mysql://127.0.0.1:3306/order_0?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 10
    minPoolSize: 1
  ds_1:
    url: jdbc:mysql://127.0.0.1:3306/order_1?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 10
    minPoolSize: 1
#分片规则（即分表）
rules:
- !SHARDING
  tables:
    t_order: 
      actualDataNodes: ds_${0..1}.t_order_${0..1}  #由数据源名 + 表名组成。0..1表示分成两个库or表
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_inline
      keyGenerateStrategy: 
        column: order_id   # 自增列名称，缺省表示不使用自增主键生成器
        keyGeneratorName: snowflake
    t_order_item:
      actualDataNodes: ds_${0..1}.t_order_item_${0..1}
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_item_inline
      keyGenerateStrategy:
        column:  # 自增列名称，缺省表示不使用自增主键生成器
        keyGeneratorName: snowflake
    t_order_setting:
      actualDataNodes: ds_${0..1}.t_order_setting_${0..1}
      tableStrategy:
        complex:  # 用于多分片键的复合分片场景
          shardingColumns: user_id,id
          shardingAlgorithmName: t_order_setting_complex_inline
      keyGenerateStrategy:
        column: id
        keyGeneratorName: snowflake
      #auditStrategy:
        #auditorNames:
          #- sharding_key_required_auditor
        #allowHintDisable: true
  #自动分片      
  autoTables:
    t_order_shipping:
      actualDataSources: ds_${0..1}
      shardingStrategy:
        standard:
          shardingColumn: id
          shardingAlgorithmName: t_order_shipping_mod
  #绑定表规则列表
  bindingTables:
    - t_order,t_order_item
  #broadcastTables:
  #分库算法 
  defaultDatabaseStrategy:
    standard:
      shardingColumn: user_id
      shardingAlgorithmName: database_inline
  #分表算法    
  defaultTableStrategy:
    none:
  #defaultAuditStrategy:
   # auditorNames:
     # - sharding_key_required_auditor
    #allowHintDisable: true
  shardingAlgorithms:
    database_inline:
      type: INLINE
      props:
        algorithm-expression: ds_${user_id % 2}
    t_order_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_${order_id % 2}
    t_order_item_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_item_${order_id % 2}
    t_order_setting_complex_inline:
      type: COMPLEX_INLINE
      props:
        sharding-columns: user_id,id
        algorithm-expression: t_order_setting_${(user_id / 2 + id / 2) % 2}
    t_order_shipping_mod:
      type: MOD
      props:
        sharding-count: 4  #自动分片数量     
  # 分布式序列算法配置      
  keyGenerators:
    snowflake:
      type: SNOWFLAKE
  # 分片审计算法配置    
  auditors:
    sharding_key_required_auditor:
      type: DML_SHARDING_CONDITIONS
2.3、读写分离

官方文档-读写分离

######################################################################################################
# Here you can configure the rules for the proxy. This example is configuration of readwrite-splitting rule.
######################################################################################################
#数据源配置
databaseName: test_rw_split #数据源配置（即对外的数据库名称），可配置一个主库多个从库，这里只配置了一个从库做测试
dataSources:
  ds_0:
    url: jdbc:mysql://127.0.0.1:3306/test?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: sangfordb
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 10
    minPoolSize: 1
  ds_read_0_0:
    url: jdbc:mysql://127.0.0.1:3307/test?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1  
#读写分离配置    
rules:
- !READWRITE_SPLITTING
  dataSources:
    readwrite_ds:
      staticStrategy:
        writeDataSourceName: ds_0
        readDataSourceNames:
          - ds_read_0_0
      loadBalancerName: random
  loadBalancers: #从库负载均衡算法，有三种
    random:
      type: RANDOM #随机
    roundRobin:
      type: ROUND_ROBIN # 轮询
    weight:   
      type: WEIGHT #权重
      props:
        ds_read_0_0: 100

三、演练

第二章揭的配置调整好后，就重启容器，然后就可以用mysql cli连shardingspher-proxy实例了。
mysql -h 127.0.0.1 -P 3305 -uroot -p
密码也是 root。
进入后执行show databases：

mysql> show databases;
+--------------------+
| schema_name        |
+--------------------+
| information_schema |
| mysql              |
| order              |
| performance_schema |
| shardingsphere     |
| sys                |
| test_rw_split      |
+--------------------+
7 rows in set (0.01 sec)

可以看到分库分表的库order和读写分离的库test_rw_split 都有了

3.1、读写分离

读写分离测试前首先保证 3306和3307两个MySQL实例 主从复制正常，教程见主从搭建。
3306和3307两个MySQL实例都开启general_log，便于观察是否确实在从节点进行读，在主节点进行写

  • 建库
 CREATE DATABASE IF NOT EXISTS test DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;
  • 建表
CREATE TABLE `test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(15) NOT NULL,
  `pwd` varchar(15) NOT NULL,
  `flag` tinyint(3) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `ind_flag` (`flag`)
) ENGINE=InnoDB AUTO_INCREMENT=32 DEFAULT CHARSET=utf8mb4
  • 写：
mysql> insert into test(name,pwd,flag)values("ers","dft",68);

docker logs -f b58cdf57b50d
可以在shardingspher-proxy日志上看到：

[INFO ] 2023-07-02 10:48:07.261 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Logic SQL: insert into test(name,pwd,flag)values(“ers”,“dft”,100)
[INFO ] 2023-07-02 10:48:07.261 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_0 ::: insert into test(name,pwd,flag)values(“ers”,“dft”,100)

可以确实是在主节点执行，观察主从节点general_log也可以确定。

  • 读：
mysql> use test_rw_split;
mysql> select * from test where id=31\G;
*************************** 1. row ***************************
  id: 31
name: ers
 pwd: dft
flag: 68

可以在shardingspher-proxy日志上看到：

[INFO ] 2023-07-02 10:45:20.021 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Logic SQL: select * from test where id=31
[INFO ] 2023-07-02 10:45:20.022 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_read_0_0 ::: select * from test where id=31

可以看到确实是在从节点执行，观察主从节点general_log也可以确定。

目前支持一主多从的架构，不支持多主多从的架构

3.2、分库分表
  • 建库
 CREATE DATABASE IF NOT EXISTS order DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci;
  • 建表
CREATE TABLE `t_order` (
`id` bigint(20) NOT NULL,
`order_no` varchar(30) DEFAULT NULL,
`user_id` bigint(20) DEFAULT NULL,
`amount` decimal(10,2) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `t_order_item` (
`id` bigint(20) NOT NULL,
`order_id` bigint(20) NOT NULL,
`product_id` bigint(20) DEFAULT NULL,
`num` int(11) DEFAULT NULL comment '商品数量',
`price` decimal(10,2) DEFAULT NULL comment '商品单价',
`amount` decimal(10,2) DEFAULT NULL comment '商品总价',
PRIMARY KEY (`id`),
KEY `order_id` (`order_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4;

CREATE TABLE `t_order_shipping` (
`id` bigint(20) NOT NULL,
`order_id` bigint(20) NOT NULL,
`from_addr`  varchar(120) DEFAULT NULL comment '出发地',
`to_addr`  varchar(120) DEFAULT NULL comment '目的地',
PRIMARY KEY (`id`),
KEY `order_id` (`order_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4;

CREATE TABLE `t_order_setting` (
`id` bigint(20) NOT NULL,
`user_id` bigint(20) NOT NULL,
`down_order`  tinyint DEFAULT NULL comment '开启订单下载权限',
PRIMARY KEY (`id`),
) ENGINE=InnoDB  DEFAULT CHARSET=utf8mb4;
  • 结果
    以建表t_order为例，到3306 MySQL实例上查看可得到：
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| order_0            |
| order_1            |
| performance_schema |
| test               |
+--------------------+

mysql> use order_0;
Database changed
mysql> show tables;
+-------------------+
| Tables_in_order_0 |
+-------------------+
| t_order_0         |
| t_order_1         |
| t_order_item_0    |
| t_order_item_1    |
+-------------------+

可以看到建库建表都按照预设的分库分表规则自动在分片库上创建了；

  • 写
INSERT INTO `order`.`t_order`(`order_no`, `user_id`, `amount`) VALUES ('OID20230702001', 179468213359476736,22.01);

docker logs -f b58cdf57b50d
可以在shardingspher-proxy日志上看到：

[INFO ] 2023-07-02 10:14:36.788 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Logic SQL: INSERT INTO order.t_order(order_no, user_id, amount) VALUES (‘OID20230702001’, 179468213359476736,22.01)
[INFO ] 2023-07-02 10:14:36.788 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_0 ::: INSERT INTO t_order_0(order_no, user_id, amount, order_id) VALUES (‘OID20230702001’, 179468213359476736, 22.01, 882206737124294656)

我们预设的分库是user_id % 2，分表是order_id % 2，结果完全符合要求，并且order_id按照雪花算法自动生成了

  • 读
    1）命中分片键
 select * from t_order where user_id=179468213359476736 and order_id=779468213359476736\G;

shardingspher-proxy日志：

[INFO ] 2023-07-02 10:21:39.323 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Logic SQL: select * from t_order where user_id=179468213359476736 and order_id=779468213359476736
[INFO ] 2023-07-02 10:21:39.324 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_0 ::: select * from t_order_0 where user_id=179468213359476736 and order_id=779468213359476736

命中分片键 user_id+order_id，只查询了ds_0的t_order_0表。

2）没有命中分片键

select * from t_order where order_no="OID20230702001"\G;

shardingspher-proxy日志：

[INFO ] 2023-07-02 10:25:49.429 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Logic SQL: select * from t_order where order_no=“OID20230702001”
[INFO ] 2023-07-02 10:25:49.430 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_0 ::: select * from t_order_0 where order_no=“OID20230702001” UNION ALL select * from t_order_1 where order_no=“OID20230702001”
[INFO ] 2023-07-02 10:25:49.430 [Connection-2-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_1 ::: select * from t_order_0 where order_no=“OID20230702001” UNION ALL select * from t_order_1 where order_no=“OID20230702001”

没有命中分片键 user_id+order_id，需要到所有的分片查询。

3.3、分库分表+读写分离

官方文档-混合规则

只需将2.2小节和2.3小节的配置合在一起即可，如下：

######################################################################################################
# Here you can configure the rules for the proxy. This example is configuration of sharding rule.
######################################################################################################
#数据源配置
databaseName: order
dataSources:
  ds_0:
    url: jdbc:mysql://127.0.0.1:3306/order_0?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: sangfordb
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 10
    minPoolSize: 1
  ds_read_0_0:
    url: jdbc:mysql://127.0.0.1:3307/order_0?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1  
  ds_1:
    url: jdbc:mysql://127.0.0.1:3306/order_1?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: sangfordb
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 10
    minPoolSize: 1
  ds_read_1_0:
    url: jdbc:mysql://127.0.0.1:3307/order_0?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=UTF-8
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1   
rules:
 - !SHARDING
  tables:
    t_order: 
      actualDataNodes: ds_rw_${0..1}.t_order_${0..1} #读写分离
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_inline
      keyGenerateStrategy:
        column: order_id
        keyGeneratorName: snowflake
    t_order_item:
      actualDataNodes: ds_rw_${0..1}.t_order_item_${0..1}
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_item_inline
      keyGenerateStrategy:
        column: order_id
        keyGeneratorName: snowflake
    t_order_setting:
      actualDataNodes: ds_rw_${0..1}.t_order_setting_${0..1}
      tableStrategy:
        complex:
          shardingColumns: user_id,id
          shardingAlgorithmName: t_order_setting_complex_inline
      keyGenerateStrategy:
        column: user_id
        keyGeneratorName: snowflake
      #auditStrategy:
        #auditorNames:
          #- sharding_key_required_auditor
        #allowHintDisable: true
  autoTables:
    t_order_shipping:
      actualDataSources: ds_rw_${0..1}
      shardingStrategy:
        standard:
          shardingColumn: id
          shardingAlgorithmName: t_order_shipping_mod
      keyGenerateStrategy:
        column: id
        keyGeneratorName: snowflake
  bindingTables:
    - t_order,t_order_item
  #broadcastTables:

  defaultDatabaseStrategy:
    standard:
      shardingColumn: user_id
      shardingAlgorithmName: database_inline
  defaultTableStrategy:
    none:
  #defaultAuditStrategy:
   # auditorNames:
     # - sharding_key_required_auditor
    #allowHintDisable: true
  shardingAlgorithms:
    database_inline:
      type: INLINE
      props:
        algorithm-expression: ds_rw_${user_id % 2}
    t_order_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_${order_id % 2}
    t_order_item_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_item_${order_id % 2}
    t_order_setting_complex_inline:
      type: COMPLEX_INLINE
      props:
        sharding-columns: user_id,id
        algorithm-expression: t_order_setting_${(user_id / 2 + id / 2) % 2}
    t_order_shipping_mod:
      type: MOD
      props:
        sharding-count: 4
  keyGenerators:
    snowflake:
      type: SNOWFLAKE
  auditors:
    sharding_key_required_auditor:
      type: DML_SHARDING_CONDITIONS

 - !READWRITE_SPLITTING
  dataSources:
    ds_rw_0:
      staticStrategy:
        writeDataSourceName: ds_0
        readDataSourceNames:
          - ds_read_0_0
      loadBalancerName: random
    ds_rw_1:
      staticStrategy:
        writeDataSourceName: ds_1
        readDataSourceNames:
          - ds_read_1_0
      loadBalancerName: random  
  loadBalancers:
    random:
      type: RANDOM
  • 读
select * from t_order_shipping\G;

shardingspher-proxy日志：

[INFO ] 2023-07-02 11:36:44.740 [Connection-1-ThreadExecutor] ShardingSphere-SQL - Logic SQL: select * from t_order_shipping
[INFO ] 2023-07-02 11:36:44.740 [Connection-1-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_read_0_0 ::: select * from t_order_shipping_0 UNION ALL select * from t_order_shipping_2
[INFO ] 2023-07-02 11:36:44.740 [Connection-1-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_read_1_0 ::: select * from t_order_shipping_1 UNION ALL select * from t_order_shipping_3

可以看到是从两个从节点读取数据的。

  • 写
insert into t_order_shipping(id,order_id,from_addr,to_addr)values(882206737124294651,882206737124294656,'北京','南京');
#or
insert into t_order_shipping(order_id,from_addr,to_addr)values(882206737124294656,"北京","南京");

shardingspher-proxy日志：

[INFO ] 2023-07-02 11:53:18.101 [Connection-1-ThreadExecutor] ShardingSphere-SQL - Logic SQL: insert into t_order_shipping(id,order_id,from_addr,to_addr)values(882206737124294651,882206737124294656,“北京”,“南京”)
[INFO ] 2023-07-02 11:53:18.101 [Connection-1-ThreadExecutor] ShardingSphere-SQL - Actual SQL: ds_1 ::: insert into t_order_shipping_3(id,order_id,from_addr,to_addr)values(882206737124294651, 882206737124294656, ‘北京’, ‘南京’)

可以看到是从主节点ds-1写入数据的。

四、总结

官方文档-分片算法
从官方文档可以看到有许多分片算法，主要可以概括为哈希分片和范围分片。
从上一篇我们知道了二者的缺陷，为何没有引入一致性哈希算法？
或者像MongoDB那样先对分片键哈希再按其哈希值进行范围分片呢？

pigfu
关注
  • 2
    点赞
  • 踩
  • 11
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
分库分表+mysql+技术方案分享
02-03
MySQL 架构的演变主要经历了从单机单库到主从架构，再到分库分表的三个阶段。 1. **单机单库**：早期简单的应用，所有数据存储在一个MySQL实例中。随着数据量和读写操作的增加，单机难以承受，且一旦服务器故障，...
MyBatis实现Mysql数据库分库分表操作和总结（推荐）
08-29
MyBatis实现Mysql数据库分库分表操作和总结 MyBatis是一款流行的持久层框架，能够与Mysql数据库进行交互。在大规模的应用系统中，数据库的性能和可扩展性变得非常重要。为了解决这个问题，需要实现数据库的分库分表...
mysql 分库分表、 分区（partition）、sharding-sphere 综合整理
何xiao树
01-17 1571
mysql 分开分表分区 记录处理，sharding-sphere 整合处理
Mysql高可用高性能存储应用系列4 - 分库分表、中间件
stark张宇
03-31 457
为什么要分库的原因：1)很多时候接口性能慢都是数据库造成的,2)并发量比较大时，大量的数据库请求，会带来磁盘I/O的性能瓶颈，3)来越多，导致sql查询数据，即使走了索引也比较慢。
【分库分表】基于mysql+shardingSphere的分库分表技术
最新发布
java骨灰级码农，10年IT从业经验
05-29 57
分库分表分库分表是一种场景解决方案，它的出现是为了解决一些场景问题的，哪些场景喃？单表过大的话，读请求进来，查数据需要的时间会过长读请求过多，单节点IO压力太大，IO压力太大会造成什么？可能会造成IO阻塞，造成响应速度变慢。分库分表是指的两种维度，一种维度是分库，另一种维度是分表。分的话有两种分法，一种是水平分，另一种是垂直分。水平分是指将数据分为多段，一个服务器节点上存放一段，读写的时候走自己要的那一段所在服务器上。一段也叫一个分片（sharding）
Mysql数据库分库分表问题+引发问题+中间件对比分析
LY201704060320的博客
10-08 1188
详细说明了mysql分库分表的各种问题：怎么分表、常见中间件优缺点、如何扩容等
MySQL_11_ShardingJDBC实现分库分表
毛毛的专栏
02-26 2395
文章目录一、前言二、关系型数据库层面的高并发优化2.1 MYSQL海量数据带来的性能问题2.2 分片策略2.3 分布式ID2.3.1 定义全局表2.3.2 UUID2.3.3 雪花算法2.3 常见分库分表策略2.4 分库分表实战2.5 分库分表带来的问题三、Sharding-JDBC分库分表（uuid 雪花算法 SPI机制）四、ShardingSphere读写分离和分布式事务（理论+实战）4.1 读写分离4.2 分布式事务2.2 详解分库分表2.3 常见分库分表策略2.4 分库分表实战2.5 分库分表带来的
使用shardingsphere实现mysql数据库分片（分库分表的实现方式）、读写分离、弹性伸缩的设计
热门推荐
前路无畏的博客
10-24 1万+
1.对shardingsphere学习的建议，也是对所有技术学习的建议 shardingsphere和mycat类似，均是高可用数据库的解决方案中间件。这里采用shardingsphere。 如果大家对shardingsphere不了解，先找些文章或者视频看一下，入门一下，然后需要看官方文档，你在看别人的文章或者东西的时候是一个快餐，而你看官方文档的时候才是大餐，所以请一定不要错过大餐。shardingsphere官方文档：https://shardingsphere.apache.org/documen
数据库读写分离(主从复制)和分库分表详解
2302_77971734的博客
03-31 1910
读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。这样的话，就能够小幅提升写性能，大幅提升读性能。其实分库分表是牵扯到高并发的，因为分库分表无非来说就是为了支撑高并发、数据量大的问题。尤其进入稍微大一点的公司或者互联网公司，这些都是必须掌握的！分库：从单个数据库拆分成多个数据库的过程，将数据散落在多个数据库中。分表：从单张表拆分成多张表的过程，将数据散落在多张表内。数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。
MySql详解（七）--分库分表篇
qq_35105015的博客
03-13 2701
Mysql详解-分库分表篇
基于Mycat实现Mysql读写分离以及分库分表.doc
09-22
基于Mycat实现Mysql读写分离以及分库分表详解 本文档详细介绍了基于Mycat实现Mysql读写分离以及分库分表的技术，涵盖了Mycat安装、配置、读写分离、分库分表等多方面的知识点。 一、读写分离 Mycat读写分离是指将...
php mysql分库分表实例
08-28
在IT行业中，数据库管理和优化是...通过合理地分库分表，可以有效地提升系统处理能力，同时需要充分理解并处理随之带来的挑战，如数据一致性、查询复杂度等。在这个实例中，各个PHP文件协同工作，共同实现了这一目标。
java mysql 分库分表详解
01-30
在Java和MySQL数据库环境中，分库分表是一种常见的解决大数据量和高并发问题的策略。随着互联网业务的快速发展，单个数据库往往无法满足性能和扩展性的需求，这时就需要采用分库分表技术来优化系统架构。 分库是将...
Sharding-JDBC实现读写分离
Coder_ljw的博客
07-23 619
本篇文章主要讲解了Sharding-JDBC实现读写分离，实操过程非常重要，大家一定要动手亲自实践一下，必须掌握。下节预告，ShardingSphere分库分表实战之强制路由详解与实战，敬请期待。
mysql中的分库分表的中间件（mycat和ShardingPhere）
荣山的博客
03-23 179
mysql中的分库分表的中间件（mycat和ShardingPhere）
mysql 分库分表中间件 （待补充）
猎人在吃肉
03-03 1004
sharding-jdbc 在介绍多库多表的时候，给大家介绍一个轻量级 分库分表 工具，sharding-jdbc，这是当当网自己实现的基本JDBC的数据库多库多表解决方案。可以让你在写业务代码的时候完全按照单库单表进行，多库多表的问题有sharding-jdbc帮你解决，需要自己实现分库分表规则接口，配置分库分表规则。 实现分库规则接口： public class DemoDatabaseSha...
ShardingJdbc 分库分表 读写分离
kutianya518的博客
10-31 1433
1、核心概念 1.1逻辑表 水平拆分的数据库（表）的相同逻辑和数据结构表的总称，如温度数据表，根据上传的日期，一月可以分为31张表，temp_1.....temp_31，它们的逻辑表名就是temp。 配置文件对应信息：spring.shardingsphere.sharding.tables.temp 2、数据分片 2.1分片键 用于分片的数据库字段，是将数据库(表)水平拆分的关键字段。 例如：将温度表中上传时间temppoint,取yyyy-MM-dd中的天对表进...
Sharding-Jdbc 实现读写分离 + 分库分表，写得太好了……
Java技术栈，分享最主流的Java技术
11-09 877
1、概览 ShardingSphere-Jdbc定位为轻量级Java框架，在Java的Jdbc层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，可理解为增强版的Jdbc驱动，完全兼容Jdbc和各种ORM框架 2、MySQL主从复制 1）、docker配置mysql主从复制 1）创建主服务器所需目录 mkdir -p /usr/local/mysqlData/master/cnf mkdir -p /usr/local/mysqlData/master/data2）定义主服务器配置文件 vi
ShardingSphere一套开源的分布式数据库中间件解决方案
纸上得来终觉浅，绝知此事要躬行
01-26 3177
项目地址：https://github.com/apache/incubator-shardingsphere 文档地址：http://shardingsphere.apache.org/document/current/cn/overview/ 1. 概览 2. 快速入门 2.1. Sharding-JDBC 2.2. Sharding-Proxy 3. 概念 &...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值