LevelDB在测试中应用应用
LevelDB是Google开源的持久化KV单机数据库，这个有点类似Redis，通常我们在存储key-value的数据都会选择Redis。但是唯一的问题就是得有Redis给我们用。LevelDB可以完美解决我们这种问题，存储在本地的文件当中，如果数据量不多的话，可以直接提交在代码中提交文件，然后就可以把数据放在这个数据库中。
之前写过了LevelDB Java&Go实践和LevelDB封装和功能拓展，下面分享最近在使用LevelDB的过程中，总结了几种使用场景，供大家参考。
Part1临时存储
对于某些临时存储的文件，比如我要存储一个登录token，但是这个token有可能会过期，正常逻辑是如果token过期，HTTPcode会返回401。然后我就需要重新登录，获取新的token，来替换掉旧的token。
如果脚本运行都执行登录操作，会显得非常麻烦，如果我们将token存储到LevelDB中，那么就比较好解决这个问题。每次执行的时候，我们判断接口返回HTTPcode，选择更新token即可。
演示的伪代码如下：
package com.funtest.groovytest
import com.alibaba.fastjson.JSONObject
import 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
}
}
Part2不可见存储
在日常的工作中，我们会遇到很多需要用到的账号和密码，但是各种信息我们并不想写在代码中或者说放在配置文件中，最起码不应该放明文信息存储在某个肉眼可见地方。通常我们会采取加密的方式将明文转成密文，然后用的时候再转成明文，把明文存储在内存中。
这种场景下，我们可以使用LevelDB存储这些数据，这样明文就是不可见，使用的时候取就行，可以理解为放在Redis里面。但是这个Redis是文件形式的，而不是服务形式。
伪代码如下：
class Demo {
static String name
static String pwd
static {
name = LevelBase.Instance().get("FunTester_name")
pwd = LevelBase.Instance().get("FunTester_pwd")
}
}
Part3有状态服务
目前使用场景中还有一个就是将一个正常的Java服务变成一个有状态的服务，比如这个服务需要执行大量的耗时的任务，这些任务都是在内存中的，会分多个阶段，在分布式性能测试中经常碰见这样的情况。每一个节点的状态都不一样，运行的任务也是不一样的，如果将这些状态都保存下来，以便后面继续执行或者根据不同状态执行不同的分支，都需要依赖一个记录功能。如果放在MySQL明显不太合适，多个节点多时段数据都会在MySQL中进行频繁的修改，而且还得考虑网络的问题，而通常这些节点之间的状态都是完全独立的。这个时候LevelDB就能非常好满足我们的需求。使用LevelDB将无状态服务转换成有状态服务。如果服务重启可以继续执行任务，通常是自动化性能巡检，进行大量io的操作。
Part4历史数据
如果不使用其他数据库，LevelDB可以讲数据存在文件中，这样有个好处就是可以随着代码一起提交，不仅可以分享数据，也能对历史数据进行统计。但这样做有个缺点，就是无法多人在同一个数据库上进行操作，跟代码还是有些区别。这一点我通常用来存储服务节点的监控数据。每小时统计一次，做一个历史情况的记录，通过监控脚本获取监控数据，使用报警规则进行判断。这些数据放在MySQL的话，会比较大，而且同样面临大量增删。当然这样的场景也有专门的解决方案，比如influxDB等。可这样显得大材小用了。取了个折中的办法，可以使用LevelDB实现这个需求。
LevelDB部分的分享就此结束了，欢迎继续关注FunTester其他内容。
