provider 接口和 client 接口共同组成了一套对外的接口，没觉得有啥问题。

家庭微型数据中心 https://i.imgur.com/agAJ0Rd.png

完全没必要。个人的观点是 c 风格的 api 直接用就行了，大不了封装一些功能类的时候写成 c++。如果只是把 c 的 api 转成 c++，没有任何增加的新内容，完全是给自己找麻烦了。c++的很多语法看着很爽，其实都是有固定场景的，场景不对就各种用着不爽，一直不喜欢这些花里胡哨的东西。

omv ，其实感觉主要是机械盘在耗电，cpu 的能耗倒是小事。

No GIL 应该主要还是针对 AI 的场景，Web 那块感觉没什么动力去改。毕竟 No GIL 其实主要就是提高计算性能，Web 那块又不需要海量计算，可能瓶颈在 IO 更多一点。

大概是有代沟吧，其实聊不到一块去

错误的事情，一般伴随着潜在的风险以及各种间接的影响。只盯着诱惑本身，会更容易陷进去。如果用更长远更广的视角稍微看一看，也许会觉得诱惑不过如此。

其实有时候提问者也不一定能抓住重点，就跟上面的 x-y 问题一样。所以大家就 模糊问，模糊答 了。

比如：

有人为了解决 x 问题，问 y 问题。然后一堆人回答怎么解决 y 问题。这个时候有人猜 y 问题是为了解决 x 问题，然后就说了怎么解决 x 问题。

提问者照着后者的解答解决了 x 问题。于是，提问者觉得后者好厉害，前面回答 y 问题的人都好菜。

hahaha...

对了，还有就是用性能更好的盘，或者用非易失内存或者保电内存之类的。反正硬件的极限就是系统的极限。

大嘴巴水一水，不用太当真：既然要在数据完备性要求这么高的情况下提升性能。那就考虑下怎么提升性能。
1. 一台机器慢就多整点节点，做好负载划分。
2. 性能也分吞吐和延迟，如果要求高吞吐，可以增大持久化的粒度。当然这样延迟会更高。如果是要求低延迟，那粒度只能维持在一个正常水平就行了，也不用太小。
3. 剩下就是软件栈上的各种优化了，简化软件栈的关键路径，略微提升性能。。。

u 盘 cv 最简单直接，在不清楚公司网络状况以及相关规定的时候，最靠谱。
其实没必要纠结，这么做的人可以是大佬，也可以是菜鸟。

楼主放宽心，就当交学费了。这玩意学校不会教，家里也没人教，全靠自己攒经验，被拿捏太正常了。

婚礼钻戒可以买个塑料的，反正就是道具用一下。

一般来说，越是难定位的问题，原因越是简单的离谱。
这里就在认为上面都是完全对的情况下，给点个人思路：
客户端连接都断开了，服务端这边有断开吗？
服务端连接断开和连接接收数据的时候可以加日志打印。可能是连接断开但是连接里的数据没有接收干净，或者看下服务端连接关联的对象什么时候销毁。
主要思路就是通过定界不断缩小范围。

相比误拨，我更关注怎么解决骚扰电话。电话号码这种场景，校验位收益不大，可有可无。

个人习惯：lib 单独出现读赖不，libxxx.so 读里布

@rainbowhu r * m 直接换成固定值 最早的 m * 0.3 吧

这样的吗？

对于总量 m 和个数 n ，以及最大比例 r, 每次确定随机范围[x, y]

x >= 1
m - x <= (n - 1) * r * m 也即 x >= m - (n - 1) * r * m

-> x = max(1, m - (n - 1) * r * m)

y <= r * m
m - y >= (n - 1) * 1 也即 y <= m - (n - 1) * 1

-> y = min(r * m, m - (n - 1) * 1)