Download the PHP package bdk/simplecache without Composer

SimpleCache

Fork of matthiasmullie/scrapbook

• Installation & usage
• Adapters
  • Memcached
  • Redis
  • Couchbase
  • APC(u)
  • PdoMySQL
  • PdoPgSQL
  • PdoSQLite
  • Flysystem
  • Memory
• Features
  • Local buffer
  • Transactions
  • Stampede protection
  • Sharding
• Interfaces
  • KeyValueStore
  • psr/cache
  • psr/simple-cache
• Collections
• Compatibility
• License

Installation & usage

Simply add a dependency on bdk/simplecache to your composer.json file if you use Composer to manage the dependencies of your project:

The exact bootstrapping will depend on which adapter, features and interface you will want to use, all of which are detailed below.

This library is built in layers that are all KeyValueStore implementations that you can wrap inside one another if you want to add more features.

Here's a simple example: a Memcached-backed psr/cache with stampede protection.

Just take a look at this "build your cache" section to generate the exact configuration you'd like to use (adapter, interface, features) and some example code.

Adapters

Memcached

Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.

The PECL Memcached extension is used to interface with the Memcached server. Just provide a valid \Memcached object to the Memcached adapter:

Redis

Redis is often referred to as a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperloglogs.

The PECL Redis extension is used to interface with the Redis server. Just provide a valid \Redis object to the Redis adapter:

Couchbase

Engineered to meet the elastic scalability, consistent high performance, always-on availability, and data mobility requirements of mission critical applications.

The PECL Couchbase extension is used to interface with the Couchbase server. Just provide a valid \CouchbaseBucket object to the Couchbase adapter:

APC(u)

APC is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code.

With APC, there is no "cache server", the data is just cached on the executing machine and available to all PHP processes on that machine. The PECL APC or APCu extensions can be used.

MySQLi

MySQL is the world's most popular open source database. MySQL can cost-effectively help you deliver high performance, scalable database applications.

While a database is not a genuine cache, it can also serve as key-value store. Just don't expect the same kind of performance you'd expect from a dedicated cache server.

But there could be a good reason to use a database-based cache: it's convenient if you already use a database and it may have other benefits (like persistent storage, replication.)

PdoMySQL

MySQL is the world's most popular open source database. MySQL can cost-effectively help you deliver high performance, scalable database applications.

While a database is not a genuine cache, it can also serve as key-value store. Just don't expect the same kind of performance you'd expect from a dedicated cache server.

But there could be a good reason to use a database-based cache: it's convenient if you already use a database and it may have other benefits (like persistent storage, replication.)

PdoPgSQL

PostgreSQL has a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness.

While a database is not a genuine cache, it can also serve as key-value store. Just don't expect the same kind of performance you'd expect from a dedicated cache server.

But there could be a good reason to use a database-based cache: it's convenient if you already use a database and it may have other benefits (like persistent storage, replication.)

PdoSQLite

SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.

While a database is not a genuine cache, it can also serve as key-value store. Just don't expect the same kind of performance you'd expect from a dedicated cache server.

Filesystem

File based cache

Flysystem

Uses league\flysystem to abstract away the file operations, and will work with all kinds of storage that league\filesystem provides.

Memory

PHP can keep data in memory, too! PHP arrays as storage are particularly useful to run tests against, since you don't have to install any other service.

Stuffing values in memory is mostly useless: they'll drop out at the end of the request. Unless you're using these cached values more than once in the same request, cache will always be empty and there's little reason to use this cache.

However, it is extremely useful when unittesting: you can run your entire test suite on this memory-based store, instead of setting up cache services and making sure they're in a pristine state...

Features

In addition to the default cache functionality (like get & set), Scrapbook comes with a few neat little features. These are all implemented in their own little object that implements KeyValueStore, and wraps around a KeyValueStore. In other words, any feature can just be wrapped inside another one or on top of any adapter.

Local buffer

Buffered wrapper helps reduce requests to your real cache. If you need the request the same value more than once (from various places in your code), it can be a pain to keep that value around. Requesting it again from cache would be easier, but then you get some latency from the connection to the cache server.

Buffered will keep known values (items that you've already requested or written yourself) in memory. Every time you need that value in the same request, it'll just get it from memory instead of going out to the cache server.

Just wrap the Buffered class around your adapter (or other features):

Transactions

Transactional wrapper makes it possible to defer writes to a later point in time. Similar to transactions in databases, all deferred writes can be rolled back or committed all at once to ensure the data that is stored is reliable and complete. All of it will be stored, or nothing at all.

You may want to process code throughout your codebase, but not commit it any changes until everything has successfully been validated & written to permanent storage.

While inside a transaction, you don't have to worry about data consistency. Inside a transaction, even if it has not yet been committed, you'll always be served the one you intend to store. In other words, when you write a new value to cache but have not yet committed it, you'll still get that value when you query for it. Should you rollback, or fail to commit (because data stored by another process caused your commit to fail), then you'll get the original value from cache instead of the one your intended to commit.

Just wrap your KeyValueStore adapter inside the Transactional wrapper:

And TA-DA, you can use transactions!

Stampede protection

A cache stampede happens when there are a lot of requests for data that is not currently in cache, causing a lot of concurrent complex operations. For example:

• cache expires for something that is often under very heavy load
• sudden unexpected high load on something that is likely to not be in cache

In those cases, this huge amount of requests for data that is not in cache at that time causes that expensive operation to be executed a lot of times, all at once.

StampedeProtector is designed counteract that. If a value can't be found in cache, a placeholder will be stored to indicate it was requested but didn't exist. Every follow-up request for a short period of time will find that indication and know another process is already generating that result, so those will just wait until it becomes available, instead of crippling the servers.

Just wrap the StampedeProtector layer around your adapter (or other features):

Sharding

When you have too much data for (or requests to) 1 little server, this'll let you shard it over multiple cache servers. All data will automatically be distributed evenly across your server pool, so all the individual cache servers only get a fraction of the data & traffic.

Pass the individual KeyValueStore objects that compose the cache server pool into this constructor & the data will be sharded over them according to the order the cache servers were passed into this constructor (so make sure to always keep the order the same.)

The sharding is spread evenly and all cache servers will roughly receive the same amount of cache keys. If some servers are bigger than others, you can offset this by adding that cache server's KeyValueStore object more than once.

Data can even be sharded among different adapters: one server in the shard pool can be Redis while another can be Memcached. Not sure why you would want to do that, but you could!

Just wrap the Shard layer around your adapter (or other features):

Interfaces

Scrapbook supports 3 different interfaces. There's the Scrapbook-specific KeyValueStore, and then there are 2 PSR interfaces put forward by the PHP FIG.

KeyValueStore

KeyValueStore is the cornerstone of this project. It is the interface that provides the most cache operations: get, getMultiple, set, setMultiple, delete, deleteMultiple, add, replace, cas, increment, decrement, touch & flush.

If you've ever used Memcached before, KeyValueStore will look very similar, since it's inspired by/modeled after that API.

All adapters & features implement this interface. If you have complex cache needs (like being able to cas), this is the one to stick to.

A detailed list of the KeyValueStore interface & its methods can be found in the documentation.

psr/cache

PSR-6 (a PHP-FIG standard) is a drastically different cache model than KeyValueStore & psr/simple-cache: instead of directly querying values from the cache, psr/cache basically operates on value objects (Item) to perform the changes, which then feed back to the cache (Pool.)

It doesn't let you do too many operations. If get, set, delete (and their *multi counterparts) and delete is all you need, you're probably better off using this (or psr/simple-cache, see below) as this interface is also supported by other cache libraries.

You can easily use psr/cache by wrapping it around any KeyValueStore object:

A detailed list of the PSR-6 interface & its methods can be found in the documentation.

psr/simple-cache

PSR-16 (a PHP-FIG standard) is a second PHP-FIG cache standard. It's a driver model just like KeyValueStore, and it works very much in the same way.

It doesn't let you do too many operations. If get, set, delete (and their *multi counterparts) and delete is all you need, you're probably better off using this (or psr/cache, see above) as this interface is also supported by other cache libraries.

You can easily use psr/simple-cache by wrapping it around any KeyValueStore object:

A detailed list of the PSR-16 interface & its methods can be found in the documentation.

Collections

Collections, or namespaces if you wish, are isolated cache subsets that will only ever provide access to the values within that context.

It is not possible to set/fetch data across collections. Setting the same key in 2 different collections will store 2 different values that can only be retrieved from their respective collection.

Flushing a collection will only flush those specific keys and will leave keys in other collections untouched.

Flushing the server, however, will wipe out everything, including data in any of the collections on that server.

Here's a simple example:

getCollection is available on all KeyValueStore implementations (so for every adapter & feature that may wrap around it) and also returns a KeyValueStore object. While it is not part of the PSR interfaces, you can create your collections first and then wrap all of your collections inside their own psr/cache or psr/simple-cache representations, like so:

Compatibility

Where possible, Scrapbook supports PHP versions 5.3 up to the current version, as well as HHVM. Differences in the exact implementation of the cache backends across these versions & platforms will be mitigated within Scrapbook to ensure uniform behavior.

Compatibility with all of these versions & platforms is tested on Travis CI using the official PHP Docker images, which means that PHP<=5.5 is no longer actively being tested even though these versions are supported by Scrapbook.

Cache backends that do not have an implementation for a particular version or platform (Flysystem, on older PHP versions) are obviously not supported.

Compatibility with old software versions will not be broken easily. Not unless there is a compelling reason to do so, like security or performance implications. Syntactic sugar is not a reason to break compatibility.

License

Scrapbook is MIT licensed.