суббота, 11 января 2014 г.

Redisson - распределенные и масштабируемые структуры данных Java на основе сервера Redis

Опубликовал первый релиз проекта Redisson. Проект позволяет использвать знакомые всем структуры данных Java (Set, List, Map, Queue, AtomicLong, Lock, CountDownLatch), а также использовть функционал publish/subscribe в распределенном виде с поддержкой масштабирования. Все это достигается благодаря использованию весьма популярного сервера Redis, для которого Redisson является лишь клиентом.

Вам даже не придется знать команды Redis-а, да и возможности вызова команд Redis напрямую нет, т.к. цель проекта предоставить удобный api с использованием уже известных Java-интерфейсов. Для выполнения вызовов на сервере Redis используется пропаченный Redis-клиент - lettuce.

Представленный api по своей стуктуре в чем-то схож с Hazelcast api. Проект Hazelcast может хранить данные только в памяти, что не всегда удобно и влияет на надежность системы. Сервер Redis, в свою очередь, предоставляет три способа хранения данных:
   1. только в памяти
   2. переодическое сохранение на диск (snapshotting) - используется по-умолчанию
   3. лог транзакций, т.е. синхронная запись каждого изменения в лог (append-only file)
Таким образом, благодаря возможностям сервера Redis, мы получаем распределенные java структуры данных с возможностью хранения состояния не только в памяти.

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

Изначально проект задумывался как простая попытка реализовать Map на Java через Redis-команды. Однако дальнейшее изучение команд Redis, (в Redis есть поддержка транзакций, hashes, lists, sets) навело на мысль о реализации более сложных структур, таких как Lock и CountDownLatch.

В проекте более 70 unit-тестов, для запуска которых (по-умолчанию они отключены) нужно запустить локально Redis-сервер и запустить maven-сборку с параметром -DskipTest=false
Примеры использования:
Распределенный Map:
        Config config = new Config();
        config.setConnectionPoolSize(10);
        config.addAddress("some.redis-server.com:8291");
        Redisson redisson = Redisson.create(config);

        ConcurrentMap<String, SomeObject> map = redisson.getMap("anyMap");
        map.put("123", new SomeObject());
        map.putIfAbsent("323", new SomeObject());
        map.remove("123");

        ...

        redisson.shutdown();

Распределенный Lock:
        Redisson redisson = Redisson.create();

        Lock lock = redisson.getLock("anyLock");
        lock.lock();
        lock.unlock();

        // или

        redisson.getLock("anyLock").lock();

        ...

        redisson.getLock("anyLock").unlock();

        ...

        redisson.shutdown();

пятница, 25 мая 2012 г.

Проект Hibernate Dynamic SQL Cache

Выложил на github проект Hibernate Dynamic SQL Cache.

Описание

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

  • HQL-кэш, а также кэш коллекций entity-объектов будут сбрасываться при каждом обновлении данных в хотя бы в одной из таблиц, участвующих в запросе. При очень частых обновлениях таблиц польза от такого рода кэшей сводится к 0.
  • SQL-кэш держит в памяти лишь результат первого вызова запроса и не сбрасывается.

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

  • Запрос должен возвращать только id объекта. По этому id вы можете легко загрузить объект из кэша. (Таким образом получается два обращения к кэшу, что всегда быстрее выполнения запросов к базе)
  • Запрос должен быть только по неизменяемым полям объекта.
  • Вместо использования коллекций в entity-объекте использовать соответствующий SQL-запрос c динамическим обновлением.

Cache provider может использоваться абсолютно любой (Infinispan, Hazelcast, EHCache ...)

Проект опубликован под Apache License 2.0

Пример использования

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

Конфигурация hibernate. Здесь важно отметить использование собственного hibernate.cache.query_cache_factory через который и осуществляется вся логика управления обновлениями кэшей:

Регистрируем com.corundumstudio.hibernate.dsc.QueryCacheEntityListener который будет отслеживать основные операции по всем entity.

Пример DAO-сервиса. com.corundumstudio.hibernate.dsc.CacheCallback - callback через который будет обслуживать операции "insert" или "delete" на объекте (в данном примере SimpleEntity), чтобы результаты запроса были всегда "свежими".

Теперь при вызове SimpleEntityDao.getEntityByPhone, первый раз будет произведено обращение к БД. Последующие вызовы метода будут возвращать значение из кэша, причем если объект SimpleEntity с искомым значением phone будет добавлен в базу он также появится и в результате данного запроса. И наоборот, если объект с таким значением phone будет удален, то результат запроса будет возвращать null

Если результат запроса возвращает список объектов, то в этом случае, при удалении/создании объекта, в списке будет удаляться/добавляться его id

пятница, 13 апреля 2012 г.

BoneCP - производительный пул соединений для БД

BoneCP - библиотека управления соединениями с БД. Использую ее уже более 2-х лет в разных проектах, в том числе и в системах с нагрузкой. Автор позиционирует ее как более производительную замену библиотекам c3p0 и dbcp. Представленные им бенчмарки это только подтверждают.

Среди полезных возможностей можно отметить:

  • логирование всех sql-операций

  • доступ к статистике через JMX

  • кэширование PreparedStatement-ов

четверг, 12 января 2012 г.

Поддержка socket.io протокола на Java

Опубликовал свой первый проект на github - netty-socketio, реализующий серверную поддержку socket.io протокола на java. В основе использован легендарный фреймворк Netty.

Socket.io - библиотека предназначенная для создания постоянной связи браузера с сервером. Таким образом возможно организовывать доставку данных в реальном времени в обе стороны. Socket.io поддерживает несколько транспортных механизмов для организации такого взаимодействия - web-sockets, xhr-polling и т.д.

В моей реализации поддерживается socket.io-client версии 0.8.7+. Из поддерживаемых транспортов пока только xhr-polling и websocket.

среда, 2 марта 2011 г.

Smooks: парсим xml с помощью ... xml

Smooks - отличный инструмент, который решает задачу парсинга xml используя xml-маппинг тэгов и аттрибутов на объекты и их свойства. Вообще продукт позиционируется как инструмент для трансформации, биндинга, валидации и обработки данных в различных форматах (CSV, XML, EDI). Я рассматриваю этот продукт как достойную альтернативу других механизмов парсинга xml - JAXB, JAXP, Digester и пр.

Предположим нам надо распарсить такой вот xml:

Xml необходимо распарсить в List из объектов типа PlayerRole:

Для начала создадим xml-маппинг необходимый для преобразования данных в объекты:

В Smooks все метаданные, необходимые для парсинга участков xml, представляются в виде бинов с сылками друг на друга. Адресация в xml осуществляется с помощью xpath-выражений. Если при парсинге необходима какая-то пост-обработка данных можно воспользоваться возможностью выполнения groovy-скриптов (тэг g:groovy), при этом код работы с xml будет более лаконичн чем на java. Из groovy также возможны обращение к бинам smooks.

Ну и наконец пример запуска механизма парсинга данных с приведенным конфигом:

Чтобы получить результат парсинга надо выбрать бин, обрабатывающий root-овый тэг, в нашем случае это бин с id="roles-bean".

Я выбраю этот движок для разбора xml т.к. он почти не требует кода и интегрирован с groovy. Использую его когда в проекте требуется распарсить различные конфигурационные ресурсы на этапе запуска сервера.

пятница, 14 января 2011 г.

Использование Javassist для генерации прокси в Spring Framework

Известно, что проект cglib давно находится в заброшенном состоянии, также при работе с ним возникают некоторые проблемы, описанные здесь. Наиболее популярная альтернатива этому проекту - javassist. Он используется в таких проектах как JBoss AS, Hibernate, Weld ...

Только вот в Spring он еще не появился. Замена библиотеки cglib, используемой для генерации proxy-объектов, на javassist, судя по плану проекта, состоится в версии 3.1 проекта. Вот jira-таск. В этом же таске я прикрепил аттачи в виде трех классов и пары патчей, которые позволяют окончательно перейти на Javassist.

Для включения поддержки Javassist вам понадобится пристроить к себе в проект вот эти три класса - JavassistAopProxy, JavassistAopProxyFactory и JavassistApplicationContext. Затем вместо spring-овой реализации ApplicationContext-а задействовать org.springframework.aop.framework.JavassistApplicationContext. Если вы не создаете его напрямую, а используете org.springframework.web.context.ContextLoaderListener сконфигурированный в web.xml, то вам необоходимо будет добавить в этот же web.xml такие строки:

суббота, 6 ноября 2010 г.

"Хорошая" новость от Oracle...

Хотя это событие было предсказуемо, после коммерциализации MySQL и OpenOffice, верить в него не хотелось. Похоже oracle хочет разделить версии JVM на "free" и "premium", подробнее тут.