Daemon23RUS

по иконке в таскбаре это однозначно фигма — https://figma.com

Приходит update со следующими ключевыми полями:

{
     "my_chat_member": {
         "chat": {
             "id": 5181600575,
         },
         "old_chat_member": {
             "status": "member"
         },
         "new_chat_member": {
             "status": "kicked",
         }
     }
 }

Tj max - температура pn-перехода, выше которой светодиод сгорит. Переход внутри, и непосредственно его охлаждать ты не можешь, но тепло отводится на подложку, а оттуда - на радиатор. Температура подложки Ts и температура перехода Tj связаны так:
Tj = Ts + P*Rth
P - рассеиваемая мощность
Rth - тепловое сопротивление кристалла (⁰C/W), тоже есть в даташите

LED Junction temperature - это температура, при которой будет разрушаться сам полупроводник.
Это точно не та температура, при которой светодиод будет нормально работать.
Ты точно не хочешь уменьшать её.
Для мощных светодиодов охлаждение - это обязательная вещь.

Следи, чтобы температура светодиодов оставалась в диапазоне Operating Temperature (рабочая температура) - тогда всё будет в порядке.

Если вы будете нанимать разработчиков и скажете им что вам нужен интернет магазин с нуля, то ориентируйтесь на минимум в 4-5 миллионов рублей и сроки в 6-12 месяцев.

Если делать на готовой CMS - то ориентируйтесь на 50-100 на разработку шаблона, какого-то доп функционала.

Если делать на готовой CMS но самому - то 0 рублей.

Если использовать облачный SaaS конструктор - то от 1.5 до 3 т.р. в месяц.

Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-sta... for information on currently recommended modes of authentication.

Даже с переводчиком не осилили ошибку?
Авторизуйтесь по ключу и всё заработает.

Это задача NLP - Natural Language Processing
Если вкратце, то работа ведется в несколько этапов:
1. Преобразование звука в текст
2. С помощью NLP этот текст обогащается:
- Форматируется
- Убирается мусор
- Выделяются ключевые слова
3. Готовый текст подается на вход другой нейронке, которая используя свою базу данных (история, контекст) понимает немерение

Собственно, сама работа ведется в последней части. Как эти нейронки работают - другой вопрос. Просто обучают на своих наборах данных

1. Ты запутался из-за того что ты смешал CAP с измеряемыми характеристиками (пропускная способность, доступность, итд)

Доступность
Здесь уже появляется неоднозначность.

Это примерно такая же неоднозначность, как в слове "замок".
Воспринимай это как разные слова из разных контекстов.
HA - это про малое количество сбоев, которые приводят к нулевой доступности.
A из CAP - это про сохранении доступности при выпадении узлов из кластера (если забыть про A, то можно сделать строго консистентную систему из нескольких узлов даже в случае потери связи между узлами - просто вся система будет отключаться)

По идее, здесь мы поддерживаем согласованность, жертвуя.. доступностью? Но ведь нет же! Мы все равно получим ответ.

Да, мы жертвуем доступностью, так как ответ мы не получим, если какой-то узел выпал из кластера => операция записи просто не будет выполнена.
Хотя в реальной жизни мы сразу получим ответ вида "запрос не может быть обработан. Почините кластер"
Пример такой системы - etcd, в которой ты заранее указываешь размер кластера и если кластер не может придти в состояние кворума (доступно N/2+1 узел, где N-количество узлов), то весь кластер переходит в аварийный режим без возможности чтения или записи.
Таким образом гарантируется консистентность даже на отвалившихся от кластера узлах.

Определение доступности из CAP вообще ничего не говорит про задержку (latency).

Потому что CAP не про это.

Резюмируя вопросы:

1. Просто читаем определение:

High availability (HA) is a system's capability to provide services to end users without going down for a specified period of time. High availability minimizes or (ideally) eliminates service downtime regardless of what incident the company runs into (a power outage, hardware failure, unresponsive apps, lost connection with the cloud provider, etc.).

Тоесть да, система вполне может уходить полностью в оффлайн на какое-то время, если это было заранее оговорено.
В пределах разумного, конечно. Если тебе дают гарантированную доступность 1с в год - это какой-то сюр.

Какая правильная и полная формулировка Availability из CAP?

По хорошему тут следует найти первоисточник, но мне лень. Вариант из Википедии достаточно точный, на мой взгляд:

доступность (англ. availability) — любой запрос к распределённой системе завершается откликом, однако без гарантии, что ответы всех узлов системы совпадают;

Любой запрос - любой запрос чтения или записи к любому из работающих узлов системы.
Завершается откликом - значит тебе дают какой-то ответ, который не является ошибкой.
Пример доступной, но не консистентной системы управления кадрами:
Запрос: "Какая зарплата у Иванова?"
Узел 1: 1000 долларов
Узел 2: две тысячи долларов
Узел 3: Иванов у нас не работает

Пример такой же системы, но в которой действует принцип консистентность:
Запрос: Иванов уволен?
Узел 1,2,3: Ошибка: кластер в аварийном режиме.
Либо:
Узел 1,2,3: Иванов не уволен.
Либо:
Узел 1,2: Иванов не уволен
Узел 3: Ошибка: отсутствует кворум.

Запрос: Уволить Иванова.
Узел 1,2,3: Ошибка: кластер в аварийном режиме. Доступно только чтение.
Либо:
Как в третьем варианте, если возможна запись при наличии кворума.

Единственное, как я смог притянуть за уши с существующей формулировкой.

CAP не про это.

Отказоустойчивая система не допускает потери функциональности вообще?

Пуленепробиваемое стекло не допускает пробития пулями вообще?)
В случае катастрофического отказа - возможно всё.

Как, в двух словах хотя бы, проводится измерение производительности и пропускной способности сервиса?

Два слова: нагрузочное тестирование.

Теперь все дополнения тут:

Конфиденциальность. Пользователь уверен, что данные из системы не утекут.

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

Управляемость
Это свойство влияет напрямую на доступность. Если система сложная, плохо настроен мониторинг (логи, трейсы, алерты), нет или просто неудобные инструменты для управления инфраструктурой, все это будет отнимать время на ремонт в случае отказа.

Вообще это в англоязычных источниках называется observability/наблюдаемость.
Ну да ладно. Просто опять смешали несколько вещей в одну.

Можно провести небольшое тестирование, собрать метрику по этому эндпоинту, взять среднее арифметическое и вот тебе производительность для конкретно этого эндпоинта.

Я бы поспорил насчёт среднего арифметического )

Здесь вопрос в том, как мерить общую производительность сервиса?

Никак, ведь нет никакой "общей производительности".
Нагрузочное тестирование существует, но его проводят в профиле какой-то конкретной нагрузки/сценария.

Например в банковской системе могут проводить нагрузочную систему по нескольким сценариям:
1. "Чёрная пятница" - резко увеличивается количество карточных операций.
2. "Реклама у крупного блогера" - резко увеличилось количество запросов на выпуск новой карты. Нужно проверить, как вообще выдержит сервис, отвечающий за эмбоссинг.
3. "Экономике в стране «очень плохо»" - смотрим как выдержит клиринг при большом количестве межбанковских переводов.

Все эти профили нагрузки будут задевать разные части системы и мы сможем сказать, как система будет держаться в каждом из сценариев.

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

Или добавив пакетную обработку.

На задержка напрямую зависит от пропускной способности (производительности) и канала связи. Чем ближе сервер к пользователю, тем меньше задержка.

А вот и нет.
У нас вполне может быть узкий канал с низкой задержкой или же широкий канал с большой задержкой.
А ещё задержка - это время обработки запроса твоей собственной системой.
Например твой сервис вполне может иметь большой latency, но и большой throughput и наоборот.

Сделай из своего приложения службу. Службы запускаются в фоне и без окошка.

лвм, рейд.. Вариантов много. Все зависит от того, что именно вам нужно, и как именно у вас существующая система размечена.

1) Можно создать 7 фолдеров типа /disk1, /disk2 .... и примонтировать диски через mount.
2) Можно собрать ZFS pool из 7 дисков и подключить их все как один большой диск (zpool create).
3) Программный JBOD на базе Btrfs (mkfs.btrfs ... )
4) LVM как уже писали выше