认识达内从这里开始

分布式编程开发随着互联网的不断发展而被越来越多的程序员掌握，今天我们就通过案例分析来简单了解一下，分布式数据库架构常见问题分析。

该做法俗称分库分表，是绝大部分互联网公司在解决容量、性能扩展性问题上的选方案。该方案将数据基于某种规则(shardingkey)均匀拆分到多个集群中来达到分摊存储与计算性能压力，代表的中间件产品TDDL/Cobar/Vitess，及基于该思想诞生的“分布式DB”代表产品TDSQL、StarDB等。这类方案虽然解决了容量、性能可扩展的问题，但是也存在如下的一些问题。

问题1：技术复杂。

通常是大公司专属玩法，普遍基于业务场景做了深度定制，周边有一套完整的配套管控系统支持。目前市面上虽然有一些开源的Proxy也能用，但对于中小公司来说很难从根上可控，使用过程中的棘手问题几乎很难在短时间解决，而且开源产品为了通用性要想基于公司场景化定制有难度。因此，很多中小公司虽然做了分库分表但或多或少存在这样那样的问题。

问题2：对业务有侵入。

从单表到分库分表的改造普遍要求带shardingkey作为数据拆分及路由依据，这样业务逻辑被迫进行改造，比如对多表join的场景很难通过中间件去解决、非shardingkey的查询被迫要扫片性能则非常低、排序/分页/聚合计算问题，等等。为了解决数据拆后聚合的问题，通常要在整个业务链路上部署复杂的中间件，这给稳定性维护及业务健壮性带来一些挑战。

问题3：扩缩容复杂。

通常在决定分库分表的时候需要提前做好容量评估，分片数定义好后就不在改变，非常不推荐后期再去扩展/缩容分片数。调整(reshard)分片数涉及数据rebalance整个过程。为了保证数据一致性要做很多额外工作，通常是DBA定制开发一个平滑迁移工具，或者研发双写+增量Binlog数据订阅做数据同步。如果reshard操作能内置到中间件，那对研发及DBA来说自然更友好，但目前市面上开源的中间件几乎没有见到有类似的功能!诸如TDSQL、StarDB等从公开资料上看是具备对用户透明的reshard能力的。

问题4：分布式事务问题。

出于对ACID完整性支持的考虑，由中间件形态构成的分布式数据库中解决分布式事务问题，通常解决方案都是差不多的，即两阶段提交(2PC)。

但实现过程非常复杂，也不可避免的对性能造成影响，通常在该形态的分布式数据库中都不太推荐用分布式事务。此外，这里分布式事务不能保证数据一致性或者说对集群而言本质还是终一致性，该形态的分布式数据库在分布式事务实现上普遍类似，可以参考分布式中间件Seata的实现原理。

对于中小公司可行的做法是业务场景拆分得足够简单的情况下基于代理中间件+业务数据补偿来保证数据的终一致性，使用分布式框架如Seata也是可行的，但太重了，对性能也会有明显的影响。

问题5：运维复杂性。

分布式中间件形态的数据库往往都有非常完善配套的管控系统来打包解决常见的运维问题，如果公司是基于某个开源的代理中间件做的，则不可避免的也要开发相关的管控系统来统一解决诸如DDL、研发数据订正等问题。整体上还是能很好解决存储、计算能力不足等问题和大表运维困境，只是对业务会有入侵，大公司专属定制，中小公司勉强也能玩转。

问题6：HTAP。

目前看到的分布式中间件形态的数据库基本不具备OLAP的能力，普遍做法还是要将数据流向到分析型数据库中。

问题7：容灾能力。

跟单机主从无本质区别

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