如果你用的是符合 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 高

var counter int64

然后如果有多个线程执行下面这个循环，每次 break 都会给 counter 加一
for {
counter0 := atomic.LoadInt64(&counter)
if atomic.CompareAndSwap(&counter, counter0, counter+1) {
break
}
}

这种就是所谓的 lock-free，把它写成用 lock 的形式，再把那几个 if 去掉，这个函数其实就是

func (t *limiter) Take() time.Time {

mutex.Lock()

oldState := t.state
newState = state{}
now := t.clock.Now()
newState.last = now
newState.sleepFor += t.perRequest - now.Sub(oldState.last)

t.state = &newState
mutex.Unlock()

t.clock.Sleep(newState.sleepFor)
return newState.last
}

然后应该很好懂了

只有一种确定的顺序还是可以随意指定顺序？


1. 只有一种顺序
如果只有一种顺序，按这个顺序建一个索引，然后 Index Scan 就好了，一个用户回答过的问题通常不会很多吧。
跳转到第 x 页这种需求不可能快，不用考虑了。

如果在这种排序下，每个用户回答过的问题都没有聚集在一起，这个方法应该就够快了。
如果有聚集在一起，用 vance123 的方法

2. 顺序可以任意指定
2.1 给每一种顺序建一个索引，然后回到 1，这个通常不现实
2.2 如果不能给每种顺序建索引，就没有通用的 O(n) 以内的算法了。基本上都要 Sequential Scan 。当然有各种优化的方法，但这种事情依赖于非常具体的需求。

这就是西安的玩法，所有地方都要扫码才让进。
喀什也有一套类似的，但是管得不严。
多数地方是楼主看到的这种，出一个二维码，工作人员看一眼就过去了。
还有的健康码只是一个像二维码一样的东西，但是有一部分被挡住了根本扫不出来。

楼主的例子也分好几类的

1. 打印机之类的东西一直可以无线

2. 长距离的无线供电不太现实

要传递能量且不经过介质
可以用微波，但这样相当于你直接坐在微波炉里
可以用更短的电磁波，但这样等同于电阳能电池板，需要对准才行，不动的电器好像还可以。目前也没有那么高效的电阳能板
也可以用磁场电场之类的，但为了家庭供电开一个大磁场，不太合适吧

3. 显示器类的
DP2.0 有 80.00 Gbit/s 的带宽，无线传输达不到这个数。
问题在于要提高无线传输的带宽需要提高频率，但频率高了就需要对准，同上不动的东西还可以


所以 1 楼说的没错，要实现可用的像 Wi-Fi 一样方便的供电和 DP HDMI 级别带宽的数据传输，都是目前看起来不可能实现的事情。

@lakin

咖啡因属于第二类精神药品，然后百度百科说第二类精神药品是毒品，但我不认同这个说法。
咖啡因被列入第二类精神药品，是因为它确实是精神药品且有医疗作用，但咖啡因的管制状态和海洛因冰毒大麻完全不一样，在京东淘宝都能买到纯咖啡因片。
尼古丁不属于精神药品，是因为它没有医疗作用，根本没人做这个东西来卖，自然没有管制的必要了。
抽烟挥发出来的气体里包含了有毒的尼古丁，但是咖啡不会挥发出来咖啡因。
喝咖啡确实会上瘾，但目前科学界的共识是适量饮用咖啡对人无害。

结论是咖啡和烟草完全不类似，不要相提并论。

这里的关键是楼主没想清楚自己要的是什么

给定的要求只有一个，>1 和 <1 的概率相等。
这样不能确定唯一的答案，所以下面给出了很多不同的解答。
给的解释又超出了楼主能解理的数学，所以估计现在更不懂了。

除了上面那个给定的要求，显然还存在一个要求是概率在某种程度上是均匀的，但均匀又存在不同的均匀。

比如把所有结果 round 到一个最接近的数，然后
0.5 0.6 0.7 0.8 0.9 1.0 1.2 1.4 1.6 1.8 2.0 的概率相同
1/2.0 1/1.8 1/1.6 1/1.4 1/1.2 1/1.0 1.2/1 1.4/1 1.6/1 1.8/1 2.0/1 的概率相同
这两个也不一样，都可以被认为是均匀的

上面说的，其实不仅 “每一个 Y 出现的概率都是 1/K” 对浮点数是错的，“所有确定的 X 都是 1/K 的概率” 也是错的。
因为浮点数本身是不均匀的，但那个随机数是均匀的。

建议楼主放弃这个问题吧，需要补的课挺多的。