|
|
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
Предположим есть сервисы a, b, c. Сервисы b и c имеют два метода пополнить/списать со счёта, у каждого своя БД соответственно. То есть сервис a дергает сначала b списать 100 рублей со счёта xxx, а затем сервис c зачислить 100 рублей на счёт xxx. Как избежать не консистентности в данном случае, когда средства списались в базе b но ещё не зачислены в c? Никакие two phase commit/atomic transactions здесь не помогают, тк коммитятся все равно последовательно базы. Допустим у нас есть сервис d который лезет в базы b и c и строит отчёты, тогда например вполне вероятен вариант, что на счёте xxx будет в данном примере 0 рублей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 20:24 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
no56892Как избежать не консистентности Никак. У тебя распределенная система. Ищи другое решение. Например все сервисы сливают сервису X свое состояние, ты делаешь запрос к X где все всегда консистентно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 20:49 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
Dima T, Тогда логичней было бы вообще объединить сервисы b и c в один, но это все противоречит духу soa, где у каждого сервиса своя база. Прикол в том, что ценной инфы по этому поводу очень мало, обычно пишут типо вам нужны distributed transactions, дак они это тоже не решают. Как вообще на практике такое решается? Надо строить отчёт по данным 20 сервисов например, естественно пока мы читаем оттуда данные туда могут понапихать еще, в результате отчёт будет кривой. Вот как такая штука решается, кроме использования общей базы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 20:56 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
ИМХО у тебя в архитектуре проблемы. Назначь главным b или c, но один. И опрашивай только его, а не объединяй ответы обоих, их нельзя объединять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 21:02 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
Dima Tno56892Как избежать не консистентности Никак. У тебя распределенная система. Ищи другое решение. Например все сервисы сливают сервису X свое состояние, ты делаешь запрос к X где все всегда консистентно. Просто сливать инфу не получится кстати, так как его тоже будут последовательно дергать, ну можно конечно ввести уникальный айдишник транзакции и сколько сервисов должно отчитаться, тогда в чревисе х мы для каждого айдишника тупо накапливает все изменения , все сервисы по этой транзакции от читались - ок сливаем в базу сервиса х, вот там консистентности будет. Но это ж какая нагрузка , явный боттлнек, ушли от монолита пришли к такому...хотя как вариант интересный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 21:02 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
Вот как бы можно было сделать теоретически: Пусть есть n сервисов и менеджер транзакций t. Шаги коммита: 1.транзанкш менеджер мультикастом шлёт precommit n сервисам, они отвечают ок 2. Транзакшн менеджер шлёт мультикастом commit-lock всем сервисам, что означает поставить все чтения/записи данных, которые затронули изменения в данной транзакции в очередь и применить эти изменения, получить подтверждение 3. Транзакшн менеджер шлёт мультикастом всем unlock Вот здесь норм должно быть, только это уже совсем не rdms.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 21:45 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
no56892, Не, это тоже неконсистентно, тк если сервис1 в состоянии lock-commit, а до второго ещё оно не дошло, то если какойлибо третий обратится в этот момент, то в сервисе1 он встанет в очередь и потом получит новое значение, а в сервисе2 успеет достать старое ещё до lock-commit ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 22:08 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
no56892, можно в сервисе "a" завести ленту бизнес операций типа проводки. а сервисы "b", "c" синхронизировать с ней. Можно даже постфактумом. Главное чтобы ошибка или непринятие пополнения или списания фиксировалась в журнале "a" тоже как откат или коррекция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 22:40 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
mayton, Это как раз таки решает two phase commit. Проблема то не в этом, а в data consistency. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 22:50 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
Тогда забей. Консистентность такого уровня о котором ты говоришь может обеспечить разве что Oracle RAC. Или у тебя своё (другое) определение консистентности в рамках имеющейся инфраструктуры и его (это понимание) необходимо как-то определить и формально описать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 22:54 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
mayton, Oracle RAC это жеж вроде как обычный master-slave, совсем не по soa'совски. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 23:02 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
В RAC нету master-slave. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 23:14 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
mayton, Ну все равно это не подходит, тк подразумевает объединение двух сервисов в один с общей базой и так в итоге приходим к монолиту... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 23:39 |
|
||
|
soa eventual consistency
|
|||
|---|---|---|---|
|
#18+
Здесь в рассуждениях где-то есть неточность. Цитирую Допустим у нас есть сервис d который лезет в базы b и c и строит отчёты, тогда например вполне вероятен вариант, что на счёте xxx будет в данном примере 0 рублей. Вот с этого места - неверно. Никакой сервис d не может ходить в базы b и с и строить отчеты. Нет единой точки где есть сведения счетчиков транзакций. Пожалуй эта точка существует только со стороны наблюдателя который сидит в сервисе A. И то при условии что мы смотрим сквозь контекст транзакционного менеджера который делает проводки. Поэтому и проводки и отчеты можно делать только со стороны сервиса A. Если на сервисы b,c смотреть отдельно со стороны то в классификации CAP мы будем иметь полную AP модель. Тоесть доступность есть (A). И есть разделение (P) (b,c разделены и полностью независимы) а consistency - остуствтует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2017, 23:59 |
|
||
|
|
start [/forum/topic.php?fid=16&msg=39417418&tid=1340465]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
203ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 263ms |
| total: | 561ms |
| 0 / 0 |
