M
Нет ну это 5
Size: a a a
2020 September 08
M
Ору сижу
M
M
@emmanuelGoldstein а ты и не увидишь
M
Потому что блокчейн по своей сути это конкретное решение проблемы путим использования распределенных технологий
M
Все попытки втолкать куда то еше блокчейн тоже самое как пытаться прикрутить к word 3д редактор и называть это новым инструментом моделирования
CD
redis это и есть in-memory db, лол
а как он держит консистентность при мутациях без хдд? или мутации редкие и он логать успевает?
EG
а как он держит консистентность при мутациях без хдд? или мутации редкие и он логать успевает?
Он в фоне пишет на хдд (и точно так же в фоне реплицируется)
Но для этой конкретной задачи не очень страшно потерять пару секунд данных, они восстановятся за те же пару секунд
Но для этой конкретной задачи не очень страшно потерять пару секунд данных, они восстановятся за те же пару секунд
CD
Он в фоне пишет на хдд (и точно так же в фоне реплицируется)
Но для этой конкретной задачи не очень страшно потерять пару секунд данных, они восстановятся за те же пару секунд
Но для этой конкретной задачи не очень страшно потерять пару секунд данных, они восстановятся за те же пару секунд
а, понял
EG
Главное, чтобы ответы не лагали и чтобы мы не теряли совсем всё при переключении на другой хост
CD
это что-то типа центра звезды по топологии что ли? данные на узлах есть, а задача - синхронизировать?
M
Это я называю всрали время
M
Когда есть задача вся ее сложность в локальной специфике
M
А технологии всем известные
M
В итоге выходит примерно как "я на работе в интерфейсе пару кнопок сделал по mvc", только с получасовой историей про то как логику собирали фиксили баг и долбили в сраку аналитиков что и а и б мы реализовать не можем птамцшо не адекватно
M
Практическая польза индустрии 0, сложность: типикал работа, эпичность: дейли таск
EG
это что-то типа центра звезды по топологии что ли? данные на узлах есть, а задача - синхронизировать?
Задача — ни в коем случае не прекращать обрабатывать данные. Желательно, но не строго обязательно — не обрабатывать одни данные два раза.
Там всего два хоста, но применено куча ухищрений, чтобы они не отрубились одновременно (у них разные источники питания, разные подключения к интернету, а между собой они соединены напрямую, чтобы не зависеть от сети)
Там всего два хоста, но применено куча ухищрений, чтобы они не отрубились одновременно (у них разные источники питания, разные подключения к интернету, а между собой они соединены напрямую, чтобы не зависеть от сети)
CD
Задача — ни в коем случае не прекращать обрабатывать данные. Желательно, но не строго обязательно — не обрабатывать одни данные два раза.
Там всего два хоста, но применено куча ухищрений, чтобы они не отрубились одновременно (у них разные источники питания, разные подключения к интернету, а между собой они соединены напрямую, чтобы не зависеть от сети)
Там всего два хоста, но применено куча ухищрений, чтобы они не отрубились одновременно (у них разные источники питания, разные подключения к интернету, а между собой они соединены напрямую, чтобы не зависеть от сети)
А, так бы и сказал - проблема возможного отключения решена дублированием
CD
Это, правда, не спасает от софтварных ошибок вида "29е февраля"
EG
А, так бы и сказал - проблема возможного отключения решена дублированием
Угу. Основной вопрос был в том, как реализовать это дублирование, если мы считаем, что отказать может примерно что угодно и в любой момент (мы всё ещё не закладываемся на случай «сдохли оба кабеля питания». В этот момент мониторинг уже не нужен, полное отсутствие питания в ДЦ эээ заметно. А вот случай «сдохли оба кабеля интернета» нужно уметь обрабатывать).