Facebook开心001人人网优酷豆瓣淘宝等高流量、高并发的网站,单点数据库很难支撑得住,WEB2.0类型的网站中使用MySQL的居多,要么用MySQL自带的MySQL NDB Cluster(MySQL5.0及以上版本支持MySQL NDB Cluster功能),或者用MySQL自带的分区功能(MySQL5.1及以上版本支持分区功能),我所知道的使用这两种方案的很少,一般使用主从复制,再加上MySQL Proxy实现负载均衡、读写分离等功能,在使用主从复制的基础上,再使用垂直切分及水平切分;或者不使用主从复制,完全使用垂直切分加上水平切分再加上类似Memcached的系统也可以解决问题。

1.优酷的经验
数据库采用水平扩展,主从复制,随着从数据库的增多,复制延迟越来越厉害,最终无法忍受。
最终还是采用数据库的sharding,把一组用户相关的表和数据放到一组数据库上。
使用SSD来优化mysql的I/O,性能提升明显,每块16G,6块SSD做RAID。
数据库的类型选用MYISAM
数据库的拆分策略,先纵向按照业务或者模块拆分。对于一些特别大的表,再采用垂直拆分
根据用户进行分片,尽可能不要跨篇查询。如果确实要跨片查询,可以考虑搜索的方案,先索引再搜索。
分布式的数据库方案太复杂,否掉。

优酷使用的是数据库分片技术,而抛弃了由于数据量的越来越多导致复制延迟的问题。按照user_id进行分片,这样必须有一个全局的表来管理用户与shard的关系,根据user_id可以得到share_id,然后根据share_id去指定的分片查询指定的数据。

假如此表的表名为sharding_manager,如果网站的用户数太多,比如千万级的或甚至更大比如亿级的用
户,此时此表也许也会成为一个瓶颈,因为查询会非常频繁,所有的动态请求都要读此表,这时可以用其它的解决方案,比如用Memcached、Tokyo
Cabinet、Berkeley DB或其它的性能更高的方案来解决。

具体怎么定位到哪台db服务器,定位到哪个数据库,定位到哪个shard(就是userN,msgN,videoN),优酷网的架构文档中说得不是很仔细,这里只能猜测一下了。

根据优酷的架构图,一共有2台db服务器,每台db服务器有2个数据库,每个数据库有3个shard,这样一共是2 * 2 * 3 = 12个shard。

user_id一般是自增型字段,用户注册的时候可以自动生成,然后看有几台db服务器,假如有m台db服务器,则用 user_id % m便可以分配一台db服务器(例如0对应100,1对应101,以此类推,字段mysql_server_ip的值确定),假设每台服务器有n个数据库,则用user_id % n可以定位到哪个数据库(字段database_name的值确定),假设每个数据库有i个shard,则用user_id % i可以定位到哪个shard(字段shard_id的值确定),这样就可以进行具体的数据库操作了。

user_id share_id mysql_server_ip database_name
101      2           192.168.1.100   shard_db1
105      0           192.168.1.100   shard_db2
108      0           192.168.1.101   shard_db3(或shard_db1)
110      1           192.168.1.101   shard_db4(或shard_db2)

如上述user_id为101的用户,连接数据库服务器192.168.1.100,使用其中的数据库为shard_db1,使用其中的表系列为user2,msg2,video2

如果上述的m,n,i发生变化,比如网站的用户不断增长,需要增加db服务器,此时则需要进行数据库迁移,关于迁移,参见这儿

因为表位于不同的数据库中,所以不同的数据库中表名可以相同
server1(192.168.1.100)
shard_db1
user0
msg0
video0
user1
msg1
video1
...
userN
msgN
videoN
shard_db2
user0
msg0
video0
user1
msg1
video1
...
userN
msgN
videoN

因为表位于不同的数据库服务器中,所以不同的数据库服务器中的数据库名可以相同
server2(192.168.1.101)
shard_db3(这里也可以用shard_db1)
user0
msg0
video0
user1
msg1
video1
...
userN
msgN
videoN
shard_db4(这里也可以用shard_db2)
user0
msg0
video0
user1
msg1
video1
...
userN
msgN
videoN

2.豆瓣的经验
由于从主库到辅库的复制需要时间
更新主库后,下一个请求往往就是要读数据(更新数据后刷新页面)
从辅库读会导致cache里存放的是旧数据(不知道这个cache具体指的是什么,如果是Memcached的话,如果更新的数据的量很大,难道把所有更新过的数据都保存在Memcached里面吗?)
解决方法:更新数据库后,在预期可能会马上用到的情况下,主动刷新缓存
不完美,but it works

豆瓣后来改为双MySQL Master+Slave说是能解决Replication Delay的问题,不知道是怎么解决的,具体不太清楚。

3.Facebook的经验

下面一段内容引用自www.dbanotes.net
大量的 MySQL + Memcached 服务器,布署简示:
California (主 Write/Read)............. Virginia (Read Only)

数据中心在 California ,远程中心在 Virginia 。这两个中心网络延迟就有 70ms,MySQL 数据复制延迟有的时候会达到
20ms. 如果要让只读的信息从 Virginia 端发起,Memcached 的 Cache 数据一致性就是个问题。

1 用户发起更新操作,更名 "Jason" 到 "Monkey" ;
2 主数据库写入 "Monkey",删除主端 Memcached 中的名字值,但Virginia 端 Memcached 不删;(这地方在 SQL 解析上作了一点手脚,把更新的操作"示意"给远程);
3 在 Virginia 有人查看该用户 Profile ;
4 在 Memcached 中找到键值,返回值 "Jason";
5 复制追上更新 Slave 数据库用户名字为 "Monkey",删除 Virginia Memcached 中的键值;
6 在 Virginia 有人查看该用户 Profile ;
7 Memcache 中没找到键值,所以从 Slave 中读取,然后得到正确的 "Monkey" 。
Via

从上面3可以看出,也仍然存在数据延迟的问题。同时master中数据库更新的时候不更新slave中的memcached,只是给slave发个通知,说数据已经改变了。

那是不是可以这样,当主服务器有数据更新时,立即更新从服务器中的Memcached中的数据,这样即使有延迟,但延迟的时间应该更短了,基本上可以忽略不计了。

4.Netlog的经验

对于比较重要且必须实时的数据,比如用户刚换密码(密码写入 Master),然后用新密码登录(从 Slaves 读取密码),会造成密码不一致,导致用户短时间内登录出错。所以在这种需要读取实时数据的时候最好从 Master 直接读取,避免 Slaves 数据滞后现象发生。还好,需要读取实时数据的时候不多,比如用户更改了邮件地址,就没必要马上读取,所以这种 Master-Slaves 架构在多数情况下还是有效的。Via这篇文章

我的相关日志:

怎样解决MySQL数据库主从复制延迟的问题的更多相关文章

  1. 怎样解决MySQL数据库主从复制延迟的问题---流行网站的解决办法(转载)

    像Facebook.开心001.人人网.优酷.豆瓣.淘宝等高流量.高并发的网站,单点数据库很难支撑得住,WEB2.0类型的网站中使用MySQL的 居多,要么用MySQL自带的MySQL NDB Clu ...

  2. 如何解决mysql数据库X小时无连接自动关闭

    windows下打开my.ini,增加: interactive_timeout=28800000 wait_timeout=28800000 专家解答:MySQL是一个小型关系型数据库管理系统,由于 ...

  3. mysql数据库主从复制部署笔记

    主从复制是mysql中数据库实时同步的一个常用做法了,今天我来给各位介绍一下关于mysql数据库主从复制部署一个过程,希望此例子对各位同学参考参考. 数据库主从复制原理: 数据库的主从复制就是从mas ...

  4. 如何解决mysql数据库8小时无连接自动关闭

    windows下打开my.ini,增加: interactive_timeout=28800000 wait_timeout=28800000 专家解答:MySQL是一个小型关系型数据库管理系统,由于 ...

  5. Mysql数据库主从复制搭建

    Mysql数据库主从复制原理: 主库开启bin-log日志,同时生成IO线程.IO线程负责将用户写入数据库的sql语句记录在二进制日志bin-log,该记录过程可并发进行:生成标识号 server i ...

  6. (转载)解决MySql 数据库 提示:1045 access denied for user 'root'@'localhost' using password yes

    今天想用用MySQL 数据库  谁知道老提示 1045 access denied for user 'root'@'localhost' using password yes 最后在csdn 上找到 ...

  7. mysql的主从复制延迟问题--看这一篇就够了

    ​ 在之前我们已经讲解了一主一从,双主双从的mysql集群搭建,在单机应用的时候看起来没有问题,但是在企业的生产环境中,在很多情况下都会有复制延迟的问题. ​ 主从复制的原理我们在此处就不再赘述了,之 ...

  8. [转载] 使用MySQL Proxy解决MySQL主从同步延迟

    原文地址:http://koda.iteye.com/blog/682547 MySQL的主从同步机制非常方便的解决了高并发读的应用需求,给Web方面开发带来了极大的便利.但这种方式有个比较大的缺陷在 ...

  9. 使用MySQL Proxy解决MySQL主从同步延迟

    MySQL的主从同步机制非常方便的解决了高并发读的应用需求,给Web方面开发带来了极大的便利.但这种方式有个比较大的缺陷在于MySQL的同步机制 是依赖Slave主动向Master发请求来获取数据的, ...

随机推荐

  1. hive学习(六) 参数和动态分区

    1.hive 参数.变量 1.1hive的命名空间: hive当中的参数.变量,都是以命名空间开头  

  2. beego学习笔记(4):开发文档阅读(5)

    controller的逻辑: 我们看下面的代码,就知道怎么传值的: import ( "github.com/astaxie/beego" ) type MainControlle ...

  3. 三十分钟理解:线性插值,双线性插值Bilinear Interpolation算法

    线性插值 先讲一下线性插值:已知数据 (x0, y0) 与 (x1, y1),要计算 [x0, x1] 区间内某一位置 x 在直线上的y值(反过来也是一样,略): y−y0x−x0=y1−y0x1−x ...

  4. MVC公开课 – 2.查询,删除 (2013-3-15广州传智MVC公开课)

    查询 /Controller/HomeController.cs /// <summary> /// 查询 文章 列表 /// </summary> /// <retur ...

  5. 《HBase权威指南》学习笔记

    第一章  简介 背景: GFS:集群存储海量数据,数据在节点间冗余复制,即使一台存储服务器发生故障,也不会影响可用性. GFS的缺点:适合存储少许非常大的文件,而不适合存储大量小文件,因为文件的元数据 ...

  6. SGU 217. Two Cylinders

    题意:给空间内两根圆柱,求轴线垂直相交时公共部分的体积. 暴力积分即可. ID: Date'n'Time: Name: Task: .Ext: Status: Time: Memory: 158937 ...

  7. 【PAT】1001. A+B Format (20)

    1001. A+B Format (20) Calculate a + b and output the sum in standard format -- that is, the digits m ...

  8. [实战]MVC5+EF6+MySql企业网盘实战(23)——文档列表

    写在前面 上篇文章实现了图片列表,这篇文章实现文档列表将轻车熟路,因为逻辑基本相似,只是查询条件的不同.这里将txt,doc,docx,ppt,pptx,xls,xlsx的文件都归为文档列表中. 系列 ...

  9. [实战]MVC5+EF6+MySql企业网盘实战(19)——BJUI和ztree

    写在前面 上周在博客园看到一篇通用权限系统的文章,看到他那个UI不错,这里就研究了一下,将网盘的UI修改为他的那个,感兴趣的可以参考:http://b-jui.com/ 系列文章 [EF]vs15+e ...

  10. js的浮点(小数)数+-*/

    //除法 function accDiv(arg1,arg2){ var t1=0,t2=0,r1,r2; try{t1=arg1.toString().split(".")[1] ...