支付的复杂主要是信息流的复杂,因为要想实现一次交易、一次支付的处理，往往会涉及到很多系统，每个系统当中都会生成相应的单据，而这些单据之间存在着千层万缕的联系,只要搞清楚了他们之间的联系，就搞懂了这些系统之间的“关系”，信息流，无非就是在系统通讯过程中生成的信息而已，而这些信息就是“单据”

css 常用代码片段,隐藏滚动条或更改滚动条样式,检测横屏竖屏,移动响应式设置,点击元素禁止产生背景或边框,禁止长按链接与图片弹出菜单,禁止用户选中文字,取消 input 输入时，英文首字母的默认大写,视频全屏播放,开启硬件加速,怎么让 Chrome 支持小于 12px 的文字？文字超出隐藏并显示省略号,重置浏览器样式

MySQL 数据库的主要备份方式有哪些？如何确保 MySQL 数据库的高可用性？ MySQL 中的 slow_query_log 作用是什么？如何监控 MySQL 数据库的性能？MySQL 中的 InnoDB 和 MyISAM 存储引擎如何选择？ 如何处理 MySQL 数据库的锁定问题？什么是 MySQL 的数据分区？MySQL 的 EXPLAIN 语句有什么作用？如何实现 MySQL 数据的恢复？

Redis 是一个开源的高性能键值对数据库，它以其内存中数据存储、键过期策略、持久化、事务、丰富的数据类型支持以及原子操作等特性，在许多项目中扮演着关键角色。以下是整理的17个Redis在项目中常见的使用场景.

对软件设计模式的理解和应用，基本上可以算做初级研发工程师和高级研发工程师的分水岭。我在面试时很喜欢问候选人对设计模式的理解，以及实际应用情况，大部分候选人都能回答单例，工厂等，再多问几句，就惨不忍睹。其实也能理解，这些内容对于初学者而言，基本只能靠死记硬背，记不长久。今天聊聊我理解的设计模式，在支付系统经常用到的场景，以及容易混淆的点，里面讲到的概念可能和一些权威的论述有所出入。下面的内容全部源自我这么多年所写代码的抽象总结，和以前一样，也不可避免会夹杂一些我个人不成熟的见解，请各位以“取其精华，去其糟粕”的精神辩证地看待此文内容。

本篇主要讲清楚收银核心的设计与实现，包括收银核心如何渲染可用支付方式，如何做可支付检查，收银台核心的系统架构、领域模型，常见支付方式等。如果说电子商务是现代经济的繁华都市，那么在线支付系统无疑就是最繁忙的交通大动脉。在这个每年数十万亿规模的在线支付交易世界中，有两个默契十足的队友密切配合，确保每一笔交易都像优雅的华尔兹舞步一样流畅 -- 那就是：收银核心和支付引擎。

每个公司的账务系统设计思路、实现方式必然是不一样的，我个人经历过好几家支付公司，实现细节千差万别，但是整体思路都差不太多，比如账户设计一定有客户账户和内部账户，一定有中间户（过渡户），也一定使用复式记账，也都有实时记账和缓冲记账等。

随着互联网应用和服务的日益增长，用户设备的网络状况直接影响着他们的使用体验。特别是在网络带宽受限或网络状况不佳（弱网）的情况下，应用程序如何自适应地调整行为显得尤为重要。本文将介绍几种在前端检测网络带宽和判断弱网环境的常用方法，以及如何基于这些判断优化用户体验。

除了从事账务系统研发的工程师外，大部分支付研发工程师对账务都了解甚少，主要原因仍然是账务系统的业务门槛往往大于技术门槛，比如很多支付研发工程师甚至不了解复式记账。所以有必要从研发工程师的角度来介绍一些账务系统入门的知识。需要说明的是，不同支付公司内部设计的账务系统必然存在差异，但有些基本原则大家都会遵守，比如复式记账、账户管理、记账、对账、会计中心、日切等。

本文描述的概念大部分做了极致简化，只是用于入门，对于理解概念应该是够用的。真实的实现会复杂非常多。这些概念如同支付核心系统拼图的一些小碎片，串起这些小碎片，就是一个完整的支付系统大图。另：后面的描述中，经常混着用“支付系统”、“支付平台”，“支付机构”，“收单机构”，本质是一个东西。在内部来说，就是一个支付系统，但从和外部机构交互来说，就是一个支付平台。对用户来说是支付，对商户来说就是帮商户收单。