高效find skill实现方案：从算法优化到工程实践

1次阅读

没有评论

共计 2036 个字符，预计需要花费 6 分钟才能阅读完成。

在用户量突破千万级、日活百万的业务场景中，我们发现传统 find skill 实现存在三大致命伤：

查询延迟飙升：当数据量超过 MySQL 单表 2000 万行时，即使有基础索引，模糊查询响应时间仍从 200ms 劣化到 2s+，直接导致接口超时
数据库不堪重负 ：一个简单的LIKE '%keyword%' 查询可能触发全表扫描，某次运营活动期间单个 find skill 接口就占用了 80% 的数据库 CPU
维护成本激增：业务规则变更需要修改数十处 SQL 语句，缺乏统一处理逻辑

我们对比了三种主流方案：

纯内存缓存方案
优点：Redis 查询仅需 1ms，吞吐量可达 10w QPS
缺点：缓存穿透风险，且无法支持复杂条件组合查询
数据库优化方案
优点：利用 Elasticsearch 的倒排索引，关键词查询性能提升 100 倍
缺点：数据同步延迟可能导致短期不一致
混合架构方案
最终选择：多级缓存 + 智能索引 + 异步处理的组合拳
决策依据：在保证 99.9% 查询 <50ms 的同时，支持每小时千万级数据更新

采用 Guava Cache + Redis + Elasticsearch 三级存储：

// 伪代码展示多级缓存查询流程
public Skill findSkill(String keyword) {
    // 第一层：本地缓存（命中率约 60%）Skill result = localCache.getIfPresent(keyword);
    if (result != null) return result;

    // 第二层：分布式缓存（命中率约 35%）result = redisTemplate.opsForValue().get(buildCacheKey(keyword));
    if (result != null) {localCache.put(keyword, result); // 回填本地缓存
        return result;
    }

    // 第三层：索引存储（剩余 5% 请求）result = elasticsearchClient.search(buildQuery(keyword));
    if (result != null) {
        // 异步更新缓存
        cacheUpdateQueue.add(() -> {redisTemplate.opsForValue().set(buildCacheKey(keyword), result, 5, MINUTES);
        });
    }
    return result;
}

针对不同查询模式建立专用索引：

倒排索引：处理关键词搜索

# Elasticsearch 映射示例
{
  "mappings": {
    "properties": {"skill_name": { "type": "text", "analyzer": "ik_max_word"},
      "tag": {"type": "keyword"}
    }
  }
}

位图索引：处理多条件组合筛选

/* PostgreSQL 示例 */
CREATE INDEX idx_skill_tags_bitmap ON skills 
USING BITMAP(tags);

通过消息队列实现三个解耦：

数据变更 => 索引更新
缓存回填
日志收集

// Spring 事件驱动示例
@EventListener
public void handleSkillUpdateEvent(SkillUpdateEvent event) {
    // 异步更新索引
    rabbitTemplate.convertAndSend("index.queue", 
        new IndexMessage(event.getSkillId(), "UPDATE"));

    // 异步清理缓存
    redisCacheEvictor.evict(event.getSkillId());
}

压测环境：8 核 16G 服务器 × 3，数据量 5 亿条