MySQL里面的分布式方案其实挺丰富的,今天来简单说下对分布式方案的理解。

首先数据库是一个软件,最基础的功能就是数据存储和数据查询。对于数据的处理方式如果通泛来说是分为读和写,所以分布式方案的很多场景其实也是围绕着这两个维度来做的。

在开始分布式方案前,要说下为什么要有分布式方案。如果单机可以解决的事情,其实完全没有必要去再考虑分布式了。如果要分,其实就不能再很自然的合起来,这也是分布式方案里需要掌握的一个平衡。 现在行业里说的HTAP方案,其实就是融合了OLTP+OLAP的场景,如果从单机的角度来说,Oracle肯定是最好的HTAP解决方案了。 但是oracle里面除了价格的问题之外,还有一个问题,那就是扩展性,暂不说sharding的细节,Oracle里面的设计思想就是share everything,所以分区表的方案还是比较合适的。

但是MySQL显然不行,因为你几乎听不到互联网行业里在用分区表的方案,因为再怎么分,怎么扩展,数据都是在单机上,况且单机性能还差强人意。 所以单机容量,单机性能都是一个瓶颈,那么就可以有两个或者多个实例来分担压力。

我来简单举个例子。从数据的处理角度来说,数据有读写需求,那么我们的需求就可以分别对读需求和写需求做扩展。

读需求的扩展相对来说简单一些,就是常说的读写分离了。这种一般的中间件都可以支持。

就如同下图的方案里面的左下角所示,对读的需求可以轻松实现读扩展,这里的读扩展是线性的,不是指数级的,对业务来说是透明的。

难点就在于写扩展了,写扩展的核心是涉及到分布式事务的部分,能不拆就不拆,如果实在要拆,那么我们可以分不同的维度,比如对于流水型数据,这类数据的前后依赖度很低,所以写需求就是insert,写的需求比较单一。这种方式可以使用中间件的方案来辅助,做到sharding的分片方案。 我们通常理解的分布式方案其实很多也是在说这个。这种方案的扩展是指数级别的,比如2个节点,变为4个,4个变为8个等等,对业务算是透明的。

但是还有一类更为复杂的,那就是状态型数据,我们不能直接拆,或者说直接分片,我们可以根据业务的维度来拆分,这种拆分就不建议直接使用中间件了。 比如一个业务如果拆分可以拆分为业务1,业务2,业务3。。。业务8,那么这8个业务的拆分逻辑建议不是做成hash的平滑方式,而是建议根据业务逻辑的优先级和其他维度来组合,比如业务1的优先级高,那么完全可以是一个独立的节点,业务3-业务6的数据量和优先级不同,则完全可以是一个节点。数据的写入路由规则建议还是通过应用层面来进行处理。这是一种更加可控的方案。这种扩展方案对应用不是透明的,需要应用的配合和处理。但是收益也显然是最佳的平衡状态,比如游戏行业里很常见的游戏服概念,就是这种分法,所以扩展起来可以是线性的。

如果要说这个基础之上的分布式方案,其实是把一套集群或者业务当做一个透明的节点,使用其他的辅助方案来达到扩展的需求,基于关系型的分布式方案更多是基于静态路由来处理,对于扩容来说还是需要做很多额外的工作,没法做到平滑的弹性。这一点上自然是NoSQL,NewSQL的用武之地了。

所以在方案的选择上,要有大局观和更高的视野,不一定什么都是MySQL,Oracle,深耕下去自然是不错的,还可以考虑其他更好的方案。