Автор оригинала: Vlad Mihalcea.
Линеаризуемость-это менее известное, но вездесущее свойство реестра данных в контексте операций чтения и записи, которые могут выполняться одновременно.
Цель этой статьи-объяснить, в чем заключается линеаризуемость и почему она более распространена, чем вы могли подумать ранее.
Теперь предположим, что у вас есть система баз данных с одним узлом, как показано на следующей схеме:
Первая инструкция SELECT считывает значение 50, в то время как вторая инструкция SELECT считывает значение 10, так как между двумя операциями чтения была выполнена операция записи.
Линеаризуемость означает, что изменения происходят мгновенно, и как только значение реестра записано, любая последующая операция чтения найдет то же самое значение, пока реестр не претерпит никаких изменений.
Линеаризуемость-это то, что теорема CAP называет согласованностью.
Чтобы продемонстрировать, что значит для системы быть нелинейной, рассмотрим следующую диаграмму:
На этот раз у нас нет единого реестра или единого источника правды. Наша система использует асинхронную репликацию базы данных , и у нас есть Основной узел, который выполняет как чтение, так и запись, и узел-последователь, используемый только для операций чтения.
Поскольку репликация происходит асинхронно, существует задержка между изменением строки основного узла и временем, когда Последователь применяет то же изменение.
Одно подключение к базе данных изменяет баланс счета с 50 до 10 и фиксирует транзакцию. Сразу после этого вторая транзакция считывается с узла-подписчика, но, поскольку репликация не применила изменение баланса, считывается значение 50.
Таким образом, эта система не линеаризуема, поскольку изменения, по-видимому, не происходят мгновенно. Чтобы сделать эту систему линеаризуемой, нам необходимо использовать синхронную репликацию, и операция ОБНОВЛЕНИЯ основного узла не будет завершена до тех пор, пока узел-последователь также не применит ту же модификацию.
Однако, если количество узлов увеличится, синхронная репликация будет невозможна по двум причинам. Во-первых, синхронное обновление нескольких узлов увеличивает время отклика, что может повлиять на скорость отклика приложения. Во-вторых, если один узел больше не отвечает, все записи должны будут приостановиться до тех пор, пока этот узел не станет отзывчивым или если система будет перенастроена, чтобы исключить этот конкретный узел.
По этой причине в распределенной системе протокол консенсуса, такой как Paxos или Raft , является гораздо лучшей альтернативой для обеспечения линеаризуемости.
Линеаризуемость не ограничивается распределенными системами и базами данных. При использовании Java не гарантируется, что операции чтения и записи будут линеаризуемыми, если изменяемая переменная не является изменчивой или если и запись, и чтение выполняются из синхронизированного блока.
Поскольку большинство компьютерных систем используют несколько ядер процессора, и каждое ядро имеет свой собственный кэш, операция записи может изменить только переменную в кэше процессора. Чтобы изменение распространилось в основную память, необходимо очистить кэш с обратной записью CPU, и это именно то, что на самом деле делает ключевое слово volatile .
В однопоточной интронизации каждая операция чтения и записи автоматически линеаризуется, что позволяет очень легко рассуждать о состоянии, а также гарантирует правильность, когда дело доходит до реализации определенного алгоритма.
В многопоточной среде, если система не линеаризуема, будет гораздо сложнее гарантировать правильность, поскольку операции чтения и записи, по-видимому, происходят в другое время, чем их фактическое время настенных часов.
В заключение следует отметить, что линеаризуемая система гарантирует строгий порядок операций чтения и записи по времени, соответствующий потоку времени настенных часов.