最近的服务器设计中,我本来打算利用redis的持久化来作为内存的配置数据源,简单的说就是不利用内存儿利用redis 提供的API来作为数据的读和写。代码如下:
// 数据的存储
bytetmp, _ := json.Marshal(stPaiHangBang)
_, error := GRedis_Client.Zadd(G_PaiHangKey, float64(iPaiMing), bytetmp)
if error != nil {
Log_Eio.Fmt("GRedis_Client.Zadd: Set data ", error)
Log_Eio.Log("GRedis_Client.Zadd: Set data ", error.Error())
return false
}
return true
以上的只是在redis里面写入数据,在go 频繁的消息调用的情况写入数据并没有出现问题。但是在读取的时候,代码如下:
MapOpenId = make(map[string]*Global_Define.StPaiHangBang)
// 获取内存数据库的数据
Log_Eio.Fmt("GRedis_Client 是否为空:", GRedis_Client)
// 重新链接存储结构
if GRedis_Client == nil {
Redis_ConnFun()
}
// bytesMap, _ := GRedis_Client.Zrevrange(keys, 0, -1)
bytesMap, _ := GRedis_Client.Zrevrange(G_PaiHangKey, 0, -1)
Log_Eio.Fmt("GRedis_Client.Zrevrange return:", bytesMap)
// 1 循环取到数据。
var vcount = 0
//
var CommentInfotmp *Global_Define.StPaiHangBang
for _, score := range bytesMap {
// 如果时间戳大于或者等于member
CommentInfotmp = new(Global_Define.StPaiHangBang)
// 如果时间戳大于或者等于member
if 1 == 1 {
// 临时的 转换
json.Unmarshal(score, CommentInfotmp) // score转换结构体
// 判断数据与自己有关不
vcount++
Log_Eio.Fmt("GRedis_Client.Zrevrange string(score)", string(score))
//test
//json转map
var r Requestbody
r.req = string(score)
if req2map, err := r.Json2map(); err == nil {
// s := fmt.Sprintf("a %s", "string")
// fmt.Println(s)
OpenID := fmt.Sprintf("%s", req2map["OpenID"])
// PaiHang := fmt.Sprintf("%s", req2map["PaiHang"])
// YaoCiShu := fmt.Sprintf("%s", req2map["YaoCiShu"])
// 转换的
CommentInfotmp.OpenID = OpenID
// CommentInfotmp.PaiHang = PaiHang
// CommentInfotmp.YaoCiShu = YaoCiShu
Log_Eio.Fmt("------------------------------------------------")
Log_Eio.Fmt("OpenID", CommentInfotmp.OpenID)
Log_Eio.Fmt("------------------------------------------------")
Log_Eio.Fmt("GRedis_Client.Zrevrange MapOpenId:", CommentInfotmp)
} else {
Log_Eio.Fmt("GRedis_Client.Zrevrange MapOpenId[vcount]:error")
}
// 保存数据
MapOpenId[strconv.Itoa(vcount)] = CommentInfotmp
Log_Eio.Fmt("GRedis_Client.Zrevrange MapOpenId[vcount]:", MapOpenId[strconv.Itoa(vcount)])
}
// return MapOpenId
}
return MapOpenId
以上代码是读取,没有加锁的情况数据出现读取延迟的问题,造成功能设计上的缺陷;但是加了读写锁,消息队列的延迟会出现丢包的的情况。
现在暂时只有更换新的数据结构,采用内存操作,功能一切正常。
总结:单点redis持久化不如内存操作数据流读写的速度快,后期在项目中redis操作在操作不是很频繁的情况可以使用,如果高并发的大数据读写上,尽量选择多点redis的连接池处理。