Contents1一个数据导入的有趣问题架构云计算微服务Contents相比于传统的单体应用，在基于微服务架构的系统中进行数据导入的操作显得更加复杂一点。通常而言，微服务的架构中包含了多个服务，服务的技术架构也可能大相径庭，同时考虑到拓展的需要，每个服务都有可能会拓展成多个。最近遇到一个有趣的问题，进行了一些思考。场景大致是这样的：我们有一个单独的（以下简称），每天定时从一个目录读取文件（一个压缩包）。其中这个包中包括多个文件，分别对应到不同的业务数据，这些数据又影响到多个不同的（以下简称，，）于是读取到文件之后，解析文件，并通过消息发送给，，。收到消息大小的限制，文件中的内容不能一次性发送完成，需要拆分成个消息（比如每条数据一个消息），都是增量更新，因此收到数据后，要么新增，要么更新，就可以了。很完美。但是确每次都是全量更新。问题来了，如果按照，的做法，面临的问题有两个：如果没有办法区分一条数据是新增还是更新，那直接有问题即便可以，如何能删除多余的数据？譬如原来有条，现在过来条，这条更新了，多余的条则没有办法删除一个直接的办法是在开始的时候，先去删除所有的数据，然后再将数据发送过去就可以了。但是这样带来的问题就是，万一后面导入失败了，而删除已经做了，会造成以前的数据也不可用。这在我们的业务场景里面是比较致命的，应该至少保证同步失败的时候，保持上一次的数据。基于这个场景，想了一个解决方案在数据表中加一个字段标识，表示是哪一批次的数据创建一个视图，根据来查询出最新的数据同步完成之后，更新视图下面详细来说。假定我们是一个类似的配置的导入，首先创建表和视图create table t_raw_config(id int not null primary key auto_increment,`version` char(6) not null,name varchar(50) not null,value varchar(100));create view t_configasselect id, name, value from t_raw_config; Contents2在中，我们需要做的事情是：在导入开始的时候，生成一个唯一的，简单一点，我们根据日期来，比如假定有条数据，每个拆分成个，则有个中，每消费完成一个，则记录下消费的到一个列表中，例如（例如存储在中）中解析完成后，告知所有的，即收到告知后，比对是否与匹配，如果不匹配则等待（可以利用的实现，如果不匹配则不断去）所有的消息都消费完成后，更新视图，将设置为。如果考虑到性能问题，可以再字段上建索引；考虑空间问题，可以在这一步以前的数据