Сергей Пуговкин

1. нет, не правильно.
блокировка либо READ, либо WRITE.
MySQL.
READ - все(как сам процесс, так и другие) могут только читать.
WRITE - процесс, который вызвал блокировку, может читать и писать, остальные курят.
2. попробовать из другой сессии произвести запрещенное действие (INSERT/UPDATE/DELETE для READ, что угодно для WRITE) - запрос "зависнет" до разблокировки. Или до таймаута.
3. Будет ждать до таймаута.

Встраиваемое kv-хранилище от гугла - leveldb вам в помощь. Обертки есть почти под каждый популярный ЯП.

leveldb используется для хранения транзакций в клиенте биткоиана, а там уже, на минуточку, объем БД перевалил за 200 гигов.

Только учитывайте, что магии не будет, когда БД в RAM не вмещается, и боттлнек будет на дисковой подсистеме. Сильное ускорение будет давать быстрый ssd, особенно который nvme через pci.
Поэтому на частые запросы обмазываемся кэшами и, возможно, радуемся.

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

Пример, опровергающий утверждение о зависимости этих двух методов:

var n = 2/0; // деление на ноль
isFinite(n)  // false
isNaN(n)     // false

Есть необходимость писать в базу данных по 10к записей в секунду. .....Чтение относительно редко из бд происходит, только запись очень частая

Не проще писать в файл? Это не шутка. Если только писать и практически не читать. Логи nginx легко могут лететь с такой скоростью.

Лучше начать с другого конца. Не с расширения файла и его содержимого, а с того, кто и зачем его создал, какое приложение. Далее с помощью гугла можно узнать про это приложение больше информации, что у него за файлы там такие и для каких целей. Какая история создания этого приложения. Чем авторы пользовались при разработке. Может это вообще к языку Lua не имеет отношения. А если имеет, то станет ясно, с чего начать "вскрытие" этой каши.

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

Ведь кто угодно и что угодно может назвать *.luaq, и на основании одного лишь расширения и отсутствия текста внутри было бы странно заключать, что конкретно там содержится, и уж тем более чем вскрывать. А больше подсказок в вопросе вы не привели.

WebAPI браузера поедоставляет вещи типа setTimeout, или async await, коллбек-функции которые закидываются в очередь, а оттуда в порядке своей приоритетности попадают в стек по очереди. Промисы обрабатываются в приоритетном порядке.

Обычные callback-функции не попадают в очередь, они вызываются в общем стеке. Кроме промисов в приоритетную очередь микрозадач функция может быть добавлена через queueMicrotask(function).

А что если "асинхронные" операции занимают много памяти и выполняются долго. Если они выполняются в том же стеке, то они также перекроют доступ ко всем остальным операциям?

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

Вся соль в использовании.
Зачем он нужен покупателю.

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

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

Первым из появившихся, а как следствие самым «прокачаным» и стабильным является модуль WebRTC.io,
большая часть остальных — его форки.
WebRTC.io (WebRTC-клиент для ноды )

PS: Тем не менее со стороны сервера WebRTC не представляет ничего особенного, с ним можно управляться при помощи всем известного socket.io (например вот так).
Что в общем-то и советуют делать некоторые умные люди, так как задача весьма специфична для решения через дополнительный уровень абстракции.

PPS: собственно сабж IRL (с исходниками)

Таненбаум. Кажись "Современные операционные системы". Книга из серии "Классика Computer Science". В конце была дана ОС "Minix", на концепцию которой когда-то опирался Торвальдс, вроде как.

Важно понимать следующее: нет никакой ложки

С точки зрения Линукса, данные, которые вы якобы пишете на диск - это страницы в памяти, которые помечены как неанонимные (это значит, что на диске есть файл, который с ними связан), и грязные (а это значит, что эти страницы надо сбросить на диск).

Причем момент, когда произойдет сброс, зависит от кучи факторов - программист на это может влиять таким образом:

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

То есть, программист может потребовать, чтобы данные сбросились на диск пораньше, но не попозже.

После сбрасывания страниц на диск, ОС помечает их как чистые. Это значит, что их можно занять под что-то другое. Можете запустить htop и посмотреть на желтую полоску - это как раз те самые страницы кэша, и их может быть очень много.

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

А теперь важный вопрос - как же понять, остаются ли данные в кэше после записи. Да легко.

-очистите кэш sync; echo 1 > /proc/sys/vm/drop_caches
-посмотрите, что желтая часть на полоске памяти в htop исчезла
-запустите DD, запишите на диск гигабайт. (dd if=/dev/urandom of=test.raw bs=8M count=128 status=progress)
-посмотрите, что у вас нарисовался желтый гигабайт
-можете потом считать этот файл и увидеть офигительную скорость - выше гигабайта в секунду (у меня получается 6, что очевидно говорит о том, что чтение происходило из RAM). Последнее лучше делать, если писали на HDD - потому что хороший SSD может выдать столько же

Объективно, этот тест показывает, что ДА, записанные данные остаются болтаться в памяти.

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

Предположение так себе. Обьясню почему.
Вы игнорируете стандартные процедуры ос threading, file locking и пытаетесь получить воспроизводимый результат.
Возможно это получится, но стоит изменится ядру и ваши труды станут не нужными

дубли это зло, не делайте дублей

Здесь указывается

ну там же ответили: один воркер может проснуться и «схапать» все ожидающие входящие соединения, в результате будет дисбаланс ну и вообще не очень хорошо.

Как стоит поступить на многоядерной системе Debian 11 x64?

правила простые: если что-то не понимаете — не меняете, дефолт нжинкса достаточно хорош для большинства применений.

Говоря простым языком, на сайте может быть онлайн более одного человека при multi_accept off?

ИМХО проще взять и проверить, чем тут спрашивать.

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

Ничего за два года по вашим вопросам не изменилось

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

Понятие грязные деньги - это худшее, что принесла современная финансовая система.

Вы думаете криптовалюты почему появились? от хорошей жизни да?

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