背景

之前没有针对 Spanner 的数据层单元测试框架，后端服务在完成编码后 DAO 层单测的数据，基本通过 Mock 的方式，或对测试数据库的读写来实现。这种单测手段存在一些问题：

1. 使用 mock 数据， 在接口和 Service 层代码不变的情况下， 内部的重构需要改写大量的单元测试用例。
2. 使用测试数据库， 随意修改数据导致的单元测试不稳定， 考虑测试完成后手动清理数据的低效问题。
3. 使用 mock 数据， 跟落盘到 Spanner 的区别，无法验证 DAO 层的代码是正确的。

原文地址：Goroutine调度器(二)：调度流程简述

我们都知道Go语言是原生支持语言级并发的，这个并发的最小逻辑单元就是goroutine。goroutine就类似于Go语言提供的一种“用户态线程”，当然这种“用户态线程”是跑在内核级线程之上的。当我们创建了很多的goroutine，并且它们都是跑在同一个内核线程之上的时候，就需要一个调度器来维护这些goroutine，确保所有的goroutine都使用CPU，并且是尽可能公平的使用CPU资源。

背景

在使用 Go 构建 Web 应用程序时，所有传入的 HTTP 请求都会被路由到对应处理逻辑的 Goroutine 中。如果应用程序在处理请求的时候，有读写同一块内存数据， 就存在竞态条件的风险。（ Spanner 支持 读写锁定 的事务模式，单个逻辑时间点以原子方式执行一组读写,不存在竞态条件问题）