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

（1）sqlserver版本程序

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

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

（2）迁徙程序

协作时的错误

如果程序中使用了读入阻塞的BlockingQueue，每个BlockingQueue要有一个单独的读取线程。

分库分表陷阱

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

（3）mysql版本程序

关于服务层的考虑

原程序

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

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

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

改为：

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

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

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

 

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

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

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

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

 

附相关知识：

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

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

mysql版本-热点数据问题解决

原加消费额度是每天消费任务触发一次本用户消费额度计算，但有一些用户每年订单量达到了百万，这些用户的数据散列到一个表中，当这些热点用户产生大量订单任务的时候，就会触发这几百万重复的计算，任务挤压。

方案一：改为累加消费额度，改动太大。

方案二：对热点数据单独处理，一般任务还走以前流程。改动小。从用户量上看，只有小量用户受本次上线影响。风险小。程序订单数超过10000设置为热点数据，加入Set进行去重，如果重复任务状态设置为21，每5分钟对热点数据每处理一次或者当set大于100时处理，状态设置为1。程序设计使用ThreadLocal保存热点数据和上次执行时间。代码：