Рационализация согласованности в облаках

Сериализуемость


Для обеспечения сериализуемости, требуемой для данных категории A, мы реализовали двухфазный протокол блокировок (two-phase locking protocol, 2PL). 2PL особенно устойчив к высокой частоте возникновения конфликтов и поэтому хорошо подходит в ситуациях, в которых конфликты ожидаются. Чтобы обеспечить права монопольного доступа, требуемые 2PL, мы реализовали службу блокировок. Чтобы всегда видеть наиболее последнее по времени состояние записей, мы были вынуждены реализовать усовершенствованную службу очередей, обеспечивающую более высокий уровень гарантий, чем Amazon Simple Queue Service. В частности, любое сообщение в любое время можно изъять из очереди, и идентификаторы сообщений монотонно возрастают.

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

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



Содержание раздела