关于hash:缓存空间优化实践

34次阅读

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

作者：京东科技 董健

导读

缓存 Redis，是咱们最罕用的服务，其实用场景宽泛，被大量利用到各业务场景中。也正因如此，缓存成为了重要的硬件老本起源，咱们有必要从空间上做一些优化，降低成本的同时也会进步性能。

上面以咱们的案例阐明，将缓存空间缩小 70% 的做法。

场景设定

1、咱们须要将 POJO 存储到缓存中，该类定义如下 

public class TestPOJO implements Serializable {
    private String testStatus;
    private String userPin;
    private String investor;
    private Date testQueryTime;
    private Date createTime;
    private String bizInfo;
    private Date otherTime;
    private BigDecimal userAmount;
    private BigDecimal userRate;
    private BigDecimal applyAmount;
    private String type;
    private String checkTime;
    private String preTestStatus;
    
    public Object[] toValueArray(){Object[] array = {testStatus, userPin, investor, testQueryTime,
                createTime, bizInfo, otherTime, userAmount,
                userRate, applyAmount, type, checkTime, preTestStatus};
        return array;
    }
    
    public CreditRecord fromValueArray(Object[] valueArray){// 具体的数据类型会失落，须要做解决}
}

2、用上面的实例作为测试数据 

TestPOJO pojo = new TestPOJO();
pojo.setApplyAmount(new BigDecimal("200.11"));
pojo.setBizInfo("XX");
pojo.setUserAmount(new BigDecimal("1000.00"));
pojo.setTestStatus("SUCCESS");
pojo.setCheckTime("2023-02-02");
pojo.setInvestor("ABCD");
pojo.setUserRate(new BigDecimal("0.002"));
pojo.setTestQueryTime(new Date());
pojo.setOtherTime(new Date());
pojo.setPreTestStatus("PROCESSING");
pojo.setUserPin("ABCDEFGHIJ");
pojo.setType("Y");

惯例做法 

System.out.println(JSON.toJSONString(pojo).length());

应用 JSON 间接序列化、打印 length=284， 这种形式是最简略的形式，也是最罕用的形式，具体数据如下：

{“applyAmount”:200.11,”bizInfo”:”XX”,”checkTime”:”2023-02-02″,”investor”:”ABCD”,”otherTime”:”2023-04-10 17:45:17.717″,”preCheckStatus”:”PROCESSING”,”testQueryTime”:”2023-04-10 17:45:17.717″,”testStatus”:”SUCCESS”,”type”:”Y”,”userAmount”:1000.00,”userPin”:”ABCDEFGHIJ”,”userRate”:0.002}

咱们发现，以上蕴含了大量无用的数据，其中属性名是没有必要存储的。

改良 1 - 去掉属性名 

System.out.println(JSON.toJSONString(pojo.toValueArray()).length());

通过抉择数组构造代替对象构造，去掉了属性名，打印 length=144，将数据大小升高了 50%，具体数据如下：

[“SUCCESS”,”ABCDEFGHIJ”,”ABCD”,”2023-04-10 17:45:17.717″,null,”XX”,”2023-04-10 17:45:17.717″,1000.00,0.002,200.11,”Y”,”2023-02-02″,”PROCESSING”]

咱们发现，null 是没有必要存储的，工夫的格局被序列化为字符串，不合理的序列化后果，导致了数据的收缩，所以咱们应该选用更好的序列化工具。

改良 2 - 应用更好的序列化工具 

// 咱们依然选取 JSON 格局，但应用了第三方序列化工具
System.out.println(new ObjectMapper(new MessagePackFactory()).writeValueAsBytes(pojo.toValueArray()).length);

选取更好的序列化工具，实现字段的压缩和正当的数据格式，打印 length=92， 空间比上一步又升高了 40%。

这是一份二进制数据，须要以二进制操作 Redis，将二进制转为字符串后，打印如下：

��SUCCESS�ABCDEFGHIJ�ABCD��j�6���XX��j�6����?`bM����@i��Q�Y�2023-02-02�PROCESSING

顺着这个思路再深挖，咱们发现，能够通过手动抉择数据类型，实现更极致的优化成果，抉择应用更小的数据类型，会取得进一步的晋升。

改良 3 - 优化数据类型

在以上用例中，testStatus、preCheckStatus、investor 这 3 个字段，实际上是枚举字符串类型，如果可能应用更简略数据类型（比方 byte 或者 int 等）代替 string，还能够进一步节俭空间。其中 checkTime 能够用 Long 类型代替字符串，会被序列化工具输入更少的字节。

public Object[] toValueArray(){Object[] array = {toInt(testStatus), userPin, toInt(investor), testQueryTime,
    createTime, bizInfo, otherTime, userAmount,
    userRate, applyAmount, type, toLong(checkTime), toInt(preTestStatus)};
    return array;
}

在手动调整后，应用了更小的数据类型代替了 String 类型，打印 length=69

改良 4 - 思考 ZIP 压缩

除了以上的几点之外，还能够思考应用 ZIP 压缩形式获取更小的体积，在内容较大或重复性较多的状况下，ZIP 压缩的成果显著，如果存储的内容是 TestPOJO 的数组，可能适宜应用 ZIP 压缩。

但 ZIP 压缩并不一定会缩小体积，在小于 30 个字节的状况下，兴许还会减少体积。在重复性内容较少的状况下，无奈取得显著晋升。并且存在 CPU 开销。

在通过以上优化之后，ZIP 压缩不再是必选项，须要依据理论数据做测试能力分辨到 ZIP 的压缩成果。

最终落地

下面的几个改良步骤体现了优化的思路，然而反序列化的过程会导致类型的失落，解决起来比拟繁琐，所以咱们还须要思考反序列化的问题。

在缓存对象被预约义的状况下，咱们齐全能够手动解决每个字段，所以在实战中，举荐应用手动序列化达到上述目标，实现精细化的管制，达到最好的压缩成果和最小的性能开销。

能够参考以下 msgpack 的实现代码，以下为测试代码，请自行封装更好的 Packer 和 UnPacker 等工具：

<dependency>    
    <groupId>org.msgpack</groupId>    
    <artifactId>msgpack-core</artifactId>    
    <version>0.9.3</version>
</dependency>
    public byte[] toByteArray() throws Exception {MessageBufferPacker packer = MessagePack.newDefaultBufferPacker();
        toByteArray(packer);
        packer.close();
        return packer.toByteArray();}

    public void toByteArray(MessageBufferPacker packer) throws Exception {if (testStatus == null) {packer.packNil();
        }else{packer.packString(testStatus);
        }

        if (userPin == null) {packer.packNil();
        }else{packer.packString(userPin);
        }

        if (investor == null) {packer.packNil();
        }else{packer.packString(investor);
        }

        if (testQueryTime == null) {packer.packNil();
        }else{packer.packLong(testQueryTime.getTime());
        }

        if (createTime == null) {packer.packNil();
        }else{packer.packLong(createTime.getTime());
        }

        if (bizInfo == null) {packer.packNil();
        }else{packer.packString(bizInfo);
        }

        if (otherTime == null) {packer.packNil();
        }else{packer.packLong(otherTime.getTime());
        }

        if (userAmount == null) {packer.packNil();
        }else{packer.packString(userAmount.toString());
        }

        if (userRate == null) {packer.packNil();
        }else{packer.packString(userRate.toString());
        }

        if (applyAmount == null) {packer.packNil();
        }else{packer.packString(applyAmount.toString());
        }

        if (type == null) {packer.packNil();
        }else{packer.packString(type);
        }

        if (checkTime == null) {packer.packNil();
        }else{packer.packString(checkTime);
        }

        if (preTestStatus == null) {packer.packNil();
        }else{packer.packString(preTestStatus);
        }
    }


    public void fromByteArray(byte[] byteArray) throws Exception {MessageUnpacker unpacker = MessagePack.newDefaultUnpacker(byteArray);
        fromByteArray(unpacker);
        unpacker.close();}

    public void fromByteArray(MessageUnpacker unpacker) throws Exception {if (!unpacker.tryUnpackNil()){this.setTestStatus(unpacker.unpackString());
        }
        if (!unpacker.tryUnpackNil()){this.setUserPin(unpacker.unpackString());
        }
        if (!unpacker.tryUnpackNil()){this.setInvestor(unpacker.unpackString());
        }
        if (!unpacker.tryUnpackNil()){this.setTestQueryTime(new Date(unpacker.unpackLong()));
        }
        if (!unpacker.tryUnpackNil()){this.setCreateTime(new Date(unpacker.unpackLong()));
        }
        if (!unpacker.tryUnpackNil()){this.setBizInfo(unpacker.unpackString());
        }
        if (!unpacker.tryUnpackNil()){this.setOtherTime(new Date(unpacker.unpackLong()));
        }
        if (!unpacker.tryUnpackNil()){this.setUserAmount(new BigDecimal(unpacker.unpackString()));
        }
        if (!unpacker.tryUnpackNil()){this.setUserRate(new BigDecimal(unpacker.unpackString()));
        }
        if (!unpacker.tryUnpackNil()){this.setApplyAmount(new BigDecimal(unpacker.unpackString()));
        }
        if (!unpacker.tryUnpackNil()){this.setType(unpacker.unpackString());
        }
        if (!unpacker.tryUnpackNil()){this.setCheckTime(unpacker.unpackString());
        }
        if (!unpacker.tryUnpackNil()){this.setPreTestStatus(unpacker.unpackString());
        }
    }

场景延长

假如，咱们为 2 亿用户存储数据，每个用户蕴含 40 个字段，字段 key 的长度是 6 个字节，字段是别离治理的。

失常状况下，咱们会想到 hash 构造，而 hash 构造存储了 key 的信息，会占用额定资源，字段 key 属于不必要数据，依照上述思路，能够应用 list 代替 hash 构造。

通过 Redis 官网工具测试，应用 list 构造须要 144G 的空间，而应用 hash 构造须要 245G 的空间 （当 50% 以上的属性为空时，须要进行测试，是否依然实用）

在以上案例中，咱们采取了几个非常简单的措施，仅仅有几行简略的代码，可升高空间 70% 以上，在数据量较大以及性能要求较高的场景中，是十分值得举荐的。：

• 应用数组代替对象（如果大量字段为空，需配合序列化工具对 null 进行压缩）

• 应用更好的序列化工具

• 应用更小的数据类型

• 思考应用 ZIP 压缩

• 应用 list 代替 hash 构造（如果大量字段为空，须要进行测试比照）

正文完
hash
发表至： hash
2023-04-17
 0
关于hash:缓存空间优化实践
关于hash:分布式-Jump-Consistent-Hash-原理解析下篇
关于hash:分布式-DBLE-分片算法之-hash-分片
关于hash:哈希理解哈希碰撞hash冲突及处理