至少有3种不同的方式，每种方式各有利弊。
第一种方法是对树使用非原子性的临时扫描，以识别和使树的第二层（第一组自定义）无效（删除）。为此，请为您的Hash字段使用层级命名方案，然后使用遍历它们
HSCAN。例如，假设哈希的键名是产品的ID（例如ProductA），则将第一个自定义版本的第一个版本的字段名使用“
0001：0001”，将其第二个版本的字段使用“
0001：0002”，等等。同样，‘0002：0001’将是第二个自定义的第一个版本，以此类推…然后，确实找到所有自定义42的版本，使用
HSCANProductA 0 MATCH0042:*，
HDEL回复中的字段，并重复进行直到光标为零。
相反的方法是主动“索引”每个定制的版本，以便您可以高效地获取它们，而不用执行哈希的完整扫描。解决方法是使用Redis的集合-
您保留一个集合，其中包含给定产品版本的所有字段名称。版本可以是顺序的（例如在我的示例中），也可以是其他任何版本，只要它们是唯一的即可。维护这些索引的代价是-
每次添加或删除产品的自定义和/或版本时，都需要保持与这些集合的一致性。例如，创建版本将类似于：
HSET ProductA 0001:0001 "<customization 1 version 1 JSON payload"SADD ProductA:0001 0001
请注意，这两个操作应该在单个事务中（即使用
MULTIEXEC块或
evalLua脚本）。进行此设置后，使自定义设置无效仅是调用
SMEMBERS相关的Set并从Hash（以及Set本身）中删除其中的版本。不过，请务必注意，从大型Set读取所有成员可能很耗时-1K成员并没有那么糟糕，但是对于大型Set来说，则是
SSCAN。
最后，您可以考虑使用排序集而不是哈希。尽管在此用例中可能不太直观，但“排序集”将使您执行所需的所有操作。但是，使用它的代价是与Hash的O（1）相比，O（logN）用于添加/删除/读取的复杂性增加了，但是给定的数字并不明显。
要释放排序集的功能，您将使用字典顺序，因此所有排序集的成员都应具有相同的分数（例如，使用0）。就像哈希一样，每种产品都将以有序集表示。Set的成员与Hash字段的等效项，即自定义版本。“技巧”以一种允许您执行范围搜索（或如果可能的话，则为2级无效）的方式构造成员。这是一个看起来像的示例（请注意，这里的键ProductA不是哈希，而是排序集）：
ZADD ProductA 0 0001:0001:<JSON>
要读取自定义版本，请使用
ZRANGEBYLEX ProductA [0001:0001:[0001:0001:xff答复中的JSON并将其拆分，并使用删除整个自定义项
ZREMRANGEBYLEX。
