用 Redis 搭配树形结构来搞查找，感觉效率能上去不少吧？

用 Redis 搭配树形结构来搞查找，感觉效率能上去不少吧？这个想法其实挺靠谱的，因为 Redis 本身就是在内存里干活，速度飞快，而树形结构，比如咱们平时听说的多叉树、前缀树这些，本来就是专门为了快速查找设计的，它俩一结合,确实能在很多场景下把效率提上一个台阶。

先说说 Redis 自己，它不是一个普通的硬盘数据库，它主要把数据放在内存里（来源：Redis 官方介绍），这就意味着，它读写数据的速度，比那些要去硬盘里翻找的数据库快太多了，差不多是几百倍甚至更多的差距，单凭这一点，用 Redis 本身就能解决很多“慢”的问题，如果数据一多，关系一复杂，光是快还不够，还得找得“巧”，这时候,树形结构的思路就能帮上大忙了。

树形结构是啥呢？你可以把它想象成一个家族的家谱图，最上面是老祖宗，下面分出几个分支，每个分支又有后代，一层一层下去，这种结构有个很大的好处：找东西的时候，不用从第一个开始一个一个地硬找，比如你要找家族里一个叫“张三”的人，如果你知道他是“河北分支-李家庄支系-第五代”的，那你就可以直接从老祖宗找到河北分支，再找到李家庄，再看第五代，很快就能定位到他，不用把全家族几万人都问一遍，在计算机里，这种查找方法效率很高，尤其是数据量大的时候,优势更明显。

怎么用 Redis 来搭出这么一个“家谱树”呢？Redis 给了我们好几样好用的“积木”，比如哈希（Hash）、集合（Set）、有序集合（Sorted Set），我们可以用它们来拼出树的结构，举个例子，一个常见的办法是：用 Redis 的哈希结构来存每个树节点的具体信息，比如一个商品分类节点，哈希里可以存“分类ID”、“分类名称”、“父分类ID”这些字段，再用集合来存每个节点都有哪些子节点。“家电”这个父分类节点下，可能有“电视机”、“冰箱”、“洗衣机”这几个子分类，那我们就在一个叫“家电的子节点”的集合里，把电视机、冰箱、洗衣机的节点ID放进去，这样，树形关系就建立起来了（来源：常见 Redis 实践方案，如存储商品分类树）。

当树搭起来之后，查找起来就厉害了，你想找“某个大分类下所有的子分类，包括孙子、重孙子分类”，如果用传统的关系数据库，可能需要写复杂的递归 SQL 语句，一层一层查，数据量大或者层次深的时候，会很吃力，但在 Redis 这里，我们可以利用它高效的集合操作，我们可以从一个起点开始，把它所有的直接子节点找出来，然后再以这些子节点为新的起点，去找它们的子节点，像滚雪球一样，因为 Redis 的集合运算非常快，都是在内存里瞬间完成，所以即使树很深、分支很多，这个查找过程也能非常迅速，这就像你有了一个指挥棒，可以在庞大的家谱里沿着清晰的路径快速穿梭,而不是在迷宫里乱撞。

还有一种特别适合用 Redis 树形结构来优化的查找，前缀查找”或者“范围查找”，你有一个通讯录，里面存了成千上万个人的名字拼音缩写，你想快速找出所有“ZH”开头的人，这时候，你可以用一种叫“前缀树”（也叫字典树）的结构，用 Redis 来实现的话，可以用字符串（String）类型来存每个节点的信息，用节点的键名来体现路径，根节点是“Z”，它的一个子节点键是“Z:H”，再下一个是“Z:H:A”……这样，找“ZH”开头时，只需要定位到“Z:H”这个节点，然后把它下面所有的后代节点取出来就行了，速度极快（来源：技术博客中关于用 Redis 实现自动补全功能的案例），这比去所有数据里扫描匹配“ZH%”要高效得多。

也不是说这就完美无缺了，用 Redis 搞树形结构，你得自己设计键名，自己维护节点之间的关系，要增加一个节点，或者把一个节点从一棵树移到另一棵树下，你需要小心地同时更新好几个地方（比如父节点的子节点集合、新节点自身的哈希信息等），不然数据就对不上了，这要求咱们在写代码的时候考虑周全，保证这些操作是准确的，树如果特别大，特别深，全部放在内存里，对内存容量也是个考验，Redis 本身支持将不常用的数据淘汰掉，或者用集群来分摊数据,所以也有办法应对。

把 Redis 和树形结构的思路揉在一起，对于需要快速查找、特别是那种带层次关系、带前缀匹配的查找任务，效率提升是非常明显的，它相当于把树形查找的“最短路径”优势和 Redis 内存操作的“闪电速度”优势强强联合了，具体怎么搭、怎么用，还得看你的实际数据是啥样、要怎么查，但可以肯定的是，这确实是一个能让查找“飞起来”的好办法。