@tf2 所以，最后它帮你把数据恢复了吗？

安慰下楼主，建好了不亏的。以后想建还建不了。
老家的居住成本比在城市低很多，自己种点菜喂点鸡，门口想怎么打理就怎么打理，以后养老绝对比在大城市舒服。

现在建了房，以后还能回去。现在不建，老房子塌了如果不修想回去都没法回去了。

对于我们这种游戏业务，只允许单客户端登录的，有很重要的意义。

1. rt 的存在，就是为了减少核心认证数据的传输频率（比如账号密码，手机验证码等）
2. rt 会持久化，at 的校验成本更低，往往会存在内存中直接校验。
3. rt 无法用来登录，只能用来刷新 at ，重点是一个账户只有唯一的一个有效 rt ，每次刷新都需要当前正确的 rt ，刷新后 rt 会变，之前的 rt 就失效了。如果所谓的 rt 被抓包拿了，除非只有你一个人用，否则，用户刷新失败触发账号密码或验证码登录，此时刷新的 rt 会覆盖掉抓包拿的 rt 。也就是游戏中的发现自己被挤下来后，自己用最高优先级的账号密码登录，对方就无法再登录了。

重点：
rt 只能使用一次，这是与账户密码最大的不同点。
rt 只能使用一次，这也是与 at 最大的不同点，成本较 at 高。

总结：
正常用户的使用过程中，几乎很少触发账户密码验证码登录，体验更好。
非正常使用过程中，也能一定程度的保证安全。
减少账户密码的传输频率也能降低其被窃取的风险。

多打打 wa3 ，星际，就好按了。

@dogfeet 我一般还是用 glibc ，但是不用 native-tls(openssl)。虽然很多人说 musl 性能较 musl 差，但其实我并不在乎这个，只是没觉得 glibc 问题有那么严重。毕竟这玩意和内核关系紧密，不像 openssl 。
在加上 zigbuild 能很方便的指定 glibc 的版本，没觉得这个有啥麻烦的地方。所以继续 glibc

@bli22ard 是的，想要不依赖 glibc 就用 musl ，想要不依赖 openssl ，就是用 rustls 。
至于要方便的交叉编译，直接使用 cargo zigbuild 就行。

大致就是这么简单。

对了，刚忘说了，我是直接在 windows 上交叉编译 linux 的。安装下 ziglang 和 zigbuild 就行了。
没觉得比 Golang 麻烦在哪里。

我都是：

不使用 native-tls ，专用 rustls
使用 cargo zigbuild ，还可以指定 glibc 版本，挺无脑的，没你说的那么费劲。

不是，这测的有啥问题吗？

要测 100 万异步并发任务内存占用，可不就是构造个 100 万异步任务同时运行的场景吗？
你可以说知道 100 万异步并发任务内存的占用了的指导意义有限，但你不能说用 `sleep` 去构造这个场景有问题吧。

看的头疼，感觉没那么难理解啊。

还有就是，虚拟线程也是 `stackful` 的，咋就不公平了呢？

怎么没人替 java 喊喊冤啊。

个人不太喜欢裸 sql 的方式，因为喜欢改字段名，再就是参数类型 时间字符串数值要不停的记住。裸 sql 对测试代码的覆盖率的要求更高。

vue 的后台管理系统，可以试试 nuxt ui [https://dashboard-template.nuxt.dev/]，pro 版本中很多 Dashboard 相关的重度组件。

@dogfeet 哦，后面有说到只是纯快照读的前提的话

大家都在说什么啊？是我搞错了吗？ rr 应该妥妥的有幻读的问题啊。

@zzhaolei 谢谢，说的正是这个讨论里的问题

账号：jackma
支持！

@bthulu 看起来就是写不依赖读，或者说写需要的读状态可以是旧数据（只需完整，无需最新）。那么单纯的将 Device 变为不可变就行。ConcurrentDictionary 单纯的读写本身是原子的，查了一下，不可变的线程安全 C# 与 Java 是一致的。

如果更新的时候不看原来的数据，且 [多个监控线程每隔 100 毫秒读取一次所有设备状态, 并根据设备状态执行一次或多次耗时较长的异步操作] 这个过程中数据变化了也没关系的话，可以考虑直接将 Device 变为不可变（所有字段都 readonly)。

C# 不是特别熟了，devices 本身读写是线程安全的，里面的 device 只要每次更新的时候是替换一个新的不可变对象，这在 java 中是线程安全的。

几十个字段的拷贝，应该也还好。

求推荐一些 flutter 开发的较重型的 app 体验下。

接触过的几个链上项目都是这么做的，生态，可控度都不错，主要是用户切换成本低，和 tg 共享生态也即意味着和其他链项目共享用户生态。