Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Вопросы:
Чем принципиально такой вид load balancing-а отличается от обычного применения affinity (sticky sessions) на load balancer-ах?
При условии, что все транзакции одного и того же клиента попадают на один и тот же хост, то блокчейны по сути тут излишни — один нод сам отлично умеет контролировать целостность redo log. Непонятна польза блокчейнов при репликации — что мешает делать two-way acknowledgement между нодами?..
Не особо понятно откуда нод понимает, что у него устарела версия цепочки. Из чего «из этого» следует?
Чем принципиально такой вид load balancing-а отличается от обычного применения affinity (sticky sessions) на load balancer-ах?
При условии, что все транзакции одного и того же клиента попадают на один и тот же хост, то блокчейны по сути тут излишни — один нод сам отлично умеет контролировать целостность redo log. Непонятна польза блокчейнов при репликации — что мешает делать two-way acknowledgement между нодами?..
Из этого следует что если запрос на транзакцию поступит на «отстающий» узел, где будет устаревшая версия цепочки, то это запрос на транзакцию будет «наведен» на тот узел, где уже был создан и сохранена более свежая транзакция, т.е. хеши последних транзакций точно не совпадут, и запрос будет отклонен. Ветвления цепочки не произойдет.
Не особо понятно откуда нод понимает, что у него устарела версия цепочки. Из чего «из этого» следует?
>все транзакции одного и того же клиента попадают на один и тот же хост,
>При условии, что все транзакции одного и того же клиента попадают на один и тот же хост,
Нет. Узел, который будет обрабатывать транзакцию индивидуален для каждой отдельной транзакции, так как рассчитывается от хеша каждой предыдущей обработанной транзакции. (если узлов не много, то возможны частные случаи когда это будет один и тот же узел, то только из-за того, что хеши предыдущей транзакции и предпредыдущей будут находиться в DHT диапазоне этого узла)
>Чем принципиально такой вид load balancing-а отличается от обычного применения affinity (sticky sessions) на load balancer-ах
мне трудно ответить на этот вопрос, так как я общего не вижу. Можете по пунктам перечислить, если не сложно?
>Не особо понятно откуда нод понимает, что у него устарела версия цепочки. Из чего «из этого» следует
из того, что хеш последней обработанной транзакции на узле, который отправил в сеть запрос не транзакцию (этот хеш в запросе) отсутствует на узле-получателе, который должен транзакцию обработать.
>При условии, что все транзакции одного и того же клиента попадают на один и тот же хост,
Нет. Узел, который будет обрабатывать транзакцию индивидуален для каждой отдельной транзакции, так как рассчитывается от хеша каждой предыдущей обработанной транзакции. (если узлов не много, то возможны частные случаи когда это будет один и тот же узел, то только из-за того, что хеши предыдущей транзакции и предпредыдущей будут находиться в DHT диапазоне этого узла)
>Чем принципиально такой вид load balancing-а отличается от обычного применения affinity (sticky sessions) на load balancer-ах
мне трудно ответить на этот вопрос, так как я общего не вижу. Можете по пунктам перечислить, если не сложно?
>Не особо понятно откуда нод понимает, что у него устарела версия цепочки. Из чего «из этого» следует
из того, что хеш последней обработанной транзакции на узле, который отправил в сеть запрос не транзакцию (этот хеш в запросе) отсутствует на узле-получателе, который должен транзакцию обработать.
>При условии, что все транзакции одного и того же клиента попадают на один и тот же хост,
Нет. Узел, который будет обрабатывать транзакцию индивидуален для каждой отдельной транзакции, так как рассчитывается от хеша каждой предыдущей обработанной транзакции. (если узлов не много, то возможны частные случаи когда это будет один и тот же узел, то только из-за того, что хеши предыдущей транзакции и предпредыдущей будут находиться в DHT диапазоне этого узла)
Почему просто не балансировать нагрузку через шардирование (платежная система, БИНы карты и т.п.)?
а как шардирование поможет балансировать нагрузку?
поток транзакций не равномерно между счетами же делится, какие-то более активные, какие-то менее, соответственно какие-то шарды будут больше нагружены, а какие-то меньше. это, конечно, лучше чем ничего, но на балансировку не тянет, как минимум из-за отсутствия возможности управлять распределением нагрузки.
поток транзакций не равномерно между счетами же делится, какие-то более активные, какие-то менее, соответственно какие-то шарды будут больше нагружены, а какие-то меньше. это, конечно, лучше чем ничего, но на балансировку не тянет, как минимум из-за отсутствия возможности управлять распределением нагрузки.
поток транзакций не равномерно между счетами же делится, какие-то более активные
нет потока со счета на счет во фронтальной системе финансового процессинга.
ИМХО, вы слабо представляете как устроен финансовый процессинг. Ну нельзя переводить деньги со счета на счет в одной БД транзакции, т.к. счет становиться узким местом.
а как шардирование поможет балансировать нагрузку?
Выделили атрибуты для шардирования и распределили нагрузку на узлы.
>ИМХО, вы слабо представляете как устроен финансовый процессинг. Ну нельзя переводить деньги со счета на счет в одной БД транзакции, т.к. счет становиться узким местом.
пожалуйста расскажите почему и как с этим бороться?
Что в данном случае «атрибут шардирования», не могу нагуглить вменяемого определения?
пожалуйста расскажите почему и как с этим бороться?
Что в данном случае «атрибут шардирования», не могу нагуглить вменяемого определения?
Как ведет себя система при split brain и падениях отдельных узлов?
Транзакции, которые маршрутизируются на упавшие узлы дропаются. (хотя возможны варианты)
Сплитбрейн в привычном смысле здесь не особо возможен, но если имеется ввиду форк цепочки, то чтоб это произошло нужно начать переназначать DHT диапазоны, но «само» это случиться не может. Но если даже и случится, то по цепочкам можно проследить когда это случилось и какие транзакции в таком состоянии были проведены. Транзакций таких вряд ли будет много, так как из-за неконсистентности цепочек проводка встанет и все.
Сплитбрейн в привычном смысле здесь не особо возможен, но если имеется ввиду форк цепочки, то чтоб это произошло нужно начать переназначать DHT диапазоны, но «само» это случиться не может. Но если даже и случится, то по цепочкам можно проследить когда это случилось и какие транзакции в таком состоянии были проведены. Транзакций таких вряд ли будет много, так как из-за неконсистентности цепочек проводка встанет и все.
проводка встанет только для тех цепочек у которых произошел форк
Здесь на помощь может придти занятная особенность условия работы процессинга. Транзакции, на списание средств производятся в нем, в 95-99% случаев живыми людьми, которым моментальная готовность системы к следующей транзакции не особо нужна (10-60с).
А как насчет транзакций на зачисление средств, по ним отдельную систему делать?
Не уверен, что правильно понял суть вопроса, можно пожалуйста чуть подробней?
Например, возьмем случай интернет-эквайринга, когда подключенный к банку интернет-магазин имеет в нем один счет, на который поступает довольно большое количество платежей, для которых задержка 10-60 сек критична? Например счёт какого нибудь мобильного оператора или популярной онлайн-игры.
10-60 секунд это время репликации всей процессинговой сети, т.е. зависит от сети между узлами.
по поводу входящих средств, они «болтаются» как отправленные, и время их попадания на все узлы(когда они могут быть задействованы в транзакциях) зависит от времени репликации в сети.
то есть практически, если мы хотим со счета с большим количеством входящих(на этот счет) транзакций перевести средства, то мы имеем достаточно информации, чтоб определить на каком узле будет такая транзакация проведена. Соответственно, можем отправить туда запрос о том, сколько в конкретный момент средств доступно (сколько входящих транзакций среплицировалось на этот узел), и оценивать текущий баланс счета-источника (на который входящие средства перечисляются).
по поводу входящих средств, они «болтаются» как отправленные, и время их попадания на все узлы(когда они могут быть задействованы в транзакциях) зависит от времени репликации в сети.
то есть практически, если мы хотим со счета с большим количеством входящих(на этот счет) транзакций перевести средства, то мы имеем достаточно информации, чтоб определить на каком узле будет такая транзакация проведена. Соответственно, можем отправить туда запрос о том, сколько в конкретный момент средств доступно (сколько входящих транзакций среплицировалось на этот узел), и оценивать текущий баланс счета-источника (на который входящие средства перечисляются).
А как насчет транзакций на зачисление средств, по ним отдельную систему делать?
Нет, не надо. Начисления делаются в бэке, там нет таких требований на ответ.
Но от процессинга требуется способность максимально быстро проводить транзакции, так как основной его пользователь не Alice которая отправила Bob 10 рублей, а онлайн магазины с тысячами и десятками тысяч клиентов, которые при падении конверсии, из-за аварий или тормозов, без раздумий уйдут к конкурентами. (Собственно это, по-видимому, основная причина, почему частные процессинги не может сожрать биткойн).
ИМХО, обоснование для статьи слабовато.
Что понимается под термином «процессинг» в контексте интернет-магазина?
И как это связано с балансом клиента?
например, есть некий qiwipaypalwebmoney, в котором есть счета у магазина и у клиента, и клиент делает перевод магазину.
Как писал выше, не делается перевод со счета на счет в одной БД транзакции.
Заблокировали сумму на счету клиента. Добавили сообщение о начислении магазину. — одна системная транзакция
Выбрали сообщение. Сделали фин. обработку. Зачислили деньги магазину — вторая системная транзакция.
Фин. обработки могут быть достаточно сложными, например, комиссия для магазина может уменьшаться после некоторого объема переводов.
Заблокировали сумму на счету клиента. Добавили сообщение о начислении магазину. — одна системная транзакция
Выбрали сообщение. Сделали фин. обработку. Зачислили деньги магазину — вторая системная транзакция.
Фин. обработки могут быть достаточно сложными, например, комиссия для магазина может уменьшаться после некоторого объема переводов.
Если относительно логики транзакции, то можно разные вещи реализовать на шаге зачисления.
В описываемой системе, входящие средства на счет магазина существуют только как исходящие транзакции со счетов клиентов, (т.е информация он них есть, их всегда можно посчитать и по ним какую-то аналитику провести).
А технически они прописываются в баланс магазина ( в последнюю транзакцию цепочки магазина), когда магазин создает исходящую транзакцию на вывод, и вот тогда все финконтроли и комиссии и могут быть проведены, что замечательно, отдельно от процесса покупки.
Или может я не понимаю деталей и нужна синхронная финобработка в момент оплаты?
В описываемой системе, входящие средства на счет магазина существуют только как исходящие транзакции со счетов клиентов, (т.е информация он них есть, их всегда можно посчитать и по ним какую-то аналитику провести).
А технически они прописываются в баланс магазина ( в последнюю транзакцию цепочки магазина), когда магазин создает исходящую транзакцию на вывод, и вот тогда все финконтроли и комиссии и могут быть проведены, что замечательно, отдельно от процесса покупки.
Или может я не понимаю деталей и нужна синхронная финобработка в момент оплаты?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распределенный криптопроцессинг