作者：京东科技 董健
导读
缓存Redis，是我们最常用的服务，其适用场景广泛，被大量应用到各业务场景中。也正因如此，缓存成为了重要的硬件成本来源，我们有必要从空间上做一些优化，降低成本的同时也会提高性能。
下面以我们的案例说明，将缓存空间减少70%的做法。
场景设定
1、我们需要将POJO存储到缓存中，该类定义如下
1public class TestPOJO implements Serializable { 2 private String testStatus; 3 private String userPin; 4 private String investor; 5 private Date testQueryTime; 6 private Date createTime; 7 private String bizInfo; 8 private Date otherTime; 9 private BigDecimal userAmount; 10 private BigDecimal userRate; 11 private BigDecimal applyAmount; 12 private String type; 13 private String checkTime; 14 private String preTestStatus; 15 16 public Object[] toValueArray(){ 17 Object[] array = {testStatus, userPin, investor, testQueryTime, 18 createTime, bizInfo, otherTime, userAmount, 19 userRate, applyAmount, type, checkTime, preTestStatus}; 20 return array; 21 } 22 23 public CreditRecord fromValueArray(Object[] valueArray){ 24 //具体的数据类型会丢失，需要做处理 25 } 26}
2、用下面的实例作为测试数据
1TestPOJO pojo = new TestPOJO(); 2pojo.setApplyAmount(new BigDecimal("200.11")); 3pojo.setBizInfo("XX"); 4pojo.setUserAmount(new BigDecimal("1000.00")); 5pojo.setTestStatus("SUCCESS"); 6pojo.setCheckTime("2023-02-02"); 7pojo.setInvestor("ABCD"); 8pojo.setUserRate(new BigDecimal("0.002")); 9pojo.setTestQueryTime(new Date()); 10pojo.setOtherTime(new Date()); 11pojo.setPreTestStatus("PROCESSING"); 12pojo.setUserPin("ABCDEFGHIJ"); 13pojo.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-使用更好的序列化工具
1//我们仍然选取JSON格式，但使用了第三方序列化工具 2System.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类型替代字符串，会被序列化工具输出更少的字节。
1public Object[] toValueArray(){ 2 Object[] array = {toInt(testStatus), userPin, toInt(investor), testQueryTime, 3 createTime, bizInfo, otherTime, userAmount, 4 userRate, applyAmount, type, toLong(checkTime), toInt(preTestStatus)}; 5 return array; 6}
在手动调整后，使用了更小的数据类型替代了String类型，打印 length=69
改进4-考虑ZIP压缩
除了以上的几点之外，还可以考虑使用ZIP压缩方式获取更小的体积，在内容较大或重复性较多的情况下，ZIP压缩的效果明显，如果存储的内容是TestPOJO的数组，可能适合使用ZIP压缩。
但ZIP压缩并不一定会减少体积，在小于30个字节的情况下，也许还会增加体积。在重复性内容较少的情况下，无法获得明显提升。并且存在CPU开销。
在经过以上优化之后，ZIP压缩不再是必选项，需要根据实际数据做测试才能分辨到ZIP的压缩效果。
最终落地
上面的几个改进步骤体现了优化的思路，但是反序列化的过程会导致类型的丢失，处理起来比较繁琐，所以我们还需要考虑反序列化的问题。
在缓存对象被预定义的情况下，我们完全可以手动处理每个字段，所以在实战中，推荐使用手动序列化达到上述目的，实现精细化的控制，达到最好的压缩效果和最小的性能开销。
可以参考以下msgpack的实现代码，以下为测试代码，请自行封装更好的Packer和UnPacker等工具：
1<dependency> 2 <groupId>org.msgpack</groupId> 3 <artifactId>msgpack-core</artifactId> 4 <version>0.9.3</version> 5</dependency>
1 public byte[] toByteArray() throws Exception { 2 MessageBufferPacker packer = MessagePack.newDefaultBufferPacker(); 3 toByteArray(packer); 4 packer.close(); 5 return packer.toByteArray(); 6 } 7 8 public void toByteArray(MessageBufferPacker packer) throws Exception { 9 if (testStatus == null) { 10 packer.packNil(); 11 }else{ 12 packer.packString(testStatus); 13 } 14 15 if (userPin == null) { 16 packer.packNil(); 17 }else{ 18 packer.packString(userPin); 19 } 20 21 if (investor == null) { 22 packer.packNil(); 23 }else{ 24 packer.packString(investor); 25 } 26 27 if (testQueryTime == null) { 28 packer.packNil(); 29 }else{ 30 packer.packLong(testQueryTime.getTime()); 31 } 32 33 if (createTime == null) { 34 packer.packNil(); 35 }else{ 36 packer.packLong(createTime.getTime()); 37 } 38 39 if (bizInfo == null) { 40 packer.packNil(); 41 }else{ 42 packer.packString(bizInfo); 43 } 44 45 if (otherTime == null) { 46 packer.packNil(); 47 }else{ 48 packer.packLong(otherTime.getTime()); 49 } 50 51 if (userAmount == null) { 52 packer.packNil(); 53 }else{ 54 packer.packString(userAmount.toString()); 55 } 56 57 if (userRate == null) { 58 packer.packNil(); 59 }else{ 60 packer.packString(userRate.toString()); 61 } 62 63 if (applyAmount == null) { 64 packer.packNil(); 65 }else{ 66 packer.packString(applyAmount.toString()); 67 } 68 69 if (type == null) { 70 packer.packNil(); 71 }else{ 72 packer.packString(type); 73 } 74 75 if (checkTime == null) { 76 packer.packNil(); 77 }else{ 78 packer.packString(checkTime); 79 } 80 81 if (preTestStatus == null) { 82 packer.packNil(); 83 }else{ 84 packer.packString(preTestStatus); 85 } 86 } 87 88 89 public void fromByteArray(byte[] byteArray) throws Exception { 90 MessageUnpacker unpacker = MessagePack.newDefaultUnpacker(byteArray); 91 fromByteArray(unpacker); 92 unpacker.close(); 93 } 94 95 public void fromByteArray(MessageUnpacker unpacker) throws Exception { 96 if (!unpacker.tryUnpackNil()){ 97 this.setTestStatus(unpacker.unpackString()); 98 } 99 if (!unpacker.tryUnpackNil()){ 100 this.setUserPin(unpacker.unpackString()); 101 } 102 if (!unpacker.tryUnpackNil()){ 103 this.setInvestor(unpacker.unpackString()); 104 } 105 if (!unpacker.tryUnpackNil()){ 106 this.setTestQueryTime(new Date(unpacker.unpackLong())); 107 } 108 if (!unpacker.tryUnpackNil()){ 109 this.setCreateTime(new Date(unpacker.unpackLong())); 110 } 111 if (!unpacker.tryUnpackNil()){ 112 this.setBizInfo(unpacker.unpackString()); 113 } 114 if (!unpacker.tryUnpackNil()){ 115 this.setOtherTime(new Date(unpacker.unpackLong())); 116 } 117 if (!unpacker.tryUnpackNil()){ 118 this.setUserAmount(new BigDecimal(unpacker.unpackString())); 119 } 120 if (!unpacker.tryUnpackNil()){ 121 this.setUserRate(new BigDecimal(unpacker.unpackString())); 122 } 123 if (!unpacker.tryUnpackNil()){ 124 this.setApplyAmount(new BigDecimal(unpacker.unpackString())); 125 } 126 if (!unpacker.tryUnpackNil()){ 127 this.setType(unpacker.unpackString()); 128 } 129 if (!unpacker.tryUnpackNil()){ 130 this.setCheckTime(unpacker.unpackString()); 131 } 132 if (!unpacker.tryUnpackNil()){ 133 this.setPreTestStatus(unpacker.unpackString()); 134 } 135 }
场景延伸
假设，我们为2亿用户存储数据，每个用户包含40个字段，字段key的长度是6个字节，字段是分别管理的。
正常情况下，我们会想到hash结构，而hash结构存储了key的信息，会占用额外资源，字段key属于不必要数据，按照上述思路，可以使用list替代hash结构。
通过Redis官方工具测试，使用list结构需要144G的空间，而使用hash结构需要245G的空间**（当50%以上的属性为空时，需要进行测试，是否仍然适用）**
在以上案例中，我们采取了几个非常简单的措施，仅仅有几行简单的代码，可降低空间70%以上，在数据量较大以及性能要求较高的场景中，是非常值得推荐的。：
• 使用数组替代对象（如果大量字段为空，需配合序列化工具对null进行压缩）
• 使用更好的序列化工具
• 使用更小的数据类型
• 考虑使用ZIP压缩
• 使用list替代hash结构（如果大量字段为空，需要进行测试对比）