Hello，大家好，我是小黑哥~ 前端时间小黑哥在公司接手了一个支付项目，这个项目接入了微信、支付宝。这个项目开发下来，小黑哥可是完完整整体验了一下微信、支付宝开发流程，也踩了一些坑。 最近正好看到有些小伙伴想接入微信、支付宝，但是不知道如何开发，所以小黑哥就给大家总结一下微信支付、支付宝接入开发流程。 总体流程 明确使用支付方式 首先我们需要明确我们需要使用的支付方式。 因为微信支付、支付宝中存在很多支付方式，不同支付方式对应的不同的业务场景，开发对接复杂度也不太一样。 以微信支付举例，其总共提供如下几种的支付方式。 这几种支付方式对应的不同的业务场景，比如说： 付款码支付：商家使用扫码枪或其他扫码机具扫描用户出示的付款码，适合于线下商超收款 Native支付：商家在系统中按微信支付协议生成支付二维码，用户扫码拉起微信收银台，确认并完成付款 JSAPI 支付：用户在商家公众号内下单，输入密码支付，完成支付，适合于在线购物的场景 APP 支付：用户在商家的APP中下单，跳转到微信中完成支付，支付完后跳回到商家APP内，展示支付结果 H5 支付：用户在手机浏览器中下单，然后跳转到微信.... 微信支付、支付宝最全接入指引，看完立刻就可以上手！ 支付系统
封面送给我狗哥，今天终于大结局了！可伶我钦哥，这么惨了，最后还要把他写没了！！ Hello，下午好，我是楼下小黑哥~ 今天的文章我们接着上次的话题，继续聊聊支付系统异常解决办法。 在上篇文章中「支付掉单异常解决方案」，我们主要提到的是支付过程中掉单的场景，用户明明付款成功，银行卡都扣款了，但是订单却还显示待付款。 而在今天的文章中，我们将聊到重复付款的异常，即同一笔订单，扣了用户两笔钱。 另外我们还将会提到另外一种异常，用户扣款成功，但是订单却支付失败的场景。 以上两种异常对于被扣款的用户来讲，使用体验极差，自己多付了钱，订单却还不成功。所以如果不及时处理这两类异常，那就真的等着被投诉吧。 重复付款异常 异常场景 重复付款异常一般常见于网银支付，微信支付，支付宝等这类需要跳转到一个支付网关页（网银支付），或者跳转到钱包 APP(支付宝、微信)，从而异步完成扣款的支付场景。 这种支付场景下，只能通过接受异步通知才能知道支付结果，我们一般将其称为异步支付。 PS：有了异步支付，那么同步支付是什么？ 其实同步支付指的就是调用支付接口之后，就可以立刻返回支付结果的，比如银行卡类快捷/代扣等.... 一笔订单，但是误付了两笔钱！这种重复付款异常到底该如何解决？|原创 支付系统
小黑碎碎念 Hello，大家好，我是楼下小黑哥~ 这个长假不知道大家玩的开心不？有没有出去玩就被堵在路上的？ 哈哈，这个长假，我过的还是有点累( Ĭ ^ Ĭ )。 长假前两天都在加班迁移旧系统的历史数据，由于这个依赖我同事那边的迁移进度，所以第一天其实还好，就是划划水，优化一下程序，晚上还出去看了下『姜子牙』。 第二天的时候，又划了一天的，等到晚上的时候，同事终于把他那边的迁移搞定，我终于可以开始迁移。 可是这个时候甲方爸爸竟然开始加各种需求了，没办法，只能满足他们，临时再开始修改程序，然后再加上监控，一直搞到了12 点。 搞完这下，本来以为没啥幺蛾子了，长假只要每天看看迁移进度就可以了。 哎，没想到设计的时候忘记考虑性能的问题，等到数据量增长到千万的时候，查询速度奇慢，无奈只好优化程序，想办法让查询加快，最后一直搞到了凌晨四点 ┭┮﹏┭┮ 真的是设计不规范，加班两行泪啊~后面有机会跟大家复盘一下这次大数据量迁移。 前言 好了，回归到今天的主题，今天分享一下支付系统中异常一些处理方式。 其实这些处理方式并不只是局限于支付系统，也可以适用于其他系统，大家可以借鉴，应用到自己系统中，提高.... 有更新！ 钱被扣走了，但是订单却未成功！支付掉单异常最全解决方案 架构设计
上次的文章手机没网了，却还能支付，这是什么原理？发布之后，没想到大家都比较感兴趣，所以反响还不错。 另外这篇文章还被码农翻身公号改编成漫画漫画：如何盗刷别人的支付宝？,嘿嘿不得不说，还是刘欣老师讲解的更加清晰明了。 现在这篇文章阅读数据已经破千，虽然对于其他号主来说还是很少的数据，但是对于我来说，真是第一个里程碑，期待后面越来越好~ -------------------------我是分割线------------------- 好了，不 BB 了，今天跟大家分享一下聚合收款码的支付原理，这也是我这大半年来一直在做的项目。 微信/支付宝收款码大家应该不会陌生，线下小微商户收款大多使用这个，就比如下图。 这种收款方式很方便，微信、支付宝后台申请开通，然后还可以免费申请相关物料。 不过这种方式用户体验其实不是很好，之前有好几次拿出支付宝，却扫了微信支付码。 另外，这种个人的收款码通常还有单日收款的上限，比如支付宝单日上限 500元。 有了需求，自然会有聪明人人想到解决方案，于是有了聚合收款码产品解决方案,如下图。 一个收款码，支持多种客户端,主流是微信、支付宝，现在常见还会支持银联，.... 有更新！ 收款神器！解读聚合收款码背后的原理|原创 支付系统
Hello，大家好，我是鸭血粉丝~ 最近看同事的代码时候，学到了个小技巧，在某些场景下非常挺有用的，这里分享一下给大家。 Spring 中 @Autowired注解，大家应该不会陌生，用过 Spring 的肯定也离不开这个注解，通过这个注解可以帮我们自动注入我们想要的 Bean。 除了这个基本功能之外，@Autowired 还有更加强大的功能，还可以注入指定类型的数组，List/Set 集合，甚至还可以是 Map 对象。 比如说当前应用有一个支付接口 PayService,分别需要对接支付宝、微信支付、银行卡，所以分别有三个不同实现类 AliPayService,WechatPayservice,BankCardPayService。 四个类的关系如下图所示： 如果此时我需要获取当前系统类所有 PayService Bean，老的方式我们只能通过 BeanFactory或者 ApplicationContext 获取。 // 首先通过 getBeanNamesForType 获取 PayService 类型所有的 Bean String[] names = ctx.getBeanN.... 巧用 Spring 自动注入快速实现策略模式 Spring
今天小黑哥来跟大家介绍一下 Redis 发布/订阅功能。 也许有的小伙伴对这个功能比较陌生，不太清楚这个功能是干什么的，没关系小黑哥先来举个例子。 假设我们有这么一个业务场景，在网站下单支付以后，需要通知库存服务进行发货处理。 上面业务实现不难，我们只要让库存服务提供给相关的给口，下单支付之后只要调用库存服务即可。 后面如果又有新的业务，比如说积分服务，他需要获取下单支付的结果，然后增加用户的积分。 这个实现也不难，让积分服务同样提供一个接口，下单支付之后只要调用库存服务即可。 如果就两个业务需要获取下单支付的结果，那也还好，程序改造也快。可是随着业务不断的发展，越来越多的新业务说是要下单支付的结果。 这时我们会发现上面这样的系统架构存在很多问题： 第一，下单支付业务与其他业务重度耦合，每当有个新业务需要支付结果，就需要改动下单支付的业务。 第二，如果调用业务过多，会导致下单支付接口响应时间变长。另外，如果有任一下游接口响应变慢，就会同步导致下单支付接口响应也变长。 第三，如果任一下游接口失败，可能导致数据不一致的情况。比如说下图，先调用 A，成功之后再调用 B，最后再调用 C。.... Redis 发布订阅，小功能大用处，真没那么废材！ Redis
哎，最近小黑哥又双叒叕犯事了。 事情是这样的，前一段时间小黑哥公司生产交易偶发报错，一番排查下来最终原因是因为 Redis 命令执行超时。 可是令人不解的是，生产交易仅仅使用 Redis set 这个简单命令，这个命令讲道理是不可能会执行这么慢。 那到底是什么导致这个问题那？ 为了找出这个问题，我们查看分析了一下 Redis 最近的慢日志，最终发现耗时比较多命令为 keys XX* 看到这个命令操作的键的前缀，小黑哥才发现这是自己负责的应用。可是小黑哥排查一下，虽然自己的代码并没有主动去使用 keys命令，但是底层使用框架却在间接使用，于是就有了今天这个问题。 问题原因 小黑哥负责的应用是一个管理后台应用，权限管理使用 Shiro 框架，由于存在多个节点，需要使用分布式 Session，于是这里使用 Redis 存储 Session 信息。 画外音：不知道分布式 Session ，可以看看小黑哥之前写的 一口气说出 4 种分布式一致性 Session 实现方式，面试杠杠的~ 由于 Shiro 并没有直接提供 Redis 存储 Session 组件，小黑哥不得不使用 Github 一.... 血的教训!千万别在生产使用这些 redis 指令 Redis
最近在学习 Redis 相关内容，为此买了两本关于 Redis 的书籍，一本为 「Redis 设计与实现」，另一本为 「Redis 开发与运维」。 目前大概看了一半，个人聊聊两本书籍的的区别。 第一本 「Redis 设计与实现」，这本书主要偏重与底层原理，本书大部分内容都是从底层 C 语言代码介绍，再结合大量插图的讲清楚其中技术点。 这样的优点在于从源码出发，可以很深刻的理解其中设计实现点，另外还可以偷学一波大佬们的代码。 第二点，对于有些原理，直接从代码理解，可能很不好弄懂，不过通过插图方式，一下子就能看懂。 再来说说这样的缺点，对于没学过 C 语言的，或者说只接触过 Java 的同学来讲，这样直接从 C 语言看起真的很难。 还记得个人两年前就同事那里看过这本书，刚看第一张，就被劝退了。 密密麻麻的 C 语言，看的真的头疼！ 不过随着自己编程经验越来越丰富，现在再来看这些 C 语言代码，已经没有那么费劲。 不知道大家有没有发现，以前有些看不懂的原理知识，有些觉得很难的原理，随着编程经验越来丰富，渐渐都明了了，都能看懂了。 所以有些东西如果在你这阶段真的看不懂，那就不要纠结，适当放弃.... 这两本 Redis 书籍，真经典！！ Redis
最近，小黑哥的一个朋友出去面试，回来跟小黑哥抱怨，面试官不按套路出牌，直接打乱了他的节奏。 事情是这样的，前面面试问了几个 Java 的相关问题，我朋友回答还不错，接下来面试官就问了一句：看来 Java 基础还不错，Java HashMap 你熟悉吧？ 我朋友回答。工作经常用，有看过源码。 我朋友本来想着，你随便来吧，这个问题之前已经准备好了，随便问吧。 谁知道，面试官下面一句： 那好的，我们来聊聊 Redis 字典吧。 直接将他整蒙逼。 小黑哥的朋友由于没怎么研究过 Redis 字典，所以这题就直接回答不知道了。 当然，如果面试中真不知道，那就回答不了解，直接下一题，不要乱答。 不过这一题，小黑哥觉得还是很可惜，其实 Redis 字典基本原理与 HashMap 差不多，那我们其实可以套用这其中的原理，不求回答满分，但是怎么也可以得个及格分吧~ 面试过程真要碰到这个问题，我们可以从下面三个方面回答。 数据结构 元素增加过程 扩容 字典数据结构 说起字典，也许大家比较陌生，但是我们都知道 Redis 本身提供 KV 查询的方式，这个 KV 就是其实通过底层就是通过字典保存。 另外，.... 阿里面试官：HashMap 熟悉吧？好的，那就来聊聊 Redis 字典吧！ Redis
小黑十一点半