@liprais #6

我看完了 https://redis.io/topics/distlock，https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html，http://antirez.com/news/101 。

我个人挺认可 Redis 作者所说的“Most of the times when you need a distributed lock system that can guarantee mutual exclusivity, when this property is violated you already lost.”。如果方便的话，可以分享一下你的想法吗？谢谢。

@wakzz #12 我不太认可你所说的“避免死锁”，因为根本都不会出现死锁这种情况。关于 ttl，所有实例里的同一个 key 的 ttl 都一样。https://redis.io/topics/distlock#making-the-algorithm-more-reliable-extending-the-lock 有讲到延长 ttl，但是它也强调了“so the maximum number of lock reacquisition attempts should be limited, otherwise one of the liveness properties is violated”。所以不是“不断给未释放的锁续期”，而是 client 还未完成计算，但是失效时间快要到了，client 可以请求延长时间。就算是这样，也不是“直到锁释放”，延长是有次数限制的，不然就会违反活跃性这个特性。

@ALLLi #1 其实我感觉，你并没有太明白我的问题，而且也没有回答到我的问题。

@ALLLi #8 是的，https://redis.io/topics/distlock#is-the-algorithm-asynchronous 中也说了“At this point we need to better specify our mutual exclusion rule: it is guaranteed only as long as the client holding the lock will terminate its work within the lock validity time (as obtained in step 3), minus some time (just a few milliseconds in order to compensate for clock drift between processes).”。

@AmmeLid #7

我觉得并不是，维基百科说“A livelock is similar to a deadlock, except that the states of the processes involved in the livelock constantly change with regard to one another, none progressing.”。

但是就我们这个例子，比如一个实例下线了，只剩下 4 个，client1 获取到两个，client2 获取到另外两个，它们都无法成功获取到锁，之后释放，但是 https://redis.io/topics/distlock#retry-on-failure 中说了“When a client is unable to acquire the lock, it should try again after a random delay in order to try to desynchronize multiple clients trying to acquire the lock for the same resource at the same time (this may result in a split brain condition where nobody wins).”，因为随机的延迟，最后不会出现“none progressing”这种情况。

@hdbzsgm #2 我不确定我是否正确理解你所说的，你所说的是[Distributed locks with Redis – Redis - Is the algorithm asynchronous?]( https://redis.io/topics/distlock#is-the-algorithm-asynchronous)中所说的“The algorithm relies on the assumption that while there is no synchronized clock across the processes, still the local time in every process flows approximately at the same rate, with an error which is small compared to the auto-release time of the lock. This assumption closely resembles a real-world computer: every computer has a local clock and we can usually rely on different computers to have a clock drift which is small.”吗？算法依赖于每个进程内的时间的流动速度是差不多一样的。是吗？

@jybox #1 你说“同时获取可能会死锁（每个客户端成功在一半的实例加锁），所有客户端都顺序访问就不会出现死锁了”。我不太同意你的说法，比如在某个时刻，client1 获取到了 5 个中的 2 个，client2 获取到了 5 个中的 2 个，它们都想去获取最后一个，但是只有一个能够成功获取，不会存在你说的死锁情况，因为不会出现“client1 持有 client2 需要的资源，client2 持有 client1 需要的资源”这种情况，不会构成一个环。

@popesaga #1
@bee7 #4

count++本身不是原子操作，但是代码里已经使用了内置锁保证了 count++的原子性。根本问题不是 count++，而是没有用锁保护好 count 这个共享可变变量，也就是两个线程可以“同时”执行 count < 100 判断。如果当前 count 是 99，奇线程执行判断成功，获取锁，但是在更新 count 值之前，这个时候奇线程中止了，轮到偶线程执行，虽然判断成功，但是没办法获取锁，不过等到奇线程释放锁之后，偶线程就可以获取到锁了，最后偶线程会打印出 100 。

@pangleon #19 “间隙锁又会引起别的 BUG”，可以详细说明一下是什么 bug 吗？谢谢。

其实我不太明白为什么这么多人都是在说 gap locking，文档里明明说的是 next-key locking 。

https://dev.mysql.com/doc/refman/8.0/en/innodb-next-key-locking.html 中说了“To prevent phantoms, InnoDB uses an algorithm called next-key locking that combines index-row locking with gap locking.”，很明显，单纯的 gap locking 是不能阻止幻读的，index-row locking 加上 gap locking 才能够解决。

@huntcool001 #12 +1，并没有完全解决。

https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html 中也描述了这个问题。在“The snapshot of the database state applies to SELECT statements within a transaction, not necessarily to DML statements.”这段里面。

我们是使用 canal 统一管理缓存的清除，在调用方法前判断是否存在缓存，没有就获取 MySQL 的数据，然后缓存起来。在方法里面处理缓存相关的逻辑，个人觉得不太好，就像 AOP 一样，不要污染业务逻辑。

@zhangysh1995 你可以自己去执行一下，看看是不是等价的，如果是的话，麻烦分享一下语句，让我重现一下。

@no1xsyzy #6
@leoleoasd #9

虽然说 a left join b on a.bid = b.id 和 b right join a on a.bid = b.id 得到的结果是一样的，但是因为它们的 a 和 b 的顺序还是会造成处理的性能差异的，具体可以看看“Database System Concepts 6th edition - Chapter 12 Query Processing - 12.5 Join Operation”，因为内容是在太多了，在评论里讲不清楚。

@zhangysh1995 #13

你说“WHERE 和 ON 在 JOIN 情况下没有什么区别”，你是说 inner join 吗？如果是的话，你说得没错，但是我想更加明确地说出，where 和 on 在 outer join 的表现是有区别的。

在“Database System Concepts 6th edition - Chapter 4 Intermediate SQL - 4.1 Join Expressions - 4.1.1 Join Conditions”中，说了“However, there are two good reasons for introducing the on condition. First, we shall see shortly that for a kind of join called an outer join, on conditions do behave in a manner different from where conditions. Second, an SQL query is often more readable by humans if the join condition is specified in the on clause and the rest of the conditions appear in the where clause.”。之后在“4.1.2 Outer Joins”中，它说“As we noted earlier, on and where behave differently for outer join. The reason for this is that outer join adds null-padded tuples only for those tuples that do not contribute to the result of the corresponding inner join. The on condition is part of the outer join specification, but a where clause is not.”。

我这里用例子演示一下 on 和 where 的区别吧。
create table t1(c1 int);
create table t2(c2 int);
insert into t1 values(1),(2),(3);
insert into t2 values(1);

select t1.*, t2.* from t1 left join t2 on t1.c1 = t2.c2; 的结果为
+------+------+
| c1 | c2 |
+------+------+
| 1 | 1 |
| 2 | NULL |
| 3 | NULL |
+------+------+

select t1.*, t2.* from t1 left join t2 on true where t1.c1 = t2.c2; 的结果为
+------+------+
| c1 | c2 |
+------+------+
| 1 | 1 |
+------+------+

@xgfan 我现在是使用 String 替代枚举作为替代应急措施，但是我更希望 Jackson 自身能够实现"保存 Map 中 key 的类型信息"，因为不能改用其他的序列化 /反序列化机制。

@hanssx #8 https://stackoverflow.com/a/47451071/5232255，这个回答或许对你有帮助。我暂时没有找到更好的方法。

@hanssx #5 谁先谁后“只能”通过最后的执行计划确定（“只能”加上双引号是因为有些还是可以直接看出来的）。如果 select 先执行，那么`select column1 from t order by column2`怎么能够成功执行呢？说 order by 先执行，`select column1 from t order by column1`，如果 t 有很多列，那么先执行 select，然后再执行 order by，肯定性能会更好。

@hanssx #4 第一条和第三条回复加起来就能够解释为什么两者不一样了，你的理解是对的。