Thresh

本节了解 MySQL 利用架构在不同的并发拜访量级和数据量级下，架构的演变过程。

MySQL 利用架构演变

• 单机单库
  一个简略的小型网站或者利用背地的架构能够非常简单, 数据存储只须要一个 MySQL Instance 就能满足数据读取和写入需要（这里疏忽掉了数据备份的实例），处于这个的阶段零碎，个别会把所有的信息存到一个 MySQL Instance 外面。
  毛病:

  1. 数据量太大，超出一台服务器接受 
  2. 读写操作量太大，超出一台服务器接受 
  3. 一台服务器挂了，利用也会挂掉（可用性差）

• 主从架构
  次要解决单体架构下的高可用和读扩大问题，通过给 Instance 挂载从库解决读取的压力，主库宕机也能够通过主从切换保障高可用。在 MySQL 的场景下就是通过主从构造（双主构造也属于非凡的从），主库抗写压力，通过从库来分担读压力，对于写少读多的利用
  毛病:

  1. 数据量太大，超出一台服务器接受 
  2. 写操作太大，超出一台主服务器接受
  

• 分库分表
  遇到写入瓶颈和存储瓶颈时，能够通过程度拆分来解决，程度拆分和垂直拆分有较大区别，垂直拆分拆完的后果，每一个实例都是领有全副数据的，而程度拆分之后，任何实例都只有全量的 1 / n 的数据。
  毛病:

  1. 数据如何路由成为一个关键问题，个别能够采纳范畴拆分，List 拆分、Hash 拆分等。2. 如何保持数据的一致性也是个难题。

• 云数据库
  云数据库（云计算）, 对于数据存储的 MySQL 来说，如何让其成为一个 saas（Software as a Service）是关键点。MySQL 作为一个 saas 服务，服务提供商负责解决可配置性，可扩展性，多用户存储结构设计等这些疑难问题。