консистентность нотификаций
Friday, 16 May 2014 18:25![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gns_uaМне на карту пришло два перечисления на две разные суммы. В sms и почту пришло два уведомления от банка: на одну сумму и на вторую. В уведомлении показывается также текущий баланс. В двух сообщениях баланс одинаковый, и именно такой, как если бы к предыдущему остатку добавили общую сумму пополнения.
Понятно, как это произошло - две транзакции выполнены виртуально одновременно. Фактически, конечно, они сериализованы, но обе прошли к тому моменту, когда сервер уведомлений запросил текущий баланс, готовя к отправке сообщение о первой.
Вот почему бы не включить в пакет данных для асинхронного нотификатора всю необходимую информацию? Триггеры работают внутри транзакции, например. Даже редисовский optimistic locking позволяет получить результирущее состояние in single shot, а больше ничего и не нужно.
Представьте, что технический мониторинг отправляет алерт, но пока обрабатывается очередь, сервис успевает починиться! Либо я получу алерт с состоянием OK и впаду в некоторую задумчивость, либо финальный обработчик будет too smart и отправит сразу recovery, и я опять же впаду в некоторую задумчивость, получив рековери без алерта, либо совсемумный отмороженный обработчик молча проигнорирует.
Хорошо если игнорирование short outages хотя бы было design decision, то есть, обдумывалась возможность такой ситуации. Но правильным, с моей точки зрения, будет отправить один алерт и одно рековери.
А когда это банк, когда речь о бабках, и эти сообщения о движении средств, допустим, обрабатываются какой-то своей системой? На ровном месте исходно имеющаяся strong consistency превращается в eventual.
Понятно, как это произошло - две транзакции выполнены виртуально одновременно. Фактически, конечно, они сериализованы, но обе прошли к тому моменту, когда сервер уведомлений запросил текущий баланс, готовя к отправке сообщение о первой.
Вот почему бы не включить в пакет данных для асинхронного нотификатора всю необходимую информацию? Триггеры работают внутри транзакции, например. Даже редисовский optimistic locking позволяет получить результирущее состояние in single shot, а больше ничего и не нужно.
Представьте, что технический мониторинг отправляет алерт, но пока обрабатывается очередь, сервис успевает починиться! Либо я получу алерт с состоянием OK и впаду в некоторую задумчивость, либо финальный обработчик будет too smart и отправит сразу recovery, и я опять же впаду в некоторую задумчивость, получив рековери без алерта, либо совсем
Хорошо если игнорирование short outages хотя бы было design decision, то есть, обдумывалась возможность такой ситуации. Но правильным, с моей точки зрения, будет отправить один алерт и одно рековери.
А когда это банк, когда речь о бабках, и эти сообщения о движении средств, допустим, обрабатываются какой-то своей системой? На ровном месте исходно имеющаяся strong consistency превращается в eventual.
