就算不用 ipv6 负载均衡实例和地址转换服务也是可以解决的，毕竟能省一点是一点
既然是 ecs，大部分 ecs 实例天然支持 ipv6 的，然后直接用 ecs 的 ipv6 地址做 AAAA 解析就好。如果不想暴露 ipv6 地址在审核通过后取消掉 AAAA 解析就好（谨慎使用）。
现代 web 框架的网络层应该是都支持双栈 tcp 协议的，所以理论上解析做完了以后没有代码要改，还是很方便的。

对于 Select 来说是这样的，你还是需要一个 while 循环来保证及时更新 socket 的就绪列表
要补充的一点是，这里拿 read 和 select 作比较不是很好，应该拿 poll 来做比较，因为 select 并不仅仅可以轮询 read 状态，和 poll 一样，是可以查询 read, write 和 error 的

对于 Epoll 来说也是一样的，通过调用循环阻塞的调用 epoll_wait 来获取最新的事件状态。

@mmqc Mac OS 11.4 (20F71)

不至于，手头有一个根据配置文件生成的 cs 文件，2993 行，移动顺滑

JetBrains Rider 2021.1.4
Build #RD-211.7628.50, built on July 13, 2021

不想折腾的话可以用 Turbo Boost Switcher 简单关闭睿频，但是单核性能也会因此被限制
实际控制功耗的话可以用 Volta, 但是 Volta 一是收费，二是他需要部分关闭 SIP，因为他加载的 kext 文件显然苹果不可能给他签名
实在想折腾的话之前 github 找到过一个项目可以参考下 https://github.com/sicreative/VoltageShift

补充一下，实验不是很严谨，看一下大致比例即可
上文所说的功耗一般指 CPU Package Core 功耗, CPU Computing Highside 的功耗通常会更高

实践下来外接 4k 能清净的方法就是限制 CPU 功耗，
实测下来不启用 dGPU 的情况下，限制在 55w-60w 没有任何压力，单烤甚至风扇不用满速
接了外接显示器后，手动把功耗限制在 35w 左右，感觉还行

附上一份前几天无聊做的 CPU 功耗和 Cinbench R23 跑分的对照表，i9-9880H
15w - 3597
20w - 4554
25w - 5448
30w - 6106
35w - 6757
40w - 7253
45w - 7702
50w - 8065
55w - 8285
62w - 8905

楼上已经说得很好，可以用 pre commit hook 来做格式化的琐碎事情，或者 jetbrains 系的 ide 都可以设置在 commit 之前做 code cleanup

建议专门找个时间按照统一标准把整个 repo 都按照统一的标准格式化了，以绝后患

保研。
实习并不等于入职，
工作并不一定快乐，
只有学历是硬通货。

个人愚见，
想要理解这些问题，需要把这些概念拆开了去理解
首先是最下面的 IO，IO 可以按阻塞，非阻塞区分，也可以按同步，异步区分，组合起来就有 4 种情况，比较常见的有同步阻塞和同步非阻塞。这个网上有很多博客讲的很好，我就不在这里献丑了
理解了 IO 之后，接着就可以看 IO 多路复用，常见的有 select，epoll，
IO 多路复用里，无论何种实现都会有一种方式通知“你”我这边有数据，你可以开始处理了，或者说这些 socket 里有可读的数据，你可以去调用他们的 read 函数了，我们将这种通知统一抽象为事件，也就是 event
所谓事件驱动，event driven，本质上就是寻找一种方式不断的去聆听到来的事件，并对到来的事件进行处理的一种编程范式。
以 Node 的事件循环 event loop 为例子，其实可以简化为以下代码，通过主线程跑一个死循环 while，不断的去拿到当前可以处理的事件，在主线程处理它，然后循环

```
while(events = wait_for_events()){
process_events(events)
}
```
此处的事件可以有很多种
1. 最常见的 IO 多路复用器告诉你哪些 socket 可以读了，主线程去读这些 socket，此时的 read 并不会阻塞主线程
2. 还可以比如说 settimeout 的定时器到时间了，主线程就会把闭包里的东西执行一下

以上可以引申出来大部分的时候我们可以认为所有跑在 nodejs 主线程的程序不需要考虑多线程问题，因为真正的脏活累活都交给了内核或者背后的 IO 线程池去做了。这样做的好处是我们极大可能的避免了线程切换带来的开销，坏处就是一个 foreach(1e100)这样的耗时任务就可以把整个主线程堵塞。

---
我不知道什么叫收银员非阻塞，但是顾客极多导致主线程来不及处理到来的事件的时候，就需要部署多个主线程，这也是 pm2 多 instance 部署能带来性能提升的原因。

---
没看过 HAProxy 和 Nginx 的具体实现，所以不确定以上的对 Node 的观点是否可以迁移到这两个上。

个人愚见，
按照你对 C/S 端架构的理解，可以理解为每次在浏览器上打开网页都是一种动态加载客户端的行为。只不过客户端的载体（ HTML，CSS，JS 之流）并不会持久化在浏览器端。

感觉可以再深入一下，根据我的理解这两个语句应该是等价的。

能否提供一个最小的出现 bug 的情形呢？

不好意思，不知道为啥没有出现 readme 排版，难道是我使用姿势错了，
代码缩进都不见了，凑合着看看吧，这个问题只要重新 create 方法一般都能解决

根据官方文档对于 nested serialization 的描述，详见 https://www.django-rest-framework.org/api-guide/serializers/#writing-create-methods-for-nested-representations

“If you're supporting writable nested representations you'll need to write .create() or .update() methods that handle saving multiple objects.”

所以光有 depth=1 是不够的，需要重写对应的`create`方法

正好有空，给你个最低限度能用的代码

```python

# models.py
class Author(models.Model):
name = models.CharField(max_length=128)

def __str__(self):
return self.name


class Book(models.Model):
name = models.CharField(max_length=128)
author = models.ForeignKey(to=Author, related_name='books', on_delete=models.CASCADE)

def __str__(self):
return self.name

# serializers.py

class AuthorSerializer(serializers.ModelSerializer):
class Meta:
model = Author
fields = '__all__'


class BookSerializer(serializers.ModelSerializer):
author = AuthorSerializer()

class Meta:
model = Book
fields = '__all__'

def create(self, validated_data):
author_data = validated_data.pop('author')
author = Author.objects.get(name=author_data['name'])
return Book.objects.create(author=author, **validated_data)

# viewset.py

class BookViewSet(ModelViewSet):
queryset = Book.objects.all()
serializer_class = BookSerializer
pagination_class = None
http_method_names = ['get', 'post']

```

```
# 示例代码 curl
curl --location --request POST '{root_url}/books/' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "Book 2",
"author": {
"name": "YYH"
}
}'
```

需要注意的是即使 author 里面传递了 ID，这个 ID 也不会出现在 validated_data 中，这个算是 drf 的一个局限性。

环境：
djangorestframework==3.12.2
Django==3.1.3

就职于游戏公司，简单的谈一点自己看法

主程的技术实力非常强，后期大规模场景的优化在业界也是做得非常好的。
除了技术硬实力，美工的水平也完全能 Hold 住这样的游戏风格。

就难度而言，
第零个难点在于知道要做什么，主创的技术实力是否能 HOLD 住场景
第一个难点在于技术团队的组成，你要能凑齐这样一个牛逼主程加上合适的美术相关人员，这其实没想象的那么简单。
第二个难点在于长期开发中的项目管理和规划，看过一点访谈，似乎主创从一开始对项目的把握就十分明确
第三个难点在于团队士气，能耐得住寂寞开发一款题材偏小众的游戏
第四个难点在于美术，包括如何把握美术风格，美术团队和技术团队的协调，如何把合适的工程量外包，如果保证外包成品的素质
最后就是团队的代码实力是否能撑得起复杂的项目了，开发流程，测试流程是否能 HOLD 住一款商业级的项目了。

大概率是电池鼓包，保修期内应该会免费换。
可以顺便看看底部是不是水平的。

可以看一下直接 ping 机器的延迟是多少，或者 tcp ping 一下了解一下平均 RTT 是多少，开启 HTTPS 加密带来的性能损失和网络延迟相比可以先忽略

HTTP 理想情况下只需要一次 RTT 的时间就可以发送数据，
HTTPS 理想情况下则多得多，TLS1.2 需要 4 个 RTT 时间，TLS1.3 需要 3 个 RTT 时间。

所以如果本身延迟就很高，那么开启 HTTPS 带来的延迟增长的确也会很高。

是否开启 HTTP2 对解决这个问题没啥帮助，但是对于网站的基准性能会有比较大的提升。
ssl_prefer_server_ciphers 这个选项只是推荐客户端选定你指定的 cipher，毕竟某些 cipher 过时，慢，并且有可能不安全
如果你的证书的 OCSP 服务器没有被墙，那么是否开启 ssl_stapling 对这个问题没有帮助。

我才疏学浅，唯一能建议的是开启 ssl session 重用，SSL-Session-Cache，这个能帮你节省 1 个 RTT 的时间。

即使 JAVA 中闭包想要用到类似题干中的 data 变量也是需要把 data 变量预先标记为 final 的吧。

这个更多感觉是语言设计上的取舍，对于较为基本数据类型，闭包中到底捕获的是值还是引用。JAVA 就强迫让你写出不会犯错的代码，但同时要达成类似的事情（妄图在闭包中修改捕获的变量的值）就需要用引用类型包装一下这个变量。