读写分离、发现读不到数据 | Mikez Namespace

在读写分离的架构中，“写后立刻读"读不到数据是一个常见问题，原因是写操作是在主库完成的，而读操作是从库进行的，由于主从同步有延迟，从库数据可能未及时同步最新的写入操作，导致读不到刚写入的数据。

以下是几种解决方案：

方案 A: 事务读（强制走主库）

对于一些对实时性要求高的读操作，如查询余额、查询额度等关键业务，可以通过 事务读 的方式强制走主库来确保读到最新的数据。这种方法保证了最新的写入在主库读取时是可见的，避免数据延迟问题。

实现方法：

在应用层控制关键的读操作（例如余额查询），强制直接从主库读取，而非从从库读取。
可以通过标记特定的查询走主库，比如使用数据库连接池中的读写分离策略：
- 主库处理写和实时性要求高的读操作。
- 从库处理普通读操作，减轻主库负载。

示例：

在 Golang 中可以通过代码逻辑来控制读操作是否走主库：

// 当写操作之后立刻需要读取，可以直接连接主库
func readFromMaster() {
    dbMaster, _ := sql.Open("mysql", "master_dsn")
    var result string
    err := dbMaster.QueryRow("SELECT balance FROM accounts WHERE id = ?", accountID).Scan(&result)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println("Balance:", result)
}

方案 B: 数据库的强同步机制（MySQL MGR，Raft 或 Paxos 协议）

使用 强同步机制 可以保证主库写入成功后，从库立即同步完成，确保在读操作时数据是一致的。MySQL MGR（MySQL Group Replication）是一种支持强一致性的同步机制，它依赖 Raft 或 Paxos 一致性协议来确保多个节点的数据一致。

工作原理：

写操作在所有节点（主库和从库）都完成后，才认为事务提交成功。这样，任何节点（包括从库）都能读取到最新的数据。
这种方式保证了读操作的一致性，但会牺牲写性能，因为写操作需要等待多个节点的响应才能完成。

MGR 强同步实现：

在使用 MySQL Group Replication（MGR）时，可以开启强同步模式来确保写入在多个节点都成功后才返回结果。MGR 内部使用 Raft 算法来协调集群中不同节点的数据一致性，避免了数据延迟问题。

缺点：

写入性能下降：因为写操作必须等待多个节点的确认，所以写入延迟可能会增加。
复杂度增加：配置和维护强同步集群的复杂度较高，尤其是对于大规模系统，节点的同步和容错机制会更加复杂。

适用场景：

对数据一致性要求非常高的业务场景，如银行转账、订单支付等需要确保每次读都能获取到最新写入数据的场景。

其他补充方案

方案 C: 延迟检测与重试机制

在一些非关键业务中，可以通过 延迟检测与重试机制 来处理主从同步延迟的问题：

当执行写操作后，应用可以检测到从库的延迟（例如通过 SHOW SLAVE STATUS 检查同步进度）。
如果发现从库数据尚未同步完成，可以采用短时间的重试机制，在确保从库同步后再进行读取操作。

方案 D: 缓存一致性方案

利用缓存（如 Redis）也可以暂时解决“写后立刻读”的问题。写入后，可以将写入结果先缓存一段时间，后续读操作直接从缓存中获取，确保一致性。在缓存失效或过期后，再从数据库读取。

总结：

事务读 适用于要求实时一致性的重要业务，但需要负担主库的读写压力。
强同步机制（MGR） 保证数据一致性，适合强一致性要求的场景，但可能影响写入性能。
其他方法如重试机制、缓存方案可以在特定场景下优化读写分离架构中的一致性问题。