苹果支付的一些问题
1.苹果支付的传递只能通过app本身传递，存在了很多的不确定性，在应用崩溃等情况时，会丢失订单号
2.传输问题，app客户单的网略情况没有服务器的传输稳定，在网络波动的情况下，会出现接收不到验证信息的情况
3.服务器向苹果验证时的网络问题，这里概率不是很高，但是偶尔也是有的，验证会有超时等等的现象
4.苹果服务器返回问题，偶尔存在服务器返回的时候，丢失了一部校验数据
5.订单返回商品存在多个订单的商品信息，连续多次下单或者曾经订单处理不及时的情况下，苹果会存在合并订单的情况
针对苹果订单的一些处理
1.对于丢失订单号的情况，需要针对用户本身获取相应订单，验证订单商品一致，对商品等校验后，将相应权益给到用户账户
2.保证重试，这里有两个地方，app与服务器之间的重试，服务器与苹果服务器之间的重试。
与app协定重试策略，让app添加定时器，每隔一段时间重试一次，并有一个最终重试机制。超过最终重试之后，每次app打开的时候验证向服务端验证等。
服务器验证方面则需要在网络错误的情况下记录到库，后续去做重试操作，最好标记次数等。
3.苹果存在合并订单的情况，需要去查询用户购买的相关产品，做好产品编号和交易号的校验，进行异步补偿处理。（ps:谁也不知道接手的项目之前卖过什么类型的商品）
事务问题
订单情况下，事务问题有时候排查起来比较困难，特别又涉及了分布式调用情况。
1.事务拆分，尽量不要在订单流程中使用大事务，如果有大事务，尽量拆分到不同的小事务
2.事务引发的脏读问题，因为事务本身具有隔离性，当事务没有提交的时候，会导致读取的情况不一样，
在订单的强一致性下，这样的情况显然不能接受。可以在拆分细的事务后，使用高可用消息中间件，解决最终一致性问题
缓存问题
在和订单相关的服务调用的时候容易产生，特别在和事务的情况融在一起时，就更加复杂。我刚接手代码的时候，很多地方的写法都排除了这样的况，导致问题出现频繁，但是对于缓存的情况，并没有通用的解决方案，只能在相应的情况下做出处理。
异步化问题
1.异步是个通用的解决模型，能通过异步消息解决很多问题。比如账户和订单之间。
这里要说的是异步化不要在事务中进行，我早期接手代码的时候，发现很多消息竟然是嵌入在事务里面的，
这里就为消息本身带来很多不确定性，发送应该在事务完整结束之后。
幂等
保证幂等是基本要求
分布式问题
需要处理好对于分布式相关的调用问题，以及分布式锁使用的情况
订单情况排查
日志入库：相应的关键位置的日志应该入库操作，毕竟是涉及用户金钱的，相关位置还是要记录一下的
报警：接入相应的监控，当出现问题时，可以及时的处理，不造成损失扩大
这里具体的方案应该每个公司都会有一些相应的基础设施，可以对接相应的部门获取，如果是一些创业型公司，可以用db、邮件服务等再相关位置做发送也是可以的。