1.聚合操作和连表问题
- 放入第三方中间件中，然后依赖于第三方中间件完成，如ES。一些大企业选用的方案。
2.数据分页问题
- 放入第三方中间件中，然后依赖于第三方中间件完成，如ES。一些大企业选用的方案。
3.ID主键的唯一性问题
- 在业务系统中，利用特殊算法生成有序的分布式ID，比如雪花算法、Snowflake算法等。
4.流量迁移、容量规划、节点扩容
线上环境从单库切换到分库分表模式，数据该如何迁移才能保证线上业务不受影响，对于这个问题来说，首先得写脚本将老库的数据同步到分库分表后的各个节点中，然后条件允许的情况下先上灰度发布，划分一部分流量过来做运营测试。
如果没有搭建完善的灰度环境，那先再本地再三测试确保没有问题后，采用最简单的方案，先挂一个公告：“今日凌晨两点后服务器会进入维护阶段，预计明日早晨八点会恢复正常运转”！然后停机更新，但前提工作做好，如：Java代码从单库到分库分表要改进完善、数据迁移要做好、程序调试一切无误后再切换，同时一定要做好版本回滚支持，如果迁移流量后出现问题，可以快捷切换回之前的老库。
根据实际情况先做垂直分库，然后再对于核心库做水平分库，水平分库的节点数量要保证的是2的整倍数，方便后续扩容。
扩容一般是指水平分库，也就是当一个业务库无法承载流量压力时，需要对相应的业务的节点数量，但扩容时必须要考虑本次增加节点会不会影响之前的业务，因为很多情况下，当节点的数量发生改变时，可能会影响数据分片的路由规则，这时就要考虑扩容是否会影响原本的路由规则。
扩容一般都是基于水平分库的基础上，进一步对水平库做节点扩容，目前业内有两种主流做法：水平双倍扩容法、异步双写扩容法。
水平双倍扩容法
想要使用双倍扩容法对节点进行扩容，首先必须要求原先节点数为2的整数倍，同时路由规则必须要为数值取模法、或Hash取模法，否则依旧会造成扩容难度直线提升。同时双倍扩容法还有一种进阶做法，被称之为从库升级法，也就是给原本每个节点都配置一个从库，然后同步主节点的所有数据，当需要扩容时仅需将从库升级为主节点即可，过程如下：
二倍扩容！！
如果你在的公司财大气粗，我推荐从库升级法，因为从库升级法不仅仅能够避免数据迁移，而且还能保证高可用，当主节点宕机时可以让从节点直接上线顶替，再配合Keepalived+VIP做重启，基本上能够让数据库真正达到7x24小时不间断运行。
异步双写扩容法（常用）
前面聊到的水平双倍扩容法，仅仅只是扩容时的一种方案，除此之外还有另一种方案称之为异步双写扩容法，大体示意图如下：
对于需要扩容时的情况，首先依旧把新的数据写入到老库中，然后写完之后同步给MQ一份，后续再由MQ的消费者去将新数据写到新库中，同时新库在这期间，会去同步老库中原有的数据，这个动作持续到所有旧数据全部同步完成后，再以老库作为校验基准，核对数据无误后，再将模式切换为扩容后的分库模式
稍微总结一下整个流程，如下：
- 第一步：修改应用服务代码，加上MQ双写方案，配置新库同步老库数据，然后部署。
- 第二步：等待新库同步复制老库中所有老数据，期间新写入的数据也会通过MQ写入新库。
- 第三步：老库中的所有老数据全部同步完成后，以老库作为校验基准，校对新库中的数据。
- 第四步：校对新老库之间的数据无误后，修改应用配置和代码，将双写改为路由分片，再次部署。
其实异步双写方案，也可以用来做后续的节点扩容，但会相对来说比较麻烦一些。
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们处理，核实后本网站将在24小时内删除侵权内容。
