Mysql在大型网站的应用架构演变 - 大熊先生|互联网后端技术 - 博客园
http://www.cnblogs.com/Creator/p/3776110.html
写在最前:
本文主要描述在网站的不同的并发访问量级下，Mysql架构的演变
可扩展性的理想状态
一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响(no down time)，这就是可扩展性的理想状态！
这里简单举个我的例子，对于用户信息这类表 （3个索引），16G内存能放下大概2000W行数据的索引，简单的读和写混合访问量3000/s左右没有问题，你的应用场景是否
V3.0 主从架构
此类架构主要解决V2.0架构下的读问题，通过给Instance挂数据实时备份的思路来迁移读取的压力，在Mysql的场景下就是通过主从结构，主库抗写压力，通过从库来分担读压力，对于写少读多的应用，V3.0主从架构完全能够胜任
在这样的架构下，我们来看看数据存储的瓶颈是什么？
1.写入量主库不能承受
V4.0 水平拆分
对于V2.0 V3.0方案遇到瓶颈时，都可以通过水平拆分来解决，水平拆分和垂直拆分有较大区别，垂直拆分拆完的结果，在一个实例上是拥有全量数据的，而水平拆分之后，任何实例都只有全量的1/n的数据，以下图Userinfo的拆分为例，将userinfo拆分为3个cluster，每个cluster持有总量的1/3数据，3个cluster数据的总和等于一份完整数据（注：这里不再叫单个实例 而是叫一个cluster 代表包含主从的一个小mysql集群）
数据如何路由？
1.Range拆分
sharding key按连续区间段路由，一般用在有严格自增ID需求的场景上，如Userid, Userid Range的小例子：以userid 3000W 为Range进行拆分 1号cluster userid 1-3000W 2号cluster userid 3001W-6000W
2.List拆分
List拆分与Range拆分思路一样，都是通过给不同的sharding key来路由到不同的cluster,但是具体方法有些不同,List主要用来做sharding key不是连续区间的序列落到一个cluster的情况，如以下场景：假定有20个音像店，分布在4个有经销权的地区，如下表所示：
地区
商店ID 号
北区
3, 5, 6, 9, 17
东区
1, 2, 10, 11, 19, 20
西区
4, 12, 13, 14, 18
中心区
7, 8, 15, 16
业务希望能够把一个地区的所有数据组织到一起来搜索，这种场景List拆分可以轻松搞定
3.Hash拆分
通过对sharding key 进行哈希的方式来进行拆分，常用的哈希方法有除余,字符串哈希等等，除余如按userid%n 的值来决定数据读写哪个cluster，其他哈希类算法这里就不细展开讲了。
在这样的架构下，我们来看看数据存储的瓶颈是什么？
在这个拆分理念上搭建起来的架构，理论上不存在瓶颈（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扩容这件事情
