高并发网站原理

对于一个刚上线的互联网项目来说，由于前期活跃用户数量并不多，并发量也相对较小，所以此时企业一般都会选择将所有数据存放在 一个数据库 中进行访问操作。但随着后续的市场推广力度不断加强，用户数量和并发量不断上升，这时如果仅靠一个数据库来支撑所有访问压力，几乎是在 自寻死路 。所以一旦到了这个阶段，大部分  Mysql DBA   就会将数据库设置成 读写分离状态 ，也就是一个  Master 节点对应多个  Salve   节点。经过  Master/Salve   模式的设计后，完全可以应付单一数据库无法承受的负载压力，并将访问操作分摊至多个  Salve   节点上，实现真正意义上的读写分离。但大家有没有想过，单一的  Master/Salve   模式又能抗得了多久呢？如果用户数量和并发量出现 量级 上升，单一的  Master/Salve   模式照样抗不了多久，毕竟一个  Master   节点的负载还是相对比较高的。为了解决这个难题，  Mysql DBA   会在单一的  Master/Salve   模式的基础之上进行数据库的 垂直分区 （分库）。所谓垂直分区指的是可以根据业务自身的不同，将原本冗余在一个数据库内的业务表拆散，将数据分别存储在不同的数据库中，同时仍然保持  Master/Salve   模式。经过垂直分区后的  Master/Salve   模式完全可以承受住难以想象的高并发访问操作，但是否可以永远 高枕无忧 了？答案是否定的，一旦业务表中的数据量大了，从维护和性能角度来看，无论是任何的  CRUD   操作，对于数据库而言都是一件极其耗费资源的事情。即便设置了索引， 仍然无法掩盖因为数据量过大从而导致的数据库性能下降的事实 ，因此这个时候  Mysql DBA   或许就该对数据库进行 水平分区 （分表，  sharding   ），所谓水平分区指的是将一个业务表拆分成多个子表，比如  user_table0   、  user_table1   、  user_table2   。子表之间通过某种契约关联在一起，每一张子表均按段位进行数据存储，比如  user_table0   存储  1-10000   的数据，而  user_table1   存储  10001-20000   的数据，最后  user_table3   存储  20001-30000   的数据。经过水平分区设置后的业务表，必然能够将原本一张表维护的海量数据分配给  N   个子表进行存储和维护，这样的设计在国内一流的互联网企业比较常见