认识达内从这里开始

数据库性能优化是需要软件编程开发程序员长期关注的一个互联网问题，而本文我们就通过案例分析来简单了解一下，分库分表常见问题与架构模式分享。

一、分库分表常见问题

分页、排序、跨节点联合查询

分页、排序、联合查询，这些看似普通，开发中使用频率较高的操作，在分库分表后却是让人非常头疼的问题。把分散在不同库中表的数据查询出来，再将所有结果进行汇总合并整理后提供给用户。

比如：我们要查询11、12月的订单数据，如果两个月的数据是分散到了不同的数据库实例，则要查询两个数据库相关的数据，在对数据合并排序、分页，过程繁琐复杂。

事务一致性

分库分表后由于表分布在不同库中，不可避免会带来跨库事务问题。后续会分别以阿里的Seata和MySQL的XA协议实现分布式事务，用来比较各自的优势与不足。

全局的主键

分库分表后数据库表的主键ID业务意义就不大了，因为无法在标识一条记录，例如：多张表t_order_1、t_order_2的主键ID全部从1开始会重复，此时我们需要主动为一条记录分配一个ID，这个全局的ID就叫分布式ID，发放这个ID的系统通常被叫发号器。

多数据库高效治理

对多个数据库以及库内大量分片表的高效治理，是非常有必要，因为像某宝这种大厂一次大促下来，订单表可能会被拆分成成千上万个t_order_n表，如果没有高效的管理方案，手动建表、排查问题是一件很恐怖的事。

历史数据迁移

分库分表架构落地以后，要的问题就是如何平滑的迁移历史数据，增量数据和全量数据迁移，这又是一个比较麻烦的事情，后边详细讲。

二、分库分表架构模式

分库分表架构主要有两种模式：client客户端模式和proxy代理模式

客户模式

client模式指分库分表的逻辑都在你的系统应用内部进行控制，应用会将拆分后的SQL直连多个数据库进行操作，然后本地进行数据的合并汇总等操作。

代理模式

proxy代理模式将应用程序与MySQL数据库隔离，业务方的应用不在需要直连数据库，而是连接proxy代理服务，代理服务实现了MySQL的协议，对业务方来说代理服务就是数据库，它会将SQL分发到具体的数据库进行执行，并返回结果。该服务内有分库分表的配置，根据配置自动创建分片表。

如何抉择

如何选择client模式和proxy模式，我们可以从以下几个方面来简单做下比较。

1、性能

性能方面client模式表现的稍好一些，它是直接连接MySQL执行命令;

proxy代理服务则将整个执行链路延长了，应用->代理服务->MySQL，可能导致性能有一些损耗，但两者差距并不是非常大。

2、复杂度

client模式在开发使用通常引入一个jar可以;

proxy代理模式则需要搭建单独的服务，有一定的维护成本，既然是服务那么就要考虑高可用，毕竟应用的所有SQL都要通过它转发至MySQL。

3、升级

client模式分库分表一般是依赖基础架构团队的Jar包，一旦有版本升级或者Bug修改，所有应用到的项目都要跟着升级。小规模的团队服务少升级问题不大，如果是大公司服务规模大，且涉及到跨多部门，那么升级一次成本就比较高;

proxy模式在升级方面优势很明显，发布新功能或者修复Bug，只要重新部署代理服务集群即可，业务方是无感知的，但要保证发布过程中服务的可用性。

4、治理、监控

client模式由于是内嵌在应用内，应用集群部署不太方便统一处理;proxy模式在对SQL限流、读写权限控制、监控、告警等服务治理方面更优雅一些。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。