摘要：持有雞的人是唯一被允許談話的人。這樣可以確保人們互不說話，也有自己的空間。所以當(dāng)作業(yè)第一次啟動時，創(chuàng)建一個互斥，然后每次作業(yè)運行時，它檢查互斥是否存在，只有在沒有工作的情況下運行。

譯文GitHub https://github.com/yuansir/diving-laravel-zh

原文鏈接 https://divinglaravel.com/task-scheduling/preventing-overlapping

Sometimes a scheduled job takes more time to run than what we initially expected, and this causes another instance of the job to start while the first one is not done yet, for example imagine that we run a job that generates a report every minute, after sometime when the data gets huge the report generation might take more than 1 minute so another instance of that job starts while the first is still ongoing.

有時一個預(yù)定的工作需要比我們最初預(yù)期的更多的時間運行，這樣會導(dǎo)致另外一個工作的實例開始，而第一個還沒有完成，例如，我們運行一個每分鐘生成報告的工作有時候當(dāng)數(shù)據(jù)變大時，報表生成可能需要1分鐘以上，這樣就可以在第一個還在進(jìn)行時啟動該作業(yè)的另一個實例。

In most scenarios this is fine, but sometimes this should be prevented in order to guarantee correct data or prevent a high server resources consumption, so let"s see how you can prevent such scenario in laravel:

在大多數(shù)情況下，這是很好的，但有時候應(yīng)該防止這種情況，以保證正確的數(shù)據(jù)或防止高的服務(wù)器資源消耗，所以讓我們看看如何防止這種情況在laravel中發(fā)生：

$schedule->command("mail:send")->withoutOverlapping();

Laravel will check for the ConsoleSchedulingEvent::withoutOverlapping class property and if it"s set to true it"ll try to create a mutex for the job, and will only run the job if creating a mutex was possible.

Laravel將檢查 ConsoleSchedulingEvent::withoutOverlapping 類屬性，如果設(shè)置為true，它將嘗試為作業(yè)創(chuàng)建互斥，并且只有在創(chuàng)建互斥的情況下才能運行該作業(yè)。

Here"s the most interesting explanation I could find online:

這是我可以在網(wǎng)上找到最有趣的解釋：

When I am having a big heated discussion at work, I use a rubber chicken which I keep in my desk for just such occasions. The person holding the chicken is the only person who is allowed to talk. If you don"t hold the chicken you cannot speak. You can only indicate that you want the chicken and wait until you get it before you speak. Once you have finished speaking, you can hand the chicken back to the moderator who will hand it to the next person to speak. This ensures that people do not speak over each other, and also have their own space to talk. Replace Chicken with Mutex and person with thread and you basically have the concept of a mutex.
-- https://stackoverflow.com/questions/34524/what-is-a-mutex/34558#34558
當(dāng)我在工作中進(jìn)行熱烈的討論時，我使用一只橡膠雞，我在這樣的場合放在桌子上。 持有雞的人是唯一被允許談話的人。 如果你不握雞，你不會說話。 你只能指示你想要雞，等到你說話之前才能得到它。 一旦你完成演講，你可以將雞回到主持人，他將把它交給下一個人說話。 這樣可以確保人們互不說話，也有自己的空間。 用線替換雞與互斥和人，你基本上有一個互斥的概念。
-- https://stackoverflow.com/questions/34524/what-is-a-mutex/34558#34558

So Laravel creates a mutex when the job starts the very first time, and then every time the job runs it checks if the mutex exists and only runs the job if it doesn"t.

所以當(dāng)作業(yè)第一次啟動時，Laravel創(chuàng)建一個互斥，然后每次作業(yè)運行時，它檢查互斥是否存在，只有在沒有工作的情況下運行。

Here"s what happens inside the withoutOverlapping method:

這里是 withoutOverlapping 方法中做的事

public function withoutOverlapping()
{
    $this->withoutOverlapping = true;

    return $this->then(function () {
        $this->mutex->forget($this);
    })->skip(function () {
        return $this->mutex->exists($this);
    });
}

So Laravel creates a filter-callback method that instructs the Schedule Manager to ignore the task if a mutex still exists, it also creates an after-callback that clears the mutex after an instance of the task is done.

因此，Laravel創(chuàng)建一個filter-callback方法，指示Schedule Manager忽略任務(wù)，如果互斥仍然存在，它還會創(chuàng)建一個在完成任務(wù)實例后清除互斥的回調(diào)。

Also before running the job, Laravel does the following check inside the ConsoleSchedulingEvent::run() method:

在運行該作業(yè)之前，Laravel會在ConsoleSchedulingEvent::run()方法中進(jìn)行以下檢查：

if ($this->withoutOverlapping && ! $this->mutex->create($this)) {
    return;
}

While the instance of ConsoleSchedulingSchedule is being instantiated, laravel checks if an implementation to the ConsoleSchedulingMutex interface was bound to the container, if yes it uses that instance but if not it uses an instance of ConsoleSchedulingCacheMutex:

當(dāng) ConsoleSchedulingSchedule 的實例被實例化時，laravel會檢查 ConsoleSchedulingMutex 接口的實現(xiàn)是否綁定到容器，如果是，則使用該實例，如果不是，使用ConsoleSchedulingCacheMutex實例：

$this->mutex = $container->bound(Mutex::class)
                        ? $container->make(Mutex::class)
                        : $container->make(CacheMutex::class);

Now while the Schedule Manager is registering your events it"ll pass an instance of the mutex:

現(xiàn)在，Schedule Manager正在注冊你的事件，它會傳遞互斥的一個實例：

$this->events[] = new Event($this->mutex, $command);

By default Laravel uses a cache-based mutex, but you can override that and implement your own mutex approach & bind it to the container.

默認(rèn)情況下，Laravel使用基于緩存的互斥，但您可以覆蓋它并實現(xiàn)自己的互斥方法并將其綁定到容器。

The CacheMutex class contains 3 simple methods, it uses the event mutex name as a cache key:

CacheMutex 類包含3個簡單的方法，它使用事件互斥名作為緩存鍵：

public function create(Event $event)
{
    return $this->cache->add($event->mutexName(), true, 1440);
}

public function exists(Event $event)
{
    return $this->cache->has($event->mutexName());
}

public function forget(Event $event)
{
    $this->cache->forget($event->mutexName());
}

As we"ve seen before, the manager registers an after-callback that removes the mutex after the task is done, for a task that runs a command on the OS that might be enough to ensure that the mutex is cleared, but for a callback task the script might die while executing the callback, so to prevent that an extra fallback was added in ConsoleSchedulingCallbackEvent::run():

如前所述，管理器注冊一個在完成任務(wù)之后刪除互斥的回調(diào)，對于在操作系統(tǒng)上運行命令的任務(wù)可能足以確保互斥被清除，但是對于回調(diào) 執(zhí)行回調(diào)時腳本可能會死機(jī)，所以為了防止這種情況在 ConsoleSchedulingCallbackEvent::run()中添加了一個額外的回退：

register_shutdown_function(function () {
    $this->removeMutex();
});

轉(zhuǎn)載請注明：?轉(zhuǎn)載自Ryan是菜鳥 | LNMP技術(shù)棧筆記

如果覺得本篇文章對您十分有益，何不 打賞一下

本文鏈接地址:?剖析Laravel計劃任務(wù)--避免重復(fù)