2013-商品迁徙

需求简述

sqlserver商品库全量迁徙至mysql

sqlserver商品库增量迁徙至mysql

mysql商品库增量迁徙至sqlserver

两边数据是异构的：几条sqlserver数据要合成一个mysql数据，几个sqlserver表数据对应mysql一张表的数据。

 

 

商品迁徙一开始设计用过头了

mysql中的一个表的记录来源于sqlserver中几个表，设计了个buiid接口，每个sqlserver中的对象实现此接口再统一进入一个build集合进行构建，在编码后发现，哪个表哪些字段怎么build的很难维护，不同build分的太散乱了，改进成不同build的逻辑放到了一起。

 

总结：不要过早设计，设计的复杂度要能解决面对的复杂问题，设计模式的意图很重要。

过早设计，不解释。

设计的复杂度要能解决面对的复杂问题，一开始认为来源于不同表是复杂，但实际哪些字段在哪些表，以及这些变更才是一个变化点。

设计模式的意图很重要：这个其实是合成模式的思想，合成模式和意图是单个对象和组合对象具有一致性。但本例不同对象并不够复杂。

正向效率解决

问题1：sqlserver商品库增量迁徙至mysql上线后发现有积压数据，观察后发现每天的变更量有1000多万，原因是一条商品变更后经过中间系统的传递，一个产品中的一个表变了，最后产生*10倍的changelog（记录哪些数据变更了）。

 

解决分析：效率点并不是因为程序处理慢，而是有重复的数据处理，只要过滤掉重复数据就可以了。增加了一个clean程序，对changelog进行清洗，增量程序只处理经过清洗的changelog.

回写效率解决

问题2：回写程序效率问题，mysql是分库分表的，sqlserver是一个库，有些表因为两边异构，比如属性表，mysql中的一条对应sqlserver几十条。担心由于数据库的压力造成积压。

 需求容易变更区域：mysql的一个changelog，可能会需要其它mysql表才能完成。这个关系是不稳定的。             

两种方案:

1.不管哪个表变了，把changelog合并成产品维度，同步整个产品，逻辑简单，适应需求变更。但担心效率。

2.按changelog影响数据，做局部同步，逻辑复杂要考虑每个表变化会不会影响其它表的情况，代码不好维护，需求变更响应差，好处是效率好。

解决分析：第一种效率问题主要在sqlserver端，第二种pass逻辑太复杂，是mysql部分哪些数据要同步及组装成需要同步的sqlserver数据复杂。使用第一种方案，用产品维度同步，但保留每个产品记录变更信息（），但在sqlserver更新数据库代码时可以使用变更信息。这样逻辑清晰，又保留了性能优化的接口。

 

总结下：解决问题要针对要解决的问题。

  1.明确问题。

  2.解决问题。

utf和GBK不兼容

mysql中为utf8，sqlserver为GBK，有些特殊字符到sqlserver中后变为?号，导致比对不通过，一开始解决方案是把特殊字符替换为？号再比对，但特殊字符不断出现新的，导致不断维护，后改为重写字符串比对方法，遍历字符比对，如果sqlserver为’?’直接通过。