背景
生产服务存在大批量数据请求报文同步的服务,但是nginx存在传输请求大小的限制,导致2000条数据就会报错,严重不满足1w的目标
解决方案
- 分页传输
分页传输有个好处,就是可以根据实际业务在大批量的情况下按固定大小报文进行传输,没有上限的压力,无非是多传输几次的事情;
但是有个数据丢失的风险,以及需要额外支持断点续传的功能; - 压缩传输
压缩传输有个好处,就是一次性递送,要么成功要么失败,不存在数据丢失的风险和断点续传的诉求。
压缩有上限,当报文大小达到一定程度压缩也会超过阈值。
方案分析
需求同意,当业务数据单批次超过1w的走线下推送的方式,
为了快速响应开发,决定采用压缩传输。该方案只需要约定压缩和解压的方法即可
实施阶段
/**
* 统一采用jdk的加解密方式
* @param primStr
* @return
*/
public static String compressByGzipAndBase64(String primStr) {
if (primStr == null || primStr.length() == 0) {
return primStr;
}
ByteArrayOutputStream out = new ByteArrayOutputStream();
GZIPOutputStream gzip = null;
try {
gzip = new GZIPOutputStream(out);
gzip.write(primStr.getBytes("UTF-8"));
} catch (IOException e) {
e.printStackTrace();
} finally {
if (gzip != null) {
try {
gzip.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
return new sun.misc.BASE64Encoder().encode(out.toByteArray());
}
/**
* 使用gzip进行解压缩
* @param compressedStr
* @return 解压后的字符串
*/
public static String decompressByGzipAndBase64(String compressedStr) throws IOException {
if (compressedStr == null) {
return null;
}
ByteArrayOutputStream out = new ByteArrayOutputStream();
ByteArrayInputStream in = null;
GZIPInputStream ginzip = null;
byte[] compressed = null;
String decompressed = null;
try {
compressed = new sun.misc.BASE64Decoder().decodeBuffer(compressedStr);
in = new ByteArrayInputStream(compressed);
ginzip = new GZIPInputStream(in);
byte[] buffer = new byte[1024];
int offset = -1;
while ((offset = ginzip.read(buffer)) != -1) {
out.write(buffer, 0, offset);
}
decompressed = out.toString("UTF-8");
} catch (IOException e) {
log.error("",e);
} finally {
if (ginzip != null) {
try {
ginzip.close();
} catch (IOException e) {
}
}
if (in != null) {
try {
in.close();
} catch (IOException e) {
}
}
if (out != null) {
try {
out.close();
} catch (IOException e) {
}
}
}
return decompressed;
}
本来网上有很多现成的例子,但是为了方便对接,不需要额外引入jar。决定采用jdk原生方法实现。
注意:在实际测试过程中出现了乱码现象,因此在方法中指定了编码格式。