Nebulex.Adapters.Replicated (Nebulex v2.0.0-rc.2) View Source
Built-in adapter for replicated cache topology.
Overall features
- Replicated cache topology.
- Configurable primary storage adapter.
- Cache-level locking when flushing cache or adding new nodes.
- Key-level (or entry-level) locking for key-based write-like operations.
- Support for transactions via Erlang global name registration facility.
- Stats support rely on the primary storage adapter.
Replicated Cache Topology
A replicated cache is a clustered, fault tolerant cache where data is fully replicated to every member in the cluster. This cache offers the fastest read performance with linear performance scalability for reads but poor scalability for writes (as writes must be processed by every member in the cluster). Because data is replicated to all servers, adding servers does not increase aggregate cache capacity.
There are several challenges to building a reliably replicated cache. The
first is how to get it to scale and perform well. Updates to the cache have
to be sent to all cluster nodes, and all cluster nodes have to end up with
the same data, even if multiple updates to the same piece of data occur at
the same time. Also, if a cluster node requests a lock, ideally it should
not have to get all cluster nodes to agree on the lock or at least do it in
a very efficient way (:global
is used here), otherwise it will scale
extremely poorly; yet in the case of a cluster node failure, all of the data
and lock information must be kept safely.
The best part of a replicated cache is its access speed. Since the data is replicated to each cluster node, it is available for use without any waiting. This is referred to as "zero latency access," and is perfect for situations in which an application requires the highest possible speed in its data access.
However, there are some limitations:
Cost Per Update - Updating a replicated cache requires pushing the new version of the data to all other cluster members, which will limit scalability if there is a high frequency of updates per member.
Cost Per Entry - The data is replicated to every cluster member, so Memory Heap space is used on each member, which will impact performance for large caches.
Based on "Distributed Caching Essential Lessons" by Cameron Purdy.
Usage
When used, the Cache expects the :otp_app
and :adapter
as options.
The :otp_app
should point to an OTP application that has the cache
configuration. For example:
defmodule MyApp.ReplicatedCache do
use Nebulex.Cache,
otp_app: :my_app,
adapter: Nebulex.Adapters.Replicated
end
Optionally, you can configure the desired primary storage adapter with the
option :primary_storage_adapter
; defaults to Nebulex.Adapters.Local
.
defmodule MyApp.ReplicatedCache do
use Nebulex.Cache,
otp_app: :my_app,
adapter: Nebulex.Adapters.Replicated,
primary_storage_adapter: Nebulex.Adapters.Local
end
The configuration for the cache must be in your application environment,
usually defined in your config/config.exs
:
config :my_app, MyApp.ReplicatedCache,
primary: [
gc_interval: 3_600_000,
backend: :shards
]
If your application was generated with a supervisor (by passing --sup
to mix new
) you will have a lib/my_app/application.ex
file containing
the application start callback that defines and starts your supervisor.
You just need to edit the start/2
function to start the cache as a
supervisor on your application's supervisor:
def start(_type, _args) do
children = [
{MyApp.ReplicatedCache, []},
...
]
See Nebulex.Cache
for more information.
Options
This adapter supports the following options and all of them can be given via the cache configuration:
:primary
- The options that will be passed to the adapter associated with the local primary storage. These options will depend on the local adapter to use.:task_supervisor_opts
- Start-time options passed toTask.Supervisor.start_link/1
when the adapter is initialized.
Shared options
Almost all of the cache functions outlined in Nebulex.Cache
module
accept the following options:
:timeout
- The time-out value in milliseconds for the command that will be executed. If the timeout is exceeded, then the current process will exit. For executing a command on remote nodes, this adapter usesTask.await/2
internally for receiving the result, so this option tells how much time the adapter should wait for it. If the timeout is exceeded, the task is shut down but the current process doesn't exit, only the result associated with that task is skipped in the reduce phase.
Extended API
This adapter provides some additional convenience functions to the
Nebulex.Cache
API.
Retrieving the primary storage or local cache module:
MyCache.__primary__()
Retrieving the cluster nodes associated with the given cache name:
MyCache.nodes()
MyCache.nodes(:cache_name)
Caveats of replicated adapter
As it is explained in the beginning, a replicated topology not only brings with advantages (mostly for reads) but also with some limitations and challenges.
This adapter uses global locks (via :global
) for all operation that modify
or alter the cache somehow to ensure as much consistency as possible across
all members of the cluster. These locks may be per key or for the entire cache
depending on the operation taking place. For that reason, it is very important
to be aware about those operation that can potentally lead to performance and
scalability issues, so that you can do a better usage of the replicated
adapter. The following is with the operations and aspects you should pay
attention to:
Starting and joining a new replicated node to the cluster is the most expensive action, because all write-like operations across all members of the cluster are blocked until the new node completes the synchronization process, which involves copying cached data from any of the existing cluster nodes into the new node, and this could be very expensive depending on the number of caches entries. For that reason, adding new nodes is something exceptional and expected to happen once in a while.
Flushing cache. When flush action is executed, like in the previous case, all write-like operations across all members of the cluster are blocked until the flush is completed (this implies flushing the cached data from all cluster nodes). Therefore, flushing the cache is also considered an exceptional case that happens only once in while.
Write-like operations based on a key only block operations related to that key across all members of the cluster. This is not as critical as the previous two cases but it is something to keep in mind anyway because if there is a highly demanded key in terms of writes, that could be also a potential bottleneck.
Summing up, the replicated cache topology along with this adapter should be used mainly when the the reads clearly dominate over the writes (e.g.: Reads 80% and Writes 20% or less) Also, flushing cache and adding new nodes must be exceptional cases happening only once in a while to avoid performance issues.
Link to this section Summary
Functions
Helper function to use dynamic cache for internal primary cache storage when needed.
Link to this section Functions
Helper function to use dynamic cache for internal primary cache storage when needed.