В целом я медленно перехожу на новые фичи языка. Не все нравится.
Например v is null лучше чем, v == null. но v is not null слишком многословно, чем v != null
Дефолтный метод в интерфейсе - я давно о таком думал. Но местами неудобно - надо приводить тип к этому интерфейсу, чтобы вызвать именно дефолтную реализацию, а не переопределение в классе.
Топ стейтмент не понравились. Теряться ощущение структуры, как и неймспейс или using без обрамляющих фигурных скобок
Но вот фича когда c# можно использовать как скриптовый язык - мне понравилась, хотя пока не пользовался так активно.
На наших продуктах кстати отразилось довольно лайтово - для нас упал AWS Systems Manager и Secrets Manager (мы там храним конфиги и сикреты), но так как мы их кешируем и никаких деплоев / перезагрузок серверов не было - все в целом работало.
Автор, для полноты картины добавьте на график роста зп - график роста цены квадратного метра жилья и ежемесячного платежа по ипотеке в регионах и столицах на данный момент. И график официальной инфляции.
Вот тут поясню (у меня такая же задача, только у меня тут не озон конечно).
Конфигурация - MySql 8.0 / i7-8700k / 32Gb, на одном складе, 10 items, 100 потоков, 1000 requests
Вариант, когда я беру из БД с SELECT FOR UPDATE, обновляю в C# коде и потом сохраняю в БД - в логах консольки деадлоки все равно есть, retry в EF Core срабатывает, цифры в конце сходятся, скорость примерно 20 rps
Вариант с хранимкой с SELECT FOR UPDATE, в логах консольки деадлоки есть, retry в EF Core срабатывает, цифры в конце сходятся, скорость примерно 60-90 rps
Вариант с хранимкой БЕЗ SELECT FOR UPDATE + без проверки остатка в конце, в логах консольки пусто, цифры в конце сходятся, скорость 400-440 rps
Вариант с хранимкой БЕЗ SELECT FOR UPDATE + с проверкой остатка в конце, в логах консольки пусто, цифры в конце сходятся, скорость 300 rps
И что еще заметил - последние два варианта отрабатывают нормально даже на уровне ReadUncommitted. Меня это смущает, пока не понимаю почему.
Позже пожалуй поставлю postgresql и проверю тоже самое на нем, интересно узнать разницу между дефолтным mysql и дефолтным postgresql
Много информации и предположений, хотелось бы уточнить некоторые моменты
Сервис из статьи как раз может стоять после очереди и принимать не заказы, а список ItemId и Qty. И до этого может быть некая пред-обработка (упаковок, китов и так далее). Это же просто облегченный пример, чтобы показать, что обычное железо с простым кодом может сделать 600 заказов в секунду.
Если 600 заказов в секунду на один склад и система справляется - то зачем шардирование? Но все же хорошо бы узнать - сколько там на самом деле у озона, возможно у них больше 600 и их усложненное решение оправдано
В любом случае бутылочным горлышком будет не программный код или БД, а люди, которые бегают по складу и собирают заказ с полок. Сколько надо людских и иных ресурсов и складских площадей, чтобы физически обработать 600 заказов в секунду (это порядка 50 млн за 24 часа) на одном складе?
Со страховым остатком разумеется дельная штука - можете чуть детальней рассказать, как вы его будете пересчитывать, чтобы он не пошел в разнос при параллельной обработке? Есть же базовый пример для общепринятого языка программирования - счетчик с interlock или volatile. Тут придется сделать примерно то же самое. И какой будет механизм отката, когда число выйдет за обозначенные рамки?
"Купим пожиже и за ночь разгребем" - в некоторых случаях может быть определен SLA, типа обработать 200 тыщ заказов за 2-3 часа, а не ночью
И еще момент - конкретно в случае с маркет-плейсом, когда резерв товара происходит до момента оплаты и откат резерва, если оплата не прошла. С точки зрения пользователя и клиентской части - это синхронна обработка. Если обрабатывать через очередь, то надо будет усложнять решение, чтобы дружить синхронного клиента и асинхронную очередь. Поэтому альтернатива с синхронным резервом без очередей - вполне себе альтернатива.
Крупный логистический центр Ozon может обрабатывать более 900 тысяч заказов в день, а распределительный центр Ozon обрабатывает до 600 тысяч заказов в сутки
Это скорее всего физическая отгрузка. Но для программной системы - это порядка 10 заказов в секунду.
В том то и дело - мы точно не знаем. Можно усложнить в стиле озона - сделать батч и перед выполнением посчитать и сравнить кол-ва на складе и во всех заказах. И если точно хватает, то можно и без блокировок.
Наконец-то! Хммм, надо же как вышло... Пожалуй все когда-нибудь заканчивается. Вместе со школьными и студенческими годами ушла эпоха печатных игровых журналов.
Хм любопвтно. А можно пример с зубодробительными мета штуками?
В целом я медленно перехожу на новые фичи языка. Не все нравится.
Например v is null лучше чем, v == null. но v is not null слишком многословно, чем v != null
Дефолтный метод в интерфейсе - я давно о таком думал. Но местами неудобно - надо приводить тип к этому интерфейсу, чтобы вызвать именно дефолтную реализацию, а не переопределение в классе.
Топ стейтмент не понравились. Теряться ощущение структуры, как и неймспейс или using без обрамляющих фигурных скобок
Но вот фича когда c# можно использовать как скриптовый язык - мне понравилась, хотя пока не пользовался так активно.
А это че теперь когда ИП заключает договор с ООО и там в конце пишут фио директора - это тоже надо эту лабуду про перс данные подписывать?
А вот настоящая причина xD /s
На наших продуктах кстати отразилось довольно лайтово - для нас упал AWS Systems Manager и Secrets Manager (мы там храним конфиги и сикреты), но так как мы их кешируем и никаких деплоев / перезагрузок серверов не было - все в целом работало.
Странный выбор Clojure. Можно же было загуглить статистику вакансий и выбрать что-то из более популярного, типа Go, Java, C#
Вроде бы не в тему ИТ, но смутно вспоминается - «где то я такое уже видел»
Гугл говорит, что на hh на начало 2025 года было 634 тыс вакансий и примерно 10% из них в ИТ. То есть 63 400.
При этом индекс hh был 9.9, то есть 630 тыс человек на 63 тыс вакансий.
Чтоб оправдать слова про нехватку 1 миллиона айтишников - это надо 1 634 000 вакансий прям щас, сию секунду.
Автор, для полноты картины добавьте на график роста зп - график роста цены квадратного метра жилья и ежемесячного платежа по ипотеке в регионах и столицах на данный момент. И график официальной инфляции.
А реальная инфляция больше статистической, так что там в лучшем случае ноль, а то и отрицательный рост.
Недавно попалась статья как китайцы сделали улучшенный прототип плазменного двигателя - сжатый воздух и микроволны https://www.ecoticias.com/en/batteries-china-plasma-jet-engine/21372/#
(Факт чекингом не занимался, может и наврали)
Кажется это безвыходная ситуация
Жаль не сохранил тот комикс, где школьник с мамой пришли покупать комп, и мальчик говорит «ну конечно rtx 4090» и продавец такой «😏»
Вот тут поясню (у меня такая же задача, только у меня тут не озон конечно).
Конфигурация - MySql 8.0 / i7-8700k / 32Gb, на одном складе, 10 items, 100 потоков, 1000 requests
Вариант, когда я беру из БД с SELECT FOR UPDATE, обновляю в C# коде и потом сохраняю в БД - в логах консольки деадлоки все равно есть, retry в EF Core срабатывает, цифры в конце сходятся, скорость примерно 20 rps
Вариант с хранимкой с SELECT FOR UPDATE, в логах консольки деадлоки есть, retry в EF Core срабатывает, цифры в конце сходятся, скорость примерно 60-90 rps
Вариант с хранимкой БЕЗ SELECT FOR UPDATE + без проверки остатка в конце, в логах консольки пусто, цифры в конце сходятся, скорость 400-440 rps
Вариант с хранимкой БЕЗ SELECT FOR UPDATE + с проверкой остатка в конце, в логах консольки пусто, цифры в конце сходятся, скорость 300 rps
И что еще заметил - последние два варианта отрабатывают нормально даже на уровне ReadUncommitted. Меня это смущает, пока не понимаю почему.
Позже пожалуй поставлю postgresql и проверю тоже самое на нем, интересно узнать разницу между дефолтным mysql и дефолтным postgresql
А походу особо и не заморачиваются, как-то был случай с покупкой видеокарты на DNS - все просто подвисло, а потом когда отвисло, они кончились.
Много информации и предположений, хотелось бы уточнить некоторые моменты
Сервис из статьи как раз может стоять после очереди и принимать не заказы, а список ItemId и Qty. И до этого может быть некая пред-обработка (упаковок, китов и так далее). Это же просто облегченный пример, чтобы показать, что обычное железо с простым кодом может сделать 600 заказов в секунду.
Если 600 заказов в секунду на один склад и система справляется - то зачем шардирование? Но все же хорошо бы узнать - сколько там на самом деле у озона, возможно у них больше 600 и их усложненное решение оправдано
В любом случае бутылочным горлышком будет не программный код или БД, а люди, которые бегают по складу и собирают заказ с полок. Сколько надо людских и иных ресурсов и складских площадей, чтобы физически обработать 600 заказов в секунду (это порядка 50 млн за 24 часа) на одном складе?
Со страховым остатком разумеется дельная штука - можете чуть детальней рассказать, как вы его будете пересчитывать, чтобы он не пошел в разнос при параллельной обработке? Есть же базовый пример для общепринятого языка программирования - счетчик с interlock или volatile. Тут придется сделать примерно то же самое. И какой будет механизм отката, когда число выйдет за обозначенные рамки?
"Купим пожиже и за ночь разгребем" - в некоторых случаях может быть определен SLA, типа обработать 200 тыщ заказов за 2-3 часа, а не ночью
И еще момент - конкретно в случае с маркет-плейсом, когда резерв товара происходит до момента оплаты и откат резерва, если оплата не прошла. С точки зрения пользователя и клиентской части - это синхронна обработка. Если обрабатывать через очередь, то надо будет усложнять решение, чтобы дружить синхронного клиента и асинхронную очередь. Поэтому альтернатива с синхронным резервом без очередей - вполне себе альтернатива.
В реальном мире все сложнее, клиент в Москве, а два склада в Москве и Новосибирске - насколько будет дороже и дольше доставка?
Поэтому хорошо бы сначала выбрать оптимальный склад.
Нашел неподтвержденную инфу в интернетах
Это скорее всего физическая отгрузка. Но для программной системы - это порядка 10 заказов в секунду.
В том то и дело - мы точно не знаем. Можно усложнить в стиле озона - сделать батч и перед выполнением посчитать и сравнить кол-ва на складе и во всех заказах. И если точно хватает, то можно и без блокировок.
Теперь интересно, что на это скажет озон. Они кстати не показали в статье результаты нагрузочный тестов.
Наконец-то! Хммм, надо же как вышло... Пожалуй все когда-нибудь заканчивается. Вместе со школьными и студенческими годами ушла эпоха печатных игровых журналов.