ShardingProxy使用自定义策略，数据迁移方案

ShardingProxy功能扩展

我们在使用ShardingJDBC时，会进行自定义分布式主键生成策略、自定义分片策略

如果我们想要我们自定义的这些策略在ShardingProxy中也能使用，应该如何操作嘞？

我们只需要将这些类以及对应的SPI文件打成一个Jar包，放到ShardingProxy的ext-lib目录下就可以使用了。使用的方式跟在ShardingJDBC中一样，直接改配置中的type值即可

只补充一个在之前的ShardingJDBC项目中，单独打功能扩展jar包的方式。在pom.xml中引入maven-jar-plugin插件就可以了。

<build>
    <plugins>
        <!-- 现有打包插件 -->
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>2.3.2.RELEASE</version>
        </plugin>

        <!-- 将SPI扩展功能单独打成jar包 -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <version>3.2.0</version>
            <executions>
                <execution>
                    <id>ShardingSPIDemo</id>
                    <phase>package</phase>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                    <configuration>
                        <classifier>spiextention</classifier>
                        <includes>
                            <include>com/hs/sharding/algorithm/*</include>
                            <include>META-INF/services/*</include>
                        </includes>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

分库分表数据迁移方案

官方文档

数据迁移场景：

• 之前项目没有分库分表，现在数据大了之后要进行分库分表改造
• 数据采用取模分片，发现数据量太大了，需要增加数据分片数量
• 等等

分库分表通常面临的就是海量数据的场景，这使得数据迁移通常是一个非常庞大，非常耗时的工作。业界有很多零迁移数据扩缩容方案可以用来预防未来可能需要的数据迁移工作。但是，如果你没有提前进行设计，在调整分片方案时，确实需要进行数据迁移，应该怎么办呢？

数据迁移的难点往往不在于数据怎么转移，而是在数据转移的过程中，如何保证不影响业务正常进行。

通常的思路都是冷热数据分开迁移。

• 冷数据是指那些存量的历史数据。这一部分数据往往数据量非常大，不可能一次性迁移完成，那就只能用定时任务的方式，一点点的逐步完成迁移。
• 热数据是指那些业务进行过程当中产生的实时数据。这一部分数据就要保证数据迁移过程中实时双写。

在冷数据迁移过程中，既要写入旧数据库当中，保证业务正常运行，同时又要写入新的数据库集群当中，保证数据正常更新。等冷数据迁移完成后，再将旧数据库完全淘汰，用新的数据库集群承载业务。

我们其实可以利用ShardingSphere的混合架构来辅助进行分库分表数据迁移。

热数据可以在旧业务数据通道外，通过ShardingJDBC往新的数据库进行实时双写。在这里主要是要考虑尽量少的影响旧业务的数据通道。而我们要做的， 就是用一个ShardingSphereDataSource，去替换旧的DataSource。首先可以在应用中配置一个ShardingJDBC数据双写库。在这个库中主要是让核心业务表能够保持在新旧两套数据库集群中同时进行双写。在这个过程中，旧的业务通道不需要做任何修改，只要在ShardingJDBC数据双写库中针对要迁移的核心业务表配置分片规则这就行。数据双写可以通过定制分片算法实现。

配置完数据双写后，就需要针对新数据库集群配置，配置一个ShardingJDBC数据写入库，主要完整针对新数据库集群的数据分片。这个ShardingJDBC数据写入库可以使用ShardingSphere的JDBC来创建，然后作为一个真实库，配置到之前的数据双写库当中，这样就可以完成针对新数据库集群的数据分片写入

冷数据部分主要是查询旧数据库中的数据，按照新的数据分片规则，转移到新数据库集群当中。这部分数据通常非常巨大，对内存的消耗非常大。所以可以通过定时任务进行增量更新，每次只读一部分数据。然后，为了简化数据转移的逻辑，可以搭建一个ShardingProxy服务，用来完成针对新数据库集群的分片规则。这样定时任务的逻辑就比较简单了，只要从一个MySQL服务读数据，然后写入另一个MySQL服务就可以了。而为了保持在写入新数据库集群时，与热数据保持相同的分片逻辑，ShardingProxy与ShardingJDBC数据写入库之间，可以通过ShardingSphere的管理中心来保持规则同步。

这样，整个数据迁移过程中，旧的业务数据通道几乎不需要做任何改变。等数据迁移完成后，只要把ShardingJDBC数据写入库保留下来，把ShardingJDBC数据双写库和旧数据通道直接删掉即可。在整个迁移过程中，对应用来说，都只是访问一个DataSource，只不过是DataSource的具体实例根据配置做了变动而已，业务层面几乎不需要做任何修改。

当然，具体实施时，还是有很多具体的细节需要你自己去补充的。例如对于业务SQL需要做梳理。如果原本只是访问一个MySQL服务，而SQL语句写得比较放飞自我的话，那就需要按照ShardingJDBC的要求进行调整，尽量不要使用ShardingSphere不支持的SQL语句。