码农在囧途
最近这段时间来经历了太多东西，无论是个人的压力还是个人和团队失误所带来的损失，都太多，被骂了很多，也被检讨，甚至一些不方便说的东西都经历了，不过还好，一切都得到了解决，无论好坏，这对于个人来说也是一种成长吧，事后自己也做了一些深刻的检讨，总结为一句话“挫败使你难受，使你睡不着觉，使你痛苦，不过最后一定会使你变得成熟，变得认真，变得负责”，每次面临挫败，我都会告诉自己，这不算什么，十年之后，你回过头来看待这件事的时候，你一定会觉得，这算什么屁事。
背景
在现在这个数据量与日俱增的时代，传统的单表，单库已经无法满足我们的需求，可能早期数据量不是很大，CRUD都集中在一个库中，但是当数据量到达一定的规模的时候，使用单库可能就无法满足需求了，在实际场景中，读的频率是远远大于写的，所以我们一般会做读写分离，主库一般用于写，而从库用于读，而主从分离有好几种模式。
一主多从
一主多从是只有一台主机用于写操作，多台从机用于读操作，一主多从是存在风险的，当主机宕机后，那么写服务就会瘫痪，本文我们主要说的是ShardingSphere读写分离，而目前ShardingSphere只支持单主库，所以如果要保证业务的高可用，那么目前ShardingSphere不是很好的选择，不过希望ShardingSphere后面支持多主机模式。
多主多从
从上面的一主多从我们看出了它的弊端，所以为了保证高可用，我们可能需要多个主机用于写操作，这样当某个主机宕机，其他主机还能继续工作，ShardingSphere只支持单主机。
ShardingSphere只需要简单的配置就能实现数据库的读写的分离，我们甚至感知不到是在操作多个数据库，极大的简化了我们的开发，但是ShardingSphere不支持多主库，也无法进行主从数据库的同步。
ShardingSphere整合SpringBoot项目进行主从分离
ShardingSphere和SpringBoot能够很简单的进行组合，只需要简单的配置，ShardingSphere能够和主流的ORM框架进行整合，ShardingSphere会从ORM框架中解析出SQL语句，判断是读操作还是写操作，如果是读操作，则会落到主库上，如果是读操作，那么ShardingSphere会使用对应的负载均衡算法负载到对应的从库上面。
maven引入ShardingSpherestarter
dependencygroupIdorg.apache.shardingsphere/groupIdartifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactIdversion5.1.2/version/dependency
yml文件配置
names为数据库名称字符串，然后需要一个一个的进行配置JDBC连接，对于读写分离，我们需要