前段时间又和同事讨论到 GS 中的 ACID 一致性，在这里唠叨几句。ACID 一致性即系统内部的数据一致性，而非分布式系统对外体现的一致性(CAP 中的 C)。

假设我们有一个业务逻辑叫做行军，在单线程下，其逻辑如下:

调度的概念这里就不赘述了，调度本质上就是一个资源分配算法，本文谈谈调度的基础策略，常见模型，以及 Go 和 Erlang 的一些调度特性。

调度策略

抢占 vs 协作

从调度机制上来讲，调度可以分为抢占式和协作式。

非抢占方式是指一旦将调度资源(如 CPU)分配给某任务 后，便让该任务一直执行，直到该任务完成或阻塞或主动让出CPU控制权，非抢占调度又称为协作式调度，它实现简单，并且对共享资源的访问也更安全(如允许使用不可重入函数)。非抢占算法常见的如 FIFO，STCF(Short time to complete first)等。

go module 是 go1.11 引入的新概念，为 go 当前饱受诟病的 GOPATH 和依赖管理提供了更好的解决方案。在理解 go module 之前，先回顾下当前 Go 的项目结构和依赖管理都有什么问题:

1.GOPATH

GOPATH一定程度上简化了项目构建，但是给了开发者过多的限制，你的项目必须位于 GOPATH 下，否则编译器找到它，想要使用你自己的项目组织结构，要么你需要为每个项目设置一个 GOPATH，要么使用软链接来实现。大多数 go 新手都会纠结于应该使用一个 GOPATH 还是为每个项目创建一个 GOPATH，还是为所有依赖创建一个 GOPATH，受到一堆限制，却并没有得到便利。

CGroup V1

1. CGroup 概念

• Task: 任务，也就是进程，但这里的进程和我们通常意义上的 OS 进程有些区别，在后面会提到。
• CGroup: 控制组，一个 CGroup 就是一组按照某种标准划分的Tasks。这里的标准就是 Subsystem 配置。换句话说，同一个CGroup 的 Tasks 在一个或多个 Subsystem 上使用同样的配置。
• Hierarchy: 树形结构的 CGroup 层级，每个子 CGroup 节点会继承父 CGroup 节点的子系统配置，每个 Hierarchy 在初始化时会有默认的 CGroup(Root CGroup)。
• Subsystem: 子系统，具体的物理资源配置，比如 CPU 使用率，内存占用，磁盘 IO 速率等。一个 Subsystem 只能附加在一个 Hierarchy 上，一个 Hierarchy 可以附加多个 Subsystem。

什么是一致性？

在谈到一致性这个词时，你会想到CAP理论的 consistency，或者 ACID 中的 consistency，或者 cache 一致性协议的 coherence，还是 Raft/Paxos 中的 consensus？

一致性大概是分布式系统中最容易造成困惑的概念之一，因为它已经被用烂了。在很多中文文献中，都将consistency，coherence，consensus 三个单词统一翻译为”一致性”。因此在谈一致性之前，我认为有必要对这几个概念做一个区分:

访问控制

1. package 内没有任何访问控制
2. package 间的访问控制只由大小写区分

问题1我们可以通过合理拆分 package，来避免代码维护变得越来越困难，为了避免循环依赖，这里有一些实践。

问题2则更难处理一些，因此 Go语言的reflect这类基础设施也受此影响，有时候你为了对象能够序列化或者 DeepCopy，就必须将其字段大写，也就对所有的package都暴露了实现。也就是说，Go 语言的基础设施(如reflect)也受此访问控制的限制(reflect本质上也是个package)。

现状&契机&目标

DevOps 是分工细化下的产物，用于提高开发和运维的协作效率，实现快速交付。这里主要从开发的角度谈谈游戏服务器中的DevOps，以及我们最近做的一些尝试。

1. 现状

我们现在是不同的项目使用不同的语言和框架，上线前，运维了解熟悉各个项目组的配置方案，部署流程，数据管理等，同时开发也需要熟悉运维的检测工具，接入监控报警机制。这通常需要一周甚至更多的时间，并且线上部署和本地部署可能是两套完全不同的流程，由于项目组相关性太强，运维通常也是专职维护指定项目，效率很低。上线后，如果出了BUG 需要紧急修复，通常是开发人员直接ssh到正式环境的主机上，进行日志查看，状态调试，甚至代码修改，对操作人员的要求比较高并且风险大，没有充分发挥运维的作用。

异步思维是后端架构设计的必备思维，尽管同步代码简单直观且易于维护，但为了构建健壮，可靠的后端系统，对于同步的选择是应该慎之又慎的。为了方便讨论同步可能带来的问题，我将同步请求大概分为三类:

1. 不带超时的同步请求
2. 带超时但非关键的同步请求
3. 带超时且关键的同步请求

第一类同步请求的问题很明显，就是请求方无法对对端的响应有一个最坏预期，即有可能对端挂掉了，永远也不响应，那么请求方就永远被阻塞了。很多时候我们在实现同步语义的时候会忽略超时处理，或者说对对端的可用性作出过高的假设。而我们要在语言机制上实现同步语义是很简单的，比如Go的res := <-chanRet，Erlang的receive Answer -> ok，而对于同步调用失败或无响应的情况却没有过多考虑。好在Go的很多网络库都通过context来规范化超时处理。

Callback / Event

Callback 在 JS 中无处不在，Ajax，XMLHttpRequest 等很多前端技术都围绕回调展开，比如创建一个 Button: <button onclick="myFunction()">Click me</button>。回调的优点是简单易于理解和实现，缺点一是调层数过深时，代码会变得非常难维护(所谓回调地狱，Callback Hell)，二是任务和回调之间紧耦合，并且只能指定一个回调函数。

Go的package和goroutine，前者组织Go程序的静态结构，后者形成Go程序的动态结构，这里谈谈对这两者的一些理解和实践。

一. package 管理

1. package 布局

分包的目的是划分系统，将系统划分为一个个更小的模块，更易于理解，测试和维护。如何组织Go项目的包结构，是大多数Go程序员都遇到过的问题，各个开源项目的实践可能也并不相同。以下是几种常见分包方案。

单一Package

适用于小型应用程序，无需考虑循环依赖等问题。但在Go中，同一个Package下的类和变量是没有隐私可言的，C++/Java可以在同一个文件中通过Class实现访问控制，但是Go不可以。因此随着项目代码规模增长(超过10K SLOC，代码维护和隔离将变得非常困难。