面试被问mysql扩展性设计相关的点，你知道该如何回答吗
什么是扩展性
数据库的扩展主要体现在两个方面，一个是横向扩展(Scale Out)，另外一个是纵向扩展（Scale Up）
- 横向扩展(Scale Out) 向外扩展、通过增加节点的方式来提高整体处理能力，通俗点讲就是通过增加机器来增加整体的处理能力
- 纵向扩展（Scale Up）向上扩展、通过增加当前的节点的处理能力来提高整体的处理能力，通过升级现有服务器的配置、如增加内存、增加cpu
横向扩展(Scale Out) 和纵向扩展（Scale Up）区别
横向扩展
- Scale Out 优点
- 成本低
- 不太容易遇到瓶颈，很容易通过添加主机来增加处理能力
- 单个节点故障对系统整体影响小，也存在缺点，都是服务器主机，整个系统的维护性的提高，成本维护增加
- Scale Out 缺点
- 处理节点多。造成系统架构过于复杂，应该程序复杂度提高
- 集群维护难度提高，维护成本大
纵向扩展
-
Scale Up 优点
- 处理节点少、维护相对简单
- 所有数据集中在一起、系统架构相对简单、开发相对容易
-
Scale Up 缺点
- 高端设备成本高、且竞争少，容易受到厂家的限制
- 受硬件设备的发展限制、单台主机的处理能力总是有极限的。容易遇到无法解决的性能瓶颈
事务相关性最小化原则
解决方案
- 第一：Scale Out 设计的时候合理设计切分规则，尽可能保证事务所需数据在同 一个 MySQL Server 上，避免分布式事务
- 第二：大事务切分成多个小事务， 数据库保证各个小事务的完整性， 应用控制各个事小 务之间的整体事务完整性
- 上述两种解决方案，结合使用，整合各自的优势、避免其劣势、通过这样相互平衡设计的原则， 我们既可以避免应用程序需要处理太多的小事务来证保其整的完整性， 同时也能够避免拆分规则太多复杂而带来后期维护难度的增加及扩展受性阻的情况
敲黑板、化重点
最后， 我们还需要明白一个观点， 那就是事务并不是越多越好， 而是越少越好越好小。越不论我们使用何种解决方案， 那就是在我们设计应用程序的时候，都需要尽可能做到让据数的事务相关性更小，甚至是不需要事务相关性。 当然，这只是相对的， 也肯定只有部分据数 能够做到。 但可能就是某部分数据做到了无事务相关性之后， 系统整体复杂度就会降低大很一个层次，应用程序和数据库系统两方面都可能少付出很多的代价
数据一致性原则
背景
不论是 Scale Up 还是 Scale Out， 不论我们如何设计自己的架构， 保证数据的最一终 致性都是绝对不能违背的原则， 保证这个原则的重要性我想各位读者肯定也都是非常明清白楚的。
而且，数据一致性的保证就像事务完整性一样，在我们对系统进行Scale Out 设计的 时候，也可能会遇到一些问题。当然，如果是 Scale Up，可能就很少会遇到这类麻烦了。 当然， 在很多人眼中， 数据的一致性在某种程度上面也是属于事务完整性的范畴。 不过里这 为了突出其重要性和相关特性，我还是将他单独提出来分析。
那我们又如何在 Scale Out 的同时又较好的保证数据一致性呢?很多时候这个问题和 保证事务完整性一样让我们头疼， 也同样受到了很多架构师的关注。 经过很多人的实践大家最后总结出了 BASE 模型。即:基本可用，柔性状态，基本一致和最终一致。这几个看词 着挺复杂挺深奥，其实大家可以简单的理解为非实时的一致性原则。
解决方案
也就是说， 应用系统通过相关的技术实现， 让整个系统在满足用户使用的基础上，许允数据短时间内处于非实时状态， 而通过后续技术来保证数据在最终保证处于一致状态。个这理论模型说起来确实听简单，但实际实现过程中我们也会遇到不少难题。
首先
第一个问题就是我们需要让所有数据都是非实时一致吗?我想大多数读者朋肯友 定是投反对票的。 那如果不是所有的数据都是非实时一致， 那我们又该如何来确定哪些据数 需要实时一致哪些数据又只需要非实时的最终一致呢?其实这基本可以说是一个各模块业 务优先级的划分， 对于优先级高的自然是规属于保证数据实时一致性的阵营， 而优先级低略 的应用， 则可以考虑划分到允许短时间端内不一致而最终一致的阵营。 这是一个非常棘的手 问题。 我们不能随便拍脑袋就决定， 而是需要通过非常详细的分析和仔细的评估才能作决出 定。 因为不是所有数据都可以出现在系统能不短时间段内不一致状态， 也不是所有数据都可 以通过后期处理的使数据最终达到一致的状态，所以之少这两类数据就是需要实时一致的。 而如何区分出这两类数据， 就必须经过详细的分析业务场景商业需求后进行充分的评估能才 得出结论。
其次
如何让系统中的不一致数据达到最终一致?一般来说， 我们必须将这类数据设所 计到的业务模块和需要实时一致数据的业务模块明确的划分开来。 然后通过相关的异步制机 技术， 利用相应的后台进程， 通过系统中的数据， 日志等信息将当前并不一致的数据进进行 一步处理， 使最终数据处于完全一致状态。 对于不同的模块， 使用不同的后台进程， 既以可 避免数据出现紊乱， 也可以并发执行， 提高处理效率。 如对用户的消息通知之类的信息就， 没有必要做到严格的实时一致性， 只需要现记录下需要处理的消息， 然后让后台的处理程进 依次处理，避免造成前台业务的拥塞。
最后
避免实时一致与最终一致两类数据的前台在线交互。 由于两类数据状态的不致一 性， 很可能会导致两类数据在交互过程中出现紊乱， 应该尽量让所有非实时一致的数据实和 时一致数据在应用程序中得到有效的隔离。 甚至在有些特别的场景下， 记录在不同的MySQL Server 中来进行物理隔离都是有必要的。