Riddle 发布的文章

公司使用CSE框架做微服务开发,在打日志时虽然可以设置单条日志的大小,目前是10240,但是对于网关这种会处理大体积请求响应的微服务,10240有时是没法打出完整的日志的。

并且公司使用的云眼日志系统,针对单条日志抽取的体积是不到1024的,所以过长的日志会发生截断或者忽略。但是这样并不利于分现现网问题,于是之前就想着可以针对航班搜索或者退改签查询这种可能体积会比较大的日志做一下压缩,打印出来,如果需要后续分析的话,可以解密还原再做处理。不过压缩加密的代价会影响处理效率,航班搜索好在有缓存,所以可实施性还有的考虑。

目前搜索了一下现成的方案,找到的就是使用zip和gzip压缩(我是想找成熟的方案,其他要么是算法题,要么是一些简陋的实现,理论上应该会有类似的需求,不过目前找到的可行的只有这一种)。类似于网关发送给供应商请求时做的处理,然后把压缩的文本再做base64编码,需要用时再解码解压缩。具体方案如下:https://www.jianshu.com/p/b3fd26d82fd7

经过测试,如果先对文本做base64编码再送去处理,文本长度大概可以压缩50%以内,如果不做base64编码直接送去压缩,长度大概在40%以内。而已经压缩过的文本,进行二次压缩是没有效果的。

补充个Cpp的实现,用多了Java,对这种需要自己手写的实现还是有点担心,没有成熟的库函数调会不会因为自己写的不好导致出问题。
https://www.cnblogs.com/t-bar/p/16506289.html

前言

之前在公司因为业务需要,调研过分布式限流器的实现,当时查看了网上许多网友的实现,最后在写Demo的时候发现还是参考Guava的RateLimite实现更明了一些。本部分先介绍一下Guava的实现,至于我是怎么修改成分布式的限流器,放在另一篇中介绍。

简介

Guava一共实现了两种RateLimite算法,一个是