微服务项目下冗余数据如何同步？

废话不多说，上例子：
企业中心，的企业名称可能被冗余到了订单服务的订单表，商品服务的商品表。那么此时企业名称可能发生变更，企业名称一旦变更，历史的所有数据就显示的所有企业名称就都不对了。此时该怎么办呢？
于是就需要一套机制来保障主数据发生变更时能够同步更新所有与之关联的数据。
本身这是一种反范式的做法，但是有时候你又不得不这么做，因为这样不用进行跨服务查询，而名称的修改本身是个低频操作，所以如果你选择只存id，而不冗余名称，你会发现，服务间调用大大增加，性能急剧下降。前端一个订单列表可能需要将仓库，商品，等信息显示在一个页面上，此时你查一个订单列表就需要调用各个服务，而每一次调用的目的仅仅是为了取一个字段。并且时候超高频调用，显然对比之下，你更愿意采取的策略就是冗余，不仅提升了系统性能，还提示了开发效率，性价比最高。

此时要考虑的就是如何解决低频修改名称的问题。开发一个组件满足如下特性
1、可配置
2、易使用
3、可观测

一般这种数据冗余是在三范式的基础上违反第三范式的冗余也就是依赖传递，所以此时在表中的数据一定存在一个被传递的唯一id，比如，商品id，商品名称，商品名称就是被冗余的字段。
那么我们就可以构建数据表如下

drop table if exists `sync_task_source`;
CREATE TABLE `sync_task_source` (`id` bigint(20) NOT NULL AUTO_INCREMENT,`code` varchar(255) NOT NULL comment 'database:table:field 例user_center:user:username',`source_database_id` bigint(20) NOT NULL comment '源数据库id',`source_table_id` bigint(20) NOT NULL comment '源表id',`source_field_id` bigint(20) NOT NULL comment '源字段id',`source_query_field_id` varchar(64) NOT NULL comment '用于查询的字段',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;drop table if exists `sync_task_target`;
CREATE TABLE `sync_task_target`(`id` bigint(20) NOT NULL AUTO_INCREMENT,`task_source_id` bigint(20) NOT NULL comment '任务对应的源元数据',`target_database_id` bigint(20) NOT NULL comment '需要被更新的字段所在库',`target_table_id` bigint(20) NOT NULL comment '需要被更新的字段所在表',`target_field_id` bigint(20) NOT NULL comment '需要被更新的字段',`target_query_field_id` varchar(64) NOT NULL comment '用于查询的字段',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;drop table if exists `sync_task_data`;
CREATE TABLE `sync_task_data`(`id` bigint(20) NOT NULL AUTO_INCREMENT,`task_code` varchar(255) NOT NULL comment 'database:table:field 例user_center:user:username',`field_new_data` varchar(1000) default NULL comment '新的数据',`field_old_data` varchar(1000) default NULL comment '旧数据',`query_field_data` varchar(128) NOT NULL comment '用于查询对应数据的唯一值',`run_type` int(4) NOT NULL default 0 comment '0-初始提交,1-执行中,2-执行成功,3-执行失败',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

配置起来可能略显麻烦，所以出于易用性考虑，写个简单的配置页面
主表配置

目标表配置

这样一个配置关系就将主表于冗余字段的库表关系配置起来了
然后接着启动个canal服务，调用配置接口进行可配置订阅对于库表变更通知，然后在项目中获取主表配置进行比对，是否对应字段变更，如果是就启动一个定时任务获取所有目标表将数据同步出去。
整体架构如下

这样既可以避免入侵，又能解决问题。

微服务项目下冗余数据如何同步？相关推荐

微服务架构下静态数据通用缓存机制
点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试文章来源 | my.oschina.net/u/3971241/bl ...
如何在微服务架构下进行数据设计？
作者:唐建法 && Mongoing中文社区来自:http://www.mongoing.com/ 微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微 ...
SpringCloud微服务项目下的权限校验
1.以前的单体架构权限验证用户登录操作传入用户名和密码,传到后端,后端到DB里查询,如果查到就返回登录成功并把session信息存到内存中并把session的唯一标识(JessionId)返回给我们 ...
微服务架构下的静态数据通用缓存机制！
什么是静态数据为什么需要缓存通用缓存机制总结后记在分布式系统中,特别是最近很火的微服务架构下,有没有或者能不能总结出一个业务静态数据的通用缓存处理机制或方案,这篇文章将结合一些实际的研发经验 ...
微服务架构下，静态数据通用缓存机制！
本文转自:波斯码链接:https://blog.bossma.cn/architecture/microservice-business-static-data-universal-cache-me ...
微服务场景下数据抽取与统计
案例小故事某公司的技术架构体系目前还是以集群扩展体系为主,集群扩展体系架构如图9-1所示.在这种体系结构中,可以看到应用都是单块结构,但是单块结构的应用具有扩展性,通过部署在多个Tomcat上实现应 ...
一文读懂 Spring Boot、微服务架构和大数据治理三者之间的故事
微服务架构微服务的诞生并非偶然,它是在互联网高速发展,技术日新月异的变化以及传统架构无法适应快速变化等多重因素的推动下诞生的产物.互联网时代的产品通常有两类特点:需求变化快和用户群体庞大,在这种情况 ...
一文透析 Spring Boot、微服务架构和大数据治理三者之间的故事
微服务架构微服务的诞生并非偶然,它是在互联网高速发展,技术日新月异的变化以及传统架构无法适应快速变化等多重因素的推动下诞生的产物.互联网时代的产品通常有两类特点:需求变化快和用户群体庞大,在这种情况 ...
Spring Cloud与微服务学习总结（8）——Spring Boot、微服务架构和大数据治理三者之间的故事
前言微服务的诞生并非偶然,它是在互联网高速发展,技术日新月异的变化以及传统架构无法适应快速变化等多重因素的推动下诞生的产物.互联网时代的产品通常有两类特点:需求变化快和用户群体庞大,在这种情况下,如 ...

微服务项目下冗余数据如何同步？

微服务项目下冗余数据如何同步？相关推荐

最新文章

热门文章