@AIdiot #11 做的是哪一年的？ diskvd 和 lockservice 是 15 年的 lab ；

@wqlin #7 补一下，mysql 不能处理 lost update 的问题，所以一个办法是使用 #1 提到的 for update 显式的锁住行； PostgreSQL，Oracle 这些可以检查到 Lost update。楼主可以参考下 Designing Data Intensive Application 的 第七章 transaction

@mayowwwww #3
抱歉看错了，用 this 也可以。
不过为啥楼主你更新不成功，我试了一下，最后 T1 和 T2 都是 377。这应该算是 Lost Update 吧，一个 transaction 覆盖了另一个 transaction 更新的值。
如果要输出 447，我觉得可以用线程互斥+ Read Committed，一个线程先 commit，然后另一个线程再开启一个 transaction，代码见： https://gist.github.com/wqlin/e957e01fcb40986996b71831a4c45404
在我的电脑上输出为：
```
T1:连接数据库...
T2:连接数据库...
T2:Amount=400
T2:更新成功...|500
T1:Amount=500
T1:更新成功...|600
```

RP 保证一个事务读不到另一个事务已经提交的修改。
可以试下 Read Commit，可以读到另一个事务已经提交的修改（没有试过）
另外，楼主的代码应该是：

```
synchronized (MyRunner.class) {
....
}
```
如果用 this，其实两个线程并没有互斥执行

@wqlin #1
TestClosure1 也可以改成：
```
func TestClosure1() {

data := []field{{"one"}, {"two"}, {"three"}}

for i := range data {
go data[i].print()
}

time.Sleep(3 * time.Second)
}
```
实现同样的效果

首先看 TestClosure2 ； 犯了常见错误，可以参考： https://github.com/golang/go/wiki/CommonMistakes#using-goroutines-on-loop-iterator-variables
应该改成：
```
func TestClosure2() {

data := []*field{{"one"}, {"two"}, {"three"}}

for _, v := range data {
go func(v *field){
v.print()
}(v)
}

time.Sleep(3 * time.Second)
}
```
理解了 TestClosure2 之后来看 TestClose1。这里要理解 function receiver ；可以参考： https://tour.golang.org/methods/4。关键是这句话
>
With a value receiver, the Scale method operates on a copy of the original Vertex value. (This is the same behavior as for any other function argument.)
>
所以要实现同样的效果，可以改成：
```
func TestClosure1() {

data := []field{{"one"}, {"two"}, {"three"}}

for _, v := range data {
go func(v field){
v.print()
}(v)
}

time.Sleep(3 * time.Second)
}
```

最后放 playground： https://play.golang.org/p/2C71XfJm2SI

@ghostwind #3 问一波，为啥刷完 6.824 才面，数据库啥的不刷吗。我也在刷 6.824 ，加个 wx 交流下？

主从复制是为了提高可用性（）和性能（读请求可以走从库，主库压力不会太大）。一般有好几种方式，以向数据库写数据为例：
1. 可以只等主库确认，那么就可以认为这次请求成功了；然后后续由主库将数据复制给其他从库（ push 方式，也可以 pull ）
2. 可以等主库将数据复制给全部从库，这样可以保证主从数据始终一致，不过这样性能不太高
3. 可以等主库将数据复制给部分从库，这样是上述两个方案的折中。
我们平时使用 mysql 主从复制的话，一般是第一种，不过 mysql 也支持第三种。那么就可能出现从库数据不一致。如果楼主应用能忍受这样的不一致，那么读从库就无所谓。如果要想读到最新的数据，可以将读请求路由到主库也是一种办法。不过这样主库读写压力会比较大。
不过还可以选择天生分布式数据库，国产 Tidb 这类

第一个

3/2 等于 1 吧。。int 计算的话。实际上就是计算 majority 的数量 = 集群总服务器 /2 + 1。+1 为了处理偶数个服务器

@csuzhangxc #6 想去 PingCAP，想问下有什么要求吗。稍微熟悉分布式一致性协议

有点好奇这种高可用怎么做？分布式复制，一致性协议吗

没怎么看懂...表达下关心

@streamo #4 不记得是不是只有这里涉及了 blank no-op，但是思想是相同的，就是新的 leader 上任后可以自己 propose 一个 command 帮助 commit，SO 的这个问题 https://stackoverflow.com/questions/37210615/raft-term-condition-to-commit-an-entry 有提到：
>
What this means in practice is when a leader is elected, it typically commits a no-op entry to force a commit in its current term. The leader doesn't increase its commitIndex until the no-op entry is stored on a majority of servers.
>
而且找到一个 Raft 实现，详见： https://github.com/yahoo/gondola，专门分出了一个 blank command:
>
Note blank commands (command 3) are written into the log after a leader election. This is due to a Raft requirement that entries are not considered committed unless the last committed entry is of the current term. Applications need to ignore these blank commands.
>

活锁是否重要取决于应用程序，如果能保证 client 会不同的 propose，那么不处理也没事。但是通常情况下都无法保证，所以一般使用 blank command 帮助 commit

@streamo #2 找到了，在 raft thesis 中 6.4 Processing read-only queries more efficiently 中提到了：
>
If the leader has not yet marked an entry from its current term committed, it waits until it
has done so. The Leader Completeness Property guarantees that a leader has all committed
entries, but at the start of its term, it may not know which those are. To find out, it needs to
commit an entry from its term. Raft handles this by having each leader commit a blank no-op
entry into the log at the start of its term. As soon as this no-op entry is committed, the leader ’ s
commit index will be at least as large as any other servers ’ during its term.
>

嗯，如果在 term 2 的时候没有 propose 新的日志，那么 server 2 就不能 commit 101-105 这几条日志，所以就可能出现活锁的问题。Raft 作者在论文提到新的 leader 上任后可以提交一个空的日志，帮助 commit，但是一时没找到在哪里...