OLTP场景下的数据分布式设计原则

布式项目，很多工作是关于OLTP(联机交易系统)场景下数据分布式架构的，疫情期间正好整理下这方面的一些设计与实践。为避免篇幅太长，本文分为设计篇和技术篇，设计篇主要偏向数据拆分的理论与方法，还有一些原则与经验。技术篇则主要会介绍分库分表中间件的设计与使用实践，以及如何构建一个完整的分布式数据服务平台。

一般来说做分布式架构，应用层是好做分布式的，因为往往都是无状态的(或者通过将数据转移到DB、缓存、MQ等方式来实现无状态)，只需在流量入口、即在应用前面加一个负载均衡即可(例如Nginx、HAProxy、F5)，这在大单体架构也多已具备。所以一般我们说分布式架构，一个重要的部分就是要做数据的分布式化。
 

分布式不像应用那么简单，因为各节点的数据可能是不一样的，需要进行路由、解决多副本一致性，甚至多写冲突等问题。虽然实现方案复杂，不过数据的分布式本质上就两种朴素思想：复制和分片。复制技术在传统关系数据库中也很常见，主要用来做主备、双活，例如 MySQL Replication、Oracle DataGuard等。分片在数据库里也有对应产品。例如 MySQL Fabric、Oracle Sharding，但与复制相比，这些数据库厂商对应的分片方案却一直没有被大众广泛接受。

在NewSQL数据库中往往都内置了sharding机制，而且都基于paxos、raft算法来保证复制一致性，关于分库分表与NewSQL方案对比选型，可参见我之前一篇文章《分库分表 vs NewSQL数据库》。

在OLTP场景下，复制和分片思想应用在传统关系数据库上，有两个更为人熟知的名字，分库分表与读写分离。

分库分表，就是对原来单一数据库表进行拆分，是基于传统关系数据库实现分布式架构转型的一个主要方式，因此首先第一个问题：

为什么拆分?什么时候需要拆分?

容量、性能、横向扩展、微服务

单机数据库的存储、CPU、内存等资源都存在上限瓶颈，当数据量、访问量到达一定量级后，性能则会急剧下降，也就是说通过scale up这种垂直扩展的方式是一个上限的，而且成本是较高的。

（编辑：盐城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!