100 的时候你多试几次就挂了，或者加 -race.
sync.Map 只对读多写少的场景有效率提升.
单 map 每次写加锁可能还不如顺序写.
一般优化思路是做 sharding, 比如预先分配 8 个 map, 每次写的时候 i%8 决定写入哪个 map

什么知识都不想学，什么风险都不想冒，就不存在能对抗通胀的手段.
定投看一年收益率完全没意义.
想进股市,基金, 先搞明白债基的投资逻辑.

@IurNusRay 意思是 __init__ .py 里的代码会在包被 import 的时候自动执行, 自己试一下就知道了

在 python2 里文件夹里必须要有 __init__.py 文件在能被当成包 import , python3 里不是必须，只有在包被 import 时候执行的时候才需要

C open 函数的 O_CREAT 也是个 typo, 25 年后, Ken Thompson 在 go 里提交了一个 patch ... https://github.com/golang/go/commit/c90d392ce3d3203e0c32b3f98d1e68c4c2b4c49b

容器这种 share kernel 也能算安全了么...

和 redis 没关系, 取决于你用的什么网络方案,比如 aws 上他们另外开发的 vpc cni plugin, 每个 pod 会被分配一个 vpc 内可路由的内网 ip, 给 redis cluster 设置 headless service 映射到 route53 上, 不在 k8s 内,但在 vpc 内的 pod 就能通过域名解析到正确的 ip.

这种群里多骗子

昨天的上涨中位数是 -0.5%, 今天是 -1.6%, 外强中干行情, 指数很有迷惑性.

你先想想为什么自己在 3500 点的时候想起来入门了.

@abbyu 哈哈，所以只是这回嘛, 逼乎什么德行大家都懂的

知乎这回硬气了一把啊 https://weibo.com/1904769205/JBDNxuHz1?type=comment

公关没到位

你这配得有点奇怪啊, ingress 那边做 https 重定向不就完了.
ssl-redirect 打开, 后端 nginx 那边不要配置 https.

ingress-nginx -> nginx 是 走的 http, 自然就被 nginx 无限重定向回 https 了.

一定要用 https 回源可以设置 nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

微信阅读里看公众号，可以语音阅读, 质量很高

传感器数据, 现在做技术选型可能会考虑时序类数据库了.
把问题限定在传统关系型数据库(不考虑 spanner, tidb 等 NewSQL)
要考虑下面问题:
- 单节点内表 sharding 还是多节点 sharding?
- 你假设的问题里数据是均匀的, 实际业务里不太可能, 所以会有 hash(id)%N 的做法.

每台车一个表实际造作上很可能是行不通的, 问题里每台车几乎是同时在线的, 意味着数据库需要同时维持 1w 张表是 open 状态, mysql 为例, 一张表至少要打开 frm,ibd 两个文件，需要考虑到操作系统 fd 限制, mysql table_open_cache, innodb_open_files 等参数的调优. 要同时开 1w 张表, 这些参数需要调到很高, 还有持续的同时写入, 文件系统可能就先崩了.

@dzdh 武断了一点, nginx + php 不涉及太多 c extention 的确可能成功.
直接 do-release-upgrade 挂一般都是因为依赖, 像 python 这种 18.04 -> 20.04 会从 3.6 升级到 3.8 就有不兼容的地方.
甚至 openssl 的升级都能搞挂一批依赖.
一般都是从新的镜像重新部署测试

100%挂

没用过, 不过一般思路是 gdb attach 上去看看有哪些活跃线程, 看看对应代码大致在做什么.
这么点 CPU 占用率, 很正常啊, 就算没数据插入, 后台线程扫描也是有开销的, 看看有什么对应参数限制线程池大小或扫描平率.