d'Ivan

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

Нужно сначала узнать что за формат файла. Есть утилита TrID для Windows/Linux.
Зная что за формат, куда проще узнать какое ПО работает с ним.

Не нужно вычислять объём памяти для буфера. Просто используй интерфейс io.Reader для потоковой обработки.
scanner := bufio.NewScanner(os.Stdin)
scanner.Text()вернёт токен с числом в строке.

https://pkg.go.dev/bufio#Scanner.Text

Пришел в голову такой вариант:
В текстовом потоке берём каждый токен и делаем инкремент количества, и т.д.
Затем сортируем результаты - здесь вопрос какую структуру данных выбрать, чтобы сортировать находу.

1) Насколько правильно обрабатывать в одной очереди и загрузку файла и парсинг самого файла?
Если произойдёт какая-то ошибка при чтении файла

Пока я не вижу смысла в дополнительной очереди. При скачивании нужно определять код статуса и если возвращает 20x, то можно приступать к чтению. Если 40x, то это баг клиента. Если 50x или сбой связи, то можно сохранить в таблице с временем последней попытки, чтобы можно было выбирать когда нужно провести следующую попытку.
Если файл скачан без ошибок и он цел, то проблем с чтением файла быть не должно, при условии соблюдения формата файла. А если скачан частично при коде 20x, то повторная обработка ничего не даст.
Скачанный файл можно удалять, если импорт окончен. А при сбое можно заново не скачивать - экономия времени.
Смену статуса импорта сделать сразу по окончанию обработки.

2) Запись сообщений в лог происходит в отдельной очереди, а для смены статуса импорта желательно отправлять сообщения в отдельную очередь или можно прямо здесь выполнять код для смены статуса?

не понял почему нужна очередь для лога.

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

сами изображения отправляются или что-то другое? Если первое, то это нелогично и это действительно нагружает очередь. Зачем все товары слать в очередь? Разве в очереди импорта нельзя считывать всё с файла и записывать сразу в СУБД? Это ведь никого задерживать не будет.

Получается, что все товары висят в одной очереди и ждут когда их проверят.

Нет, очередь нужна для обработки без ожидания. А для хранения используется СУБД с пометкой последней проверки и, возможно, временем, когда товар надо снова обновить. Какой-то периодический процесс может опрашивать таблицу: у кого протухли товары, отзовись!

Подключи APM к приложению, добавь системы мониторинга системы и узнаешь что и когда тормозит. Тогда от этого можно отталкиваться. Приложи скриншоты нагрузки СУБД с ее характеристиками, количества соединений, список долговисячих запросов, тогда будет о чем говорить.
А так, судя по нагрузке на скриншоте, как заметил Александр Карабанов , в среднем 1/6 процессоров нагружены на 100%, что не является потолком для нагрузки. Остальное время система/приложение ждет чего-то. Возможно, при работе с СУБД или при запросах наружу.

Официальный источник: https://redis.io/docs/getting-started/installation...

Литература - очень сомневаюсь в этом, уж больно много нюансов.
А вот ПО с открытым кодом (библиотеки и т.д.) - имеются. Допустим, Apache Tika.
Если для полнотекстового поиска нужно, то лучше взять готовое ПО: Apache Solr.

мне просто счётчик для различных скриптов

Memcached/Redis/SQLite

Если нет денег или не особо играешь в игры, дешевле взять процессор со встроенным GPU (интегрированная графика).

На POSIX системах можно использовать fgrep:

$ cat /tmp/file1.txt
aaa
bbb
ccc
$ cat /tmp/file2.txt
bbb
123
aaa
$ fgrep -f /tmp/file1.txt /tmp/file2.txt
bbb
aaa

Так что на PHP как-то так:

$output = shell_exec('fgrep -f /tmp/file1.txt /tmp/file2.txt > /tmp/dups.txt');

Однако, если требуется выполнять какие-то дополнительные манипуляции, тогда, возможно, лучше сразу импортировать в СУБД.

Добавлено:
упустил факт, что помимо дубликатов нужно оставить и неповторяющиеся значения. Тогда так:

$ sort -u /tmp/file1.txt /tmp/file2.txt
123
aaa
bbb
ccc

$output = shell_exec('sort -u /tmp/file1.txt /tmp/file2.txt > /tmp/dups.txt');

Нужно установить пакет с компилятором Vala:
sudo apt install valac

scan <cursor> MATCH user:* COUNT 100
вместо <cursor> выставить 0 и дальше изменять согласно полученному курсору.
https://redis.io/commands/scan/

Если верно понял требования, то вот мои мысли.

Использовать Transparent Data Encryption (TDE)

Выполнить шифрование данных на уровне таблиц:
https://www.postgresql.org/docs/current/encryption...
https://dev.mysql.com/blog-archive/controlling-tab...

То есть расшифровывание будет происходить на уровне СУБД, а с точки зрения приложения - обычные запросы LIKE.

Скрипт с циклом for по маске *.docx , в каждом найденном файле взять первый символ (Unicode) файла, приставить в конце .7z и получится имя файла, куда нужно добавить этот документ в архив. Ну и составить команду добавления в архив. Читать справку по cmd скриптам, 7z.