本文共 1203 字，大约阅读时间需要 4 分钟。

垂直拆分

水平拆分

分库分表解决方案

技术方案：proxy或应用层

proxy: mycat-cobar(社区), atlas(数字),heinsberge(百度),vitess(youtube)

应用层：sharding-jdbc(当当)，TDDL(阿里)

拆分的原则

• 能不拆分尽量不拆分
•  如果要拆分一定要选择合适的拆分规则，提前规划好
•  数据拆分尽量通过数据冗余或表分组来降低跨库join的可能
•  跨库join是共同难题，所以业务读取尽量少使用多表join

mycat

    mycat就是一个数据库中间件，数据库的代理，它屏蔽了物理数据库，应用连接mycat，然后mycat再连接物理数据库 

分片规则和策略     （多种策略，可自定义）

分布式全局唯一ID（多种分布式全局唯一ＩＤ）

多数据源管理问题（统一管理所有数据源）

跨库跨表join问题　（全局表、ｓｈａｒｄｊｏｉｎ、ｃａｔｌｅｔ）

其它特点

整体架构图

核心的配置文件

server.xml：是Mycat服务器参数调整和用户授权的配置文件。

schema.xml：是逻辑库定义和表以及分片定义的配置文件。

rule.xml：是分片规则的配置文件，分片规则的具体一些参数信息单独存放为文件，也在这个目录下，配置文件修改需要重启MyCAT。

log4j.xml：日志存放在logs/log中，每天一个文件，日志的配置是在conf/log4j.xml中，根据自己的需要可以调整输出级别为debug；debug级别下，会输出更多的信息，方便排查问题。

分片相关的id分片规则配置文件

autopartition-long.txt

partition-hash-int.txt

sequence_conf.properties

sequence_db_conf.properties

高可用架构

分库分表问题

垂直拆分带来的问题：

• 部分业务表无法join，只能通过接口方式，提高了系统复杂度
•  存在单表性能瓶颈，不易扩展 1000w 10张表 1亿
•  事务处理复杂

水平拆分带来的问题：

• 拆分规则难以抽象
•  分片事务一致性难以解决
•  维护难度极大
•  跨库join性能差

共同带来的问题

• 分片规则和策略
• 分布式全局唯一ID  
• 多数据源管理问题   多个datasource
•  跨库跨表join问题
• 跨节点合并排序分页问题
• 事务复杂，带来了分布式事务问题
• 数据管理难度加大（出问题后所有相关联的人都会MMP）

转载地址：http://qujdi.baihongyu.com/