金融分布式架构需要关注的几个问题

Posted 2021-04-14 金融科技小站

金融系统相对于一般的软件，对数据的可靠性和一致性要求更高。而在互联网时代，面对大数据量、高并发的交易请求，分布式架构成为一种较优的选择。

幂等

幂等是指任意多次执行所产生的影响均与一次执行的影响相同，即相同的交易请求多次，只处理一遍，不能重复处理，并且每次请求拿到的结果与交易的结果保持一致。一般的幂等设计会基于流水号或联合主键进行唯一性判断，例如通过数据库的唯一性约束进行幂等控制，每次请求时先进行唯一性约束校验，如果通过了则继续处理，如果没通过则说明已经存在了相同的交易，则此时需要根据唯一性条件查出已经存在的交易，并返回该交易的结果。

并发

在分布式系统中，对于外界的请求是不可预知的，同一笔交易可能重复发送多次，也可能相同的交易同时到来，而且请求每次可能访问不同的机器，而在程序处理过程中可能要经历多个阶段，不同的线程或机器同时处理同一笔交易时，其各阶段执行的次序也可能是参差不齐的；此外不仅需要考虑单个系统的请求及处理并发，一份数据可能会被多个系统处理，当数据处于某个中间终态时被其他系统并行消费也需要关注。

解决并发问题，一是在必要的阶段进行幂等控制，幂等控制越靠前，后面的处理就越容易，但如果因为某种特殊的原因，在幂等控制前仍有一部分逻辑需要处理，则需要重点考虑此部分在并发时是否会产生问题。处理时可考虑在幂等前的逻辑是否与时序有关，如果有关就需要幂等前输出的结果做到一致性，或者幂等后可以对前面的数据（可能是内存的数据或者DB中的数据）进行修复。

时序

交易需要有序的处理，例如需要先付款再退款、先有交易再查询交易结果。但实际的请求可能是无序的，例如某个阶段付款还没收到或还在处理中，但退款的请求已经处理到下一阶段了；外部系统先发送的交易请求，紧接着又发送了查询请求，但由于种种因素（例如做了异步化或者中间的某个系统卡主）后端系统先收到的查询请求并返回了交易不存在，之后交易请求又来了。

此时，有几种设计方式可规避此问题，例如：

• 通过幂等控制：在查询或退款时，如果发现原交易不存在则保存幂等，之后原交易的请求到来时会写入幂等异常，以此来保证处理的结果一致性；

• 基于原交易流水号：收到付款请求后生成服务端的流水号，之后的退款或查询时要求外部基于服务端的流水号进行操作。此时，如果请求端原交易发送时掉单则无法收到原交易流水号，因此请求端掉单时需要重发，在服务端做好幂等控制即可；
  

• 基于版本控制：例如配置推送系统，很多时候追求的是最终一致性，即每次收到请求只处理大于本地版本的数据，对于小于等于本地版本的请求则直接丢弃；

异步

异步设计提升了系统的稳定性，节省了系统的性能，但也造成了本地线程的增多，增加了CPU上下文切换的开销，但最重要的是异步之后，线程的处理次序就变得不再可控，因此异步后需要仔细分析系统是否存在时序或者相互依赖的问题。

事务

在分布式系统中，一般会采用分库分表设计，此时需要考虑操作的数据是否在同一个DB，如果不在同一个DB就可能导致遇到错误无法有效的回滚。此时在设计时需要尽量能把相关的交易落到一个库中，如果不能就需要考虑分布式事务或补偿等控制。

自我恢复

系统的处理必然会经历多个阶段，可能会产生各种的问题，例如DB抖动、RPC调用时网络抖动等等，在分布式中这种情况可能还很常见。因此设计时需要考虑必要的容错机制，系统需要尽量使用异步交互，并且具备自我发现自我恢复的能力。

超时时间

一般超时时间的设计是在交易发起方发起请求时带上时间戳，接收方接收到交易后判断当前时间与请求时间的时间差，如果大于一定的时间则直接丢弃或置为失败。另一种超时时间思想的变种是关单模式，关单本质上是一种业务模式，一般会设定一个关单时间，当达到一定时间后还没有到达终态则自动关单，之后各方以关单的状态为准，而这种关单的决定权往往掌握在进行账务清算处理的一方。

防止脏读

对于防止脏读，仅举一类例子，在金融系统交互过程中，很多时候是基于文件的，为防止在文件写的过程中被消费的一方读取，导致消费方读取的数据不完整的问题，可采用如下几种方式设计：

• 写文件时使用临时文件名，当文件写成功后修改为最终文件名；

• 基于文件锁控制并发，无论是写文件的一方还是读文件的一方，当需要操作文件夹下的目录时先判断文件锁是否存在，如果存在则过一段时间后再来检查，如果不存在则先生成一个文件锁，处理完成后删除文件锁；

• 基于通知接口方式，写文件的一方随机生成文件名，当文件写成功后通过通知接口告知接收方，接收方根据接口中的文件路径（含文件名）读取文件。
  

相关文章