Апачи что это такое

История Apache

В марте 1989 года Тим Бернерс Ли, английский ученый, работающий в CERN (Швейцария), предложил новый способ управления огромным количеством информации в проектах CERN. В то время никто не знал, что такое Apache. Первичная разработка сети документов с гиперссылками, как их назвал Тед Нельсон в 1965 году, привела к созданию WWW – первого программного обеспечения, которое вышло в ноябре 1990 года под названием World Wide Web, с веб-браузером, графическим интерфейсом и редактором WYSIWYG. Два года спустя в списке WWW-серверов было всего около тридцати записей, среди которых был HTTPs NCSA.

Настоящая история «Апач» начинается в марте 1995 года с выпуском Apache 0.2 на основе сервера NCSA HTTPD 1.3. Многим пользователям интересно знать, что такое Apache сегодня и что программа представляла из себя в первые месяцы своего существования. Это был всего лишь набор правок, применяемых к серверу NCSA. Далее Роберт Тау выпустил Shambhala 0.1 с API для модулей, которые оказались очень успешными.

Крупнейшими вехами проекта было полное соответствие стандарту HTTP 1.1, включенному в апреле 1997 года в версию 1.2. В эту версию уже была включена платформа Windows NT, которая стартовала в июле 1997 года. Объединение файлов конфигурации было реализовано в выпуске 1.3.3.

Apache Group отвечает за эволюцию веб-сервера и конкретные решения по разработке. Эту группу следует отличать от разработчиков ядра – Core group. Добровольный характер большинства разработчиков делает маловероятным то, что все они одновременно активны в «Апач», поэтому ядро отвечает за постоянную работоспособность. В общем, решения, которые должны принимать разработчики, принадлежат ядру и ограничиваются голосованием за включение кода. С другой стороны, они обычно имеют право на запись в репозиторий CVS, поэтому служат воротами для кода, обеспечивая его правильность и качество.

Минимальные требования и преимущества

Apache получил широкое признание в сети, с 1996 года он является наиболее часто используемым HTTP-сервером. Достигнул своей максимальной доли рынка в 2005 году, когда сервер использовался на 70 % сайтов во всем мире. В последние годы его доля на рынке сократилась. Примечательно то, что для Apache такой спад не свидетельствует о непопулярности и деградации технологии.

Минимальные требования для эксплуатации:

1. Процессор – Pentium.
2. Оперативная память – 64 Мб.
3. ОС-Microsoft Windows, GNU/Linux.
4. Размер установки- 50 Мб.

Преимущества:

1. Модульная конструкция.
2. Открытый исходный код.
3. Мультиплатформенная конструкция.
4. Растяжимость.
5. Популярность – легко получить помощь и поддержку.

Архитектура сервера

Модульный сервер «Апач» состоит из основного раздела и различных модулей, предоставляющих большую часть базовых функций. Некоторые из этих модулей:

1. mod_ssl – безопасная связь через TLS;
2. mod_rewrite – перезапись адреса, обычно используется для преобразования динамических страниц, таких как php, в статические, чтобы обмануть поисковые системы относительно того, где они были разработаны;
3. mod_dav – поддержка протокола WebDAV (RFC 2518) ;
4. mod_deflate – алгоритм сжатия прозрачен, когда содержимое отправляется клиенту;
5. mod_auth_ldap – позволяет пользователям проходить аутентификацию на сервере LDAP;
6. mod_proxy_ajp – соединитель для связи с Jakarta Tomcat динамических страниц в Java (сервлеты и JSP).

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

• mod_cband – управление трафиком и ограничение полосы пропускания;
• mod_perl – динамические в Perl;
• mod_php – динамические в PHP;
• mod_python – динамические в Python;
• mod_rexx – динамические в REXX и объект REXX;
• mod_ruby – динамические в Ruby;
• mod asp dot net – динамические в Microsoft.NET;
• mod_mono – динамические в моно;
• mod_security – фильтрация на уровне приложения для безопасности.

Конфигурация и безопасность

Для того чтобы понять, что такое Apache в свете безопасности, нужно рассмотреть его конфигурацию. Большая часть конфигурации выполняется в файле apache2.conf и httpd.conf, в зависимости от системы, в которой ПО работает. Любое изменение этого файла требует перезапуска сервера или повторного принудительного чтения.

Лицензия на программное обеспечение, по которой распространяется базовое ПО «Апач», является отличительной частью истории Apache HTTP Server и сообщества открытого исходного кода. Лицензия позволяет распространять продукты с открытым и закрытым исходным кодом.

Фонд свободного ПО не считает таковым Apache License, совместимого с версией 2 GNU General Public License (GPL), в которой программное обеспечение лицензируется и не интегрировано с ПО. Это нужно учитывать, перед тем как настроить веб-сервер Apache, распространяемого под лицензией GPL. Тем не менее версия 3 GPL включает в себя положение, которое позволяет ему быть совместимым с лицензиями, имеющими оговорки о патентном возмещении.

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

Проверка функционирования Апач

Чтобы убедиться, что «Апач» работает правильно, открывают веб-браузер и прописывают следующий адрес: http: // localhost. Затем нажимают Enter, появляется белая страница с сообщением «Это работает», что является доказательством того, что веб-сервер работает отлично.

«Апач» позволяет создавать специальные конфигурации для настройки и адаптации к потребностям. Для этого находят файл http.conf в C: appserv Apache2.2 conf. Создается его резервная копия, чтобы избежать ошибок выполнения, затем его открывают посредством любого редактора и изменяют нужные строки.

Чтобы правильно выполнить эти действия, нужно хорошо знать Apache worker, поскольку любые сделанные изменения будут отражены в производительности и запуске «Апач». Благодаря последним рекомендациям сервер будет установлен. Работать он будет в базовой конфигурации, которая позволяет загружать страницы или сетевые приложения в интернет.

Управление информацией

Apache – наиболее используемый веб-сервер, лидер с наибольшим количеством установок в мире, намного опережающий другие решения, такие как Microsoft Internet Information Server (IIS). Этот проект открыт для использования, так как он мультиплатформенный, имеющий версии для всех основных операционных систем, очень надежный и выделяющийся своей безопасностью и производительностью.

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

1. Эффективность запросов.
2. Большое количество HTTP-запросов, включая многозадачное выполнение, может оставить сервис свернутым.
3. Ограничения на доступ к файлам, управления аутентификации пользователей или фильтрации запросов в соответствии с их происхождением.
4. Обработка ошибок по страницам с информацией посетителя и перенаправлением на заранее определенные страницы.
5. Управление информацией, подлежащей передаче в соответствии с ее форматом, и адекватное информирование браузера, запрашивающего указанный ресурс.
6. Журнал управления для хранения полученных запросов, произошедших ошибок и в целом всей информации, которая зарегистрирована и проанализирована для получения статистики доступа к сайту.

«Апач» позволяет настраивать виртуальный хостинг на основе IP-адресов или имен, то есть иметь несколько веб-сайтов на одном компьютере.

Файл apache2.conf

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

Он находится в каталоге /etc /apache2, и, поскольку это текстовый файл, его можно легко редактировать с помощью текстового редактора. Свойства файла конфигурации – глобальные переменные сервера и расширение функциональности.

Глобальные переменные сервера – это переменные, которые определяют общее функционирование:

1. Таблица директив «Апач». Имя сервера обозначено переменной ServerName, поэтому любое перенаправление или ссылка, существующие в HTML-документах, работают хорошо. Большинство переменных конфигурации распределены среди других небольших файлов, хранящихся в mods-available.
2. .htaccess – это скрытый текстовый файл, который позволяет настроить работу сервера.
3. «Апач» – конкретный каталог без необходимости изменять основной файл конфигурации apache2.conf. Когда веб-клиент запрашивает файл с сервера, он смотрит из корневого каталога в подкаталог, содержащий запрошенный для .htaccess, и принимает во внимание содержащиеся в нем директивы перед выполнением запроса.

Принцип .htaccess:

1. Запрещает перечисление файлов в каталоге.
2. Перенаправляет веб-трафик.
3. Настраивает страницы ошибок.
4. Ограничивает доступ к определенным файлам.
5. Запрещает доступ к определенным IP-адресам или диапазонам IP-адресов.
6. Расширяет функциональность, что связано с вызовами других модулей и файлами конфигурации. Всем директивам, связанных с этим пунктом, будет предшествовать слово «Включить».

Установка веб-сервера Apache

«Апач» изначально был разработан для работы с технологией PHP, но без проблем может работать и с .NET, что делает его более успешным по сравнению с IIS Microsoft, являющимся коллаборантом для серверов, использующих IIS, и обеспечивающим полную поддержку PHP без необходимости изменять конфигурацию.

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

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

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

Далее появится окно установки, где указаны все доступные компоненты. Выбирают их все и проверяют, наличие папки c: appserv Apache2.2. Далее выполняют настройку веб-сервера Apache.

Веб-Monitor на панели задач

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

Алгоритм установки:

1. В консоли Windows находят папку bin Apache, для этого прописывают следующее предложение в консоли – c: appserv Apache2.2? in.
2. После ввода нажимают Enter и системный компонент, который будет выглядит так – C: appserv Apache2.2? In>.
3. Находясь в папке bin, вводят http: .exe -k install и нажимают Enter.
4. Появиться сообщение, похожее на «.Apache 2.2: служба уже установлена». Это сообщение проверит, что «Апач» был успешно установлен.

Один из наиболее эффективных способов проверить правильность работы Apache – установить, активен ли монитор приложения. Его можно увидеть на панели задач. Если он неактивен, активируют его, переходя в меню «Пуск», раздел «Все программы» и Apache http Server 2.2., нажимают на Monitor Apache Server и активируют его.

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

Советы по установке в Linux

Если у пользователя есть сайт и нужна платформа для его размещения, можно воспользоваться услугами одного из хостинг-провайдеров либо попробовать самостоятельно разместить свой сайт на сервере.

Алгоритм установки:

1. Скачивают последнюю стабильную версию «Апач».
2. Загружают исходные файлы, соответствующие системе.
3. Извлекают файлы ПО.
4. После того загруженные файлы нужно будет распаковать:gunzip -d httpd-2_0_NN.tar.gz; tar xvf httpd-2_0_NN.tar.
5. Это создает новый каталог в текущем каталоге с исходными файлами.
6. Как только появятся файлы, указывают машине, где найти все исходные. Самый простой способ сделать это – принять все значения по умолчанию и просто набрать: ./configure.
7. Настраивают Apache при условии, что не было никаких проблем с установкой и сборкой. Пользователь настраивает конфигурацию, что равносильно редактированию файла httpd.conf. Он обычно редактируется с текстовым редактором- vi PREFIX /conf/httpd.conf. Для внесения любых изменений нужно быть пользователем root.
8. Проверяют работу сервера.

Применение в World Wide Web

Apach используется в основном для отправки статических и динамических страниц в World Wide Web. Многие приложения разработаны с учетом среды реализации «Апач» или будут использовать характеристики этого сервера. Apach – компонент сервера в популярной платформе приложений LAMP наряду с языками программирования MySQL и PHP, Perl , Python и Ruby, включая базу данных Oracle и сервер приложений IBM WebSphere. Mac OS X интегрирует его как часть собственного web-server и поддержку приложений WebObjects.

Apache используется для многих других задач, когда контент должен быть доступен безопасным и надежным способом. Например, при совместном использовании файлов с персонального компьютера в интернет. Пользователь, у которого на рабочем столе установлен «Апач», может произвольно размещать файлы в корне документов, откуда они могут стать общими.

Разработчики веб-приложений иногда используют локальную версию Apache для предварительного просмотра и тестирования кода во время разработки. Microsoft Internet Information Services (IIS) является основным конкурентом «Апач», а также веб-сервером Sun Java System от Sun Microsystems и множеством других приложений, таких как Zeus Web-Server.

Некоторые из крупнейших сайтов в мире работают на Apache. Внешний интерфейс поисковой системы Google основан на ее модифицированной версии, которая называется Google веб-сервер (GWS). Многие проекты “Википедии” также работают на серверах «Апач».

что это такое и краткий обзор возможностей / Ростелеком corporate blog / Habr

Мы в «Ростелекоме» стремимся развивать работу с Hadoop, так что уже попробовали и оценили преимущества Apache NiFi по сравнению с другими решениями. В этой статье я расскажу, чем нас привлек этот инструмент и как мы его используем.

Предыстория

Первое, что нам, как администраторам, не нравилось – это то, что написание конфига Flume для выполнения очередной тривиальной загрузки нельзя было доверить разработчику или аналитику, не погруженному в тонкости работы этого инструмента. Подключение каждого нового источника требовало обязательного вмешательства со стороны команды администраторов.
Вторым моментом были отказоустойчивость и масштабирование. Для тяжелых загрузок, например, по syslog, нужно было настраивать несколько агентов Flume и ставить перед ними балансировщик. Все это затем нужно было как-то мониторить и восстанавливать в случае сбоя.
В-третьих, Flume не позволял загружать данные из различных СУБД и работать с некоторыми другими протоколами «из коробки». Конечно, на просторах сети можно было найти способы заставить работать Flume с Oracle или с SFTP, но поддержка таких «велосипедов» — занятие совсем не из приятных. Для загрузки данных из того же Oracle приходилось брать на вооружение еще один инструмент — Apache Sqoop.
Откровенно говоря, я по своей натуре являюсь человеком ленивым, и мне совсем не хотелось поддерживать зоопарк решений. А еще не нравилось, что всю эту работу приходится выполнять самому.

Есть, разумеется, достаточно мощные решения на рынке ETL-инструментов, которые умеют работать с Hadoop. К ним можно отнести Informatica, IBM Datastage, SAS и Pentaho Data Integration. Это те, о которых чаще всего можно услышать от коллег по цеху и те, что первыми приходят на ум. К слову, у нас используется IBM DataStage для ETL на решениях класса Data Warehouse. Но так уж исторически сложилось, что использовать DataStage для загрузок в Hadoop наша команда не имела возможности. Опять же, нам не нужна была вся мощь решений такого уровня для выполнения достаточно простых преобразований и загрузок данных. Что нам требовалось, так это решение с хорошей динамикой развития, умеющее работать со множеством протоколов и обладающее удобным и понятным интерфейсом, с которым способен справиться не только администратор, разобравшийся во всех его тонкостях, но и разработчик с аналитиком, которые зачастую и являются для нас заказчиками самих данных.

Как вы могли понять из заголовка, мы решили перечисленные проблемы с помощью Apache NiFi.

Что такое Apache NiFi

NiFi — это open source ETL/ELT-инструмент, который умеет работать со множеством систем, причем не только класса Big Data и Data Warehouse. Вот некоторые из них: HDFS, Hive, HBase, Solr, Cassandra, MongoDB, ElastcSearch, Kafka, RabbitMQ, Syslog, HTTPS, SFTP. Ознакомиться с полным списком можно в официальной документации.

Работа с конкретной СУБД реализуется за счет добавление соответствующего JDBC-драйвера. Есть API для написания своего модуля в качестве дополнительного приемника или преобразователя данных. Примеры можно найти здесь и здесь.

Основные возможности

Веб-интерфейс управления NiFi

Ниже я покажу несколько примеров DataFlow для выполнения некоторых обыденных операций.

Пример загрузки файлов с SFTP-сервера в HDFS

В этом примере процессор «ListSFTP» делает листинг файлов на удаленном сервере. Результат этого листинга используется для параллельной загрузки файлов всеми нодами кластера процессором «FetchSFTP». После этого, каждому файлу добавляются атрибуты, полученные путем парсинга его имени, которые затем используются процессором «PutHDFS» при записи файла в конечную директорию.

Пример загрузки данных по syslog в Kafka и HDFS

Здесь с помощью процессора «ListenSyslog» мы получаем входной поток сообщений. После этого каждой группе сообщений добавляются атрибуты о времени их поступления в NiFi и название схемы в Avro Schema Registry. Далее первая ветвь направляется на вход процессору «QueryRecord», который на основе указанной схемы читает данные и выполняет их парсинг с помощью SQL, а затем отправляет их в Kafka. Вторая ветвь направляется процессору «MergeContent», который агрегирует данные в течение 10 минут, после чего отдает их следующему процессору для преобразования в формат Parquet и записи в HDFS.

Вот пример того, как еще можно оформить DataFlow:

Загрузка данных по syslog в Kafka и HDFS. Очистка данных в Hive

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

Пример использования переменных и функций в процессоре UpdateAttribute

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

Визуализация цепочки DataFlow

Просмотр содержимого и атрибутов данных

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

Меню Version Control

В NiFi можно управлять доступом к веб-интерфейсу и разделением прав пользователей. На текущий момент поддерживаются следующие механизмы аутентификации:

• На основе сертификатов
  
• На основе имени пользователя и пароля посредством LDAP и Kerberos
  
• Через Apache Knox
  
• Через OpenID Connect
  

Как я уже говорил, NiFi умеет работать в режиме кластера. Это обеспечивает отказоустойчивость и дает возможность горизонтально масштабировать нагрузку. Статично зафиксированной мастер-ноды нет. Вместо этого Apache Zookeeper выбирает одну ноду в качестве координатора и одну в качестве primary. Координатор получает от других нод информацию об их состоянии и отвечает за их подключение и отключение от кластера.
Primary-нода служит для запуска изолированных процессоров, которые не должны запускаться на всех нодах одновременно.

Работа NiFi в кластере

Распределение нагрузки по нодам кластера на примере процессора PutHDFS

Краткое описание архитектуры и компонентов NiFi

NiFi опирается на концепцию «Flow Based Programming» (FBP). Вот основные понятия и компоненты, с которыми сталкивается каждый его пользователь:

FlowFile — сущность, представляющая собой объект с содержимым от нуля и более байт и соответствующих ему атрибутов. Это могут быть как сами данные (например, поток Kafka сообщений), так и результат работы процессора (PutSQL, например), который не содержит данных как таковых, а лишь атрибуты сгенерированные в результате выполнения запроса. Атрибуты представляют собой метаданные FlowFile.

FlowFile Processor — это именно та сущность, которая выполняет основную работу в NiFi. Процессор, как правило, имеет одну или несколько функций по работе с FlowFile: создание, чтение/запись и изменение содержимого, чтение/запись/изменение атрибутов, маршрутизация. Например, процессор «ListenSyslog» принимает данные по syslog-протоколу, на выходе создавая FlowFile’ы с атрибутами syslog.version, syslog.hostname, syslog.sender и другими. Процессор «RouteOnAttribute» читает атрибуты входного FlowFile и принимает решение о его перенаправлении в соответствующее подключение с другим процессором в зависимости от значений атрибутов.

Connection — обеспечивает подключение и передачу FlowFile между различными процессорами и некоторыми другими сущностями NiFi. Connection помещает FlowFile в очередь, после чего передает его далее по цепочке. Можно настроить, как FlowFile’ы выбираются из очереди, их время жизни, максимальное количество и максимальный размер всех объектов в очереди.

Process Group — набор процессоров, их подключений и прочих элементов DataFlow. Представляет собой механизм организации множества компонентов в одну логическую структуру. Позволяет упростить понимание DataFlow. Для получения и отправки данных из Process Groups используются Input/Output Ports. Подробнее об их использовании можно прочитать здесь.

FlowFile Repository — это то место, в котором NiFi хранит всю известную ему информацию о каждом существующем в данный момент FlowFile в системе.

Content Repository — репозиторий, в котором находится содержимое всех FlowFile, т.е. сами передаваемые данные.

Provenance Repository — содержит историю о каждом FlowFile. Каждый раз, когда с FlowFile происходит какое-либо событие (создание, изменение и т.д.), соответствующая информация заносится в этот репозиторий.

Web Server — предоставляет веб-интерфейс и REST API.

Заключение

К слову, NiFi входит в дистрибутив Hortonworks Data Flow и активно развивается самим Hortonworks. А еще у него есть интересный подпроект Apache MiNiFi, который позволяет собирать данные с различных устройств и интегрировать их в DataFlow внутри NiFi.

Дополнительная информация о NiFi

обзор / Издательский дом «Питер» corporate blog / Habr

Сегодня мы предлагаем вам сравнительно краткую, но при этом толковую и информативную статью об устройстве и вариантах применения Apache Kafka. Рассчитываем перевести и выпустить книгу Нии Нархид (Neha Narkhede) et. al до конца лета.

Сегодня много говорят о Kafka. Многие ведущие айтишные компании уже активно и успешно пользуются этим инструментом. Но что же такое Kafka?

Kafka был разработан в компании LinkedIn в 2011 году и с тех пор значительно усовершенствовался. Сегодня Kafka – это целая платформа, обеспечивающая избыточность, достаточную для хранения абсурдно огромных объемов данных. Здесь предоставляется шина сообщений с колоссальной пропускной способностью, на которой можно в реальном времени обрабатывать абсолютно все проходящие через нее данные.

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

Мудрено звучит. Давайте рассмотрим каждый из этих терминов и разберемся, что он означает. А затем подробно исследуем, как все это работает.

Распределенный

Распределенной называется такая система, которая в сегментированном виде работает сразу на множестве машин, образующих цельный кластер; поэтому для конечного пользователя они выглядят как единый узел. Распределенность Kafka заключается в том, что хранение, получение и рассылка сообщений у него организовано на разных узлах (так называемых «брокерах»).
Важнейшие плюсы такого подхода – высокодоступность и отказоустойчивость.

Горизонтально масштабируемый

Давайте сначала определимся с тем, что такое вертикальная масштабируемость. Допустим, у нас есть традиционный сервер базы данных, и он постепенно перестает справляться с нарастающей нагрузкой. Чтобы справиться с этой проблемой, можно просто нарастить ресурсы (CPU, RAM, SSD) на сервере. Это и есть вертикальное масштабирование – на машину навешиваются дополнительные ресурсы. При таком «масштабировании вверх» возникает два серьезных недостатка:

1. Есть определенные пределы, связанные с возможностями оборудования. Бесконечно наращиваться нельзя.
2. Такая работа обычно связана с простоями, а большие компании не могут позволить себе простоев.

После определенного порога горизонтальное масштабирование становится гораздо дешевле вертикального

Отказоустойчивость

Для нераспределенных систем характерно наличие так называемой единой точки отказа. Если единственный сервер вашей базы данных по какой-то причине откажет – вы попали.
Распределенные системы проектируются таким образом, чтобы их конфигурацию можно было корректировать, подстраиваясь под отказы. Кластер Kafka из пяти узлов остается работоспособным, даже если два узла лягут. Необходимо отметить, что для обеспечения отказоустойчивости обязательно приходится частично жертвовать производительностью, поскольку чем лучше ваша система переносит отказы, тем ниже ее производительность.

Журнал коммитов

Журнал коммитов (также именуемый «журнал опережающей записи», «журнал транзакций») – это долговременная упорядоченная структура данных, причем, данные в такую структуру можно только добавлять. Записи из этого журнала нельзя ни изменять, ни удалять. Информация считывается слева направо; таким образом гарантируется правильный порядок элементов.

Схема журнала коммитов

— Вы имеете в виду, что структура данных в Kafka настолько проста?

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

• Операции считывания и записи выполняются за постоянное время O(1) ( если известен ID записи), что, по сравнению с операциями O(log N) на диске в другой структуре, невероятно экономит время, так как каждая операция подвода головок затратна.
• Операции считывания и записи не влияют друг на друга (операция считывания не блокирует операцию записи и наоборот, чего не скажешь об операциях со сбалансированными деревьями).

Как все это работает?

Приложения (генераторы) посылают сообщения (записи) на узел Kafka (брокер), и указанные сообщения обрабатываются другими приложениями, так называемыми потребителями. Указанные сообщения сохраняются в теме, a потребители подписываются на тему для получения новых сообщений.

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

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

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

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

Так устроен поток данных

Долговременное хранение на диске

Как упоминалось выше, Kafka на самом деле хранит свои записи на диске и ничего не держит в оперативной памяти. Да, возможен вопрос, есть ли в этом хоть капля смысла. Но в Kafka действует множество оптимизаций, благодаря которым такое становится осуществимым:

1. В Kafka есть протокол, объединяющий сообщения в группы. Поэтому при сетевых запросах сообщения складываются в группы, что позволяет снизить сетевые издержки, а сервер, в свою очередь, сохраняет партию сообщений за один присест, после чего потребители могут сразу выбирать большие линейные последовательности таких сообщений.
2. Линейные операции считывания и записи на диск происходят быстро. Известна проблема: современные диски работают сравнительно медленно из-за необходимости подвода головок, однако, при крупных линейных операциях такая проблема исчезает.
3. Указанные линейные операции сильно оптимизируются операционной системой путем опережающего чтения (заблаговременно выбираются крупные группы блоков) и запаздывающей записи (небольшие логические операции записи объединяются в крупные физические операции записи).
4. Современные ОС кэшируют диск в свободной оперативной памяти. Такая техника называется страничный кэш.
5. Поскольку Kafka сохраняет сообщения в стандартизированном двоичном формате, который не изменяется на протяжении всей цепочки (генератор->брокер->потребитель), здесь уместна оптимизация нулевого копирования. В таком случае ОС копирует данные из страничного кэша прямо на сокет, практически обходя стороной приложение-брокер, относящееся к Kafka.

Распределение и репликация данных

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

Репликация данных

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

В любом случае, один из брокеров всегда “владеет” секцией: этот брокер — именно тот, на котором приложения выполняют операции считывания и записи в секцию. Этот брокер называется «ведущим секции». Он реплицирует получаемые данные на N других брокеров, так называемых ведомыми. На ведомых также хранятся данные, и любой из них может быть выбран в качестве ведущего, если актуальный ведущий откажет.
Так можно сконфигурировать гарантии, обеспечивающие, что любое сообщение, которое будет успешно опубликовано, не потеряется. Когда есть возможность изменить коэффициент репликации, можно частично пожертвовать производительностью ради повышенной защиты и долговечности данных (в зависимости от того, насколько они критичны).

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

Однако, логично спросить:

— Как генератор/потребитель узнает, какой брокер – ведущий данной секции?

Для хранения таких метаданных в Kafka используется сервис под названием Zookeeper.

Что такое Zookeeper?

Zookeeper – это распределенное хранилище ключей и значений. Оно сильно оптимизировано для считывания, но записи в нем происходят медленнее. Чаще всего Zookeeper применяется для хранения метаданных и обработки механизмов кластеризации (пульс, распределенные операции обновления/конфигурации, т.д.).

Таким образом, клиенты этого сервиса (брокеры Kafka) могут на него подписываться – и будут получать информацию о любых изменениях, которые могут произойти. Именно так брокеры узнают, когда ведущий в секции меняется. Zookeeper исключительно отказоустойчив (как и должно быть), поскольку Kafka сильно от него зависит.

Он используется для хранения всевозможных метаданных, в частности:

• Смещение групп потребителей в рамках секции (хотя, современные клиенты хранят смещения в отдельной теме Kafka)
• ACL (списки контроля доступа) — используются для ограничения доступа /авторизации
• Квоты генераторов и потребителей — максимальные предельные количества сообщений в секунду
• Ведущие секций и уровень их работоспособности

Ранее Генератор и Потребители непосредственно подключались к Zookeeper и узнавали у него эту (а также другую) информацию. Теперь Kafka уходит от такой связки и, начиная, соответственно, с версий 0.8 и 0.9 клиенты, во-первых, выбирают метаданные непосредственно у брокеров Kafka, а брокеры обращаются к Zookeeper.

Поток метаданных

Потоки

Потоковый процессор в Kafka отвечает за всю следующую работу: принимает непрерывные потоки данных от входных тем, каким-то образом обрабатывает этот ввод и подает поток данных на выходные темы (либо на внешние сервисы, базы данных, в корзину, да куда угодно…)
Простую обработку можно выполнять непосредственно на API генераторов/потребителей, однако, более сложные преобразования – например, объединение потоков, в Kafka выполняется при помощи интегрированной библиотеки Streams API.

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

Обработка без сохранения состояния

Обработка без сохранения состояния — это поток детерминированной обработки, не зависящий ни от каких внешних факторов. В качестве примера рассмотрим вот такое простое преобразование данных: прикрепляем информацию к строке

"Hello" -> "Hello, World!"

Потоково-табличный дуализм

Важно понимать, что потоки и таблицы – это, в сущности, одно и то же. Поток можно интерпретировать как таблицу, а таблицу – как поток.

Поток как таблица

Если обратить внимание, как выполняется синхронная репликация базы данных, то очевидно, что речь идет о потоковой репликации, где любые изменения в таблицах отправляются на сервер копий (реплику). Поток Kafka можно интерпретировать точно так же – как поток обновлений для данных, которые агрегируются и дают конечный результат, фигурирующий в таблице. Такие потоки сохраняются в локальной RocksDB (по умолчанию) и называются KTable.

Таблица как поток

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

При каждом обновлении можно сделать мгновенный снимок потока (запись)

Обработка с сохранением состояния

Некоторые простые операции, например, map() или filter(), выполняются без сохранения состояния, и нам не приходится хранить каких-либо данных, касающихся их обработки. Однако, на практике большинство операций выполняется с сохранением состояния (напр. count()), поэтому вам, естественно, придется хранить состояние, сложившееся на настоящий момент.

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

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

Итак, какой же подход лучше?

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

Потоковый процессор может сохранять свое состояние в локальной таблице (например, в RocksDB), которую будет обновлять входной поток (возможно, после каких-либо произвольных преобразований). Если этот процесс сорвется, то мы сможем восстановить соответствующие данные, повторно воспроизведя поток.

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

Обработка с сохранением состояния, соединение KStream с KTable

KSQL

Как правило, код для обработки потоков приходится писать на одном из языков для JVM, поскольку именно с ней работает единственный официальный клиент Kafka Streams API.

Образец установки KSQL

KSQL – это новая фича, позволяющая писать простые потоковые задания на знакомом языке, напоминающем SQL.

Настраиваем сервер KSQL и интерактивно запрашиваем его через CLI для управления обработкой. Он работает точно с теми же абстракциями (KStream и KTable), гарантирует те же преимущества, что и Streams API (масштабируемость, отказоустойчивость) и значительно упрощает работу с потоками.

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

Альтернативны потоковой обработке

Потоки Kafka – идеальное сочетание силы и простоты. Пожалуй, Kafka – лучший инструмент для выполнения потоковых заданий, имеющихся на рынке, а интегрироваться с Kafka гораздо проще, чем с альтернативными инструментами для потоковой обработки (Storm, Samza, Spark, Wallaroo).

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

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

Kafka Streams позволяет вам сформулировать собственную стратегию развертывания, когда вам это потребуется, причем, работать с инструментом на ваш вкус: Kubernetes, Mesos, Nomad, Docker Swarm и пр.

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

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

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

Kafka позволяет с легкостью разграничить коммуникацию между различными (микро)сервисами. Работая Streams API, стало как никогда просто писать бизнес-логику, обогащающую данные из темы Kafka перед тем, как их станут потреблять сервисы. Здесь открываются широчайшие возможности – поэтому настоятельно рекомендую изучить, как Kafka применяется в разных компаниях.

Итоги

Apache Kafka – это распределенная потоковая платформа, позволяющая обрабатывать триллионы событий в день. Kafka гарантирует минимальные задержки, высокую пропускную способность, предоставляет отказоустойчивые конвейеры, работающие по принципу «публикация/подписка» и позволяет обрабатывать потоки событий.

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

что это, как работает и почему лучше других брокеров сообщений

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

Давайте посмотрим, что такое Apache Kafka, как он работает и кому пригодится.

Нервная система бэкенда: зачем нужен Apache Kafka

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

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

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

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

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

Почему установка Apache Kafka — лучший выбор

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

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

Для устранения этих проблем и был создан Apache Kafka — сверхнадежная сверхмасштабируемая сверхгибкая система обмена сообщениями внутри бэкенд-приложений.

Описание Apache Kafka

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

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

Еще один плюс — консистентность данных. Записи в Apache Kafka хранятся в виде журнала коммитов. Это выглядит как очередь сообщений, в которую можно добавлять записи, а вот удалять или модицифировать — нет. Такой подход дает огромную надежность и простоту изменения любых состояний — всегда понятно, что, как и в какой последовательности менялось.

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

Apache Kafka: обзор возможностей

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

1. Самый очевидный подход — для связи микросервисов между собой. Сделал действие, послал сообщение другим сервисам — все, молодец. Или подписался на обновления от других частей системы и потихоньку на них реагируешь.
2. Организация потоков данных. Допустим, у вас идет постоянный стрим каких-то событий, их нужно передавать по цепочке и на каждом этапе что-то с ними делать. Apache Kafka идеально реализует этот сценарий с помощью грамотной организации роутинга сообщений.
3. Агрегация записей. В Apache Kafka можно писать данные куда быстрее, чем в обычную базу данных. Это значит, что с помощью сообщений можно организовать сбор кучи метрик, считать от них, например, средние, и уже эти значения писать в БД.
4. Сбор логов. Apache Kafka дает возможность хранить сообщения в течение определенного времени. Это значит, что сообщения можно использовать для кратковременного (часы/сутки) хранения логов. Это позволяет разгрузить БД и медленные системы логирования.

Апачи (округ) — Википедия

Материал из Википедии — свободной энциклопедии

Апачи (англ. Apache) — округ, расположенный на северо-востоке американского штата Аризона.

Окружной центр — Сент-Джонс^[en]

В округ частично входят резервации Навахо-нейшен, Форт Апачи^[en] и национальный парк Петрифайд-Форест. Здесь же полностью расположен Национальный монумент Каньон Де Шейи. Округ Апачи занимает территорию 29 055,6 км², 29 020,5 км² из которых суша, а 35,1 км² — водные угодья^[2]. Это шестой по величине округ США (за исключением районов Аляски).

Граничит с округами:

68,34 % (19,857.34 км²) территории округа занимают индейские резервации навахо, апачи и зуни. Это больше, чем в любом другом округе США.

Охраняемые территории:

Города[править | править код]

Деревни и посёлки[править | править код]

• Бёрнсайд
• Чинли
• Деннехотсо
• Форт-Дефайанс
• Ганадо
• Хук
• Лукачукай
• Мэни-Фармс
• МакНари
• Назлини
• Ред-Меса
• Рок-Пойнт
• Раф-Рок
• Раунд-Рок
• Соумилл
• Сент-Майклс
• Стимбот
• Тик-Нос-Пос
• Тсейл
• Уиндоу-Рок

Прочие населённые пункты[править | править код]

• Алпайн
• Кончо
• Грир
• Сандерс

Основные дороги[править | править код]

• I-40
• U.S. Route 60
• U.S. Route 64
• U.S. Route 180
• U.S. Route 191
• Arizona State Route 64
• Arizona State Route 260
• Arizona State Route 264

Аэропорты[править | править код]

2010[править | править код]

В соответствии с переписью населения США в 2010 году, в округе Апачи проживало:

• 72,9 % — коренных американцев
• 23,3 % — белых
• 5,8 % — латиноамериканцев (любой расы)
• 2,0 % — людей двух или более рас
• 1,3 % — людей других рас
• 0,3 % — азиатов
• 0,2 % — чёрных
• 0,0 % — коренных жители Гавайских островов или островов Тихого океана

2000[править | править код]

По данным переписи 2000 года в округе Апачи проживало 69 тысяч 423 человека. Плотность населения составляла 2 чел./км², существовало 31621 жилое здание. Расовый состав в 2000 году был таков:

• 76,88 % — коренные американцы
• 19,5 % — белые
• 4,49 % — латиноамериканцы (любой расы)
• 1,75 % — люди других рас
• 1,43 % — люди двух или более рас
• 0,25 % — чёрные
• 0,13 % — азиаты
• 0,06 % — коренные жители Гавайских островов или островов Тихого океана

Существовала 19971 семья, из которых 43,8 % имели детей в возрасте до 18 лет, а 49,3 % — супружеские пары без детей.

Средний доход на домашнее хозяйство составил $23344, а средний доход на семью — $26315. Средний доход мужчин составил $30182 против $22312 женщин. Доход на душу населения в округе составил $8986. 33,5 % семей и 37,8 % населения были ниже черты бедности, в том числе 42,8 % из них моложе 18 лет и 36,5 % в возрасте 65 лет и старше. Доход округа на душу населения делает его одним из беднейших округов в США.

Апачи является одним из всего лишь 38 округов Соединённых Штатов, где самый распространенный язык — не английский, и один из 3, где не английский и не испанский. 58,32 % населения говорят у себя дома на языке навахо, далее идёт английский язык, на нём говорят 38,34 %, а на испанском — всего 2,72 %^[3].

В 2000 году крупнейшей конфессиональной группой были католики (с 19965 приверженцев). Крупнейшие религиозные организации — Католическая Церковь и Церковь Иисуса Христа Святых последних дней (8947 членов)^[4].

В округе работают 11 окружных начальных и средних школ. Главной библиотекой округа является Библиотека округа Апачи в Сент-Джонсе^[5]. Она управляет всеми остальными библиотеками округа, а именно:

• Публичная библиотека Алпайна^[6]
• Публичная библиотека Кончо^[7]
• Мемориальная библиотека Грира^[8]
• Публичная библиотека Круглой Долины^[9]
• Публичная библиотека Сандерса^[10]
• Публичная библиотека Вернона^[11]

апач — Викисловарь

Морфологические и синтаксические свойства[править]

а·па́ч

Существительное, одушевлённое, мужской род, 2-е склонение (тип склонения 4a по классификации А. А. Зализняка).

Корень: -апач-.

Произношение[править]

• МФА: ед. ч. [ɐˈpat͡ɕ], мн. ч. [ɐˈpat͡ɕɪ]

Семантические свойства[править]

Значение[править]

1. представитель апачей ◆ В отличие от уравновешенного и миролюбивого Сергея Витёк был агрессивен и воинственен, как апач. Евгений Шкловский, «Свой», 1990-1996 г. (цитата из Национального корпуса русского языка, см. Список литературы)
2. мн. ч. собирательное название для нескольких культурно родственных племён североамериканских индейцев, говорящих на апачских языках атабаскской ветви семьи на-дене ◆ Отсутствует пример употребления (см. рекомендации).
3. жарг., комп. веб-сервер Apache ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы[править]

1. -

Антонимы[править]

1. -

Гиперонимы[править]

1. индеец
2. индейцы

Гипонимы[править]

Родственные слова[править]

Этимология[править]

Происходит от ??

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Анаграммы[править]

Библиография[править]

Морфологические и синтаксические свойства[править]

а·па́ч

Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 4a по классификации А. А. Зализняка).

Корень: -апач-.

Произношение[править]

• МФА: ед. ч. [ɐˈpat͡ɕ], мн. ч. [ɐˈpat͡ɕɪ]

Семантические свойства[править]

Значение[править]

1. спец. цирк. звонкая фальшивая пощёчина, исполняемая клоунами как игровой прием с незаметным хлопком в ладоши для имитации звука ◆ Клоуны опасались, что малыш начнет во время действия громко выкликать их по именам или во всеуслышание протестовать, когда Белый клоун навешивает Рыжему звонкие апачи. Василий Ливанов, «Мой любимый клоун», 1985 г.

Синонимы[править]

1. -

Антонимы[править]

1. -

Гиперонимы[править]

1. пощёчина

Гипонимы[править]

Родственные слова[править]

Этимология[править]

Происходит от нем. Patsch — пощёчина.

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Библиография[править]

апачи - это... Что такое апачи?

Апачские войны — Википедия

Апачские войны (англ. Apache Wars) — серия военных конфликтов между Соединёнными Штатами Америки и племенами индейцев-апачей на юго-западе страны в период с 1849 по 1886 год (хотя отдельные незначительные боевые действия продолжались до 1924 года^[1], а первые столкновения зафиксированы ещё в 1847 году). Армия Конфедерации в начале 1860-х годов также приняла участие в войнах — например, в Техасе, прежде чем сражения в Гражданской войне в США в Нью-Мексико и Аризоне стали более интенсивными. Также в войне на стороне правительства США, особенно в первые десятилетия войны, активно участвовало ополчение из гражданского населения.

Апачи всегда существенно уступали своим противникам в численности и вооружении, но противопоставляли этому высокий боевой дух и хорошее знание местности, что позволяло им выигрывать ряд сражений. Грегори Мично, историк Индейских войн, указывает, что на юго-западе США было значительно больше конфликтов между правительством США и коренными американцами, нежели где бы то ни было, объясняя это в том числе существованием у племён апачей богатых военных традиций.^[2]

В конце концов все племена апачей были либо истреблены, либо насильно поселены в резервациях, а их исконные территории были заняты белыми переселенцами — фермерами и шахтёрами. Немалую роль в создании у населения (причём не только населения США) крайне негативного образа апачей сыграла пресса, действовавшая в том числе в интересах тех, кто желал завладеть богатыми ресурсами апачских земель.

Наряду с Войной за Чёрные Холмы Апачская война (которую правильнее всё же назвать Апачскими войнами, поскольку боевые действия велись с перерывами, а разные группы апачей действовали нередко отдельно друг от друга) является одним из последних крупных конфликтов между правительством США и индейцами в ходе так называемых Индейских войн, при этом одним из самых «дорогостоящих» не только в плане собственно денег, но и в плане человеческих жизней.

История противостояния племён апачей с белыми насчитывает много десятилетий — их первыми противниками были ещё испанцы, впервые вступившие на их земли в XVI веке. После получения Мексикой в начале XIX века независимости от Испании противником апачей становятся мексиканцы.

Самые первые конфликты между апачами (самоназвание которых на их родном языке — T`Inde, Inde, N`dee, N`ne, что означает Люди) и американскими переселенцами начались в 1847 году во время Американо-мексиканской войны, особенно в ходе восстания Таоса.

Первая кампания армии Соединённых Штатов против апачей началась два года спустя — в 1849 году^[3], последним крупным событием стала капитуляция апачского вождя Джеронимо в 1886 году. Тем не менее, апачи продолжали нападать на белых переселенцев как минимум до 1906 года. По состоянию на 1915 год группа апачей чирикауа, бежавших от власти американцев после поражения, всё ещё жила в Сьерра-Мадре на севере Мексики. Апачи боролись против колониальных притязаний со стороны испанцев и мексиканцев за десятилетия до начала конфликта с Соединёнными Штатами. Основные военные кампании периода Апачских войн произошли в области современного города Тусон в штате Аризона. Апачи не смогли остановить продвижение испанцев и мексиканцев и изгнать их из земель, завоёванных ими у других индейских племён, а впоследствии были вынуждены защищать уже свою непосредственную родину — в период более поздних Апачских войн. Различные племена апачей владели территориями, простирающимися от южной Калифорнии до западного Техаса, от северной Аризоны до севера Мексики и части Оклахомы.

В первый период войны — примерно в 1849-1875 годах — вооружённые конфликты часто возникали в результате так называемых рейдов апачей против белых переселенцев, в ходе которых они похищали их скот и имущество и иногда убивали американцев и мексиканцев. С первой половины 1860-х годов на границах апачских земель американцы начали возводить форты и наблюдательные пункты, чтобы держать в поле зрения каждое племя. Первым таким объектом стал построенный на границах Аризоны Форт-Бьюкенен, затем были построены Кэмп-Грант и Форт-Гудвин (позднее переименованный в Форт-Томас) для контроля над племенем пима, Форт-Верде и Фот-Макдоннел для контроля за тонто и явапаи и Форт-Боуи для контроля за чирикауа. Позже всего был возведён Форт-Апаче для контроля за территорией апачей Белых Гор и сибеку.

Во второй период войны — 1875-1886 годы — боевые действия с апачами вела преимущественно армия США, целью которой было насильственное переселение апачей в индейские резервации или же предотвращение побега племён из резерваций, если они уже были помещены туда. Третьим периодом войны можно условно считать период с 1886 по конец 1906 года, когда происходили мелкие стычки между небольшими группами апачей, до сих пор избежавших переселения в резервации, с одной стороны и силами Экспедиционного кавалерийского корпуса армии США и ополчением из переселенцев с другой.

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

Иногда апачи бывали спровоцированы для совершения нападения американскими и мексиканскими поселенцами и торговцами, которые спекулировали на поставках товаров племенам (а впоследствии — резервациям). Наиболее известными военными вождями апачей, возглавлявшими военные действия или рейды, были Мангас Колорадас, Кочис, Викторио, Ху и Джеронимо из племени чирикауа и Делшай из племени тонто. Они стояли во главе сопротивления апачей попыткам армии США насильно переселить их в резервации.

В начале Американо-мексиканской войны многие племена апачей обещали американским солдатам безопасный проход через свои земли, даже вступая с США в союз, тогда как другие племена сражались на стороне Мексики, противостоя американцам и повстанцам Нью-Мексико. Когда после окончания войны в 1848 году Соединённые Штаты устанавливали границу с Мексикой, вождь чирикауа-апачей Мангас Колорадас подписал с США мирный договор, признавая американцев в качестве завоевателей мексиканской земли. США также признавало за апачами права на их земли, однако в договоре, подписанном в Санта-Фе в 1851 году, говорилось, что апачи должны выполнить его условия немедленно, тогда как США выполнят свою часть обязательств только после того, как договор будет ратифицирован Конгрессом США. Конгресс США же никогда не ратифицировал этот договор. Вскоре после окончания войны хрупкий мир между апачами и белыми переселенцами был нарушен: у индейцев возник конфликт с белыми, прибывавшими в завоёванные территории в качестве золотоискателей после обнаружения залежей золота в горах Санта-Рита.

Война хикарилья началась в 1849 году, когда несколько групп переселенцев подверглись нападению и были убиты индейцами на северо-востоке Нью-Мексико. Второе подобное нападение произошло в 1850 году, когда было убито несколько почтовых курьеров. Армия не вмешивалась в события до 1853 года. Сначала хикарилья одержали победу в битве при Синегуилле, затем американцы разбили их в каньоне Охо-Кальенте.

В 1851 году один из вождей апачей Мангас Колорадас подвергся нападению группы шахтёров, которые привязали его к дереву и жестоко избили. Этот случай не был единичным: белые поселенцы неоднократно нарушали договор, заключённый между правительством США и апачами после Американо-мексиканской войны, что приводило к ответным репрессиям по отношению к белым переселенцам со стороны апачей. Хотя следует отметить, что апачи также не были безгрешны, нередко воруя у белых скот. В декабре 1860 года шахтёры предприняли неожиданную атаку на лагерь апачей в отместку за очередную кражу скота, убив множество индейцев и взяв в плен тридцать женщин и детей; в отместку апачи также ответили атакой на многие фермы с похищением имущества белых и убийствами.

В феврале 1861 года группа неустановленных апачей похитила пасынка фермера Джона Уорда около Соноты, Аризона, угнав также множество скота. Уорд пытался найти помощь у ближайшего гарнизона американской армии. В помощь Уорду для изучения деталей дела был направлен лейтенант Джордж Баском. Баском намеревался встретиться между Апаче-Пасс и Баттерфилдским дилижансковым трактом с апачским вождём Кочисом, которого он подозревал в преступлении, чтобы вернуть пасынка Уорда и украденный скот. В действительности же Кочис ничего не знал об инциденте и предложил его расследовать, чтобы найти настоящих виновных. Следует отметить, что Кочис, впервые вступивший в контакт с армией США ещё в конце 1850-х годов, первоначально не был настроен к ним враждебно и даже позволил им свободно пройти через свои земли.

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

Баском не желал производить предложенный ему несколько раз Кочисом обмен пленными, и тогда Кочис и его люди напали на проходящий поезд с пассажирами-мексиканцами. Они убили и ритуально изуродовали девятерых мексиканцев и взяли в плен трёх белых, которых позже убили. Затем они пытались устроить засаду на дилижансовом тракте, но это закончилось неудачей. Переговоры между Баскомом и Кочисом окончательно зашли в тупик, и Баском послал за подкреплением. Кочис убил четырёх остававшихся у него в руках белых пленников со станции Баттерфилд и прекратил переговоры. Баском, в свою очередь, приказал своему военному хирургу, доктору Бернарду Ирвину, повесить пленённых апачей. Этот обмен казнями, позже ставший известным как дело Баскома, который в основном и стал причиной последовавшей одиннадцатилетней войны между различными племенами апачей и американскими переселенцами, армией США и армией Конфедерации после начала Гражданской войны, а также многих последующих конфликтов.

За месяцы 1861 года перед Гражданской войной с обеих сторон было множество актов насилия и захвата заложников с их последующим убийством. После начала Гражданской войны в апреле 1861 года Мангас Колорадас и Кочис, женатый на его дочери, заключили военный союз, целью которого было изгнание всех белых с территории апачей. В 1861-1862 годах апачи воевали как против армии Союза, так и против Конфедерации. В частности, сражения апачей с войсками конфедератов произошли у Тубака, каньона Кук, гор Флориды, Пинос-Альтос и Дрэгон-Спрингс. Другие группы апачей сражались также с повстанцами; в частности, воины племени мескалеро атаковали Форт-Дэвис и захватили там стадо скота 9 августа 1861 года, убив при этом двух американских солдат. Военные послали за ними в погоню патруль с целью вернуть скот, но апачи убили всех преследователей. Мангас Колорадас и Кочис объединили свои усилия с вождём Ху и известным воином Джеронимо. Они думали, что достигли определённого успеха, когда американцы закрыли Баттерфилдский дилижансовый тракт, а американские войска покинули территорию, однако в действительности это было связано с началом Гражданской войны.

Командование вооружённых сил США решило наступать против конфедераторов Аризоны в Нью-Мексико, послав колонну калифорнийских добровольцев под командованием полковника Джеймса Генри Карлтона. Колонна, ставшая позднее известной как Калифорнийская, двигалась по старому Баттерфилдскому тракту. В 1862 году войска столкнулись с Мангасом Колорадасом, Кочисом и их воинами. В произошедшей битве при Апаче-Пасс, в которой белые первыми открыли огонь, Мангас Колорадас был тяжело ранен в грудь, но выжил (его отправили в Мексику, где его смогли выходить), после чего стал призывать своих сторонников к миру с Соединёнными Штатами.

В январе 1863 года Мангас Колорадас согласился встретить с американскими военными в Форт-Маклейн, около современного города Херли, Нью-Мексико, для переговоров и прибыл туда под белым флагом парламентёра, чтобы встретиться с бригадным генералом Джозефом Родманом Уэстом, офицером калифорнийского ополчения, но был жестоко им обманут. Вооружённые солдаты схватили Мангаса Колорадаса и по приказу Уэста жестоко пытали всю ночь, в том числе кололи его тело штыками, нагретыми на костре, после чего убили (так как он якобы пытался бежать), а на следующий день отрубили голову, сварили её и отправили череп в Смитсоновский институт, оставив изувеченное тело вождя в покинутом лагере, чтобы апачи затем обнаружили его. Эта ужасная расправа лишь увеличила враждебность апачей к белым. Кочис после убийства Мангаса Колорадаса укрылся в Драгунских горах, где оставался на протяжении последующих десяти лет, не прекращая партизанскую войну против белых: его силы, насчитывавшие порядка 300 воинов, провели целый ряд успешных атак на американские войска за эти годы; позже к ним присоединилась группа вождя Викторио, которая бежала из резервации Боск-Редондо. В качестве главного своего оружия эти отряды апачей использовали луки и стрелы.

Карлтон после убийства Мангаса Колорадаса решил заставить апачей и союзных им навахо поселиться в резервациях. Первоначально он намеревался сделать долину Рио-Гранде безопасной для европейских и американских переселенцев и исключить возможность нападений на путешественников. Карлтон начал с того, что попытался принудить различные группы мескалеро и навахо поселиться в резервации в Форт-Самнер. Он привлёк к этому Кита Карсона, бывшего когда-то другом навахо, - Карсон устроил настоящую облаву на индейцев, уничтожая их посевы и скот и вынудив их на так называемый долгий марш к Форт-Самнеру. Карлтон позднее участвовал в битве при Эдоуб-Уоллс.

В 1862 году в землях явапаи произошло небольшое сражение между американцами под командованием Теодора Боггса и небольшой группой апачей при Биг-Баг, Аризона. Боггс был сыном губернатора штата Миссури Лилбурна Боггса.

Война чирикауа не закончилась с убийством Мангаса Колорадаса и стала частью Техасско-Индейских войн с 1864 года.

Крупнейшим событием Техасско-индейских войн стала Первая битва у Эдоуб-Уоллс, состоявшаяся 25 ноября 1864 года, — одно из крупнейших сражений Индейских войн на Великих равнинах, в котором белым противостояли объединённые силы народов кайова, команчей и кайова-апачей, насчитывавшие более тысячи воинов. Сначала индейской армии удалось оттеснить американские войска к старым глинобитным зданиям на вершине близлежащего холма, но затем солдаты отбили несколько приступов, после чего индейцы прекратили штурм. Потери американской армии в этой битве составили шесть человек, потери индейцев — более пятидесяти, причём в этой битве был убит военный лидер кайова-апачей Железная Рубашка.

В начале 1871 года группы апачских племён пиналеньо и араваипа (последних возглавлял вождь Эскиминзин), численностью около 150 человек, приняли решение жить под опекой командира американского военного лагеря Грант, находившегося возле рек Аравайпа и Сан-Педро. Индейцы предложили, что будут жить мирно у притоков этих рек, так как больше не в состоянии выносить бесконечных преследований со стороны армии. Военное командование форта первоначально не могло обещать им предоставление земель и направило информацию о предложении в органы власти для официального решения, однако ответ долго не приходил, в итоге военные разрешили апачам поселиться близ форта неофициально. Число жителей этого импровизированного посёлка быстро увеличивалось, индейцы стали выращивать кукурузу, производить из неё мескаль, налаживать торговлю продуктами питания и другими товарами с соседями, ведя себя сначала совершенно спокойно.

Тем не менее, 10 апреля этого года несколько апачей совершили рейд на Сан-Хавьер к югу от Тусона, угнав множество скота и лошадей. Кроме того, через три дня после этого инцидента четверо американцев были убиты в городе Сан-Педро. Несмотря на то, что город находился в 80 км от места их проживания и их участие в этом преступлении было маловероятным, убийцами были объявлены именно индейцы Кэмп-Гранта.

Месть не заставила себя ждать. 30 апреля жители Тусона собрали группу из шести белых американцев, сорока восьми мексиканцев и девяноста двух воинов народа папаго и атаковали Кэмп-Грант, где произвели страшные разрушения и убили минимум 144 человека, включая женщин и детей. Некоторые индейцы попали в плен и впоследствии были отправлены на принудительные работы в Мексику. Данный инцидент стал известен как Резня в Кэмп-Гранте, и она послужила началом новой войны, хотя и довольно локального масштаба. Нападавшие затем были арестованы, но оправданы — якобы из-за отсутствия доказательств вины.

Эта война представляла собой большей частью нескоординированные атаки. Военная кампания против апачей была продолжена на протяжении 1870-х годов в битвах при каньоне Солт-Ривер и Туррет-Пик, являющихся яркими примерами насилия в Аризоне. Военные, а иногда и гражданские лица, преимущественно из района Тусона, часто преследовали различные группы апачей, чтобы положить конец их набегам, кражам скота и побегам из резерваций. Группы западных апачей присоединились к явапаям. Объединёнными усилиями они продолжили войну до 1875 года.

Увеличение роли участия правительства США в Апачских войнах[править | править код]

После Резни в Кэмп-Гранте апачский вопрос привлёк большее внимание американского правительства, нежели ранее. В июне 1871 года командиром департамента Аризона был назначен генерал Джордж Крук. По прибытии в Форт-Апаче первым его действием было создание отряда разведчиков из апачей — того же народа, с которым он собирался воевать, — бывших лояльными американским властям, собираясь активно использовать их в будущем конфликте. Джордж Коулер, представитель Бюро по делам индейцев, в это же время провёл ряд встреч с индейскими вождями, в том числе с Эскиминзином. Вождь Делшай не приехал на встречу, но направил Коулеру письмо, в котором не отказывался от идеи мира и заявлял, что готов предоставить всем людям с белым цветом кожи свободный проезд по своим землям.

Однако более всего американцы были заинтересованы в переговорах с мятежным апачским вождём Кочисом, чей возраст к тому моменту уже исчислялся более чем 60 годами. Ни Коулер, ни Крук не были в силах договориться с ним о встрече, несмотря на то, что Крук отправлял к нему в горы индейцев-парламентёров, пытавшихся его разыскать. Единственным, с кем Кочис согласился говорить, стал генерал Гордон Грейнджер, пославший Кочису письмо, в котором предлагал встретиться в ущелье Аламоса. В этом месте находилось индейское агентство, которое передало Кочису и его людям приказ правительства поселиться в этом же месте, однако во время переговоров решение внезапно изменилось: теперь апачам предписывалось переселяться в Форт-Тулароса. Кочис отверг это предложение из-за крайне плохих условий проживания там, однако приказ правительства остался неизменным. Тогда Кочис и его люди приняли решение бежать во внутренние горные районы Аризоны.

В сентябре 1872 года была сформирована новая комиссия, целью которой было найти и захватить Кочиса, возглавляемая генералом Оливером Ховардом и Томом Джеффордсом, в прошлом — другом апачей, который даже имел апачское имя — Таглито. Благодаря переговорам в итоге апачи всё же согласились прекратить сопротивление и поселиться в резервации у гор Чирикауа, находящейся под управлением Джеффордса. Другие племена, как, например, тонто во главе с Делшаем, были отнюдь не столь удачливы, так как их вынудили поселиться в резервации близ Форт-Апаче в 1873 году. Условия проживания там были ужасными, поэтому они в итоге приняли решение бежать к реке Рио-Верде.

Во время этих событий произошло убийство солдата в индейском агентстве в Сан-Карлосе, индейской резервации у Белых гор в восточной Аризоне. Вскоре после инцидента, в убийстве были обвинены апачи Делшая. Объявив его розыск, генерал Крук обещал вознаградить того, кто принесёт ему голову Делшая или доставит его живым, и в июле 1874 года Делшай был приведён к нему двумя пленившими его людьми. В том же году умер Кочис, уже давно тяжело болевший. К 1875 году значительная часть апачей — около четырёх тысяч — уже была поселена в резервациях или бежала в Мексику.

После смерти Кочиса лидерство в племени чоконенов перешло к его сыну Тазе. Он не смог сохранить единство своего народа, а жизнь посвятил побегам из резервации и кражам скота. Из-за протестов поселенцев в этом регионе правительство приняло решение изолировать всех чирикауа в резервации Белых гор в 1875 году. Во главе резервации был поставлен Джон Клюм, член Бюро по делам индейцев. В 1876 году он получил приказ организовать переселение чирикауа в это место, но лишь половина из них сделала это, а другая бежала в Мексику под руководством вождя Гоятлая, более известного как Джеронимо.

Противостояние апачского вождя Викторио белым началось ещё в первой половине 1860-х годов, когда его люди присоединились к силам Кочиса, став его соратниками. В 1865 году уставшие от войны Викторио и ещё один апачский вождь, Нана, встретились с представителями американского военного командования, чтобы попытаться найти выход из затянувшегося конфликта. Американские представители выдвинули единственное условие — возвращение в резервацию Боск-Редондо, что индейцев устроить ни в коей мере не могло. Тем не менее, формально Викторио обещал подчиниться и отвести туда своих людей, но на деле не сделал этого, предпочтя частью партизанских сил Кочиса или бежать в Мексику, если того потребуют обстоятельства. Его люди продолжали устраивать засады на переселенцев и воровать у белых лошадей и скот весьма активно на протяжении пяти последующих лет. При этом любые преступления в этом районе в скором времени стали приписываться людям Кочиса.

В 1871 году комиссар по делам индейцев Эли Паркер пригласил лидеров апачей на встречу в Вашингтон, чтобы провести переговоры по установлению мира на апачских землях. К этому времени существовало уже четыре резервации для апачей в штатах Аризона и Нью-Мексико, и многие из них в конце концов соглашались на проживание там. Кочис, тем не менее, отверг предложение Паркера.

В 1879 году армия апачей под предводительством Викторио начала кампанию (более активную, чем предыдущие партизанские действия) против белых переселенцев в районе Альмы в штате Нью-Мексико. Устроив в этом местечке резню, ставшую известной как Резня в Альме, жертвами которой стали более сорока белых, апачи начали очередную войну, в которой им удалось даже осадить американский форт Тулароса. Тем не менее, победа в войне осталась за армией США.

Год спустя, в августе 1881 года, Джордж Джордан был одним из тех, кто сражался в битве у каньона Карризо на территории штата Нью-Мексико, завершившей войну. После победы сержант Джордан за свои действия на поле боя был награждён Медалью Конгресса.

Всего через несколько дней после боя у каньона Карризо в индейской резервации Форт-Апаче в Аризоне отряд солдат был послан расследовать недавние сообщения о массовых беспорядках среди апачей и для ареста апачского знахаря Ночайделклинне. Его арест тремя разведчиками-индейцами, состоящими на службе у правительства, произошёл мирно, точно так же без происшествий они добрались и до лагеря разведчиков, но сам лагерь к этому времени уже был занят последователями Ночайделклинне. Началась битва при Сибеку-Крик — одно из последних сражений Апачских войн, выигранное апачами, пусть и ценой потерь. На следующий день войска апачей напали на Форт-Апаче — в отместку за гибель Ночайделклинне, которая произошла днём раньше при Сибеку-Крик.

Весной 1882 года апачский воин На-Тио-Тиша возглавил отряд из шестидесяти воинов-апачей с Белых гор. В начале июля они устроили засаду и убили четырёх полицейских в Сан-Карлосе, включая начальника полиции. После этой успешной засады На-Тио-Тиша повёл свою группу воинов на северо-запад, через долину реки Тонто. Местные поселенцы в Аризоне были сильно встревожены этим и требовали защиты от армии США. Для противостояния апачам было послано четырнадцать кавалерийских рот армии из всех фортов в регионе.

В середине июля На-Тио-Тиша повёл своих воинов к Черри-Крик у Могольон-Рим, намереваясь достичь Дженерал-Спрингс, известного водоворота на Крук-Трейл. Заметив, что их группа преследуется одним отрядом американской конницы, апачи устроили засаду в семи милях к северу от Дженерал-Спрингс, где приток Ист-Клиар-Крик образует ущелье в Могольон-Риме. Апачи спрятались на противоположной стороне и ждали в засаде.

Преследовавшую их кавалерийскую роту возглавлял капитан Адна Чаффи. Главный разведчик роты Альберт Сибер обнаружил устроенную апачами ловушку и предупредил о ней войска. В течение ночи одинокая рота Чаффи была усилена ещё четырьмя, прибывшими из Форт-Апаче, под командованием майора Эванса. После этого началась битва при Биг-Драй-Уош, победу в которой одержали американцы.

Завершение войны Викторио[править | править код]

Джеронимо был, вероятно, наиболее известным военным предводителем апачей этого периода, но не единственным. Известность он получил ещё в период зимы 1876-1877 годов, когда совершил множество краж скота, который он затем выменивал на различные вещи, оружие и алкоголь. Многие чирикауа проживали рядом с территорией агентства Охо-Кальенте, лидером которой был апачский вождь Викторио, ещё в 1870 году примирившийся с белыми. В этой ситуации в 1877 году правительство увидело возможность избавиться от угрозы со стороны чирикауа раз и навсегда: после смерти Кочиса политика США изменилась, и теперь всех чирикауа планировалось переселить в Сан-Карлос. Поэтому Джордж Клюм получил приказ арестовать Джеронимо в Белых горах, подстроив их встречу с Викторио; самого Викторио в ходе этой встречи также предполагалось арестовать, а индейцев хитростью заставить прийти в Сан-Карлос, используя это обстоятельство. Однако в итоге был арестован только Джеронимо, Викторио же арестован не был, но также вынужден был переселиться в Сан-Карлос. Джордж Клюм стал полновластным хозяином в резервации Охо-Кальенте.

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

В скором времени условия жизни в ней из-за ухудшения климата стали невыносимыми, и в сентябре Викторио со своими сторонниками самовольно оставили резервацию, чтобы вернуться на свои старые земли в Охо-Кальенте. В 1878 году правительство отдало приказ Викторио возвратиться в Сан-Карлос, и Викторио с группой из 80 бойцов после этого бежал в горы. Тем не менее, вскоре он согласился на новые переговоры, по итогам которых апачам было разрешено поселиться у Форт-Тулароса, в Нью-Мексико. Позже, в 1879 году, Викторио были предъявлены обвинения в краже им и его людьми лошадей, но он, прежде чем его пришли арестовывать, бежал из резервации и возобновил партизанскую войну. С отрядом из 200 воинов он нападал на мексиканских фермеров и американских переселенцев и устраивал засады на военные патрули.

За его голову американское правительство назначило награду в 3000 долларов. Наконец, в 1880 году его отряд был окружён войсками, и в состоявшейся битве погибли 78 апачей, включая и самого Викторио. Однако его союзник, вождь Нана, избежал окружения с другой частью отряда и впоследствии продолжил партизанскую войну.

Из-за сложившейся ситуации в район резервации Белых гор были направлены дополнительные американские войска, стягивающиеся к резервации. Опасаясь ареста, семьсот апачей в сентябре 1881 года бежали из неё, включая Джеронимо, который опасался возможного ареста в том числе за свою прошлую деятельность. Группа, тем не менее, оставалась в родных краях и подстрекала оставшихся в резервации индейцев покинуть её и готовя атаку, но на них начал наступление отряд американской армии под командованием Джорджа Форсайта для отражения возможной атаки апачей. Апачам Джеронимо удалось избежать этого наступления, отступив к югу, в Мексику, но там они столкнулись с мексиканским пехотным полком, который уничтожил большую часть их, включая женщин и детей. Джеронимо же выжил и решил присоединиться к партизанам Наны.

19 апреля 1882 года другой вождь чирикауа, Ху, напал на резервацию Сан-Карлос и уговорил её вождя, Локо, бежать оттуда. Во время битвы воины Ху убили начальника полиции Альберта Стерлинга и Саготала, апача-полицейского на службе у правительства. Ху привёл Локо и около 700 апачей обратно в Мексику.

Прибытие Джорджа Крука[править | править код]

Когда военная обстановка в регионе ухудшилась, численность гарнизонов американской армии в крепостях Форт-Апаче, Форт-Боуи и Форт-Томас значительно возросла. Весной 1883 года генерал Джордж Крук, имевший среди местного населения прозвище Серый Волк, был назначен ответственным за резервации Аризоны и Нью-Мексико, будучи призван взять ситуацию под контроль: пример Джеронимо и его партизан побуждал многих индейцев покидать резервацию.

С 200 союзными апачами он отправился в Мексику, так как между правительствами двух стран было заключено соглашение о том, что их армии могут пересекать границу, преследуя индейцев. Весной 1883 года он отыскал там лагерь Джеронимо, сначала некоторое время преследовал его, а затем с помощью Тома Хорна, переводчика, после ряда встреч убедил Джеронимо вернуться в резервацию Сан-Карлос, но при условии, если другие вожди поддержат это, что и случилось. Вожди Бонито, Локо и Нана согласились идти с Круком обратно. Ху остался в Мексике, где случайно умер в ноябре этого же года. Джеронимо не возвращался в США до февраля 1884 года. При этом он вновь украл у мексиканцев некоторое количество крупного рогатого скота и товаров, но Крук приказал всё вернуть обратно владельцам.

Крук предпринял некоторые реформы резерваций: его политика по отношению к индейцам, как и прошлые годы при переговорах с Кочисом, оставалась достаточно гуманной. Ведя личные беседы с индейцами, Крук узнал об их недоверчивом отношении к правительству. Кроме того, многие так называемые индейские агенты открыто обманывали апачей. Также невыносимой была осада поселенцев, которые требовали у индейцев всё новые земли и занимали их. Одной из реформ, начатых Круком, было разрешение апачам свободно избирать место проживания в рамках резервации, выселение шахтёров с территории резерваций и разрешение заключать контракты на поставки продовольствия непосредственно самим индейцам, а не переселенцам. Кроме того, он пытался организовать в резервации индейское самоуправление, как ранее делал Джордж Клюм.

Но местные газеты критиковали его за то, что он был слишком снисходителен к апачам. Они буквально демонизировали Джеронимо. К 1885 году в резервации процветали бродяжничество, азартные игры и поножовщина. Сам Джеронимо однажды подрался с другим вождём, Чато, когда тот отказался бежать вместе с ним из резервации. 17 мая 1885 года Джеронимо, будучи пьяным и испуганным требованиями о его аресте и казни через повешение, напечатанными в газетах, снова бежал в Мексику. Его сопровождали вожди Мангас, Чиуауа и Нана; группа состояла в общей сложности из 35 мужчин, 101 женщины и 8 детей.

После бегства апачей газеты напечатали статью «Апачи на свободе!», а слово Джеронимо стало символом кровавой войны. Джеронимо же, тем не менее, стремился лишь достигнуть западной части Сьерра-Мадре в Мексике. Вскоре вождь Чиуауа с небольшим отрядом отделился от группы Джеронимо, и армия начала преследовать его. Чтобы выжить, он начал совершать разбойные нападения на жителей окрестностей, но все эти преступления приписывали не ему, а Джеронимо.

Под давлением местных газет, из которых особенно активной была Tombstone Epitaph, выпускавшаяся в Тусоне обществом «Тусон Ринг», весной 1886 года Крук отправился в погоню за Джеронимо; его сопровождали в том числе Чато и сын Кочиса, Альчис. Он настиг его у самой границы Мексики, в Сьерра-Мадре, в марте, где он пытался избежать преследования мексиканской армии. По некоторым данным, армейское командование начало переговоры с ними: 25 мая 1886 года Крук предложил Джеронимо безоговорочную капитуляцию и отправку на восток страны, во Флориду; Джеронимо согласился, но при условии, что через два года им позволят возвратиться в Аризону; Крук отказал. По пути в Форт-Боуи Джеронимо и возглавляемые им апачи всё же бежали, и Крук не смог их догнать. Не последнюю роль в их решении бежать сыграл некий местный фермер, который дал многим из апачей спиртного и рассказал им жуткие слухи о их будущей участи — будто бы всех их собираются повесить в Аризоне.

Военный департамент объявил Круку выговор за провал, припомнив ему также его мягкое отношение к индейцам, после чего он ушёл в отставку.

Его место в апреле 1886 года занял бригадный генерал Нельсон Майлз. Он развернул более двух десятков гелиографов для координации действий 5000 солдат, 500 разведчиков-апачей, 100 разведчиков-навахо и около пяти тысяч гражданских ополченцев против Джеронимо и его отряда из всего лишь 24 воинов. Лейтенант Чарльз Гейтвуд и разведчики-чирикауа Мартин и Кайтах обнаружили Джеронимо и его людей в сентябре 1886 года в Сьерра-Мадре и убедили их сдаться Майлзу.

Джеронимо и его отряд, по численности всегда несоизмеримо уступая американским войскам, всё же сумели убить несколько десятков американцев и мексиканцев во время рейда на Медвежью Долину (Bear Valley) и подобных атак, которые они совершали во время своей войны с белыми. Военные взяли в плен Джеронимо и всех его людей, а также некоторых разведчиков-апачей, которые могли быть с ним связаны, и некоторых других людей (в частности — давно верного белым вождя араваипа Эскиминзина), и перевезли их затем на Восток, во Флориду, в качестве военнопленных. Президент Гровер Кливленд первоначально требовал повесить Джеронимо, но позже смягчился под влиянием протестов общественности. Некоторые из апачей и их семей были арестованы в Форт-Мэрион, а также во Флориде.

Рядом с местом, где был расположен Форт-Мэрион, находился курортный городок Сант-Августин, в котором отдыхали многие северяне, среди которых были учителя и миссионеры, заинтересовавшиеся судьбой пленных апачей. Добровольцы из их числа принимали участие в попытках обучения апачей говорить и писать по-английски, рассказать им об основах христианской религии и американской культуры. Многие жители собрали средства для отправки 20 юношей-апачей для обучения в колледже, после того как они были освобождены из заключения. Большинство из них было принято в Исторический чёрный колледж института Хамптона. Многие апачи, тем не менее, погибли в тюрьмах и от непривычного климата, холода и влажности, заразившись туберкулёзом и менингитом. Позже дети-апачи были отправлены в трудовой интернат Карлайл в Пенсильвании, где 50 из них погибли.

После тюремного заключения многие апачи также были размещены в казармах Маунт-Вернон в Алабаме. В конце концов по прошествии двадцати шести лет апачи во Флориде были освобождены и могли вернуться на юго-запад, в Аризону, как, в частности, случилось с Эскиминзином и араваипами, но Джеронимо еще до этого, в 1894 году, был отправлен в Форт-Силл, Территория Оклахома, — ему на родину было возвращаться запрещено. Там в 1909 году он и умер. Некоторые другие апачи также были переселены в Оклахому; многие чирикауа и мескалеро остались жить в Нью-Мексико, где проживают и поныне.

Помимо войн Кочиса и Джеронимо, было также много других, гораздо менее известных сражений. Так, в Аризоне в начале 1864 года действовал некий белый бандит Король Вусли, который, явившись однажды на встречу апачей, приказал своим людям расстрелять их всех (это событие носит название bloody tanks). В том же году апачи и явапаи убили американского солдата, который взял на воспитание найденного им мальчика-туземца. Мальчик был возвращён в племя, но белые ответили военными действиями, в ходе которых множество апачей было уничтожено.

Явапаи также были вовлечены в локальные конфликты: например, в сражении у пещеры Черепа рядом с каньоном Лейк они потеряли 76 человек, а в сражении при Туррет-Пик — 50. В конце концов они в количестве 2300 человек были вынуждены поселиться в резервации у Рио-Верде. Ситуация с продовольствием и санитарные условия там были ужасные, в феврале 1875 года резервация была закрыта, и 1500 явапаев были отправлены в резервацию Сан-Карлос.

Несмотря на капитуляцию Джеронимо и его воинов в 1886 году, воины апачей продолжали сопротивление американцам и мексиканцам. Кавалерия США совершила несколько военных экспедиций против апачей после 1886 года. Во время одной из них силы 4-го кавалерийского и 10-го кавалерийского полков под командованием первого лейтенанта Джеймса Уотсона преследовали отступавших индейских воинов к северу от Глоба, Аризона, вдоль реки Солт-Ривер. Сержант Джеймс Дэниэлс роты L 4-го кавалерийского полка и сержант Уильям Макбриар взвода K 10-го кавалерийского полка стали последними известными солдатами, получившими Медаль Почёта за свои действия в Апачской войне. Оба они были награждены за «беспримерное мужество и героизм» во время атаки апачей 7 марта 1890 года. Рядовой Броуди из взвода A Индейских скаутов также был награждён за «верность, ревностность и огромное упорство, какие только возможно встретить среди скаутов апачей».

1. ↑ Massai & The Apache Kid
2. ↑ Michno, F. Gregory. — C.367
3. ↑ Rajtar, Steve. Indian War Sites: A Guidebook to Battlefield, Monuments and Memorials, State by State with Canada and Mexico, McFarland & Company, Jefferson North Carolina, 1999. С. — 159.

Значение слова АПАЧИ. Что такое АПАЧИ?

• Апа́чи (англ. Apache) — собирательное название для нескольких культурно родственных племён североамериканских индейцев, говорящих на апачских языках атабаскской ветви семьи на-дене.

Источник: Википедия

• апачи

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

• Апачи

  1. округ на северо-востоке американского штата Аризона с окружным центром Сент-Джонс

Источник: Викисловарь

Делаем Карту слов лучше вместе

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я стал чуточку лучше понимать мир эмоций.

Вопрос: скоротечный — это что-то нейтральное, положительное или отрицательное?

Положительное

Отрицательное

Смотрите также

• 
  Гигиеническая чистка лица что это такое
• 
  Гликоделин что это такое
• 
  Фм что это такое в номерах
• 
  Арбалет что это такое
• 
  Палантин что это такое фото
• 
  Гаманок что это такое
• 
  Уреаплазма специес что это такое
• 
  Поясничный лордоз сглажен что это такое
• 
  Ассертивность что это такое
• 
  Тиамин что это такое
• 
  Кофе лювак что это такое