@imsoso #82 看问题一定要全面辩证性的看，不要被轻易带节奏，要有自己的思考！
如果你了解问题深入一点，他们现在正在打官司，并未有结果。目前都是一方说辞！

如果说 一个供应商 就把一个租赁公司整垮，那本身来说，这个租赁公司在运营思路就会有很大的问题！
写程序还讲个主备呢！

买 DMI 版本，然后等等，再然后看新版本 充电功率能到多少，如果功率够大 110KM 的 基本 40 分钟左右就行了。主要是 DMI 解决焦虑！多数只有一辆车的家庭，纯电适用范围还是小了点。

我两孩，是唐 DMI 车主，油电两套系统保养，不用担心，BYD 保养很便宜，一年一保 390 块，大保还未经历过，估计也很低。
如果你要求能平躺人，建议选择 SUV ，你这个价格我建议你选择 腾势 D9 DMI 版本。

拥有电，带小孩出去，是你想不到的快乐！！！简直太方便了，而且我平常都是近郊游，来回 100km 内，简直不算油钱。有时小孩想吃东西，不用下馆子，在大山里面，随便搞，还不用考虑防火政策！

我在重庆，而且两个儿子，目前只有一套学区还过得去的两室，或许很多人认为我会买大房子等等。
但是我的策略是争取 45 岁不再坐班，然后回县城。所以我就算换大房子也只能住 5-10 年。
孩子一般初中就要读住校，18 岁就要读大学。所以和你朝夕相处的日子也就 12 岁前。当他们意识觉醒，需要自己的独立空间时，可能就是 10 岁往上了。那时我差不多 40 岁了，我会选择租一套豪宅，5000/月往上，享受几年大房子带来的快感，然后小房子留一个户口，45 岁环游中国，美滋滋！

当然这一切就建立在比较顺利的情况下，话说，如果我不置换改善，不背大额房贷，我的风险抵抗能力是优秀的！

#7 你猜测是对的，官方对 os/exec 包的解释
Unlike the "system" library call from C and other languages, the os/exec package intentionally does not invoke the system shell and does not expand any glob patterns or handle other expansions, pipelines, or redirections typically done by shells. The package behaves more like C's "exec" family of functions.

官方：就是有意不调取系统的 shell 所以你原本的 shell 配置和环境变量都是读取不到的。

大多数虚拟化的东西，多会虚拟一层网卡，这种虚拟网卡就会导致网上一些常规操作无法完全适用。

对于此场景我的处理办法是：让 wsl 和宿主机 win 网络互通（还可以解决很多问题）。然后所有通过 Dockerfile 设置 http_proxy 代理到 win 上，就实现了 wsl 的 VPN 作用。这样做就不用特殊去配置 docker 了

具体如何互通，可以参考 https://zhuanlan.zhihu.com/p/588329608

上面 #3 #5 给了方案，我瞄了一眼 cog：
cog 不得行的原因是 就是 dockerd 代理限制。

cog 做的不好的一点是，他不提供额外的 docker --build-arg 参数让用户配置！

如果提供配置，你就不需要修改 dockerd 了，这样就会更灵活

```go
func Build(dir, dockerfile, imageName string, progressOutput string) error {
var args []string
if util.IsM1Mac(runtime.GOOS, runtime.GOARCH) {
args = m1BuildxBuildArgs()
} else {
args = buildKitBuildArgs()
}
args = append(args,
"--file", "-",
"--build-arg", "BUILDKIT_INLINE_CACHE=1",
"--tag", imageName,
"--progress", progressOutput,
".",
)
cmd := exec.Command("docker", args...)
cmd.Env = append(os.Environ(), "DOCKER_BUILDKIT=1")
cmd.Dir = dir
cmd.Stdout = os.Stderr // redirect stdout to stderr - build output is all messaging
cmd.Stderr = os.Stderr
cmd.Stdin = strings.NewReader(dockerfile)

console.Debug("$ " + strings.Join(cmd.Args, " "))
return cmd.Run()
}
```

瓶颈 Mysql 写入，核心解决思路，控制 Mysql 写入更新量。

如果可以容忍最新进度的丢失的容忍性，和粒度放大问题。最低成本的解决方案：
本地记录最新的时间。拉长上报 最新进度上报时间间隔比如 3 分钟？ TPS 约 600 了。
退出立即记录退出时间。
客户：异常退出再进来利用本地记录恢复。本地没有取远端最新，导致进度可能不准，但是异常退出量少
正常退出再进来，利用远端退出时间记录。准确进度

1.这样改动最少 2 不引入其他额外组件，最低成本
缺点：统计的粒度不够细。

@hopingtop
https://github.com/uber-go/automaxprocs

这库的原理就是取读取 容器里 /sys/fs/cgroup/cpu 里面的值，然后计算出一个合理的 MAXPROCS
在你 main 函数执行之前通过 import 这个过程去初始化 MAXPROCS

针对 Docker 运行 Go 确实有取宿主机的 CPU 来设置 MAXPROCS.
当使用 Pod 限制资源的配置时，就不建议手动去调整 MAXPROCS ， 这样做不好运维，所以可以选择 Uber 的一个库

我也很好奇一个问题，好大的人员规模才适合中台？因为之前一直没接触过。
我在重庆这个互联网荒漠的地方，也听到一些人到处都吹中台中台！
结果一落地，稀烂！

我个人感觉架构更多的是基于自己团队的演进，而不是一开始就各种高大上的名词整起，服务上起。

对于 50 人内的研发团队来说，大概率是徒增开支，加剧内耗。
可能最终就是丰富了，带头人的简历： 执行 XXX 战略，引进 XXX 先进技术。 失败原因就是公司不行！

看官就当看个乐吧。

首先要考虑你场景的一致性容忍度，如果一点就不能容忍，那么你就不应该用 redis 来做。应该选强一致性方案，也就是说的 etcd 或者 zk 。

redis 是做不了强一致性的，包括 多 client 端连接多 master (n/2)+1 这种方案，还有就是 redis wait 命令，都只能是减少锁失效的概率。

如果有容忍性，又是选举场景这种并发不大的情况，只需要找一块共享存储原子操作就行。member 去 loop 尝试加锁，leader 去续约就好。

如果 Leader 后续操作有数据库的话，这样 redis 这个依赖就能不要，减少一个自己不太熟悉的东西，提升稳定性。

不建议用 Pub 消息去通知。订阅可能存在失效等问题，而且这样实现就深度绑定了一些特性，以后不好做迁移。

xorm.io/xorm 我印象中，是没有 空返回 error ，exists, error := .Get(&struct{}) 不存在 exists 是 false

@aaaaaaaaa 因为是自有协议，目前不支持 公共第三方导入。
/api 有协议编码文件，不过没有详细的文档

@BigTaoTao 一般操作是，起一个 nginx 通过 acme.sh 去配置，然后通过 nginx 代理你的 nextcloud 。内部 http 访问应该不影响。没具体看 nextcloud 但是看它上面的 docker 报错，应该内部有 Apache 服务，acme.sh 也支持

看看 Dockerfile 是否有通过 环境变量 配置这个 ServerName

@sbex 嗯，你的问题很好！这里我们可以看到，当前系统，不支持 全文搜索，不支持跳条件查询，这都是考虑到 索引大小和查询速度， 而牺牲更大的灵活性。traceId 这种查询就不说了，他是走的单索引。
我们觉得 靠谱的日志打印，一定不是大海捞针 才找到。 一般来说通过 3 个 查询维度，就能缩小到很小的范围。所以我们只建立了一个联合索引，并且查询条件设置顺序 严格表现为 前缀形式， 比如：填了 等级筛选，才能填入短消息筛选，填入一级条件，才能使用二级条件...

我们举一个应用场景：一个进程每天的写入量在 5000W 日志，那么我们设置 此进程 3 天分一片， 那么此模块下，单集合容量差不多在 1.5 亿的情况。这个时候如果时间范围控制的比较好，查询返回是在 毫秒 级别的。因为缓存问题，相似查询条件，第二次查询会更快。
当然这里就会产生一个限制，就是单次最大查询时间范围只有 3 天，我们不支持自动跨集合查询。因为产生了跨集合查询，可能会导致资源占用不可控。

因为我们自定义了 collection 隔离，所以需要大量 IO 查询的情况下，对其他的进程写入和查询也是不受影响的。

我们知道 Count 是很耗时的，所以在查询的时候我们 优化了查询方式，异步最大 Count 5W 条 | MaxTimeout 3s 。 所这里存在的问题就是，日志条件筛选后还大于 5W 条 Count 就是不准的了。


如果写入量还很大，比如一天达到了 3-5 亿，因为我们的最小粒度是天分片。所以 2c4g 的 mongo 对单表 5 亿的筛选是很有压力的。不过还是特别恭喜你！你可以有更多的钱 去升级更好的系统了。 或者升级此系统的 Mongo 也可以！

@gerorim 嗯，前端这块不是我的强项，是要优化一下，后面空了，我来弄 详细的 error code 来处理，这块的提醒。目前只有验证类型的错误会直接返回给前端，偷了个懒，哈哈。

@gerorim qezap.New(qezap.WithLevel(YourLevel)) 默认 DEBUG 。 在初始化指定一下就行。 指定 info, 就是 info 及以上。其他日志级别同理