mletov

Если прямо обязательно нужно в конкретном месте перенести строку и пофиг на то, как это будет выглядеть при другом размере/соотношении экрана, и при этом это логически не является новым параграфом - вполне можно и br вставить.

Моё мнение.

Это Conspiracy и сговор, против мелких игроков на рынке рассылки писем.
Используйте API/сервисы крупных игроков и все будет в порядке.

С таким количеством ошибок в заголовке вопроса вы бы подумали сначала, перед тем как статью писать) а то ведь заминусуют совсем)

Как мне правильно прописать в верхнем цикле for , чтобы был поиск только по этому массиву

Цикл не делает поиск. Для этого есть array_search и т.д.

я бы вначале создал массив с данными индексированными по id, а потом уже выводил во втором цикле перебирая только Ваш $arrSKU

А мы откуда должны это знать?

Несколько мыслей.

1) У меня устойчивое дежа-вю. Периодически в топик заходят люди с именно этим вопросом. Разница только в количестве. Кому 1 млрд. Кому 10. Можно также поискать и слинковать эти вопросы в один большой вопрос.

2) MySQL который указан в тегах - нормально справляется с этой задачей. Он и не такое число строк
умеет хранить. И если взять MariaDb - там есть куча новых engines которые можно крутить для тюнинга
именно скорости чтения. Разумеется жертвуя чем-то другим. Транзакциями и записью например.

3) Непонятно что такое минимальное время? Если использовать дисковую БД типа MySQL то деградация времени
поиска будет примерно зависеть от логарифма количества строк. Тоесть деградация будет но очень медленно.
Для 10 млрд индекс по key будет содержать порядка 4-5 уровней BTree дерева. Тоесть дисковой системе
нужно будет сделать до 5 или до 6 рандомных чтений (если нужные данные лежат в таблице). Это достаточно
быстро для того чтобы моргнуть глазом за это время. Рандомное чтение любого блока из магнитного диска
класса SATA-3 занимает порядка 20 милисекунд. Тоесть для 5 уровней - это 100 милисекунд. Для дисков
класса SSD и это время можно уже считать меньше милисекунды. Точно я не знаю надо мерять.

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

4) Непонятно зачем здесь указан Redis. Его задача не хранить 10 млрд а хранить только горячие
ключи по котороым идет очень частый доступ. Если автор хочет In-memory хранение - то время можно
еще сильнее улучшить. Его можно свести практически до нуля (я вангую несколько микро-секунд)
но придется прикупить планок памяти побольше и посчитать сколько памяти
надо для 10 млрд key/values неизвестной длины. Вообще крутить регулятор в направлении
микро-секунд нет особого смысла т.к. другие звенья вашего стека (приложение и сеть) могут
быть на порядки медленнее а это вообще нивелирует всю пользу от такой оптимизации.

Есть подозрение, что из-за него некорректно работает форма авторизации / регистрации на сайте.

Надо бороться с причиной, а не с явлением как таковым. Если форма криво работает из-под VPN, то виновата форма, а не VPN. Половина мира уже сидит в интеренет под VPN, поэтому стоит задуматься о том, что у тебя не так реализовано. Тем более, что каких то объективных причин нарушения работы web-сервера если на него поступают запросы от VPN нет.
Я бы скорее предположил, что в форме реализованы какие то скрипты (возможно даже сторонние JS библиотеки), который блокировщики рекламы считают спамом, и режут их, отсюда и проблема. Надо конкретно смотреть, что не так.

ак определить, что у пользователя включен vpn

Ну определишь ты, и что дальше? Как это тебе поможет реализовать исправление ошибки формы? Лучше задуматься о том, как исправить форму, чтобы все могkи ей пользоваться независимо от VPN.

Только по косвенным признакам.
Если вы ждёте аудиторию из РФ, а VPN находится за ее пределами, можно дергать IP посетителя ($_SERVER['REMOTE_ADDR'];) и прогонять через какой-нибудь сервис типа https://ip-api.com. Результат отличный от "Russua" - обрабатывать, как вам требуется...
Но это как вариант. Способ весьма костыльный.

Не знаю насколько мой случай типичен или является экзотикой, но я целенаправленно не учился программировать и все познавал в процессе.

Мне захотелось сделать сайт и я просто открыл исходный код похожей страницы и стал изучать как там все устроено - так я изучил HTML и CSS. Захотел сделать галерею и просто начал делать - в процессе освоил PHP (тогда это была еще третья версия). На сисадминской подработке попросили автоматизировать ежедневную рутинную операцию с заявками - освоил 1С 7.7. На следующей работе меня посадили на поддержку бухгалтерского софта для бюджетных организаций и единственным источником информации были только исходники программы - так я освоил Foxpro и SQL. И все это происходило в начале 2000-х в так сказать догугловскую и достекоферфлововский период.

И вот как-то мне захотелось изучить Java. У меня была какая-то бумажная книга от Питера, потом электронная версия философии Экера, смотрел форумы... Но не пошло и я забросил. А где-то пару лет назад нужно было для моего проекта сделать мобильное приложение и снова все пошло как по маслу - все что в подкорке лежало по Jave всплыло, а остальное быстро выловил на стековерфлоу, джаватолке и стартандроиде.

Так что мой совет: найдите себе дело и просто делайте его.

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

https://youmightnotneedjquery.com/#on и далее по пунктам

https://developer.chrome.com/docs/devtools/remote-...
Подключаем телефон к компу, открываем на телефоне сайт и на компьютере видим что в консоли телефона.