特征服务 QPS 优化方案

可视化演示

指标与瓶颈

开餐厅的第一步，不是急着炒菜，而是先盘清自己手里有几口锅、每道菜要炒多久。你站在后厨门口，看着厨师满头大汗却端不出菜，心里只有一个疑问：这一秒到底能出几道菜？这个“每秒出菜数”就是特征服务的 QPS——每秒能处理的请求数量，它是衡量服务产能最直接的标尺。

但 QPS 不是孤立数字，它由两个更底层的指标决定：并发请求数和平均响应时间。并发请求数是同一时刻同时在处理的请求有多少个，就像后厨同时开火的灶位；平均响应时间是从客人下单到菜端上桌的耗时。两者相除，就是出菜速率——流水线上同时有 C 道菜在做，每道菜花 T 秒，每秒就能流出 C÷T 道菜。

生产环境还要盯住 P99 延迟：把一万次请求的响应时间从小到大排列，排在第 99% 位置的那个值，就是 P99。它代表“最倒霉的 1% 客人要多等多久”，专门用来揪出尾部慢请求。瓶颈定位通常从这两个指标入手：QPS 上不去，要么是并发通道太窄，要么是单次响应太慢。当你发现并发已经很高但 QPS 仍低，多半是响应时间失控了。

所以，优化 QPS 之前要像店长盘点后厨一样，先算清并发数和平均响应时间：是灶台不够（并发低），还是做菜太慢（耗时高）？有了这两个数字，后面所有优化手段才有的放矢。

缓存加速

想提高出菜速度，最聪明的办法不是把每道菜都现洗现切，而是把天天有人点的菜提前做成半成品：卤好的牛肉、切好的葱姜、调好的酱汁，客人一点单，热一热就能上桌。这些“半成品库存”，就是特征服务里的缓存。

特征服务的缓存通常分两层：本地缓存和分布式缓存。本地缓存像后厨灶台边的小料盒，取用最快，但容量小、每台灶各自独立；分布式缓存像后门的大冷库，容量大、所有灶台共享，但多一次网络往返。生产系统常常两层都上：先翻小料盒，没有再去冷库，还不行才回源现做。

缓存对平均响应时间的影响可以精确量化：命中率越高，平均耗时越接近缓存耗时。但缓存不是白拿的——特征源更新后，缓存可能变馊。所以要有更新策略：设置过期时间（TTL）、主动失效、异步刷新。为了守住命中率，热点特征要重点保活，冷门特征不必长期占用空间。漫无目的地堆缓存，就像把整个菜单都做成半成品，库存爆炸还大量过期。

厨房的半成品库越丰富，客人等菜时间越短，QPS 自然水涨船高。但半成品也会过期变质，缓存必须配上更新策略，否则端出去的就是一盘馊菜。

请求合并

如果你点了宫保鸡丁，隔壁桌也点了宫保鸡丁，厨师会怎么做？当然是凑够一批一起下锅，一次颠勺出十份。这正是请求合并的思想：与其为一个请求单独跑一趟上游，不如把多个相同或相似的请求攒起来，一次性处理。

在特征服务里，大量请求会拿同一个特征（比如“用户城市”“商品分类”），或者同一批用户的不同特征。按一个时间窗口（比如 10 毫秒）收集请求，合并成批量请求向下游发送，这就是窗口聚合。更进一步，服务端可以主动把重复查询折叠成一次，让所有等待方共享同一份结果，这叫请求折叠——相当于几个桌一起点宫保鸡丁，后厨只炒一锅，各家分菜。

合并后的吞吐量可以用一个简洁式子表达：每秒能处理的请求数，约等于“每批能装几个请求 ÷ 每次上游调用耗时”。合并前 N 个请求要打 N 次上游，合并后只需 N 除以批大小那么多次。批越大，削掉的重复调用越多。但注意，合并不是无限的：窗口太长会让响应时间变长，批量太大可能撑爆上游，批大小和窗口时间必须按 P99 预算来调。

后厨的大锅饭策略看似简单，却立竿见影——菜还是那些菜，锅还是那口锅，只因为“一锅炒十份”，翻台率立刻上了一个台阶。

异步化改造

客人多的时候，聪明的服务员会先收下菜单、说声“马上好”，让客人安心落座等，而不是让所有人堵在柜台前干瞪眼。这个“先收单、后做菜”的思路，就是异步化。

同步处理时，每个请求线程全程占着一个灶台，菜没好之前火不能停。而异步化让请求线程发出任务后立刻释放，去接待下一批客人；真正做菜由后台任务完成，结果好了再通知客人。在特征服务里，异步通常体现为非阻塞 IO、Future 回调和消息队列。一个请求往往要查多个特征源（用户画像、商品信息、环境特征）：串行查询时耗时累加，并发发出、统一聚合，总耗时只取决于最慢的那个源。

异步化还要处理背压：下游处理不过来时，队列不能无限堆积，否则就像等位的客人把门口堵死。常见做法是限制队列长度、触发降级，宁可拒绝一小部分请求，也不能让系统崩溃。并发与串行的耗时差异，用数学表达就是下面的不等式。

异步化把“堵在柜台前等”变成“落座等菜”，灶位不再被空等浪费，同样的人手和灶台，翻台率却能翻好几倍。

资源与预热

餐厅每天开门前有一件必做的事：开火、热锅、烧油。如果等第一位客人点完菜才起火，第一桌客人要等上半小时。特征服务完全同理——刚启动时缓存是空的、连接是冷的，如果流量直接压上来，第一批请求会全部打到特征源上，延迟飙高、错误率上升。

因此，服务上线前要“热锅”：预先把热点特征灌入缓存、预先建立数据库和下游连接、预热线程池。这就是冷启动预热。它让服务在承接真实流量之前，已经把最耗时的准备工作做完。很多大厂在发布新版本时，会先让服务“空转”几分钟再切流量，原理就是如此。

线程池和连接池的规模则决定厨房能承受的火力。线程不是越多越好：开太多线程，CPU 忙着切换上下文反而变慢。工程上常用一个经验公式估算最优线程数：IO 占比越高，越应该多开线程去并行等待；CPU 密集型的计算，线程数接近核数就够了。连接池同理——池太小请求排队，池太大浪费资源，需要结合压测结果微调。

提前烧热的锅、备好的连接，让流量高峰到来时服务从容不迫。就像老练的餐厅开门迎客前一切就绪，客人涌入也依然行云流水。

熔断限流

生意火爆也可能成为灾难：客人源源不断涌进来，后厨迟早崩盘——灶台烧穿、盘子摔碎、厨师累倒。聪明的餐厅会在门口放一个取号机，满员就发号排队；如果某道菜的供应商突然断货，就先暂停这道菜，而不是让客人空等。这就是限流与熔断。

限流为服务划定一个最大速率：每秒最多放 N 个请求进后端，超出的请求要么排队，要么直接返回“稍后再试”。常见算法有令牌桶和滑动窗口。熔断则是在下游持续异常时主动断开：当错误率超过阈值，后续请求不再打向下游，而是快速返回兜底结果——默认值、缓存副本、降级文案——给下游喘息恢复的时间。

令牌桶的限流能力可以这样理解：一个桶以固定速率补充令牌，请求进来必须取走一个令牌才能放行。桶里攒下的令牌允许短时间应付流量尖峰，但长期平均速率仍被补充速率锁死。这就像取号机：平时客流平稳，攒一批号可以集中放行，但总的接待能力是固定的，队伍不会无限放进来。

取号机不是赶客，而是保护厨房不超载；熔断不是没菜吃，而是把有限资源留给真正能上桌的菜。稳定，才是高 QPS 的前提。

监控压测

一家成熟的餐厅，后厨墙上一定挂着数据看板：今日翻台率、每道菜出餐用时、食材消耗速度、差评关键词。店长每天的功课就是看数据、复盘、调菜单。特征服务的 QPS 优化同样是一场需要数据支撑的持久战，没有监控的优化等于蒙眼开车。

核心监控指标包括：QPS、平均响应时间、P99、错误率、缓存命中率、线程池活跃数、队列长度、下游依赖耗时。这些指标要能按服务、接口、特征维度拆分，才能定位到底是哪台灶、哪道菜拖了后腿。压测则是把问题提前暴露的手段：在灰度环境用模拟流量逐步加压，直到指标恶化，摸出单实例的真实上限。

有了单实例上限，容量规划就变成一道算术题：目标流量除以单实例能力，再乘上冗余系数。比如业务目标 10 万 QPS，单实例实测能扛 5000，留 50% 冗余，大约需要 30 个实例。压测还能帮我们揪出“纸面达标、尾部爆炸”的隐患——平均延迟很漂亮，P99 却已经超时。

数据看板让店长心里有数，压测演习让每个岗位知道自己的极限。只有持续监控、定期压测、复盘调优，餐厅才能在客流高峰中稳稳接住每一单。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""特征服务 QPS 优化模拟器：对比缓存与批量合并的吞吐提升"""import timeimport randomfrom collections import deque  class FeatureService:    """模拟一个带缓存和批量合并的特征服务"""     def __init__(self, latency=0.002):        self.cache = {}        self.hit_count = 0        self.total_count = 0        self.latency = latency        self.batch_queue = deque()     def query_with_cache(self, key):        """缓存优先的单个特征查询"""        self.total_count += 1        if key in self.cache:            self.hit_count += 1            return self.cache[key]        time.sleep(self.latency)        value = random.randint(1, 100000)        self.cache[key] = value        return value     def query_batch(self, keys):        """批量合并查询：未命中特征只回源一次"""        result = {}        miss_keys = [k for k in keys if k not in self.cache]        for k in keys:            self.total_count += 1            if k in self.cache:                self.hit_count += 1                result[k] = self.cache[k]        if miss_keys:            time.sleep(self.latency)            for k in miss_keys:                value = random.randint(1, 100000)                self.cache[k] = value                result[k] = value        return result  def run_single(total=60):    svc = FeatureService(latency=0.002)    start = time.time()    for i in range(total):        svc.query_with_cache("user_%d" % (i % 20))    elapsed = time.time() - start    hit_rate = svc.hit_count / svc.total_count    print("单请求模式: QPS=%.0f 命中率=%.1f%%" % (total / elapsed, hit_rate * 100))  def run_batch(total=60, size=10):    svc = FeatureService(latency=0.002)    keys = ["user_%d" % (i % 20) for i in range(total)]    start = time.time()    for i in range(0, len(keys), size):        svc.query_batch(keys[i:i + size])    elapsed = time.time() - start    hit_rate = svc.hit_count / svc.total_count    print("批量合并模式: QPS=%.0f 命中率=%.1f%%" % (total / elapsed, hit_rate * 100))  if __name__ == "__main__":    run_single()    run_batch()

1. self.cache = {}用字典充当半成品库：key 是特征名，value 是算好的特征值。
2. if key in self.cache:翻小料盒：命中直接返回，不回源。
3. time.sleep(self.latency)模拟每次回源特征计算的耗时。
4. miss_keys = [k for k in keys if k not in self.cache]批量模式先筛出没命中的 key。
5. if miss_keys: time.sleep(self.latency)关键优化：一批缺失特征只回源一次，而不是每个都回源。
6. run_single()单请求模式：每个请求独立走一遍“查缓存→miss→回源”的流程。
7. run_batch()批量模式：攒满一批再查询，miss 特征合并回源，QPS 大幅提升。

常见误区

面试题