Улучшение технического поля обмена мгновенными сообщениями

задняя часть

[TOC]

Улучшение технического поля обмена мгновенными сообщениями

Основы технологии обмена мгновенными сообщениями

Как обновить серверную программу уровня доступа

Для текущей конкретной службы доступа с длительным подключением Access

Ситуация в проекте ххх, которую я испытал:

  1. Служба уровня доступа доступа, длинное соединение tcp, если его нужно обновить, то нужно ли клиенту снова логиниться?

    • Да, но его можно изменить, а доступ убирается для поддержания длительного соединения.

  2. Доступ делится на уровень подключения и доступ. Первый не включает службы, поэтому не ожидается перезапуска, а второй несет службы. Перезапуски обновления не влияют на соединение. Я также рассмотрю возможность включения push в доступ позже.

  3. Уровень соединения и доступ поддерживают информацию о соединении путем совместного использования памяти.

Для уровня общего доступа

  1. Настройте уровень доступа, чтобы он был с сохранением состояния => без сохранения состояния, уровень доступа и логический уровень строго разделены.

  2. Уровень доступа без сохранения состояния, который можно перезапустить в любое время.

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

Количество длинных TCP-соединений, поддерживаемых одним сервером

  1. Операционная система содержит ограничение на максимальное количество открытых файлов (Max Open Files), которое делится на общесистемное и на уровне процессов.

    • fs.file-max
    • soft nofile/ hard nofile

  2. Каждое соединение через сокет tcp занимает определенный объем памяти.

    • Через тестовую проверку и связанные данные просто сохраняйте соединение и ничего не делайте.Каждое соединение tcp примерно занимает около 4 КБ памяти, а для миллионов соединений ОС требуется более 4 ГБ памяти.
    • Обратите внимание, что вам также необходимо изменить net.ipv4.tcp_rmem/net.ipv4.tcp_wmem.

  3. ограничение сети

    • Предполагая, что 20% из миллиона соединений активны, и каждое соединение передает 1 КБ данных в секунду, требуемая пропускная способность сети составляет 0,2 М x 1 КБ/sx 8 = 1,6 Гбит/с, а сервер должен иметь сетевую карту не менее 10 Гбит/с. (10 Гбит/с).

  4. Некоторые основные часто используемые модификации sysctl:

    • net.ipv4.tcp_mem = 78643200 104857600 157286400
    • net.ipv4.tcp_rmem=4096 87380 16777216
    • net.ipv4.tcp_wmem=4096 87380 16777216
    • net.ipv4.ip_local_port_range = 1024 65535
    • net.ipv4.tcp_tw_recycle=1
    • net.ipv4.tcp_tw_reuse=1
    • fs.file-max = 1048576
    • net.ipv4.ip_conntrack_max = 1048576

    n = (mempages * (PAGE_SIZE / 1024)) / 10;

    PAGE_SIZE:typically 4096 in an x86_64

    files_stat.max_files = n;

  5. механизм epoll, слишком много длинных соединений, повлияет ли это на производительность?

    • Это не повлияет на tcp-соединение и производительность, даже если epoll отслеживает больше событий, это нормально.
    • Помимо того, что помогает нам построить файловый узел в файловой системе epoll, ядро ​​строит красно-черное дерево в кеше ядра для хранения сокетов из epoll_ctl позже, а также строит список-список для хранения готового события, когда вызывается epoll_wait , просто наблюдайте, есть ли данные в списке list.

  6. Что следует учитывать в практических приложениях?

    • Поддержка нескольких очередей сетевой карты, проверьте, поддерживает ли ее сетевая карта, иначе процессор не может очень хорошо обрабатывать сетевые данные, для этого требуется хорошая сетевая карта, а также потребляет процессор

    • Управление узлом для поддержания длинных соединений tcp, требующих потребления ресурсов процессора, требует управления соответствующими структурами данных.

    • На практике следует также учитывать скорость, с которой могут устанавливаться соединения в секунду, потому что миллионы соединений не устанавливаются сразу.Если переподключение будет перезапущено, как насчет скорости соединения?

    • Если эта нода зависнет, что произойдет с распределением запросов?

    • Каковы возможности обработки прикладного уровня для каждого соединения?Какова способность сервера анализировать и обрабатывать пакеты протоколов?

    • Проблема с TCP MEM, память не выделяется, но не обязательно сразу перерабатывается.

  7. Дополнительные соображения для длинных соединений:

    • В случае стабильных подключений показатель количества длинных подключений часто не имеет большого значения по сравнению с отсутствием пропускной способности сети.Поддержание соединения потребляет очень мало ресурсов процессора.Каждое соединение tcp стек протоколов будет занимать около 4k накладных расходов памяти.Система параметры После настройки наши тестовые данные для одной машины могут достигать максимальной продолжительности соединения 300 Вт для одного экземпляра. Но делать более высокий тест лично мне кажется, что в этом мало смысла.

    • В реальной сетевой среде один экземпляр длинного соединения 300 Вт теоретически находится под большим давлением: в реальной слабой сетевой среде скорость отключения мобильного клиента очень высока.Предполагается, что один из 1000 пользователей отключается и снова подключается каждую секунду. . Соединение длиной 300 Вт, новое соединение в секунду достигает 3 Вт, и одновременно подключенные пользователи 3 Вт должны зарегистрироваться, загрузить автономное хранилище и другие внутренние вызовы rpc, а пульс других пользователей длинного соединения 300 Вт необходимо поддерживать. требуется tps в секунду. Пересылка одноадресных и многоадресных данных, а также пересылка широковещательных данных также должны отвечать на внутренние вызовы RPC.В случае длинного соединения 300 Вт можно стабильно гарантировать давление, создаваемое gc, и задержку ответа внутреннего интерфейса. Они сосредоточены в одном экземпляре, где доступность является проблемой. Таким образом, одиночный онлайн-экземпляр не будет поддерживать большое длинное соединение, и реальная ситуация также должна определяться в соответствии с сетевыми условиями клиента доступа.

  8. Следует отметить проблему слишком большого количества close_wait.Из-за нестабильности сети клиент часто отключается.Если сервер не сможет вовремя закрыть сокет, в состоянии close_wait будет слишком много ссылок.

    • Ссылка в состоянии close_wait не освобождает ресурсы, такие как дескрипторы и память.Если отставание слишком велико, система может быть исчерпана, возникнет исключение «Слишком много открытых файлов», и новые клиенты не смогут получить доступ. Операции, связанные с созданием или открытием дескрипторов, завершатся ошибкой.

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

    • На практике мы обнаружили, что некоторые сетевые операторы запретили некоторые порты, заставляя некоторые пользователи подключаться. Чтобы решить эту проблему, могут быть предоставлены несколько IPS и несколько портов, и клиент может опросить, переключиться на более быстрый IP при подключении IP.

  10. TCP_NODELAY

    • Говоря об этой теме, Томпсон считает, что многие люди, думающие об архитектуре микросервисов, плохо понимают TCP. В некоторых сценариях можно столкнуться с задержкой ACK, которая ограничивает количество пакетов, отправляемых по каналу, до 2-5 пакетов в секунду. Это происходит из-за взаимоблокировки, вызванной двумя алгоритмами TCP: Nagle и TCP Delayed Acknowledgement. После тайм-аута в 200-500 мс эта взаимоблокировка снимается, но связь между микросервисами затрагивается отдельно. Рекомендуемое решение — использовать TCP_NODELAY, который отключает алгоритм Нэгла и позволяет последовательно отправлять несколько пакетов меньшего размера. По словам Томпсона, разница составляет от 5 до 500 запросов в секунду.

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

    • Мы обнаружили, что синхронный вызов gRPC конфликтует с алгоритмом Nagle.Хотя gRPC добавил в код socketopt TCP_NODELAY, он не действует в OS X. Позже это было решено установкой net.inet.tcp.delayed_ack = 0, а также мы установили net.ipv4.tcp_low_latency = 1 под linux, чтобы время синхронного вызова при пропускной способности 100M было ниже 500us. А в практических приложениях мы решаем проблему большого количества повторных передач данных через потоковые вызовы, вместо передачи одних и тех же данных через повторные синхронные вызовы, так что одна запись может составлять около 5us. Фактически, пакетная запись всегда была хорошим решением проблем с производительностью.

Обработка, связанная с пульсом

  1. На самом деле сердцебиение выполняет две функции.

    • Сердцебиение гарантирует соединение и мониторинг клиента и сервера, а сервер должен определить, находится ли клиент в сети.
    • Heartbeat также требуется для поддержки GGSN мобильной сети.

  2. Наиболее распространенным является отправка сердцебиений через фиксированное время (например, 4 с половиной минуты), но это недостаточно разумно.

    • Время пульса слишком мало, что потребляет трафик/мощность и увеличивает нагрузку на сервер.
    • Если время подтверждения слишком велико, соединение может быть пассивно разорвано, поскольку политика оператора исключает соответствующую запись в таблице NAT.

  3. Алгоритм сердцебиения (см. сердцебиение стратегии смарт-микроканалов Android)

    • Поддержка мобильной сети GGSN (Gateway GPRS Support Node)
      • Большинство операторов мобильных беспроводных сетей удаляют соответствующую запись в таблице NAT, если в течение определенного периода времени по каналу отсутствует передача данных, что приводит к прерыванию канала. Тайм-аут NAT — важный фактор, влияющий на продолжительность жизни TCP-соединений (особенно внутренних), поэтому клиент автоматически рассчитывает время тайм-аута NAT для динамической настройки интервала пульсации, что является очень важным моментом оптимизации.
    • Обратитесь к набору алгоритмов адаптивного сердцебиения WeChat:
      • Чтобы обеспечить своевременное получение сообщений, используется фиксированное сердцебиение, когда приложение активно на переднем плане.
      • Когда приложение переходит в фоновый режим (или экран закрывается на переднем плане), сначала используйте несколько минимальных тактов для поддержания длинной связи. Затем введите фоновый адаптивный расчет сердцебиения. Целью этого является попытка выбрать период времени, когда пользователь неактивен, чтобы уменьшить влияние несвоевременного сбора сообщений, которые могут быть сгенерированы расчетом пульса.

  4. Упростите пакеты пульса, убедитесь, что размер пакета пульса не превышает 10 байт, и отрегулируйте интервал пакетов пульса в соответствии с передним и фоновым статусом приложения (в основном Android)

Соответствующая обработка в слабой сетевой среде

  1. сетевое ускорение cdn

    • Включая точку ускорения сигнализации и сеть CDN изображений

  2. Истончение и сжатие протокола

    • Используйте алгоритм сжатия для сжатия пакетов

  3. После того, как TCP-соединение через доменное имя в первый раз, IP-адрес кэшируется, и в следующий раз IP-соединение выполняется напрямую; если следующее IP-соединение не удается, снова используется соединение с доменным именем.

  4. Для больших файлов и изображений и т. д. используйте загрузку с помощью точки останова и многокомпонентную загрузку.

  5. Уравновешивание эффектов сетевой задержки и пропускной способности

    • Когда размер пакета меньше 1500 байт, насколько это возможно, пакет запроса на слияние требует сокращения.

  6. ip ближайший доступ

    • ip прямое подключение (доменное имя к ip)
    • Разрешение доменного имени (ip-библиотека), разрешение доменного имени занимает много времени, особенно медленно в мобильных сетях.
    • Рассчитать точки доступа одного и того же оператора, наиболее близкие к географическому положению пользователя

Стратегия отключения и повторного подключения

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

  1. Самый короткий интервал между отключением и переподключением выполняется в последовательности 4, 8, 16 ... (максимум не более 30) в единицу секунд (ов), чтобы избежать частых отключений и переподключения, тем самым уменьшая нагрузку на сервер. Эта политика сбрасывает, когда сервер получает правильный пакет

  2. Если есть сеть, но соединение не установлено, оно будет непрерывно повторяться в последовательности с интервалами 2, 2, 4, 4, 8, 8, 16, 16... (максимум не более 120) в секундах (с). .

  3. Механизм политики после успешного переподключения

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

  4. В таймере повторного подключения, чтобы предотвратить возникновение лавинного эффекта, когда мы обнаруживаем сбой сокета (аномалии сервера), мы не переподключаемся немедленно, а позволяем клиенту случайным образом спать в течение определенного периода времени (или другие стратегии, упомянутые выше). перед подключением к сервису Таким образом, разные клиенты не будут подключаться одновременно при перезапуске сервера, что приведет к лавинному эффекту.

Как бороться с переключением сети, нужно ли переподключаться или заново авторизоваться?

  1. Вообще говоря, если есть сетевой коммутатор (3g->4g->wifi->4g), переподключитесь и повторите весь процесс снова.

  2. Лучше всего, чтобы приложение могло перерегистрировать сервер с минимальным взаимодействием, например, оно больше не получает информацию о конфигурации с сервера и напрямую считывает кэшированные данные конфигурации сервера, которые были извлечены в прошлый раз (если изменения сервера, лучше отправить уведомление об обновлении приложения)

  3. Например, при переключении с wifi на 4G, в метро, ​​в крае WIFI и т.д., во избежание штормов переподключения (поскольку сеть нестабильна, запросы на переподключение будут выдаваться часто) можно использовать слегка отложенный стратегия воссоединения

Как расширить/уменьшить мощность серверной программы План горизонтального расширения?

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

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

  3. Динамическая конфигурация

новости группы

  1. Сообщение пишется или читается: все в группе пишут одно и то же сообщение один раз или группа читает одно и то же сообщение с одного и того же места?

    • Распространение записи: просто, но все в группе должны снова записывать в кеш.Объем данных немного велик, и это увеличивает потребление сети (например, при записи Redis).

    • Расширение чтения: записывать в кеш только одну копию, при вытягивании вытягивать из группового кеша сообщение, нужно добавить немного логической обработки, чтобы данные кеша можно было удалить (или просрочить) после того, как все члены группы вытащили его.

  2. способ отправки

    • Пройдитесь по членам группы и отправьте их последовательно, если они в сети, но когда в группе много участников и группа активна, это может усилить давление.

    • Возможна ли отправка пакетами при обходе членов группы, онлайн-персонала и внутренней циркуляции службы (RPC)?

  3. групповой режим

    • В сети есть только одна копия msg в бд, а индекс все равно пишется и распространяется в кеш и бд.
    • Офлайн, в кеш, пиши диффузию (msg и index), если кеш недействителен, то проникнет в бд тянуть.

  4. Для групповых сообщений каждое сообщение должно извлекать онлайн-статус членов группы. Если оно хранится в Redis, извлечение будет слишком частым. Количество подключений резко возрастет, а параллелизм будет слишком высоким. Помещать в локальный кеш. (уменьшить сетевые подключения и запросы, потребляя память)

Стратегия снижения мощности клиента

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

  2. Минимизируйте сетевые запросы, желательно иметь возможность объединять (или отправлять несколько запросов одновременно).

  3. Скорость загрузки мобильной сети выше, чем скорость загрузки, 2G не должен отправлять слишком много пакетов данных за раз, а 3G/4G отправлять больше за раз для экономии энергии.

Как гарантируется доступность сообщения (не потеря)/уникальность/сохранение порядка?

  1. Заголовок сообщения содержит поле dup.Если это сообщение с повторной доставкой, это поле устанавливается для определения повторной доставки.

  2. Сервер кэширует соответствующий список msgid, клиент отправляет максимальный полученный msgid, и сервер определяет, что все сообщения меньше этого идентификатора были получены в соответствии с максимальным msgid, полученным клиентом, Это гарантирует, что сообщения не будут потеряны.

  3. Сервер обеспечивает чрезвычайно высокую доступность генератора msgid и увеличивает размер msgid, чтобы обеспечить порядок сообщений.

Подробный механизм защиты от потери сообщений

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

  1. Каждый пользователь имеет 4,2 миллиарда пространства последовательностей (от 1 до UINT_MAX), постоянно выделяемых от малого к большему.
  2. Каждому сообщению для каждого пользователя должна быть назначена последовательность
  3. Сервер хранит максимальную последовательность, на которую был назначен каждый пользователь.
  4. Максимальная последовательность полученных сообщений сохраняется на мобильном телефоне
    image.png

** Преимущества программы **

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

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

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

Метод связи (TCP/UDP/HTTP) использует как tcp, так и http.

  1. Основные требования системы обмена мгновенными сообщениями: включая учетную запись, цепочку отношений, отображение онлайн-статуса, взаимодействие с сообщениями (текст, изображение, голос), аудио и видео в реальном времени.

  2. режим http (короткая ссылка) и режим tcp (длинная ссылка), для протокола состояния и протокола передачи данных соответственно

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

  4. При получении других несвоевременных ресурсов используйте короткие соединения http.Почему бы не использовать все протокол TCP?В чем преимущества использования протокола http?

    • В настоящее время большинство функций можно реализовать через TCP.
    • Если вы загружаете и загружаете файлы, это должен быть http.
      • Поддерживает возобновляемую загрузку и многокомпонентную загрузку.
    • Модель в автономном режиме обмена сообщениями, избегать давления канала TCP слишком велико, влияющая на эффективность обмена мгновенными сообщениями
    • Большие граффити и файлы загружаются с помощью сервисов хранения, чтобы избежать чрезмерной нагрузки на tcp-канал.

  5. Должен ли IM использовать протокол UDP или TCP?

    • UDP и TCP имеют свои собственные сценарии применения.В качестве IM, в раннем IM, поскольку ресурсы сервера (серверное оборудование, пропускная способность сети и т. д.) дороги и нет лучшего способа разделить нагрузку на производительность, часто рассматривают UDP. , который в основном представлен ранним QQ.

    • Нагрузка на сервер TCP имеет очень хорошее решение в сочетании со снижением стоимости серверных ресурсов и наличием большого количества решений для обмена мгновенными сообщениями, push-сообщениями, которые также используют TCP в качестве протокола транспортного уровня. Тем не менее, UDP также не исключается из решения IM, Push-сообщения, такие как: слабая сетевая связь (включая трансграничную сетевую среду с высокой задержкой), связь в рамках M2M, IM в режиме реального времени, аудио- и видеосвязь и т. д. сцена, UDP по-прежнему является предпочтительным вариантом.

    • Что касается того, следует ли IM выбирать UDP или TCP, это вопрос благожелательного мнения. Не нужно слишком запутываться. Пожалуйста, всесторонне рассмотрите ваши сценарии приложений IM, затраты на разработку, затраты на развертывание и эксплуатацию и т. д., я думаю, вы можете найти то, что вы хотите Ответить.

Выбор протокола связи для сервера и клиента

  1. Обычно используемые протоколы обмена мгновенными сообщениями. Принципы выбора протокола обмена мгновенными сообщениями в целом следующие: простота расширения, удобство охвата различной бизнес-логики и экономия трафика. Является ли последнее требование особенно важным для мобильного обмена мгновенными сообщениями?

    • xmpp: протокол с открытым исходным кодом и широкими возможностями расширения.Он реализован на разных языках на каждом конце (включая сервер), что удобно для разработчиков. Но есть и много недостатков: XML слаб в выразительности, слишком много избыточной информации, большой трафик, много провалов в реальном использовании.

    • MQTT:Протокол простой и трафик низкий, но это не протокол, специально разработанный для обмена мгновенными сообщениями. Он в основном используется для push. Вам нужно внедрить в свой бизнес групповые, связанные с друзьями и т. Д. Он подходит для продвигайте бизнес- и живые сценарии обмена мгновенными сообщениями.

    • SIP: в основном используется для модулей, связанных с VOIP, это текстовый протокол.Управление сигнализацией SIP более сложное.

    • Частный протокол: реализуйте протокол самостоятельно. Большинство популярных приложений для обмена мгновенными сообщениями используют частные протоколы. Хорошо спроектированный частный протокол обычно имеет следующие преимущества: высокая эффективность, экономия трафика (обычно с использованием двоичных протоколов), высокая безопасность и сложность взлома.

  2. Соображения по разработке протокола:

    • Размер сетевых данных - занимаемая полоса пропускания, эффективность передачи: хотя объем передаваемых данных невелик для одного пользователя, чтобы серверная сторона могла выдерживать большое количество одновременных передач данных с большим объемом, необходимо учитывать полосу пропускания, занимаемую данными, и постарайтесь не иметь избыточных данных, чтобы занимать меньшую полосу пропускания, меньше ресурсов, меньше сетевых операций ввода-вывода и повышать эффективность передачи;

    • Безопасность сетевых данных - сетевая безопасность конфиденциальных данных: некоторые передачи данных для связанных служб являются конфиденциальными данными, поэтому необходимо рассмотреть возможность шифрования части передаваемых данных.

    • Сложность кодирования - сложность сериализации и десериализации, эффективность, масштабируемость структур данных

    • Общность протоколов — общедоступная спецификация: типы данных должны быть кроссплатформенными, а форматы данных — общими.

  3. Сравнение распространенных протоколов сериализации

    • Протоколы с открытым исходным кодом, которые предоставляют библиотеки сериализации и десериализации: pb, Thrift.Довольно удобно расширять, и сериализация и десериализация удобны

    • Текстовый протокол: xml, json.Сериализация и десериализация просты, но занимают много места.

  4. Определение аспектов протокола

    • Пакетные данные можно считать сжатыми для уменьшения размера пакета.

    • Пакетные данные учитывают шифрование для обеспечения безопасности данных

    • Некоторые поля в протоколе имеют формат uint64, который можно соответствующим образом настроить на uint32.Уменьшить размер заголовка пакета.

    • Который предпочтительно содержит заголовок протокола seq_num

      • Это для асинхронной поддержки. Наиболее важному мнению канала сообщения - решить проблему канала. Все обработка сообщений не может быть синхронно, она должна быть асинхронной. Вы отправляете сообщение, ABC три пакеты, а после получения XYZ три пакеты, как вы получите Знайте, что это соответственно, как мы имеем дело с соответствующими отношениями, то есть добавить идентификатор

Основные аспекты проектирования архитектуры системы обмена мгновенными сообщениями

  1. Угол кодирования: Принять эффективную сетевую модель, модель потоков, модель обработки ввода-вывода, разумный дизайн базы данных и оптимизацию операторов операций;

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

  3. Горизонтальное расширение: балансировка нагрузки за счет разумного проектирования архитектуры и стратегий эксплуатации и обслуживания для эффективного повышения производительности; позже вы даже можете рассмотреть возможность добавления уровня кэширования данных, чтобы преодолеть узкое место ввода-вывода;

  4. Высокая доступность системы: предотвращение единой точки отказа;

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

  6. Для ключевых независимых узлов могут быть использованы двойные машины горячей резервной технологии

  7. Безопасность данных базы данных может быть решена за счет избыточной конфигурации дисковых массивов и первичных и вторичных баз данных.

Решение проблемы перегрузки TCP

Контроль перегрузки TCP состоит из четырех основных алгоритмов: «Медленный старт», «Предотвращение перегрузки», «Быстрая повторная передача» и «Быстрое восстановление».

Как определить, отстает ли очередь кафки?

Кафка очередь, нет понятия полного, есть понятие отставание/накопление потребления

  1. Мониторинг kafka в режиме реального времени с помощью мониторинга офсетного монитора

  2. для кафки

    • Он сам является распределенным и может поддерживать это линейное расширение, поэтому он не столкнется с этой проблемой.

    • Будете ли вы записывать данные, не потребляя их?

Сценарии манипулирования кэшами и базами данных

  1. Запись: сначала запишите базу данных, после успеха обновите кеш

  2. Чтение: сначала прочитайте кеш и проникните в БД, если данных нет.

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

план:

  1. Устраняйте сначала кеш, а потом записывайте в базу.Однако несогласованность может возникнуть и при одновременном выполнении, то есть если кеш устранен, а бд вовремя не записана, то при поступлении запроса на чтение она будет прочитана прямо из БД Получить старые данные.

    • Поэтому необходимо строго следить за тем, чтобы операции над одними и теми же данными были последовательными.

  2. Благодаря параллельному чтению и записи на уровне базы данных проблему несогласованности между базой данных и кэшированными данными (по сути, запрос на чтение, который происходит позже, возвращается первым) можно решить двумя небольшими изменениями:

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

    • Измените пул соединений с БД базы данных и выберите соединение с БД по модулю идентификатора, что может гарантировать последовательное чтение и запись одних и тех же данных на уровне базы данных.

Подтаблица базы данных

Почему база данных должна быть подбазой и подтаблицей?При каких обстоятельствах подбаза данных является подтаблицей?

  1. Разрешение максимального ограничения файловой системы на диске

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

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

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

  5. Когда объем данных очень велик, роль индекса B-Tree не так очевидна. Если объем данных огромен, будет генерироваться много случайных операций ввода-вывода, а время отклика базы данных будет неприемлемо большим.

    • Большой объем данных, когда глубина дерева B-TREE становится глубже, увеличивает количество операций ввода-вывода от корневого узла до конечных узлов. После более чем четырех слоев ввода-вывода он станет очень медленным, на самом деле, четыре уровня ввода-вывода, хранение данных на уровне ТБ, если вы не являетесь типом данных INT и другим небольшим типом. BTREE не может сказать, что не работает, но эта роль не столь очевидна.
    • Объем данных огромен, должен ли это быть случайный ввод-вывод? Это не обязательно так: если используются все запросы первичного ключа, записи 10E могут быстро возвращать результаты. Когда вторичный индекс используется для запроса, он становится случайным вводом-выводом, и время ответа будет медленнее, что также зависит от распределения данных. Кроме того, он не упомянул носитель данных.Если используется SSD-диск, случайный ввод-вывод в 100 раз сильнее, чем у SAS, и производительность тоже хорошая.

горутины на Голанге

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

  2. Для создания горутины требуется около 2 КБ (V1.4) пространства стека.

  3. go имеет упреждающее планирование: если горутина занимает ЦП и не планировалась в течение длительного времени, она будет вытеснена средой выполнения.

Означает ли это, что при условии достаточного объема памяти создание определенного количества горутин (например, 30w, 50w) не приведет к слишком сильному падению производительности из-за планирования процессора?

  1. Если там идет слишком много, вероятно, одна из причин, потому что каждое время обработки Goroutine слишком длинно, тогда вам нужно понять, почему процесс занимает больше времени.

  2. Учитывая приблизительные данные, на сервере с 24 ядрами и 64G, когда QoS является как минимум сообщением, чистым push, а тело сообщения составляет 256B~1kB, один экземпляр 100w реальных пользователей (200w+) сопрограмм, пиковое значение может достигать 2~5w QPS ... Память может быть стабильной на уровне около 25G, а время gc составляет около 200~800 мс (еще есть место для оптимизации). (Поделиться из системы сообщений 360)

Управление сетевым соединением на уровне доступа длинных соединений

Есть много сетевых соединений на уровне доступа длинного соединения.Как правило, один сервер может иметь сотни тысяч или даже миллионы.Так как же управлять этими соединениями?Когда приходят внутренние данные,как быстро найти соединение, соответствующее на этот запрос?Подключение и пользователь Как переписываться

Управление длинными TCP-соединениями

  1. Структура соединения. Содержит информацию о TCP-соединении, время последней связи, общий ключ шифрования и дешифрования, адрес клиента. Также содержит структуру пользователя.

    • Структура пользователя содержит uid, deviceid.name, version...., а также указанное выше подключение, которые по очереди соответствуют друг другу.

    • Не используйте карту для управления, а сделайте взаимно однозначное соответствие между информацией о tcp-соединении и информацией о пользователе.Если есть карта, миллионы могут долго не находить.

    • Когда делается запрос на вход, информация о пользователе может быть получена в соответствии с информацией о соединении tcp, но в это время информация о пользователе в основном не заполняется какими-либо данными, поэтому структура информации о пользователе должна быть заполнена в соответствии с логином. ключ:В текущей службе доступа Access будет useMap, который будет соответствовать uid и информации о пользователе, которые можно использовать для определения того, был ли uid зарегистрирован в этом экземпляре.

    • При возврате данных вы можете получить соответствующую структуру пользователя в соответствии с этим uid, а затем вы можете получить соответствующую информацию о соединении tcp через эту структуру, и вы можете отправить информацию.

  2. Кроме того, при входе и выходе из пользовательского центра будет добавляться и удаляться дополнительная информация о соединении (uid/topic/protoType/addr...).

    • Вход выполнен успешно: UseAddConn
    • Выход: UserDelConn
    • Информация о соединении здесь используется для других вызовов удаленных служб, таких как Oracle.

  3. Если имеется несколько уровней доступа Access, каждый уровень доступа будет иметь структуру useMap.

    • Если несколько терминалов входят в одну и ту же учетную запись и находятся в разных Access, их нельзя отключить с помощью useMap, и для управления отключением требуется пользовательский центр, упомянутый на предыдущем шаге.
    • Множественный доступ означает несколько useMaps, поэтому вам нужно убедиться, что запрос, отправленный из определенного доступа, обязательно вернется в текущий доступ. время, согласно ip:addr доставленного Access, вернуться к соответствующему Access.
    • Затем по uid получается структура пользователя и структура tcp соединения, соответствующая текущему uid.

Структура данных: карта/хэш (красно-черное дерево)

Управление отправкой и получением исключений, запросить ответ ACK, время ожидания

  1. Используя структуру данных карты, после отправки (публикации) сообщения немедленно добавьте соответствующее тело сообщения в структуру карты через msgid и uid.

  2. Получив ответ, удалите соответствующую структуру карты.

  3. По истечении тайм-аута повторно отправьте OfflineDeliver, а затем удалите соответствующую структуру карты.

Когда асинхронный и параллельный, как инфраструктура rpc узнает, какой запрос какой?

  1. Каждый раз, когда клиентский поток вызывает удаленный интерфейс через сокет, он генерирует уникальный идентификатор, то есть requestID (requestID должен быть гарантированно уникальным в соединении сокета).Как правило, AtomicLong часто используется для накопления чисел от 0 для генерации уникальный идентификатор или используйте время Poke для создания уникального идентификатора.

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

  3. Синхронные вызовы RPC блокируются до тех пор, пока не будет получен ответ от сервера, что является наиболее близкой абстракцией к тому, что нужно RPC. Сеть, с другой стороны, внутренне асинхронна, и во многих случаях полезно иметь возможность инициировать RPC, не блокируя текущий поток. На большинстве языков интерфейс программирования gRPC поддерживает как синхронные, так и асинхронные функции.

  4. gRPC позволяет клиентам указывать крайний срок перед вызовом удаленного метода. Это значение указывает, как долго клиент может ждать ответа сервера, после чего RPC завершится с ошибкой DEADLINE_EXCEEDED. Значение срока действия можно запросить на сервере, чтобы узнать, истек ли срок действия конкретного метода или сколько времени осталось для завершения метода. Способ, которым каждый язык определяет крайний срок, отличается

Вопросы производительности службы

  1. Угол кодирования:

    • Принять эффективную сетевую модель, модель потоков, модель обработки ввода-вывода, разумный дизайн базы данных и оптимизацию операторов операций;

  2. Вертикальное расширение:

    • Повысить производительность, увеличивая единичные серверные аппаратные ресурсы или сетевые ресурсы;

  3. Горизонтальное расширение:

    • Благодаря разумному дизайну архитектуры и стратегиям балансировки нагрузки при эксплуатации и обслуживании нагрузка распределяется для эффективного повышения производительности, на более позднем этапе вы даже можете рассмотреть возможность добавления уровня кэширования данных, чтобы преодолеть узкое место ввода-вывода;

  4. Высокая доступность системы:

    • предотвратить единую точку отказа;

  5. В архитектуре бизнес-обработка и данные разделены, что позволяет использовать распределенное развертывание для обеспечения доступности системы в случае единой точки отказа.

  6. Для ключевых независимых узлов для переключения можно использовать технологию горячего резервирования с двумя машинами.

  7. Безопасность данных базы данных может быть решена за счет избыточной конфигурации дисковых массивов и первичных и вторичных баз данных.

Анализ узких мест сервера

Через нагрузочное тестирование известно, что gRPC является одним из узких мест.Почему это grpc?Почему он потребляет процессор?Как это решить?Сеть не повлияет на пропускную способность.

  1. Принят армейский метод.Можно рассмотреть потоковый метод.Пакетная отправка для повышения эффективности

    • Метод uarmy — один к одному, когда параллелизм увеличивается, количество соединений будет увеличиваться.

    • Метод потоковой передачи заключается в объединении нескольких запросов (пакетных запросов/ответов), сокращении сетевых взаимодействий и уменьшении подключений.

    • Я провел тест потоковой передачи под давлением, и говорят, что производительность более чем в два раза выше, чем у одинарного

  2. Как правило, сервер будет действовать по параболическому закону: по мере увеличения количества параллелизма он будет постепенно потреблять и работать на полную мощность (процессор/память/пропускная способность сети/дисковый ввод-вывод), что приведет к увеличению времени отклика (задержка становится большой) и qps/пропускная способность не растет.

  3. Для grpc после увеличения числа concurrency виден фактический эффект, что задержка увеличивается, а время ответа одного запроса на некоторые запросы достигает около 5с (ACCESS/PUSH), значит задержка слишком большая, qps /throughput=Количество параллелизма/времени отклика.Если время отклика слишком велико, пропускная способность, конечно, не увеличится.

    • Почему время отклика такое долгое?Это потому что процессор заполнен?

    • Другая причина в том, что ответ медленный, то есть окончательный запрос будет идти к сервису Oracle, а оракул будет запрашивать ресурсы данных (cache/db).Задержка увеличивается, поэтому вызов возврата к верхнему grpc также будет увеличить задержку.

    • Таким образом, ключ, наконец, возвращается к процессору/памяти/пропускной способности сети/диску.

  4. Для rpc увеличение количества подключений приведет к:

    • Подобно длинным соединениям tcp, каждому соединению должен быть выделен определенный объем памяти.

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

  5. Позже, после расследования, мы обнаружили, что синхронный вызов gRPC будет конфликтовать с алгоритмом Nagle.Хотя gRPC добавил в код socketopt TCP_NODELAY, это не имело никакого эффекта в OS X. Позже это было решено установкой net.inet.tcp.delayed_ack = 0, а также мы установили net.ipv4.tcp_low_latency = 1 под linux, чтобы время синхронного вызова при пропускной способности 100M было ниже 500us. А в практических приложениях мы решаем проблему большого количества повторных передач данных через потоковые вызовы, вместо передачи одних и тех же данных через повторные синхронные вызовы, так что одна запись может составлять около 5us. Фактически, пакетная запись всегда была хорошим решением проблем с производительностью.

Как быстро получить доступ к уровню доступа сервера

Если сервер в Пекине, а клиент в Гуанчжоу, как мне быстро получить к нему доступ, есть ли другой способ, кроме как через CDN?

  1. Если есть только один дата-центр, другого пути, кроме ускорения CDN, пока нет.

  2. При наличии двух центров обработки данных можно принять принцип близости, но данные двух центров обработки данных необходимо синхронизировать

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

Как я могу улучшить свои способности в области IM?

  1. Необходимо иметь возможность оценить количество запросов в секунду, которое система может поддерживать без стресс-тестирования.Необходимо примерно оценить, сколько времени занимает запрос к базе данных, сколько времени занимает запрос redis и сколько времени занимает вызов rpc?

    • Какая из систем требует больше времени и процессора?

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

    • Введены ли в систему другие ресурсы?

    • Узким местом производительности не может быть процессор / ввод-вывод.

    • Запрос к БД медленный, почему он медленный?Должна быть причина медлительности?

      • Время запроса оператора sql составляет примерно 0,2-0,5 мс (в случае небольшого количества данных таблицы, независимо от того, основан ли запрос на идентификаторе индекса, разница невелика).

    • Для одной машины qps составляет 8 к, что относительно мало. одновременно отправлять и получать расчеты. Если используется один qps, то qps уменьшается вдвое, то есть 2w qps, 10w онлайн одновременно, и каждый человек отправляет сообщение каждые 3-4 с, что требует qps до 3w .

    • Когда я тестировал Redis раньше, я тестировал его: если параллелизм слишком высок, для извлечения Redis потребуется много времени, более 3 с.

    • В нормальных условиях человеку требуется не менее 5 секунд (6-8 слов), чтобы отправить сообщение.

  3. Для дальнейшего совершенствования технологии обмена мгновенными сообщениями вы должны уметь анализировать производительность, находить узкие места в производительности и устранять их.

    • Это также зависит от практики других, таких как WeChat.

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

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

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

    • Полностью понимать значение базовых инструментов системы, таких как sar, iosta, dstat, vmstat, top и т. д. Эти данные следует часто просматривать.

    • Убедитесь, что все части, задействованные во всей системе, отмечены белым ящиком.

      • Кто отвечает за другие зависимые службы, ситуацию с развертыванием и в каком компьютерном зале

      • Сколько используется памяти Redis? Сколько базы данных MySQL? Сколько таблиц? Как распределено master-slave? Для сообщений: один master и два slave, 32 базы данных, 32 таблицы. Для данных друзей: один master и один раб, 128 табл., разделенных по месяцам.

Резюме и как думать о проблемах и повышать самооценку

  1. Если вы не думаете сами, существующие вещи разумны, что, очевидно, не сработает.

    • Каждый раз, когда вы смотрите на что-то, вы должны думать: разумна ли эта вещь, можно ли ее оптимизировать, в чем сходство?

    • Например: когда я впервые соприкоснулся с проектом ххх, я почувствовал, что архитектура хорошая, и я чувствовал, что нет необходимости ее оптимизировать, однако после того, как масштабное продвижение понадобилось позже, ххх предложил некоторые моменты оптимизации Благодаря усовершенствованию на порядок были выявлены некоторые проблемы.

      • После большого параллелизма проблема медленного запроса mysql

      • После большого параллелизма слишком много одновременных запросов на ресурсы и слишком много подключений, поэтому необходимо объединить запросы на ресурсы

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

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

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

    • Когда текущий уровень - уровень W, вы должны подумать, что вам нужно сделать на уровне 100 000. После уровня 100 000 вы должны рассмотреть миллион. Вы не должны делать это сразу, но сначала вы должны подумать ,рассмотрите сначала,как текущая производительность,как работает?Расширение?Как рефакторить?

  4. Понять соответствующие технические решения отрасли и понять ямы, на которые наступили другие.После того, как объем последующих действий будет большим, он может предоставить лучшие технические методы и архитектуры и развиваться в направлении старшего им/им передового, а не ограничено только проектами xxx. Чтобы иметь возможность сосредоточиться на всем направлении мышления в области IM

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

["Добро пожаловать, обратите внимание на мою общедоступную учетную запись WeChat: разработка серверной системы Linux, и позже я буду активно отправлять высококачественные статьи через общедоступную учетную запись WeChat"]

我的微信公众号

Категории