为什么需求订单重试
订单重试是指当用户提交的订单无法成功处理时，系统测验重新处理该订单，以确保其终究能够被成功处理的操作。现在，大部分互联网应用都需求运用订单重试来确保订单流程的可靠性以及确保每一笔订单能够成功完结。
订单重试关于现代互联网应用系统来说至关重要。一旦订单丢掉，客户或许无限期地失去服务，并形成可怕的负面影响，如恶评和负面评价，从而导致公司的形象和事务受到影响。订单重试能够确保顺利完结买卖，维护公司的事务利益，并进步客户的满意度，增强用户对公司的信任感。一旦呈现掉单，就得从日志或许数据库等数据源获取订单数据，进行重试调用发货。而本文旨在将这一进程做到主动化，尽量确保订单能够终究完结。
面向场景
订单重试并不局限于充值发货这个场景，还有其它涉及到权益发放的都合适，比方活动发放礼包、代金券，玩家充值添加VIP积分等。
怎么做
-
常见的重试计划会有根据数据库如mysql，还有音讯行列如Kafka
-
数据库灵活性高，能够经过订单状况，找到要重试的订单来完成重试功用；可是缺点也比较显着涉及扫表，表里会包含要发货的记载和成功的记载，跟着时刻推移，数据越大，且扫表频率高，功用也会更差；
-
行列尽管灵活性不高，不像数据库能够进行筛选，可是功用好，行列的数据都是要处理的，只管发货就行；而要完成重试的功用，能够运用到推迟行列
那咱们如何结合二者的优势，来完成一个可用性、容错性高的订单重试功用，咱们以一个最初的订单发货功用进行改造
不论是什么渠道，只需涉及到钱，都会有充值发货功用，比方游戏内道具购买、电商购物。而37手游作为一个发行渠道，并不会发生本质的游戏内容比方钻石或元宝，渠道主要是对接不同的游戏，如小小蚁国、斗罗大陆、云上城之歌等。当玩家充值后，调用游戏服务的发放接口，比方游戏钻石和元宝等。咱们以安卓付出的流程为例子，输出一个简易模型来表达这一个流程
- 玩家下单，挑选付出方法充值，等待游戏发货。而渠道给玩家创立订单，等待付出渠道回调告诉充值成果，然后给玩家发货。
- 游戏翻开收银台
- 玩家挑选付出方法如微信，进行充值后等待到账
- 付出渠道微信收到账后，进行回调给37手游渠道
- 渠道收到回调后履行发货
行列计划：
一般的，在发货环节咱们会有不少查看，等一系列校验经过后才履行真正的发货。关于发货来说，并不需求做到非常实时，事务是能够接受准实时或许更晚，只需能确保最后有发货即可，所以一般发货会采纳异步发货，这也能减轻web接口的压力。
那发货的最初始版别就出来了，咱们只需将待发货的数据入到行列，由脚本消费处理调用发货服务即可。
抱负状况，这彻底能够稳定跑很长一段时刻，可是现实往往会有很多意想不到的问题，比方某款游戏反常、发货服务反常无法正常呼应、设备毛病、宕机等等。
当发货服务反常状况下，咱们需求对订单进行重试，假如幸运的话，服务没彻底挂掉，立刻又康复了，咱们失利后再调一次就成功了。可是呢，服务往往是一段时刻内都是无法重试成功的，而且一向重试也会给服务带来压力，或许康复一点点就被流量打挂了，需求给它时刻康复。所以当遇到失利后，咱们不要立刻重试，而是推迟重试，由于有时分有反常的或许有多款游戏，假如大家都是隔1分钟就重试，就会抢占资源乃至导致自身服务负载高。正确的做法是跟着重试失利次数变多，推迟重试的时刻也变长。比方前三次失利后，都是隔1分钟后再试，而第四次失利后，隔5分钟后再试。这样关于游戏服务和自身服务来说都能够防止持续的压力，也能确保音讯不丢。
当时市面上主流的推迟行列是 rabbitmq，需求装插件才能运用，还有rocketmq。而咱们公司运用的mq产品包含 rabbitmq、kafka、redis。咱们只能从这三者选，redis不支持ack机制，会有丢音讯的或许，所以抛弃。尽管rabbitmq有支持，可是需求装插件升级版别，而且rabbitmq的音讯是放在内存的，当流量大的状况下或许会触发限流，稳定性不如Kafka。那Kafka又没有供给推迟行列的功用，咱们怎么办呢？咱们挑选了开源的推迟库，运用Kafka作为行列，由推迟库来操控音讯什么时分消费，以及音讯失利处理主动升级推迟处理，详细可参考github.com/wsqun/go-de…
流程：
-
付出回调音讯入Kafka行列
-
实时发货脚本消费到音讯后，调用发货服务
-
假如发货失利，则运用推迟处理库将音讯投递到Topic1
-
推迟处理脚本从Topic1消费到音讯后，隔1分钟后调用发货服务，失利则持续改变直到重试次数悉数用完
运用Kafka作为音讯行列留意：
-
无法直接经过添加消费脚原本进步发货速度。由于Kafka是分区办理的，一个分区只能被一个消费者处理，比方发货的音讯Topic只有一个分区，即便你开了两个进程消费，也只会有一个进程能够消费到数据，不像redis能够不断添加消费者来进步消费速度。所以假如想供给发货的速度，应当将Kafka对应的topic分区数添加，调整分区记住及时添加消费者，防止没消费新的分区; 假如不希望添加太多分区，也能够考虑进程内做并发，比方编程言语Go，拉到一个分区的音讯后分发到N个协程，提条件交offset，拉取下一批数据，要留意监听退出信号确保进程的音讯能够处理完，不然重启就会到导致没发货。所以能够看出咱们是抛弃了ACK，极点状况下有或许导致音讯丢掉。当然呈现这状况也不是无计可施，咱们能够经过位移重置来康复，条件是要做好幂等，不能重复发货，也能够经过其它数据源康复，下面计划介绍；
-
装备的推迟时刻不宜过长，不要超越客户端设置的音讯处理时刻，假如超越或许会导致Kafka以为消费者有反常，进行重平衡而导致音讯重复消费，当然关于重试来说，多重试一次问题不大。建议是要在逻辑里约束重试的次数，不然有或许会重试很屡次，比方能够约束在某个时刻点（一个小时后），就不再重试；也能够记载下重试次数，不过需求额外去记载，下面计划介绍。
行列+Mysql计划：
上面重试解决了外部服务反常带来的影响，那相对的，内部反常是否会影响当时架构的稳定性。答案是肯定的，当时架构很显着的一个问题便是强依靠Kafka，假如Kafka自身呈现反常会直接影响后续的发货，相当于所有鸡蛋放在一个篮子里。
那解决计划也很容易想到，做数据冗余，与行列相得益彰。多一个mysql表记载行列的数据，一起也有状况流转（待发货、发货失利、发货成功）。发货的音讯不仅会入行列，也会写mysql记载状况为待发货状况，脚本实时处理行列音讯，将发货成果更新到mysql记载状况，
别的的脚本守时批量获取待发货、发货失利的记载进行补发处理，这样即便Kafka呈现反常，也能经过扫表的方法补偿，有点类似于事务的最大努力告诉机制。而且多了mysql记载咱们能够更直观的看到音讯发货的健康状况，能够知道哪一类的音讯发货失利。
流程：
-
付出回调音讯入mysql 和 Kafka行列，留意互相独立，入mysql失利不影响入kafka行列，mysql写入的状况是待发货
-
获取待发货音讯
-
行列的脚本流程与上面一致，区别是履行完发货后，会把发货成果记载到mysql，假如发货失利照样会入到推迟行列
-
mysql作为辅佐，会查看记载的状况。会有两个守时脚本进行查看
-
找出待发货的记载，履行发货流程，将发货成果更新为成功或许失利状况，失利次数+1
-
找出失利记载，履行发货流程，将发货成果更新为成功或许失利状况，失利次数+1
-
-
下面为表记载的状况信息例子，
- 待发货+成功的订单截图：
- 失利后在进行重试的订单截图（记载里面还包含了失利的详细原因还有traceid，traceid能够方便咱们快速定位其时整个发货周期内发生的相关日志，能够快速定位问题）：
- 重试后成功的订单截图：
那么关于上面行列计划说到留意点1，当极点状况导致音讯丢掉，咱们能够知道mysql里没发货的记载，捞出来履行发货确保终究不丢即可；而留意点2约束最大重试次数，便是经过记载的失利次数，由于每次失利都会+1，这样当发现达到某个阈值，那就不再入推迟行列。
运用细节：
关于查看未发货状况的守时脚本，并不是直接拉悉数的记载，而是拉一段时刻的，比方曩昔一天到曩昔1分钟的时刻段，那为什么不是当时时刻呢？由于会跟实时的发货脚本功用重合，假如拉当时时刻的话，那么当一个音讯一起入到行列和数据库，会被两头一起消费到处理，其实就浪费资源了，咱们数据库是做为一个辅佐的手段，不是来跟行列抢夺的，不需求两个相同的人物；那咱们操控了是曩昔1分钟时刻段来拉音讯了，当咱们拉到音讯后对其进行发货处理后，还不能直接就完毕了。由于脚本能拉到音讯，就阐明你的发货已经是呈现推迟了，这时分假如退出了，那下次查看便是1分钟后了，那又有一批玩家付出推迟到账了，这体验是很不好的。应该持续查看是否还有未发货的记载存在，这时分就不是拉曩昔1分钟前的了，而是主动调整为比方5秒前的。别的还要考虑这批音讯要不要并发处理，关于咱们渠道来说，发货是依靠不同的游戏服务，假如是顺序履行的话，只需呈现呼应慢了就会导致推迟。所以咱们是运用Go做并发处理，同个进程拉到一批音讯后就并发处理，立刻就去拉下一批音讯，这时分就要留意不能拉到上一批音讯，由于上一批音讯还在处理中，所以咱们在select时分，会把上一批音讯的最大ID作为查询条件，要大于这个ID的音讯。
关于查看发货失利状况的守时脚本，最重要的便是要设置重试最大次数和时刻规模，不能一向重试下去。然后不是拉出所有契合条件的，而是约束行数，由于失利的记载或许很多，而且实时性要求不会太高，能够拉一批处理，再根据ID规模拉下一批。别的便是重试的最大次数是能够配的，比方作为脚本发动时分的参数，由于有时分服务会毛病很长时刻，就容易抵达重试次数上限，当服务康复后就会需求再重试一次，这时分只需改下最大重试次数就能够了。
前面咱们也说到了mysql有个不好的地方便是扫表耗功用，那咱们这个表作为一个音讯事情记载，咱们能够定期对表进行删除归档防止变成一个大表，比方只保留最近3个月的记载。关于表的结构也要做好设计，比方日期索引便是必须的，也能够考虑案日期作分区，乃至换一个功用更优的分布式数据库。别的还能够把查询变成有状况的，以查看未发货状况的守时脚本为例，在扫表前把最大的ID获取到缓存起来，下次发动就select条件添加id>?的条件，速度就能够提高很大；查看发货失利状况的脚本也是能够用相同的思路去提高功用。
前面讲的都是发货反常导致的发货减少，但也别忘了发货自身要做好幂等和并发锁，不能由于重试或许多个脚本在调用发货就呈现了多发。
监控
那咱们已经做了这么多了来确保发货不会掉单和推迟，那是不是就能够高枕无忧了呢？答案显然不是！总会呈现一些问题不被上面计划覆盖到，那或许又是一个毛病。那毛病的等级来自于毛病的规模和时刻，那规模咱们很难操控，由于毛病便是发生了，咱们很难阻挠一个未知的毛病发生，能知道也不会有毛病一说了。咱们能做的便是提前发现它，缩短毛病的时刻。
关于咱们的订单重试功用，咱们要能及时知道它当时的状况，不然你只能知道你的脚本在运转着，而不知道它跑的正不正常（不知道推迟正在发生、不知道补单尽管有在补但一向失利）。只有知道了这些，咱们才能采纳下一步的动作来防止毛病扩大。假如咱们能知道推迟了，咱们就能够考虑添加进程数，进步并发能力；知道补单一向失利了，咱们就能反应给下流服务进行查看。
- 推迟消费监控
监控Kafka消费推迟数
- 发货失利，补单监控
- 反常日志监控
除了技能工具来及时发现还是有或许没覆盖到的，只能一向去完善。咱们还要借助舆情的力量，要关注是否有玩家反应反常，由于玩家是最直接感受到毛病的，因此有收到反应，要及时反应出来，能够建立一个专门反应毛病的群，客服有收到相关的音讯就及时发布出来。
综上所述，37手游采纳的计划是
Kafka音讯行列 + Mysql音讯状况 + (Grafana+Prometheus)/日志监控
一共有四个脚本：
- 实时处理事务发生的订单数据，成功/失利就更新Mysql音讯状况，失利则入推迟行列
- 推迟处理失利的音讯，进行重试
- 1分钟守时Select出Mysql音讯为待发货的记载，假如无音讯就退出，有则处理发货而且循环查看是否还有记载，直到无记载才退出，确保不会呈现推迟到账
- 1分钟守时Select出Mysql音讯为失利的记载，进行重试
脚本做到装备化/参数化，可灵活调整重试次数、并发约束、时刻规模；
监控要全不能遗漏，内部（自己开发的脚本，其运转状况+消费速度；依靠的数据源Kafka推迟状况+Mysql表功用状况）+ 外部（舆情反应）
