您是正确的，Redis仅提供简单的数据结构，并且它们不能由值组成（就像您可以使用面向文档的数据库（例如CouchDB或MongoDB）那样。但是，可以通过引用来构成数据结构，这是非常常见的模式。
例如，集合中包含的项目可以是其他对象（列表，哈希表，其他集合等）的键。让我们尝试将其应用于您的示例。
要对客户和设备+端口之间的关系进行建模，可以使用包含客户ID的集合。为了存储有关客户的信息，每个客户一个哈希表就可以了。
以下是客户：
hmset c:1 name Smith protocol tcp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2hmset c:2 name Jackson protocol udp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2hmset c:3 name Davis protocol tcp snmp_dest 127.0.0.3 syslog_dest 127.0.0.4
这些记录的键是c：ID
让我们将其中两个与设备和端口关联：
sadd d:Los_Angeles:11 2 3
该集合的密钥是d：device：port。c：和d：前缀只是一个约定。每个设备/端口应创建一组。给定的客户可能属于多个集合（因此与多个设备/端口关联）。
现在，要查找具有附加到此设备/端口的交付方式的客户，我们只需要检索设备的内容即可。
smembers d:Los_Angeles:111) "2"2) "3"
然后可以通过管道传递多个hgetall命令来检索相应的客户信息：
hgetall c:2hgetall c:31) "name"2) "Jackson"3) "protocol"4) "udp"5) "snmp_dest"6) "127.0.0.1"7) "syslog_dest"8) "127.0.0.2"1) "name"2) "Davis"3) "protocol"4) "tcp"5) "snmp_dest"6) "127.0.0.3"7) "syslog_dest"8) "127.0.0.4"
不要担心命令的数量。它们非常快，并且大多数Redis客户端都具有对查询进行管线化的功能，因此仅需要最少的往返次数。通过仅使用一个成员和几个hgetall，只需两次往返即可解决该问题。
现在，由于普遍存在的SORT命令，可以进一步优化。这可能是Redis中最复杂的命令，可用于在此处保存往返。
sort d:Los_Angeles:11 by nosort get c:*->name get c:*->protocol get c:*->snmp_dest get c:*->syslog_dest1) "Jackson"2) "udp"3) "127.0.0.1"4) "127.0.0.2"5) "Davis"6) "tcp"7) "127.0.0.3"8) "127.0.0.4"
在一个命令中，它检索设备/端口集的内容并获取相应的客户信息。
这个例子很简单，但是更普遍的是，尽管您可以使用Redis表示复杂的数据结构，但这并不是立即的。您需要在结构和数据访问方面仔细考虑模型（例如，在设计时，坚持使用数据
和 用例）。
