1.5 数据库复制

根据维基百科上的定义，“在很多数据库管理系统中，通常都可以利用原始数据库（Master，主库）和拷贝数据库（Slave，从库）之间的主从关系进行数据库复制。”[3]。

主库通常只支持写操作，从库保存主库的数据副本且仅支持读操作。所有修改数据的指令，如插入、删除或更新等，都必须发送给主库来执行。在大部分应用中，对数据库的读操作远多于写操作，因此系统中从库的数量通常多于主库的数量。图1-5展示了一个主库搭配多个从库的例子。

图1-5

数据库复制有如下优点：

• 性能更好。在主从模式下，所有的写操作和更新操作都发生在主节点（主库）上，而读操作被分配到各个从节点（从库），因此系统能并行处理更多的查询，性能得到提升。

• 可靠性高。如果有一台数据库服务器因自然灾害而损毁，比如遭遇台风或者地震，数据依然被完好保存，你不需要担心数据会丢失，因为这些数据已经被复制到处于不同地理位置的其他数据库服务器中。

• 可用性高。由于不同物理位置的从库都复制了数据，因此即使一台数据库服务器宕机，你的网站依然可以运行，因为另一台数据库服务器里存储了数据。

前面讨论了负载均衡器是如何帮助提升系统可用性的，这里我们问一个同样的问题：如果有数据库服务器宕机了怎么办？图1-5所示的架构可以应对这种情况。

• 如果只有一个从库，而它宕机了，则系统暂时会将读操作路由至主库。一旦发现有从库宕机，就会有一个新的从库来替代它。要是有多个从库可用，读操作会被重定向到其他正常工作的从库上；同样，也会有一个新的数据库服务器来替代宕机的那个。

• 如果主库宕机，会有一个从库被推选为新的主库。所有的数据库操作会暂时在新的主库上执行。另一个从库会替代原来的从库并立即开始复制数据。在生产环境中，因为从库的数据不一定是最新的，所以推选一个新的主库会更麻烦。缺失的数据需要通过运行数据恢复脚本来补全。尽管还有别的数据复制方式可以解决数据缺失问题，比如多主复制或者循环复制，但是它们的设置更加复杂，本书不对这些内容进行讨论。感兴趣的读者可以进一步阅读相关参考资料[4]。

图1-6展示了添加了负载均衡器和数据库复制之后的系统设计方案。

图1-6

我们再来看一下现在的设计：

• 用户从DNS获取负载均衡器的IP地址。

• 用户通过这个IP地址连接负载均衡器。

• HTTP请求被转发到服务器1或者服务器2上。

• Web服务器在从库中读取用户数据。

• Web服务器把所有修改数据的操作请求都转发到主库上，包括写、更新和删除操作。

现在我们对于网络层和数据层都有了一定的理解，接下来可以提升加载和响应速度了。可以通过添加缓存层、把静态资源（JavaScript、CSS、图片、视频文件）转移到内容分发网络（CDN）上来实现加速。