Как писал выше, не делается перевод со счета на счет в одной БД транзакции.
Заблокировали сумму на счету клиента. Добавили сообщение о начислении магазину. — одна системная транзакция
Выбрали сообщение. Сделали фин. обработку. Зачислили деньги магазину — вторая системная транзакция.
Фин. обработки могут быть достаточно сложными, например, комиссия для магазина может уменьшаться после некоторого объема переводов.
поток транзакций не равномерно между счетами же делится, какие-то более активные
нет потока со счета на счет во фронтальной системе финансового процессинга.
ИМХО, вы слабо представляете как устроен финансовый процессинг. Ну нельзя переводить деньги со счета на счет в одной БД транзакции, т.к. счет становиться узким местом.
а как шардирование поможет балансировать нагрузку?
Выделили атрибуты для шардирования и распределили нагрузку на узлы.
Но от процессинга требуется способность максимально быстро проводить транзакции, так как основной его пользователь не Alice которая отправила Bob 10 рублей, а онлайн магазины с тысячами и десятками тысяч клиентов, которые при падении конверсии, из-за аварий или тормозов, без раздумий уйдут к конкурентами. (Собственно это, по-видимому, основная причина, почему частные процессинги не может сожрать биткойн).
ИМХО, обоснование для статьи слабовато.
Что понимается под термином «процессинг» в контексте интернет-магазина?
И как это связано с балансом клиента?
>При условии, что все транзакции одного и того же клиента попадают на один и тот же хост,
Нет. Узел, который будет обрабатывать транзакцию индивидуален для каждой отдельной транзакции, так как рассчитывается от хеша каждой предыдущей обработанной транзакции. (если узлов не много, то возможны частные случаи когда это будет один и тот же узел, то только из-за того, что хеши предыдущей транзакции и предпредыдущей будут находиться в DHT диапазоне этого узла)
Почему просто не балансировать нагрузку через шардирование (платежная система, БИНы карты и т.п.)?
Я не правил ISO. Я переписал net_tg3.v00 в корне USB флешки с инсталляцией. И все.
Конечно правка net_tg3.v00 может выльется в цирк, т.к. используется vmtar для архивирования net_tg3.v00, но можно попробовать поискать утилиты для vmtar. Я сам перепаковывал net_tg3.v00 в по ходу инсталляции, чтобы сохранить результат потребуется флешка размером не более 2Гб, отформатированная под FAT.
Заблокировали сумму на счету клиента. Добавили сообщение о начислении магазину. — одна системная транзакция
Выбрали сообщение. Сделали фин. обработку. Зачислили деньги магазину — вторая системная транзакция.
Фин. обработки могут быть достаточно сложными, например, комиссия для магазина может уменьшаться после некоторого объема переводов.
нет потока со счета на счет во фронтальной системе финансового процессинга.
ИМХО, вы слабо представляете как устроен финансовый процессинг. Ну нельзя переводить деньги со счета на счет в одной БД транзакции, т.к. счет становиться узким местом.
Выделили атрибуты для шардирования и распределили нагрузку на узлы.
ИМХО, обоснование для статьи слабовато.
Что понимается под термином «процессинг» в контексте интернет-магазина?
И как это связано с балансом клиента?
Почему просто не балансировать нагрузку через шардирование (платежная система, БИНы карты и т.п.)?
Нет, не надо. Начисления делаются в бэке, там нет таких требований на ответ.
Конечно правка net_tg3.v00 может выльется в цирк, т.к. используется vmtar для архивирования net_tg3.v00, но можно попробовать поискать утилиты для vmtar. Я сам перепаковывал net_tg3.v00 в по ходу инсталляции, чтобы сохранить результат потребуется флешка размером не более 2Гб, отформатированная под FAT.