高性能数据库集群：读写分离

笔记

• 大部分情况下，我们做架构设计主要都是基于已有的成熟模式，结合业务和团队的具体情况， 进行一定的优化或者调整；即使少部分情况我们需要进行较大的创新，前台也是需要对已有的各种架构模式和技术非常熟悉。

• 读写分离的基本原理是将数据库读写操作分散到不同的节点上，下面是其基本架构图。

  
  读写分离示意图

• 读写分离的基本实现是：

  • 数据库服务器搭建主从集群，一主一从、一主多从都可以。
  • 数据库主机负责读写操作，从机只负责读操作。
  • 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据。
  • 业务服务器将写操作发给数据库主机，将读操作发给数据库从机。

• 两个细节点将引入设计复杂度：主从复制延迟和分配机制。

• 解决主从复制延迟有几种常见的方法：

  1. 读从机失败后再读一次主机。
  2. 写操作后的读操作指定发给数据库主服务器。
  3. 关键业务读写操作全部指向主机，非关键业务采用读写分离。

• 将读写操作区分开来，然后访问不同的数据库服务器，一般有两种方式：程序代码封装和中间件封装。

• 程序代码封装指在代码中抽象一个数据访问层（所以有的文章也称这种方式为“中间层封装”），实现读写操作分离和数据库服务器连接的管理。例如，基于 Hibernate 进行简单封装，就可以实现读写分离，基本架构是：

  
  代码封装实现读写分离示意图

• 中间件封装指的是独立一套系统出来，实现读写操作分离和数据库服务器连接的管理。事实上在业务服务器看来，中间件就是一个数据库服务器。其基本架构是：

  
  中间件实现读写分离示意图

• 由于数据库中间件的复杂度要比程序代码封装高出一个数量级，一般情况下建议采用程序语言封装的方式，或者使用成熟的开源数据库中间件。如果是大公司，可以投入人力去实现数据库中间件，因为这个系统一旦做好，接入的业务系统越多，节省的程序开发投入就越多，价值也越大。

理解与思考

学习思维导图

课后习题

数据库读写分离一般应用于什么场景？能支撑多大的业务规模？
适用数据更改较少的场景，数据一旦写入，大部分后续的操作都是读。
从机可以水平扩展，业务规模应该会比较大，但是因为同步操作，对网络带宽要求较高。

实践

目标1 搭建mysql数据库集群（一主而从）

目标2 实现基于程序代码封装的读写分离

目标3 实现基于中间件的读写分离