Tapdata 技术博客
Tapdata 技术博客

周生生 | 全渠道商品中心建设

2020-04-10 10:00

关于周生生

周生生,源于1934年,中国内地、香港、澳门、台湾著名的的黄金珠宝企业。其名喻意周而复始,生生不息。周生生于1973年成为香港首家上市的黄金珠宝公司,其股票编号116。时至今日,已成为在大中华地区以企业管治严谨、服务殷勤专业、和产品优质精良见称的珠宝企业。


项目描述

周生生在原有手工盘点基础上,启动销售、生产、库存三方联动的盘点系统。其原方案为以数据变动产生的trigger,通过http方式,请求MQ,通过java接口程序,向目标端同步数据。


面临的挑战

MQ直连生产环境,对销售系统产生极大影响;

Trigger通过http方式请求MQ,一旦数据量增大,服务端来不及消费;

生产环境由原来的2家增加到70家门店同步数据;

高峰期RMQ每秒产生200 – 300条记录,造成同步瓶颈。


方案架构对比


tapdata 案例-周生生


产品成效对比

对比项原方式Tapdata
业务场景生产环境仅支持2家

无法实现增加到70家门店同步数据

支持中国大陆港澳台的上千家门店的生产环境
系统性能trigger直连生产环境

严重影响销售系统

tapdata通过挖掘oracle cdc机制完成增量数据同步对 oracle数据库性能几乎没有影响
同步速度trigger 通过 http 的方式请求 RMQ

一旦数据量增大,服务端来不及消费

tapdata 的增量同步机制无须记录中间过程


从而避免大量过程数据堆积

处理能力高峰期RMQ产生200 – 300条/秒记录

造成同步瓶颈

tapdata 的基于日志的流处理操作每秒并发量提高至600条/秒左右
配置周期需要编写大量程序与调试,开发周期可达数月Tapdata可以使用JS脚本来进行流处理计算,业务需求从开发到上线过程快至 1 天以内
维护成本程序开发与调试,耗费大量人工

业务增加或修改需要重写,维护成本高

任务配置与执行监测全程可视化操作,不懂技术也能完成操作,极大降低维护成本
业务模型每个业务模型需要专门配置一个触发器+MQ+

Java接口,冗余操作耗时

tapdata一套产品可满足不同需求,根据业务需求产出不同类型的业务模型节省大量人力物力





推荐阅读