Вы совершенно правы в том, что в статье не написано того, чего мы в ней не планировали писать. А именно про технологическое развитие проекта, его архитектуру, подход и организацию решения аварийных ситуаций. Это темы отдельных статей и выступлений, которые планируются в ближайшее время.
О том, что вы не предполагаете, а утверждаете об архитектурной и организационной непродуманности основываясь на предположениях и отдельных, не являющихся ключевыми фактах. Это скорее можно отнести к теории о том, что “все можно продумать” или “разработчики и админы не должны делать ошибок”. Что нельзя воспринимать серьезно. Все ошибаются, и мы тоже не исключение. Выводы сделаны, работы продолжаются. По результатам наших действий получен измеряемый результат. Кто-то возможно научится чему-то на наших ошибках.
Совершенно верно. Ваши предположения без отсутствия технических подробностей ошибочны. Кроме этого архитектура меняется и вместе с этим решаются еще известные нам концептуальные проблемы, в том числе и указанная вами проблема с потенциальной нагрузкой. Более подробно рассказать о том, как мы решаем аварийные ситуации и предотвращаем их, мы планируем в отдельных статьях, ориентированных на техническую аудиторию.
Вы несколько преувеличиваете масштаб проблемы с Unsafe. Мы ее используем, пока нет столь же эффективных альтернатив. C появлением альтернативы — мы перейдем на нее.
Лимитировать нагрузку и ограничивать количество запросов мы умеем. Правда, без раскрытия технических подробностей сложно обьяснить, почему это нам в данном случае не помогло. Что касается Unsafe, его использует большое количество известных всем проектов, таких как (и не ограничиваясь) : Cassandra, Hadoop/HBase, Scala, Akka,Netty и даже Spring и Hibernate (более подробно можно почитать, например, в документе международной рабочей группы https://docs.google.com/document/d/1GDm_cAxYInmoHMor-AkStzWvwE9pw6tnz_CebJQxuUE/edit?usp=sharing)
Мы в курсе проблемы и решим ее своевременно.
Дискуссии пользователя
Вы совершенно правы в том, что в статье не написано того, чего мы в ней не планировали писать. А именно про технологическое развитие проекта, его архитектуру, подход и организацию решения аварийных ситуаций. Это темы отдельных статей и выступлений, которые планируются в ближайшее время.
О том, что вы не предполагаете, а утверждаете об архитектурной и организационной непродуманности основываясь на предположениях и отдельных, не являющихся ключевыми фактах. Это скорее можно отнести к теории о том, что “все можно продумать” или “разработчики и админы не должны делать ошибок”. Что нельзя воспринимать серьезно. Все ошибаются, и мы тоже не исключение. Выводы сделаны, работы продолжаются. По результатам наших действий получен измеряемый результат. Кто-то возможно научится чему-то на наших ошибках.
На тот момент серверов было более 5000.
Совершенно верно. Ваши предположения без отсутствия технических подробностей ошибочны. Кроме этого архитектура меняется и вместе с этим решаются еще известные нам концептуальные проблемы, в том числе и указанная вами проблема с потенциальной нагрузкой. Более подробно рассказать о том, как мы решаем аварийные ситуации и предотвращаем их, мы планируем в отдельных статьях, ориентированных на техническую аудиторию.
Вы несколько преувеличиваете масштаб проблемы с Unsafe. Мы ее используем, пока нет столь же эффективных альтернатив. C появлением альтернативы — мы перейдем на нее.
Приблизительно так и действовали. Начинали вручную, параллельно автоматизируя процесс и решая множество сопутствующих технических проблем.
Лимитировать нагрузку и ограничивать количество запросов мы умеем. Правда, без раскрытия технических подробностей сложно обьяснить, почему это нам в данном случае не помогло. Что касается Unsafe, его использует большое количество известных всем проектов, таких как (и не ограничиваясь) : Cassandra, Hadoop/HBase, Scala, Akka,Netty и даже Spring и Hibernate (более подробно можно почитать, например, в документе международной рабочей группы https://docs.google.com/document/d/1GDm_cAxYInmoHMor-AkStzWvwE9pw6tnz_CebJQxuUE/edit?usp=sharing)
Мы в курсе проблемы и решим ее своевременно.
Разница в операционных системах и текстовых редакторах, используемых сотрудниками. Один оставлял дополнительный символ перевода строки, другой нет.