Apache Kafka для магазинов

Всем привет! Меня зовут Игорь, я работаю системным архитектором в CSI. Хочу поделиться историей появления в нашем стеке технологий надежного и универсального брокера сообщений. Расскажу, как и для чего мы его используем, поделюсь полезными нюансами и примером с сетью Fix Price. Статей про Apache Kafka уже более, чем достаточно, но наш кейс немного отличается от стандартного использования. Надеюсь, опыт пригодится кому-то ещё.

Немного о нас

Мы создаём софт для автоматизации торговли крупных и не очень сетей магазинов (продукты, спортивные товары, одежда и т.п.). Несмотря на то, что у нас уже запущена целая экосистема узкоспециализированных программных продуктов, всё начиналось с монолита. Он до сих пор установлен на тысячах серверов наших клиентов — и почти весь софт распространяется on-premise. Такая модель доставляет массу сложностей: поддержка разных операционных систем, выпуск дистрибутивов, доставка обновлений, обеспечение обратной совместимости, интеграция с ИС клиента, обеспечение потребления небольших ресурсов у небольших клиентов и одновременное поддержание необходимой производительности в крупных сетях.

Учитывая более сотни тысяч инсталляций наших касс и серверов магазинов, которые обеспечивают непрерывный товарно-денежный обмен, цена ошибок в софте слишком высока. Нет возможности срочно выкатить/откатить фикс, в отличие от SAAS, PAAS-решений. Есть только возможность выпустить патч, доставить его до клиента и применить на всех узлах сети. Бэклоги команд разработки всегда расписаны минимум на полгода вперед, но нам удаётся решать все эти сложности.

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

Основные потоки данных

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

Далее речь пойдет про тот самый монолит – фронт-офисную систему Set Retail 10. Продукт, без преувеличения, имеет огромное количество функционала, а в каждой торговой сети интегрирован с другими ИС.

Основной процесс интеграции с ERP-системой клиента упрощенно выглядит так:

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

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

Отправка товаров на кассы реализована так:

  • сервер после обработки сериализует данные пачками по 100 шт., сохраняет файлы в папки, который сервер Nginx раздаёт, как статику (размеры файла в среднем 100 — 500 КБайт);
  • в качестве очередей выступают таблицы БД;
  • касса периодически вызывает метод сервера и получает упорядоченный список файлов для обработки;
  • касса по HTTP скачивает файл, десериализует, сохраняет в БД, подтверждает обработку файла вызовом метода на сервере, сервер удаляет запись из таблицы.
Пример таблицы-очереди
Пример таблицы-очереди

Обратный поток данных реализован аналогично:

  • касса сериализует документ и отправляет файл по HTTP в Nginx, регистрирует имя файла в очереди сервера вызовом метода;
  • на сервере работает процесс обработки очереди: десериализация полученных файлов, сохранение в БД, удаление файлов.

Изначально Set Retail 10 проектировалась и предназначалась как сервер для одного магазина (супермаркета или гипермаркета), однако с появлением нетипичных для нее задач трансформировалась в центральный сервер для сети магазинов с возможностью централизованной конфигурации и управления. Стала доступна работа и в сетях, где в магазинах нет своего сервера, т.е. один монолит обменивается информацией со всеми кассами.

Все магазины делятся на два типа: с серверами и без

Магазины с выделенными серверами

Это типичные гипермаркеты, супермаркеты с множеством касс. В такой конфигурации обмен касс выполняется с сервером магазина, а он, в свою очередь, способен обмениваться с ERP-системами клиента. Таким образом, нагрузка по обмену и обработке информации распределена между всеми серверами магазинов. Отсутствует «бутылочное горлышко» в виде зависимости от центрального сервера — он используется только для управления. Но это требует финансовых затрат на инфраструктуру и её содержание.

Магазины без выделенных серверов

Обычно имеют 2-3 кассы. Это формат ювелирных, спортивных и небольших продуктовых магазинов. До того момента, как у нас появился клиент Fix Price, наш сервер работал в таких сетях только с сотнями касс.

10 000 касс и один сервер

В один прекрасный день появился проект по смене фронт-офисной системы в сети Fix Price. На тот момент в сети было уже более 6000 касс и планировалось расширение до 10000.

Мы тогда уже проводили нагрузочное тестирование сервера и знали, что при количестве касс более 2000 сервер переставал справляться с нагрузкой. Виной всему — реализация обмена данными с кассами. Кассы каждую минуту опрашивают сервер на предмет наличия данных, в несколько потоков, по разным типам данных, что приводит к выполнению множества SELECT и DELETE при подтверждении. Кроме постоянной нагрузки на слой работы с БД, постоянной занятости пула коннектов, есть еще такая проблема, как снижение эффективности индексов таблиц-очередей, известная, как «распухание» индексов.

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

К выбору брокера были составлены требования:

  • гарантии доставки at-least-once, exactly-once в зависимости от типа данных;
  • обеспечение очередности при доставке сообщений как одному получателю, так и всем (здесь имеется в виду, что через один канал может быть отправлено сообщение для всех касс, для касс конкретного магазина, для конкретной кассы);
  • размер одного сообщения может достигать нескольких мегабайт;
  • персистентность отправляемых данных, настройка времени хранения недоставленных сообщений;
  • обеспечивать работу более 10К клиентов с несколькими очередями сообщений (отправка и получение данных);
  • иметь возможность горизонтального масштабирования, обеспечение отказоустойчивости;
  • иметь возможность мониторинга доставки сообщений до каждого клиента;
  • известность (распространенность), наличие подробной документации, готовый клиент для Java;
  • лицензия Open Source.

Забавно, но когда всё уже было в продакшен, добавилось еще одно требование, об этом чуть позже 🙂

Итак, после небольшого research, выбор сузился до двух решений: RabbitMQ и Apache Kafka. 

Два совершенно разных продукта: push vs poll, богатые возможности vs простота, Erlang vs Java+Scala.

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

Фильтрация доставки сообщений

Apache Kafka реализует единственный паттерн обмена сообщениями publish-subscribe. Producer публикует сообщения в топик, consumer подписывается на топик, выполняет poll и получает сообщения. Причем Consumer не имеет возможности какой-либо фильтрации получаемых сообщений на стороне брокера, т.е. при подписке на топик он будет получать абсолютно все сообщения.

С доставкой документов от касс до сервера всё просто – кассы отправляют в топик, сервер подписан на топик. Надо было только проверить, как брокер «переживет» 10000 отправителей в один топик. А вот с выборочной доставкой сообщений до касс не всё так просто. Есть сообщения для всех касс сети, есть сообщения для касс одного магазина и даже для конкретной кассы, и необходимо соблюдать очередность FIFO для этих сообщений.

Варианты создать по топику или партиции на получателя были отброшены как иррациональные. Можно было бы использовать топики только для отправки сообщений, в которых указывать некий URI на внешний ресурс, например, хранилище S3. Но при on-premise распространении это добавит сложности в развертывании, конфигурировании, мониторинге и освоении «подводных камней» еще одного компонента. Не хотелось также сильно изменять код сервера и кассы в части сериализации и объема передаваемых данных — хотелось добавить лишь ветвление при непосредственно отправке и получении. У каких-то клиентов будет использоваться брокер, но у кого-то останется всё как прежде, on-prem ведь ;).

Изучив возможности API Apache Kafka, мы выбрали такой способ фильтрации сообщений:

  • два топика: один с payload, другой с event;
  • producer публикует сообщение в топик с payload и получает метаданные (RecordMetadata): в какую партицию и с каким смещением было сохранено сообщение;
  • затем producer публикует короткие сообщения в топик с event: кому предназначается сообщение (всем, кассам одного магазина или конкретной кассе) и метаданные о местонахождении payload в топике;
  • получатель создаёт два consumer: первый всегда подписан на топик с event, если полученное сообщение адресовано ему, то второй consumer выполняет assign на конкретную партицию, seek на конкретное смещение и выполняет poll для чтения сообщения с payload.

Чтобы второй consumer получал только одно сообщение, необходимо, как минимум, задать значение параметра max.poll.records = 1. Также ему нет необходимости выполнять commit.

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

Тестирование и внедрение

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

  • скорость доставки всего товарного справочника (20 тысяч товаров, 100 млн цен) до всех касс сети — менее 8 часов;
  • скорость сохранения чеков на сервере — не менее 100 чеков в секунду (при размере БД в 200 млн чеков)

Также фиксировались предполагаемые проблемные места производительности сервера в части обработки данных, потребление ресурсов брокером Apache Kafka и другие важные нам показатели. Нагрузку от касс, приближенную к реальности, создавали многопоточные эмуляторы, которые получали товары и отправляли чеки. Эмулятор — это по сути простое Spring Boot приложение, которое выполняет периодические RPC вызовы к методам сервера по тому же API, что и касса, с такой же интенсивностью, имеет диапазон номеров магазинов и касс и пул потоков. Понадобилось целых 25 хостов для эмуляции 10 тысяч касс. Под брокеры Apache Kafka были выделены сервера с 8-ядерными CPU Xeon и 16GB RAM.

Результаты нагрузочного тестирования показали, что брокер отлично справляется с такой нагрузкой. Потребление CPU не превышало 30%. Нагрузку на диск мы и не ожидали, исходя из предварительных расчетов, т.к. касса не может отправлять сериализованный в 10-20 КБайт чек чаще, чем раз в минуту, а отправка товаров и цен требует предварительной обработки сервером. Запас оперативной памяти также был более, чем достаточным. Оставшаяся память выделяется ОС для файлового кеша, что только положительно сказывается на производительности чтения данных брокером.

К тому моменту, как решение было реализовано и протестировано в продукте, миграция фронт-офисной системы у клиента уже шла полным ходом. Ежедневно десятки касс меняли свой софт. Монолит пока справлялся с нагрузкой. Мы, конечно, предусмотрели переключение на использование Apache Kafka в рантайм центральным «рубильником». Установили и настроили брокер, создали топики. В час Х поменяли одну настройку, она разлетелась по всем кассам и данные пошли в топики. Этот этап прошёл у нас гладко, без происшествий, что не могло не радовать. Но нас поджидал сюрприз )

Экономия трафика

Не прошло и двух недель, как от клиента поступила жалоба. У них выросли затраты на каналы связи. Оказалось, что при аналитике проекта не была учтена важная деталь. Около 10% магазинов находятся в глубинке, куда еще не добрались витые пары и оптоволокно цивилизации. Связь с магазинами осуществляется по воздуху, при помощи модемов мобильной связи. Трафик ограничен в тарифе на каждый месяц. На весь магазин, в котором обычно 2-3 кассы, ограничение составляет от 6 до 10 ГБ на месяц. Если вычесть трафик на другие нужды и разделить на количество касс, то придётся срочно как-то вписываться в 50 МБайт/день на кассу.

Сниффер на нашем тестовом стенде подтверждал, что трафика тратится на порядок больше. Проблема была не с доставкой большого количества чеков, а с доставкой товаров. Точнее, даже при отсутствии сообщений для конкретных касс магазинов, ими тратилось много трафика. В ход пошло тщательное изучение массы настроек Apache Kafka, мозговой штурм и успокоительное для наших менеджеров 🙂

Решение этого, не учтенного на старте, требования было комплексным:

  • long polling,
  • партицирование топика с event-ами,
  • подписка каждой кассы только на одну партицию,
  • настройки consumer, producer.

Подробнее по каждому пункту.

Long polling. Kafka Consumer должен периодически выполнять poll, указывая время ожидания ответа в аргументе (KafkaConsumer.poll(Duration timeout)). Это время ожидания мы увеличили до 5 минут. Если за время ожидания у брокера появляются сообщения — то ответ клиенту поступает сразу.

Количество партиций у топика с уведомлениями мы увеличили до 100. Номер партиции при отправке вычисляется на основе номера магазина получателя (shopNumber % partitionsCount). Если это широковещательное сообщение, то оно отправляется в каждую партицию.

Kafka Consumer на кассе вместо подписки на все партиции топика (subscribe(Collection<String> topics)) теперь подписывается только на одну, вычисляя ее на основе номера магазина (assign(Collection<TopicPartition> partitions)).

Нам необходимо было получать ровно одно payload сообщение, но снифер показывал, что от брокера считывалось больше байт, чем размер этого сообщения. Всё потому, что алгоритм Kafka создан для обеспечения максимальной пропускной способности. Даже если указать в конфиге KafkaConsumer max.poll.records=1, данных может быть считано больше, т.к. предполагается дальнейшее последовательное чтение. Помогла настройка fetch.max.bytes=1. В документации (org.apache.kafka.clients.consumer.ConsumerConfig #MAX_PARTITION_FETCH_BYTES_DOC) сказано, что если размер сообщения больше этой настройки, то одно сообщение всё равно будет доставлено. 

Мы также включили сжатие отправляемых сообщений в конфиге продюсера compression.type=gzip. Поскольку payload сообщение в нашем случае — не одна сериализованная сущность, а список до 100 штук — это также дало положительный эффект.

Замеры трафика по результатам всех этих доработок показали, что на «холостой» трафик, т.е. при отсутствии полезных данных касса тратит теперь лишь около 36 МБайт в месяц. Цель достигнута.

Set ESB

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

Название Set ESB в семействе продуктов Set возникло само собой. Это и шина обмена, и интеграция. Да, это не полноценное, мощное и гибкое ESB-решение со своим UI и прочими штуками, что представляется обычно при упоминании этой аббревиатуры. Для нас это — скорее, подход к решению задач и дополнительный компонент именно к нашим продуктам. Для интеграции с ИС клиента у нас создаются микросервисы с использованием Apache Camel, как это завещают Enterprise Integration Patterns. 

У наших клиентов может быть установлен разный набор наших продуктов, и обмен между ними осуществляется через общий кластер Apache Kafka. Решение уже внедрено во многих сетях магазинов. Кстати, в Fix Price уже более 12 тысяч касс, и сеть продолжает успешно расширяться.

Кроме доставки сообщений, мы получили возможность строить разные агрегаты в realtime, благодаря фреймворку Kafka Streams. Compacted топики используются как небольшие key-value хранилища в интеграции, не требуя установки отдельных СУБД.

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


ссылка на оригинал статьи https://habr.com/ru/company/crystal_service/blog/669974/

Кто нанимает в русскоязычные команды вне РФ и Беларуси? (апрель 2022)

После 24-го февраля появились десятки каналов в Телеграме, постов на VC, Хабре, страничек в Notion, которые собирают компании с удаленкой и релокацией. Но я не нашел ресурсов или каналов, которые концентрируются на одном аспекте: русском языке общения в командах.

На мой взгляд, это важный аспект, потому для ИТ-специалиста с хорошим английским, у которого главная цель — уехать из РФ или Беларуси, найти работу — вообще не проблема даже без всяких чатов и каналов. Английский — единственный профессиональных язык общения в огромном количестве компаний в Англии, Германии, Швеции, ОАЭ, Юго-Восточной Азии, куда довольно легко попасть (потому что сейчас везде острая нехватка специалистов), а релоцируют быстро и без особых проблем.

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

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

Пост не претендует на полноту или оригинальность. Хочется сделать русско-эмигрантский аналог постов Who is hiring? на Hacker News, где участники сообщества рекламируют вакансии в своих компаниях в комментариях.

Список компаний для затравки

Если у компании несколько офисов вне РФ и Беларуси, указана страна, где скорее всего есть русскоязычные команды.

Многие из компаний ниже также предлагают удаленку вне РФ и Беларуси: работа по контракту с З/П в долларах или евро, при этом сам человек может выехать, например, в Грузию или Армению и открыть там местный аналог ИП.

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

Компания Сфера Страны релокации Вакансии
Akvelon* Аутсорс Сербия, Грузия, Армения, Казахстан DevOps
ChainEngine Игры/NFT удаленка Фулстек-разработчик
Checklens Автоматизация ритейла (ИИ) Кипр QA (Python)
Cryptology Финтех/крипта Кипр Python/Go-разработчик
DexGuru Финтех/крипта Сербия DBA
DigiU Финтех/блокчейн удаленка Golang-разработчик
Exness* Финтех Кипр Много
FunCorp Развлечения Кипр, Армения Много
GrowMore* Маркетинг Грузия Много
Hand2Note Покер удаленка C# developer
Helio Games Игры Кипр Много
Ivelum аутсорс, электронный помощник удаленка Python/Django-разработчик
JetBrains* Инструменты для разработки Германия, вероятно, скоро Кипр(?) Много
Laoshi Изучение языка удаленка iOS developer
Latoken Финтех/крипта Грузия, Армения Много
Mercury Development Аутсорс Сербия React developer
Miro (?) Коллаборативная работа Армения По идее, вакансий должно быть много, потому что не все смогут уехать из Перми. Но найти именно такие вакансии сейчас на сайте нельзя. Попробуйте найти их рекрутеров. Также, в комментарии призываются люди с информацией из первых рук.
Nexters Игры Кипр Техлид. Возможно, большинство из вакансий в Москве могут быть на Кипре тоже.
Novakid* Обучение языку удаленка Много
Ortnec Инструменты для веба и маркетинга Кипр Много
PandaDoc* Электронные документы Португалия Много (см. раздел «Remote (Europe)»)
Playrix Игры Армения Арт-директор, продюсер, художник, С++ программист
Prisma Фильтры и обработка фото (ИИ) Кипр Go-разработчик. На сайте вакансий много, но они ведут на недоступные страницы в Notion, поэтому их статус неизвестен.
Superdao Блокчейн удаленка Много
TapClap Игры Кипр, Грузия Разработчик HTML5-игр, UA manager, игровой аналитик
Via Delivery* e-commerce удаленка, в перспективе Турция PHP-разработчик
Wisebits Веб-разработка Кипр Много

Если в списке компаний выше есть какие-то ошибки, напишите мне пожалуйста об этом в личку, исправлю.

Источники:

Формат комментариев с вакансиями

Предлагается использовать формат из постов Who is hiring. В первой строчке такая отбивка:

Название компании | Страны релокации | Вакансии | Нужен ли английский, и если да, какого уровня

А в следующих строчках краткое описание проекта и вакансий.

ссылка на оригинал статьи https://habr.com/ru/post/658685/

Как активировать одноразовые электронные сигареты Pyne в Таиланде?

ВНИМАНИЕ! Ни в коем случае не начинайте их курить, не ознакомившись с инструкцией ниже! Мы не компенсируем поломку, если электронка сгорела по вине пользователя.

Pyne 103 (5% никотина 3000 затяжек) и Pyne 101 (3% никотина 2500 затяжек) — электронные сигареты весьма необычного характера, очень напоминающие вейп. Они имеют особый способ предварительной активации устройства перед тем, как можно начать курение. На упаковках данных устройств напечатана краткая инструкция, которой нужно следовать, но удивительно (нет) — ее почему-то почти никто не читает, и это часто заканчивается приводом устройств в необратимую негодность одно за другим. О том, как избежать такой ситуации, ниже и поговорим.

Начнем с инструкции на упаковке Pyne 103.

Электронная сигарета Pyne 103 инструкция.
Электронная сигарета Pyne 103 инструкция.
  1. Нажмите.
  2. Ждите 3 минуты или коил сгорит.

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

Устройство PYNE 103 в нерабочем состоянии
Устройство PYNE 103 в нерабочем состоянии

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

Устройство PYNE 103 готово к работе
Устройство PYNE 103 готово к работе

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

Указатель на метод активации PYNE 103
Указатель на метод активации PYNE 103

На самом устройстве тоже есть наклейка с указателем куда нажимать.

Вот и все премудрости. Существуют так же Pyne 101

Одноразовые электронные сигареты PYNE 101
Одноразовые электронные сигареты PYNE 101

О них отдельно писать не стану, метод активации абсолютно идентичен Pyne 103. Нажали, ждем 3 (лучше 5) минуты, далее наслаждаемся.

На этом пожалуй всё, надеюсь кому-то моя инструкция всё-таки поможет. Приятного курения.

Купить электронные сигареты в Таиланде с описанием

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

Многие, приезжая в Таиланд, надеются без проблем достать знаменитые и многим полюбившиеся HQD. Однако реальность такова, что здесь это практически нереально. Их просто нет, как и прочих брендов, часто встречающихся в России. А если и есть, то не каждый потянет предлагаемый прайс. Поэтому сейчас мы поговорим об альтернативах.

dot

Одноразовые электронные сигареты dot
Одноразовые электронные сигареты dot

Это пожалуй самая близкая к HQD альтернатива, я бы наверное их даже не отличил вслепую попробовав. Вполне умеренная крепость в 3,5% позволяет и вдоволь посмаковать (не отъехав в больницу с никотиновым отравлением как один мой коллега) и накуриться за один неспешный перекур. Вкус у них довольно насыщенный. Если брать вкусы ICE (в простонародье «с холодком»), то при слишком частых затяжках неслабо бьет по мозгам, так что будьте аккуратны. Каждое устройство рассчитано на 2к затяжек, и по своему опыту скажу, что своё они отрабатывают вполне.

PYNE

На мой взгляд довольно необычная марка электронных сигарет, по нескольким причинам. Начнем с того, что их три модели (может и больше, но мне удалось найти только три), с абсолютно нелогичной на мой взгляд нумерацией. 101, 103 и 105. Казалось бы, что сложного? Последняя цифра – показатель содержания никотина скажете вы? А нет. У 103 содержание никотина 5%, в то время как у 105 всего 3.5%. Далее — наличие порта для подзарядки у любой модели (на случай, если она разрядится раньше положенного, за это производителям отдельный лайк).

Одноразовые электронные сигареты PYNE 105
Одноразовые электронные сигареты PYNE 105

PYNE 105 особо ничем не отличается от прочих электронок хорошего качества. Насыщенный вкус, умеренная крепость — ничего необычного. Само устройство рассчитано на 3000 затяжек, так что мера с подзярядкой вполне уместна. Думаю, 105 подойдет именно для ценителей HQD, если рассматривать PYNE как альтернативу. Содержание никотина 3,5%. Порт для зарядки у них типа USB-C.

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

Одноразовые электронные сигареты PYNE 101
Одноразовые электронные сигареты PYNE 101

PYNE 101 — это 3% никотина и 2500 затяжек. НИ В КОЕМ СЛУЧАЕ не начинайте курить пока не ознакомитесь с инструкцией (кликабельно), если вы пробуете их впервые. Могу только сказать, что для меня она оказалась слабоватой. Зато вкус и аромат мне очень понравились. Можно курить пока не надоест. Порт для подзярядки USB micro B.

Одноразовые электронные сигареты PYNE 103
Одноразовые электронные сигареты PYNE 103

Про PYNE 103 – это уже целые 5% никотина и устройство рассчитано на 3000 затяжек, как и 105. НИ В КОЕМ СЛУЧАЕ не начинайте курить пока не ознакомитесь с инструкцией (кликабельно), если вы пробуете их впервые. Хотите попробовать что-то особенное – начните с них. Не смотря на высокое в отличии от прочих содержание никотина, курится очень мягко. Нет сильного ощущения что куришь что-то особенно крепкое. Порт для подзярядки стандарта USB-C.

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

Часто задаваемые вопросы по PYNE

  1. Если электронная сигареты разрядилась, сколько ее нужно заряжать?
    Ответ: 1-2 часов будет достаточно для длительной работы устройства. Сколько точно его необходимо заряжать до полной зарядки — не известно. Когда идет зарядка, устройство подает признаки жизни путем световой индикации. Когда оно полностью заряжено — индикация по идее пропадает. У меня еще ни одно устройство не разряжалось, потому точнее не скажу.
  2. Устройство PYNE 103 или PYNE 101 изначально не работает, почему и что делать?
    Ответ: Первым делом удостоверьтесь в том, что устройство активировано. PYNE 103 и 101 имеют отличительную особенность от всех электронок — перед первым использованием их надо перевести в рабочее состояние.
Устройство PYNE 103 в нерабочем состоянии
Устройство PYNE 103 в нерабочем состоянии

Для того что бы перевести новый PYNE 103 или 101 в рабочее стостояние, надо вдавить внутрь черную «пимпочку» вверху устройства (без фанатизма, ровно до тех пор, пока она не зайдет туда целиком).

Устройство PYNE 103 готово к работе
Устройство PYNE 103 готово к работе

После данной манипуляции устройство будет куриться (однако перед первым использованием необходимо подождать 3-5 минут и потом курить).

Указатель на метод активации PYNE 103
Указатель на метод активации PYNE 103

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

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


Monster Bars XL

Одноразовые электронные сигареты Monster Bars XL
Одноразовые электронные сигареты Monster Bars XL

Monster Bars – для любителей (обкуриться в хлам и уехать в больничку с никотиновым отравлением как один мой коллега) чего-то покрепче я бы рекомендовал именно их. На деле электронки отличные, как и предыдущие имеют приятные и вкус, и аромат, и в качестве не уступают. Лично для меня с непривычки оказались слегка крепковаты, если много курить, так что можно считать, что название свое оправдывают. Это действительно монстры, самое крепкое что я курил из электронок. Имеют массу вкусов как с холодком (линейка Frozen), так и без него. Характеристики: содержание никотина 5%, заявленное количество паффов (затяжек) – 3500, что довольно экономно, особенно при такой крепости, за что отдельный лайк.

FOF Plus

Одноразовые электронные сигареты FOF Plus
Одноразовые электронные сигареты FOF Plus

Миниатюрные FOF Plus меня порадовали. Очень компактные и при этом довольно вкусные. Да и крепостью обладают не малой, содержание никотина 5%, при этом курятся легко и мягко. Однако я таки умудрился докуриться до головной боли, а значит показатель крепости оправдан, так что не злоупотребляйте. Устройство рассчитано на 600 затяжек.

Smok Vvow

Одноразовые электронные сигареты Smok Vvow
Одноразовые электронные сигареты Smok Vvow

Еще одна марка, представляющая нам миниатюрные электронные сигареты. Значительно слабее предыдущих, что для многих будет являться плюсом. Содержание никотина 2%, рассчитаны так же на 600 затяжек. Но помимо малого содержания никотина, они отличаются еще и легким вкусом. В общем любителем полегче рекомендую. Наверное ближе всего к Elf bar.

DTL Again

Одноразовые электронные сигареты DTL Again
Одноразовые электронные сигареты DTL Again

Приятные миниатюрные электронки на 500 затяжек с насыщенным вкусом. Довольно лайтовые, всего 2% никотина, но при этом крепость в них ощущается сильнее, нежели в смоках, как и сам вкус.

KS Quik

Одноразовые электронные сигареты KS Quik
Одноразовые электронные сигареты KS Quik

Очень вкусные, а благодаря небольшому количеству затяжек еще и компактные. Рассчитаны на 800 затяжек при содержании никотина от 3% до 5%. Крепость ощущается как средняя, вкус же очень насыщенный.

Elf Bar

Одноразовые электронные сигареты Elf Bar 1500
Одноразовые электронные сигареты Elf Bar 1500

Имеется в трех вариациях, главное отличие между которыми — количество затяжек.

Elf Bar 800 и Elf Bar 1500 — практически одинаковы, количество затяжек 800 и 1500 соответственно модели. Это подходит вам, если любите электронки полегче, ведь содержание никотина в них всего 2%.

А вот их старший брат Elf Bar BC3000 — это уже для любителей покурить во взрослому, ибо имеет полностью оправдывающие себя 5% заявленной крепости, приправленных хорошо насыщенным вкусом и рассчитанных аж на 3000 затяжек. Так как объем затяжек велик, в устройстве есть гнездо для подзарядки стандарта Type-C.

Vapeman Dig2

Одноразовые электронные сигареты Vapeman Dig2
Одноразовые электронные сигареты Vapeman Dig2

Я бы назвал это плодом совокупления описанных выше электронок Pyne 105 и Elf Bar BC3000, иначе чем еще можно объяснить полную внешнюю схожесть с первым, и схожесть по крепости и вкусу со вторым. В общем Vapeman Dig2 собрали лучшее от своих «родителей» и даже превзошли их, так как при 5% крепости и классном вкусе имеют аж 3500 затяжек на сигарету. Порт подзарядки разумеется присутствует Type-C.

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



Купон для друга на одну бесплатную доставку с основного склада в Бангкоке за один день.

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

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

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

Чтобы оформить заказ свяжитесь с нами по текущим контактам

Телеграм: https://t.me/kolesnikov1988 

Ватсап: https://wa.me/79529476185 

Вк: https://vk.com/id507517641

Заказы мы отправляем до 3 часов дня, приходят они на следующий день. Если вы сделали заказ после 3 часов дня он прийдет после завтра.

Для доставки нам понадобится ваше имя, адрес, местный номер(или номер отеля) и номер рума в отеле.