N
Nikita Ilin
Так а счётчик книги не надо обновить сто раз?
ну да, и?
Size: a a a
2020 November 16
NI
ну да, и?
Ну получается, что все 100 запросов ломятся к одному агрегату
NI
И ещё вопрос, при таком подходе со временем часть книг будут закончены и удалены (причём где-то в середине) и новым пользователям придётся как-то пропускать некоторые номера книг. Заранее непонятно, какой номер книги будет следующим для пользователя
N
ну да. аггрегат - книга, которая умеет выдавать "следующую запись". В зависимости от реализации она выдает следующую запись из базы, инкрементит свой индекс при каждом запросе или еще что. инкремент - дешевая атомарная неблокирующая операция. По большому счету ее можно даже в базе не делать - просто крутить связанный список в сервисе.
N
Nikita Ilin
И ещё вопрос, при таком подходе со временем часть книг будут закончены и удалены (причём где-то в середине) и новым пользователям придётся как-то пропускать некоторые номера книг. Заранее непонятно, какой номер книги будет следующим для пользователя
новым пользователям назначается первая непройденная кига или же заводится аггрегат книжного хранилища, который умеет в операцию "следующая непройденная книга"
N
хотя я бы хотел это оставить в аггрегатах книг - просто каждый из них знает следующего и может самоустраниться из этой цепочки, когда внутри него все пройдено.
NI
хотя я бы хотел это оставить в аггрегатах книг - просто каждый из них знает следующего и может самоустраниться из этой цепочки, когда внутри него все пройдено.
Ну да, что-то такое... При удалении он может соседние книги обновить, к примеру
SP
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Саги
NI
Получается связанный список из агрегатов-книг
N
Nikita Ilin
Получается связанный список из агрегатов-книг
да. вполне в духе учебного примера :)
SP
Nikita Ilin
Получается связанный список из агрегатов-книг
А тип 10 к юзеров мы игнорим?
N
А тип 10 к юзеров мы игнорим?
почему?
SP
Ну тоесть у тебя ж там по сути резервация идет
N
Ну тоесть у тебя ж там по сути резервация идет
неа, в каждой книге 5000 параграфов, каждый из которых надо пройти как минимум дважды
NI
да. вполне в духе учебного примера :)
На самом деле логика этих апрувов может быть намного сложнее, но смысл с точки зрения нагрузки такой же
SP
Тысяча челов тыкает "следующий", система должна каждому выдать по параграфу
SP
При этом один и тот же параграф можно выдать двоим
SP
С описанными агрегатами у тебя система будет педалить безбожно
N
С описанными агрегатами у тебя система будет педалить безбожно
аргументируй, в каком месте? Основная проблема - высококонкуретный доступ - решается использованием неблокирующих операций. Тут можно накосячить только в реализации.
YG
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)
Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.
Пользователи проверяют параграфы на достоверность.
Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).
Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.
Когда все параграфы документа пройдены, документ считается выполненным.
При этом каждый раз пользователю должен выдаваться параграф из документа, который имеет минимальное количество параграфов для проверки (максимальное прогресс).
Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Возможно что то вроде этого.
Проверяющий: [ {непроверенные док-ты: кол-во свободных(непроверенных) параграфов} ]
Документ: [ Параграф: {проверка1(свободен/занят/valid/invalid), проверка2(свободен/занят/valid/invalid)} ]
Мы бьем на две части.
Сначала находим документ, который текущий юзер еще не проверял и который имеет наименьшее кол-во непроверенных параграфов.
А затем пытаемся захватить параграф в этом документе.
Проверяющий: [ {непроверенные док-ты: кол-во свободных(непроверенных) параграфов} ]
Документ: [ Параграф: {проверка1(свободен/занят/valid/invalid), проверка2(свободен/занят/valid/invalid)} ]
Мы бьем на две части.
Сначала находим документ, который текущий юзер еще не проверял и который имеет наименьшее кол-во непроверенных параграфов.
А затем пытаемся захватить параграф в этом документе.