新手问题 MySQL 水平扩展方案讨论

ihlayy · 2012年11月30日 · 最后由 xiaogui 回复于 2012年12月01日 · 10504 次阅读

顺便说下,如果 mysql 也水平扩展的话,那事务,锁怎么处理?以前可能都在单台 web 服务器加锁或者加事务,但是水平扩展有多台了,就锁不住了。大家都是怎么一个方案?

是说的横向拆分吗

对恩,横向拆分的时候,程序或者 DB 设计应该注意些什么?比如锁,事务?都神么样的方案,好像有 mysql ndb

事务肯定不能用 mysql 自带的了,哪个事务只支持单个数据库内部事务。 拆分要重新设计表结构,以及业务流程,设置重新设计数据库,避免跨库事务,如果非要跨的话,需要自己写代码来保证数据的一致性。

关系型数据库在水平扩展上都非常痛苦,不是一句话两句话能说清楚的。

方案一是 MySQL 的复制,一个 Master 数据库,多个 Salve,然后利用 MySQL 的异步复制能力实现读写分离,这个方案目前应用比较广泛,但是不怎么好玩。

方案二是 MySQL 的 Sharding 策略,很不巧的是 MySQL 在设计之初就没有考虑过很好的支持自动 Sharding。特别是构建一个自动基于应用的数据分区和负载均衡,以及单点故障处理等等,用 MySQL 实现 Sharding 的话,Sharding 逻辑在你的应用内手动实现的并维护,要手动 Sharding 非常不容易,而且规划好避免每个单机 MySQL 实例的负载过重,以及不同 Sharding 中的数据迁移相当费事,可谓困难重重。这些在后面发展起来的 NoSQL 就处理的很好,比如 MongoDB,甚至自动 Sharding 成了 MongoDB 的核心功能。

#4 楼 @lgn21st 做水平扩展没有一些现成的东西吗,大家都手动 sharding。

那确实单点问题,数据分片都是个大问题。那个 mysql ndb 有实际使用吗?好像淘宝也有开源的类库?

另外 MySQL 的复制,如果数据量大了还是得做 sharding 吧。。。sharding 最后逃不掉啊感觉

#5 楼 @ihlayy 你说的这些都是关系数据库长久的痛点,可能有一些工具和库,但是好用的,信得过的有没有我不知道,我自己的方案是绕行到 MongoDB 上去。

#6 楼 @lgn21st

我们老总对 mongodb 还是有所顾忌的。。喜欢 redis+mysql 的架构方式。。

nosql 这块到时候还是要研究下唉,品种太多了

我们现在 mysql 分主从,读写分离。缓存使用 redis,自己写了一个将 mysql 导 redis 的小系统。

没实际操作过大数据量,想问下,每天大概有 300W 的访问量,会有大量的图片上传,会有交易。应该考虑怎样的架构?

#8 楼 @xiaogui

还是有经验的唉。。我之前都没做过数据量比较大的,这次悲催了,多指导唉

#9 楼 @ihlayy 不知道你项目的详细情况,先说几句: 1、把图片相关的操作与其他业务分离,图片相关的上传比较消耗磁盘 io 2、mysql 作个主从读写分离,将那种"不是更新后马上需要读取的读操作"放在从库操作。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号