企业🤖AI智能体构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
# 测试环境 平台:虚拟机 CPU:E7-4890 4核8线程 内存:8G 硬盘:机械硬盘 OS:Windows Sever 2012 R2 MySQL: 5.5 Rides: 4.0.2 # 测试数据 t_user表,14个字段,1个字段包含中文,数据量527206条 # 测试配置 配置: ``` #maxprocs: 50 #并发协(线)程数量,默认为: CPU核数*2;一般情况下不需要设置此项 bulk_size: 1000 #每批处理数量,不写默认100,可以根据带宽、机器性能等调整;如果是全量数据初始化时redis建议设为1000,其他接收端酌情调大 ``` 规则: ``` schema: eseap table: t_user order_by_column: id #排序字段,全量数据初始化时不能为空 #column_lower_case:false #列名称转为小写,默认为false #column_upper_case:false#列名称转为大写,默认为false column_underscore_to_camel: true #列名称下划线转驼峰,默认为false # 包含的列,多值逗号分隔,如:id,name,age,area_id 为空时表示包含全部列 #include_column: ID,USER_NAME,PASSWORD date_formatter: yyyy-MM-dd #date类型格式化, 不填写默认yyyy-MM-dd datetime_formatter: yyyy-MM-dd HH:mm:ss #datetime、timestamp类型格式化,不填写默认yyyy-MM-dd HH:mm:ss value_encoder: json #值编码,支持json、kv-commas、v-commas redis_structure: string # 数据类型。 支持string、hash、list、set类型(与redis的数据类型一直) redis_key_prefix: USER_ #key的前缀 redis_key_column: ID #使用哪个列的值作为key,不填写默认使用主键 ``` 脚本: ``` local json = require("json") -- 加载json模块 local ops = require("redisOps") -- 加载redis操作模块 local row = ops.rawRow() --当前变动的一行数据,table类型,key为列名称 local action = ops.rawAction() --当前数据库的操作事件,包括:insert、updare、delete local id = row["ID"] --获取ID列的值 local userName = row["USER_NAME"] --获取USER_NAME列的值 local key = "user_"..id -- 定义key if action == "delete" -- 删除事件 then ops.DEL(key) -- 删除KEY else local password = row["PASSWORD"] --获取USER_NAME列的值 local createTime = row["CREATE_TIME"] --获取CREATE_TIME列的值 local result= {} -- 定义结果 result["id"] = id result["userName"] = userName result["password"] = password result["createTime"] = createTime result["source"] = "binlog" -- 数据来源 local val = json.encode(result) -- 将result转为json ops.SET(key,val) -- 对应Redis的SET命令,第一个参数为key(string类型),第二个参数为value end ``` # 测试用例一 使用规则,将52万条数据全量初始化同步到Redis,结果如下: ![](https://img.kancloud.cn/70/88/7088639500d3892b6c31237ecef35592_472x143.png) 3次运行的中间值为4.6秒 # 测试用例二 使用Lua脚本,将52万条数据全量初始化同步到Redis,结果如下: ![](https://img.kancloud.cn/78/3c/783cb3ba21e169a3c74964dca7268bd8_473x147.png) 3次运行的中间值为9.5秒 # 测试用例三 使用规则,将binlog中52万条增量数据同步到Redis。结果如下: ![](https://img.kancloud.cn/16/c6/16c636650a9f3dcc47d60e10a429d7e6_510x290.png) 每秒增量同步(TPS)32950条 # 测试用例四 使用Lua脚本,将binlog中52万条增量数据同步到Redis。结果如下: ![](https://img.kancloud.cn/9f/1d/9f1d33d63ab8e1ae90db44999555a720_500x464.png) 每秒增量同步(TPS)15819条 # 测试用例五 100个线程不停向MySQL写数据,使用规则将数据实时增量同步到Redis,TPS保持在4000以上,资源占用情况如下: ![](https://img.kancloud.cn/30/5d/305ddb4dec44df6985fd7433516d000d_586x209.png) 100个线程不停向MySQL写数据,使用Lua脚本将数据实时增量同步到Redis,TPS保持在2000以上,资源占用情况如下: ![](https://img.kancloud.cn/20/a7/20a78bb8d23c06e7534ef035181399e5_586x171.png) <br/> # 结果说明 **测试环境不同,测试结果也会随着改变;硬件配置、软件版本、网络环境都会影响着测试结果** **以上,仅作为参考,为你在选择go-mysql-transfer时候提供依据**