Using IPv6 with Predis was basically impossible due to various inconsistencies
and bugs through the library, now it is supported by all the connection classes.
Following the standard for IPv6 literal addresses in URI strings, the IP literal
must be enclosed within square brackets when passing the parameters as a string:
$parameters = 'tcp://[2001:db8:0:f101::1]:6379';
See https://tools.ietf.org/html/rfc3986#section-3.2.2 for further details.
This commit also fixes#239 making redis-cluster usable with nodes using IPv6.
Instead of using "unix://" you should just use "unix:":
$old = 'unix:///path/to/redis.sock';
$new = 'unix:/path/to/redis.sock';
The old format should be considered obsolete and will not be supported
starting from the next major release of Predis.
Meh
This is handy for accessing remote Redis instances over a secure SSL connection
which is currently a popular option or even requirement with many cloud hosting
environments.
In order to configure the client to use an SSL-encrypted connection the scheme
in the connection parameters must be either "tsl" or "rediss" and a set of SSL
options (see http://php.net/manual/en/context.ssl.php) must be provided via the
"ssl" parameter as a named array.
The following example (which does not necessarily represent an example of good
practices!) illustrates how to set the "ssl" parameter using a named array and
the equivalent URI string:
// Parameters as named array
$parameters = [
'scheme' => 'tls',
'host' => '127.0.0.1',
'ssl' => [
'cafile' => '/home/adaniele/redis.pem',
'verify_peer_name' => false,
],
];
// Parameters as URI string
$parameters = 'tls://127.0.0.1?ssl[cafile]=redis.pem&ssl[verify_peer_name]=1';
Support for SSL is currently limited to the Predis\Connection\StreamConnection
backend but we intend to investigate if it is possible to extend this feature
to Predis\Connection\PhpiredisStreamConnection in the future.
Be aware that using encrypted connections may lead to a performance degradation
especially in the connect() operation due to the overhead of the TLS handshake.
Unfortunately there is no real way to reuse SSL sessions from userland, aside
from enabling persistent connections, but this will work only on PHP >= 7.0.0
because previous versions of PHP do not provide enough info about a stream from
get_stream_meta_data().
NOTE: Redis does not have built-in support for SSL-encrypted connections, but if
you want to expose it to public networks you may want to rely on "stunnel".
Falling back to a default timeout values should be done by the connection class
as it is an implementation detail that may vary depending on the backend.
These parameters augment the set of user-supplied parameters when creating a new
connection, but they do not override specific parameters when already defined.
An example of self-contained configuration using client options:
$client = new Predis\Client('tcp://127.0.0.1', [
'parameters' => [
'timeout' => 10,
],
'connections' => function ($options) {
$factory = $options->getDefault('connections');
$factory->setDefaultParameters($options->parameters);
return $factory;
},
]);
This change will be useful for both redis-cluster and redis-sentinel as it makes
it easy to apply shared parameters such as a common password for authentication
when the server returns one ore more new nodes from response (think of -MOVED).
stream_socket_client() has the undocumented ability to open different persistent
streams by providing a path in the $address string. Previously we supported this
behaviour with a combination of "persistent" and "path" (see #139) but this can
be confusing, especially now that we support the redis:// scheme which uses the
path part of an URI string to specify a database number.
After this change, instead of using an URI string such as:
$parameters = 'tcp://127.0.0.1/first?persistent=1&database=5';
You should use the following ones:
$parameters = 'tcp://127.0.0.1?persistent=first&database=5';
$parameters = 'redis://127.0.0.1/5?persistent=first';
Avoiding "path" makes even more sense when using array connection parameters:
$parameters = [
'host' => '127.0.0.1',
'database' => 5,
'persistent' => 'first',
]
This feature is not supported when using UNIX domain sockets because the path
trick of stream_socket_client() does not play well with the actual path of the
socket file. The client will throw an InvalidArgumentException exception to
notify the user.
NOTE: unfortunately we have to disable the tests for persistent connections when
running under HHVM due to a bug in their implementation of get_resource_type()
preventing us to recognize a persistent stream from userland code.
Serializing an instance of a redis-cluster connection with its nodes
can take more than 1 seconds on extremely slow hardware.
See issue #220 for reference.
This optimization makes it possible to fetch the slots map directly
from the server indicated by the -MOVED response eliminating the need
to use a random node in the pool, which in turn could require Predis
to open a new and useless connection.
This is a more sane default as it allows users to indicate only a few
servers of the whole cluster composition, while it previously required
a more complex configuration of the client using client options.
This feature can be disabled using the "enableAutoSlotsMap()" method.
This change is possible because, after a few changes in redis-cluster,
our default cluster strategy used for client side sharding and the one
used for redis-cluster turned out to be exactly the same, except for
the hashing function used to calculate distribution.
Actually some checks used to enforce correctness are redundant in the
context of redis-cluster (e.g. the one used to make sure that keys in
requests performing cross-keys operations will hash to the same slot,
which is performed by the server) so we could also add a more dumb and
permissive cluster strategy that relies on checks performed by Redis.
Differently to v0.8, the strategy for client-side sharding now uses
the same rules for extracting hash tags from keys especially when
empty tags are found in the string.
CLUSTER SLOTS returns a structured response easier to handle compared
to the bulk response of CLUSTER NODES which must be parsed making the
whole thing more fragile.
CLUSTER SLOTS has been added in Redis 3.0.0b7.
This is more consistent with the actual purpose of this method and
more in-line with a possible future change in the underlying command
used to retrieve the slots map if redis-cluster will implement the
CLUSTER SLOTS command.
* Renamed SingleConnectionInterface to NodeConnectionInterface since
this name is better and makes even more sense in the context of
cluster and replication scenarios.
* Moved specialized aggregate connections (the ones implementing both
predis and redis cluster and master/slave replication) in a newly
created Predis\Connection\Aggregate sub-namespace.
* Removed the "Connection" part from names of aggregate connection
interfaces in the Predis\Connection\Aggregate sub-namespace.
* Changed "Composable" to "Composite" in the name of interfaces and
classes that can use pluggable protocol processors.
Using PHP's "parse_str()" to parse the query string is slightly more
efficient then our own code especially when the number of fields in
the query string grows, with the additional benefit of supporting
arrays for values when brackets are present in fieldnames.
So after this commit, providing this URI string:
$string = 'tcp://127.0.0.1?metavars[]=foo&metavars[]=hoge';
Is equivalent to providing the following named array:
$array = [
'scheme' => 'tcp',
'host' => '127.0.0.1',
'metavars' => ['foo', 'hoge'],
];
Aside from this improvement, the URI parsing behavior has not changed.
Only named arrays are explicitly accepted now, but the old behaviour
of creating a connection parameters instance out of an URI string or
a named array is still available using the "create()" static method.
$array = ['host' => '127.0.0.1', 'timeout' => 1];
$uri = 'tcp://127.0.0.1?timeout=1';
$parameters = new ConnectionParameters($array); // Arrays only
$parameters = ConnectionParameters::create($array); // Arrays OK
$parameters = ConnectionParameters::create($uri); // Strings OK
The purpose of the change is to have a more concise constructor with a
well defined signature.
List of changes:
- The cluster connection can be initialized with a partial list of
nodes, the full slots map will be fetched from Redis itself using
the CLUSTER NODES command.
- The slots map can be optionally retrieved from Redis if the server
returns a -MOVE response, otherwise only the interested slot will
be permanently reassigned to the new target node.
- $cluster->connect() connects to a random connection in the pool
instead of forcing the connect operation on all the connections.
Status response objects are needed mostly to make it possible from the
client perspective to differentiate a status response with the payload
"OK" from a normale bulk reply containing "OK".
The biggest change is for commands returning +OK responses: these were
previously translated to TRUE (bool value), but they are now returned
as instances of Predis\Response\Status. Just to illustrate an example
of the possibilities with this change we will use SET since it is the
most widely used command returning +OK:
$response = $client->set('foo', 'bar');
echo $response; // 'OK'
$response == 'OK'; // TRUE
isset($response->ok); // TRUE
$response == true; // TRUE
$response === true; // FALSE
$response instanceof Predis\Response\ObjectInterface; // TRUE
$response instanceof Predis\Response\Status; // TRUE
For those checking responses returned by commands such as SET or PONG,
the breaking change basically lies in the usage of strict comparison:
doing $response === true will now evaluate to FALSE instead of TRUE.
By default Predis caches common status responses such as OK or QUEUED
to lower the memory usage when using pipelines or transactions.
Daniele Alessandri