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

Недавно Амазон объявил о переходе с модели eventual consistency на strong consistency, то есть read-after-write consistency.
А также есть статья в блоге некоего высокопоставленного манагера из Амазона:
https://www.allthingsdistributed.com/2021/04/s3-strong-consistency.html — Diving Deep on S3 Consistency

Первое, что думается в ответ на эти новости: а как же теорема CAP? Подсказки для этого ответа ищутся в гугле:

https://news.ycombinator.com/item?id=25271791

So they claim performance and availability will remain same while claiming strong consistency. I was confused at first but then “same” availability isn’t 100% availability. So it indeed CP.

In this paper about Spanner, we learn that it’s possible to build a CA system (one which prioritises Consistency and Availability) and also build a network so good that the risk of Partitions to be Tolerant of is negligible enough to effectively ignore.

Короче говоря, CAP никуда не делось, вечного двигателя, сверхсветовой передачи информации, или телепорта в амазоне не изобрели. Амазон пошел по логичному пути: пока нет ни единого разрыва сети, БД дает consistency+availability гарантии, когда сеть рвется — запросы на запись перестают выполняться, имеющиеся данные замораживаюся в том систоянии, в котором они были до разрыва.

Теперь по самой реализации. Инфа в гугле крайне скудная, пока что лучшее, что удалось найти:
https://www.reddit.com/r/aws/comments/k4yknz/s3_strong_consistency/gecdohv/

If I had to guess, s3 synchronously writes to a cluster of storage nodes before returning success, and then asynchronously replicates it to other nodes for stronger durability and availability. There used to be a risk of reading from a node that didn't receive a file's change yet, which could give you an outdated file. Now they added logic so the lookup router is aware of how far an update is propagated and can avoid routing reads to stale replicas.

Судя по всему, ключевым архитектором сего чуда был некто Нихил Шах:
https://www.linkedin.com/in/nikhiljshah/

DATA ITEM AND WITNESS SERVICE PARTITIONING IN A DISTRIBUTED STORAGE SYSTEM
Patent date Filed Oct 1, 2021 Patent issuer and number P73159-US01

TRANSACTION MANAGEMENT FOR MONOTONIC WRITE CONSISTENCY IN A DISTRIBUTED STORAGE SYSTEM
Patent date Filed Oct 1, 2021 Patent issuer and number P74530-US01

Первое, что находится в гугле по запросам «strong consistency witness» и «monotonic writes witness» — это статьи:

http://www2.cs.uh.edu/~paris/MYPAPERS/Icdcs86.pdf - Voting with Witnesses: A Consistency Scheme for Replicated Files
https://web.stanford.edu/~ouster/cgi-bin/papers/ParkPhD.pdf - Achieving both low latency and strong consistency in large-scale systems

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

https://www.usenix.org/system/files/fast20-ganesan.pdf - Strong and Efficient Consistency with Consistency-Aware Durability

Здесь авторы просто отложили операции записи, за счет чего уменьшили время ответа по запросам записи до уровня асинхронной репликации (и потеряли гарантии сохранности при исчезновении питания, но кого это волнует в 2022?). Монотонность чтений без необходимости опроса всего кластера «гарантировали» списком активных узлов, которые получили актуальные изменения и знают об этом. Можно спорить по поводу того, вовремя ли отвалившиеся узлы поймут, что у них уже нет актуальных данных, и потому сериализуемы ли чтения по кластеру, но ведь чтения несериализуемы даже в оригинальном ZooKeeper по абсолютно той же причине (узел может продолжать думать, что он лидер, хотя в кластере выбран новый лидер) — так что вроде как ухудшения нету.

Вот я сидел-сидел, думал-думал, и подумал «а зачем здесь полный консенсус?». Соответственно, взор мой возвращается снова на

https://web.stanford.edu/~ouster/cgi-bin/papers/ParkPhD.pdf - Achieving both low latency and strong consistency in large-scale systems

где авторы используют свидетелей просто как избыточное eventual consistency хранилище. Вам ничего это не напоминает? Мне напоминает устройство S3 до введения строгой согласованности.

Лично я склоняюсь к тому, что Амазон под капотом S3 оставил тот же самый eventual consistency, работающий на типичной для той же Amazon DynamoDB модели «sloppy consensus», например, когда у вас 10 узлов в сети и для подтверждения записи достаточно подтверждения от 3 узлов (а не шести, как это было бы в строгом консенсусе). Данные со временем будут раскопированы асинхронно на остальные узлы. Естественно, sloppy consensus никак не защищает от split brain, когда у вас две части кластера теряют связь и начинают независимо изменять файлы (в обоих частях есть по три узла для успешного подтверждения), и потому не знают про изменения в другой части кластера. Очевидно, при восстановлении связи нужно как-то конфликтные изменения разруливать. Amazon DynamoDB и Riak уже давно используют решение «в лоб» — оставлять запись с самым последним timestamp. Ту же политику декларирует S3:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html#Consistenc...

Amazon S3 does not support object locking for concurrent writers. If two PUT requests are simultaneously made to the same key, the request with the latest timestamp wins.

Совпадение? Не думаю. По итогу воображается что-то такое:

https://habrastorage.org/webt/ve/c9/ua/vec9uatqx1zht2814ljj-ipvipm.png

То есть, по сути то же самое DynamoDB плюс подобие процессорного кэша. Успешный ответ на операцию PUT возвращается только после успешного сохранения на достаточное число персистентных хранилищ и после оповещения кэшей. Операция оповещения кэша требует передачи данных по сети, но лишь самого минимума, и кэш может мгновенно ответить на этот запрос, так что синхронность не является проблемой.

Как можно заметить, я нарисовал четыре стрелки от кэша к хранилищу — это минимальное количество связей, которое нужно для гарантированного получения данных, залитых на 2 из 5 хранилищ. В принципе, используя информацию из оповещения кэш может стучаться только в два первых хранилища, в которые данные будут размещены раньше всего. Конечно, может оказаться так, что данные уже нужны, а они даже в первые хранилища не залиты — это достаточно редкая ситуация, которую можно разрулить через запрос «отдай мне данные версии XXX, если они у тебя уже есть».

Здесь возникает множество подводных камней при потери связи между узлами. Например, кэш может так и не дождаться ответа на «отдай мне данные версии XXX». Но проблема может быть еще серьезнее: что если кэш вообще не получил уведомления и до сих пор считает, будто данные остались в своей старой версии? Вот это и есть вся фишка CAP и недосказанности со стороны Амазона — а ничего не делать, тупо выдавать старую версию файла, хотя уже давно есть новая. Скрестим пальчики и будем надеяться, что ситуация февраля 2017 года больше никогда не повторится.

• [:|||||||||:] -> Символ бояна -> На бояне играют «заезжаные» песни -> Аналогия повторно опубликованной шутки или информации.
  
• Зомбо-ящик -> Обозначение материального предмета, имеющего форму ящика и обладающего свойством зомбирования -> Связь с телевидением и СМИ -> Ложь, искаженная информация, НЛПшные трюки из серии «купи-купи» -> Неосознанная потеря контроля над желаниями, личностью -> Состояние зомби.
  
• $ -> Обозначение денежной единицы США -> Деньги -> специфический товар максимальной ликвидности, который является универсальным эквивалентом стоимости других товаров или услуг -> ...

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

Накидайте еще таких цепочек.

В последнее время заинтересовался способностью языковыми конструкциями описывать обстановку окружающего материального мира. Пока что Пришвина почитываю. Может кто посоветует что-нибудь аналогичное или получше? Интересует русскоязычная и англоязычная литература.

Заранее благодарю

как вы считаете нужно ли в корзину интернет магазина класть реальные товары склада либо брать реальные товары в момент оформления заказа? товары могут быть как абстрактные типа «килограмм апельсин», так и конкретные типа «билет на 12 место в 4 ряду». если класть реальные товары то сколько по вашему должны эти товары хранится в корзине прежде чем будут удалены в случае если оформления заказа не будет?

GNU/Linux тут при том что весь backend на нем

Что можно почитать из современной философии, которая хорошо согласуется или даже берёт за основу современные научные теории? Ну там, философское осмысление квантмеха, например, вот такое вот.

А то как откроешь что-нибудь из XIX и ранее века - плакать хочется от этой бредотни (ну кроме Ницше, тот жжот на 5+). Из XX века я из «чистых» философов только Камю читал, отлично зашёл вообще, хоть науке и ортогонален.

Перемещено leave из science

Всем хорошего дня.

Увеличивается количество серверов на debian. Назначения различные. Настроены уведомления в телеграм и почту с помощью скриптов на python. Срабатывают при запуске события и сообщают затем результат его выполнения. Не очень удобно. Так как приходится проверять утром телегу и почту и вспоминать от каких серверов какие уведомления пришли, а какие нет. Логичнее было бы уведомлять только тогда, когда есть проблема. Но нужно тогда мониторить работает ли сервер вообще. А то выключенный сервер не отправит уведомление как и тот, на котором все хорошо.

Надеюсь тут я понятно объяснил. Так как я еще год-два назад имел лишь поверхностные знания и по сути учился по ходу работы, то с системами мониторинга по типу zabbix, я не сталкивался. Теперь же есть реальная необходимость. Перехожу к сути.

Расскажите, что сейчас из актуального софта можно развернуть для мониторинга debian-серверов, с возможностью отправки уведомлений и контроля доступности самих серверов. Желательно с возможностью настройки что именно мониторить.

Кроме zabbix. Про него я знаю. Но вдруг есть что-то еще интересное. Просто поделитесь своими мыслями и расскажите как сами мониторите свои сервера. Спасибо!=)

Добрый день.

Возник такой философский вопрос - куда лучше всего помещать блокировку контекста модуля:

1. В сам контекст и делать функции lock/unlock внутри модуля при вызове каждой функции. Примерно так

   struct mytype
   {
       mutex_t m;
       /* some data to protect */
   }
   
   void mytype_do_something(mytype *ctx)
   {
       mutex_lock(ctx->m);
       /* do something with data */
       mutex_unlock(ctx->m);
   }
   

2. В сам контекст, но сделать API функции lock/unlock, которые должен вызывать пользователь модуля

   struct mytype
   {
       mutex_t m;
       /* some data to protect */
   }
   
   void mytype_lock(mytype *ctx)
   {
       mutex_lock(ctx->m);
   }
   
   void mytype_unlock(mytype *ctx)
   {
       mutex_unlock(ctx->m);
   }
   
   void mytype_do_something(mytype *ctx)
   {
       /* do something with data with the assumption that user called mytype_lock() */
   }
   

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

   void thread_func(void *user_ctx)
   {
       mytype *ctx = ((thread_ctx *)user_ctx)->ctx;
       mutex_t m = ((thread_ctx *)user_ctx)->m;
       /* ... */
       mutex_lock(m);
       mytype_do_something(ctx);
       mutex_unlock(m);
   }
   
   int main()
   {
       mytype *ctx;
       mutex_t m;
       /* init ctx and mutex */
       /* start threads */
       /* ... */
   }
   

Лично у самого предпочтения идут с конца списка в начало, т.е. сначала 3, потом 2 и меньше всего нравится скрытая блокировка.

3—4 ноября в Санкт-Петербурге состоится большая хардкорная Java-конференция Joker 2017. Для всех, кому до Питера не добраться, будет онлайн-трансляция.

Как всегда, будет тёплая ламповая атмосфера, хардкорные доклады, крутые спикеры, жаркие дискуссии и холивары c коллегами и многое другое.

Что будем обсуждать:

• JVM/JDK под капотом (Runtime, GC, OpenJDK);
• Java Performance;
• высоконагруженные системы;
• языки программирования для JVM;
• распределенные системы.
• архитектуры Java-проектов;
• инструменты разработчика;
• хранилища данных (SQL/NoSQL/Cloud);
• фреймворки (Spring, Spark, Hibernate и др);
• Java 9 / Java 10 и будущие версии;
• DevOps, CD, CI;
• Data Science / ML;
• Java EE;
• Puzzlers!

Программа полностью готова, среди спикеров конференции — Алексей Шипилёв (Red Hat), Александр Борисов (Google), легенда Хабра Сергей Абдульманов (Мосигра), Alvaro Hernandez (8Kdata), Тагир Валеев (JetBrains), Николай Алименков (XP Injection), Барух Садогурский (JFrog) и другие звёзды.

Это будет пятый по счёту Joker: с каждым годом он растёт, становится всё интереснее и хардкорнее. Ежегодно конференция собирает более 1000 участников. Все доклады конференции — только про востребованные в Java технологии.

«Изюминка» конференции — дискуссионные зоны, куда направляются после докладов все спикеры для живого общения. Учитывая, что почти все посетители — Java-разработчики уровня Senior и Middle, можно с уверенностью утверждать, что там, в кулуарах, рождается будущее.

>>> Подробности и регистрация на сайте конференции Joker 2017