We, as developers, want our applications to be up all the time. This is actually a common mission where redundancy and horizontal scalability is in place; so we have just decided to distribute the same application to different environments. So far so good.
作为开发人员，我们希望我们的应用程序一直在运行。 实际上，这是实现冗余和水平可伸缩性的常见任务。 因此我们刚刚决定将同一应用程序分发到不同的环境。 到现在为止还挺好。
However, distributing the same process in different environments may be a problem when it comes to some tasks which should not be executed concurrently on more than one instance of the application. In this post, I propose a simple approach to overcome this issue. My example will be built around a cron job scheduler job which will be problematic in case of two(or more) occurences of the same jobs are executed concurrently. In a cluster, same problem may come up in different shapes and there are various alternative solutions. To keep our example simple and lean, there will be a single job in our environment.
但是，当涉及一些不应在一个以上应用程序实例上同时执行的任务时，在不同的环境中分配相同的进程可能是个问题。 在这篇文章中，我提出了一种解决此问题的简单方法。 我的示例将围绕cron作业调度程序作业构建，如果同时执行两个(或多个)相同作业，这将是一个问题。 在集群中，相同的问题可能以不同的形式出现，并且存在各种替代解决方案。 为了使我们的示例简单而精简，我们的环境中将只有一项工作。
As scheduler is installed to different environments, following problems need to be addressed:
由于调度程序已安装到不同的环境，因此需要解决以下问题：
Which host will handle the responsibility of executing the job? The host, which is in charge, is the master.
哪个主机将负责执行工作？ 负责的主机是主机。
What happens if the master dies or becomes unresponsive? How other pending host will be activated as master (which is called slave in the rest of this post)
如果主人死亡或无React怎么办？ 其他待定主机将如何被激活为主服务器(在本文的其余部分中称为从服务器)
My approach here will be, storing a mutual resource (mutex) among all cluster instances. Whoever succeeds acquiring the mutex, will perform as master host.
我在这里的方法是在所有群集实例之间存储一个互助资源(互斥体)。 成功获取互斥锁的任何人都将充当主控主机。
Why Redis? Redis is a well-known key value store and widely used in system design for several years. It support high availability and has a configurable persistence system. However, same mission can be achieved by several other tools like Consul, Zookeeper or simply a database. I felt more confortable with Redis and that’s the motivation behind my choice. I you wish to use another tool, I wouldn’t expect applied principles to change.
为什么选择Redis？ Redis是一个著名的键值存储，并在系统设计中广泛使用了几年。 它支持高可用性，并具有可配置的持久性系统。 但是，可以通过Consul，Zookeeper或其他数据库等其他工具来实现相同的任务。 我对Redis感到更自在，这就是我选择的动机。 我希望使用其他工具，我希望应用的原理不会发生变化。
Here are our options with Redis:
以下是Redis的选项：
Redlock algorithm described here in detail https://redis.io/topics/distlock
此处详细描述的Redlock算法https://redis.io/topics/distlock
SETNX command which is an optimistic concurreny supported key declaration. SETNX命令是乐观并发支持的键声明。 SET command with some LUA scripts. SET命令和一些LUA脚本。Here, my choice will be using Redlock algorithm for following reasons:
在这里，出于以下原因，我将选择使用Redlock算法：
It supports high availability (Although there are criticisms) 它支持高可用性(尽管有批评) There is an awesome library for C# (RedLock.Net) and it has out-of-box resiliency features 有一个很棒的C＃库(RedLock.Net)，它具有开箱即用的弹性功能Initially we have to initialize a RedLockFactory instance. Our strategy will be to try to acquire red lock reference initially.
最初，我们必须初始化RedLockFactory实例。 我们的策略将是尝试首先获取红色锁定参考。
var redisEndpoint = new RedLockEndPoint(new DnsEndPoint("localhost", 6379)) { RedisDatabase = 0, RedisKeyFormat = "MiniJobScheduler:{0}", }; var listOfRedisEndpoints = new List<RedLockEndPoint> {redisEndpoint}; var redlockFactory = RedLockFactory.Create(listOfRedisEndpoints);However, if the application instance fails to acquire the lock, it will periodically check if it can get the lock to claim a master role. Just not to code this functionality in every job separately, a RedLock wrapper (called LockReference) can be introduced.
但是，如果应用程序实例未能获取该锁，它将定期检查它是否可以获取该锁以声明主角色。 只是不要在每个作业中单独编写此功能，否则可以引入RedLock包装器(称为LockReference)。
public async Task<bool> ClaimAsync() { if (_redLock == null || !_redLock.IsAcquired) { _redLock = await _redLockFactory.CreateLockAsync("my-cluster", TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(1), _cancellationToken); } return _redLock.IsAcquired; }Our sample job is responsible for tracking availability status. If the application instance doesn’t hold a valid lock, it will try to claim lock via LockReference wrapper.
我们的样本工作负责跟踪可用性状态。 如果应用程序实例未持有有效锁，它将尝试通过LockReference包装器声明锁。
public async void RunAsync(CancellationToken cancellationToken) { while (!cancellationToken.IsCancellationRequested) { if (await _lockReference.ClaimAsync()) { Console.WriteLine($"Job has executed at {DateTime.Now}"); } else { Console.WriteLine($"Waiting to acquire lock {DateTime.Now}"); } await Task.Delay(1000, cancellationToken); } }Full source code can be found here: https://github.com/kutluarasli/cron-job-cluster-sample
完整的源代码可以在这里找到： https : //github.com/kutluarasli/cron-job-cluster-sample
In this sample application, I tried to keep every aspect as simple as possible; However, a real world example may be more sophisticated than example code. Anyway, I would not expect basic principles to change. These are:
在这个示例应用程序中，我试图使每个方面都尽可能简单。 但是，现实世界中的示例可能比示例代码更为复杂。 无论如何，我不会期望基本原理会发生变化。 这些是：
RedLock ensures only one instance of the application holds a valid lock at the same time. RedLock确保只有一个应用程序实例同时持有有效锁。 When the master instance dies, lock is released once the eviction period is over. 当主实例死亡时，驱逐期结束后将释放锁定。 As mutual resource is set to free, a running instance of the application would acquire the lock and promote itself as master. 由于将相互资源设置为免费，因此正在运行的应用程序实例将获得该锁并将其自身提升为主服务器。I created a library on GitHub to perform these tasks. It is not tested on production yet but you might want to follow it for further developments.
我在GitHub上创建了一个库来执行这些任务。 它尚未在生产中经过测试，但是您可能希望遵循它进行进一步的开发。
https://github.com/kutluarasli/minilock
https://github.com/kutluarasli/minilock
翻译自: https://medium.com/trendyol-tech/a-simple-active-passive-cluster-implementation-with-redis-beef4f7bbf23
相关资源：四史答题软件安装包exe