认识达内从这里开始

服务器架构随着应用场景的不同采用的架构方式也是不一样的，而今天我们就通过案例分析来简单学习一下，在服务器架构中的可扩展性都有哪些特点。

MySQL的可扩展性

架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种

Scale-up : 纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力

Scale-out : 横向扩展, 通过加节点(机器)来实现伸缩，提升服务能力

对于互联网的高并发应用来说，无疑Scale out才是出路，通过纵向的买更的机器一直是我们所避讳的问题，也不是长久之计，在scale out的理论下，可扩展性的理想状态是什么?

可扩展性的理想状态

一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响(no down time)，这就是可扩展性的理想状态!

MySQL架构的演变

MySQL简单网站架构(V1.0)

一个简单的小型网站或者应用背后的架构可以非常简单, 数据存储只需要一个mysql instance就能满足数据读取和写入需求(这里忽略掉了数据备份的实例)，处于这个时间段的网站，一般会把所有的信息存到一个database instance里面。

在这样的架构下，我们来看看数据存储的瓶颈是什么?

单实例单业务，依然存在V1.0所述瓶颈，遇到瓶颈时可以考虑往本文更高V版本升级, 若是读请求导致达到性能瓶颈可以考虑往V3.0升级， 其他瓶颈考虑往V4.0升级

MySQL的主从架构(V3.0)

此类架构主要解决V2.0架构下的读问题，通过给Instance挂数据实时备份的思路来迁移读取的压力，在Mysql的场景下就是通过主从结构，主库抗写压力，通过从库来分担读压力，对于写少读多的应用，V3.0主从架构完全能够胜任。

数据拆分后引入的问题：

数据水平拆分引入的问题主要是只能通过sharding key来读写操作，例如以userid为sharding key的切分例子，读userid的详细信息时，一定需要先知道userid,这样才能推算出再哪个cluster进而进行查询，假设我需要按username进行检索用户信息，需要引入额外的反向索引机制(类似HBASE二级索引)，如在redis上存储username->userid的映射，以username查询的例子变成了先通过查询username->userid，再通过userid查询相应的信息。

实际上这个做法很简单，但是我们不要忽略了一个额外的隐患，那就是数据不一致的隐患。存储在redis里的username->userid和存储在mysql里的userid->username必须需要是一致的，这个保证起来很多时候是一件比较困难的事情，举个例子来说，对于修改用户名这个场景，你需要同时修改redis和mysql,这两个东西是很难做到事务保证的,如mysql操作成功 但是redis却操作失败了(分布式事务引入成本较高),对于互联网应用来说，可用性是重要的，一致性是其次，所以能够容忍小量的不一致出现. 毕竟从占比来说，这类的不一致的比例可以微乎其微到忽略不计(一般写更新也会采用mq来保证直到成功为止才停止重试操作)

在这样的架构下，我们来看看数据存储的瓶颈是什么?

在这个拆分理念上搭建起来的架构，理论上不存在瓶颈(sharding key能确保各cluster流量相对均衡的前提下),不过确有一件恶心的事情，那就是cluster扩容的时候重做数据的成本，如我原来有3个cluster，但是现在我的数据增长比较快，我需要6个cluster，那么我们需要将每个cluster 一拆为二，一般的做法是

1.摘下一个slave,停同步,

2.对写记录增量log(实现上可以业务方对写操作 多一次写持久化mq 或者mysql主创建trigger记录写 等等方式)

3.开始对静态slave做数据, 一拆为二

4.回放增量写入,直到追上的所有增量,与原cluster基本保持同步

5.写入切换，由原3 cluster 切换为6cluster

有没有类似飞机空中加油的感觉，这是一个脏活，累活，容易出问题的活，为了避免这个，我们一般在开始的时候，设计足够多的sharding cluster来防止可能的cluster扩容这件事情。

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