Memcached: посоветуйте что-нибудь почитать про нюансы работы распределенной системы

Присоединяюсь к вопросу, но более абстрактному: кому в 2022 нужны мои навыки проектирования и реализации распределенных систем? Ну, кроме гугла-фейсбука, которые я в гробу видал. Я несколько вакашек смотрел по этому делу — там сплошные «индексы, оптимизация SQL, WAL». Короче говоря, обычная однозадачная реляционная дристня, но реплицированная/шардированная — хз, почему в индустрии так любят делать «распределенные БД» максимально нераспределенными.

По поводу вопроса:

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

Вообще-то так, как ты распределишь ключи — так они и будут распределены. Нештатные ситуации точно так же ты лично руками обрабатываешь — memcached не умеет в репликацию и fail-over.

почему могут возникать ситуации с разными данными на разных php-клиентах

Потому что есть CAP теорема, которая говорит, что при потере связи между узлами либо система виснет, либо происходит рассинхрон. Собственно, никакой теоремы не нужно — проблема невозможности связи там, где связи нет, довольно самоочевидна. Всё разработки распределенных система как раз сводится к тому, чтобы грамотно выбрать, разработать, и протестировать степень рассинхронизации между клиентами. Всё, больше тут теории особо нету, остается только долго и мучительно перебирать и анализировать модели, выбирая наиболее удобный, а потом придумывать реализацию, которая бы минимизировала шанс выстрелить в ногу для придуманной модели.

https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nishtala

https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nish...

Ух ты, наконец индус-лектор с хорошим английским. Аж приятно слушать.

По содержанию лекции — я теперь начинаю понимать, откуда растут корни некоторых современных решений фейсбука:
https://habr.com/post/593167/
У фейсбука был относительно успешный опыт внедрения распределенного кэша на memcached и распределенных транзакций на «сагах» — техническое руководство окончательно решило, что можно продолжать ничего не менять, писать на тех же PHP с мускулем до посинения... пока они наконец не упёрлись в потолок по операциям записи, которых вроде бы «немного» и в основном происходят операции чтения, но на таком масштабе «немного» выглядит устрашающе — десятки тысяч транзакций в секунду на распределенной высокосогласованной БД находятся где-то около технологического предела для нынешних интернет-каналов.

По сути, фейсбук слепил на диком числе костылей банальный statefull уровень бизнес-логики (с memcached в основном общаются PHP-worker-ы). Это к слову о том, почему микросервисы на самом деле не работают: они просто перекладывают проблему на другое узкое место — БД/кэш. Примерно из таких соображений лично я посчитал, что будет хорошей идеей сделать универсальный механизм для создания statefull логики в питоне:
https://github.com/byko3y/python-shared-objects
К сожалению, моя задумка так и осталась моей, потому что всех остальных более чем устраивают костыли, уже имеющиеся в экосистеме питона.

По теме треда — я сомневаюсь, что автор будет проектировать-реализовывать систему хотя бы на миллион пользователей. Если посмотреть на диаграмму на 15:00, то можно заметить, что авторы системы никак не решили проблему одновременного изменения одной ячейки из нескольких регионов. Индус оправдывается, что чтение-запись ячейки скорее всего будет происходить в рамках одного региона, потому вроде как ему пофиг, но это опасный совет, который может оказаться вредным для посетителей LOR, разрабатывающих крупные высоконагруженные распределенные системы уровня фейсбука.

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

традиционно https://jepsen.io/