分表分库解决⽅案（mycat,tidb,shardingjdbc）
公司最近有分表分库的需求，所以整理⼀下分表分库的解决⽅案以及相关问题。
1.sharding-jdbc（sharding-sphere）
优点：
1.可适⽤于任何基于java的ORM框架，如:JPA、Hibernate、Mybatis、Spring JDBC Template，或直接使⽤JDBC
2.可基于任何第三⽅的数据库连接池，如:DBCP、C3P0、Durid等
3.分⽚策略灵活，可⽀持等号、between、in等多维度分⽚，也可⽀持多分⽚键。
4.SQL解析功能完善,⽀持聚合、分组、排序、limit、or等查询，并⽀持Binding Table以及笛卡尔积表查询。
5.性能⾼，单库查询QPS为原⽣JDBC的99.8%，双库查询QPS⽐单库增加94%。
缺点：
1.理论上可⽀持任意实现JDBC规范的数据库。⽬前仅⽀持mysql
2.维护会⽐较⿇烦，需要逐个项⽬的修改配置。不能进⾏跨库连接，代码需要进⾏改造。
3.在扩展数据库服务器时需要考虑⼀致性哈希问题，或者采⽤分⽚键局部取模⽅式，也难免要进⾏部分的数据迁移。
优点：
1.⽀持Mysql集，可以作为Proxy使⽤
2.⽀持JDBC连接ORACLE、DB2、SQL Server，将其模拟为MySQL Server使⽤
3.⾃动故障切换，⾼可⽤性
4.⽀持读写分离，⽀持Mysql双主多从，以及⼀主多从的模式，⽀持全局表，数据⾃动分⽚到多个节点，⽤于⾼效表关联查询
5.⽀持独有的基于E-R 关系的分⽚策略，实现了⾼效的表关联查询
6.多平台⽀持，部署和实施简单
jpa mybatis缺点：
3.tidb
优点：
1 .⾼度兼容 MySQL  ⼤多数情况下，⽆需修改代码即可从 MySQL 轻松迁移⾄ TiDB，分库分表后的 MySQL 集亦可通过 TiDB ⼯具进⾏实时迁移。
2.⽔平弹性扩展　通过简单地增加新节点即可实现 TiDB 的⽔平扩展，按需扩展吞吐或存储，轻松应对⾼并发、海量数据场景。
3.分布式事务　TiDB 100% ⽀持标准的 ACID 事务。
4. 真正⾦融级⾼可⽤相⽐于传统主从 (M-S) 复制⽅案，基于 Raft 的多数派选举协议可以提供⾦融级的
100% 数据强⼀致性保证，且在不丢失⼤多数副本的前提下，可以实现故障的⾃动恢复 (auto-failover)，⽆需⼈⼯介⼊。
5 .⼀站式 HTAP 解决⽅案　TiDB 作为典型的 OLTP ⾏存数据库，同时兼具强⼤的 OLAP 性能，配合 TiSpark，可提供⼀站式 HTAP解决⽅案，⼀份存储同时处理OLTP & OLAP⽆需传统繁琐的 ETL 过程。
6.云原⽣ SQL 数据库    TiDB 是为云⽽设计的数据库，同 Kubernetes深度耦合，⽀持公有云、私有云和混合云，使部署、配置和维护变得⼗分简单。
缺点：该项⽬较新，还没有经过⼤量的⽣产环境检验，可能会存在⼀定的风险。
不适⽤场景：
(1) 单机 MySQL 能满⾜的场景也⽤不到 TiDB。
(2) 数据条数少于 5000w 的场景下通常⽤不到 TiDB，TiDB 是为⼤规模的数据场景设计的。
(3)如果你的应⽤数据量⼩（所有数据千万级别⾏以下），且没有⾼可⽤、强⼀致性或者多数据中⼼复制等要求，那么就不适合使⽤ TiDB。下⾯详细讲⼀下mycat，因为部署和对系统的改造量相对较⼩，但实测mycat的⽹络消耗和线程池的问题对性能的消耗还是挺严重的，所以还是根据现有情况选择。
mycat
1.架构
如图所⽰：MyCAT使⽤Mysql的通讯协议模拟成了⼀个Mysql服务器，并建⽴了完整的Schema（数据库）、Table （数据表）、User(⽤户)的逻辑模型，并将这套逻辑模型映射到后端的存储节点DataNode（MySQL Instance）上的真实物理库中，这样⼀来，所有能使⽤Mysql的客户端以及编程语⾔都能将MyCAT当成是Mysql Server来使⽤，不必开发新的客户端协议。
2.⼯作原理
Mycat的原理中最重要的⼀个动词是“拦截”，它拦截了⽤户发送过来的SQL语句，⾸先对SQL语句做了⼀些特定的分析：如分⽚分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给⽤户。
当Mycat收到⼀个SQL时，会先解析这个SQL，查涉及到的表，然后看此表的定义，如果有分⽚规则，则获取到SQL⾥分⽚字段的值，并匹配分⽚函数，得到该SQL对应的分⽚列表，然后将SQL发往这些分⽚去执⾏，最后收集和处理所有分⽚返回的结果数据，并输出到客户端。以select * from Orders where prov=?语句为例，查到prov=wuhan，按照分⽚函数，wuhan返回dn1，于是SQL就发给了MySQL1，去取DB1上的查询结果，并返回给⽤户。
3.分⽚策略(分表分库)
MyCAT通过定义表的分⽚规则来实现分⽚，每个表格可以捆绑⼀个分⽚规则，每个分⽚规则指定⼀个分⽚字段并绑定⼀个函数，来实现动态分⽚算法。
1、Schema：逻辑库，与MySQL中的Database（数据库）对应，⼀个逻辑库中定义了所包括的Table。
2、Table：表，即物理数据库中存储的某⼀张表，与传统数据库不同，这⾥的表格需要声明其所存储的逻辑数据节点DataNode。在此可以指定表的分⽚规则。
3、DataNode：MyCAT的逻辑数据节点，是存放table的具体物理节点，也称之为分⽚节点，通过DataSource来关联到后端某个具体数据库上
4、DataSource：定义某个物理库的访问地址，⽤于捆绑到Datanode上
4.分⽚规则
1.分⽚枚举通过在配置⽂件中配置可能的枚举 id，⾃⼰配置分⽚，本规则适⽤于特定的场景，⽐如有些业务需要按照省份或区县来做保存，⽽全国省份区县固定的，这类业务使⽤本条规则.
2.固定分⽚ hash 算法本条规则类似于⼗进制的求模运算，区别在于是⼆进制的操作，是取 id 的⼆进制低 10 位，即 id ⼆进制
&1111111111。此算法的优点在于如果按照 10 进制取模运算，在连续插⼊ 1-10 时候 1-10 会被分到 1-10 个分⽚，增⼤了插⼊的事务控制难度，⽽此算法根据⼆进制则可能会分到连续的分⽚，减少插⼊事务事务控制难度。
3.按⽇期分⽚此规则为按天分⽚。按单⽉⼩时拆分此规则是单⽉内按照⼩时拆分，最⼩粒度是⼩时，可以⼀天最多 24 个分⽚，最少 1 个分⽚，⼀个⽉完后下⽉从头开始循环。每个⽉⽉尾，需要⼿⼯清理数据。
4.截取数字 hash 解析此规则是截取字符串中的 int 数值 hash 分⽚。
5.⽇期范围 hash 分⽚思想与范围求模⼀致，当由于⽇期在取模会有数据集中问题，所以改成 hash ⽅法。先根据⽇期分组，再根据时间hash 使得短期内数据分布的更均匀。优点可以避免扩容时的数据迁移，⼜可以⼀定程度上避免范围分⽚的热点问题。要求⽇期格式尽量精确些，不然达不到局部均匀的⽬的
6.⼀致性 hash ⼀致性哈希主要应⽤于分布式集对机器添加、删除的管理 1 按照常⽤hash算法将要管理的对象映射到⼀个2^32-1的闭合环形上 2 按照常⽤hash算法将机器映射也映射到此闭合环形上 3 以顺时针计算，将要管理的对象纳⼊离⾃⼰最近的机器上
4.删除节点时，该机器存储的对象按照顺时针就近原理分配到临近机器上
5.增加节点时，按照哈希算法获得机器hash值，然后把临近对象分配到该节点
6. 通过虚拟节点⽅式，增加hash环节点的密集度，保障平衡性特性: 1 平衡性：各节点的对象个数相对均衡 2 单调性：新对象加⼊时不影响原对象的存储位置 3 分散性：相同内容会被分散到相同节点 4 负载：同⼀个节点不能被不同⽤户映射不同内容
5.读写分离
数据库读写分离对于⼤型系统或者访问量很⾼的互联⽹应⽤来说，是必不可少的⼀个重要功能。对于MySQL来说，标准的读写分离是主从模式，⼀个写节点Master后⾯跟着多个读节点，读节点的数量取决于系统的压⼒，通常是1-3个读节点的配置 Mycat读写分离和⾃动切换机制，需要mysql的主从复制机制配合。
1、主DB server和从DB server数据库的版本⼀致
2、主DB server和从DB server数据库数据⼀致[ 这⾥就会可以把主的备份在从上还原，也可以直接将主的数据⽬录拷贝到从的相应数据⽬录]
3、主DB server开启⼆进制⽇志，主DB server和从DB server的server_id都必须唯⼀
准备阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送准备消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执⾏事务，写本地的redo和undo⽇志但不提交，可以进⼀步将准备阶段分为以下三个步骤： 1）协调者节点向所有参与者节点询问是否可以执⾏提交操作(vote)，并开始等待各参与者节点的响应。 2）参与者节点执⾏询问发起为⽌的所有事务操作，并将Undo信息和Redo信息写⼊⽇志。 3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执⾏成功，则它返回⼀个”同意”消息；如果参与者节点的事务操作实际执⾏失败，则它返回⼀个”中⽌”消息。提交阶段：如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息，否则发送提交(Commit)消息，参与者根据协调者的指令执⾏提交或者回滚操作，释放所有事务处理过程中使⽤的锁资源。⼆阶段提交所存在缺点的： 1）同步阻塞问题，执⾏过程中所有参与节点都是事务阻塞型的，当参与者占有公共资源时，其他第三⽅节点访问公共资源不得不处于阻塞状态。 2）单点故障，由于协调者的重要性⼀旦协调者发⽣故障参与者会⼀直阻塞下去。 3）数据不
⼀致，在⼆阶段提交的阶段⼆中，当协调者向参与者发送commit请求之后，发⽣了局部⽹络异常或者在发送commit请求过程中协调者发⽣了故障，这回导致只有⼀部分参与者接受到了commit请求，⽽在这部分参与者接到commit请求之后就会执⾏commit操作，但是其他部分未接到commit请求的机器则⽆法执⾏事务提交，于是整个分布式系统便出现了数据部⼀致性的现象。
1.⾮分⽚字段查询如果该分⽚字段选择度⾼，也是业务常⽤的查询维度，⼀般只有⼀个或极少数个DB节点命中（返回结果集）。⽰例中只有3个DB节点，⽽实际应⽤中的DB节点数远超过这个，假如有50个，那么前端的⼀个查询，落到MySQL数据库上则变成50个查询，会极⼤消耗Mycat和MySQL数据库资源。
2.分页排序但Mycat向应⽤返回的结果集取决于哪个DB节点最先返回结果给Mycat。如果Mycat最先收到DB1节点的结果集，那么Mycat返回给应⽤端的结果集为 [0,1]，如果Mycat最先收到DB2节点的结果集，那么返回给应⽤端的结果集为 [5,6]。也就是说，相同情况下，同⼀个SQL，在Mycat上执⾏时会有不同的返回结果。
3.任意表JOIN ⽆法跨库join
4.分布式事务 Mycat并没有根据⼆阶段提交协议实现 XA事务，⽽是只保证 prepare 阶段数据⼀致性的弱XA事务

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。