转转搜推排序服务的响应对象序列化优化

• 1 优化背景

• 2 问题分析

• 3 设计方案

• 3.1 优化方案一

• 3.2 优化方案二

• 3.2 优化方案三

• 4 总结

1 优化背景

为了提升搜索推荐系统的整体工程效率和服务质量，搜索推荐工程团队对系统架构进行了调整。将原本的单一服务架构拆分为多个专门化的独立模块，分别为中控服务、召回服务和排序服务。

在新的架构中，中控服务负责统筹协调请求的分发和流量控制，召回服务用于搜索意图和用户行为分析并计算返回搜索推荐候选商品集合，而排序服务则进一步对这些候选商品进行精排序，以达到更好的最终展示结果的相关性、点击率、转化率等目标。

在推荐系统接入新的排序服务过程中，发现与原有逻辑相比，微详情页场景的响应时间显著增加了大约10毫秒，主要问题出现在接口请求和响应的环节上。

同样，搜索系统在接入排序服务时也遇到了类似的情况。与原有逻辑相比，响应时间增加了近20毫秒，导致无法达到上线的性能标准。

例如，搜索排序服务在本地执行时的时间为60毫秒，但通过远程调用时，执行时间却增加到接近80毫秒，两者之间的差异接近20毫秒。

为了解决这些性能问题，需要对这些延迟的原因进行深入分析和优化。

2 问题分析

问题现象是调用方等待耗时和服务方执行耗时相差较大，所以问题主要出现在远程调用过程，接下来就是分析这个过程

远程调用可以理解为一种实现远程代码与本地接口调用相一致体验的开发模式

远程调用一般通过动态代理实现，通过调用动态方法将调用方法标识和调用参数序列化为字节码，再通过通信协议请求服务端

服务端解析方法标识和反序列化参数字节码到实体参数对象，再反射的方式调用方法标识对应的方法

该方法返回结果（即响应对象）序列化，并返回给调用方，调用房完成反序列化响应对象，返回给代理调用者

整个过程较为耗时的部分为序列化/反序列化、网络IO、本地调用，一般为ms级别。

调用动态方法和反射耗时相对不高，一般为us级别。如下图所示。

调用动态方法耗时相比于其他过程一般可忽略不计，服务端本地调用逻辑与原服务已经对齐，也不在本次考虑之内。

接下来就是要分析序列化和网络IO请求开销在各环节的占比。选择skynet来定位序列化和网络环节的耗时

skynet是公司架构组提供的分布式链路追踪工具，通过链路中携带的上下文，可以记录经过的服务接口的日志信息

skynet的基本概念是一次完整请求链路称为trace，一次远程调用过程称为span

以推荐微详情页某次请求为例，查询单次请求的调用过程，可以看到下图所示，排序服务调用过程中的远程耗时与本地耗时差值约为 4ms

通过span携带的日志，可以看到以下数据

可见，耗时问题主要集中在响应过程阶段。如果要计算远程耗时与本地耗时的差异为20毫秒的开销情况，可以结合上述日志数据进行线性计算和整理，得出各个过程的近似耗时及其占比，如下图所示。

搜索与推荐的区别在于，搜索的请求阶段不传输特征，因此响应过程的耗时占比更高。因此，需要优先考虑减少响应过程的耗时。

在整个响应过程中，序列化和网络 I/O 的耗时各占一半。影响 I/O 耗时的因素之一是网络环境和机器配置，另一个因素是序列化后对象的长度。

通过与运维团队沟通，我们了解到部分机器使用的是千兆网卡，而我们传输的对象长度通常都在 MB 级别，这对耗时有一定的影响。

网络问题可以统一整理后提交给运维团队调整机器配置来解决，而我们的主要精力应放在优化序列化过程上。

接下来是对响应对象的序列化过程分析

首先需要了解响应对象数据结构，响应对象是一个泛型类，以支持不同类型的ID，如下所示，包括：

• 状态值，判断结果正常或异常
• RankResult对象
• 主要存储约500长度的RankResultItem列表，每个Item对象需要返回商品ID，并以Map的形式返回模型日志、模型打分结果及部分特征
• 请求携带的其他信息，如A/B测试实际命中分组名的集合等等
• 异常日志

如以下代码所示

class RankResponse<T> {
    int status;
    RankResult<T> result;
    String errorMsg;
}
 
class RankResult<T> {
    List<RankResultItem<T>> items;
    Map<String, Object> others;
}
 
class RankResultItem<T> {
    T id;
    Map<String, Object> features; // 回传特征
    Map<String, String> metric;     // 模型日志
    Map<String, Double> results;  // 模型结果
}

优化前，搜索排序服务采用了架构组提供的 SCFV4 序列化方法。

SCFV4 是一种最终输出字节码的序列化方式，它会对所有被 @SCFSerializable 注解标注的业务数据传输对象预编译序列化和反序列化方法。对于 Java 的基础类（如 List、Map 等）和基本类型（如 Integer 等），SCFV4 也预设了相应的序列化和反序列化方法。

在序列化执行时，SCFV4 根据对象的数据结构层次逐层遍历，调用每个子成员对象的序列化方法，最终输出字节码。反序列化的过程与之类似。

SCFV4 序列化的特点如下：

• 与 JSON 相比，反序列化后的类型较为安全，但不能完全保证类型一致性。例如，不论输入的 Map 是何种类型，反序列化后都会变为 HashMap。
• 对泛型类型和基本类型的序列化过程进行了优化，对于数据大小在 KB 级别的对象，性能表现良好。
• 作为一种与SCF框架紧密集成的序列化方法，能够与框架中的其他模块无缝协作，从而简化开发流程，减少开发者的工作量。
• 在代码编写时，需要通过注解的方式对序列化对象类进行预设定，版本只能向后兼容。
• 有时存在异常处理不够友好的问题，异常信息无法直接反映业务代码中的问题，定位序列化问题时，往往需要依赖经验进行判断。

下面回到排序响应对象，分析响应对象的序列化过程，将过程梳理到下图：

可以看到，一次序列化过程可能需要对多达 500 次的商品日志 Map、商品得分 Map 和商品 ID 进行序列化。

由于日志对象的数据规模远大于其他类型的对象，因此我们可以假设，序列化的主要开销来自于序列化特征日志 Map 的耗时。

在相关的 MapSerializer 类中可以发现，序列化 Map 时不仅需要解析 Key-Value 的数据类型，还大量调用了 String.getBytes() 方法。

假设特征日志的总长度约为 1MB，在本地测试中，getBytes 方法的耗时大约为 10 毫秒，这与我们的预期一致。因此，我们的优化思路应重点放在优化特征日志的序列化过程中。

3 设计方案

3.1 优化方案一

首先想到的优化方案是通过不传输日志来完全节省日志的序列化时间。针对这一思路，有两种具体的实现方式：

• 在排序服务中直接打印日志，并由排序服务直接将日志上报到 Kafka。
• 使用 Redis 缓存日志，从而减少序列化和传输的开销。

如果直接打印日志，每个请求最多需要打印 1000 条日志。经过与数据团队的讨论，我们得出了以下结论：

• 数据采集：直接打印日志将导致每天的日志量达到约 15TB。以 15 台机器的集群计算，每分钟需要采集 1GB 的数据，这会给日志采集系统和我们的服务 I/O 带来巨大压力。
• 数据存储：每天新增的数据量将达到 50-60TB。由于每天生成的 15TB 数据需要先采集再清洗，这样就会产生两份数据。每份数据有 3 个副本，总共是 6 份数据。最终在 Hadoop 集群中还会有 2 份备份，约 45TB。即使使用 Hive 表和 Parquet+GZ 格式压缩，数据量也大约在 5-10TB 之间。

经过分析，我们认为改用直接打印日志的方案并不是最优选择，因此没有实施。

如果将日志异步写入Redis，并在重排序时从Redis中读取，就能有效地优化性能。通过设置日志缓存的过期时间为 1 秒，可以满足排序到重排序之间的时间间隔要求。

在这种情况下，Redis的预估使用量为：每请求日志大小 × QPS × 过期时间 = 2MB × 500 × 1秒 = 1GB。

由于成本相对可控，因此我们决定尝试这一方法。

如上图所示，本次方案的目标是将红色部分的输入特征日志处理逻辑提前到模型输入特征处理之后，并引入 Redis 缓存逻辑，同时实现异步执行。

然而，这里遇到了一个挑战：输入特征集合是由预测框架生成的，其生成时间点只有框架内部知道。因此，日志处理过程必须在预测框架内部执行。

在深入讨论之前，先介绍一下预测框架和排序框架之间的关系。预测框架的主要职责是管理和执行算法模型，它生成模型所需的输入特征，并基于这些特征进行预测。排序框架则利用预测框架的输出，对商品或内容进行排序，以优化最终展示给用户的结果。

虽然预测框架和排序框架在功能上是相互独立的，但它们之间密切合作。排序框架依赖预测框架提供的预测结果，而预测框架则处理来自排序框架的输入特征。然而，预测框架的主要任务是执行算法模型，与具体的业务逻辑无关。因此，在预测框架中引入排序框架的业务逻辑会导致相互依赖，这违背了各自的设计初衷，也不利于系统的可维护性和扩展性。

因此，我们需要一种方式来解耦两者，实现日志处理逻辑的同时，不破坏架构设计。

如果在预测框架内部执行日志处理，就需要将排序商品列表、排序上下文、日志处理插件、线程池、Redis 客户端对象、过期时间配置等所有组件都传递到预测框架中。这将导致排序框架与预测框架的相互依赖，而这种双向依赖是不合理的，因为预测框架不仅服务于排序框架，还用于通用推荐和定价框架。

为了解决这个问题，我们可以通过传递 Consumer 对象来实现解耦。预测框架作为模型输入特征的生产者，排序框架作为消费者。具体来说，排序框架可以实现一个指定日志处理逻辑的 Consumer 接口。当预测框架生成输入特征集合后，调用 accept 方法来完成日志处理。

为了便于异步处理，我们在排序框架中定义了一个 IFutureConsumer 接口，该接口支持获取 Future 方法，用于在排序框架中等待日志处理完成。同时，预测框架接收到的仍然是一个标准的 Consumer 接口对象。

这种方法确保了预测框架和排序框架之间的解耦，明确了各自的职责，避免了双向依赖，使系统更加灵活和可扩展。

interface IFutureConsumer<T> extend Consumer<T> {
    // accpet(T t)
 
    Future<?> getFuture();
}

预测框架生成输入特征并传递给排序框架

// 预测框架生成输入特征
T inputFeatures = ...;

// 调用排序框架的日志处理逻辑
IFutureConsumer<T> consumer = ...; // 由排序框架提供
consumer.accept(inputFeatures);

排序框架处理日志

public class HandleLogConsumer<T> implements IFutureConsumer<T> {
    private Future<?> future;

    @Override
    public void accept(T t) {
        // 异步处理日志逻辑
        this.future = executorService.submit(() -> {
            // 处理日志逻辑
        });
    }

    @Override
    public Future<?> getFuture() {
        return this.future;
    }
}

整个过程如下图所示

另外本方案使用了Redis的哈希（hash）数据结构进行存储，原因是在搜索服务中，每次请求都需要刷新结果缓存，这也意味着需要同时刷新相关的日志缓存。然而，搜索服务并不知道具体有哪些 infoid 已经被存储，如果使用字符串（string）结构来存储这些日志数据，很难做到全量刷新，因为无法有效地管理和定位所有存储的键值对。

相比之下，使用哈希（hash）结构存储日志信息有明显的优势。我们可以使用 ctr、cvr、info 等作为哈希表的关键字前缀，并以请求的 MD5 值作为后缀。这种方式只需要刷新 2～3 个哈希键（key），就可以覆盖所有相关的日志数据。这种方法不仅简化了缓存刷新操作，而且更高效，因为只需操作少量的哈希键即可完成全量刷新，适合搜索服务的需求。

推荐侧在找靓机微详情页场景先行接入了此方案，额外耗时由14ms优化至4ms

但随后发现了两个问题：

随着首页推荐等主要场景的接入，后处理过程中获取日志过程耗时达到了7ms以上，原因是写qps较高（单redis-server节点近7w qps），日志数据又属于bigkey（1k以上），redis-server极易发生阻塞，扩容后仍在3ms左右水平 搜索测试耗时并未明显下降，读取和刷缓存过期时间也带来了额外的成本。

总结

• 此方案是对Redis性能过于乐观，在处理高qps + bigkey的场景性能无法满足要求，后续需要经常关注单点qps并评估扩容，维护成本也高
• 业务过多的感知框架实现逻辑，有些操作甚至需要业务干预，如手动刷新过期时间等，接入过程体验不够友好，负担过重

3.2 优化方案二

在本地打印日志和缓存日志的方案不可行后，我们只能重新考虑通过响应对象将日志数据传回调用方的方案。以下是几种可行的思路：

• 本地缓存日志数据：将日志数据暂时缓存到本地，等待重排序完成后，再请求同一台机器取出所需的日志数据。

• 分步返回数据：先返回排序后的模型得分部分，再异步返回日志数据部分。

• 日志异步转换和压缩：在预测阶段，将日志数据异步转换为字节数组并进行压缩，序列化时直接返回这些字节数据。在整个搜索推荐流程完成后，再将要下发的topN商品的日志数据解压并转换回字符串。

经过评估，前两种方案虽然具有一定的可行性，但需要调用方进行较多的开发支持，实施周期较长。此外，这些方案还需考虑更复杂的容灾处理设计，例如应对因重启或超时导致的日志丢失，以及缓存引起的 GC 问题。为了规避这些风险，我们决定尝试第三种方案。

为了能实现仅在需要时，即取商品列表topN并打印后端日志时，才将日志从bytes转回String，在响应RankResultItem增加了LazyMetric数据类型，利用延迟加载机制，减少了不必要的数据处理和传输开销，数据结构如下：

class RankResultItem {
    Map<String, LazyMetric> lazyMetricMap;
}
 
class LazyMetric {
    byte[] data; // 编码后的字符串数据
    byte compressMethodCode; // 压缩类型
 
    LazyMetric(String str){
        // string2bytes
    }
  
    String toString() {
        // bytes2string
    }
}

日志生产及获取过程调整为：

可以看出，String 转 bytes 的编码过程耗时已经在模型执行时并行处理中被优化掉了。在从模型预测模块到 topN 节点的整个执行过程中，系统始终携带的是 bytes 类型的数据。只有在 topN 节点完成了所有搜索推荐流程需要准备返回商品时，才会主动调用 toString 方法将 bytes 转回 String，而其他商品的日志数据则会被直接丢弃。这样一来，decode 的次数从 500 次减少到了 10 次（假设 N 一般为 10）。整个过程对业务侧的集成并不复杂，开启功能后，排序框架就会自动将日志数据转存到 LazyMetricMap 中。中控服务随后可以从每个 Item 的 LazyMetricMap 中取出 LazyMetric 对象，并在合适的时机调用 toString 方法，提升搜索推荐业务整体开发效率。压缩过程选择了java自带的gzip和zlib两种方法进行测试，测试结果如下：

可以看到，在不同的序列化方法下，序列化耗时都有所减少，性能最高提升至原来的 35%，序列化后的数据量也减少到原来的 36%，这也预示着网络 I/O 的开销会有所下降。

接入情况：

• 推荐系统：在转转首页推荐场景中接入后，与原 Redis 方案相比，性能没有显著提升，但减少了 Redis 中间存储环节，从而降低了特征数据丢失的风险。
• 搜索系统：在接入并进行压测后，虽然整体耗时有所减少，但仍然存在大约 13 毫秒的额外耗时（71ms 对比 58ms），尚未完全解决性能问题。

总结：

• 尽管方案在性能上有所提升，但这仅是对原有序列化框架的修补，核心问题在于 SCF 序列化对特定对象的执行效率仍然不高，因此问题并未彻底解决。初步分析表明，可能的原因在于 Map 的序列化过程本身依然较为耗时，并且在反序列化时，需要为 LazyMetric 的字节数组（搜索约 1500 个，推荐约 800 个）分配大量碎片化的内存空间，这导致了额外的耗时。

3.2 优化方案三

根据对 V2 方案的总结，V3 方案的设计原则是：放弃使用 SCF 的通用对象序列化，RPC 层仅通过字节数组进行交互，而排序框架采用自定义的序列化方法。

思路一：继续尝试接入现有的开源序列化框架，并在此基础上对排序响应对象进行定制化开发。常见的开源项目包括 protobuf、Kryo、Hessian 等。

思路二：自行开发专门适用于排序响应对象的序列化方法。

思路一的优势在于安全性、通用性和高性能方面都表现良好，部分框架也提供一定的定制化能力。然而，这类框架通常为了适应多种业务场景，会包含大量通用代码和复杂逻辑。以 Kryo 为例，其项目代码行数超过 2 万行，这使得短期内很难掌握所有细节，一旦出现问题可能会阻碍开发进度，并且不一定能按期解决序列化问题。不过，开源框架技术成熟，适合作为长期方案。

思路二的优势在于既可以借鉴其他框架的优化策略，又可以低成本地针对特定对象进行定制优化，从而实现更高的序列化效率。虽然在安全性方面，需要通过单元测试来保障，但开发一个针对特定应用场景的序列化方法相对简单。考虑到排序框架接口的参数对象不经常更改，这种方法可以做到一次开发、长期受益。因此，我们倾向于选择思路二。

整理思路后，序列化开发可以按照以下步骤进行：

定义字节数组的序列化数据结构

• 确定如何将对象数据映射到字节数组的格式中，包括字段的顺序、类型，以及如何处理可变长度数据。

定义序列化接口并实现具体的序列化类：

• 创建一个通用的序列化接口，用于定义序列化和反序列化的方法。
• 为每个需要序列化的对象类型实现具体的序列化类，确保符合接口的要求。

定义序列化过程的数据缓冲类：

• 开发一个用于在序列化和反序列化过程中暂存数据的缓冲类，以便有效管理字节数组的读写操作。

实现各对象的具体序列化方法：

• 为每个对象类型实现具体的序列化和反序列化方法，将对象数据转换为字节数组或从字节数组重构对象。

序列化结果最终要存储在字节数组（byte[]）中，因此定义如何存储是我们的首要任务。

一个排序对象包含许多内容。为了简化存储过程并便于编写代码，我们采用了一种类似树状的存储结构，与其他序列化方式大致相同。这种结构将排序对象的整体作为根节点，然后按照对象的层次结构逐级展开存储。

与其他序列化方式不同的是，我们考虑到排序过程中对所有商品都会执行相同的操作，因此商品类的特征 Map、结果 Map 和日志 Map 的存储键集合在实际应用中是保持一致的。由于这些键是可以复用的，我们将其提取出来并统一存储在 items_common 中。这样一来，Map 的值可以按照固定的顺序进行链式存储，这种方法不仅节省了空间，还提升了存储效率。

为了进一步降低代码复杂度，还需要定义统一的接口，再将各个成员序列化过程分解到多个具体实现类中

自定义序列化方法接口定义如下：

public interface IRankObjSerializer<T> {
 
    int estimateUsage(T obj, RankObjSerializeContext context);
 
    void serialize(T obj, RankObjSerializeContext context) throws Exception;
 
    T deserialize(RankObjDeserializeContext context) throws Exception;
}

方法的含义如下：

estimateUsage：快速评估序列化对象的长度。

• 在序列化过程中，如果字节数组的容量不足，就需要创建一个新数组，其大小为当前大小的两倍，并复制已有数据。这一过程需要进行 log(最终大小) - log(初始大小) 次扩容操作。estimateUsage 方法通过快速评估一个稍大于或接近最终大小的初始容量，来减少扩容次数，提高效率。

serialize：用于序列化对象。

• 序列化过程中，context 包含一个 Output 对象，用于处理字节数据的输出，同时还包括 metricMap、resultMap 等公共的 keySet，这些 keySet 用于统一管理序列化过程中的键集合。

deserialize：用于反序列化对象。

• 反序列化过程中，context 包含一个 Input 对象，用于处理字节数据的输入，此外，还包括 metricMap、resultMap 等公共的 keySet，以确保反序列化时使用的键集合与序列化时一致。

通过这些方法，可以更有效地管理对象的序列化和反序列化过程，提升整体性能和资源利用率。

根据响应对象的数据层次，序列化过程需要针对不同的类型进行拆解，并为每种具体类型设计相应的序列化类。以下是各类序列化器的设计：

GeneralObjSerializer：

• 负责序列化和反序列化 Java 的基本数据类型（如 int、float、double 等）以及字符串 (String) 类型。
• 提供方法将基本数据类型和字符串转换为字节数组，并在反序列化时将字节数组转换回相应的基本类型或字符串。

GeneralMapSerializer（用于基本 Map 类型，按顺序存储键值对）：

• 负责序列化和反序列化 Map 对象。该类按特定顺序存储 Map 的键值对（key-value），确保在反序列化时可以恢复 Map 的原始状态。
• 支持常见的 Map 实现（如 HashMap、TreeMap 等），并处理可能的空键或空值。

GeneralListSerializer（

• 负责序列化和反序列化 List 对象，能够将 List 转换为字节数组，并在反序列化时恢复 List 的原始结构和内容。
• 适用于各种 List 实现（如 ArrayList、LinkedList 等），并处理列表中的空元素。

GeneralSetSerializer：

• 负责序列化和反序列化 Set 对象，将 Set 中的元素序列化为字节数组并按序恢复。
• 支持常见的 Set 实现（如 HashSet、TreeSet 等），并确保在反序列化后保持 Set 的无序性和唯一性。

RankResultSerializer：

• 负责序列化和反序列化 RankResult 对象，处理与排序结果相关的数据结构和字段。
• 该类将 RankResult 的复杂对象和嵌套结构序列化为字节数组，并在反序列化时重构完整的 RankResult 对象。

RankResultItemSerializer：

• 专门用于序列化和反序列化 RankResultItem 对象，处理单个排序结果项的序列化。
• 负责将每个 RankResultItem 的各个字段（包括特征、结果和日志等）转换为字节数组，并在反序列化时恢复其内容和结构。

RankResponseSerializer：

• 用于序列化和反序列化 RankResponse 对象，管理整个排序响应的序列化过程。
• 该类负责将完整的响应数据，包括所有 RankResultItem，序列化为字节数组，并在反序列化时重建整个 RankResponse 对象。

序列化过程中依次将写入到一段足够长的byte数组里，序列化完成时再一次性读出所有写入数据，定义Output类作为序列化过程中的数据缓冲（同样有Input类作用于反序列化，实现类似）

class Output {
    byte[] data;
    int offset;
 
    Output(int estimateUsage) {
        data = new byte[estimateUsage];
        offset = 0;
    }
     
 
    void writeInt(int);
    void writeLong(long);
    void writeFloat(float);
    void writeBytes(byte[]);
    ...
}

data：作为序列化数据的缓冲区，为了写入效率最高，缓冲区是连续且足够长的byte数组，足够长由入参estimateUsage来保证

offset：是下一个要写入数据的位置，如果offset >= 数组长度，则需要扩容，扩容每次按两倍扩容

estimateUsage的准确性影响了扩容次数，进而影响序列化效率，经测试从以32为起始容量初始化并逐渐扩容到所需容量与直接使用estimateUsage初始化，序列化耗时相差20%左右

writeInt、writeLong：整型和长整型的写入是可变长的，虽然int和long分别使用了32bit和64bit的空间，但如1、2、8、64等较小的数字只是用了前8bit的空间，一般可变长序列化采取的做法是将每8bit为一组，低7位存储真实数据，高位存储标识符，表明更高位是否仍存在更多数据，可变长编码下整型需要1～5byte，长整型则需要1～10byte，存储数字值越小时，可变长的压缩效果越好。读取时再从低位依次向高位读取，直到标识符表明数据读取完毕，当缓冲区剩余长度不足可变长的最大长度时，需要调用readInt_slow或readLong_slow方法，逐个byte读取并判断是否越界

writeFloat、writeDouble：这两种类型不能直接写入，需要调用Float.floatToRawIntBits和Double.doubleToRawLongBits转为Integer型和Long型。我们的特征由于特征默认值等原因存在大量0.0、-1.0、1.0等数值，但在可变长存储下，转int后实际占用位数很长，优化方式是转换前先判断了它是否为整型数字，如是整型就取整后直接存为整型，可将原本需要5～10位的存储空间节省到1位，一个较为快速的判断方式为：

void checkDoubleIsIntegerValue(double d) {
    return ((long)d == d);
}

多数序列化实现按待序列化的各个成员类型依次调用对应序列化方法即可

Item间的共享数据处理，是本次序列化优化最核心的优化点，对序列化效率提升有决定性影响，如特征/结果/日志Map的keySet的存储复用，具体做法是

读取第一个Item的所有keySet并保存在序列化上下文中，作为基准数据，后续每个Item都与第一个的keySet判断，完全相同就按第一个item的相同顺序将values依次取出，按队列存储，快速的判断方式如下：

private static boolean isNotEqualSet(Set<String> set1, Set<String> set2) {
        return set1 == null || set2 == null || (set1.size() != set2.size()) || !set1.containsAll(set2);
 }

当任意商品不满足keySet一致性的要求时，Item序列化方法会向上抛出异常，排序框架会捕获到该异常，并将返回的压缩响应对象(CompressedRankResponse)退化为普通响应对象(RankResponse)

异常行为会根据用户的选择上报给监控平台，或需要排查问题时选择打印到本地文件

上游服务无需关心排序服务返回了哪种响应对象，这是因为普通响应对象和序列化后的压缩响应对象实现了同一接口

即原RankResponse对象和新CompressedRankResponse对象实现了IRankResponse接口，CompressedRankResponse是RankResponse的装饰器对象

CompressedRankResponse对象在用户调用任意方法，且当内置RankResponse对象为空时完成反序列化，如下段代码中的getStatus方式所示

后续再调用其他方法在使用体验上是与未压缩对象一致的，这种与直接返回byte数组相比，业务使用更友好，异常时可以快速降级，也没有太多带来额外成本

IRankResponse rank(RankRequest request);
 
class RankResponse implements IRankResponse;
 
class CompressedRankResponse implements IRankResponse {
    byte[] bytes; // 排序服务返回的数据
     
    RankResponse response = null; // 调用任意方法后反序列化生成的数据
     
    public int getStatus() {
        if(response == null) {
            // 执行反序列化
            response = this.doDeserilize();
        }
        return response.getStatus();
    }
}

模拟搜索500个商品，测试2000次，序列化前大小1430640

第一次测试：实验组为V3优化，对照组为无优化

第二次测试：实验组为V3优化，对照组为V2优化

可见V3对序列化过程的执行效率提升明显

以下是业务接入情况 

搜索侧接入：测试接入排序服务耗时于未服务化时持平，满足上线要求

推荐测接入：序列化过程在2ms左右完成，场景接入后耗时均有明显下降，符合预期

4 总结

本项目旨在解决搜索推荐服务化过程中因日志传输引起的序列化额外耗时问题。经过三次版本迭代和测试，最终方案成功落地。

结论

本地测试：

• 与优化前相比，排序响应对象的序列化过程节省了约 83% 的序列化开销，网络开销减少了约 67%。搜索：
• 有效降低了排序服务响应中的序列化过程对搜索接口整体耗时的影响，使得新的搜索排序服务在性能上达到了上线要求。推荐：
• 在推荐排序服务化后，接入本项目方案，在多个展位实现了接口整体耗时绝对值降低 2ms 到 6ms 的性能提升。

思考

从问题发现到解决上线，项目历时近一个月。虽然问题定位较为迅速，但在确定最终方案和落地时经历了较长的周期。方案设计过程中有两点需要注意：

方案评估要更细致：

• 不要急于实施方案，要及时暴露性能瓶颈。例如，前期如果发现日志上报超出了 Redis 单节点 10 万 QPS 的瓶颈，在考虑实施 V1 方案时会更加谨慎。

方案设计要更具全局性：

• 不应仅将视角局限于字符串序列化过程，而是从整个序列化过程的角度出发。这样可以更快地跳过 V2 方案，直接进入更高效的 V3 方案。

后续工作

废弃遗留代码：

• 遗留代码增加了开发的不确定性和风险性，因此需要废弃 SCF 原生序列化方法和 V1 方法。

召回框架的序列化优化：

• 召回服务框架的序列化优化尚未启动，预计也能获得显著的性能提升。然而，与排序框架相比，召回框架涉及的传输对象类型更多，优化难度更高，因此方案需要在排序优化的基础上进一步调整。