午饭吃什么

1、问题描述 前段时间把生产的支付结果通知改为使用 HttpAsyncClient 之后，虽然没出现生产事故，可事情也并没有想象中的那么简单。观察日志我们发现每天都存在一些（随着交易量变化的） 获取

起因 618 当天有客户反馈交易成功异步通知延迟很高，部分单子延后了半个小时。经排查发现，异步通知队列消息堆积严重大，底层原因是，通知是 BIO，当时部分客户响应速度高达 10 秒，直接导致通知消息消

一、必备知识 在分析源码之前，我们先来回顾下 MyBatis 中存在的几种查询情况和语法，如果不熟悉这些对源码理解上面有一定的困难。 1. 几种常见的映射方式 简单结果集映射 嵌套结果集映射：1-1、

前言 某项目里已经存在对外的固定报文格式，最近需求增加，需要兼容另一个系统的接口请求和返回格式。虽然对请求的解析也不一致，但这里要讲的是对返回值的处理，所以忽略请求。先来看看原先的和目前需要兼容的返回

解析了 mybaits-spring 项目关键类的源码，对 mybatis 和 spring 两个框架如何集成有个大概的了解

这段时间工作中本人对项目进行了一次压测，用到了不少常见的压测技术，和一些典型的场景，这里简单分享下。看完你可以解答如下一些问题： JMeter 如何发送有签名验签或者是加密的复杂请求？ JMeter

系统接入了多个支付渠道：招行、建行、工行、农行等用于收款，支付时需要很多的参数，如：签名、加密相关等。每个支付渠道的商户配置参数都不同，共同点是存在商户号、商户名字等字段。当前需要实现的是在 一个 H

上篇笔记我们在内存中实现了一个简单异步通知框架。但由于没有持久化功能，应用重启就会导致数据丢失，且不支持分布式和集群。这一篇是笔记的第二篇，引入了 Redis 来解决这些问题，以下是几点理由： 基于 Redis 实现延时队列也有几种方法，展开详细讲讲。 Redis 2.8.0 …

上图是目前扫码支付中普遍的数据流转情况。在此场景中，异步结果通知 承担着保证两系统（支付渠道和商户）之间 数据一致性 的工作。当有支付结果时，为保证时效性，必须 立即 通知给下游商户，且当通知失败时需要尽量保证系统间数据一致性，即遵循约定的 重试策略。由此可以看出是十分重要的一…