2013-用户等级消费额度升级程序迁徙及开发

协作时的错误

1个线程读入map<String,BlockingQueue>,key按库和每个库取余数，每个key分一个线程进行写入。

写入不同Queue时如果阻塞，其它Queue不能入数据，库余数和每个库余数造成有的key无值(4个库，每个库两个线程，不用一个值求hash可解决)。改用读到数据后用不同线程写入。如果有一个没写入完成，不能进行下次取数据。改为几个线程读入数据放入BlockingQueue中，一批线程来取BlockingQueue中的数据，然后分几个线程来进行写入。

分库分表大陷阱

计算库和表的hash种子不能一样，避免分库和分表奇偶问题造成的不平均。

先锁定再处理防止重复锁定

 

    取出加消费额任务时，先锁定成状态值+100的状态，再进行处理，防止被重复处理。并且在特定业务表使用业务关联UUID来进行防重复。

关于服务层的考虑

原程序

BatchGradeService批量任务升级服务（锁定一批升级任务，UpGrade单个任务进行升级-事务，出错回滚，成功发送邮件短信）

UpGrade（计算用户等级，变更等级，产生升级记录，解锁）事务

如果我又想加入这样一个功能，重新计算一下用户等级(包括修改等级)，这样就要求和任务无关，任务只是触发计算等级的一个开关，但并不是计算等级的领域逻辑，目前计算等级是要根据任务来锁定的。可以单独把计算用户等级和修改等级做为一个领域逻辑，这个逻辑是可以重复执行，不需要锁定的解锁的。

改为：

BatchGradeService（锁定一批升级任务，UpGrade单个任务进行升级-事务，出错回滚，成功发送邮件短信）

根据任务升级服务(UpGrade升级，解锁)事务

UpGrade升级（计算用户等级，变更等级，产生升级记录）

 

总结：锁定再操作属于应用服务，锁定本身可以看做一个技术辅助，但不是一个领域服务。

           发邮件短信提醒可以看做是领域服务。

           应用服务协调领域服务来工作。

 注：此版本程序是访问sqlserver只是个中间版本，在后续版本中更新本文档

 

附相关知识：

领域逻辑：只与问题领域有关

 

应用逻辑：与应用的职责有关，也称为工作流逻辑。（组装领域服务来做一个工作职责）