Новый API функциональной карты в Infinispan 8

Асинхронный и ленивый

Будучи асинхронным API, все методы, которые возвращают один результат, возвращают CompletableFuture, который оборачивает результат, так что вы можете использовать ресурсы вашей системы более эффективно, имея возможность получать обратные вызовы после завершения CompletableFuture, или вы можете связать или составьте их с другими CompletableFuture. Если вы хотите заблокировать поток и дождаться результата, как это происходит с вызовом метода ConcurrentMap или JCache, вы можете просто вызвать ` CompletableFuture.get () ` (для таких ситуаций мы работаем над поиском способов избежать создание ненужного потока, когда вызывающая сторона будет блокироваться на CompletableFuture).

Для тех операций, которые возвращают несколько результатов, API возвращает экземпляры интерфейса Traversable, который предлагает ленивый API в стиле pull для работы с несколькими результатами. Хотя интерфейсы push-стиля для обработки нескольких результатов, такие как RxJava, являются полностью асинхронными, их сложнее использовать с точки зрения пользователя. Traversable, будучи ленивым API-интерфейсом в стиле pull, все еще может быть асинхронным, поскольку пользователь может решить работать с traversable на более позднем этапе, а сама реализация Traversable может решить, когда вычислять эти результаты.

Лямбда прозрачность

Поскольку содержимое лямбда-кодов является прозрачным для Infinispan, API был разделен на 3 интерфейса для операций « только чтение» ( ReadOnlyMap ), «чтение-запись» ( ReadWriteMap ) и «только запись» ( WriteOnlyMap ) соответственно, чтобы обеспечить подсказки для Внутренние элементы Infinispan о типе работы, необходимой для поддержки лямбд.

Например, Infinispan был разработан таким образом, что наши реализации ‘ ConcurrentMap.get () ‘ и ‘ JCache.getAll () ‘ не требуют получения блокировок. Эти  операции get () / getAll () предназначены только для чтения, и, следовательно, если вы вызовите нашу функцию ReadOnlyMap ‘ eval () ‘ или ‘ evalMany () ‘, вы получите то же преимущество. Ключевое преимущество ReadOnlyMap ‘ eval () ‘ и ‘ evalMany ()Операции заключаются в том, что они принимают лямбда-выражения в качестве параметров, что означает, что возвращаемые типы являются более гибкими, поэтому мы можем вернуть значение, связанное с ключом, или мы можем вернуть логическое значение, если значение имеет ожидаемое содержимое, или мы можем вернуть некоторые параметры метаданных из него, например, время последнего доступа, время последнего изменения, время создания, срок службы, информация о версии … и т. д.

Другой важный совет, который требуется для эффективного использования системы, — это знать, когда выполняется операция только для записи. Операции только для записи требуют получения блокировок и, как демонстрируют JCache ‘ void removeAll () ‘ и ` void put (K, V) ‘или ConcurrentMap’ putAll () ‘, они не требуют, чтобы предыдущее значение запрашивалось или читалось , что, как объяснено выше, является очень важной оптимизацией, поскольку для чтения предыдущего значения может потребоваться запрос персистентного уровня или удаленного узла. WriteOnlyMap ‘ eval () ‘, ‘ evalMany () ‘ и ‘ evalAll () ‘следуйте этому же шаблону с дополнительной гибкостью для лямбды, чтобы решить, какую операцию записи выполнить.

Последний тип операций, которые мы имеем, это операции чтения-записи, и в этой категории мы находим CAS-подобные (Compare-And-Swap) операции. Для этого типа операций требуется, чтобы считывалось предыдущее значение, связанное с ключом, и для получения блокировок перед выполнением лямбды.  Большинство операций в операциях ConcurrentMap и JCache находятся в этом домене, включая: « V put (K, V) », « Boolean PutIfAbsent (K, V) », « V replace (K, V) », « Boolean replace (( K, V, V) ‘… и т. Д. ReadWriteMap ‘ eval () ‘, ‘ evalMany () ‘ и ‘ evalAll ()‘предоставить способ для выполнения подавляющего большинства этих операций благодаря гибкости передаваемых лямбд. Таким образом, вы можете выполнять CAS-подобные сравнения не только на основе равенства значений, но и на основе равенства параметров метаданных, таких как информация о версии, и вы можете отправить назад предыдущее значение или логические экземпляры, чтобы указать, успешно ли выполнено сравнение, подобное CAS.

$ DEITY, мне нужно выучить новый API !!!

Этот новый функциональный API, подобный Map, предназначен для дополнения существующих предложений API Key / Value Infinispan, поэтому вы все равно сможете использовать стандартные API ConcurrentMap или JCache, если это лучше всего подходит для вашего варианта использования.

Целевая аудитория для этого нового API:

1. Распределенные или постоянные пользователи сетки данных кэширования / в памяти, которые хотят воспользоваться преимуществами CompletableFuture и / или Traversable для асинхронной / отложенной сетки данных или манипулирования данными кэширования. Очевидным преимуществом здесь является то, что потоки не должны бездействовать в ожидании завершения удаленных операций, но вместо этого они могут уведомляться о завершении удаленных операций, а затем связывать их с другими последующими операциями.
2. Пользователи, которые хотят выйти за рамки стандартных операций, предоставляемых ConcurrentMap и JCache, например, если вы хотите выполнить операцию замены, используя равенство параметров метаданных вместо равенства значений, или если вы хотите извлечь информацию метаданных из значений … и т. Д.

Внутренне мы чувствуем, что этот новый функциональный API, похожий на Map, отгоняет API, подобные Map, которые мы в настоящее время предлагаем (включая ConcurrentMap и JCache), и избавляется от большого дублирования в нашем AdvancedCache API (например, ‘ getCacheEntry () ‘, ‘ getAsync () ‘,’ putAsync () ‘,’ put (K, V, Metadata) ‘… и т. д.) и, следовательно, мы хотим, чтобы все эти API были реализованы с использованием нового функционального Maplike API. Делая это, мы надеемся уменьшить количество команд, которые реализует наша внутренняя архитектура, и, следовательно, уменьшить нашу кодовую базу.

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

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

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

import org.infinispan.commons.api.functional.EntryView.*;
import org.infinispan.commons.api.functional.FunctionalMap.*;
import org.infinispan.manager.*;
import org.infinispan.functional.impl.*;

import java.util.concurrent.CompletableFuture;

// Create Infinispan cache manager
EmbeddedCacheManager cacheManager = ...;

// Construct write-only and read-only map facades
WriteOnlyMap<Integer, String> writeOnlyMap = WriteOnlyMapImpl.create(
    FunctionalMapImpl.create(cacheManager.<Integer, String>getCache().getAdvancedCache()));
ReadOnlyMap<Integer, String> readOnlyMap = ReadOnlyMapImpl.create(
    FunctionalMapImpl.create(cacheManager.<Integer, String>getCache().getAdvancedCache()));

// Execute a write-only operation to store a key/value pair
CompletableFuture<Void> writeFuture = writeOnlyMap.eval(1, "v1", (v, view) -> view.set(v));

// When the write-only operation completes, execute a read-only operation to retrieve the value
CompletableFuture<String> readFuture = 
    writeFuture.thenCompose(r -> readOnlyMap.eval(1, ReadEntryView::get));

// When the read-only operation completes, print it out
readFuture.thenAccept(System.out::println);