MySQL分库分表解决大数据量

前段时间在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分库分表解决大数据量