近日踩坑小记

一、订单重复结算问题
1、订单设有标志位，区分已结算和未结算订单；
2、结算开始查询标志位，对未结算订单进行结算；
3、结算函数加锁；
4、结算开始加入redis缓存结算中订单 prefix+orderId ,结算中订单不重复结算，结算完成去掉缓存；
以上处理后仍存在重复结算问题： public synchronized void orderFinish(Orders orders)；仔细检查后发现是传入订单的问题；并发结算同一订单时缓存了结算前的订单信息（此时订单未结算），处理方式是结算时重新查询该订单最新信息；虽然是之前人员遗留的问题，解决后记录下防止自己犯同样的错误。

二、请求分配简单分配
业务需求：保证一个终端每次的信息分配至同一服务
1、配置多个mq,分发至不同的服务；
2、每个服务接收指定Queue消息；
3、终端上报信息时：
a、查询是否有已宕机服务，对于已宕机的服务清空对应信息
RedisUtil.fuzzyDel(routeData.SERVER_BINDING_TERMINAL+deadServerName+"*");//清空终端服务对应表
RedisUtil.del(routeData.SERVER_BINDING_TERMINAL_NUM+deadServerName); //清零服务队对应的服务数量
b、根据终端号查询缓存中是否存在对应的服务，有直接使用，
没有则分配（相对平均原则）
RedisUtil.incr(routeData.SERVER_BINDING_TERMINAL_NUM+distributedServerName);//记录服务绑定终端数量
RedisUtil.set(routeData.SERVER_BINDING_TERMINAL+distributedServerName+terminalId,distributedServerName);//分配终端对于服务列表
4、服务定时更新自身活动时间（超过指定阀值判定为宕机）

三、数据被覆盖问题
这个坑是之前遗留的，多服务共用一个三方信息表，缓存用户各服务对应的信息，采用的是sysType段加以区分；
userId sysType cashMessage date 以及标志位等其他信息；在其中一个系统调用update时居然发现用户所有信息都被覆盖成了同样的，
查看mapping才发现update是依赖userId，而此表居然没有主键，一个用户的userid对应的不容服务的信息全部被覆盖，万幸是在测试发现。
解决方式：1、update时同时依赖userid和sysType;2、加入主键以主键更新；3、各服务独立拥有自己的三方信息表

四、支付订单号重复问题
在调用微信支付时：返回201商户订单号重复；之前测试和生产是分开两个商户的，某些原因要求使用一个；
由于两个环境使用同一商户号，测试和生产同时在跑就会存在订单号重复问题；
解决方式：1、测试和生产订单号分段（如测试0-20000000；生产20000001------）；2、加不同的前缀或后缀；