CRVV

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

比如性能比较。当然这公司是搞 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，这个问题就算是解决了。


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