@KunsLand 几十块夸张了，微软员工也要三十美元。office 2019

为啥导出 xls，如果只是数据的话 CSV 不就行了
excel 可以直接打开

管不住手是自己问题。我所有信用卡额度加起来都快比我年薪高了，我也没还不起卡债啊。
有多少钱买多少东西，把信用卡当借记卡用，从不欠钱交利息。开了自动还款，账单最后一天自动还账单。

@touchwithe 既然你明白有限位数会导致精度丢失，那你在硬件里实现个无限位数的出来？
做个减法，小于某个限度就算相等。
科学计数法的计算结果应该用科学的方法读。你输入只有 1 位有效数字，加法的输出就只有 1 位有效数字，你应该只取有效数字进行比较。计算机的比较就是减法，所以两者相减小于某个限度就可以说是相等。

就是你自己用没事，即使是在公司用
但是公司统一装就不行

@FloatLost 找工作还行吧，看所在地区
6 年之内必须提交绿卡申请。有绿卡申请就可以无限续期。主要问题是绿卡排期无法确定。绿卡排期是排队制，但你不知道前面多少人在排，多少人排过队又走了，也不知道每年能从队里处理多少人的申请。

@fengsien1999 那是大赦非法移民，和合法移民无关。拜登确实提出了数条利好移民的法案修改，如果能全部通过的话确实等于现在排期清空，今后也不会有很长排期。但是法案能否通过并不乐观，通不过就是废纸。

本科找工作够不够？够，我就是本科。现在在上 UIUC 的网校硕。水就水吧，反正公司报销学费，就当刷免费公开课还送文凭了。如果美国搞不定要移民其他国家，文凭有用。不然工作经验更有用。

基本上只要你有对应的经验和面试表现，文凭不是大问题。基本上都是要求本科足够，除非是 research 岗。硕也分研究硕和上课硕。后者就是一年学费换个学历，没什么难的。授课硕很少了，现在已经变成上课硕+TA 。

读硕的好处是：
h1b 抽签概率高。我三抽才中
绿卡容易办。我就因为本科 0 工作经验，绿卡被公司卡了两年多

如果你非常想留美国的话，那么最重要的是 PD 。早开始申请，早拿 PD，比什么公司什么学历都重要得多。因为别的都能换，之后再想办法就是。PD 是完全没法讨巧的。

一共就一年半的项目，有个毛的圈子，最多就是招聘会可以跳过一面而已。店面该怎么面还是怎么面。当你没其他东西的时候，抬学校名气做个敲门砖。有几年工作经验的人谁老提学校。好汉不提当年勇啊。

因为规模效益
语言再好用，没有现成的库，什么都得自己写，那谈何好用呢？

也有例外：汇编和 C
因为他们不是因为好用才用得多，而是因为贴近硬件。用汇编和 C 的人要的就是什么都自己写，为了性能。

“无序的环状链表要么使用额外的哈希表存储已经遍历过的 item，要么使用双指针增加遍历范围直至指针重合而退出”
不对吧，只要和列表头的地址比较不就好了，如果和头一致就说明遍历结束
换句话说，插入一个 dummy node

@fenglangjuxu 如果你需要的是高并发系统，那我非常怀疑你是否真的需要绝对的 C 。
同时我也很怀疑你是否真的应该用分布式锁实现这个目的。你去看实际生产中用的多的分布式的储存系统，以高性能为卖点的，其中有多少是强一致，又有多少用的是锁。不用锁，也有很多办法能保证程序的正确与高效，如何选择合适的分布式算法，这需要相关领域的知识。
该请人的时候就得请人。

@itskingname
@trlove
非常同意
我是材料工程和 CS 双学位。目前也是从事系统底层的工作，实践为主。说几个事情，恶心一下楼主：
1. 工程课教授：c 是一个经验常数，一般取 3
2. 工程课教授：这个公式的结果通常比实际稍大，但是没关系，我们下一步会取 10 倍安全余量
3. 工程课教授：这一大坨公式我们直接约等于 3
4. 老板：这个 corner case 你先别管，上线再说
5. 老板：这个 bug 我们都知道，但是很少见而且后果很小，先不修它
6. 老板：灰度上线跑了一个月了，有没有问题？没问题我们就放量了。
7. 我们之前都好好的啊，怎么到你这里就出 bug 了？

楼主呢，无非是想掉个书袋子，秀秀优越感。诚然，瞎 JB 用的傻逼是有，还不在少数。但是：
1. 如我楼上所说，垃圾文章到处都有，不局限于中文
2. 工程实现很多时候就是这么脏
3. 闻道有先后，术业有专攻

@Blueming 证明有 bug 很简单：举出一个 bug 就行。证明没有 bug 则是恶魔的证明。除非形式化论证，否则无法保证没有 bug 。
ZK 和 ETCD 是有设计模型的。虽然代码可能有 bug，但算法理论上是没问题的。
而 Redlock 的算法设计就是没有 C 的。

@sampeng Google：distributed lock library
1. Distributed locks with Redis – Redis
2. madelson/DistributedLock: A .NET library for ... - GitHub
其中 Redis 部分就是 Redlock
3. Kleppmann's blog 之前提到的
4. Everything I know about distributed locks | by Davide Cerbo
推荐了 ShedLock, 和 ZK 、ETCD 没细看 ShedLock，但是看起来不是 Redlock 衍生物
5. Distributed lock manager - Wikipedia
Redis can be used to implement the Redlock Algorithm for distributed lock management.[10]
呵呵
6. The Top 7 Distributed Locks Open Source Projects
猜猜 Redlock 出现了几次
7. Distributed Locks are Dead; Long Live Distributed Locks
看起来是没啥问题。
8. Everything I Know About Distributed Locks - DZone Database
和 4 一样
9. Building Distributed Locks with the DynamoDB Lock Client
没有细看。看到 heartbeat every 10 seconds 就说明和 Redlock 是一个意思
10. distributed locking - npm search
猜猜这里面有几个 redis ？又有几个 Redlock ？

这就是 Google 第一页。你觉得这够不够垃圾？
垃圾文哪都有，英文社区也不比中文社区少。

至于多少钱需要考虑可靠性的问题，我就提几个：
1. 阿里抢月饼
2. 2010 flash crash，有一说是高频交易程序出 bug，或者 fat finger，然后触发做市商程序挂起。请问这种事情是多少概率？
3. Ariane 5，就问这个 bug 贵不贵？
事实就是，这个世界并不是这么的可靠。有相当多的人其实根本无法理解其重要性。同时也有相当多的人理解但选择忽视。当然咱不是故意去写 bug 。但是如果一共也就几万块钱的系统，管的是不那么重要的东西，你觉得老板会希望你多花一个月时间去实现一个可以提供形式验证的软件吗？你一个月工资也要几千了。
还有电商搞促销活动，抢占市场重要还是不被撸 bug 重要？大不了事后砍单就是了。甚至还有故意塞漏洞就是吸引你来撸的。
任何事情，都有其机会成本。实践中，重点不是绝对无 bug，而是在某些关键节点做好 damage control，同时完善日志，确保出了问题以后能够查到原因。很多时候，这就够了。

@Makuma 要证明不安全只需要一个反例。
要证明安全则必须要靠推导。所以真的需要绝对正确的软件，那得先写出数学推导，然后把数学算法转换成代码，再证明数学模型和代码等价。这样做是可以保证没用 bug 的（只要硬件不出问题）。

当然，实际上需要这么干的软件非常非常少。大部分程序员就是写几个 test case，然后上线的时候灰度上线就算了。如果真的是这个行业的人，也不可能不看文档，只看一篇百度就瞎 JB 用。

@nagatoism 你说的垃圾技术文章问题，和中文无关。英文的垃圾文章也多了去了。只不过作为中文 native speaker，既然都在看英文文章了，大部分还是会去看官方文档的人。Aka，英文是个门槛。
但是如果完全脱离中文，直接就搜英文，你有非常大的概率会搜到垃圾英文文章。
比如有人今天手上就有个 redis，就想要个锁，你猜 Google 第一条是啥？
这是中文的锅吗？这明明是不看文档的锅。

@nagatoism
@sampeng
1000 万美金的系统还用 Redlock 那是自己作死。人家文档里都说了无法保证 C，不看文档能怪谁。上千万的系统没个设计文档没个安全审计，逗谁呢？都搞上千万的分布式系统了，还请不起一个专业搞分布式的来审计一下算法？技术负责人干什么用的？就是拍板负责用的啊。谁是老板谁负责。

什么情况下可以用？
1. 东西不值钱，不存在你说的 1000 万。
2. 活该傻逼不看文档
3. 不要求强一致，再维护一套 ZK 集群又太麻烦。比如楼上某些人提到的，第三方 API 限制频率。偶尔 miss 一次不是不能接受，但是不挡一下又不好。既然已经在用 Redis，那用个现成的 Redlock 实现也是顺理成章的事情。

说到底：不看文档就瞎用自己不懂的算法那就是活该。谁用谁负责。

@pisc 我也再最后重复一次：逻辑上全局一致的时间戳是可以实现的。linearizability 也是可以实现的。
但是你不可能在一个分布式的储存系统里，在处理请求的瞬间就确定，这是最新的 token 。
Martin 的文章里自己就写了。我说的和 Martin 说的不矛盾，OK ？所以他文中 making the lock safe with fencing 的方法是无效的。而他就是为了说明这个方法无效而写的这一段。

@sprite82 p 不是 performance，是 partition safety 。
你说的性能问题其实并不是 cap 三者任一。或者，最多就是和 a 沾点边。但是 a 只要系统不死锁，再慢都是合格的。
为了性能的分布式系统通常会适当放弃 C，比如设计模型就是实现最终一致性。

然后你说的节点挂掉的问题，其实也不是绝对的。通常是保证过半节点存活时，系统还可以保证 A 。如果不过半的话真的很难保证 P 。

@pisc 我上面就说了，全局时间戳是可以实现的，但全局时钟是不存在的。靠全局时间戳常见是实现最终一致性。
你在写入的瞬间无法知道这个写入是否成功。而是只能事后再去观测系统的状态。Martin 自己都说了，这个前提是 database 能够做到 reject 过期 token，问题是怎么实现呢？如果你可以实现这一点，你从一开始就不需要分布式锁。

我觉得一个程序员应该有阅读文档的能力并为理解一个算法的局限性。你说警告，Redis 的官方文档里是有警告的。

@nagatoism 我理解他的话。但是这是设计系统时瞎 jb 用算法而不看说明的锅，而不是算法没有做到 promise 。我们俩的意思是一样的，但是角度不同。我的意思是这个问题无解，但是算法在适当的情况下还是可以用。你和 Martin 的意思是这个问题无解，所以应该用其他算法。

@liudaolunhuibl 但是放弃 A 还是放弃 C，不是你所决定。具体系统设计要具体看待。
Martin 的意思是，既然你都用上分布式锁了，你也就别指望啥性能了。A 保也是白保，不如放弃 A 保 C，搞个强一致。
你要是能接受弱一致，大概率是不需要全局锁的。