前面我们已经完结了整个秒杀系统,不管是同步的方式还是异步的方式,相信不熟悉的同学按照这里的内容实际操作一遍之后都会很轻松的熟悉整个秒杀系统,并且能独立的编写实际的秒杀系统项目。
在咱们这个演示项目里面其实还有很多细节性的东西没有完善,在这里我们列出以下:
1、tcc对应的cancel和confirm,其实还应该有很多判断,例如取消的订单号由插入的时候保存,取消的时候查询验证后再进行取消,咱们这里做的比较简单,只要查询到有未支付的订单就取消。 2、在实际的项目中,对应的这些表和表结构其实会更加的复杂,例如里面还有商品的状态,商品的sku等等信息,这些细节需要结合实际情况进行处理。 3、本项目由于只是做演示用,要并发演示效果,所以这里我们没有编写同一个人只能抢购一单等情况,实际情况需要在缓存这一个service代码层里面进行多个判断。 4、整个项目细节很重要,其实看代码没有多少,但是写的每一行代码都可能在其他地方进行关联,虽然这个演示项目可能1天就写完了,但是实际开发中结合细节等部分测试,至少开发这个接口建议还是多预留一些时间,把每个地方测试好(建议至少1周以上) 5、对于分布式事务的使用这里还比较欠缺,主要是tcc框架里面可能try执行成功了,此时数据库挂了,那么confirm和cancel方法执行会失败,虽然hmily自身带有重试,但是这里我们也需要做一手人工处理的准备,因为所有的分布式事务框架在实际的使用中我们都需要预留一手人工处理的准备,这是必备的事项。 6、在进行confirm和cancel的时候,一定要进行相关的判断,避免可能没有执行成功,就直接执行了confirm或者cancel方法,导致数据错误。
最后再总结一句,秒杀系统重在细节,一定要做白盒测试,保证每一行代码的关联性出现异常都可以被正确的还原。
还没有评论,来说两句吧...