解析 PowerJob 的序列化方案

作者 | HelloGitHub

来源 | HelloGitHub(ID:GitHub520)

头图 | CSDN 下载自视觉中国

序列化与反序列化一直是分布式编程中无法绕开的话题。PowerJob 作为一个完全意义上的分布式系统,自然少不了节点通讯时不可避免的序列化问题。由于 PowerJob 定位是中间件,出于对性能的追求,在序列化上自然也是花费了不少时间去雕琢。以下是整个过程中的一些经验与分享,希望对大家有所帮助。

序列化界新贵:kryo

kryo 作为目前最快的序列化框架,自然受到了我的青睐。在 PowerJob 中,kryo 是内置默认的序列化框架。下面为大家介绍 kryo 的用法。

1、基础用法

对于序列化框架来说,API 其实都差不多,毕竟入参和出参都定义好了(一个是需要序列化的对象,一个是序列化后的结果,比如字节数组)。下面简单介绍下 kryo 的基础用法,由于序列化和反序列化类似,以下使用序列化来作为演示。

Kryo kryo = new Kryo();
try (Output opt = new Output(1024, -1)) {
    kryo.writeClassAndObject(opt, obj);
    opt.flush();
    return opt.getBuffer();
}

代码很简单,首先需要创建两个对象:Kryo 和 Output。其中,Kryo 是序列化主角,负责完成实际的序列化/反序列化工作。而 Output 则是 kryo 框架封装的流对象,用于存储序列化后的二进制数据。当两个对象都准备完毕后,调用 kryo.writeClassAndObject(opt, obj) 方法即可完成对象的序列化,最后调用 Output 流对象的 getBuffer() 方法获取序列化结果,也就是二进制数组。

2、线程不安全

相信大家都用过 fastjson,初次接触 fastjson 肯定会被它简单的 API 所吸引,常用的序列化/反序列化统统一行代码搞定,比如 JSON.toJSONString() 。通常来说,这种通过静态方法暴露的 API,其背后的设计与实现都是线程安全的,也就是在多线程环境中,你可以安心的使用 fastjson 的静态方法进行序列化和反序列化,那么 kryo 可以吗?

从上述代码不难看出,不可以~否则,人家为什么要多次一举让你创建对象提高使用成本呢?

王进喜同志说过,没有条件就创造条件。既然 kryo 官方不提供静态方法让我们简单使用,那就自己封装一个吧~

抛开性能因素,封装一个工具类非常简单,毕竟我们的目标是解决 kryo 的并发安全问题,而当没有任何共享资源时,是不存在任何并发安全问题的。那么我们只需要在刚刚的实例代码上,套上一个静态方法,就完成了最简单的kryo 工具类封装,代码示例如下:

public static byte[] serialize(Object obj) {
    Kryo kryo = new Kryo();
    try (Output opt = new Output(1024, -1)) {
        kryo.writeClassAndObject(opt, obj);
        opt.flush();
        return opt.getBuffer();
    }
}

安全问题是解决了,但...事情往往不会那么简单。这种模式下,每一次调用都会重复创建 2 个新对象(Kryo 和 Output),这在高并发下会产生一笔不小的开销。为了获取性能的提升,自然要考虑到对象的复用问题。对象的复用常用解决方案有两个,分别是对象池和 ThreadLocal,下面分别进行介绍。

3、对象池

在编程中,“池”这个名词相信大家一定不陌生。线程池、连接池已经是并发编程中不可避免的一部分。“池”重复利用了复用的思想,将创建完后的对象通过某个容器保存起来反复使用,从而达到提升性能的作用。Kryo 对象池原理上便是如此。Kryo 框架自带了对象池的实现,因此使用非常简单,不外乎创建池、从池中获取对象、归还对象三步,以下为代码实例。

首先,创建 Kryo 对象池,通过重写 Pool 接口的 create 方法,便可创建出自定义配置的对象池。

private static final Pool<Kryo> kryoPool = new Pool<Kryo>(true, false, 512) {
    @Override
    protected Kryo create() {
        Kryo kryo = new Kryo();
        // 关闭序列化注册,会导致性能些许下降,但在分布式环境中,注册类生成ID不一致会导致错误
        kryo.setRegistrationRequired(false);
        // 支持循环引用,也会导致性能些许下降 T_T
        kryo.setReferences(true);
        return kryo;
    }
};

当需要使用 kryo 时,调用 kryoPool.obtain() 方法即可,使用完毕后再调用 kryoPool.free(kryo) 归还对象,就完成了一次完整的租赁使用。

public static byte[] serialize(Object obj) {
    Kryo kryo = kryoPool.obtain();
    // 使用 Output 对象池会导致序列化重复的错误(getBuffer返回了Output对象的buffer引用)
    try (Output opt = new Output(1024, -1)) {
        kryo.writeClassAndObject(opt, obj);
        opt.flush();
        return opt.getBuffer();
    }finally {
        kryoPool.free(kryo);
    }
}

对象池技术是所有并发安全方案中性能最好的,只要对象池大小评估得当,就能在占用极小内存空间的情况下完美解决并发安全问题。这也是 PowerJob 诞生初期使用的方案,直到...PowerJob 正式推出容器功能后,才不得不放弃该完美方案。

在容器模式下,使用 kryo 对象池计算会有什么问题呢?这里简单给大家提一下,至于看不看得懂,就要看各位造化了~

PowerJob 容器功能指的是动态加载外部代码进行执行,为了进行隔离,PowerJob 会使用单独的类加载器完成容器中类的加载。因此,每一个 powerjob-worker 中存在着多个类加载器,分别是系统类加载器(负责项目的加载)和每个容器自己的类加载器(加载容器类)。序列化工具类自然是 powerjob-worker 的一部分,随 powerjob-worker 的启动而被创建。当 kryo 对象池被创建时,其使用的类加载器是系统类加载器。因此,当需要序列化/反序列化容器中的类时,kryo 并不能从自己的类加载器中获取相关的类信息,妥妥的抛出 ClassNotFoundError!

因此,PowerJob 在引入容器技术后,只能退而求其次,采取了第二种并发安全方法:ThreadLocal。

4、ThreadLocal

ThreadLocal 是一种典型的牺牲空间来换取并发安全的方式,它会为每个线程都单独创建本线程专用的 kryo 对象。对于每条线程的每个 kryo 对象来说,都是顺序执行的,因此天然避免了并发安全问题。创建方法如下:

private static final ThreadLocal<Kryo> kryoLocal = ThreadLocal.withInitial(() -> {
    Kryo kryo = new Kryo();
    // 支持对象循环引用(否则会栈溢出),会导致性能些许下降 T_T
    kryo.setReferences(true); //默认值就是 true,添加此行的目的是为了提醒维护者,不要改变这个配置
    // 关闭序列化注册,会导致性能些许下降,但在分布式环境中,注册类生成ID不一致会导致错误
    kryo.setRegistrationRequired(false);
    // 设置类加载器为线程上下文类加载器(如果Processor来源于容器,必须使用容器的类加载器,否则妥妥的CNF)
    kryo.setClassLoader(Thread.currentThread().getContextClassLoader());
    return kryo;
});

之后,仅需要通过 *kryoLocal*.get() 方法从线程上下文中取出对象即可使用,也算是一种简单好用的方案。(虽然理论性能比对象池差不少)

老牌框架:Jackson

大名鼎鼎的 Jackson 相信大家都听说过,也是很多项目的御用 JSON 序列化/反序列化框架。在 PowerJob 中,本着不重复造轮子的原则,在 akka 通讯层,使用了 jackson-cbor 作为默认的序列化框架。

“什么,你问我为什么不用性能更好且已经在项目中集成了的 kryo?”

“那当然是因为 akka 官方没有提供 kryo 的官方实现,于是......”

如果使用 kryo,则需要自己实现一大堆编解码器,俨然有点写 netty 的味道...而 jackson-cbor 呢?只需要一点小小的配置就能搞定~

actor {
    provider = remote
    allow-java-serialization = off
    serialization-bindings {
        "com.github.kfcfans.powerjob.common.OmsSerializable" = jackson-cbor
    }
  }

虽然绝对性能可能不及 kryo,但对比于自带的 Java 序列化方式,性能已经提升 10 倍以上,在绝大部分场景都不会是性能瓶颈。所以~又有什么理由拒绝它呢~


更多精彩推荐
☞张勇云栖连讲三年,阿里云十年一剑,王者归来
☞微软水下数据中心“浮出水面”、GitHub代码保存在北极,数据黑科技贮藏方式大曝光!
☞微软全球 AKS 女掌门人,这样击破云原生“怪圈”!
☞阿里动物园再添新丁,小蛮驴搞定物流最后三公里
☞中国移动云智融合峰会 与您相约揽胜九天
☞我投资比特币的3个原因
点分享点点赞点在看
©️2020 CSDN 皮肤主题: 代码科技 设计师:Amelia_0503 返回首页