面对着数百G的数据,数万的TPS,一直在找合适的数据库及RPC框架。最近对aerospike和google grpc、apache thrift进行了简单的测试。
测试的内容比较简单,就是客户端根据KEY到服务端进行查找,返回value。为了测试简单,数据库中只有一对key_value。数据库用的aerospike,RPC框架分别用grpc\thrift,客户端、服务端都用GO语言开发。
grpc定义如下:
syntax = "proto3";
package inf;
message AuthRq {
string clientId = 1;
string token = 2;
}
message AuthRp {
string token = 1;
}
message DataTypeRq {
AuthRq authRq = 1;
string groupName = 101;
string enName = 102;
}
message DataTypeRp {
AuthRp authRp = 1;
int64 codeId = 101;
string cnName = 102;
}
service Data {
rpc DataType (DataTypeRq) returns (DataTypeRp){};
}
thrift定义如下:
namespace go inf
namespace java inf
namespace cpp inf
struct AuthRq {
1: string clientId;
2: string token;
}
struct AuthRp {
1: required string token;
}
struct DataTypeRq {
1: required AuthRq authrq;
2: required string groupName;
3: required string enName;
}
struct DataTypeRp {
1: required AuthRp authrp;
2: required i64 codeId;
3: required string CnName;
}
service Data {
DataTypeRp DataType (1: DataTypeRq dataTypeRq);
}
服务端与grpc相关代码如下:
//DataType 将请求参数转化为DataTypeM的请求参数,调用DataTypeM,并将结果返回
func (t *Data) DataType(ctx context.Context, request *inf.DataTypeRq) (response *inf.DataTypeRp, err error) {
//log.Printf("App request: %#v", request)
// if authRsp, err := t.Auth(ctx, request.AuthRq); err == nil {
var req DataTypeReq
req.EnName = request.EnName
req.GroupName = request.GroupName
result, err := dataTypeM(req)
response = &inf.DataTypeRp{
AuthRp: &inf.AuthRp{Token: authRsp.Token},
CnName: result.CnName,
CodeId: result.CodeId,
}
return response, err
// } else {
// return nil, err
// }
}
服务端与thrift相关代码如下:
func (t *Data) DataType(request *inf.DataTypeRq) (response *inf.DataTypeRp, err error) {
//log.Printf("App request: %#v", request)
// if authRsp, err := t.Auth(request.Authrq); err == nil {
var req DataTypeReq
req.EnName = request.EnName
req.GroupName = request.GroupName
result, err := dataTypeM(req)
response = inf.NewDataTypeRp()
response.Authrp.Token = authRsp.Token
response.CnName = result.CnName
response.CodeId = result.CodeId
//log.Printf("DataType response: %#v", response)
return response, err
// } else {
// return nil, err
// }
}
服务端与aerospike相关代码,DataType调用如下函数:
func dataTypeM(request DataTypeReq) (response DataTypeRsp, err error) {
//log.Printf("DataTypeM request: %#v", request)
cacheTable := "data_type_def"
key := request.GroupName + "|" + request.EnName
keys, err := NewKey("test", cacheTable, key)
result, err := asClient.Get(nil, keys)
if result == nil {
for {
hostname, _ := os.Hostname()
serverId := hostname + strconv.Itoa(os.Getpid()) + strconv.Itoa(time.Now().Nanosecond())
if ok := tdp.DLock(key, serverId); ok {
bin1 := NewBin("cnname", "语音接通")
bin2 := NewBin("code_id", 101)
asClient.PutBins(nil, keys, bin1, bin2)
result, _ = asClient.Get(nil, keys)
tdp.UnDLock(key, serverId)
break
} else {
time.Sleep(tryLockSleep * time.Millisecond)
result, _ := asClient.Get(nil, keys)
if result != nil {
break
}
}
}
}
if result != nil {
response.CnName, _ = result.Bins["cnname"].(string)
tmp, _ := result.Bins["code_id"].(int)
//log.Printf("code_id: %d", tmp)
response.CodeId = int64(tmp)
} else {
log.Printf("can't get result: %#v", request)
}
return response, err
}
客户端代码如下,与RPC框架无关的代码完全一样:
func dataType(client inf.DataClient, t string) {
var request inf.DataTypeRq
var reqAuth inf.AuthRq
reqAuth.ClientId = clientId
reqAuth.Token = token
request.AuthRq = &reqAuth
// request.ClientId = clientId
// request.Token = "1"
request.EnName = "app_call_connect_success"
request.GroupName = "USER_EVENT"
response, err := client.DataType(context.Background(), &request) //thrift中是: response, err := client.DataType(request)
if err == nil {
token = response.AuthRp.Token
log.Printf("token: %s", response.AuthRp.Token)
if response.CodeId != 101 {
log.Printf("DataType %#v", response)
}
} else if err.Error() == "1" {
log.Printf("auth failer: %#v", err)
}
}
测试服务器是两台,都是两颗Intel E5 2630 CPU,服务端在A服务器上,192G内存,aerospike和客户端在B服务器上,128G内存;多客户端用goroutine实现。
以下是客户端并发数在50时的截图
grpc:
服务端
客户端
thrift:
服务端
客户端
在整个测试过程中,客户端并发数无论是50,还是800,资源使用情况都相差不大。总体来看,thrift服务端或者客户端,对CPU的使用率偏少,而grpc的使用率偏多,在客户端50时服务端grpc比thrift多使用30%的CPU。
以下是性能测试结果:
从测试来看grpc性能普遍好于thrift,但两者性能相差很小。最好的成绩是好于17%,最差好于3%。不过,grpc刚出来,还处于alpha阶段,所用的protobuf3协议,也处于alpha阶段。相信等正式版后,GPRC的性能会有一个提升的。
另外,从开发的角度看,thrift和grpc协议在使用上相差很小,从学习曲线上来讲,从一方转向另一方是比较容易的。目前grpc-go依赖的第三方包,大部分都在googlecode上,需要越狱获取,很不方便。
版权声明:欢迎转载。
有疑问加站长微信联系(非本文作者)