btrfs 的 online dedup 从来都没有合并过，换句话说就没这个功能。
压缩率是由算法决定的，和文件系统没关系。你测出来没压缩率那显然是没配置对。

btrfs 可以把文件系统建好了再加硬盘上去，更改 raid 之类的，这些操作都不影响正常使用文件系统。zfs 不支持这个。
这是我用 btrfs 的最主要原因。

@cctrv

1. 进程不是进城

2. 进程和线程有什么区别，这的确不是一个好问题。
这个问题差在这两个东西不应该拿来并列比较，比如你可以问牛奶和豆浆有什么差别，但进程和线程不属于这种可并列的关系。
就好像问整列的火车和单个的车厢有什么区别，这个问题本身就很奇怪。但是，如果一个人答不上来这个问题，估计他从来没见过火车。
回到线程的问题上，如果答不上线程和进程的区别，我会觉得这个人不应该拿计算机专业的本科毕业证，因为他完全没学过操作系统这门课。

我没用过 Oracle，但对 PostgreSQL 还算比较熟悉

只要分别读一下 MySQL 和 PostgreSQL 的文档就能看到很大的差别了。
比如 TEXT JSON DATETIME 这些类型的定义和功能。
PostgreSQL 还带一大堆好像没人在用的高端功能。

在性能上，如果会手写稍微复杂一点的 SQL，随便玩一下就能看出来差别了，PostgreSQL 可能会快非常多。比如嵌套几层的子查询，比如多个表的 JOIN，比如有多个索引和多个筛选条件。
如果只在最普通的索引上写最简单的查询，SELECT * FROM table1 JOIN table 2 ON table1.id = table2.table1_id WHERE table1.id = x 这种的，传说 MySQL 比较快。

传说在这些方面 Oracle 都比 PostgreSQL 更厉害一些。

> 所以 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