从之前的介绍我们知道gdb支持基于应用层的主从配置以及读写分离,并且所有的特性仅需要通过简单的配置即可实现,gdb内部将会对SQL请求自动地进行主从切换。以下是一个简单的主从配置,包含一主一从:

database:
  default:
  - type: "mysql"
    link: "root:12345678@tcp(192.168.1.1:3306)/test"
    role: "master"
  - type: "mysql"
    link: "root:12345678@tcp(192.168.1.2:3306)/test"
    role: "slave"

在大部分的场景中,我们的写入请求是到Master主节点,而读取请求是到Slave从节点,这样的好处是能够对数据库的请求进行压力分摊,并提高数据库的可用性。但在某些场景中,我们期望读取操作在Master节点上执行,特别是一些对于即时性要求比较高的场景(因为主从节点之间的数据同步是有延迟的)。

开发者可以通过MasterSlave方法自定义决定当前链式操作执行在哪个节点上。

我们来一个简单的示例。我们有一个订单系统,每天的流量比较大,因此数据库在主从同步时往往会存在1-500ms时间的延迟。在业务需求中,创建订单后需要立即展示订单列表页面。可以预料到如果该订单列表页面默认往从节点读取数据的话,很有可能用户在创建订单后在订单列表页面看不到最新创建的订单(因为数据库主从同步延迟)。这个问题,我们可以在订单列表页面设置为往主节点读取数据即可解决。

  1. 在订单创建的时候,没有必要指定操作的节点,因为写入操作默认是在主节点上执行的。为简化示例,我们这里仅展示关键的代码:

    g.Model("order").Data(g.Map{
        "uid"   : 1000,
        "price" : 99.99,
        // ...
    }).Insert()
  2. 在订单列表页面查询时,我们需要使用Master方法指定查询操作是在主节点上进行,以避免读取延迟。

    g.Model("order").Master().Where("uid", 1000).All()

  • No labels

10 Comments

  1. 使用gdb,默认就是主从读写分离的么?

    1. 你如果没有配置slave节点,那么所有读写都是在master节点上执行。

      如果配置了slave,那么读操作自动走slave,写操作走master

      并且在集群配置时,配置中至少应该有一个master节点。

  2. 那在配置了主从的情况下,如果master或者salve挂了,会是什么结果呢?

    1. 那在配置了主从的情况下,如果master挂了则写失败,slave挂了则读失败。

      1. 郭大侠, 如果配置2个master, 是不是就是主主热备?

  3. 没找到怎么配置主从


    1. 我特意在本章节加了一个配置示例,再看看呢。

  4. 数据库的配置,既然有分组形式,为何还要主从模式,请问他们的区别和意义在哪?

  5. 如果配置了多个slave节点,那么读操作的时候到底读的哪个节点呢?会有类似负载均衡的逻辑吗?

  6. 如果配置了多个slave节点,那么读操作的时候到底读的哪个节点呢?会有类似负载均衡的逻辑吗?