对于高并发流量大的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主从复制延迟