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.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
}
}
不可见存储
在日常的工作中，我们会遇到很多需要用到的账号和密码，但是各种信息我们并不想写在代码中或者说放在配置文件中，最起码不应该放明文信息存储在某个肉眼可见地方。通常我们会采取加密的方式将明文转成密文，然后用的时候再转成明文，把明文存储在内存中。
这种场景下，我们可以使用 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 其他内容。