自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(52)
  • 收藏
  • 关注

原创 支付网关设计-1

支付网关系统设计

2022-10-16 00:05:41 928

原创 监控系统-1

支付系统监控系统

2022-09-25 01:00:11 829

原创 Canal 架构解析水文

提示:本篇使用Canal 完成数据同步功能文章目录前言 一、pandas是什么? 二、使用步骤 1.引入库 2.读入数据 总结前言提示:这里可以添加本文要记录的大概内容:例如:随着人工智能的不断发展,机器学习这门技术也越来越重要,很多人都开启了学习机器学习,本文就介绍了机器学习的基础内容。提示:以下是本篇文章正文内容,下面案例可供参考一、pandas是什么?示例:pandas 是基于NumPy 的一种工具,该工具是为了解决数据分析任.

2022-05-26 19:43:45 607 1

原创 基于数据库的分布式唯一ID生成

前言提示:本篇内容是基于数据库方式生成唯一Id代码案例,通过自定义starter,组件式开发,引入直接使用,避免重复造轮通过实例代码你能学到什么:基于数据库生成唯一Id(号段模式)自定义start包Spring后置处理器的扩展CAS无锁机制日常工作中,使用Mysql时候,数据表主键我们通常使用数据库自增方式,但是当我们使用sharding-jdbc或Mycat等方式分表后如何保证多个表主键的唯一性?实现方式有很多,最长用的有雪花算法(你不觉得这个生成的主键太长了吗?主键一般和业务无关,有

2022-05-10 21:48:10 630

原创 分布式限流设计一:并发数限流

在开发高并发系统时有三把利器用来保护系统:缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量;而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开;而有些场景并不能用缓存和降级来解决,比如稀缺资源(秒杀)、写服务(下单),因此需有一种手段来限制这些场景的并发/请求量,即限流。限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求量进行限速来保护系统,一旦达到限制链接数、速率则可以拒绝服务、排队等。高并发系统常见的限流主要有:限制并发数

2021-12-05 21:29:55 1502

原创 数据迁移设计

一、背景随着交易系统线上运行,交易实时表数据不断增加,当订单已经处于终态,在对完账后应该及时进行数据迁移,保证交易实时表数据量不宜太大。二、分析设计1.分析数据迁移有很多方式,我们来说如果让开发自己在业务系统里定时进行数据迁移应该怎么办。从实时表将满足条件的数据迁移到历史表中,首先要考虑待迁移的数据量,如果不考虑每次符合迁移条件的数据量,直接一个sql:select-->insert 从实时表查询出来满足条件的数据,直接插入历史表,那就等着出事故吧,其次是数据量大的话怎么进行数据分..

2021-11-28 01:48:29 670

原创 支付路由系统设计三:命中-1

当使用纵向扩展方式,同时使用Drools规则引擎和Velocity模板引擎结合使用来组织这些规则条件,难度等级上了不止一个层次了,但是这样的系统,运营使用起来会非常爽,简单的配置就可以满足业务需求了

2021-11-20 18:01:01 1306 7

原创 支付路由系统设计二:核心流程

技术栈:Java+Groovy+Lua+Springboot+Spring Data Jpa+Mysql+Redis+Drools+Velocity+RabbitMQ一、背景本篇博文,我们来片下支付系统中最重要的一个模块--路由系统,当然很多小公司的支付系统可能压根没有这个模块。先说下路由系统的作用,随着业务不断丰富,支付系统为了满足各种支付场景提供多元化的支付产品,需要对接很多银行、第三方支付机构来为业务方提供服务,随着对接的支付渠道越来越多,支付渠道的管理问题就来了,渠道规则各异,如何从对.

2021-11-20 14:43:23 2964

原创 缓存管理设计

本文主题:一、去除Redis,使用进程内缓存;二、集中缓存管理。我们在写系统时为了提高系统业务处理速度,在系统中大量使用Redis作为缓存使用,但是对于一些信息使用Reids是首选吗?我们还是以支付系统为例,对于对接的通道的一些配置信息、交易机构信息(银行),响应码转换信息等等,真的有必要上来就怼Redis里吗?对于这些信息每笔交易都会使用到,那么我们系统在运行时强依赖Redis,还是那句话,我们系统在运行时依赖的外界系统越少越好,依赖的越多,在后期运行过程系统性能瓶颈有很大可能发生在和这些系统交互上面

2021-11-14 00:21:27 2043

原创 支付交易限额设计

一、背景技术栈:Redis+Lua双十一,一个属于电商而不是属于运营商的节日,然鹅无奈还是被安排了值班,零点过后支付系统流量上升了一波持续了半小时然后稳定运行没啥问题,本着认真负责的态度还是坚持个通宵吧,不知干点为了让自己不瞌睡,想到了平时最容易失眠的方法,想业务实现,于是想了下白天产品同学的需求:增加商户维度的交易额度限制,无聊扒了下系统已经实现的渠道维度的交易限额代码,看了下.....没看完,实在看不下去了,曲线救国,绕的圈有点大,不明觉厉吧,于是自己写了下。二、分析实现1.分析.

2021-11-11 22:26:36 1920

原创 商户交易结果通知设计

流程大概如上,我们要解决的是如果我们给商户通知失败了,那么我们该怎么处理?当一笔交易发生后,支付渠道返回交易已经受理,我们也给商户返回交易已经受理,此交易流程结束,就等着接收交易结果的通知了,当渠道处理完此笔交易后调用我方交易时上送的结果通知接口将交易结果告知我方,接收到渠道交易结果通知报文后,获取到相关交易参数数据,将我方数据库中对应的那笔交易的状态改为终态,然后再将此交易结果通知给商户,商户拿到支付结果,在用户手机里展示出支付成功的页面。我们又该如何将交易结果通知给我们的商户系统呢?

2021-11-06 19:37:26 623 2

原创 批付系统设计

批付此文章我们来讲下批付系统设计,在讲批付系统之前先要理解单笔代付交易,批付也就是一次完成多笔单笔代付交易,有的公司批付系统表面是批付,实际系统将批付转成了单付,比如财务要支付100名员工报销款,批付系统一行一行读取批付文件数据请求银行100次,如果财务需求为此100笔交易只要一张回执单,那么此批付系统就凉凉了,所以批付系统咱们就设计为批付系统,不转单付。对于没有做过支付系统的小伙伴,我们先理解下什么是代付,代付也称为代发,代付交易就是委托第三方代为支付的交易,委托方从被委托单位的结算账户向持卡人指定银

2021-10-31 21:30:06 1700

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除