Fix typos/bad Markdown in cluster.markdown

michael-grunder · michael-grunder · commit 21c3ef94e848 · 2022-09-19T12:17:06.000-07:00
diff --git a/cluster.markdown b/cluster.markdown
@@ -8,7 +8,7 @@ Redis introduces cluster support as of version 3.0.0, and to communicate with a
 To maintain consistency with the RedisArray class, one can create and connect to a cluster either by passing it one or more 'seed' nodes, or by defining these in redis.ini as a 'named' cluster.
 
 #### Declaring a cluster with an array of seeds
-~~~php
+```php
 // Create a cluster setting three nodes as seeds
 $obj_cluster = new RedisCluster(NULL, Array('host:7000', 'host:7001', 'host:7003'));
 
@@ -21,24 +21,24 @@ $obj_cluster = new RedisCluster(NULL, Array("host:7000", "host:7001"), 1.5, 1.5,
 
 // Connect with cluster using password.
 $obj_cluster = new RedisCluster(NULL, Array("host:7000", "host:7001"), 1.5, 1.5, true, "password");
-~~~
+```
 
 #### Loading a cluster configuration by name
 In order to load a named array, one must first define the seed nodes in redis.ini.  The following lines would define the cluster 'mycluster', and be loaded automatically by phpredis.
 
-~~~ini
+```ini
 # In redis.ini
 redis.clusters.seeds = "mycluster[]=localhost:7000&test[]=localhost:7001"
 redis.clusters.timeout = "mycluster=5"
 redis.clusters.read_timeout = "mycluster=10"
 redis.clusters.auth = "mycluster=password"
-~~~
+```
 
 Then, this cluster can be loaded by doing the following
 
-~~~php
+```php
 $obj_cluster = new RedisCluster('mycluster');
-~~~
+```
 
 ## Connection process
 
@@ -60,7 +60,7 @@ Because of this, the RedisCluster class will update its keyspace mapping wheneve
 ## Automatic slave failover / distribution
 By default, RedisCluster will only ever send commands to master nodes, but can be configured differently for readonly commands if requested.
 
-~~~php
+```php
 // The default option, only send commands to master nodes
 $obj_cluster->setOption(RedisCluster::OPT_SLAVE_FAILOVER, RedisCluster::FAILOVER_NONE);
 
@@ -76,24 +76,24 @@ $obj_cluster->setOption(
 $obj_cluster->setOption(
     RedisCluster::OPT_SLAVE_FAILOVER, RedisCluster::FAILOVER_DISTRIBUTE_SLAVES
 );
-~~~
+```
 
 ## Main command loop
 With the exception of commands that are directed to a specific node, each command executed via RedisCluster is processed through a command loop, where we make the request, handle any MOVED or ASK redirection, and repeat if necessary.  This continues until one of the following conditions is met:
 
-1.  We fail to communicate with *any* node that we are aware of, in which case a ~~~RedisClusterException~~~ is raised.
+1.  We fail to communicate with *any* node that we are aware of, in which case a `RedisClusterException` is raised.
 2.  We have been bounced around longer than the timeout which was set on construction.
-3.  Redis cluster returns to us a ~~~CLUSTERDOWN~~~ error, in which case a ~~~RedisClusterException~~~ is raised.
+3.  Redis cluster returns to us a `CLUSTERDOWN` error, in which case a `RedisClusterException` is raised.
 4.  We receive a valid response, in which case the data is returned to the caller.
 
 ## Transactions
 The RedisCluster class fully supports MULTI ... EXEC transactions, including commands such as MGET and MSET which operate on multiple keys.  There are considerations that must be taken into account here however.
 
-When you call ~~~RedisCluster->multi()~~~, the cluster is put into a MULTI state, but the MULTI command is not delivered to any nodes until a key is requested on that node.  In addition, calls to EXEC will always return an array (even in the event that a transaction to a given node failed), as the commands can be going to any number of nodes depending on what is called.
+When you call `RedisCluster->multi()`, the cluster is put into a MULTI state, but the MULTI command is not delivered to any nodes until a key is requested on that node.  In addition, calls to EXEC will always return an array (even in the event that a transaction to a given node failed), as the commands can be going to any number of nodes depending on what is called.
 
 Consider the following example:
 
-~~~php
+```php
 // Cluster is put into MULTI state locally
 $obj_cluster->multi();
 
@@ -108,7 +108,7 @@ $obj_cluster->get("myotherkey");
 // This will always return an array, even in the event of a failed transaction
 // on one of the nodes, in which case that element will be FALSE
 print_r($obj_cluster->exec());
-~~~
+```
 
 ## Pipelining
 The RedisCluster class does not support pipelining as there is no way to detect whether the keys still live where our map indicates that they do and would therefore be inherently unsafe.  It would be possible to implement this support as an option if there is demand for such a feature.
@@ -123,25 +123,25 @@ RedisCluster has specialized processing for MGET, MSET, DEL, and UNLINK which al
 
 *Note:  If you send keys that hash to more than one slot, these commands are no longer atomic.*
 
-~~~php
+```php
 // This will send two `MGET` commands.  One for `{hash1}` keys, and one for `otherkey`
 $obj_cluster->mget(["{hash1}key1","{hash1}key2","{hash1}key3","otherkey"]);
-~~~
+```
 
 This operation can also be done in MULTI mode transparently.
 
 ## Directed node commands
 There are a variety of commands which have to be directed at a specific node.  In the case of these commands, the caller can either pass a key (which will be hashed and used to direct our command), or an array with host:port.
 
-~~~php
+```php
 // This will be directed at the slot/node which would store "mykey"
 $obj_cluster->echo("mykey","Hello World!");
 
 // Here we're iterating all of our known masters, and delivering the command there
 foreach ($obj_cluster->_masters() as $arr_master) {
 	$obj_cluster->echo($arr_master, "Hello: " . implode(':', $arr_master));
 }
-~~~
+```
 
 In the case of all commands which need to be directed at a node, the calling convention is identical to the Redis call, except that they require an additional (first) argument in order to deliver the command.  Following is a list of each of these commands:
 
@@ -167,10 +167,10 @@ You can use the cluster functionality of phpredis to store PHP session informati
 
 To do this, you must configure your `session.save_handler` and `session.save_path` INI variables to give phpredis enough information to communicate with the cluster.
 
-~~~ini
+```ini
 session.save_handler = rediscluster
 session.save_path = "seed[]=host1:port1&seed[]=host2:port2&seed[]=hostN:portN&timeout=2&read_timeout=2&failover=error&persistent=1&auth=password&stream[verify_peer]=0"
-~~~
+```
 
 ### session.session_handler
 Set this variable to "rediscluster" to inform phpredis that this is a cluster instance.
@@ -179,7 +179,7 @@ Set this variable to "rediscluster" to inform phpredis that this is a cluster in
 The save path for cluster based session storage takes the form of a PHP GET request, and requires that you specify at least one `seed` node.  Other options you can specify are as follows:
 
 * _timeout (double)_:  The amount of time phpredis will wait when connecting or writing to the cluster.
-* _read_timeout (double)_: The amount of time phpredis will wait for a result from the cluster.
+* _read\_timeout (double)_: The amount of time phpredis will wait for a result from the cluster.
 * _persistent_: Tells phpredis whether persistent connections should be used.
 * _failover (string)_:  How phpredis should distribute session reads between master and slave nodes.
   * _none_ : phpredis will only communicate with master nodes
