У меня есть вопрос, связанный с проектированием системы.
Предположим, у нас есть услуга, которая принимает баллы от продавцов на основе платежа, выполненного с помощью какого-либо кошелька. Как пользователь Uber использует PayPal для оплаты ; Тогда в этом случае Uber вызывает этот API (выставленный PayPal), чтобы дать пользователю несколько баллов, поскольку он потратил немного денег, используя PayPal (например, если пользователь потратил 500 рупий, то Uber вызывает этот API с 5 баллами для этого пользователя ).
Этот API-интерфейс принимает следующие поля в качестве входных данных {идентификатор продавца, идентификатор запроса, идентификатор пользователя, количество выделенных точек}
Таким образом, по мере увеличения масштаба у нас может быть множество микроуслуг который может принимать запросы.
Теперь в БД мы ведем таблицу, называемую точками, которая имеет следующие поля
точек (идентификатор продавца, идентификатор запроса, идентификатор пользователя, количество не выделенных точек, количество оставшихся точек , обновлено в, Создано в)
Обратите внимание, что идентификатор запроса генерируется продавцом, и есть вероятность, что Запрос продавца уже использовался, и в этом случае мы должны сообщить продавцу, что следует использовать другой запрос. Вы можете предположить, что торговец для своего бухгалтерского учета хранит таблицу, в которой первичный ключ является идентификатором запроса.
Так что здесь, в таблице баллов, мы можем предположить, что идентификатор продавца и идентификатор запроса могут рассматриваться как первичный ключ.
1). Теперь, если продавец делает запрос, и этот запрос занимает некоторое время на стороне сервера, и продавец хочет знать, что случилось с этим запросом. Этот запрос может быть где-нибудь в системе. Он может зависнуть где-то в каком-то потоке. Ожидание в очередь за его сроком для выполнения. Как мы можем выполнить sh this.
Я думал об этом, мы можем использовать какое-то хранилище значений ключа. Как только приходит запрос на обновление таблицы точек , Этот кэш значения ключа обновляется; ключом является merchantid@requestid с ttl в качестве времени ожидания запроса. Так что на это можно ссылаться.
2). Теперь, что происходит, когда пользователь u1 имеет некоторые записи, такие как
идентификатор продавца, идентификатор запроса, идентификатор пользователя, количество точек, оставшиеся точки
m1, r1, u1, 10, 0
m1, r2, u1, 15, 0
m2, r1, u1, 25, 0
m3, r1, u1, 10, 0
Теперь пользователь У u1 есть 60 очков. u1 хочет использовать эти очки. Теперь 2 запроса попадают в систему одновременно. один запрос для u1 хочет использовать 40 баллов, а другой запрос хочет использовать 30 баллов. Они попадают в разные сервисы. Так что, когда они запрашивают базу данных, каждый запрос может видеть, что у них есть достаточные значения, и в довершение всего будет быть полями, в которых у вас есть значения, оставшиеся поля, которые будут обновлены. Как мы можем обработать регистр оставшихся точек.
Как обрабатывать такой случай?
И как мы можем обрабатывать случаи, например, где 2 запроса попали в службы в parellel.
Заранее спасибо.