Size: a a a

Software Design/Architecture/Zen

2020 November 16

N

Nekt in Software Design/Architecture/Zen
Nikita Ilin
Так а счётчик книги не надо обновить сто раз?
ну да, и?
источник

NI

Nikita Ilin in Software Design/Architecture/Zen
Nekt
ну да, и?
Ну получается, что все 100 запросов ломятся к одному агрегату
источник

NI

Nikita Ilin in Software Design/Architecture/Zen
И ещё вопрос, при таком подходе со временем часть книг будут закончены и удалены (причём где-то в середине) и новым пользователям придётся как-то пропускать некоторые номера книг. Заранее непонятно, какой номер книги будет следующим для пользователя
источник

N

Nekt in Software Design/Architecture/Zen
ну да. аггрегат - книга, которая умеет выдавать "следующую запись". В зависимости от реализации она выдает следующую запись из базы, инкрементит свой индекс при каждом запросе или еще что.  инкремент - дешевая атомарная неблокирующая операция. По большому счету ее можно даже в базе не делать - просто крутить связанный список в сервисе.
источник

N

Nekt in Software Design/Architecture/Zen
Nikita Ilin
И ещё вопрос, при таком подходе со временем часть книг будут закончены и удалены (причём где-то в середине) и новым пользователям придётся как-то пропускать некоторые номера книг. Заранее непонятно, какой номер книги будет следующим для пользователя
новым пользователям назначается первая непройденная кига или же заводится аггрегат книжного хранилища, который умеет в операцию "следующая непройденная книга"
источник

N

Nekt in Software Design/Architecture/Zen
хотя я бы хотел это оставить в аггрегатах книг - просто каждый из них знает следующего и может самоустраниться из этой цепочки, когда внутри него все пройдено.
источник

NI

Nikita Ilin in Software Design/Architecture/Zen
Nekt
хотя я бы хотел это оставить в аггрегатах книг - просто каждый из них знает следующего и может самоустраниться из этой цепочки, когда внутри него все пройдено.
Ну да, что-то такое... При удалении он может соседние книги обновить, к примеру
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)

Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.

Пользователи проверяют параграфы на достоверность.

Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).

Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.

Когда все параграфы документа пройдены, документ считается выполненным.

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

Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Саги
источник

NI

Nikita Ilin in Software Design/Architecture/Zen
Получается связанный список из агрегатов-книг
источник

N

Nekt in Software Design/Architecture/Zen
Nikita Ilin
Получается связанный список из агрегатов-книг
да. вполне в духе учебного примера :)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Nikita Ilin
Получается связанный список из агрегатов-книг
А тип 10 к юзеров мы игнорим?
источник

N

Nekt in Software Design/Architecture/Zen
Sergey Protko
А тип 10 к юзеров мы игнорим?
почему?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Ну тоесть у тебя ж там по сути резервация идет
источник

N

Nekt in Software Design/Architecture/Zen
Sergey Protko
Ну тоесть у тебя ж там по сути резервация идет
неа, в каждой книге 5000 параграфов, каждый из которых надо пройти как минимум дважды
источник

NI

Nikita Ilin in Software Design/Architecture/Zen
Nekt
да. вполне в духе учебного примера :)
На самом деле логика этих апрувов может быть намного сложнее, но смысл с точки зрения нагрузки такой же
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Тысяча челов тыкает "следующий", система должна каждому выдать по параграфу
источник

SP

Sergey Protko in Software Design/Architecture/Zen
При этом один и тот же параграф можно выдать двоим
источник

SP

Sergey Protko in Software Design/Architecture/Zen
С описанными агрегатами у тебя система будет педалить безбожно
источник

N

Nekt in Software Design/Architecture/Zen
Sergey Protko
С описанными агрегатами у тебя система будет педалить безбожно
аргументируй, в каком месте? Основная проблема - высококонкуретный доступ - решается использованием неблокирующих операций. Тут можно накосячить только в реализации.
источник

YG

Yury Golikov in Software Design/Architecture/Zen
Nikita Ilin
Всем привет!
Решаю кейс и пытаюсь спроектировать агрегаты, нужна помощь, может, кто сталкивался с такой задачей)

Имеются книги, каждая из которых содержит в среднем 5000 параграфов.
Всего около 1 млн книг.
Каждая из книг может быть просмотрена пользователем максимум один раз.

Пользователи проверяют параграфы на достоверность.

Процесс выглядит следующим образом:
Пользователь жмёт кнопку GetNextItem, получает новый параграф, проверяет его на достоверность и жмёт либо valid, либо invalid. Далее цикл повторяется. В следующий раз пользователь получит параграф из другого документа (пользователь может посмотреть максимум один параграф из одного документа).

Когда у параграфа два подтверждения -> параграф считается правильным. Когда два раза invalid - считается invalid соответсвенно.

Когда все параграфы документа пройдены, документ считается выполненным.

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

Всё это похоже на очередь, но нужно проверять на уникальность участников.
У кого есть какие-то мысли как правильно спроектировать агрегаты, так чтобы не было много проблем с конкурентным доступом, т.к. ожидается большое количество конкурентных пользователей (10 000)?
Возможно что то вроде этого.

Проверяющий: [  {непроверенные док-ты: кол-во свободных(непроверенных) параграфов}  ]
Документ: [  Параграф: {проверка1(свободен/занят/valid/invalid), проверка2(свободен/занят/valid/invalid)}  ]

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