From e812962857338a15c52eb801c2854e1ad8d5bf2b Mon Sep 17 00:00:00 2001 From: sfw Date: Tue, 7 Aug 2018 23:01:36 +0800 Subject: [PATCH] ch6-1-fix typos --- ch6-cloud/ch6-01-lock.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch6-cloud/ch6-01-lock.md b/ch6-cloud/ch6-01-lock.md index 95667c9..cfc4f51 100644 --- a/ch6-cloud/ch6-01-lock.md +++ b/ch6-cloud/ch6-01-lock.md @@ -129,7 +129,7 @@ func main() { } ``` -因为我们的逻辑限定每个 goroutine 只要成功执行了 Lock 才会继续执行后续逻辑，因此在 Unlock 时可以保证 Lock struct 中的 channel 一定是空，从而不会阻塞，也不会失败。 +因为我们的逻辑限定每个 goroutine 只有成功执行了 Lock 才会继续执行后续逻辑，因此在 Unlock 时可以保证 Lock struct 中的 channel 一定是空，从而不会阻塞，也不会失败。 在单机系统中，trylock 并不是一个好选择。因为大量的 goroutine 抢锁可能会导致 cpu 无意义的资源浪费。有一个专有名词用来描述这种抢锁的场景：活锁。 @@ -221,7 +221,7 @@ current counter is 2028 unlock success! ``` -通过代码和执行结果可以看到，我们远程调用 setnx 实际上和单机的 trylock 非常相似，如果获取锁失败，那么相关的任务逻辑就不应该继续向后执行。 +通过代码和执行结果可以看到，我们远程调用 setnx 实际上和单机的 trylock 非常相似，如果获取锁失败，那么相关的任务逻辑就不应该继续向前执行。 setnx 很适合在高并发场景下，用来争抢一些“唯一”的资源。比如交易撮合系统中卖家发起订单，而多个买家会对其进行并发争抢。这种场景我们没有办法依赖具体的时间来判断先后，因为不管是用户设备的时间，还是分布式场景下的各台机器的时间，都是没有办法在合并后保证正确的时序的。哪怕是我们同一个机房的集群，不同的机器的系统时间可能也会有细微的差别。