数据库架构的演变

浏览数：25 / 时间：2015年06月12日

如果你对项目管理、系统架构有兴趣，请加微信订阅号“softjg”，加入这个PM、架构师的大家庭

最近看了很多公司架构的演变的文章，发现其中的基本思路和架构演变都很类似，这里也总结一下数据库架构的演变以及演变背后的思路。

单主机

最开始网站一般都是由典型的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层来说，其实也是可以按照业务垂直拆分的。