Когда вы можете использовать семафоры в повседневной жизни кодирования

Вы сидите в классе математики 8-го класса, читаете о тройках Пифагора, вы грабите теорему Пифагора. Знаменитое уравнение (a * a) + (b * b) = (c * c) запомнилось вам .

Перенесемся на 10 лет вперед - вы все еще вспоминаете тот день и задаетесь вопросом, почему, во имя бога, вас учили этому уравнению, вы никогда не встречали ничего практического в жизни, которое использует это уравнение, и это заставляет вас усомниться в нашей существующей системе образования.

Это один из сценариев, который заставляет нас задуматься, стоили ли те годы обучения на самом деле затраченных усилий. Многие из нас согласятся, что большая часть нашего образования на самом деле не помогает нам в нашей практической жизни.

Я разработчик программного обеспечения, работающий над продуктом SaaS, и я придумываю такие откровения, которые заставляют меня задуматься о резких различиях между моими теоретическими знаниями и практической жизнью. Но время от времени вещи всплывают в самых необычных сценариях и местах. Они заставляют меня задуматься, игнорируем ли мы и не ценим ли мы то, что на самом деле происходит под капотом нашей повседневной жизни.

Постановка проблемы

Итак, история началась, когда в один прекрасный день я мирно сидел в своем уютном теплом уголке офиса и занимался своей обычной разработкой API. Появился пользовательский билет, в котором говорилось, что они получили несколько сообщений от нашей службы, и они были этим раздражены. Я дважды проверил код, но этого не могло быть. Хрон, который запускает и отправляет сообщение конечному пользователю, должен был отправить его только один раз (и этот крон запускается каждый час).

В то же время я получил pagerduty, в котором говорилось, что на моем сервере cron произошел скачок загрузки ЦП. Обычно это случается время от времени, когда множество заданий должны обрабатываться несколькими кронами. Я случайно проверил систему и, к своему удивлению, обнаружил проблему, которая вызвала весь хаос и эти пользовательские тикеты.

К своему ужасу, я увидел несколько экземпляров одного и того же коммуникационного cron, работающих одновременно, выбирая одни и те же задания и отправляя сообщения. Это все объяснило. (Этого не должно было произойти - первый экземпляр cron должен был завершить свое выполнение до того, как начал работать второй экземпляр. Вот как должны работать задания cron).

В тот день произошел всплеск количества заданий, которые должен обрабатывать cron, из-за чего cron продолжал работать дольше обычного времени выполнения. Это привело к перекрытию (другими словами, он продолжал работать даже через час, а затем появился второй экземпляр).

Моя работа была вырезана для меня: я должен был ускорить выполнение и никогда не разрешать одновременное выполнение нескольких экземпляров одного и того же cron.

Решение

Первое, что пришло мне в голову, это реализовать семафоры (наконец, эти классы операционной системы промелькнули в моей памяти). Мой профессор был прав, говоря, что в один прекрасный день я воспользуюсь этой техникой, чтобы спасти свою жизнь.

«Сегодня тот день», - подумал я.

Так что я погуглил и нашел много полезных ресурсов для выполнения моей задачи. Я буду писать здесь о своих знаниях и о том, как, наконец, я понял, что фактически реализовал концепцию семафоров с самого начала.

Шаг 1

В каталоге системных файлов создайте файл с именем myCronPID.txt, в котором будет храниться идентификатор процесса (PID) cron, запущенного в этом конкретном экземпляре. Согласно Википедии:

В вычислениях идентификатор процесса (обычно именуемый идентификатор процесса или PID) - это число, используемое большинством ядер операционной системы, например те из UNIX, macOS и Microsoft Windows - для однозначной идентификации активного процесса.

Шаг 2

Узнайте идентификатор процесса (PID) запущенного cron. Это можно сделать, используя приведенный ниже код (я буду использовать PHP для справки).

Шаг 3

Впервые файл myCronPID.txt будет пустым. Сохраните текущий PID, полученный на шаге 2, в этом файле. В следующий раз, при получении PID запущенного cron (допустим, 5678), получите PID из файла myCronPID.txt. PID, полученный из файла (скажем, 1234), будет идентификатором процесса экземпляра cron, который выполнялся ранее. Убедитесь, что PID 1234 все еще находится в состоянии выполнения / работы. Это легко найти.

В системах Linux есть папка / proc, в которой находятся папки для текущих процессов в системе. Имена папок в этой папке / proc являются идентификаторами процессов. Допустим, если папка / proc содержит папку 1234,, это означает, что процесс с PID 1234 находится в рабочем состоянии. Если такой папки нет, это означает, что в данный момент не запущен процесс с PID 1234.

Шаг 4

На этом этапе получите PID из файла myCronPID.txt и проверьте, выполняется ли все еще процесс, используя код, указанный на шаге 3.

  1. Если isProcessRunning возвращает true, это означает, что предыдущий запущенный экземпляр cron не завершил свое выполнение. Следовательно, новый экземпляр, который вызвал функцию isProcessRunning, не должен возобновлять свое выполнение.
  2. Если isProcessRunning возвращает false, это означает, что предыдущий экземпляр cron завершил свое выполнение. Новый экземпляр, который вызвал функцию isProcessRunning, должен возобновить выполнение и поместить свой собственный идентификатор процесса в myCronPID.txt.

Шаг 5

Собираем все вместе:

Если вы запускаете экземпляр cron, просто вызовите указанный выше объект класса с его соответствующим конструктором.

$ fileName - это будет имя файла, в котором будет храниться PID файла cron.

$ rootDir - Это будет корневой каталог вашего текущего проекта.

После вызова используйте методы Util в вашем коде Cron следующим образом:

Это гарантирует, что одновременно не будет запущено несколько экземпляров одного и того же задания cron.

Подведение итогов

Изучив все это и написав приведенный выше код, я понял, что с самого начала не реализовал ничего, кроме семафоров. Мой профессор ОС сегодня бы гордился.

Это заставило меня снова задуматься: мы просто грабим концепции. Мы не изучаем тонкости наших знаний, а, скорее, работаем над такими абстрактными слоями, что не тратим время, чтобы оценить красоту работы, которая на самом деле происходит под капотом.

Наша система образования не всегда бывает поврежденной. Вся разница в том, как мы учимся. Попробуйте изменить себя, а не жаловаться. Мир полон чудес и прекрасен.

PS: Надеюсь, вам понравилась моя статья, поправьте меня, если я где-то ошибаюсь.