最新消息:我们是一群和平年代充满浮躁与抱怨的程序猿,心中充满抱负却无处撒野,明明是一匹野马,却找不到草原。

MySQL分库分表解决大数据量

IT闲聊 goomoon 707浏览 0评论
前段时间在WOT大会上,听了我公司(58同城)架构师的一个分享,
《大数据量下,58同城mysql实践》PPT地址:http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=204498648&idx=1&sn=849f4cafec3eb4b7fccff884bb81e8ca&scene=5#rd,颇有感触和理解。下面就根据我个人经历就MYSQL分库分表做一些简单的记录吧。
在互联网公司,大数据量和高并发是很常见的事情,业内针对于这两大特点也都做了很多实践。对于高并发,我觉得可以从以下几方面来解决(严格的来说应该是缓解,绝对解决的办法很难做到):

1、将数据拦截在用户浏览器

所有的请求都是来自于用户,最起始点就是每个用户所使用的浏览器或者终端。这个时候可以根据一些规则对某部分用户进行拦截,比如:
1)小米手机抢购,在前端会有个规则来判断是否允许用户进入下一步,这个规则是根据用户ID来算的,所以那些抢购小米手机而每期都不中的人,你一直排队买不到,不是因为你的RP不好也不是因为你的网速慢,而是你的用户ID不好。赶上一个好的用户ID,龟速的网络也能买上。
2)淘宝秒杀,淘宝秒杀时候会有一个验证码,并且验证码相当复杂,也就这一步就将突如其来的高并发进行分流了,毕竟这个验证码用程序很难破解,人工打码也需要时间的。

2、增加站点服务器

这的确是一种最快的解决办法,但是不能长期使用,只能短暂地解决高并发。并且这种解决办法也很有限,毕竟一台机器所能承担的并发量也是有限的。

3、页面缓存,服务器端数据缓存

缓存是很多工程师常用的一种解决方式之一,效果也是很不错的,对于一些不太常改变的页面或者数据进行缓存,可以从某种程度上很大的减少服务器端的压力,目前常用的缓存比如MemCached、Redis等都有不错的分布式存储优势以及高效的读写性能。
但是对于一些实时的数据,Cache就有点爱莫能助了。。。比如电商网站秒杀时商品库存等等

4、架构优化之数据库优化

实时的数据读写,肯定就涉及到读数据库了,对于大数据量的网站,分库分表是必不可少的一项工作。
对于分库的解决思路:

1)复制

比如:1主2从、1主1从等,主库与从库之间的同步策略就是复制,有同步的也有异步的,根据业务可以选择合适的。

2)读写分离

主库用来写,从库用来读。但是这种策略对于读多写少的场景比较适合,但是对于读写相近,或者写多读少的场景这种分离就不太适合了,这时候就可以考虑水平切分数据库表了。这也就是下面要说的一个解决方案:拆库。

3)拆库(水平拆分)

水平拆分,将数据分在多个库里,每个库里数据都是不一样的,这就是水平切分。水平切分库的一个关键点就在于选择一个合适的Key,也就是拆分规则,既要均匀拆分又要保证将来的拓展。
下面就58通常能够的数据库拆库做一下分享:
归类下,约有下面四类场景:
a)“单key”场景,
比如:用户库, user(uid, XXOO),因为uid是user的唯一key,我们完全可以用uid作为分库的依据,
b)“1对多”场景,帖子库如何拆分: tiezi(tid, uid, XXOO)
c)“多对多”场景,好友库如何拆分: friend(uid, friend_uid, XXOO)
d)“多key”场景,订单库如何拆分:order(oid, buyer_id, seller_id, XXOO)

转载请注明:刘召考的博客 » MySQL分库分表解决大数据量

发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址