Никогда не теряя методы данных

Question

Мне любопытно узнать о методах, используемых для построения системы, в которой обеспечение того, чтобы никакие данные не были потеряны, являлось первостепенным приоритетом. В качестве упрощенного примера, что делает финансовое учреждение, чтобы убедиться, что когда деньги переводятся между счетами, как только они снимаются с одного счета, они, без сомнения, помещаются на другой счет. Я не столько ищу конкретные методы, как транзакции с базой данных, но более масштабные, более архитектурные концепции, например, как данные сохраняются, если сервер выходит из строя, или в очереди заканчивается свободное место, или что-то в этом роде.

Если бы кто-то мог указать мне на книги или статьи, я был бы очень благодарен.

Answer 1

Вы должны прочитать о Банкомате , Обработка транзакций в режиме онлайн и другие темы о шифровании данных, также подумайте об использовании HTTPS, если вы думаете о веб-сайтах.

Answer 2

Как вы уже упоминали, существуют различные механизмы (например, транзакции) для обеспечения того, что программный «рукопожатие» является надежным и успешно завершается.

Архитектурно - да, наличие двух копий материала дает вам избыточность, котораяпомогает не потерять вещи.кроме этого:

• Очистить процессы: люди должны точно знать, куда направляется информация - как в солнечные дневные сенарио, так и когда коричневый материал попадает в вентилятор.Наличие данных, но не возможность их найти или распознать - это так же плохо, как потерять их.Чем яснее (и лучше задокументированы) ваши процессы, тем лучше.
• Согласованность: автоматизация, очевидно, лучше, чем случайная человеческая ошибка.
• Чтобы конкретно ответить на ваш вопрос - но вышеизложенные пункты следует повторить впонятная архитектура и дизайн, которые явно разделяют интересы.
• Максимально уменьшите количество точек отказа.
• Сосредоточьте внимание на областях повышенного риска.
• Используйте проверенныеметоды (я думаю, это то, что вы на самом деле просите).
• Делайте вещи максимально простыми.

Я работал над архитектурой решения для готового документасистема управления некоторое время назад;без потери данных был большой драйвер.Система была развернута на национальном уровне, поэтому она была многосайтовой с точки зрения «региональных» кешей для обслуживания локальных пользователей и реальных «центров обработки данных».Некоторые интересные моменты:

• Все компоненты (где это возможно) были развернуты на виртуальных блоках, которые были привязаны к SAN, поэтому в случае сбоя физического хоста мы могли бы быстрее восстановить сервис,С точки зрения потери данных это означает, что пользователи с большей вероятностью смогут использовать защищенную систему, чем хранить данные локально, если система не работает.
• Кроме того, SAN считался более безопасным, чем локальные диски.
• Вышеприведенное было частью существующей установки, поэтому для Ops ничего нового не нужно изучать.
• Отказоустойчивый сайт, с репликацией.Это не было в режиме реального времени, и было дополнено журналами транзакций в базах данных.

Я думаю, что ничего из этого не является программным центром, но я думаю, что всехорошая архитектура программного обеспечения / принципы проектирования, которые мы используем, помогли мне мыслить.

Answer 3

в случае с примером банка, каждый банк будет вести запись для каждой транзакции, указывая, что, сколько и куда, откуда и сколько и их порядок времени

, чтобы позже, если естьпроблема, вы сравниваете два журнала транзакций, если они не совпадают, вы можете идентифицировать отсутствующие транзакции

, это также покрывает проблему, что один банк не может доверять другому, чтобы вести записи для него

какони перепроверяют это почти протокол распределенных транзакций

Answer 4

Возможно, вы захотите прочитать о транзакциях XA или X / Open, которые могут координировать несколько систем, включая базы данных, очереди и многое другое, в транзакции, подобные ACID DB.но я слышал, что это может быть дорого в плане задержки и в вычислительном отношении.Но опять же, сколько стоит ваша целостность данных?

http://en.wikipedia.org/wiki/X/Open_XA

Answer 5

Все может действительно сводиться к наличию одинаковых данных в двух местах; от кода, который хранит кэш до передачи данных, вплоть до избыточности сервера.

Единственный способ убедиться, что вы не потеряете что-то, - это иметь несколько его копий.

Answer 6

Основная техника - это устранение любой точки отказа.Все, что может потерпеть неудачу в вашей настройке, должно иметь резервную копию или несколько резервных копий.От нескольких коммутаторов, серверов, ИБП, жестких дисков и т. Д. Базы данных постоянно реплицируются, а данные резервируются и хранятся за пределами площадки на случай пожара или другой катастрофы, которая может угрожать зданию.