半芽湾

WaitGroup，我们以前都多多少少学习过，或者是使用过。其实，WaitGroup 很简单，就是package sync用来做任务编排的一个并发原语。它要解决的就是并发-等待的问题: 现在有个gor

我们使用 Mutex来保证读写共享资源的安全性。不管是读还是写，我们都通过 Mutex 来保证只有一个 goroutine 访问共享资源，这在某些情况下有点“浪费”。比如说，在写少读多的情况下，即使一

使用 Mutex 常见的错误场景有 4 类，分别是Lock/Unlock 不是成对出现Copy 已使用的 Mutex、重入和死锁。 Lock/Unlock 不是成对出现 Lock/Unlock 没有成

把 Mutex 的架构演进分成了四个阶段。 “初版”的Mutex 使用一个 flag 来表示锁是否被持有，实现比较简单;后来照顾到新来的goroutine，所以会让新的 goroutine 也尽可能地

在使用golang开发中，常常碰到一些并发问题，比如多个 goroutine 并发更新同一个资源，像计数器更新，如果没有互斥控制，就会出现一些异常情况，比如计数器的计数不准确。 这些问题怎么解决呢?

Deployment、StatefulSet，以及 DaemonSet 这三种编排，主要编排的对象，都是“在线业务”，即：Long Running Task（长作业）。比如，我在前面举例时常用的 Ng

如何对 StatefulSet 进行“滚动更新”（rolling update）？ 你只要修改 StatefulSet 的 Pod 模板，就会自动触发“滚动更新”: kubectl patch sta

StatefulSet 对存储状态的管理机制。这个机制，主要使用的是一个叫作 Persistent Volume Claim 的功能。

Deployment认为，一个应用的所有 Pod，是完全一样的。所以，它们互相之间没有顺序，也无所谓运行在哪台宿主机上。需要的时候，Deployment 就可以通过 Pod 模板创建新的 Pod；不需