|
V5.0 云计算 腾飞（云数据库） 云计算现在是各大IT公司内部作为节约成本的一个突破口，对于数据存储的mysql来说，如何让其成为一个saas（Software as a Service）是关键点。在MS的官方文档中，把构建一个足够成熟的SAAS(MS简单列出了SAAS应用的4级成熟度)所面临的3个主要挑战：可配置性，可扩展性，多用户存储结构设计称为"three headed monster". 可配置性和多用户存储结构设计在Mysql saas这个问题中并不是特别难办的一件事情，所以这里重点说一下可扩展性。
对于架构实现的关键点，需要满足对业务透明，扩容缩容对业务不需要任何改动，那么就必须eat our own dog food，在你mysql saas内部解决这个问题，一般的做法是我们需要引入一个Proxy,Proxy来解析sql协议，按sharding key 来寻找cluster, 判断是读操作还是写操作来请求主 或者 从，这一切内部的细节都由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 ? 等待革命... 其他资料 百度Dbproxy设计 http://tech.it168.com/a2012/0413/1337/000001337034.shtml 淘宝RDS 云数据库设计： http://blog.csdn.net/ywh147/article/details/8954625 http://www./cn/news/2012/10/taobao-ump Mysql Fabric http://mysqlmusings./2013/09/brief-introduction-to-mysql-fabric.html http://vnwrites./2013/09/mysqlfabric-sharding-introduction.html http://vnwrites./2013/09/mysqlfabric-sharding-example.html http://vnwrites./2013/09/mysqlfabric-sharding-migration.html http://vnwrites./2013/09/mysqlfabric-sharding-maintenance.html
|
|
|
