@lion250258 看你对 gpu 的要求了，不是很高可以 rx560 ，这是 imac2019 的显卡。更强点的 rx580 ，或者 6600xt 记得也是可以兼容的，网上有人整理 macos 兼容的 amd 卡，可以去了解下，不要用 nvidia 的，新系统不兼容。

rx560 和 rx580 二手市场买到矿卡概率很高，买新的 6600xt 之类的可以减少矿卡风险。当然 rx560 二手也不值几个钱，要是没翻车性价比就很高。

主板最好使用 z390 罗，这个兼容性应该是最好的，我用的是华硕 z390p 。cpu ，主板和电源淘个二手就行了，性价比很高。

@723X 不是按钮问题，评论作为最常用的功能，竟然要点开从侧边显示。还遇到了一个声音 2 个同样声音重叠播放的 bug ，不止一次，google 也拉胯成这样了。


@sdk234 广告确实是越来越丧心病狂了

显卡换成 amd 的，硬盘 sn570 500g ，内存 32g 3200 频率左右，这个配置仿冒为 imac2019 ，用 opencore 引导，体验跟白苹果基本没差别。

我类似的配置 2019 年用到现在，非常省心好用，x86 还能随便用虚拟机。

官方的 books ，谈不上最好用，不过标记都可以通过 icloud 同步到 mac 上，非常方便。有苹果全家桶的话阅读体验很不错。

@qweaszxcdf 很早就搞定啦，有计划写文章彻底介绍网络数据流量和 iptables 的工作工程，不过事情比较多，一直在拖延😂。
有几个点你可以参考一下:
1. openvpn 可能会增加自己的 iptables 规则，只有自己的 ip 段才会做 SNAT ，这个你可以检查你的 nat 表规则
2. 做 DNS 转发时需要启用 loopback 的转发
3. 做 SNAT ，就如同上面朋友所说的，SNAT 可以用 masquerade ，或者直接 snat 到 easyconnect 网卡那个 ip 地址

调试的时候用 tcpdump 看一下 ip 的报文流向可以比较清晰的看到问题所在。

@sujin190 实际上 mysql 数据库的插入性能并不低，只要可以绕过行锁竞争，一台 4 核 8g 的服务器承受 1 秒 6000 条插入游刃有余。加上分表设计，并发下单性能就会非常可观。

@sujin190 我个人的观点是只有在十分严谨的场景才会考虑用锁(比如涉及到金额)，对于下单的场景，使用 redis 之类的设计并发量能提升好几个数量级，这个缺点就是在极端情况下超卖和少卖选择一个。

我大概测试过 redis ，保守 6w 的原子扣减库存(lua)是很轻松的。

@sujin190 不知道你们有没有压测的数据，这种设计在一定的节点下能承载多高的并发下单量？其实我想表达的是，如果大量请求传到了下游，就会出现多个事务竞争行锁的问题，这样系统的吞吐量就会急剧下降。

@sujin190 再请教下你们实际场景有这样用过吗，对性能的影响有没有经过详细的测试验证。

想一下你提到的美团场景，实际上美团商家经常会有一些特价商品，如果是一些热门商家，多个用户都会选择这个特价商品再加上其他商品，如果是这种场景，这个热门商家的锁几乎是被穿透了？大量的请求都获得了锁，是否会把下游的服务击穿？

@BBCCBB 服务在释放锁的时候就能感知到锁不属于自己了

@sujin190

"实现正常的都是对需要操作的资源加锁而不是对服务加锁，这种情况下并不是全局锁，冲突率实际是极低的"
这一点我请教一下，你们实际锁的使用是如何设计来达到你描述的冲突低的。 实际上有很多场景我们操作资源并不是对单一资源的操作，如果对多个资源分别加锁，这就很容易出现死锁。

不管是使用 redis 还是 zookeeper 作为分布式锁，结果必然是把所有并行请求串行化，这必然会带来一个非常严重的性能损失。如果获得锁的线程需要 10ms 完成一个任务，那么 10 个并发请求必然需要 100ms ，所以他说的“zookeeper 的能提供的并发量也有限”我表示怀疑，到底是他系统先到瓶颈，还是 zookeeper 先到瓶颈？

对于一个并行系统执行效率的评估，可以引用 csapp 中的一条公式
Ep = T1 / p*Tp

Ep: 相对效率
T1: 单线程执行时间
p: 线程数
Tp: p 个线程的执行时间

对于他的系统，解决单线程的执行效率才是最重要的，这就意味着不能串行化，要放弃使用锁。所以就需要评估他们业务系统对于锁的依赖有多重，是不是业务重要到必须不能出任何差错。

就拿扣库存这种业务场景，可以通过库存预热到 redis ，通过 redis 原子扣减库存，再通过异步任务把库存回写到数据库，达到数据的最终一致。

还有一点，redis 最致命的问题在于它不是可靠的锁，它依赖了系统时钟，在学术角度看，在某些情况下它是没法判断 2 个 event 之间的 happend-before 关系。 而 zookeeper 内部的实现的逻辑时钟，因此更加安全。

开发机都要 32g 起步吧。苹果就是那么鸡贼，也没办法，上了他的贼船，只盼 intel 争气一点，让 mac 更便宜一些。

这个功能经常间歇性抽风，原因不明。话说我的 iphone13 好像一整年没失效过，以前总老的设备容易失效。

@ZhiyuanLin 这个真的是很危险，如果自己的 id 被泄漏出去，别人可以拿来替换然后截图，达到嫁祸的目的。就算没做过都是有口难辩。

换算到每秒的话一台 2 核 4g 服务器就可以扛下。当然这么复杂的系统架构不可能这么简单，但这并不是值得炫耀的事。为啥不敢换算成每秒呢，还是因为太拉了……

@Jirajine 很专业👍

@Jirajine 复杂度确实也是个原因，vpn 的复杂度比 socks5 高几个量级。主流 vpn 都有非常明显的握手特征，这个非常容易被检测。Wireguard 这类就不太清楚了。