Backends

About 4 min

Backends

All examples in this section utilize the default cache frontend for clarity and consistency. Frontends in Hazaar\Cache are independent of the backend implementation, meaning you can freely combine any frontend with any backend. If you wish to use a different frontend, simply specify it in your adapter configuration and no additional changes are required to the backend setup.

`Hazaar\Cache\Backend\Session`

The session backend stores cache data in the current user session. It is simple to use but cannot be shared across users or processes.

Options

Name	Data Type	Default Value	Description
ttl	Integer	`3600`	Time-to-live for cached values in seconds. Values expire after this window.
session	Array	`null`	Session configuration options applied to the session instance if needed.

Pros

Zero external services; always available.
Good for per-user ephemeral data.

Cons

Not shared across sessions or servers.
Cache size is limited by session storage.

Example

$cache = new Hazaar\Cache\Adapter('session', [
    'ttl' => 600,
]);
if (($value = $cache->get('profile:menu')) === false) {
    $value = buildMenuForUser();
    $cache->set('profile:menu', $value);
}

`Hazaar\Cache\Backend\File`

The file backend stores cached data on disk, making it a reliable and portable option that works on any PHP installation.

Options

Name	Data Type	Default Value	Description
cache_dir	String	Application runtime cache path	Directory to store cache files in.
file_prefix	String	`null`	Optional prefix for the cache files.
use_zlib	Boolean	`false`	Enable zlib compression for stored values.
ttl	Integer	`0`	Namespace time-to-live in seconds. `0` disables namespace expiration.
flush	Integer	`3600`	Cleanup interval in seconds for idle cache files.

Pros

Works everywhere without extra services.
Shared between processes on the same host.

Cons

Slower than memory caches.
Requires filesystem access and cleanup.

Example

$cache = new Hazaar\Cache\Adapter('file', [
    'cache_dir' => '/tmp/hazaar-cache',
    'ttl' => 3600,
]);
if (($result = $cache->get('report:weekly')) === false) {
    $result = buildWeeklyReport();
    $cache->set('report:weekly', $result);
}

`Hazaar\Cache\Backend\Apc`

The APC backend uses APCU user cache to store data in memory for very fast access.

Options

This backend uses the general options supported by the adapter (like ttl). No APC-specific configuration is required.

Pros

Extremely fast in-process memory cache.
Supports automatic expiration.

Cons

Requires APCU extension.
Not shared across multiple servers.

Example

$cache = new Hazaar\Cache\Adapter('apc', [
    'ttl' => 120,
]);
if (($value = $cache->get('config:app')) === false) {
    $value = loadAppConfig();
    $cache->set('config:app', $value);
}

`Hazaar\Cache\Backend\Redis`

The Redis backend stores cache data in a Redis server. It is a strong choice for shared, high-performance caching.

Options

Name	Data Type	Default Value	Description
server	String	`localhost`	Redis host to connect to.
port	Integer	`6379`	Redis port to connect to.
dbIndex	Integer	`0`	Redis database index.
ttl	Integer	`0`	Default time-to-live for cached values in seconds.
serverpass	String	`null`	Password for authenticated Redis servers.

Pros

Fast and shared across servers.
Supports expiration and large datasets.

Cons

Requires a running Redis service.
Network latency for remote servers.

Example

$cache = new Hazaar\Cache\Adapter('redis', [
    'server' => '127.0.0.1',
    'port' => 6379,
    'dbIndex' => 1,
    'ttl' => 300,
]);
if (($value = $cache->get('inventory:summary')) === false) {
    $value = loadInventorySummary();
    $cache->set('inventory:summary', $value);
}

`Hazaar\Cache\Backend\Memcached`

The memcached backend stores cache data in a memcached server. It is simple, fast, and commonly used for shared caching.

Options

Name	Data Type	Default Value	Description
server	String or Array	`localhost`	One server or an array of servers.
port	Integer	`11211`	Memcached server port.
use_compression	Boolean	`false`	Enable compression on the connection.
persistent_id	String	`""`	Optional persistent ID for reusing connections.

Pros

Fast and widely supported.
Simple operational model.

Cons

Requires memcached extension and service.
Limited data structures compared to Redis.

Example

$cache = new Hazaar\Cache\Adapter('memcached', [
    'server' => ['127.0.0.1'],
    'port' => 11211,
    'use_compression' => true,
]);
if (($value = $cache->get('pricing:tiers')) === false) {
    $value = loadPricingTiers();
    $cache->set('pricing:tiers', $value, 600);
}

`Hazaar\Cache\Backend\Shm`

The shared memory backend uses PHP SysV shared memory and semaphores. It is the fastest option when it is available.

Options

Name	Data Type	Default Value	Description
ttl	Integer	`3600`	Default time-to-live for cached values in seconds.
size	Integer	`1000000`	Shared memory segment size in bytes.
permissions	Integer	`0666`	Permissions for shared memory segment.
ns_index	Array	`null`	Optional namespace index options: `size` and `permissions`.

Pros

Extremely fast, in-memory storage.
No external service required.

Cons

Requires SysV shared memory and semaphore support.
Data is lost on restart.

Example

$cache = new Hazaar\Cache\Adapter('shm', [
    'ttl' => 120,
    'size' => 2000000,
]);
if (($value = $cache->get('feature:flags')) === false) {
    $value = loadFeatureFlags();
    $cache->set('feature:flags', $value);
}

`Hazaar\Cache\Backend\Dbi`

The DBI backend uses the Hazaar DBI adapter and can be configured with DBI connection options. It can use any DBI-supported driver, including SQLite.

Options

Name	Data Type	Default Value	Description
dbi	Array or String	`null`	DBI connection configuration or named DBI profile.
schema	String	`null`	Optional schema name to create or use.

Pros

Integrates with Hazaar DBI.
Can auto-create schema and table.

Cons

Slower than memory caches.
Requires database access.

Example

$cache = new Hazaar\Cache\Adapter('dbi', [
    'dbi' => [
        'type' => 'pgsql',
        'host' => 'localhost',
        'dbname' => 'hazaar_test',
        'user' => 'hazaar',
        'password' => 'password',
    ],
    'schema' => 'cache',
]);
if (($value = $cache->get('orders:count')) === false) {
    $value = loadOrderCount();
    $cache->set('orders:count', $value, 120);
}

`Hazaar\Cache\Backend\Chain`

The chaining cache backend is slightly different to other backends in that it doesn't store anything itself and instead instantiates a group of other backends that have been requested. The chain backend is also selected a little differently due to each individual backend requiring its own array of backend configuration parameters be passed to it. For this reason, the chain backend is not requested directly, and instead it is used when the $backend parameter of the Hazaar\Cache class is set to chain and you provide a backends option.

The format of the array is dynamic. If no backend options are needed, then the member value can be the name of the backend. To pass backend options the key is the backend name and the value is the array of configuration parameters to send to it.

$config = [
    'type' => 'pgsql',
    'host' => 'localhost',
    'dbname' => 'hazaar_test',
    'user' => 'hazaar',
    'password' => 'password',
];
$cache = new Hazaar\Cache\Adapter('chain', [
    'backends' => [
        'apc' => [],
        'dbi' => ['dbi' => $config],
    ],
]);

The above example shows how to instantiate the chain backend with two real backends, APC and DBI. In this scenario the APC backend will be the primary backend as it is considered to be the faster of the two. Cache writes will occur on both backends but reads will occur on the APC backend. Only if the value does not exist will a read be performed on the DBI backend and if that is successful, the APC backend will be updated with the found value.