项目亮点归总

父子事务嵌套问题

订单系统涉及到的异步操作主要集中在与第三方的交互中，例如用户开户后需要发送指令（订购商品，停复机等）给多个第三方，并且要等到所有第三方回调成功后，订单才能继续往下走，进行资源出库归档订单等操作。

在服务器接收到回调请求时，会启一个独立（required_new）的子事务A，先将对应的指令状态更新为收到回调然后提交该事务。再在父事务中进行其他操作，这个操作中包含了查询该指令。最后再启一个独立的子事务B，将指令状态改为回调成功。

但是实际场景中，我们发现有一些订单，在接口日志中能够查询到所有第三方都回调了，但是我们的表中还存在部分指令处于收到回调而不是回调成功的状态。排查日志后发现父事务出现了超时的问题。继续检查日志发现该指令执行了三次update语句（理论上只会有两个更新状态）。于是开始检查第二个update语句是哪里来的：

经过前后日志对比发现是在父事务中查询该指令后生成的，这个是因为hibernate的autoFlush机制：因为事务A修改了父子共享的session中的数据，导致父事务查询的时候也生成了一条update语句，这一条语句生成了行锁，并且这条行锁需要等到父事务结束后才会释放。导致在子事务B中的update语句一直在等待这个行锁释放导致子事务B一直无法提交。最终造成了死锁，父事务超时后该次回调请求就被忽略掉了。

解决方案就是要么就让父子事务不共享session，但是这样会造成性能降低有点因小失大。另外一个就是将hibernate的flush模式设置为commit，也就是事务提交时才会触发flush，避免意外生成update语句。

全表查询导致FullGC

预生产环境的批量节点频繁GC，导致服务被隔离，业务失效。

开启了heap dump之后使用jProfiler检查了dumpFile，发现有几个线程占用内存较大，堆中存储了40W个对象。根据堆栈找到对象加载的地方，发现这些对象来自于一个订单关系表，该表的数据量刚好也是40W条，经排查业务代码本来搜索条件是会带订单ID进行查询的（订单ID是索引），不会查出太多条数据。但是特殊场景中，订单ID为空，导致走了全表扫描。于是将所有的数据都查了一遍，最终导致GC。

这里就存在两个问题，第一个是这张表的数据不应该有这么多，在订单结束后需要及时移入历史表中，第二个是查询时不能允许不带任何条件查询，必须要带索引字段查询，避免全表扫描。

消息队列消息丢失

由于批量业务中一次性会开超1W个用户的场景（企业批量开户），该场景下如果使用正常的逻辑来进行指令发送会对服务器造成压力。所以我们选用了KAFKA实现一个消息队列来对该场景削峰，因为我们批量的业务类型比较少（批量开户，批量过户，批量停复机）所以根据业务类型来设置Topic不会超过100个，并且我们这些子订单之间不用保证发送的顺序（虽然kafka可以支持分区保证顺序），所以选用kafka足以。

但是在有一次版本更新之后，在预生产环境发现指令发送成功（我们订单表中状态更新为了指令发送成功），但是实际上接口日志中并没有调用第三方接口。于是就需要定位一下消息为什么会丢失。

首先从生产者，也就是我们的订单服务开始排查，我们默认的ACK设置的是1，也就是只要leader broker响应成功了，就认为消息入队成功，不再重试。为了排除是否是因为leader broker出现问题，导致消息丢失，我们将ack设置成-1（即必须要所有broker都响应成功才认为成功）再重试时，发现问题仍然存在，这就可以排除生产者端的问题。

再去broker上排查，发现每次生产者发送消息后，对应的topic和producerID都能在server.log上查询的到，并且在持久化文件中也能查到该消息，也就排除了broker的问题。

最终在consumer端的代码处发现了问题，之前因为commit模式设置的auto已经及发生过消息丢失的问题（在拉取消息时超过了设置的auto commit时间间隔，就自动提交offset给broker，最后异常导致该消息丢失）。所以他们设置的是手动提交offset，但是排查他们有一个新员工不熟悉这个commit的机制，在commit之后又进行了一次业务处理，在该次处理中发生了异常，最终导致消息被消费掉了，但是指令没有发送给第三方。

解决方案就是，一定要将指令发送请求的结果和提交offset的动作强绑定，不然都有可能造成消息丢失或者重复消费的问题。