对于高并发流量大的web站点，单点的数据库每每很难支持，通常是使用主从复制，再加上mysql proxy实现复制均衡，读写分离等功能等。可是主从复制会有延迟，大网站是如何解决这些问题的呢？转载自PHP老杨文章。mysql
1.优酷的经验linux
数据库采用水平的扩展，主从复制，随着从库的增多，复制延迟愈来愈厉害，最终没法忍受。最终仍是采用了平行的数据库，至关于集群吧，把一组用户的相关的数据和表放到一组的数据库上。使用SSD来优化mysql的I/O，性能明显提升，采用数据库分片的技术，抛弃了原来主从延迟的问题，按照userid进行分片，这样的话就必须有一个全局的表来管理用户和shard的关系，根据userid能够获得shardid，而后根据shardid去制定的分片查询数据，可是若是网站的用户过多，此表也可能会成为瓶颈，由于查询会很是的频繁，能够考虑使用memcache，等方案。web
具体的用户分片的方案是userid通常是用户注册的时候自动生成的，而后看有几台web服务器，假若有M台，用userid % M即可以分配一台DB服务器，而后再继续的对应数据库表等，求余数的方案来进行。sql
2.facebook的经验数据库
采用大量的MySQL服务器加memcache服务器。服务器
用户发起更新操做,改名‘a'->'b'---->主数据库写入b,删除主端memcahce的名字值-->远程的memcache并不删除，主从复制更新从库，而后更新memcache,这样的方案仍然会有数据延迟的问题，我以为能够这样，当主服务器有数据更新的时候，当即更新从服务器中的memcache的数据，这样的话延迟就很是少了。并发
对于比较重要而写必须实时的数据，好比用户更换密码，更新操做写入主库，而后用新密码登陆（从库读），会形成密码不一致的状况，致使短期内登陆错误，因此这种须要实时读取的数据最好从主库直接读取，避免从库数据滞后，还好须要实时读取的状况并非不少。高并发