潘森 面向过程

我将公司的项目内容抽象，大概是要做这样一件事情：

1、数据库 A 中有 2000 万条用户数据；

2、将数据库 A 中的用户读出，为每条用户生成 guid，并保存到数据库 B 中；

3、同时在数据库 A 中生成关联表；

项目要求为：

1、将用户存入数据库 B 的过程需要调用 sdk 的注册接口，不允许直接操作 jdbc 进行插入；

2、数据要求可恢复：再次运行要跳过已成功的数据；出错的数据要进行持久化以便下次可以选择恢复该部分数据；

3、数据要保证一致性：在不出错的情况下，数据库 B 的用户必然一一对应数据库 A 的关联表。如果出错，那么正确的数据加上记录下来的出错数据后要保证一致性；

4、速度要尽可能块：共 2000 万条数据，在保证正确性的前提下，至多一天内完成；

二、第一版：面向过程 ——2 个月

特征：面向过程、单一线程、不可拓展、极度耦合、逐条插入、数据不可恢复

最初的一版简直是汇聚了一个项目的所有缺点。整个流程就是从 A 库读出一条数据，立刻做处理，然后调用接口插入 B 库

然后在拼一个关联表的 sql 语句，插入 A 库。没有计数器，没有错误信息处理。

这样下来的代码最终预测 2000 万条数据要处理 2 个月。如果中间哪怕一条数据出错，又要重新再来 2 个月。简直可怕。

这个流程图就等同于废话，是完全基于面向过程的思想，整个代码就是在一个大 main 方法里写的，实际业务流程完全等同于代码的流程。

思考起来简单，但实现和维护起来极为困难，代码结构冗长混乱。而且几乎是不可扩展的。暂且不谈代码的设计美观，它的效率如此低下主要有一下几点：

1、每一条数据的速度受制于整个链条中最慢的一环。

试想假如有一条 A 库插入关联表的数据卡住了，等待将近 1 分钟（夸张了点），那这一分钟 jvm 完全就在傻等，它完全可以继续进行之前的两步。

正如你等待鸡蛋煮熟的过程中可以同时去做其他的事一样。

2、向 B 库插入用户需要调用 sdk（HTTP 请求）接口

那每一次调用都需要建立连接，等待响应，再释放链接。正如你要给朋友送一箱苹果，你分成 100 次每次只送一个，时间全搭载路上了。