不如做分布式 kv 存储还简单，只需要找一个 raft lib 和 leveldb/rocksdb ，一天就能撸完

直接 grpc 吧，生态好还能用 gateway 转成 json 吐出，又能对内又能对外
ORM 直接 grom 即可，jinzhu 大哥的实力还是很有保障的

服务器一般是 linux ，系统实现的差异肯定有，可以看看 arch 下面的文件里面封装了平台差异

分析的没错：SSI 保证 Serializability 就是排除掉异常情况

我记得在工程实现上是用了一个什么图模型，然后判断是否有环，只有有环就是异常情况，直接取消事务这么来保证 Serializability 的

头发

没有钱去什么字节

#6 + #7 应该是最快的
导出 sql 上传到 oss，起一个机器从 oss 下载 然后导入 mysql

给老东家赞一个

虚拟机有平台还行，物理机肯定不行

pipenv 不适用与生产环境，请使用更轻量级的 virtualenv，起码能没人会删除你代码目录下的文件

只能说领导不动技术

这不是典型的 hbase 场景吗？又便宜又好用写入性能好

node 已经不太行了。。

Folly：facebook c++ 开源工具库

先说结论：要在 main 中感知任务的完成状态可以通过 chan，控制数据流转也是用 chan，如果有超时机制或者每个任务属性之类数据需要用到 context 。

1 ）步骤大约是
main 函数中创建三个用于接受结果的 A B C chan，大小为 A 任务个数，和一个 notify chan 用于完成通知，再来一个通知主程序关闭的 doneChan

起一个 goruntine 去 for notify chan
go func() {
for a := range nChan {
if (ACount == BCount == CCount == 100) {
doneChan <- struct{}
}

}
}


起三个 goruntine 去 for 分别处理 A B C chan，里面写处理逻辑，大约是这样子
go func(nChan chan Notify) {
for a := range AChan {
// dosomething

if ok {
bChan <- weiboEntryID
} else {
nChan <- weiboEntryID
}
}
close(bChan)
}(nChan)

go func(chan Notify) {
for b := range BChan {
// dosomething

if ok {
cChan <- commentID
} else {
nChan <- commentID
}
}
close(cChan)
}(nChan)

go func(chan Notify) {
for c := range CChan {
// dosomething

if ok {
cChan <- commentUserID
} else {
nChan <- commentUserID
}
}
}(nChan)

这时候就 main 中可以往 AChan 里写数据了，写完直接 close AChan，然后直接用 doneChan 阻塞

for userID := range userIDs {
AChan <- userID
}
close(aChan)
<-doneChan


大致流程就是这样，需要注意的是需要正确关闭 ABC chan，就是在发送完成后关闭，nChan 用于任务信息回收还可以用于任务回放，另外为了保证每个任务都会返回，需要弄一个 timeout context 超时当作失败处理

2 ）第二种情况，由于任务个数是未知的，上面的 100 就不能用了，有两种方式可以解决，一是可以预先知道每次数量，用另外的一个 chan 再任务开始时候传给发送 doneChan 那个 goruntine，把 100 改成最后总数即可。二是未知任务数量，这时候只能再来一个 chan，在做完 ABC 后发送一个 aDone 、bDone 、cDone，给发送 doneChan 那个 goruntine，当确认三个都完成后，就可以发送 done 了。

------

code 硬敲的可能很多不对，变量和具体结构可酌情改变 :-)