Комментарии

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

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

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

— Нужно сохранить огромное количество данных  —  около терабайта.
— Кэш должен выдерживать от 50 до 1 млн запросов в секунду.
— Ожидаемая задержка  —  около 1 мс.
— LRU (Least Recently Used)  —  алгоритм, при котором вытесняются значения, которые дольше всего не запрашивались.
— 100% доступность.
— Масштабируемость.

Шаблоны доступа к кэшу

— Кэш сквозной записи. Всякий раз, когда приходит какой-либо запрос на “запись”, он будет поступать в БД через кэш. Запись считается успешной только в том случае, если данные успешно записаны и в кэш, и в БД.
— Кэш прямой записи. Запрос на запись идет напрямую в БД, минуя кэш, и подтверждение отправляется обратно. Данные не уходят в кэш, а записываются туда только при первом промахе кэша.
— Кэш обратной записи. Обновленная запись отправляется в кэш, данные сохраняются в кэше, и подтверждение отправляется немедленно. Затем другой сервис передает данные в БД.

Структура данных для реализации кэша называется “хеш-таблицей”. Все, что нам нужно,  —  это функция хеширования, ключ и значение.
Работа с хеш-таблицей

Как показано изображении, у нас есть три набора данных: “яблоко”, “мальчик” и “кот”, которые необходимо сохранить в хеш-таблице. Эти значения задаются в качестве входных параметров для функции хеширования (hashCode()), откуда мы получаем хешированные значения, в данном случае 53, 78 и 76. Затем эти значения делятся на количество ячеек в корзине, т.е. в данном случае на 10, и сохраняются в ячейке, номер которой совпадает со значением остатка: 53 в ячейке №3, 78 в ячейке №8 и так далее.

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

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

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

Как показано на рисунке, все значения оранжевого цвета хранятся в узле 1, а синего  —  в узле 2. Если по какой-либо причине узел 2 выйдет из строя, эти два положения, т. е. ячейки под номерами 9 и 10, станут недоступны. Хеш-таблица в таком случае остается прежней, но размер корзины теперь равен 8. Теперь для того же примера “яблоко” нужно брать остаток от деления на 8  —  53/8. Вместо 3 получаем 5. В данном случае эта ячейка пуста.

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

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

Для значения “яблоко” мы передаем его в функцию хеширования и получаем результат: 2394. Берем этот хеш-номер и сразу находим местоположение  —  набор ключей, который больше 2394, в данном случае это 3030. Мы сохраняем значение здесь.

Допустим, есть еще один ключ “шарик” со значением 2567  —  он также будет храниться в том же месте цепочки. Если мы получили хешированное значение 11000, то, поскольку доступного значения в ячейках нет, мы возвращаемся к началу и сохраняем в 1000. Это что-то вроде закольцовки. Вот как работает согласованное хеш-кольцо.
Политика вытеснения кэша

Как вытеснять кэш и когда нужно это делать?

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

Одна из распространенных стратегий вытеснения  —  Least Recently Used или LRU. Она предполагает удаление записи, к которой за последнее время обращались реже всего.

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

Мы разобрались с хеш-таблицами, оперативной памятью и LRU. Теперь нам нужен сервис, который обслуживает запросы на получение/размещение/удаление (get/put /delete). Несмотря на высокую скорость работу, оперативная память все равно блокирует вызовы. Поэтому нужен эффективный способ удовлетворения этих запросов.

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

Как показано на рисунке выше, у нас есть очередь событий. Туда попадает любой запрос “get/put”. Также есть цикл событий, который выполняется бесконечно и представляет собой однопоточную операцию. Помимо этого, доступен пул потоков, который выполняет только операции ввода-вывода в оперативную память.

Каждый раз, когда мы получаем запрос “get/put”, он помещается в очередь событий. Цикл событий продолжает считывать очередь событий и передает запрос, который свободно располагается в ней. Как только происходит передача в пул потоков, он выполняет обратный вызов и снова считывает очередь событий.

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

Есть так называемые «союзы вебмастеров» или «биржы вебмастеров» — 站长交易 или 连接交易. Не знаю насколько будет корректно тут на них ссылки давать. Поищите лучше по моему кейводру в байде.

У Байду тоже есть свой рейтинг, его посмотреть можно используяю Байду.Вебмастер или другие инструменты, типа: tool.cnzz.cn или tool.seowhy.com

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

Локальные ссылочные биржи, типа Sape в Китае есть?
Есть ли у Baidu аналог ТИЦ/PR?
Учитывает ли Baidu при ранжировании пользовательские факторы или учитывается только ссылочное?

Байду на порядок хуже индексирует сайты, расположенные на иностранных серверах. Официальная позиция такая: Baidu индексирует, а затем ранжирует сайты по многочисленным параметрам, в том числе по скорости ответа сервера. А для многих не секрет, что в Китае для иностранного трафика выделен небольшой канал. Поэтому если хотите попасть в индекс быстрее и быть выше — перенесите сайт в Китай, или как минимум в Гонконг.

Обзаведитесь ICP-лицензией для сайта. Официально: ее наличие не влияет на индексацию. Но на практике ICP помогает Baidu быстрее решить хороший сайт или плохой (если одобрен правительством = хороший), и ставит его быстрее/выше.

Позиционирование и рейтинг в Baidu

Вкратце можно сказать, что как и с другими поисковиками, оценивается множество параметров: уникальность и качество контента, количество внешних ссылок и рейтинг ссылающихся сайтов, «плотность» ключевых слов и так далее. Пожалуй, только с плотностью дело тут обстоит несколько свободнее: если в Google/Яндекс за большое количество ключевиков на «сантиметр» текста можно получить «банхаммером», то Baidu на это смотрит проще. А самую главную роль в ранжировании играет link-building и количество внешних ссылок.

Сразу стоит отметить, что SEM и платная реклама в Байду (Baidu PPC, 百度推广) никак не влияют на индексацию/позиционирование. Но так как у Baidu нет никакой совести и рекламные площади находятся сверху выдачи, снизу, сбоку и посередине (еще совсем недавно они почти никак не отличались от обычных результатов, но сейчас у них другой фон), то этот момент очень важно не упускать. Можно вложить в SEO сотни тысяч юаней и оказаться на первом «органическом» месте, но это будет пятое (а недавно и десятое) место сверху от платных результатов. Некоторые эксперты говорят, что 80% пользователей не знают, что это проплаченные результаты. А те, кто знает, по инерции кликают в середину или в нижние результаты. Но не тут-то было, даже нижние результаты можно купить.

Если сравнить «теплокарты» (heat map) страниц результатов Google и Baidu, то мы увидим, что в Google активно кликают на первые три строчки. В Байду же большое количество кликов размазано по центру и нижним строчкам.

Вообще за Baidu давно сложилась репутация с одной стороны активного проправительственного цензора, а с другой монополиста в поиске, чья выдача продана более чем наполовину. Сейчас по этому поводу негодуют в основном «гики», но и среди обычных интернет-пользователей начинает расти недовольство. Байду старается потихоньку исправлять репутацию, но конкуренты не упускают возможности как-то на этом факте сыграть.

Хронология изоляции от всемирного интернета

1998 год. «Если вы откроете окно для притока свежего воздуха, вы должны ожидать, что с воздухом прилетят и мухи!» — так была ознаменована эпоха Великого китайского фаервола, проекта, направленного на разделение интернет-пространства на Западное и Восточное, и, как следствие, ограничившего доступ рядовому китайскому пользователю к интернету «извне».

2006 год. Google открывается в зоне CN (google.cn) и обязуется блокировать сайты с «нежелательным» контентом, противоречащие политике КНР.

2009 год. Заблокированы сервисы Facebook, YouTube, Twitter, Flickr, Hotmail и частично почтовый клиент Gmail.

2010 год. Google заявляет об уходе с китайского рынка и перенаправляет весь трафик в Гонконг (google.com.hk).

2011 год. Google окончательно теряет свое присутствие в материковом Китае.

Сегодня китайский рынок поделен между четырьмя крупнейшими поисковыми системами:
— Baidu (百度 bǎidù) — доля рынка 73%
— Shenma (神马 shénmǎ) — доля рынка 10.9%
— 360 (360搜索 sōusuǒ) — доля рынка 7.9%
— Sogou (搜狗 sōugǒu) — доля рынка 4.5%

Хронология изоляции от всемирного интернета

1998 год. «Если вы откроете окно для притока свежего воздуха, вы должны ожидать, что с воздухом прилетят и мухи!» — так была ознаменована эпоха Великого китайского фаервола, проекта, направленного на разделение интернет-пространства на Западное и Восточное, и, как следствие, ограничившего доступ рядовому китайскому пользователю к интернету «извне».

2006 год. Google открывается в зоне CN (google.cn) и обязуется блокировать сайты с «нежелательным» контентом, противоречащие политике КНР.

2009 год. Заблокированы сервисы Facebook, YouTube, Twitter, Flickr, Hotmail и частично почтовый клиент Gmail.

2010 год. Google заявляет об уходе с китайского рынка и перенаправляет весь трафик в Гонконг (google.com.hk).

2011 год. Google окончательно теряет свое присутствие в материковом Китае.

Сегодня китайский рынок поделен между четырьмя крупнейшими поисковыми системами:
— Baidu (百度 bǎidù) — доля рынка 73%
— Shenma (神马 shénmǎ) — доля рынка 10.9%
— 360 (360搜索 sōusuǒ) — доля рынка 7.9%
— Sogou (搜狗 sōugǒu) — доля рынка 4.5%

SEO в Китае стоит рассматривать не как основной и, тем более, единственный канал для привлечения китайского трафика и популяризации своего бренда, а как сопутствующий инструмент поискового продвижения сайтов в Китае, наряду с их продвижением в социальных сетях, размещением ссылок на релевантных веб-ресурсах, рекламой у лидеров мнений, а также закупкой трафика у крупнейших рекламных сетей Китая — Baidu Ads, Tencent Ads, Alimama от Alibaba или Ocean Engine от ByteDance.

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

Для размещения контекстной рекламы в Китае, а именно в Baidu, предлагается 3 варианта:

— Платные результаты поиска — ничем не отличаются от органической выдачи.
— Баннерная реклама — размещение логотипа справа от поисковой выдачи.
— Бренд-зона — совмещение предыдущих 2 вариантов.

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

Жесткое регулирование Интернета государством сделало одним из важнейших, а главное доступных способов продвижения сайта в Китае сарафанное радио, или партизанский маркетинг в Сети (рекомендации, отзывы, обзоры и т. п. в таких социальных сетях, как WeChat, QQ и Sina Weibo).

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

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

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

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

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

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

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

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

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

Рекламные кампании, в которых используются фиды с разными статусами, будут показываться по-разному:

— с красным статусом показываться не будут;
— со статусом «Есть проблемы» будут показываться в ограниченном формате;
— со статусом «Успешно загружен» начнут показываться на вторые сутки после запуска.

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

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

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

На поверхности DevSecOps выглядит весьма красивой картинкой, когда же дело доходит до реальных внедрений сложного инструментального комплекса с полноценной интеграцией в ифраструктуру разработки, то сталкиваешься с суровой реальностью). Решения класса ASOC способны сильно помочь, и, на мой взгляд, в обозримой перспективе будут консолидироваться под большими стратегическими игроками — вендорами из квадранта Application Security Testing.

Отличная обзорная статья по делу! Тоже считаю, что необходимо интегрировать процессы Sec в общий agile пайплайн devops процессов. К сожалению, сталкиваюсь с тем, что нынешние инструменты или сильно платные, или сильно разрозненные и достаточно сложно интегрируются друг в друга. Модульностью даже и не пахнет. А вендорам это особо и не нужно — у них задача одна — подсадить клиента на иглу своего продукта(-ов).

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

И каким тогда по Вашему должен быть идеальный финансовый помощник?