День 2377. #УрокиРазработки
Уроки 50 Лет Разработки ПО
Урок 60. Невозможно изменить всё сразу
Независимо от того, сколько болевых точек, идей по улучшению или желательных направлений вы определите, скорость восприятия изменений людьми и организациями ограничена. Люди не могут совершенствовать свою работу быстрее, чем позволяют их индивидуальные способности, поэтому инициатива крупномасштабных изменений, навязанная руководством, может ошеломить тех, кого она касается. Попытка изменить слишком многое и сразу может затруднить выполнение работы, поскольку люди будут пытаться понять новые веяния и стараться соответствовать им.
По аналогии с личностным ростом совершенствование процессов разработки ПО — это циклическое, а не прямолинейное движение. Изобразить цикл изменений можно, например, как на рисунке выше.
1. Оценка. Определите, где вы находитесь сегодня: каких результатов достигли ваши проекты в настоящее время и насколько хорошо идут дела. Определите самые проблемные области и самые большие возможности для улучшения.
2. Планирование. Решите, где вы хотели бы быть в будущем: каковы цели по улучшению. Наметьте план, как этого достичь.
3. Выполнение. Самое сложное - начать работать как-то иначе. Придётся познакомиться с практиками и методами, которые могут дать лучшие результаты, опробовать их и скорректировать под условия своей среды. Сохраняйте то, что работает, и изменяйте, заменяйте или отказывайтесь от того, что не работает.
4. Проверка. Позвольте новым методам закрепиться, а затем проверьте, дают ли они ожидаемые результаты. Чтобы изменить направление, требуются время и терпение. Затраты на обучение неизбежны. Улучшение показателей — это долгосрочный, но запаздывающий признак пригодности новых подходов для ваших проектов. Попробуйте определить промежуточные показатели, по которым можно понять, окупается ли то, что вы пытаетесь сделать.
Всегда найдётся над чем поработать. Возвращайтесь к шагу оценки в конце каждого цикла изменений, чтобы изучить новую ситуацию, а затем начинайте новый.
Приоритизация изменений
Вы можете определить больше желаемых изменений, чем могли бы внедрить, поэтому придётся расставить приоритеты, чтобы сосредоточить всю свою энергию на получении максимальной выгоды. Затем вы должны выкроить время для реализации каждого изменения. Если вы намеренно не выделяете время, то никогда не найдёте свободной минутки, не занятой другими хлопотами. Но если вы не сделаете первых шагов к изменениям, то не добьётесь прогресса. Выберите самые актуальные проблемы и начните работать над ними завтра. Да, завтра!
В какой области было бы наиболее желательно увидеть улучшения и уменьшить неприятные последствия? Какие изменения могли бы быть наиболее ценными? Какие изменения кажутся наиболее достижимыми при разумном вложении энергии и денег? Определите основные проблемные области и выберите возможные решения, которые окупятся с высокой вероятностью. Ищите плоды на нижних ветках — быстродостижимые улучшения — и празднуйте эти успехи.
Применяйте системный подход и на личном уровне. Начиная новый проект, определите 2 области, в которых хотелось бы совершенствоваться. Это может быть модульное тестирование, оценка, алгоритмизация, рецензирование, и т.п. Выделите часть времени на чтение литературы или прохождение курсов по выбранным темам и ищите возможности применить то, чему научились, понимая при этом, что потребуются некоторые усилия, чтобы выяснить, как получить наибольший эффект от изменений. Помните, что кривая обучения не является плавным и непрерывным переходом. У вас обязательно будут взлёты и падения. Но, применяя системный подход, вы доберётесь туда, куда хотите попасть.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 8.
Уроки 50 Лет Разработки ПО
Урок 60. Невозможно изменить всё сразу
Независимо от того, сколько болевых точек, идей по улучшению или желательных направлений вы определите, скорость восприятия изменений людьми и организациями ограничена. Люди не могут совершенствовать свою работу быстрее, чем позволяют их индивидуальные способности, поэтому инициатива крупномасштабных изменений, навязанная руководством, может ошеломить тех, кого она касается. Попытка изменить слишком многое и сразу может затруднить выполнение работы, поскольку люди будут пытаться понять новые веяния и стараться соответствовать им.
По аналогии с личностным ростом совершенствование процессов разработки ПО — это циклическое, а не прямолинейное движение. Изобразить цикл изменений можно, например, как на рисунке выше.
1. Оценка. Определите, где вы находитесь сегодня: каких результатов достигли ваши проекты в настоящее время и насколько хорошо идут дела. Определите самые проблемные области и самые большие возможности для улучшения.
2. Планирование. Решите, где вы хотели бы быть в будущем: каковы цели по улучшению. Наметьте план, как этого достичь.
3. Выполнение. Самое сложное - начать работать как-то иначе. Придётся познакомиться с практиками и методами, которые могут дать лучшие результаты, опробовать их и скорректировать под условия своей среды. Сохраняйте то, что работает, и изменяйте, заменяйте или отказывайтесь от того, что не работает.
4. Проверка. Позвольте новым методам закрепиться, а затем проверьте, дают ли они ожидаемые результаты. Чтобы изменить направление, требуются время и терпение. Затраты на обучение неизбежны. Улучшение показателей — это долгосрочный, но запаздывающий признак пригодности новых подходов для ваших проектов. Попробуйте определить промежуточные показатели, по которым можно понять, окупается ли то, что вы пытаетесь сделать.
Всегда найдётся над чем поработать. Возвращайтесь к шагу оценки в конце каждого цикла изменений, чтобы изучить новую ситуацию, а затем начинайте новый.
Приоритизация изменений
Вы можете определить больше желаемых изменений, чем могли бы внедрить, поэтому придётся расставить приоритеты, чтобы сосредоточить всю свою энергию на получении максимальной выгоды. Затем вы должны выкроить время для реализации каждого изменения. Если вы намеренно не выделяете время, то никогда не найдёте свободной минутки, не занятой другими хлопотами. Но если вы не сделаете первых шагов к изменениям, то не добьётесь прогресса. Выберите самые актуальные проблемы и начните работать над ними завтра. Да, завтра!
В какой области было бы наиболее желательно увидеть улучшения и уменьшить неприятные последствия? Какие изменения могли бы быть наиболее ценными? Какие изменения кажутся наиболее достижимыми при разумном вложении энергии и денег? Определите основные проблемные области и выберите возможные решения, которые окупятся с высокой вероятностью. Ищите плоды на нижних ветках — быстродостижимые улучшения — и празднуйте эти успехи.
Применяйте системный подход и на личном уровне. Начиная новый проект, определите 2 области, в которых хотелось бы совершенствоваться. Это может быть модульное тестирование, оценка, алгоритмизация, рецензирование, и т.п. Выделите часть времени на чтение литературы или прохождение курсов по выбранным темам и ищите возможности применить то, чему научились, понимая при этом, что потребуются некоторые усилия, чтобы выяснить, как получить наибольший эффект от изменений. Помните, что кривая обучения не является плавным и непрерывным переходом. У вас обязательно будут взлёты и падения. Но, применяя системный подход, вы доберётесь туда, куда хотите попасть.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 8.
👍7
День 2378. #TipsAndTricks
Используем COPY для Экспорта/Импорта Данных в Potgresql
В PostgreSQL есть функция, позволяющая эффективно выполнять массовый импорт и экспорт данных в таблицу и из неё. Обычно это гораздо более быстрый способ загрузки данных в таблицу и извлечения из неё, чем использование команд INSERT и SELECT.
В .NET провайдер Npgsql поддерживает три режима операции COPY: бинарный, текстовый и бинарный необработанный.
1. Бинарный
Пользователь использует API для чтения и записи строк и полей, которые Npgsql кодирует и декодирует. После завершения необходимо вызвать функцию Complete() для сохранения данных; в противном случае операция COPY будет откачена при освобождении объекта записи (это поведение важно в случае возникновения исключения).
2. Текстовый
В этом режиме данные в БД и из неё передаются в текстовом или CSV-формате PostgreSQL. Пользователь должен самостоятельно отформатировать текст или CSV-файл, Npgsql предоставляет только функции чтения или записи текста. Этот режим менее эффективен, чем бинарный, и подходит, если у вас уже есть данные в CSV, а производительность не критична.
3. Бинарный необработанный
Данные передаются в двоичном формате, но Npgsql не выполняет никакого кодирования или декодирования — данные предоставляются как необработанный поток .NET. Имеет смысл только для обработки больших объемов данных и восстановления таблицы: таблица сохраняется как BLOB-объект, который впоследствии можно восстановить. Если нужно разбирать данные, используйте обычный бинарный режим.
Отмена
Операции импорта можно отменить в любой момент, освободив (dispose) NpgsqlBinaryImporter до вызова метода Complete(). Операции экспорта можно отменить, вызвав метод Cancel().
Источник: https://www.npgsql.org/doc/copy.html
Используем COPY для Экспорта/Импорта Данных в Potgresql
В PostgreSQL есть функция, позволяющая эффективно выполнять массовый импорт и экспорт данных в таблицу и из неё. Обычно это гораздо более быстрый способ загрузки данных в таблицу и извлечения из неё, чем использование команд INSERT и SELECT.
В .NET провайдер Npgsql поддерживает три режима операции COPY: бинарный, текстовый и бинарный необработанный.
1. Бинарный
Пользователь использует API для чтения и записи строк и полей, которые Npgsql кодирует и декодирует. После завершения необходимо вызвать функцию Complete() для сохранения данных; в противном случае операция COPY будет откачена при освобождении объекта записи (это поведение важно в случае возникновения исключения).
// Импорт в таблицу с 2 полями (string, int)
using (var writer = conn.BeginBinaryImport(
"COPY my_table (field1, field2) FROM STDIN (FORMAT BINARY)"))
{
writer.WriteRow("Row1", 123);
writer.WriteRow("Row2", 123);
writer.Complete();
}
// Экспорт из таблицы с 2 полями
using (var rdr = conn.BeginBinaryExport(
"COPY my_table (field1, field2) TO STDOUT (FORMAT BINARY)"))
{
rdr.StartRow();
Console.WriteLine(rdr.Read<string>());
Console.WriteLine(rdr.Read<int>(NpgsqlDbType.Smallint));
rdr.StartRow();
// пропускает поле
rdr.Skip();
// проверяет на NULL (без перехода на следующее поле)
Console.WriteLine(rdr.IsNull);
Console.WriteLine(rdr.Read<int>());
rdr.StartRow();
// StartRow() вернёт -1 в конце данных
}
2. Текстовый
В этом режиме данные в БД и из неё передаются в текстовом или CSV-формате PostgreSQL. Пользователь должен самостоятельно отформатировать текст или CSV-файл, Npgsql предоставляет только функции чтения или записи текста. Этот режим менее эффективен, чем бинарный, и подходит, если у вас уже есть данные в CSV, а производительность не критична.
using (var writer = conn.BeginTextImport(
"COPY my_table (field1, field2) FROM STDIN"))
{
writer.Write("HELLO\t1\n");
writer.Write("GOODBYE\t2\n");
}
using (var reader = conn.BeginTextExport(
"COPY my_table (field1, field2) TO STDOUT"))
{
Console.WriteLine(reader.ReadLine());
Console.WriteLine(reader.ReadLine());
}
3. Бинарный необработанный
Данные передаются в двоичном формате, но Npgsql не выполняет никакого кодирования или декодирования — данные предоставляются как необработанный поток .NET. Имеет смысл только для обработки больших объемов данных и восстановления таблицы: таблица сохраняется как BLOB-объект, который впоследствии можно восстановить. Если нужно разбирать данные, используйте обычный бинарный режим.
int len;
var data = new byte[10000];
// Экспорт table1 в массив данных
using (var inStream = conn.BeginRawBinaryCopy(
"COPY table1 TO STDOUT (FORMAT BINARY)"))
{
// Предполагаем, что данные влезут в 10000 байт
// В реальности их нужно читать блоками
len = inStream.Read(data, 0, data.Length);
}
// Импорт данных в table2
using (var outStream = conn.BeginRawBinaryCopy(
"COPY table2 FROM STDIN (FORMAT BINARY)"))
{
outStream.Write(data, 0, len);
}
Отмена
Операции импорта можно отменить в любой момент, освободив (dispose) NpgsqlBinaryImporter до вызова метода Complete(). Операции экспорта можно отменить, вызвав метод Cancel().
Источник: https://www.npgsql.org/doc/copy.html
👍14
День 2379. #ЗаметкиНаПолях
Алгоритмы Выбора Главного Узла в Распределённых БД. Начало
Распределённые системы БД нуждаются в координации для корректной работы. Когда несколько узлов реплицируют данные и обрабатывают запросы между регионами или зонами, определённый узел должен взять на себя управление операциями записи. Этот узел обычно называется лидером: единый узел, отвечающий за упорядочивание обновлений, фиксацию изменений и обеспечение согласованности системы даже в случае сбоя.
Выбор лидера существует для ответа на простой, но важный вопрос: какой узел в данный момент отвечает за управление? Процесс выбора должен выдерживать реальные нагрузки, включая сбои процессов, задержки в сети, разделы, перезапуски и непредсказуемую потерю сообщений. В случае сбоя главного узла система должна обнаружить его, согласовать замену и продолжить работу, не повреждая данные и не обрабатывая один и тот же запрос дважды. Это проблема отказоустойчивости и консенсуса, лежащая в основе проектирования распределённых БД.
Рассмотрим основные подходы к выбору лидера, каждый со своими предположениями, сильными сторонами и компромиссами.
1. Алгоритм забияки (Bully)
Основан на базовом правиле: узел с наивысшим идентификатором становится лидером. Если узел замечает, что текущий лидер не отвечает, он пытается взять на себя управление.
Каждому узлу присваивается уникальный числовой идентификатор. Чем он выше, тем выше «ранг» узла. Все узлы заранее знают идентификаторы друг друга, что важно для работы алгоритма.
Предположим, имеются узлы с идентификаторами от 1 до 5. Узел 5 в настоящее время является лидером.
Если №5 выходит из строя, и №3 замечает это (например, перестаёт получать сигналы), №3 инициирует выборы.
Вот как может работать такой процесс (см. диаграмму ниже):
A) №3 обнаруживает, что ведущий узел №5 вышел из строя.
№3 отправляет сообщения о выборах узлам 4 и 5.
B) №4 активен и отвечает «OK».
№3 отступает, увидев ответ от узла с более высоким идентификатором.
C) №4 отправляет сообщения о выборах №5.
D) Если №5 вышел из строя, №4 не получает ответа.
E) №4 становится ведущим и рассылает сообщение координатора всем узлам.
Процесс останавливается, когда все узнают, кто новый лидер.
Если узел с более низким ID инициирует выборы, а несколько узлов с более высоким ID активны, все они могут ответить сообщениями «OK» или «Я активен». Однако эти ответы не объявляют лидерство. Они лишь указывают: «Мой ID выше вашего. Вы не подходите для роли лидера. Я возьму на себя процесс выборов».
После отправки сообщения «OK» каждый из этих узлов с более высоким ID начинает выборы, отправляя сообщения о выборах узлам с ещё более высокими ID. Этот процесс каскадируется вверх по цепочке.
Предположения
- Все узлы знают идентификаторы друг друга.
- Узлы взаимодействуют по надёжным каналам связи.
- Отказ лидера может быть точно обнаружен.
Недостатки
- Коммуникационные расходы. Каждые выборы могут включать в себя поток сообщений между несколькими узлами. В большом кластере это быстро становится затратным.
- Алгоритм плохо переносит разделение. Если узел ошибочно предполагает, что лидер мёртв из-за сетевой задержки, он может начать ненужные выборы, что приведёт к путанице или дублированию сообщений о лидерстве.
- Проблема поэтапного восстановления. Если узлы возвращаются в сеть после неисправности, каждый новый узел с более высоким идентификатором может инициировать новые выборы. Система тратит больше времени на выбор лидеров, чем на саму работу.
Продолжение следует…
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
Алгоритмы Выбора Главного Узла в Распределённых БД. Начало
Распределённые системы БД нуждаются в координации для корректной работы. Когда несколько узлов реплицируют данные и обрабатывают запросы между регионами или зонами, определённый узел должен взять на себя управление операциями записи. Этот узел обычно называется лидером: единый узел, отвечающий за упорядочивание обновлений, фиксацию изменений и обеспечение согласованности системы даже в случае сбоя.
Выбор лидера существует для ответа на простой, но важный вопрос: какой узел в данный момент отвечает за управление? Процесс выбора должен выдерживать реальные нагрузки, включая сбои процессов, задержки в сети, разделы, перезапуски и непредсказуемую потерю сообщений. В случае сбоя главного узла система должна обнаружить его, согласовать замену и продолжить работу, не повреждая данные и не обрабатывая один и тот же запрос дважды. Это проблема отказоустойчивости и консенсуса, лежащая в основе проектирования распределённых БД.
Рассмотрим основные подходы к выбору лидера, каждый со своими предположениями, сильными сторонами и компромиссами.
1. Алгоритм забияки (Bully)
Основан на базовом правиле: узел с наивысшим идентификатором становится лидером. Если узел замечает, что текущий лидер не отвечает, он пытается взять на себя управление.
Каждому узлу присваивается уникальный числовой идентификатор. Чем он выше, тем выше «ранг» узла. Все узлы заранее знают идентификаторы друг друга, что важно для работы алгоритма.
Предположим, имеются узлы с идентификаторами от 1 до 5. Узел 5 в настоящее время является лидером.
Если №5 выходит из строя, и №3 замечает это (например, перестаёт получать сигналы), №3 инициирует выборы.
Вот как может работать такой процесс (см. диаграмму ниже):
A) №3 обнаруживает, что ведущий узел №5 вышел из строя.
№3 отправляет сообщения о выборах узлам 4 и 5.
B) №4 активен и отвечает «OK».
№3 отступает, увидев ответ от узла с более высоким идентификатором.
C) №4 отправляет сообщения о выборах №5.
D) Если №5 вышел из строя, №4 не получает ответа.
E) №4 становится ведущим и рассылает сообщение координатора всем узлам.
Процесс останавливается, когда все узнают, кто новый лидер.
Если узел с более низким ID инициирует выборы, а несколько узлов с более высоким ID активны, все они могут ответить сообщениями «OK» или «Я активен». Однако эти ответы не объявляют лидерство. Они лишь указывают: «Мой ID выше вашего. Вы не подходите для роли лидера. Я возьму на себя процесс выборов».
После отправки сообщения «OK» каждый из этих узлов с более высоким ID начинает выборы, отправляя сообщения о выборах узлам с ещё более высокими ID. Этот процесс каскадируется вверх по цепочке.
Предположения
- Все узлы знают идентификаторы друг друга.
- Узлы взаимодействуют по надёжным каналам связи.
- Отказ лидера может быть точно обнаружен.
Недостатки
- Коммуникационные расходы. Каждые выборы могут включать в себя поток сообщений между несколькими узлами. В большом кластере это быстро становится затратным.
- Алгоритм плохо переносит разделение. Если узел ошибочно предполагает, что лидер мёртв из-за сетевой задержки, он может начать ненужные выборы, что приведёт к путанице или дублированию сообщений о лидерстве.
- Проблема поэтапного восстановления. Если узлы возвращаются в сеть после неисправности, каждый новый узел с более высоким идентификатором может инициировать новые выборы. Система тратит больше времени на выбор лидеров, чем на саму работу.
Продолжение следует…
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
👍10
День 2380. #ЗаметкиНаПолях
Алгоритмы Выбора Главного Узла в Распределённых БД. Продолжение
1. Алгоритм Забияки
2. Кольцевой Алгоритм
Сообщение передается по кругу, и побеждает узел с наивысшим идентификатором. В отличие от алгоритма Забияки, здесь нет концепции прерывания или повышения приоритета. Каждый узел имеет шанс принять участие, но только один из них становится лидером.
Система предполагает логическую кольцевую топологию, где каждый узел знает о следующем. Сообщения передаются по кругу, всегда в одном направлении. Кроме того, каждый узел имеет уникальный числовой идентификатор.
Предположим, 5 узлов объединены в кольцо с идентификаторами: A(3), B(5), C(2), D(1), E(4), и обратно к узлу A (см. диаграмму ниже).
Если C обнаруживает отсутствие лидера, он начинает выборы, отправляя сообщение своему соседу (D). Сообщение содержит идентификатор 2. Вот что может произойти:
- D(1) получает идентификатор 2, сравнивает его со своим идентификатором (1) и пересылает 2 узлу E.
- E(4) видит, что 4>2, поэтому он заменяет содержимое сообщения на 4 и пересылает его (есть вариант алгоритма, в котором идентификатор не заменяется, а добавляется). Таким образом, сообщение может принять вид [2,4], но в данном примере мы будем использовать подход с заменой.
- A(3) видит, что 4>3, поэтому он сохраняет 4 и пересылает сообщение.
- B(5) снова заменяет его на 5 и пересылает сообщение.
- В конце концов, сообщение возвращается к узлу C, отправителю.
В этот момент узел C видит, что его сообщение вернулось с идентификатором 5, который является наивысшим в системе. Следовательно, он делает вывод, что узел B(5) должен быть лидером. Он рассылает сообщение координатора по кольцу, сообщая всем, что узел B теперь является лидером.
Преимущества
- Кольцо гарантирует участие каждого активного узла в выборах.
- Идентификатор с наивысшим значением естественным образом распространяется и заменяет идентификаторы с более низкими значениями по мере распространения сообщения.
- Инициатор определяет завершение цикла и принимает окончательное решение.
- Выбирается только один лидер, и два узла не могут одновременно претендовать на лидерство. Процесс гарантированно завершится, пока кольцо цело и все соединения работают.
Недостатки
- Предполагает наличие надёжной и упорядоченной доставки. Если сообщение потеряно или задержано, весь процесс выборов может остановиться.
- Разрывается в динамической топологии. Если узлы появляются и исчезают, кольцо необходимо перестраивать. Это медленно и подвержено ошибкам.
- Задержка выборов линейно растет с количеством узлов. Для возвращения к инициатору всегда требуется N переходов, даже если победитель очевиден с самого начала.
Продолжение следует…
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
Алгоритмы Выбора Главного Узла в Распределённых БД. Продолжение
1. Алгоритм Забияки
2. Кольцевой Алгоритм
Сообщение передается по кругу, и побеждает узел с наивысшим идентификатором. В отличие от алгоритма Забияки, здесь нет концепции прерывания или повышения приоритета. Каждый узел имеет шанс принять участие, но только один из них становится лидером.
Система предполагает логическую кольцевую топологию, где каждый узел знает о следующем. Сообщения передаются по кругу, всегда в одном направлении. Кроме того, каждый узел имеет уникальный числовой идентификатор.
Предположим, 5 узлов объединены в кольцо с идентификаторами: A(3), B(5), C(2), D(1), E(4), и обратно к узлу A (см. диаграмму ниже).
Если C обнаруживает отсутствие лидера, он начинает выборы, отправляя сообщение своему соседу (D). Сообщение содержит идентификатор 2. Вот что может произойти:
- D(1) получает идентификатор 2, сравнивает его со своим идентификатором (1) и пересылает 2 узлу E.
- E(4) видит, что 4>2, поэтому он заменяет содержимое сообщения на 4 и пересылает его (есть вариант алгоритма, в котором идентификатор не заменяется, а добавляется). Таким образом, сообщение может принять вид [2,4], но в данном примере мы будем использовать подход с заменой.
- A(3) видит, что 4>3, поэтому он сохраняет 4 и пересылает сообщение.
- B(5) снова заменяет его на 5 и пересылает сообщение.
- В конце концов, сообщение возвращается к узлу C, отправителю.
В этот момент узел C видит, что его сообщение вернулось с идентификатором 5, который является наивысшим в системе. Следовательно, он делает вывод, что узел B(5) должен быть лидером. Он рассылает сообщение координатора по кольцу, сообщая всем, что узел B теперь является лидером.
Преимущества
- Кольцо гарантирует участие каждого активного узла в выборах.
- Идентификатор с наивысшим значением естественным образом распространяется и заменяет идентификаторы с более низкими значениями по мере распространения сообщения.
- Инициатор определяет завершение цикла и принимает окончательное решение.
- Выбирается только один лидер, и два узла не могут одновременно претендовать на лидерство. Процесс гарантированно завершится, пока кольцо цело и все соединения работают.
Недостатки
- Предполагает наличие надёжной и упорядоченной доставки. Если сообщение потеряно или задержано, весь процесс выборов может остановиться.
- Разрывается в динамической топологии. Если узлы появляются и исчезают, кольцо необходимо перестраивать. Это медленно и подвержено ошибкам.
- Задержка выборов линейно растет с количеством узлов. Для возвращения к инициатору всегда требуется N переходов, даже если победитель очевиден с самого начала.
Продолжение следует…
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
👍8
День 2381. #ЗаметкиНаПолях
Алгоритмы Выбора Главного Узла в Распределённых БД. Продолжение
1. Алгоритм Забияки
2. Кольцевой Алгоритм
3. Алгоритм Paxos
Позволяет любому узлу попытаться предложить значение, а затем использует кворумное голосование для определения того, какое предложение будет принято. Лидерство переходит к узлу, который последовательно добивается успеха в этой игре.
Это мощный протокол, но его сложно реализовать правильно. Paxos безопасен даже в условиях ненадёжных сетей, задержек сообщений и частичных сбоев. Но требует точной логики, постоянного хранения данных и глубокого понимания динамики кворума.
По сути, Paxos пытается решить проблему консенсуса, то есть как заставить группу узлов согласовать единое значение, даже если некоторые из них выходят из строя или сообщения приходят в неправильном порядке. Это значение может быть чем угодно, например, записью журнала, параметром конфигурации или идентификатором ведущего узла.
Paxos разделяет процесс на два этапа:
- Подготовка/Обещание
- Предложение/Принятие
Каждый узел играет одну или несколько ролей: предлагающего, принимающего и иногда обучающегося (см. диаграмму ниже).
1. Подготовка и обещание
Любой узел может выступать в роли предлагающего. Для начала он генерирует номер предложения, который представляет собой монотонно возрастающий идентификатор.
- Предлагающий отправляет сообщение «Prepare(n)» большинству принимающих, прося их пообещать не принимать предложения с номерами меньше n.
- Когда принимающий получает сообщение «Prepare(n)», он отвечает «Promise(n)», если он ещё не обещал что-то более высокое. Вместе с обещанием он включает предложение с уже принятым им значением (если оно есть).
Этот шаг помогает подавить конфликтующие или устаревшие предложения, гарантируя, что будущие предложения будут либо более новыми, либо основаны на ранее принятых.
Вот пример:
- Предлагающий A отправляет Prepare(100)
- Принимающие 1, 2 и 3 получают его и отвечают:
№1: Promise(100), ранее принятого значения нет
№2: Promise(100), ранее принятое значение (лидер = №4)
№3: Promise(100), ранее принятого значения нет
Теперь узел A знает, что он должен сохранить «№4» в качестве кандидата на лидера, даже если изначально он его не предлагал.
2. Предложение и принятие
Предлагающий выбирает значение:
- Если какой-либо принимающий ответил ранее принятым значением, он должен повторно предложить это значение.
- Если ранее ни одно из них не было принято, он может выбрать своё собственное (например, «выбрать A лидером»).
Он отправляет сообщение «Accept(n, значение)» тому же большинству. Если принимающие за это время не обещали ничего более высокого, они отвечают «Accepted(n, значение)». Как только кворум принимает значение, оно выбирается.
Multi-Paxos
В базовом протоколе Paxos каждое значение требует нового раунда шагов Prepare/Promise и Accept/Accepted. Это затратно и неэффективно, если значения предлагаются часто.
Multi-Paxos оптимизирует этот процесс:
- Выбирается определённый предлагающий, который будет выступать в качестве стабильного лидера.
- Лидеру предоставляется возможность пропускать фазу 1 для последующих значений, повторно используя лидерство до тех пор, пока его никто не оспорит.
Это создаёт форму стабильного лидерства. Лидер не избирается посредством отдельного механизма, а становится единственным узлом, постоянно успешно предлагающим значения.
Почему Paxos сложен?
- Номера предложений должны быть уникальными и упорядоченными глобально.
- Узлы должны сохранять состояние (обещания, принятые значения) при перезапусках.
- Восстановление после частичных сбоев или передачи управления требует тщательной координации.
Продолжение следует…
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
Алгоритмы Выбора Главного Узла в Распределённых БД. Продолжение
1. Алгоритм Забияки
2. Кольцевой Алгоритм
3. Алгоритм Paxos
Позволяет любому узлу попытаться предложить значение, а затем использует кворумное голосование для определения того, какое предложение будет принято. Лидерство переходит к узлу, который последовательно добивается успеха в этой игре.
Это мощный протокол, но его сложно реализовать правильно. Paxos безопасен даже в условиях ненадёжных сетей, задержек сообщений и частичных сбоев. Но требует точной логики, постоянного хранения данных и глубокого понимания динамики кворума.
По сути, Paxos пытается решить проблему консенсуса, то есть как заставить группу узлов согласовать единое значение, даже если некоторые из них выходят из строя или сообщения приходят в неправильном порядке. Это значение может быть чем угодно, например, записью журнала, параметром конфигурации или идентификатором ведущего узла.
Paxos разделяет процесс на два этапа:
- Подготовка/Обещание
- Предложение/Принятие
Каждый узел играет одну или несколько ролей: предлагающего, принимающего и иногда обучающегося (см. диаграмму ниже).
1. Подготовка и обещание
Любой узел может выступать в роли предлагающего. Для начала он генерирует номер предложения, который представляет собой монотонно возрастающий идентификатор.
- Предлагающий отправляет сообщение «Prepare(n)» большинству принимающих, прося их пообещать не принимать предложения с номерами меньше n.
- Когда принимающий получает сообщение «Prepare(n)», он отвечает «Promise(n)», если он ещё не обещал что-то более высокое. Вместе с обещанием он включает предложение с уже принятым им значением (если оно есть).
Этот шаг помогает подавить конфликтующие или устаревшие предложения, гарантируя, что будущие предложения будут либо более новыми, либо основаны на ранее принятых.
Вот пример:
- Предлагающий A отправляет Prepare(100)
- Принимающие 1, 2 и 3 получают его и отвечают:
№1: Promise(100), ранее принятого значения нет
№2: Promise(100), ранее принятое значение (лидер = №4)
№3: Promise(100), ранее принятого значения нет
Теперь узел A знает, что он должен сохранить «№4» в качестве кандидата на лидера, даже если изначально он его не предлагал.
2. Предложение и принятие
Предлагающий выбирает значение:
- Если какой-либо принимающий ответил ранее принятым значением, он должен повторно предложить это значение.
- Если ранее ни одно из них не было принято, он может выбрать своё собственное (например, «выбрать A лидером»).
Он отправляет сообщение «Accept(n, значение)» тому же большинству. Если принимающие за это время не обещали ничего более высокого, они отвечают «Accepted(n, значение)». Как только кворум принимает значение, оно выбирается.
Multi-Paxos
В базовом протоколе Paxos каждое значение требует нового раунда шагов Prepare/Promise и Accept/Accepted. Это затратно и неэффективно, если значения предлагаются часто.
Multi-Paxos оптимизирует этот процесс:
- Выбирается определённый предлагающий, который будет выступать в качестве стабильного лидера.
- Лидеру предоставляется возможность пропускать фазу 1 для последующих значений, повторно используя лидерство до тех пор, пока его никто не оспорит.
Это создаёт форму стабильного лидерства. Лидер не избирается посредством отдельного механизма, а становится единственным узлом, постоянно успешно предлагающим значения.
Почему Paxos сложен?
- Номера предложений должны быть уникальными и упорядоченными глобально.
- Узлы должны сохранять состояние (обещания, принятые значения) при перезапусках.
- Восстановление после частичных сбоев или передачи управления требует тщательной координации.
Продолжение следует…
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
👍2
День 2382. #ЗаметкиНаПолях
Алгоритмы Выбора Главного Узла в Распределённых БД. Продолжение
1. Алгоритм Забияки
2. Кольцевой Алгоритм
3. Алгоритм Paxos
4. Алгоритм Raft
Raft существует, потому что Paxos, несмотря на свою мощь, сложен в реализации и ещё сложнее в понимании. Raft предоставляет те же гарантии безопасности, что и Paxos, например, отсутствие двух лидеров одновременно, согласование журнала и отслеживание прогресса при наличии кворума. Однако архитектуру проще отслеживать, отлаживать и развёртывать.
Каждый узел Raft находится в одном из трёх состояний:
- Ведомый (Follower) - пассивный узел, слушает лидера и отвечает на запросы.
- Кандидат (Candidate) - пытается стать лидером при отсутствии тактовых импульсов.
- Лидер (Leader) - активный узел, который обрабатывает все клиентские запросы и репликацию.
Узлы начинают работу как ведомые. Если они слишком долго не получают ответ от лидера (по тактовым импульсам), они считают лидера мёртвым и запускают выборы (см. диаграмму ниже).
Raft предотвращает конфликты выборов, используя рандомизированные таймауты. Каждый ведомый начинает обратный отсчёт со случайным значением, например, от 150 до 300 миллисекунд. Если до истечения таймера он не получает ответа от лидера, он становится кандидатом и начинает выборы.
Кандидат:
- Увеличивает свой срок полномочий (своего рода счётчик эпох).
- Голосует за себя.
- Отправляет RPC-запросы «RequestVote» всем остальным узлам.
- Другие узлы будут голосовать за кандидата только в том случае, если:
они не голосовали в текущем сроке полномочий и журнал кандидата как минимум не менее актуален, чем их собственный.
- Если кандидат получает голоса большинства, он становится новым лидером и начинает отправлять тактовые импульсы для поддержания своего статуса. Если ни один из кандидатов не побеждает (например, голоса разделились), все ждут и повторяют попытки с новыми таймаутами. Такой рандомизированный подход гарантирует, что один из узлов в итоге опередит остальных.
Raft использует сроки полномочий (term) для отслеживания эпох лидерства. Каждая запись в журнале привязана к сроку полномочий, в котором она была создана. Это позволяет легко обнаруживать и отклонять устаревших или конфликтующих лидеров. Перед голосованием узлы сравнивают журналы. Кандидат с устаревшим журналом будет отклонён, даже если его запрос первым достигнет других узлов. Это гарантирует, что лидером может стать только узел с самой актуальной версией журнала. Затем лидеры реплицируют новые записи журнала на ведомых с помощью RPC-вызовов «AppendEntries». После того, как кворум подтвердил запись, она считается подтверждённой.
Raft решает проблему разделения власти, применяя правила кворума:
- Лидер должен иметь поддержку большинства узлов.
- Два лидера не могут быть активны в одном и том же сроке.
- Ведомый принимает запросы только от лидера текущего срока.
- Если устаревший лидер пытается действовать после разделения сети, он немедленно отклоняется ведомыми с более новым сроком.
Эта чёткая структура позволяет избежать неоднозначности, характерной для таких протоколов, как базовый Paxos, где одновременное выдвижение предложений может замедлять работу узлов или приводить системы в состояние неопределённости.
Окончание следует…
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
Алгоритмы Выбора Главного Узла в Распределённых БД. Продолжение
1. Алгоритм Забияки
2. Кольцевой Алгоритм
3. Алгоритм Paxos
4. Алгоритм Raft
Raft существует, потому что Paxos, несмотря на свою мощь, сложен в реализации и ещё сложнее в понимании. Raft предоставляет те же гарантии безопасности, что и Paxos, например, отсутствие двух лидеров одновременно, согласование журнала и отслеживание прогресса при наличии кворума. Однако архитектуру проще отслеживать, отлаживать и развёртывать.
Каждый узел Raft находится в одном из трёх состояний:
- Ведомый (Follower) - пассивный узел, слушает лидера и отвечает на запросы.
- Кандидат (Candidate) - пытается стать лидером при отсутствии тактовых импульсов.
- Лидер (Leader) - активный узел, который обрабатывает все клиентские запросы и репликацию.
Узлы начинают работу как ведомые. Если они слишком долго не получают ответ от лидера (по тактовым импульсам), они считают лидера мёртвым и запускают выборы (см. диаграмму ниже).
Raft предотвращает конфликты выборов, используя рандомизированные таймауты. Каждый ведомый начинает обратный отсчёт со случайным значением, например, от 150 до 300 миллисекунд. Если до истечения таймера он не получает ответа от лидера, он становится кандидатом и начинает выборы.
Кандидат:
- Увеличивает свой срок полномочий (своего рода счётчик эпох).
- Голосует за себя.
- Отправляет RPC-запросы «RequestVote» всем остальным узлам.
- Другие узлы будут голосовать за кандидата только в том случае, если:
они не голосовали в текущем сроке полномочий и журнал кандидата как минимум не менее актуален, чем их собственный.
- Если кандидат получает голоса большинства, он становится новым лидером и начинает отправлять тактовые импульсы для поддержания своего статуса. Если ни один из кандидатов не побеждает (например, голоса разделились), все ждут и повторяют попытки с новыми таймаутами. Такой рандомизированный подход гарантирует, что один из узлов в итоге опередит остальных.
Raft использует сроки полномочий (term) для отслеживания эпох лидерства. Каждая запись в журнале привязана к сроку полномочий, в котором она была создана. Это позволяет легко обнаруживать и отклонять устаревших или конфликтующих лидеров. Перед голосованием узлы сравнивают журналы. Кандидат с устаревшим журналом будет отклонён, даже если его запрос первым достигнет других узлов. Это гарантирует, что лидером может стать только узел с самой актуальной версией журнала. Затем лидеры реплицируют новые записи журнала на ведомых с помощью RPC-вызовов «AppendEntries». После того, как кворум подтвердил запись, она считается подтверждённой.
Raft решает проблему разделения власти, применяя правила кворума:
- Лидер должен иметь поддержку большинства узлов.
- Два лидера не могут быть активны в одном и том же сроке.
- Ведомый принимает запросы только от лидера текущего срока.
- Если устаревший лидер пытается действовать после разделения сети, он немедленно отклоняется ведомыми с более новым сроком.
Эта чёткая структура позволяет избежать неоднозначности, характерной для таких протоколов, как базовый Paxos, где одновременное выдвижение предложений может замедлять работу узлов или приводить системы в состояние неопределённости.
Окончание следует…
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
👍2
День 2383. #ЗаметкиНаПолях
Алгоритмы Выбора Главного Узла в Распределённых БД. Окончание
1. Алгоритм Забияки
2. Кольцевой Алгоритм
3. Алгоритм Paxos
4. Алгоритм Raft
5. Zookeeper и Zab
ZooKeeper не является БД. Он не хранит записи пользователей, индексы запросов и не реплицирует записи журнала. Вместо этого он играет важнейшую роль в распределённой экосистеме: координирует работу. Когда системам требуется выбрать брокера, управлять отказоустойчивостью лидера или синхронизировать конфигурацию, ZooKeeper — незаменимый сервис.
Внутренне ZooKeeper использует протокол Zab (ZooKeeper Atomic Broadcast). Zab обрабатывает как выбор лидера, так и репликацию состояния, гарантируя безопасность, согласованность и отказоустойчивость даже метаданных координации (см. диаграмму ниже).
Zab обеспечивает надёжность выборов лидера в ZooKeeper. Прежде чем новый лидер сможет начать обработку запросов на запись, он должен синхронизироваться с кворумом ведомых, чтобы убедиться, что у него самое последнее зафиксированное состояние.
Каждая транзакция в ZooKeeper помечается zxid (идентификатором транзакции ZooKeeper), который объединяет эпоху лидера и индекс журнала. Это позволяет узлам определять, кто имеет наиболее актуальную картину мира.
Во время выборов лидера в Zab:
- Предпочтение отдаётся кандидату с наиболее актуальным ZXID.
- Новый лидер должен пройти фазу синхронизации состояния с кворумом, прежде чем сможет фиксировать новые транзакции.
- Если синхронизация не удаётся, выборы завершаются неудачей, и повторяются.
Итого
Каждый алгоритм выборов лидера решает одну и ту же фундаментальную задачу: выбор одного надёжного лидера в распределённой системе. Но они подходят к этому с разными допущениями, компромиссами и эксплуатационными характеристиками.
- Алгоритмы Забияки и Кольцевой используют детерминированные правила, основанные на идентификаторах узлов. Paxos, Raft и Zab используют принятие решений на основе кворума.
- Для обеспечения отказоустойчивости алгоритм Забияки предполагает надёжные соединения и точное обнаружение сбоев. Узел, ложно помеченный как мёртвый, может привести к появлению нескольких лидеров или частым перевыборам. Кольцевой алгоритм останавливается, если любой узел в кольце выходит из строя без предупреждения. В отличие от этого, Paxos, Raft и Zab допускают частичные сбои и продолжают принимать безопасные решения.
- С точки зрения производительности, Raft и ZooKeeper/Zab предсказуемо справляются с перевыборами. Алгоритмы Забияки и Кольцевой неэффективны в средах с высокой текучестью. Paxos, особенно в базовой версии, может испытывать трудности при наличии нескольких предлагающих узлов и нечётком лидерстве, если не использовать такие усовершенствования, как Multi-Paxos.
- Алгоритмы Забияки и Кольцевой просты в реализации. Raft требует больше усилий. Paxos довольно сложно настроить правильно. ZooKeeper/Zab скрывает сложность за API, но лежащие в его основе механизмы нетривиальны.
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
Алгоритмы Выбора Главного Узла в Распределённых БД. Окончание
1. Алгоритм Забияки
2. Кольцевой Алгоритм
3. Алгоритм Paxos
4. Алгоритм Raft
5. Zookeeper и Zab
ZooKeeper не является БД. Он не хранит записи пользователей, индексы запросов и не реплицирует записи журнала. Вместо этого он играет важнейшую роль в распределённой экосистеме: координирует работу. Когда системам требуется выбрать брокера, управлять отказоустойчивостью лидера или синхронизировать конфигурацию, ZooKeeper — незаменимый сервис.
Внутренне ZooKeeper использует протокол Zab (ZooKeeper Atomic Broadcast). Zab обрабатывает как выбор лидера, так и репликацию состояния, гарантируя безопасность, согласованность и отказоустойчивость даже метаданных координации (см. диаграмму ниже).
Zab обеспечивает надёжность выборов лидера в ZooKeeper. Прежде чем новый лидер сможет начать обработку запросов на запись, он должен синхронизироваться с кворумом ведомых, чтобы убедиться, что у него самое последнее зафиксированное состояние.
Каждая транзакция в ZooKeeper помечается zxid (идентификатором транзакции ZooKeeper), который объединяет эпоху лидера и индекс журнала. Это позволяет узлам определять, кто имеет наиболее актуальную картину мира.
Во время выборов лидера в Zab:
- Предпочтение отдаётся кандидату с наиболее актуальным ZXID.
- Новый лидер должен пройти фазу синхронизации состояния с кворумом, прежде чем сможет фиксировать новые транзакции.
- Если синхронизация не удаётся, выборы завершаются неудачей, и повторяются.
Итого
Каждый алгоритм выборов лидера решает одну и ту же фундаментальную задачу: выбор одного надёжного лидера в распределённой системе. Но они подходят к этому с разными допущениями, компромиссами и эксплуатационными характеристиками.
- Алгоритмы Забияки и Кольцевой используют детерминированные правила, основанные на идентификаторах узлов. Paxos, Raft и Zab используют принятие решений на основе кворума.
- Для обеспечения отказоустойчивости алгоритм Забияки предполагает надёжные соединения и точное обнаружение сбоев. Узел, ложно помеченный как мёртвый, может привести к появлению нескольких лидеров или частым перевыборам. Кольцевой алгоритм останавливается, если любой узел в кольце выходит из строя без предупреждения. В отличие от этого, Paxos, Raft и Zab допускают частичные сбои и продолжают принимать безопасные решения.
- С точки зрения производительности, Raft и ZooKeeper/Zab предсказуемо справляются с перевыборами. Алгоритмы Забияки и Кольцевой неэффективны в средах с высокой текучестью. Paxos, особенно в базовой версии, может испытывать трудности при наличии нескольких предлагающих узлов и нечётком лидерстве, если не использовать такие усовершенствования, как Multi-Paxos.
- Алгоритмы Забияки и Кольцевой просты в реализации. Raft требует больше усилий. Paxos довольно сложно настроить правильно. ZooKeeper/Zab скрывает сложность за API, но лежащие в его основе механизмы нетривиальны.
Источник: https://blog.bytebytego.com/p/top-leader-election-algorithms-in
👍4
День 2384. #TipsAndTricks
Как Продолжить Выполнение Процесса После Завершения Задания GitHub Action
После завершения задания GitHub Actions обработчик завершает все запущенные им дочерние процессы. Он идентифицирует эти процессы, проверяя переменную окружения RUNNER_TRACKING_ID. Любой процесс, где эта переменная установлена переменной считается дочерним процессом обработчика и будет остановлен.
Чтобы процесс продолжил работу после завершения задания, запустите его без переменной окружения RUNNER_TRACKING_ID:
Либо:
Примечание: В обработчиках, размещенных на GitHub, это решение не поможет, поскольку вся виртуальная машина удаляется после завершения задания.
Источник: https://www.meziantou.net/how-to-keep-processes-running-after-a-github-action-job-ends.htm
Как Продолжить Выполнение Процесса После Завершения Задания GitHub Action
После завершения задания GitHub Actions обработчик завершает все запущенные им дочерние процессы. Он идентифицирует эти процессы, проверяя переменную окружения RUNNER_TRACKING_ID. Любой процесс, где эта переменная установлена переменной считается дочерним процессом обработчика и будет остановлен.
Чтобы процесс продолжил работу после завершения задания, запустите его без переменной окружения RUNNER_TRACKING_ID:
var psi = new ProcessStartInfo("sample_app");
psi.EnvironmentVariables.Remove("RUNNER_TRACKING_ID");
Process.Start(psi);Либо:
# Вариант 1
$env:RUNNER_TRACKING_ID = $null
# Вариант 2
$psi = New-Object System.Diagnostics.ProcessStartInfo "sample_app"
$psi.EnvironmentVariables.Remove("RUNNER_TRACKING_ID")
[System.Diagnostics.Process]::Start($psi)
Примечание: В обработчиках, размещенных на GitHub, это решение не поможет, поскольку вся виртуальная машина удаляется после завершения задания.
Источник: https://www.meziantou.net/how-to-keep-processes-running-after-a-github-action-job-ends.htm
👍2
День 2385. #TipsAndTricks
5 Современных Возможностей C#, Которые Улучшат Ваш Код
C# стал гораздо более выразительным и мощным языком, чем был ещё несколько лет назад. Вот 5 новинок языка, которые отличают инженеров, просто «знающих C#», от тех, кто использует его на полную.
1. Структуры только для чтения для критически важных для производительности типов-значений
Обычная структура копируется без необходимости, что приводит к скрытым потерям производительности. Отметив её как только для чтения, вы сообщаете компилятору, что её поля никогда не изменятся, что позволяет среде выполнения не создавать защитные копии.
Раньше:
Сейчас:
Для высокопроизводительного кода, такого как графика, игры или API с большим количеством математических вычислений, это небольшое ключевое слово может означать значительную экономию.
2. Ключевое слово scoped для предотвращения использования ref-переменных вне области видимости
C# позволяет использовать ref-переменные для повышения производительности, но распространённой ошибкой является случайное их использование вне области видимости (возвращение ссылки на что-то, что больше не является безопасным). scoped гарантирует во время компиляции, что ссылка не проживёт дольше положенного.
Без scoped:
scoped:
3. Обязательные свойства для принудительной инициализации объекта
Сколько раз вы создавали объект и забывали установить одно из его критически важных свойств? При использовании обязательных свойств компилятор принуждает инициализировать объект.
Раньше:
Сейчас:
4. Возврат типа ref readonly, чтобы избежать защитного копирования
При возврате больших структур возврат по значению часто приводит к ненужному копированию. Возврат типа ref readonly даёт вызывающим функциям ссылку на объект, который они могут читать, но не могут изменять.
Без ref readonly:
С ref readonly:
Это особенно актуально в библиотеках, критичных к производительности, где структуры неизменяемы, но копирование требует больших затрат.
5. Статические абстрактные члены в интерфейсах для обобщённой математики
Это кажется узкоспециализированной функцией, но открывает доступ к настоящей обобщённой математике без рефлексии и упаковки. До появления этой функции нельзя было писать обобщённые алгоритмы, работающие с числовыми типами:
Благодаря статическим абстрактным членам, INumber<T> определяет операторы и константы обобщённо, обеспечивая чистые, независимые от типов математические библиотеки.
Итого
Современный C# — это не просто новый синтаксис; это достижение ясности, безопасности и производительности, которых просто не могли предложить старые версии. Начните внедрять эти функции в свой код, и вы не только начнёте писать лучшее ПО, но и по-новому взглянете на возможности языка.
Источник: https://blog.stackademic.com/5-modern-c-features-that-will-make-your-code-feel-like-magic-d1ef6a374d13
5 Современных Возможностей C#, Которые Улучшат Ваш Код
C# стал гораздо более выразительным и мощным языком, чем был ещё несколько лет назад. Вот 5 новинок языка, которые отличают инженеров, просто «знающих C#», от тех, кто использует его на полную.
1. Структуры только для чтения для критически важных для производительности типов-значений
Обычная структура копируется без необходимости, что приводит к скрытым потерям производительности. Отметив её как только для чтения, вы сообщаете компилятору, что её поля никогда не изменятся, что позволяет среде выполнения не создавать защитные копии.
Раньше:
public struct Point
{
public int X { get; }
public int Y { get; }
public Point(int x, int y) => (X, Y) = (x, y);
}
Сейчас:
public readonly struct Point
{
public int X { get; }
public int Y { get; }
public Point(int x, int y) => (X, Y) = (x, y);
}
Для высокопроизводительного кода, такого как графика, игры или API с большим количеством математических вычислений, это небольшое ключевое слово может означать значительную экономию.
2. Ключевое слово scoped для предотвращения использования ref-переменных вне области видимости
C# позволяет использовать ref-переменные для повышения производительности, но распространённой ошибкой является случайное их использование вне области видимости (возвращение ссылки на что-то, что больше не является безопасным). scoped гарантирует во время компиляции, что ссылка не проживёт дольше положенного.
Без scoped:
ref int Dangerous(ref int number)
{
// Может быть использовано извне и привести к проблемам
return ref number;
}
scoped:
ref int Safe(scoped ref int number)
{
// Компилятор проверяет, что number может
// использоваться только внутри метода
// и выдаёт ошибку компиляции
return ref number;
}
3. Обязательные свойства для принудительной инициализации объекта
Сколько раз вы создавали объект и забывали установить одно из его критически важных свойств? При использовании обязательных свойств компилятор принуждает инициализировать объект.
Раньше:
public class User
{
public string Name { get; set; }
public string Email { get; set; }
}
// Можно забыть инициализировать свойства
var user = new User { Name = "John" };
Сейчас:
public class User
{
public required string Name { get; init; }
public required string Email { get; init; }
}
// Компилятор проверяет полноту инициализации
var user = new User {
Name = "John", Email = "[email protected]" };
4. Возврат типа ref readonly, чтобы избежать защитного копирования
При возврате больших структур возврат по значению часто приводит к ненужному копированию. Возврат типа ref readonly даёт вызывающим функциям ссылку на объект, который они могут читать, но не могут изменять.
Без ref readonly:
public BigStruct GetData() =>
_bigStruct; // Копирует структуру
С ref readonly:
public ref readonly BigStruct GetData() =>
ref _bigStruct; // Нет копирования
Это особенно актуально в библиотеках, критичных к производительности, где структуры неизменяемы, но копирование требует больших затрат.
5. Статические абстрактные члены в интерфейсах для обобщённой математики
Это кажется узкоспециализированной функцией, но открывает доступ к настоящей обобщённой математике без рефлексии и упаковки. До появления этой функции нельзя было писать обобщённые алгоритмы, работающие с числовыми типами:
T Add<T>(T a, T b) where T : INumber<T>
=> a + b;
Благодаря статическим абстрактным членам, INumber<T> определяет операторы и константы обобщённо, обеспечивая чистые, независимые от типов математические библиотеки.
Итого
Современный C# — это не просто новый синтаксис; это достижение ясности, безопасности и производительности, которых просто не могли предложить старые версии. Начните внедрять эти функции в свой код, и вы не только начнёте писать лучшее ПО, но и по-новому взглянете на возможности языка.
Источник: https://blog.stackademic.com/5-modern-c-features-that-will-make-your-code-feel-like-magic-d1ef6a374d13
👍24