首页 > 代码库 > mysql主从复制延迟

mysql主从复制延迟

  对于高并发流量大的web站点,单点的数据库往往很难支持,一般是使用主从复制,再加上mysql proxy实现复制均衡,读写分离等功能等。但是主从复制会有延迟,大网站是如何解决这些问题的呢?转载自PHP老杨文章。

1.优酷的经验

  数据库采用水平的扩展,主从复制,随着从库的增多,复制延迟越来越厉害,最终无法忍受。最终还是采用了平行的数据库,相当于集群吧,把一组用户的相关的数据和表放到一组的数据库上。使用SSD来优化mysql的I/O,性能明显提高,采用数据库分片的技术,抛弃了原来主从延迟的问题,按照userid进行分片,这样的话就必须有一个全局的表来管理用户和shard的关系,根据userid可以得到shardid,然后根据shardid去制定的分片查询数据,但是如果网站的用户过多,此表也可能会成为瓶颈,因为查询会非常的频繁,可以考虑使用memcache,等方案。

  具体的用户分片的方案是userid一般是用户注册的时候自动生成的,然后看有几台web服务器,假如有M台,用userid % M便可以分配一台DB服务器,然后再继续的对应数据库表等,求余数的方案来进行。

2.facebook的经验

  采用大量的MySQL服务器加memcache服务器。

  用户发起更新操作,更名‘a‘->‘b‘---->主数据库写入b,删除主端memcahce的名字值-->远程的memcache并不删除,主从复制更新从库,然后更新memcache,这样的方案仍然会有数据延迟的问题,我觉得可以这样,当主服务器有数据更新的时候,立即更新从服务器中的memcache的数据,这样的话延迟就非常少了。

  对于比较重要而写必须实时的数据,比如用户更换密码,更新操作写入主库,然后用新密码登录(从库读),会造成密码不一致的情况,导致短时间内登录错误,所以这种需要实时读取的数据最好从主库直接读取,避免从库数据滞后,还好需要实时读取的情况并不是很多。

mysql主从复制延迟