写点什么

LevelDB 在测试中应用应用

作者:FunTester
  • 2022 年 1 月 04 日
  • 本文字数:2038 字

    阅读完需:约 7 分钟

LevelDB 是 Google 开源的持久化 KV 单机数据库,这个有点类似 Redis,通常我们在存储 key-value 的数据都会选择 Redis。但是唯一的问题就是得有 Redis 给我们用。LevelDB 可以完美解决我们这种问题,存储在本地的文件当中,如果数据量不多的话,可以直接提交在代码中提交文件,然后就可以把数据放在这个数据库中。


之前写过了LevelDB Java&Go实践LevelDB封装和功能拓展,下面分享最近在使用 LevelDB 的过程中,总结了几种使用场景,供大家参考。

临时存储

对于某些临时存储的文件,比如我要存储一个登录 token,但是这个 token 有可能会过期,正常逻辑是如果 token 过期,HTTPcode 会返回 401。然后我就需要重新登录,获取新的 token,来替换掉旧的 token。


如果脚本运行都执行登录操作,会显得非常麻烦,如果我们将 token 存储到 LevelDB 中,那么就比较好解决这个问题。每次执行的时候,我们判断接口返回 HTTPcode,选择更新 token 即可。


演示的伪代码如下:


package com.funtest.groovytest
import com.alibaba.fastjson.JSONObjectimport com.funtester.db.leveldb.LevelBase
class Demo {
static def token;
static { token = LevelBase.Instance().get("FunTester_token") }
/** * 登录 */ def login() { String url = "/login" params.name = "FunTester" params.pwd = "123456" def response = getResponse(url, params) token = response.getString("token") LevelBase.Instance().put("FunTester_token", token) }
/** * 查询 */ def select() { String url = "/select" params.key = "FunTester" def response = getResponse(url, params) if (response.getCode == 401) { login() response = getResponse(url, params) } dosomething() }
/** * 获取请求响应 * @param url * @param params * @return */ def getResponse(String url, JSONObject params) { def request = getRequest(url, params) request.addHeader("token", token) def httpresponse = getHttpresponse(request) httpresponse }
}
复制代码

不可见存储

在日常的工作中,我们会遇到很多需要用到的账号和密码,但是各种信息我们并不想写在代码中或者说放在配置文件中,最起码不应该放明文信息存储在某个肉眼可见地方。通常我们会采取加密的方式将明文转成密文,然后用的时候再转成明文,把明文存储在内存中。


这种场景下,我们可以使用 LevelDB 存储这些数据,这样明文就是不可见,使用的时候取就行,可以理解为放在 Redis 里面。但是这个 Redis 是文件形式的,而不是服务形式。


伪代码如下:


class Demo {
static String name
static String pwd
static { name = LevelBase.Instance().get("FunTester_name") pwd = LevelBase.Instance().get("FunTester_pwd") }
}
复制代码

有状态服务

目前使用场景中还有一个就是将一个正常的 Java 服务变成一个有状态的服务,比如这个服务需要执行大量的耗时的任务,这些任务都是在内存中的,会分多个阶段,在分布式性能测试中经常碰见这样的情况。每一个节点的状态都不一样,运行的任务也是不一样的,如果将这些状态都保存下来,以便后面继续执行或者根据不同状态执行不同的分支,都需要依赖一个记录功能。如果放在 MySQL 明显不太合适,多个节点多时段数据都会在 MySQL 中进行频繁的修改,而且还得考虑网络的问题,而通常这些节点之间的状态都是完全独立的。这个时候 LevelDB 就能非常好满足我们的需求。使用 LevelDB 将无状态服务转换成有状态服务。如果服务重启可以继续执行任务,通常是自动化性能巡检,进行大量 io 的操作。

历史数据

如果不使用其他数据库,LevelDB 可以讲数据存在文件中,这样有个好处就是可以随着代码一起提交,不仅可以分享数据,也能对历史数据进行统计。但这样做有个缺点,就是无法多人在同一个数据库上进行操作,跟代码还是有些区别。这一点我通常用来存储服务节点的监控数据。每小时统计一次,做一个历史情况的记录,通过监控脚本获取监控数据,使用报警规则进行判断。这些数据放在 MySQL 的话,会比较大,而且同样面临大量增删。当然这样的场景也有专门的解决方案,比如 influxDB 等。可这样显得大材小用了。取了个折中的办法,可以使用 LevelDB 实现这个需求。


LevelDB 部分的分享就此结束了,欢迎继续关注 FunTester 其他内容。

Have Fun ~ Tester !

发布于: 1 小时前
用户头像

FunTester

关注

公众号:FunTester,750篇原创,欢迎关注 2020.10.20 加入

公众号FunTester,坚持原创文章的测试人,一个有趣的灵魂。

评论

发布
暂无评论
LevelDB在测试中应用应用