浅析支付平台数据正确性保证

支付平台必须保证数据正确性，保证数据并发安全性，保证数据最终一致性。数据一致性场景大致可以分为弱一致性和强一致性，所谓的弱一致性，就是有可能在某个时刻数据非一致，但是到达某个时间点以后总能保持一致，也即我们所说的最终一致性。 而强一致性就是需要保证数据的一致性是实时的，每一时刻都保持一致。我们支付平台通过如下几种方式来保证数据一致性：

•分布式锁

这个比较容易理解，就是在操作某条数据时先锁定，可以用redis或zookeeper等常用框架来实现。比如我们在修改账单时，先锁定该账单，这样如果该账单有并发操作，后面的操作只能等待上一个操作的锁释放后再依次执行。 分布式锁的优点是能够保证数据强一致性，但是高并发场景下可能有性能问题。

•消息队列

消息队列是为了保证最终一致性，我们需要确保消息队列有ack机制，客户端收到消息并消费处理完成后，客户端发送ack消息给消息中间件，如果消息中间件超过指定时间还没收到ack消息，则定时去重发消息。比如我们在用户充值完成后，会发送充值消息给账户系统，账户系统再去更改账户余额。消息队列的优点是异步、高并发，缺点是有一定延时、数据弱一致性，并且必须能够确保该业务操作肯定能够成功完成，不可能失败。比如充值，收到钱后业务上来讲就是代表充值成功了，用户余额延迟几秒更新没有影响，因此可以采用消息队列异步更新余额。

•TCC模式

TCC模式把操作分成 Try-Confirm-Cancel三阶段，只要Try成功了，Confirm一定会成功，采用类似于两阶段提交的方式来确保数据一致性。比如我们用户支付时，用户可能会同时采用会员卡和微信支付，而微信支付依赖于第三方系统，我们用TCC模式来确保微信支付成功后会员卡消费肯定能成功。具体来说就是在调起微信支付时，我们先Try一下，把用户会员卡冻结某笔金额，微信支付成功后，我们再Confirm一下，核销会员卡冻结的钱。TCC的优点是数据强一致性，缺点是引入了中间状态和操作，不一定所有的业务都可以支持。

•对账系统

对账系统是最鲁棒的技术，最适用于财务系统。对账贯穿整个支付流程，资金流和数据流在各个系统中的流转都会通过对账来核实。优点是鲁棒性强，基本适合任何场景，缺点是延时比较多，如果对账有差异，需要人工介入处理。

•多版本并发控制（MVCC）

也就是我们常说的乐观锁，在用户数据上加一个版本号，每次更新前都先取出版本号，更新时先比对版本号，版本号一致才更新并把版本号加一。优点是性能高，缺点是高并发场景下更新可能失败，需要重试。

•补偿事务

先操作，如果操作失败再补偿。比如我们用户提现，再申请提现时直接从用户账户余额中扣除该提现金额，然后再调用三方系统去提现，如果提现最终失败，我们再把该扣除的余额给用户补上。优点是非常简单，缺点是不一定所有的业务操作都可以补偿，只能实现数据弱一致性。