Хайбулла Мусаев

Когда надо удалять файлы? Тогда когда они не нужны. А не нужны когда закрыта страница с формой - это можно отследить на клиенте, сделать отбивку ajax-сообщением и удалить файлы. На случай неожиданного падения клиента можно повесить скрипт для периодической отбивки серверу, что клиент ещё жив, при этом обновлять время в базе и удалять по крону все файлы у которых дельта ушла за какое-то значение (10 минут, час... ). Думаю, основная масса будет удаляться по первому варианту.

Для защиты от перегруза, можете выделить под временные файлы отдельную директорию с квотой. При её переполнении переходите на вариант FileAPI, и загружайте только при сохранении.

Загружаешь картинки в темповую директорию и переносишь их в нужные папки только после создания объявления.
По крону вычищаешь темповую директорию например раз в сутки (удалять файлы, которые лежат в папке более x часов).
Можно использовать какие нибудь облачные хранилища, для темповых изображений и переносить их на сайт после подачи объявления. ( 1 ТБ 9,99 €/месяц. гугл драйв.)

Все что вам написали брехня. Нужно делать так:
1. Создать в БД таблицу для картинок (у вас она уже и так есть)
2. Добавить к таблице поля date, confirm
3. При загрузке картинки сразу грузить ее по конечному пути, при этом поле confirm у нас должно быть (null, 0, no) в общем как угодно, для примера пусть будет 0 не подтвержденная, 1 подтвержденная
4. После отправки формы с объявлением даем картинкам статус подтвержденных
5. Например раз в сутки удаляем картинки дата зашрузки которых < например сегодня - 1 день

Есть вариант гораздо лучше - FileApi.
То есть вы их превьювите на странице прямо в браузере, не загружая на сервер. А загрузите в момент подачи объявления. И UX хороший и место не простаивает.

Ограничивать по времени пользователя не хорошо. Я начал создавать объявление, меня позвала жена, вернулся через два часа, заполнил объявления, отправил форму и что мне скажет сервер? Первый вариант предпочтительнее, но его можно доработать дополнительными событиями. К примеру посылать ajax запрос с открытой страницы каждую минуту, на сервере обновлять "lock" файл, который отвечает за сохранность изображений, чекаем каждые 10 минут, удаляем если время обновления файла исчерпало время блокировки (к примеру 30 минут).

Столкнулся со схожими проблемами, долго бился с wrt , потом колдовал собственными костылями. В конечном счете плюнул и купил микротиковский роутер. Убил сразу кучу зайцев. Во первых внутри роутеров микротика можно поднимать виртуалки с wrt прошивками, во вторых роутер работает просто как часы, в третьих запитал по poe от роутера 2 ip телефона и wifi в другой комнате. Сам роутер посадил на ибп и теперь проблем с доступностью вообще не бывает, все в своих vlan'ах, скорость даже с кучей торрентов не падает, все легко настраивается и вообще был первый опыт общения с оборудованием микротика и сказать что я доволен это ничего не сказать, хотя так же работал с цисками и кучей разных дешевых комутаторов\свичей и роутеров.
В общем почитай по этой теме я сильно уверен что RouterOS или маршрутизаторы\роутеры микротиковские больше всего под задачи доступности подойдут.

Проблема доступности количеством каналов не решится.
Для веб сервиса, нужен нормальный фронт балансер.
Сначало все упрется в A запись DNS, по доменому имени же заходим.
1 решение. DynDNS будет менять запись в зависимости от рабочего канала.
2 решение. Свой собственный DNS сервер, который через Round Robin будет балансировать записи.
Но от кеша DNS пользователя все равно никуда не деться, активный пользователь наткнется на ошибку доступа к сайту.

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

Из комментариев видно, что вам непонятен практический смысл терминов "напряжение" и "ток". В этом случае разобраться помогает сравнение с потоком воды. Напряжение - это аналог давления, или разницы уровней выше-ниже плотины. А ток - аналог расхода воды (не зря созвучен слову "поток"). Если кран закрыт (выключатель выключен, цепь разомкнута) то какое бы ни было напряжение/давление, (по)тока не будет.
Теперь с вашим примером. Есть адаптер 12 в, 0,5 а. Включаем его - на выходе 12 вольт, и никакого тока, хотя на нём написано 0,5 а - ещё не создан путь для потока. Подключаем кулер - пошёл такой ток, который затребовал кулер, т.е. 0,18 а, и не больше (поток течёт по размеру дырочки, которую ему открыли). Остальные 0,32 ампера пока не востребованы. Подключаем ещё один такой же кулер - ток возрос до 0,36 а (два потока по 0,18). Поскольку адаптер может обеспечить 0,5, всё нормально. Но если подключим ещё один такой же кулер, суммарный ток возрастет до 0,54 а, что больше допустимого для адаптера - он будет перегружен, от него требуют невозможного. Если через плотину перельётся поток больше, чем может прийти по реке, то поскольку вода ушла, верхний уровень над плотиной понизится. Аналогично при перегрузке по току выходное напряжение адаптера понизится и уже будет менее 12 вольт. Если защиты от перегрузки в схеме адаптера не предусмотрено, он просто перегреется и может сгореть. Если защита предусмотрена, то при перегрузке она сработает, адаптер отключится, выходной ток исчезнет.

если врубаем напрямую, то нужно ли еще какой элемент в цепи, чтобы обезопасить сию конструкцию?

Если встроенной защиты от перегрузки нет, то обычно последовательно в цепь включают такой элемент, как плавкий предохранитель. Сгорая сам, он защищает от повреждения остальную схему, гораздо более дорогую. В вашем случае полезно последовательно с выходной цепью адаптера включить предохранитель на 0,5 а. Но реальный ток сгорания у дешёвых плавких предохранителей не точен и может быть в пределах -30%... +80%. Так что не удивляйтесь, если увидите, что такой предохранитель сгорит при подключении всего двух кулеров или не сгорит вообще, когда уже весь адаптер будет в дыму.

Не в коем случае!!! Вы просто удаляйте елемент масива, а потом проверяйте существование этого елемента. Есть == идентифицирован

С точки зрения хорошего кода плохо. Других ограничений нет.

Помимо закона Ома, в электротехнике существуют и другие фундаментальные правила.
Одно из которых - правило Кирхгофа. Согласно которому сумма токов в узел втекающих, равна сумме токов вытекающих, ну либо алгебраическая сумма токов в узле равна нулю.

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

Батарейки имеет внутреннее сопротивление, которое ограничивает ток который она может выдать в случаи короткого замыкание. (нижний ряд) и это сопротивления растет по мере ее разряда.

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

Когда мы говорим о силе тока применительно к источникам тока, то подразумеваем предельную силу тока, которые они способны выдать без повреждения. Кроме того, источники тока имеют собственное сопротивление, которое определяет ток короткого замыкания. Iкз = U/Rисточника.

При этом реальная сила тока в цепи с нагрузкой (в простейшем случае) считается по закону Ома для полной цепи: I = U/(Rнагрузки + Rисточника). Этот ток должен быть меньше предельно допустимого для источника.

При последовательном соединении батарей их напряжения суммируются, сопротивления тоже. А вот ток при последовательном соединении одинаков на всех участках цепи и, соответственно, предельный ток соединённых батарей будет равен предельному току одной батареи. Реальный ток всей цепи I = U*n/(Rнагрузки + Rисточника*n).

При параллельном соединении батарей ток будет распределяться между ними обратно пропорционально их внутреннему сопротивлению. Если батареи одинаковые, то ток цепи разделится поравну между ними и, соответственно, общий предельный ток соединённых батарей будет равен предельному току одной батареи, умноженному на количество батарей. Реальный ток всей цепи I = U/(Rнагрузки + Rисточника/n).