数据库架构的演变

发表于:2014-4-03 10:44

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Lee的博客    来源:51Testing软件测试网采编

  最近看了很多公司架构的演变的文章,发现其中的基本思路和架构演变都很类似,这里也总结一下数据库架构的演变以及演变背后的思路。
  单主机
  最开始网站一般都是由典型的LAMP架构演变而来的,一般都是一台linux主机,一台apache服务器,php执行环境以及mysql服务器,一般情况下,这些都在一台虚拟主机上,简称单主机模式。
  单主机模式缺点:
  1 web服务器和mysql服务器公用一台主机,共享硬件资源,可能存在某一方资源征用太大,导致整个应用产生瓶颈
  2 当业务增长之后,没有办法做到横向扩展。
  3 容错性太差,一旦主机存在问题,整个应用不可用
  独立主机
  随着业务的发展,可以把mysql服务器和web服务器主机分开,分别部署,就是独立主机模式。
  独立主机模式下,web服务器和mysql不再共享硬件资源,分别部署。没有把鸡蛋放在一个篮子里面,增加了容错性。如果只是mysql服务器故障,那么对于web上不访问服务器的应用是不会受到影响的。而且web服务器可以做到横向扩展,如果web服务器性能不够,可以增加多台web服务器,进行负载均衡,分散web服务器的压力。
  独立主机模式的缺点:
  1 可扩展性问题:虽然web服务器可以做到横向扩展,但是mysql服务器是没有办法做到横向扩展的。
  2 可用性问题:mysql服务器存在单点问题,一旦mysql服务器宕机,对影响的影响很大
  3 性能问题:单台mysql服务器能够支撑的服务是有限的。
  读写分离
  随着业务的不断发展,数据库的压力会越来越大,单数据库慢慢的就不能满足需求了,一些网站对数据实时性要求不高,就会慢慢发展读写分离模式,对于普通的查询请求,分配到读库(也可以说是备库),对于修改请求,在主库上完成。对于读库,由于是无状态的,可以做到横向扩展。对于写库,还只能是单台主机
  这种模式其实有限制的,要根据业务的类型来考虑。主库的数据是最新的,但是同步到读库会有时延,所以应用必须能够容忍短暂的不一致性。对于一致性要求非常高的场景是不适合的。
  这种模式的存在的问题:
  1 可扩展性:虽然读库可以做到横向扩展,但是写库还不行,读库不能够横向扩展
  2 可用性:读库成为单点,一旦故障,影响所有的写操作业务
  业务垂直拆分
  随着业务的发展,一台写库显然不能够满足高并发的情况,但是考虑到写库是有状态的,不能简单的横向扩展,假设有两台写库,那么随机更新一台的数据,就会导致另一方数据存在问题。出现一种数据两个不同版本,显然是无法接受的。在写库上,可以考虑按照业务来垂直进行分库。由于我们这里讨论的是数据库架构,对于web层来说,其实也是可以按照业务垂直拆分的。
  在按照业务垂直拆分以后,系统在性能上有了很高的提升,只需要把业务上分成垂直部分,分的越细,系统的整体扩展能力就越强。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号