工业和信息化部：上半年工业经济继续平稳复苏，主要指标平稳增长
06-18
每笔交易，各参与者的记录必须一致，不能有偏差。
对账系统的工作是发现有差异的记录，即对账；然后手动或自动解决这些差异，即对账。
对于电子商务系统来说，每一笔交易都必须与所有相关实体进行匹配：交易实体，如果发起人是个人，必须能够从个人交易历史中找到该交易。
但大多数人不会保存电子记录，因此一般会提供可下载的账单或交易记录供用户自行查看。
交易对手通常是商家。
商户侧对账流程与用户侧相同，仅提供报表。
在交易渠道方面，这是对账的重点。
一是验证交易流程，二是验证交易佣金。
毕竟通道是租来结算的。
哪些记录需要核对？目前主要有两个：一是交易记录；二是交易记录。
二是退款记录。
一般来说，对账流程包括下载渠道报表、准备本地交易记录、调账、结算等步骤。
渠道对账单下载 银行、第三方支付、银联等基本都提供对账单下载功能。
但也有少数银行的工作做得不够好或做得太好。
他们只提供账单查询后台，不提供账单下载功能。
对于开发人员来说，这里有几个陷阱：语句格式不同，包括文本、XML 和 csv。
为了以后能够统一处理，话单下载后需要进行标准化处理。
有不同的下载方法，包括 HTTP、HTTPS 和 FTP。
下载程序需要按照通道的协议进行处理。
下载时间各不相同，通常在凌晨 1 点之后，有时只能到中午 12 点。
如果在预定时间无法获取数据，需要注意重试读取。
稳定性差。
FTP 服务器出现问题是很常见的。
通道侧的解决方案往往是重启。
所以重试机制是必要的。
看一下第三方支付的报表： 银行直连对账：技术选型上，HTTP(S)可以使用apache httpclient实现链接池和断点续传，FTP也可以使用Apache Commons Net API。
但无论是哪一种，都需要设置重试次数和链接超时时间。
设置重试次数和间隔时需要小心。
如果重试太频繁，很容易杀死服务器。
如果时间间隔太大，就会阻塞后续的处理步骤。
5 到 10 分钟是合适的重试间隔。
链接超时是指当服务器出现问题时，如果在规定的时间内无法获取到数据，就会自动断开连接。
这很容易被忽视。
我们曾经遇到过系统问题。
通道端的FTP被挂起并重新启动，导致我们的客户端挂起并等待重新连接。
让我们看一个渠道声明标准化的例子。
例如，微信的对账单是csv格式，包含以下信息： 交易时间：即微信端支付完成的时间。
这一次可能会成为一个陷阱。
公众账号ID、商户号、子商户号、设备号：这些信息需要验证，以确保是您自己的订单。
不要让微信发送老王的订单；微信订单号、商户订单号：这两个是一对的核心。
前者是微信生成的订单号，包含在微信支付接口的返回值中。
但如果没有收到这个返回值，则本地记录可能为空。
后者就是我们发送到微信的订单号，一般作为匹配订单的依据。
该值将出现在双方的数据中。
用户ID、交易类型、交易状态、支付银行、币种、总额、企业红包金额：这些是订单的核心字段，双方必须保证一致。
产品名称、商户数据包、费用、费率：这些是可选验证。
某宝物的表述为文本格式，并以空格分隔。
他们的就简单多了，只有商户订单号、交易序列号、交易时间、支付时间、付款人、交易金额、交易类型、交易状态等字段。
由于各个渠道的账单格式不同，拿到账单后，下一步就是规范账单，以便统一处理结算和后续工作。
标准化的计费数据可以放置在文件系统或数据库中。
这取决于交易数据量。
对于每天超过100万的量，使用文件系统更为合适。
数据库操作速度比较慢，而且浪费资源。
基于文件系统的标准化涉及以下内容： 文件格式标准化：统一使用csv或json或xml格式。
如果您使用hadoop或spark进行协调，那么使用csv是一个不错的选择。
统一文件存储：文件目录和文件名需要遵循统一的命名标准。
为了加快处理速度，我们使用HDFS作为文件系统，这有利于后续的对账处理。
本地交易记录的准备 一般来说，本地交易记录的准备有以下几种方法：什么都不做，直接使用原始数据。
由于大多数系统都使用 mysql，这也意味着在 MySQL 上进行协调。
对账需要大量的数据查找工作，这势必影响线上业务。
当数据规模较大时，例如超过10000条时，不适合。
当然，还有一种选择是使用备份数据库进行对账，既简单又不影响线上业务。
这是典型的以空间换时间的做法。
如果业务规模很大，需要单独的表和数据库来处理，那么对账数据的准备就会有所不同。
使用分库也是不现实的，因为分库通常是根据主题ID而不是频道ID来划分的。
这样就需要对多个数据库进行对账，降低了效率。
建立分表、分库的从库也是非常耗费资源的。
在这种情况下，您需要将数据的副本同步到（hdfs）文件系统或NOSQL数据库。
由于交易记录是支付系统的核心数据，信用、风控等大量应用都需要交易记录数据。
这些应用对于交易记录的要求并不完全一致。
为了提高性能，交易记录会使用异步的方式将数据传递给用户。
当交易记录存储在数据库中时，消息将被传递到消息系统。
用户收听此消息。
一旦收到新的消息，就从交易记录数据库中查询数据，获取数据并更新到数据库中。
关于这种数据同步的文章很多，这里不再赘述。
算账就是根据客户订单号来对比本地交易记录和渠道交易记录，看是否一致。
从算法的角度来说，就是计算两个数组的差异。
在单机上运行时，可以使用的算法有很多，这里不再详细介绍。
我们建议使用mapreduce来平衡账户。
这样做的好处是可以将通道提供的记录和本地记录按照序号打乱到同一个reduce进程中，从而可以方便地进行数据比较。
记账过程中最大的陷阱就是分点问题。
比如用0点钟作为切点，就有问题。
23:59本地发起的交易可能会在00:01在通道侧得到处理，该交易将成为第二天的账户。
在实际处理中，一笔交易在通道侧处理，可能需要几分钟的时间。
对于分割点附近无法确认的科目，会创建一个时间窗口，该时间窗口内的数据留待第二天对账时处理。
当您发现账户双方数据不一致时，应该如何处理？当数据量不大时，只需记录并手动筛选即可。
但如果数据量很大，每天几千条，人工处理的成本就太高了。
对此没有统一的处理方法。
需要根据有问题的数据进行分析，然后自动处理。
交易记录对账处理主要包括以下几种情况：不在本地支付，而是通过支付通道支付。
这主要是本地没有正确接收通道发送的异步通知造成的。
一般的处理是修改本地状态为已支付，并对响应进行后续处理，例如通知业务方。
已在本地和通过支付渠道进行支付，但金额不同，需要人工验证。
本地已支付，但支付通道无记录；或者本地没有记录，但支付渠道有记录。
排除跨日因素，这种情况很少见，需要了解具体原因后再处理。
关于退款的对账处理，主要情况如下：如果本地没有退款，但支付渠道已退款，则以支付渠道为准，将本地状态修改为已退款，并进行后续处理。
已在本地和支付渠道退款，但金额不同，需要人工验证；已在本地退款，但无支付渠道记录；或者有支付渠道的记录，但本地没有。
除了排除跨日因素外，这种情况很少见，需要了解具体原因后进行处理。
总之，和解工作并不复杂，也不复杂。
它需要细心、对业务的深刻理解并选择正确的架构。
相关阅读：支付系统设计：支付系统的账户模型（一）雷锋网 注：本文由人人都是产品经理社区作者@凤凰品牌老雄（微信公众号：shamphone）原创发布。
凤凰牌老熊，程序员&架构师。
曾就职于富龙、三星（中国）研究院及国内一些大型互联网公司。
2006年加入爱奇艺，负责数据仓库和支付系统建设。
文章未经许可不得转载。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-18
06-18
06-18
06-17
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态