MatthewHan

The Redlock algorithm

In the distributed version of the algorithm we assume we have N Redis masters. Those nodes are totally independent, so we don’t use replication or any other implicit coordination system. We already described how to acquire and release the lock safely in a single instance. We take for granted that the algorithm will use this method to acquire and release the lock in a single instance. In our examples we set N=5, which is a reasonable value, so we need to run 5 Redis masters on different computers or virtual machines in order to ensure that they’ll fail in a mostly independent way.

In order to acquire the lock, the client performs the following operations:

1. It gets the current time in milliseconds.
2. It tries to acquire the lock in all the N instancessequentially, using the same key name and random value in all the instances. During step 2, when setting the lock in each instance, the client uses a timeout which is small compared to the total lock auto-release time in order to acquire it. For example if the auto-release time is 10 seconds, the timeout could be in the ~ 5-50 milliseconds range. This prevents the client from remaining blocked for a long time trying to talk with a Redis node which is down: if an instance is not available, we should try to talk with the next instance ASAP.
3. The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.
4. If the lock was acquired, its validity time is considered to be the initial validity time minus the time elapsed, as computed in step 3.
5. If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to unlock all the instances (even the instances it believed it was not able to lock).

以上英文原文是 Redis 关于红锁的部分说明，我也标粗了其中的第二步操作。

以上 5 点为客户端的操作，其中第二步说明了「如果实例不可用，应该尽快尝试与下一个实例通信。」也就是防止阻塞。

为了因为互斥导致的「时钟漂移」，会减去一些上锁的消耗的时间（非常的小）。

你可以看看官方文档哦：redis 官方文档。

synchronized (file) {
            if (!file.exists()){
                file.mkdirs();
            }
		}

创建文件夹这里需要加锁吗？不是每个线程自己创建的私有对象吗？

从 BND 认识到的 Hacpai

啥时候再来一波空投

是不是 3.7.0 也加入了该内容，同步社区做了外链检测限制？

有一些错别字嗷~

• 名宿 [❌] 民宿 [✅]
• channel[❌] CHANEL[✅]

那可以在后台的视图层加一个 MessageBox 提示用户 Solo 的文章发布成功，但是社区的推送由于保护机制隔间在 10 分钟以上，请稍后再试吗？

probably

[INFO ]-[2020-01-16 10:39:03]-[org.b3log.solo.event.B3ArticleSender:124]: Pushed an article [title=《码出高效》系列笔记（一）：面向对象中的方法] to Rhy, result [更新失败 - 请休息一会再发布，最小发布间隔为 600 秒]

我在 Solo 的日志中找到了这么一条，也就是说距离上一条推送，必须要间隔 10 分钟以上才能 publish 下一次文章？

因为是这样的，昨天搭建了 Solo，所以把之前的 Hexo 的博客全搬过来了，所以一次性发布了 30+ 文章，每篇文章之间的推送肯定是小于 600 秒的。

但是如果这样的设计是为了社区服务器的过载吗？是否可以升级一下？利用缓存先收集客户的发布消息，不第一时间发布，利用空闲时间延时发布？因为对「新搬迁」的用户来说，我还得一篇一篇的在后台「更新」再推送一次，一小时只能推 6 篇，属实有、麻烦。