> 所以 event-driven 、nonblocking I/O 只是实现了收银员的非阻塞而已吗？
对的。
直接看这个名词，non-blocking I/O，是说 I/O 的，假设你在挖矿，出一个块需要 1 个小时，I/O 的时间可以忽略，要怎么做 I/O 根本就是无关紧要的事情。
I/O 只是收钱和送餐这种事情，后面的计算任务相当于厨师。

> 想要更快地为顾客提供咖啡，最后还是需要请很多很多的厨师？
对的。
但是在计算机里面，不存在“请很多厨师”这个操作。因为 CPU 是通用的，相当于你一共有 100 个员工，安排更多人去收银的话，厨师就少了，所以提高了收银的效率，做饭也会更快。
假设你在挖矿，当然是分配 99.99 个人去做饭，做好了让那 0.01 个人去送餐就行。

> 那么对于 HAProxy 或 Nginx 来说，它们的处理方式也是类似这样吗？
对，也是这样。
这个东西是个代理，它不做计算任务，它的主业就是 I/O 。
相当于外卖平台，它的工作仅限于收钱和送餐。
只要考虑用最少的资源送好餐就行，请多少厨师和它没关系。

原因之一是关系型数据库本身更可靠或者性能更好。

比如性能比较。当然这公司是搞 PostgreSQL 的，结果可能有偏差。
https://www.enterprisedb.com/blog/comparison-mongodb-vs-postgresql

PostgreSQL 更可靠应该没什么悬念。

1. 认不清各种蔬菜

去超市买，都写着的

2. 摘菜不知道怎么摘

有些明显看着不好的当然直接扔掉。
其它的你可以直接都留下来，如果是本来应该扔掉的东西应该可以尝出来（可能会咬不动，比如用手掰不断的蒜苔通常也咬不动）。

3. 洗菜各种乱洗，洗干净没有自己也不清楚

饭店几乎不洗的，你随便洗洗把虫冲掉，已经比饭店干净了（包括不少大饭店）。
另外洗碗机也可以用来洗菜。

4. 切食材勉勉强强，切的有长有短有粗有细，不至于影响口感所以无所谓

这个无所谓，天天做饭，做个几年就能切好了。

5. 试过煎鸡蛋，煎肉排，不清楚加多少油，不清楚要开多大火，不清楚何时能翻面，不清楚肉熟没熟能不能起锅了。

蛋和肉排本来就有不同的熟度，生一点熟一点都没错，合自己口味就行，如果不合下次就延长 /缩短时间。
肉只要不带血色就可以算是熟的，但也有人觉得这样太生要炒老一点。比如白切鸡应该是骨头里带血的，但很多人吃到白切鸡说这玩意不熟。我要表达的意思是，如果你已经把肉炒焦了一次，那下次可以时间稍微短一点，估计就不会焦了。至于到底炒到什么程度算刚好，只有你自己知道。

至于要加多少油，如果用不粘锅就可以少一点，如果是普通的铁锅就需要的多一点。只要不把东西粘到锅上就算可以吧，但这个也看技术的，用普通的铁锅，放很少的油，在恰好的温度放料，也可以做到不粘，如果做不到就稍微多放一点油。如果你想做那种一碗菜半碗油风格的，油直接使劲放就好了。

lock-free 的算法需要用到 cas，但不是说用到了 cas 就是 lock-free
比如用 cas 来实现 counter 就是 lock-free，但用 cas 实现的自旋锁就不是 lock-free

具体的定义在 wiki 里面有写 https://en.wikipedia.org/wiki/Non-blocking_algorithm
A non-blocking algorithm is lock-free if there is guaranteed system-wide progress, and wait-free if there is also guaranteed per-thread progress.

比如一共有 10 个线程，有一个线程在拿着锁的情况下被停了下来，其它的线程也拿不到这个锁，整个系统就停了。
避免这种情况出现的算法叫 lock-free

1. 发 HTTP 请求不需要用多进程
2. 如果在乎性能，请用 requests.session
3. 如果单线程顺序发请求不够快，可以用 ThreadPoolExecutor 或者 aiohttp

重点不是把密码写在哪里，即使是写在代码里面，只要代码不泄漏就是安全的。
当然有代码权限的人通常很多，所以不泄漏代码通常会困难一些。
如果你的代码的价值比数据的价值更高，那你直接写在代码里就好了，没必要折腾别的。

重点是要怎么保证密码不被别人拿到。
比如用加密的配置文件，那么重点是你要把密钥放在哪里，如果密钥和配置文件在一起，加密就是没用的。
如果你有一个安全的地方存密钥，当然也可以直接用这个安全的地方存配置文件，那么加密就是没必要的。

AWS GCP 都有 secret manager 来做这件事情。
当然如果你真的想要保证安全，只是上一个现成的服务当然解决不了问题。比如很多人喜欢在程序启动的时候把配置记在日志里，比如很多开发人员都有登录到服务器上的权限，这些地方都能拿到密码。

如果你用的是符合 SQL 标准的数据库，比如 PostgreSQL，只要字符串里没有单引号，就不会有 SQL 注入。

如果你要用 MySQL，那请认真阅读 https://dev.mysql.com/doc/refman/8.0/en/string-literals.html
注意 MySQL 的文档里面还有一句是
In certain client environments, it may also be necessary to escape NUL or Control+Z.
escape 的结果还取决于 client environment 的。

如果有自信把这些奇怪的 escape 规则都搞对，那当然就可以 “不管怎么拼接 SQL 语句都没法注入了”
如果没有这个自信，就别这么玩了。

@ryd994

ZooKeeper 和 etcd 的设计模型是说它自己的若干台机器之间要怎么通讯，但这里说的“分布式锁”是说 client 和 etcd/ZooKeeper/Redis 之间要怎么通讯，这是两码事。

这个事情早就有人讨论得很清楚了，给 “觉得中文技术社区真是垃圾堆” 的楼主贴一篇
http://zhangtielei.com/posts/blog-redlock-reasoning.html
http://zhangtielei.com/posts/blog-redlock-reasoning-part2.html


其中对 Martin Kleppmann 的观点有实质性反驳作用的其实是
ZooKeeper 也一样存在 Martin Kleppmann 说的问题

这个 Martin Kleppmann 在文章里大力推荐 ZooKeeper，还给了个链接
https://curator.apache.org/curator-recipes/index.html

然后随便点一个 Lock 进去看，都有这么一段
Error Handling
It is strongly recommended that you add a ConnectionStateListener and watch for SUSPENDED and LOST state changes. If a SUSPENDED state is reported you cannot be certain that you still hold the lock unless you subsequently receive a RECONNECTED state. If a LOST state is reported it is certain that you no longer hold the lock.

说在拿到锁的情况下，如果 ConnectionState 变成了 LOST，you no longer hold the lock.
也就是在没有释放的情况下，另一个 client 会再次拿到这个锁。
这完全没有解决 Martin Kleppmann 提出的问题吧。

大约翻译且概括一下这两篇文章

首先是 https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
提出了两个具体的问题，都和超时有关系


1. Protecting a resource with a lock 和 Making the lock safe with fencing 这两段
因为这个锁有超时的设定，所以有可能 A 拿到了锁，然后 A 卡住了，然后超时，然后 B 也拿到了锁，这样锁就崩了。
然后提供了一个解法，说 A 拿到锁之后再拿一个 token （ 33 ），B 拿到锁的时候也拿一个 token （ 34 ），这个 token 是递增的。然后 B 用 34 来 commit，然后 A 用 33 commit，这样系统可以拒绝 A 的 commit
但是他又说他不知道具体怎么实现这个解法。

2. Using time to solve consensus 和 Breaking Redlock with bad timings 这两段
因为 Redis 用 gettimeofday 来计算超时，所以如果有人（或者程序）修改了系统时间，这个超时就错了，后面当然锁也崩了。


然后是 Redis 作者的回复，http://antirez.com/news/101

对第一个问题，提出了 2 个反驳
1. 上面的解法（ Making the lock safe with fencing ）不可行，因为这个解法需要能够把 A 的操作 revert 掉（依赖于 transactional memory ）。如果你都已经有 transactional memory 了，那锁就不重要了。
2. 解法不可行，因为这个解法依赖 linearizable store 。也就是说如果 A 先拿 33 来 commit 然后 B 再用 34 来 commit，系统不会出现 lost updates 。但常见情况是 A 的操作会被 B 覆盖（没有 linearizable store 的情况）。

对第 2 个问题，Redis 作者说
However I think Martin is right that Redis and Redlock implementations should switch to the monotonic time API provided by most operating systems in order to make the above issues less of a problem. This was proposed several times in the past, adds a bit of complexity inside Redis, but is a good idea: I’ll implement this in the next weeks.
作者说他会改用 monotonic time，这个问题就算是解决了。


所以核心就是第一个问题，他俩互相说对方的方案不可行，其实都没有给出能让对方认可的方案。
我觉得吧，如果存在一个能解决这所有问题的算法，应该有人直接给出那个算法，“你这个算法不行” 太没有建设性了。

@nagatoism


> 感觉你没有细看 martin 的文章。Martin 的意思是，Redis 目前的实现里缺乏实现正确分布式锁的基础设施，是救不回来的。你什么地方看出 marin 有解法的？

https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html#making-the-lock-safe-with-fencing

> The fix for this problem is actually pretty simple: you need to include a fencing token with every write request to the storage service.

这种事情当然可以发邮件过去要，即使是他自己写的，发个邮件要一下也很正常。
但对方没有义务提供。

因为 GPL 只管 distribution，也就是发行软件（拿去卖，放在网站上提供下载之类的）。
他只是算了个结果，这事不归 GPL 管。
The GPL series are all copyleft licenses, which means that any derivative work must be distributed under the same or equivalent license terms.

@linhongye
我不用 Xcode，不了解。但是
1. 打开文件数量是操作系统上的一个限制，和内存没关系。https://www.manpagez.com/man/1/ulimit/ 里面的 The maximum number of open file descriptors
2. 如果不是因为 oom 崩的，那就不是内存容量的问题，锅当然属于那个崩掉的东西。我从来没在开着 swap 的 macOS 上见过 oom
3. 同 2，显然和内存容量没关系

在 swap 够用的情况下，内存不够的唯一现象应该就是变慢，但某些情况下会变得非常慢。

“Xcode 经常反应不正常”
内存不够只会变慢，不会反应不正常。如果你说的“不正常”指其它现象，这应该是 Xcode 的锅。

随便搜了一下

https://www.postgresql.org/message-id/4C1A6339.9080300%402ndquadrant.com

> every experiment I've ever seen that tries to add more direct I/O to the database has failed to improve anything

这个帖子比较老了，但 2020 年还有人对比测试了 Oracle 和 PostgreSQL

https://fritshoogland.wordpress.com/2020/01/25/oracle-and-postgres-disk-io-performance/

结论是 PostgreSQL 不用 Direct I/O 但某些情况下还比 Oracle 快。


如果再搜一下 Linux Direct I/O，会找到很多人说这玩意不好用，包括 Linus Torvalds 。

这么看一圈下来，不用 Direct I/O 是个很正常的决策了；当然如楼主所说，用 Direct I/O 也有优点用它当然也是合适的。

@santheniko
我这里用 google 搜索 wlb，出来的是招商永隆银行。
CMB Wing Lung Bank

第一页的 10 条里只有 3 条是指 work-life balance

@cnt2ex

查了一下，来源应该是 https://www.cvedetails.com/top-50-products.php?year=2019


1. Debian 有 360 个漏洞，前 20 个里面，只有 9 和 13 是 Debian 的锅，其它都是软件包的漏洞。
Debian 有五万多软件包，每个用户都只会装其中的很小一部分，对于每一个 Debian 用户来说，只会被这里面很少的漏洞影响到。

这里面 Windows 的漏洞都是微软的锅。其中大部分应该属于 Windows 默认安装的组件。

2. 如果用 Debian 的归类方式，Acrobat Reader 那 342 个应该算进 Windows 和 Mac OS X 。

3. 这个漏洞数量有重复的，比如 Acrobat 虽然占了两行，但都是那 342 个。
对 Windows 也是一样，所以不能把数字加进来得到 Windows 的总漏洞数，但大约估算一下我觉得 Windows 的总漏洞会比 Linux 多。


结论是，从这个数据来说，好像是 Linux 的安全性更好一些。

需求不是这么提的，不能用 “尽最大可能” 这几个字。如果要用 “尽最大可能”，那你就需要明确项目预算或者类似的限制。
尽最大可能提高速度，那当然是直接把 Internet 停了，全给你一个人用，同时把光纤铺满地球，地表满了就打洞过去，如果嫌光在介质里的速度不够快还可以再开发个不用光纤的传输方式，这样才叫尽最大可能。

另外，所谓速度其实是两件事情，高吞吐量高和低延迟。DDOS 那样应该是高吞吐量但延迟无所谓。但楼主又说“慢一毫秒都无法接受”，这和 DDOS 完全是两码事了。

@abersheeran

> 论运营能力，youyuxi 比整个 V2EX 社区所有人加起来都强，不服的可以拎自己的项目出来看看影响力和知名度有没有 Vue 高。

自己的项目当然拎不出来。
但我觉得 Shadowsocks 的影响力和知名度远比 Vue 高