业务相关
文章平均质量分 91
业务相关
猎户星座。
花有重开日,人无再少年。
展开
-
支付系统高可用架构设计实战
对于互联网应用和企业大型应用而言,多数都尽可能地要求做到7*24小时不间断运行,而要做到完全不间断运行可以说“难于上青天”。为此,对应用可用性程度的衡量标准一般有3个9到5个9。对于一个功能和数据量不断增加的应用,要保持比较高的可用性并非易事。为了实现高可用,宜信支付系统从避免单点故障、保证应用自身的高可用、解决交易量增长等方面做了许多探索和实践。在不考虑外部依赖系统突发故障,如网络问题、三方支付和银行的大面积不可用等情况下,宜信支付系统的服务能力可以达到99.999%。转载 2024-02-23 16:34:23 · 66 阅读 · 0 评论 -
防重复提交
配合使用的防重复提交的实现。但是这个方案有个小弊端。仅生效于有RequestBody注解的参数,因为使用RequestBodyAdvice来实现。但是大部分我们需要做请求防重复提交的接口一般都是POST请求,且有requestBody。注解即可,interval即多久的间隔内相同参数视为重复请求。类来实现代码实现更加简洁,配置更加简单。通过在Controller上打上。这种防请求重复提交的实现有基于。最后考量下笔者认为利用。转载 2024-02-23 11:22:25 · 14 阅读 · 0 评论 -
分布式事务及常见解决方案
试想一个由两台服务器一起参与的事务,服务器A发起事务,服务器B参与事务,B的事务需要人工参与,所以处理时间可能很长。如果按照ACID的原则,要保持事务的隔离性、一致性,服务器A中发起的事务中使用到的事务资源将会被锁定,不允许其他应用访问到事务过程中的中间结果,直到整个事务被提交或者回滚。**主事务记录 Activity:**主事务记录是整个分布式事务的主体,其最核心的数据结构是事务号(TX_ID)和事务状态(STATE),它是在启动分布式事务的时候持久化写入数据库的,它的状态决定了这笔分布式事务的状态。转载 2020-01-19 19:13:30 · 2239 阅读 · 0 评论 -
交易流水号的艺术:掌握支付系统的业务ID生成指南
数据库一般都会设计一个自增ID做为主键,同时还会设计一个能唯一标识一笔业务的ID,这就是所谓的业务ID(也称业务键)。比如收单域有收单单号,支付域有支付号,渠道网关域有渠道支付号等,这些都属于业务ID。为什么有了自增ID后,还需要有业务ID呢?转载 2024-02-19 17:09:26 · 39 阅读 · 0 评论 -
支付系统的心脏:简洁而精妙的状态机设计与核心代码实现
状态机,也称为有限状态机(FSM, Finite State Machine),是一种行为模型,由一组定义良好的状态、状态之间的转换规则和一个初始状态组成。它根据当前的状态和输入的事件,从一个状态转移到另一个状态。下图就是在《支付交易的三重奏:收单、结算与拒付在支付系统中的协奏曲》中提到的交易单的状态机。从图中可以看到,一共4个状态,每个状态之间的转换由指定的事件触发。转载 2024-02-19 17:03:41 · 103 阅读 · 0 评论