引言
上篇有关分分库分表一文中已经将分库分表的方法论全面阐述清楚了，总体看下来用一个字形容，那就是爽！（手动狗头）尤其是分库分表技术能够让数据存储层真正成为三高架构，但前面爽是爽了，接着一起来看看分库分表后产生一系列的后患问题，注意我这里的用词，是一系列而不是几个，也就是分库分表虽然好，但你要解决的问题是海量的。
一、垂直分表后带来的隐患
垂直分表后当试图读取一条完备数据时，需要毗连多个表来获取，对于这个问题只要在切分时，设置好映射的外键字段即可。当增、删、改数据时，往往需要同时操纵多张表，并且要保证操纵的原子性，也就是得手动开启事务来保证，否则会出现数据差别等的问题。
这里可以看到，垂直分表虽然会有后患问题，但带来的问题本质上也不算大问题，就是读写数据的操纵会相对贫苦一些，下面来看看其他的分库分表方案，接下来是真正的重头戏。
二、程度分表后带来的问题
程度分表就是将一张大表的数据，按照肯定的规则划分成差别的小表，当原本的一张表变为多张表时，虽然提升了性能，但问题随之也来了~
2.1、多表联查问题（Join）
之前在库中只存在一张表，所以非常轻松的就能进行联表查询获取数据，但是此时做了程度分表后，同一张业务的表存在多张小表，这时再去连表查询时具体该毗连哪张呢？似乎这时问题就变的贫苦起来了，怎么办？解决方案如下：
- ①假如分表数量是固定的，直接对所有表进行毗连查询，但如许性能开销较大，还不如不分表。
- ②假如不想用①，或分表数量会随时间不绝变多，那就先根据分表规则，去确定要毗连哪张表后再查询。
- ③假如每次连表查询只需要从中获取1~3个字段，就直接在另一张表中设计冗余字段，避免连表查询。
第一条好明白，第二条是啥意思呢？好比现在是按月份来分表，那在连表查询前，就先确定要毗连哪几张月份的表，才能得到本身所需的数据，确定了之后再去查询对应表即可，这里该如何落地实现呢？各人别急，会在后续的《库内分表篇》去详细讲解。
2.2、增编削数据的问题
当想要增加、删除、修改一条数据时，因为存在多张表，所以又该去哪张表中操纵呢？这里还是前面那个问题，只要在操纵前确定好具体的表即可。但另有一种情况，就是批量变动数据时，也会存在问题，要批量修改的数据该具体操纵哪几张分表呢？依旧需要先定位到具体分表才行。
2.3、聚合操纵的问题
之前因为只有一张表，所以进行sum()、count()....、order by、gorup by....等各类聚合操纵时，可以直接基于单表完成，但此刻似乎行不通了呀？对于这类聚合操纵的解决方案如下：
- ①放入第三方中间件中，然后依靠于第三方中间件完成，如ES。
- ②定期跑脚本查询出一些常用的聚合数据，然后放入Redis缓存中，后续从Redis中获取。
- ③首先从所有表中统计出各自的数据，然后在Java中作聚合操纵。
前面两种操纵比力好明白，第三种方案是什么意思呢？好比count()函数，就是对所有表进行统计查询，最后在Java中求和，好比分组、排序等工作，先从所有表查询出符合条件的数据，然后在Java中通过Stream流进行处置惩罚。
上述这三种方案都是比力合理且通例的方案，最好是选择第一种，这也是一些大企业选用的方案。
到这里就大致聊清楚了单库中分表的一些主要问题，一样平常情况下库内无需做分表，只有一些特别场景下需要做，具体的会在后续《库内分表篇》讲解，下面聊聊分库问题，分库带来的问题更多更复杂。
三、垂直分库后产生的问题
垂直分库是按照业务属性的差别，直接将一个综合大库拆分成多个功能单一的独享库，分库之后能够让性能提升N倍，但随之而来的是需要解决更多的问题，而且问题会比单库分表更复杂！
3.1、跨库Join问题
因为将差别业务的表拆分到了差别的库中，而往往有些情况下大概会需要其他业务的表数据，在单库时直接join连表查询相应字段数据即可，但此时已经将差别的业务表放到差别库了，这时咋办？跨库Join也不太现实呀，此时有如下几种解决方案：
- ①在差别的库需要数据的表中冗余字段，把常用的字段放到需要要数据的表中，避免跨库连表。
- ②选择同步数据，通过广播表/网络表/全局表将对应的表数据直接完全同步一份到相应库中。
- ③在设计库表拆分时创建ER绑定表，具备主外键的表放在一个库，保证数据落到同一数据库。
- ④Java体系中组装数据，通过调用对方服务接口的情势获取数据，然后在步伐中组装后返回。
这四种方案都能够解决需要跨库Join的问题，但第二、三种方案提到了广播表/网络表/全局表、ER绑定表似乎之前没听说过对嘛？这实在是分库分表中的一些表名词，后续《分库分表实践篇》具体落地时会详细讲解。但往往垂直分库的场景中，第四种方案是最常用的，因为分库分表的项目中，Java业务体系那边也绝对接纳了分布式架构，因此通过调用对端API接口来获取数据，是分布式体系最为常见的一种现象。
3.2、分布式事务问题
分布式事务应该是分布式体系中最核心的一个问题，这个问题绝对不能出现，一样平常都要求零容忍，也就是所有分布式体系都必须要解决分布式事务问题，否则就有大概造成数据差别等性。
在之前单机的MySQL中，数据库自身提供了完善的事务管理机制，通过begin、commit/rollback的下令可以灵活的控制事务的提交和回滚，在Spring要对一组SQL操纵利用事务时，也只需在对应的业务方法上加一个@Transactional注解即可，但这种情况在分布式体系中就不可了。
为什么说MySQL的事务机制会在分布式体系下失效呢？因为InnoDB的事务机制是建立在Undo-log日记的底子上完成的，以前只有一个Undo-log日记，所以一个事务的所有变动前的数据，都可以记录在同一个Undo-log日记中，当需要回滚时就直接用Undo-log中的旧数据覆盖变动过的新数据即可。
但垂直分库之后，会存在多个MySQL节点，这自然也就会存在多个Undo-log日记，差别库的变动操纵会记录在各自的Undo-log日记中，当某个操纵实行失败需要回滚时，仅能够回滚自身库变动过的数据，对于其他库的事务回滚权，当前节点是不具备该能力的，所以此时就必须要出现一个事务管理者来介入，从而解决分布式事务问题。
上述提到的通过第三方：事务管理者来介入，这只属于分布式事务问题的一种解决方案，解决方案如下：
- ①Best Efforts 1PC模式。
- ②XA 2PC、3PC模式。
- ③TTC事务补偿模式。
- ④MQ最终同等性事务模式。
上述是解决分布式事务问题的四种思想，目前最常用的Seata的两种模式就是基于XA-3PC和TCC思想实现的，但对于这些具体的讲解，会放到后面的《分布式事务篇》中讲解，这里相识即可。
3.3、部门业务库依旧存在性能瓶颈问题
这种情况前面说到过，颠末垂直分库之后，某些核心业务库依旧需要承载过高的并发流量，因此一单节点模式部署，依然无法解决所存在的性能瓶颈，对于这种情况直接再做程度分库即可，具体过程请参考阶段二。
四、程度分库后需要解决的问题
程度分库这种方案，能够建立在垂直分库的底子上，进一步对存储层做拓展，能够让某些业务库具备更高的并发处置惩罚能力，不过程度分库虽然带来的性能收益巨大，但产生的问题也最多！
4.1、聚合操纵和连表问题
对单个业务库做了程度分库后，也就是又对单个业务库做了横向拓展后，一样平常都会将库中所有的表做程度切分，也就是差别库中的所有表，每个程度库节点中存储的数据是差别的，这时又会出现4.2阶段聊到的一些问题，如单业务的聚合操纵、连表操纵会无法进行，这种情况的解决思绪和程度分表时一样，先确定读写的数据位于哪个库表中，然后再去生成SQL并实行。
当然，对于这类情况，假如只是因为并发过高导致出现性能瓶颈，最好的选择是直接做业务库集群，也就是拓展出的所有节点，数据都存一模一样的，如许无论在任何库中都具备完备数据，所以就无需先定位目标数据所处的库再操纵。
但假如数据量也比力大，就只能做程度分库分表了，相同业务差别的数据库节点，存储差别范围的数据，能够在最大程度上提升存储层的吞吐能力，但会让读写操纵困难度增高，因为读写之前需要先定位读写操纵到底要落到哪个节点中处置惩罚。
4.2、数据分页问题
以MySQL数据库为例，假如是在之前的单库环境中，可以直接通过limit index,n的方式来做分页，而程度分库后由于存在多个数据源，因此分页又成为了一个难题，好比10条数据为1页，那假如想要拿到某张表的第一页数据，就必须通过如下本领获取：
这种方式可以是可以，但略微有些繁杂，同时也会让拓展性受限，好比原本有两个程度分库的节点，因此只需要从两个节点中拿到第一页数据，然后再做一次过滤即可，但假如程度库从两节点扩容到四节点，这时又要从四个库中各自拿10条数据，然后做过滤操纵，读取前十条数据显示，这显然会导致每次扩容需要改动业务代码，对代码的侵入性有些强，所以合理的解决方案如下：
- ①常用的分页数据提前聚合到ES或中间表，运行期间跑按时更新此中的分页数据。
- ②利用大数据技术搭建数据中台，将所有子库数据汇聚到此中，后续的分页数据直接从中获取。
- ③上述聊到的那种方案，从所有字库中先拿到数据，然后在Service层再做过滤处置惩罚。
上述第一种方案是较为常用的方案，但这种方案对数据及时性会有肯定的影响，利用该方案必须要能接受肯定延时。第二种方案是最佳的方案，但需要搭建完善的大数据体系作为底子，本钱最高。第三种方案本钱最低，但对拓展性和代码侵入性的粉碎比力严重。
4.3、ID主键的唯一性问题
在之前的单库环境时，对于一张表的主键通常会选用整数型字段，然后通过数据库的自增机制来保证唯一性，但在程度分库多节点的情况时，假设还是以数据库自增机制来维护主键唯一性，这就绝对会出现肯定的问题，大概会导致多个库中出现ID相同、数据差别的情况，如下：
上述两个库需要存储差别的数据，当插入数据的哀求被分发到对应节点时，假如再依据自增机制来确保ID唯一性，因为这里有两个数据库节点，两个数据库各自都维护着一个自增序列，因此两者ID值都是从1开始往上递增的，这就会导致前面说到的ID相同、数据差别的情况出现，那此时又该如何解决呢？如下：
这时可以根据程度库节点的数量来设置自增步长，假设此时有两个库，那自增步长为2，两个库的ID起始值为：{DB1:1}、{DB2:2}，最终达到上图中的效果，无论在插入数据的操纵落入哪个节点，都能够确保ID的唯一性。当然，保障分布式体系下ID唯一性的解决方案许多，如下：
- ①通过设置数据库自增机制的起始值和步长，来控制差别节点的ID交叉增长，保证唯一性。
- ②在业务体系中，利用特别算法生成有序的分布式ID，好比雪花算法、Snowflake算法等。
- ③利用第三方中间件生产ID，如利用Redis的incr下令、或创建独立的库专门做自增ID工作。
上述这几种方案都是较为主流的分布式ID生成的方案，同时也能够保证ID的有序性，能够最大程度上维护索引的性能，相对来说第一种方案本钱最低，但是会限制节点的拓展性，也就是当后续扩容时，数据要做迁移，同时要重新修改起始值和自增步长。
一样平常企业中都会利用第二种方案，也就是通过分布式ID生成的算法，在业务体系中生成有序的分布式ID，以此来确保ID的唯一性，但具体该如何去实现，这点会放到后续的《分布式ID篇》讲解。
4.4、数据的落库问题
对数据库做了程度拆分后，数据该怎么存储呢？写操纵究竟该落到哪个库呢？读操纵又如何确定数据在哪个库中呢？好比新增一条ID=987215的数据，到底插入到哪个库中，需要这条数据时又该如何查询？这显然是做了程度拆分之后必须要思考的问题，这定然不能随便写，因为写过的数据在后续业务中肯定会用到，所以写数据时需要根据肯定规则去落库，如许才能在需要时能定位到数据。
但数据的拆分规则，大概被称之为路由规则，具体的还是要根据本身的业务来进行选择，在拆分时只需遵循：数据分布均匀、查询方便、扩容/迁移简朴这几点原则即可。
一样平常简朴常用的数据分片规则如下：
- ①随机分片：随机分发写数据的哀求，但查询时需要读取全部节点才能拿取数据，一样平常不消。
- ②一连分片：每个节点负责存储一个范围内的数据，如DB1:1~500W、DB2:500~1000W....。
- ③取模分片：通过整数型的ID值与程度库的节点数量做取模运算，最终得到数据落入的节点。
- ④同等性哈希：根据某个具备唯一特性的字段值盘算哈希值，然后再通过哈希值做取模分片。
- ..........
总之想要处置惩罚好数据的落库问题，那首先得先确定一个字段作为分片键/路由键，然后基于这个字段做运算，确保同一个值经盘算后都能分发到同一个节点，如许才能确保读写哀求正常运转，但关于具体该如何去做，会在后续的《MySQL分库分表实践篇》去落地。
4.5、流量迁移、容量规划、节点扩容等问题
流量迁移、容量规划、节点扩容等这些问题，在做架构改进时基本上都会碰到，接着依次聊一聊。
4.5.1、流量迁移
线上环境从单库切换到分库分表模式，数据该如何迁移才能保证线上业务不受影响，对于这个问题来说，首先得写脚本将老库的数据同步到分库分表后的各个节点中，然后条件答应的情况下先上灰度发布，划分一部门流量过来做运营测试。
假如没有搭建完善的灰度环境，那先再本地再三测试确保没有问题后，接纳最简朴的方案，先挂一个公告：“今日凌晨两点后服务器会进入维护阶段，预计嫡清晨八点会规复正常运转”！然后停机更新，但前提工作做好，如：Java代码从单库到分库分表要改进完善、数据迁移要做好、步伐调试一切无误后再切换，同时肯定要做好版本回滚支持，假如迁移流量后出现问题，可以快捷切换回之前的老库。
4.5.2、容量规划
关于分库分表首次到底切分成多少个节点符合，对于这点业内没有明白规定，更多的要根据自身业务的流量、并发情况决定，根据实际情况先做垂直分库，然后再对于核心库做程度分库，但程度分库的节点数量要保证的是2的整倍数，方便后续扩容。
4.5.3、节点扩容
扩容一样平常是指程度分库，也就是当一个业务库无法承载流量压力时，需要对相应的业务的节点数量，但扩容时必须要考虑本次增加节点会不会影响之前的业务，因为许多情况下，当节点的数量发生改变时，大概会影响数据分片的路由规则，这时就要考虑扩容是否会影响原本的路由规则。
扩容一样平常都是基于程度分库的底子上，进一步对程度库做节点扩容，目前业内有两种主流做法：程度双倍扩容法、异步双写扩容法。
程度双倍扩容法
想要利用双倍扩容法对节点进行扩容，首先必须要求原先节点数为2的整数倍，同时路由规则必须要为数值取模法、或Hash取模法，否则依旧会造成扩容难度直线提升。同时双倍扩容法另有一种进阶做法，被称之为从库升级法，也就是给原本每个节点都设置一个从库，然后同步主节点的所有数据，当需要扩容时仅需将从库升级为主节点即可，过程如下：
早先某个业务的程度库节点数量为2，因此业务服务中的数据源设置为{DB0:144.xxx.xxx.001、DB1:144.xxx.xxx.002}，当读写数据时，假如路由键经哈希取模运算后的结果为0，则将对应哀求落到DB0处置惩罚，如若取模结果为1，则将数据落到DB1中处置惩罚，此时两节点的数据如下：
- DB0：{2、4、6、8、10、12、14、16.....}
- DB1：{1、3、5、7、9、11、13、15......}
同时DB0、DB1两个节点都各有一个从节点，从节点会同步各自主节点的所有数据，此时假设两个节点无法处置惩罚哀求压力时，需要进一步对程度库做扩容，这时可直接将从节点升级为主节点，过程如下：
颠末扩容之后，节点数量变成了4，所有首先得修改业务服务中的数据源设置为{DB0:144.xxx.xxx.001、DB1:144.xxx.xxx.002}、{DB2:144.xxx.xxx.003、DB3:144.xxx.xxx.004}，然后将路由算法修改为%4，最终数据分片如下：
- DB0：{4, 8, 12, 16, 20, 24.....}
- DB1：{1, 5, 9, 13, 17, 21......}
- DB2：{2, 6, 10, 14, 18, 22.....}
- DB3：{3, 7, 11, 15, 19, 23.....}
此时要注意，因为DB2原本属于DB0的从库，所以具备原本DB0的所有数据，现在再观察上述的数据分片情况，对好比下：
- 扩容后的DB2：{2, 6, 10, 14, 18, 22.....}
- 扩容前的DB0：{2、4、6、8、10、12、14、16.....}
此时各人应该会发现，扩容后DB2中落入的分片数据，原本都是存在于DB0中的，而DB2原先就是DB0的从库，所以也具备之前DB0中数据，因此接纳这种扩容法，基本上无需做数据迁移！
好比现在要查询ID=10的数据，根据原本Hash(XX)%2的路由算法，会落入到DB0中读取数据，而根据现在Hash(XX)%4的路由算法，应该落入到DB2中读取数据，因为DB2具备原本DB0的数据，所以也无需在扩容后，再次从DB0中将数据迁移过来（DB1、DB3亦是同理）。
为了不占用存储空间，也可以在凌晨两点到六点这段业务低峰期，去跑脚本删除重复的数据，因为目前DB0、DB2之间的数据完全相同，都包罗了对方要负责的分片数据，所以在跑脚本的时间就是要从自身库中删除对方的数据（DB1、DB3亦是同理）。
这种从库升级扩容法是双倍扩容法的进阶实现，但这种情况会浪费一倍的机器，所以实用于一些流量特别大的场景，因为在这种扩容法中无需做数据迁移，同时扩容之后的4个节点，也可以再为其设置4个从库，以便于下次扩容。
当然，假如你感觉这种做法太浪费机器，也可以利用传统的双倍扩容法，即每次扩容之后，要手动从原本的库中将分片数据迁移过来，假如数据量较大时，迁移数据的时间会较长，所以只能做离线迁移。
同时在离线迁移的过程中，线上数据另有大概发生变动，所以离线迁移后还需要查对数据的同等性，过程会更繁琐一些，所以省机器还是省贫苦，需要诸位在两者之间做决议。
假如你在的公司财大气粗，我推荐从库升级法，因为从库升级法不但仅能够避免数据迁移，而且还能保证高可用，当主节点宕机时可以让从节点直接上线顶替，再共同Keepalived+VIP做重启，基本上能够让数据库真正达到7x24小时不中断运行。
异步双写扩容法
前面聊到的程度双倍扩容法，仅仅只是扩容时的一种方案，除此之外另有另一种方案称之为异步双写扩容法，大体表示图如下：
对于需要扩容时的情况，首先依旧把新的数据写入到老库中，然后写完之后同步给MQ一份，后续再由MQ的消费者去将新数据写到新库中，同时新库在这期间，会去同步老库中原有的数据，这个动作连续到所有旧数据全部同步完成后，再以老库作为校验基准，查对数据无误后，再将模式切换为扩容后的分库模式：
切换到分库模式后，记得在业务代码中去掉双写的逻辑，改为路由分片的逻辑，稍微总结一下整个流程，如下：
- 第一步：修改应用服务代码，加上MQ双写方案，设置新库同步老库数据，然后部署。
- 第二步：等待新库同步复制老库中所有老数据，期间新写入的数据也会通过MQ写入新库。
- 第三步：老库中的所有老数据全部同步完成后，以老库作为校验基准，校对新库中的数据。
- 第四步：校对新老库之间的数据无误后，修改应用设置和代码，将双写改为路由分片，再次部署。
看到这里信赖诸位已经明白了两种扩容方法，这两种方案都是分库分表扩容时最常用的方案，但异步双写扩容法，更实用于垂直分库后的第一次单节点扩容。而程度双倍扩容法，则实用于程度分库后的第N次扩容。
实在异步双写方案，也可以用来做后续的节点扩容，但会相对来说比力贫苦一些。
4.6、分库后的多维度查询问题
之前单库的一张表，好比以zz_users用户表为例，既可以通过user_id检索数据，如：
- select * from zz_users where user_id = 10086;
也可以通过user_name进行数据的查找，如：
- select * from zz_users where user_name = '竹子爱熊猫';
但是现在程度分库后呢，实行SQL究竟该落入哪个库是根据路由键和路由算法来决定的，假设这里路由键为user_id，此时通过user_id查询当然没有问题，但通过user_name查询时，就无法通过路由键定位具体DB了，那又该怎么办呢？解决方案如下：
- ①淘宝方案：对于订单库实现了多库多维路由键拆分，直接用了三个程度库集群，一个以用户ID作为路由键，一个以商户ID作为路由键，一个以订单时间作为路由键，三个分库集群中数据完全相同，从而满意差别维度查询数据的业务需求。
- ②数据量小的时间时，可以通过ES维护路由键的二级索引，如1:竹子、2:熊猫....。
假如业务数据量特别巨大，可以选择第一种方案做分库集群，但假如数据量不是百亿级别的规模，则可以通过ES建立路由键的二级索引，当基于非路由键字段查询时，先从ES中查到路由键值，然后再根据路由键查询数据库的数据返回。
4.7、外键约束问题
一样平常的项目基本上都会存在主外键，虽然不会在表上添加主外键约束，但也会从逻辑上保障主外键关系，但颠末程度分库后，所有的读写操纵会基于路由键去分片，那此时以订单表、订单详情表为例，假设用户选择了三个购物车的商品提交订单，此时会产生一条订单记录、以及对应的三条订单详情记录，关系大致如下：
- 订单数据：order_id=1, pay_money=8888, user_id=666, shop_order_row=3, ......
- 订单详情数据： order_info_id=1, shop_name='黄金竹子', shop_count=1, unit_price=6000..... order_info_id=2, shop_name='白玉竹子', shop_count=2, unit_price=1111..... order_info_id=3, shop_name='翠绿竹子', shop_count=1, unit_price=666.....
假设商品库有两个程度节点，两个商品库都具备订单表、订单详情表，而订单表的路由键是order_id，订单详情表的路由键是order_info_id，数据分片的路由算法为取模，那此时数据的落库情况为：
- order_id % 2：1 % 2 = 1，order_id=1的订单数据落入DB1商品库中。
- order_info_id % 2： 1 % 2 = 1、3 % 2 = 1，order_info_id = 1、3的订单详情数据落入DB1商品库中。 2 % 2 = 0，order_info_id = 2的订单详情数据落入DB0商品库中。
但此时order_id=1，order_info_id=1、2、3的数据是存在外键关系的，假如按照上述的路由方式去对数据做分片，最终就会导致通过order_id=1的订单ID查询订单详情时，只能在DB1中查询到两条订单详情数据，这个问题显然是业务上无法接受的。
所以面对于这种业务上存在主外键关系的表，必须要能够确保外键所在的数据记录，必须要和主键数据记录落到同一个库中去，否则后续无法通过主键值查询到完备的数据，对于这种情况的解决方案是通过绑定表去实现（绑定表也是分库分表中的一个新概念，这里放到后面实践篇讲解，目前简朴相识即可）。
五、分库后步伐怎么访问数据库？
在之前的单库模式下，业务体系需要利用数据库时，只需要在相干的设置文件中，设置单个数据源的地点、用户、密码等信息即可。但分库分表后由于存在多个数据源，步伐怎么样访问数据库，设置和代码该怎么写呢？这是一个更应该关心的问题，具体可分为几种方式：
- 编码层：在代码中通过框架提供的数据源动态切换类实现，如Spring.AbstractRoutingDataSource类。
- 框架层：一样平常的ORM框架也会提供切换数据源的实现类，好比MyBatis.Interceptor接口拦截SQL实现。
- 驱动层：在JDBC驱动层拦截SQL语句，然后改写SQL实现，如Sharding-JDBC框架的原理就是如此。
- 代理层：所有利用数据库的业务服务都毗连代理中间件，由中间件来决定落库位置，如MyCat实现。
- 服务层：如今较为流行的分布式数据库，基本上都自带分库分表功能，如TiDB、OceanBase....
一样平常编码层或框架层都无法单独实现数据源的切换，两者必须共同起来完成，用MyBatis.Interceptor接口拦截SQL语句，然后根据SQL中的路由键做运算，最终再通过Spring.AbstractRoutingDataSource类去动态切换数据源。但这种方案的工程量很大，实现过程也较为繁杂，所以下面直接来看一些成熟的方案，如下：
- 工程（依靠、Jar包、不需要独立部署，可集成在业务项目中） 淘宝网：TDDL 蘑菇街：TSharding 当当网：Sharding-Sphere-JDBC
- 进程（中间件、需要独立部署的第三方进程） 早年最热门、基于阿里Cobar二开的MyCat 阿里B2B：Cobar 奇虎360：Atlas 58同城：Oceanus 谷歌开源：Vitess 当当网：Sharding-Sphere-Proxy
实在早些年各人听说的比力多的应该是MyCat这款分库分表中间件，也包罗前些年一样平常用的比力多也是它，但迩来几年MyCat不再进一步优化了，而且其核心首创人之一整天在技术群里吹水卖课，导致原本远景无穷的一款产品给玩凉了，关于其首创人Leader-us的一些故事各人可参考>>知乎答复<<，这里个人不做过多评价。
先如今要考虑做分库分表时，可首先选用当当网的Sharding-Sphere框架，早些年原本只有Sharding-JDBC驱动层的分库分表，但到了后续又推出了代理层的Sharding-Proxy中间件，最终归并建立了Sharding-Sphere项目。
近几年该项目也交由Apache软件基金会来孵化，并且列入到顶级项目孵化列表，随着Apache接办后也有了充实的后背保障，因此更建议分库分表时选用Sharding-Sphere来实现，官网：《Sharding-Sphere官网》。
从社区生态和GitHub的趋势来看，基本上近些年的增长也十分迅猛，并且Sharding-Sphere中对分库分表后产生的一系列问题，也提供了一站式解决方案。
六、分库分表后患问题总结
在本章中补齐了分库分表带来的一系列问题的分析，以及问题产生后相应的解决方案，但在这里仅给出了基本的解决方案，但并未对其进行落地实践，究竟内容较多不大概面面俱到，具体的落地会在后续的章节中徐徐道来~
最后附言：所谓的架构师并不是指能做架构选型即可，好比决定缓存用Redis、消息中间件用RocketMQ、ORM框架用MyBatis-Plus、微服务框架用SpringCloud Alibaba.......，真正的架构是要能够清楚各层面中主流的技术方案，究竟能够充分联合业务去做选型，最关键的是自身也得清楚选用某个技术栈后能够带来的性能收益，以及引入某项技术后会带来的风险问题及解决方案。
好比当你考虑对存储层做分库分表时，就得先考虑清楚本章中提到的所有问题，以及具体该如何解决，只考虑追求技术风潮，不考虑技术风险的做法，显然无法被称作一位及格的架构师。一名及格的架构除开能全面考虑到技术风险且给出解决方案外，应当还得将项目架构设计的更为合理才行，好比设计的技术架构具备很强的弹性伸缩能力，可根据业务的增长/萎靡进行动态的伸缩调解。
可否设计并将分库分表方案落地，这也是每一名技术职员进阶蹊径上的一个大门槛，当你迈过了这道门槛，间隔成为一名初阶架构也就不远了，本章中聊到的一些疑难杂症，也盼望能够引起诸君的思考，作为一位技术者，不应该仅关注平常开发中的业务，不应该被日常的增编削查蒙蔽双眼，更应该在工作空闲之余适当思考技术，否则你会很难真正跳出逆境。
最后，如若本文对你能起到绵薄的帮助，还请多多点赞支持~，上述那些鸡汤、客气话实在不看也罢，简朴一句人话来总结就是：不要只当个增编削查的螺丝仔，平常多学多看多思考才能真正进阶涨薪！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
