Как Git Push обрабатывает отставание

Question

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

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

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

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

Мои вопросы:

Действительны ли мои опасения?Будут ли эти процессы склеивать работы, пока они не будут получены центром?Клиенты не будут знать об этом состоянии, потому что процессы проталкивания будут отключены от первоначального приема.Однако они увидят, что изменения будут задерживаться при появлении на других удаленных серверах.

Если эти процессы завершатся неудачно, произойдет ли сбой в зависимости от интервала ожидания для sshd или у самого git есть метод указанияинтервал ожидания?

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

Можете ли вы указать мне на некоторые темы или статьи, связанные с этой темой?

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

Answer 1

Вы на самом деле смотрите на громкость пуша настолько высокую, что это может сделать сервер? Я не совсем уверен в вашем вопросе.

толчки работают так:

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

Передача может происходить параллельно. Поэтому все, о чем вам действительно нужно беспокоиться, это о том, достаточно ли у вас емкости сети, чтобы выдержать все нагрузки, и я сомневаюсь, что это проблема. Толчки и извлечения очень маленькие. Они передают только необходимые объекты (ничего, что уже находится на другой стороне), и они дельта-сжимают содержимое на основе объектов, которые уже есть на другой стороне, поэтому размер пропорционален размеру diff переданные коммиты представляют. Если вы не можете справиться с передачей такого большого количества данных, то я не уверен, что любая распределенная система управления источниками когда-либо будет работать для вас.

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

Прежде всего, если вы на самом деле смотрите на тысячу разработчиков, возможно, они не все работают над чем-то в одном и том же хранилище, верно? И если они ... вы, вероятно, хотите разделить это. Если вещи нужно связать вместе на каком-то высоком уровне, взгляните на субмодули. Так, например, хранится исходный код ядра Linux. Есть много битов, каждый в своем подмодуле, которые затем являются частью родительского репозитория. Не много людей должны связываться с родительским хранилищем; они просто имеют дело с репо для подмодуля, над которым работают, и над этим работают не так много людей. Вы действительно не хотите быть в ситуации, когда у вас есть монолитный репозиторий, представляющий 10 миллионов строк кода.

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

Наконец, если вы можете избежать этого, постарайтесь не делать хаб / спиц. Крупные проекты с открытым исходным кодом успешно размещаются в отдельных репозиториях, поэтому, вероятно, это будет работать и для вас. Помните, что большинство операций являются инкрементными (push / fetch), а не итоговыми (clone), поэтому они не передают тонну данных. Если пропускная способность является проблемой, вам снова поможет правильное разделение репозиториев; это уменьшит объем передаваемых данных.