数据库负载均衡那些事儿，聊聊几种常见的做法和思路

说到数据库负载均衡,说白了就是想个办法，别让一个数据库太累，把活儿分给几个数据库一起干，这样大家都能轻松点，整个系统的速度和稳定性也就上去了，这事儿听起来简单，但做起来门道还挺多，因为数据库不像普通的网页服务器，它肚子里装着最重要的数据，不能随便乱分，下面我们就聊聊几种常见的做法和思路。

第一种思路，也是最常见的，就是在应用程序和数据库之间加个“中间人”。

这个“中间人”负责接收所有应用程序发来的请求，然后看哪个数据库小弟比较闲，就把请求转给它，这种做法里，最经典的就是“读写分离”。

读写分离,顾名思义，就是把“读”和“写”这两种操作分开，一个网站或者应用，大部分操作都是查询、浏览，也就是“读”操作，真正修改数据的“写”操作要少得多，我们可以设置一个主数据库，专门负责处理“写”操作（比如新增、修改、删除数据），设置好几个从数据库，它们的数据是从主数据库那里同步过来的副本，专门负责处理大量的“读”操作（比如查询、列表展示）。

这样一来,写的压力全在主库身上，而读的压力就被分摊到了多个从库上，应用程序要读数据的时候，就去问那个“中间人”（通常叫中间件或代理），这个中间件会挑一个当前最空闲的从库来应答，要写数据的时候，中间件则会把请求统统转给主库。

这种做法好处很明显,简单有效，特别适合读多写少的场景，很多开源软件像MySQL Proxy，或者一些云服务商提供的数据库代理服务，都是干这个的，但缺点也有，比如从库的数据和主库之间会有一点点延迟，如果你刚写完数据立马就要读，可能会读不到最新的结果，这就需要应用程序做一些特殊处理了。

第二种思路，是从数据本身下手，把数据“切开”来存，这叫分库分表。

当你的数据量变得超级大,比如一张表里有几亿条数据，这时候即使做了读写分离，单个数据库服务器也可能因为数据太多而变慢，硬盘都快装不下了，怎么办呢？那就把数据和它带来的压力一起分摊掉。

分库分表有两种切法：一种是横着切，一种是竖着切。

横着切（水平分片），就像是按学号分班，我们把用户表切开，用户ID是1到10000的放在数据库A里，10001到20000的放在数据库B里，以此类推，这样，每个数据库只存一部分用户的数据，压力和存储空间自然就小了。

竖着切（垂直分片），就像是把一个人的基本信息（姓名、年龄）和详细档案（履历、成绩单）分开存放在两个不同的文件柜里，我们把用户的核心信息（账号、密码）放在一个数据库，把用户的个人资料、订单记录等放在另一个数据库，这样也可以减轻单个数据库的压力。

分库分表之后,同样需要一个“大脑”来指挥，这个大脑（通常是专门的中间件）要知道一条数据到底存放在哪个具体的数据库里，应用程序不用关心这些，它只管发出请求，由这个“大脑”去正确的数据库里把数据找出来或者存进去。

这种做法能力超强,能应对海量数据和高并发，但代价是变得非常复杂，尤其是以后想跨多个分片做查询、或者数据分布不均匀时，会很麻烦，像阿里的TDDL、ShardingSphere这类工具就是用来管理分库分表的。

第三种思路，是利用一些现成的高级数据库功能。

有些数据库自己就带了一些负载均衡的本事,像PostgreSQL这类数据库，可以配置一个集群，应用程序可以连接到一个统一的入口，数据库集群内部自己会决定把读写请求发到哪个节点上去，这对应用程序来说几乎是无感的，因为它感觉就像在连接一个单一的数据库，这种做法比较省心，但通常依赖于特定数据库的支持能力。

还有一种更“硬核”的思路，是从应用程序内部解决。

也就是在写代码的时候,就直接配置好多个数据库的连接信息，在代码里写死（或者通过配置中心动态获取）主库的地址和多个从库的地址，当需要读数据时，程序自己随机或者用轮询的方式选一个从库去连接；需要写数据时，则固定连接主库。

这种做法非常直接,没有中间件带来的性能损耗，很灵活，但缺点是把负载均衡的逻辑和应用程序紧紧绑在了一起，以后如果想换一种负载均衡策略，或者数据库地址变了，可能需要修改代码并重新发布程序，维护起来比较麻烦。

数据库负载均衡没有一种方法是万能的,读写分离适合大部分普通场景；数据量爆炸式增长时，就得考虑分库分表了；如果用到了合适的数据库，可以试试它自带的集群功能；而对性能和可控性要求极高、不怕麻烦的团队，也可以自己写在代码里，关键是要根据自己的业务特点、数据量和团队技术能力，来选择最合适的那一种或几种组合拳。