MySQL在大型网站的应用架构演变

　　对于架构实现的关键点，需要满足对业务透明，扩容缩容对业务不需要任何改动，那么就必须eat our own dog food，在你MySQL SaaS内部解决这个问题，一般的做法是我们需要引入一个Proxy，Proxy来解析SQL协议，按sharding key来寻找Cluster，判断是读操作还是写操作来请求Master或者Slave，这一切内部的细节都由Proxy来屏蔽。

这里借淘宝的图来列举一下Proxy需要干哪些事情

　　对于架构实现的关键点，扩容缩容全自动化且对在线服务无影响； 扩容缩容对应到的数据操作即为数据拆分和数据合并，要做到完全自动化有非常多不同的实现方式，总体思路和V4.0介绍的瓶颈部分有关，目前来看这个问题比较好的方案就是实现一个伪装Slave的Sync Slave，解析MySQL同步协议，然后实现数据拆分逻辑，把全量数据进行拆分。具体架构见下图：

　　其中Sync Slave对于Original Master来说，和一个普通的Mysql Slave没有任何区别，也不需要任何额外的区分对待。需要扩容/缩容时，挂上一个Sync slave，开始全量同步+增量同步，等待一段时间追数据。以扩容为例，若扩容后的服务和扩容前数据已经基本同步了，这时候如何做到切换对业务无影响？ 其实关键点还是在引入的Proxy，这个问题转换为了如何让Proxy做热切换后端的问题。这已经变成一个非常好处理的问题了。

　　另外值得关注的是：2014年5月28日——为了满足当下对Web及云应用需求，甲骨文宣布推出MySQL Fabric，在对应的资料部分我也放了很多Fabric的资料，有兴趣的可以看看，说不定会是以后的一个解决云数据库扩容缩容的手段。 

V more ?

等待革命……

淘宝用例

• 淘宝RDS 云数据库设计： http://blog.csdn.net/ywh147/article/details/8954625  http://www.infoq.com/cn/news/2012/10/taobao-ump
  

Mysql  Fabric

• http://mysqlmusings.blogspot.jp/2013/09/brief-introduction-to-mysql-fabric.html
  
• http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-introduction.html
  
• http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-example.html
  
• http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-migration.html
  
• http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-maintenance.html
  

博文链接：Mysql在大型网站的应用架构演变