resolved conflict merging pietern/bpop-timeout

[redis.git] / design-documents / REDIS-CLUSTER

diff --git a/design-documents/REDIS-CLUSTER b/design-documents/REDIS-CLUSTER
index 95aaddc1f1ec479531e436dd09f112385e0e2b91..28b95ae50e9a144be9b758180f4630e1e471e303 100644 (file)
--- a/design-documents/REDIS-CLUSTER
+++ b/design-documents/REDIS-CLUSTER
@@ -7,8 +7,8 @@ Overview
 ========
 
 Redis is a fast key-value store supporting complex aggregate data types as
-values. Values can be complex aggregate data types. For instance keys can be
-bound to lists with many elements, sets, sub-dictionaries (hashes) and so forth.
+values. For instance keys can be bound to lists with many elements, sets,
+sub-dictionaries (hashes) and so forth.
 
 While Redis is very fast, currently it lacks scalability in the form of ability
 to transparently run across different nodes. This is desirable mainly for the
@@ -55,10 +55,10 @@ and refusing any further query. The system administrator should check why
 M-1 nodes are offline and bring them back again if possible.
 
 Once resisting to big net splits is no longer a requirement as there is no
-conflict resolution stage, since at least an original node responsible to hold
-every possible key must be online for the cluster to work, there is also no need
-a design where every node can act as an independent entity receiving queries
-and forwarding this queries to other nodes as needed.
+conflict resolution stage, since at least an original node responsible of
+holding every possible key must be online for the cluster to work, there is
+also no need for a design where every node can act as an independent entity
+receiving queries and forwarding this queries to other nodes as needed.
 
 Instead a more decoupled approach can be used, in the form of a Redis Proxy
 node (or multiple Proxy nodes) that is contacted by clients, and