Sharding-Proxy分库分表

一 安装：

juejin.im/post/1

二资源

ROLE

master1

slave1

slave2

Sharding

三为什么分库分表

业务越来越大，数据库扛不住啊。

扛不住会怎样呢？数据库性能降低

解决方法：

1 增加mysql硬件资源

2 历史数据归档

3 增加数据库—— 读写分离

4 增加数据库—— 分库分表

5 云数据库TIDB

四如何分库分表

1 垂直拆分 -- 微服务化 -- 一个服务一个库

1) 每个库(表)的数据结构一般不同
2) 每个库(表)至少有一个列一样—— 为了join

缺点：
1)数据不均衡。

2 水平拆分--分库分表 -- 数据存的不一样

1)每个库(表)的数据结构都一样
2)双十一订单大，订单一定均分到012库中，解决数据热点问题

缺点：1)扩容的问题，麻烦

3 水平拆分和垂直拆分结合：垂直拆库，水平拆表

五Sharding-Proxy分库分表实战

1 master建库建表

库：
bookstore_0
bookstore_1
在库中分别建表：
bookinfo_0
bookinfo_1

2 修改Config-sharding.yaml

①把mysql驱动jar包复制到lib文件夹下

②config-sharding.yaml

schemaName: bookstore

dataSources:
  bookstore_0:
    url: jdbc:mysql://IP:3306/bookstore_0?serverTimezone=UTC&useSSL=false
    username: root
    password: 
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
  bookstore_1:
    url: jdbc:mysql://IP:3306/bookstore_0?serverTimezone=UTC&useSSL=false
    username: root
    password: 
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50

shardingRule:
  tables:
    bookinfo:
      actualDataNodes: bookstore_${0..1}.bookinfo_${0..1}
      databaseStrategy:
        inline:
          shardingColumn: storeid
          algorithmExpression: bookstore_${storeid % 2}
      tableStrategy:
        inline:
          shardingColumn: bookid
          algorithmExpression: bookinfo_${bookid % 2}
      #keyGenerator:
        #type: SNOWFLAKE
        #column: order_id

  bindingTables:
    - bookinfo
  defaultDatabaseStrategy:
    inline:
      shardingColumn: storeid
      algorithmExpression: bookstore_${storeid % 2}
  defaultTableStrategy:
    none:

•  mysql -hIP -uroot -P3307 -p     

4 进行sql命令操作，只能看到一个库

5 插入数据。Sharding-Proxy代理端里有数据了

6 连接真正的数据库

这里有个问题：
分库失败，全部写入bookstore_0
分表成功