今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 

完成手机端支付标注。
明天计划的事情：（一定要写非常细致的内容） 

完成网页标注
遇到的问题：（遇到什么困难，怎么解决的） 

收获：（通过今天的学习，学到了什么知识）

• 体，如果发起人是个人，必须能够从个人交易历史记录中找到这笔交易。但大部分人不会保留电子记录，所以一般是提供可以下载的账单或交易记录，让用户自己对去。
• 交易对手，一般是商户。商户侧对账处理同用户侧，也仅仅提供对账单。
• 交易渠道侧，这是对账的重点，一是核实交易流水，二是核实交易佣金，毕竟是租用人家通道做结算的。

那有哪些记录需要对账？ 目前主要是两个：一个是交易记录；一个是退款记录。

对账处理流程

一般来说，对账流程涉及到如下步骤： 渠道对账单下载、本地交易记录准备、轧账、平账。

渠道对账单下载

银行，第三方支付，银联等，基本都会提供对账单下载的功能。不过也有少数工作做不到位或者太到位的银行，只提供账单查询后台，不提供对账单下载功能。

对开发人员来说，这里有几个坑：

• 对账单格式不一。文本，XML，csv的都有。为了后续能够统一处理，在账单下载完成后，需要进行标准化处理。
• 下载方式不一，HTTP，HTTPS，FTP的，都有。下载程序需要按照渠道的协议来处理。
• 下载时间不一，一般是凌晨1点后，到中午12才能用的也有。如果在预定的时间取不到数据，需要注意重试读取。
• 稳定性差。FTP服务器出问题那是常有的事。渠道侧解决方案往往就是重启。所以重试机制是必要的。

渠道对账单标准化

本地交易记录准备

本地交易记录的准备，总的来说有如下方法: – 啥都不做，直接用原始数据。鉴于大部分系统使用的是mysql，这也意味着在MySQL上做对账。对账时需要大量的数据查找工作，必然会影响线上业务。在数据规模较大，比如超过100万时，就不太合适了。

• 当然，还有一个选择是使用备库来执行对账，这样既简单，也不影响线上业务。这是典型的空间换时间的做法。
• 如果业务大到需要分表分库才能处理，那对账数据准备也不一样。使用分库也不现实，因为分库一般是按照主体id，而不是渠道id，来分库，这样对账就需要在多个库上进行，效率反而降低了。而对分表分库建立从库也非常耗费资源。这种情况下，需要同步一份数据到(hdfs)文件系统中，或者NOSQL数据库上。

由于交易记录是支付系统核心数据，有大量的应用，如信用、风控等，都需要交易记录数据。这些应用对交易记录的需求还不完全一致，为了提升性能， 交易记录会使用异步的方式来将数据投递给使用方。 交易记录在入库时，投递消息到消息系统中。使用方监听这个消息，一旦收到新消息，则从交易记录库中查询数据，获取数据并更新到库中。关于此类数据同步的文章不少，这里就不详细介绍。

轧帐

轧帐是按照客户订单号来比较本地交易记录和渠道交易记录是否一致。从算法角度，是计算两个数组的差异。在单机运行时，可以采用的算法不少，这里不详细介绍。 我们推荐采用mapreduce来轧帐，这有个优势，可以按照订单号将渠道提供的记录和本地记录shuffle到同一个reduce处理上，这样就可以很容易进行数据比对。 轧帐中最大的坑，莫过于切分点的问题。

比如以整0点为切分点，那存在一个问题，本地23:59发起的交易，到了渠道侧，可能会在00:01处理，这一笔交易变成第二天的帐了。实际处理中，一笔交易在渠道侧处理，花上几分钟都有可能。 对于切分点附近无法确认的帐，做一个时间窗，在时间窗内的数据，留待第二天对账时继续处理。

平帐

发现两边不一致的数据，那应该如何处理？数据量不大时，记录起来，人工甄别就行。但如果数据量很大，每天上千条，人工处理就成本太高了。这个没有统一的处理方法，需要根据有问题的数据，做个分析，然后做自动处理。 针对交易记录的对账的处理，主要有如下情况：

• 本地未支付，支付渠道已支付。这主要是本地未正确接收到渠道下发的异步通知导致。 一般处理是将本地状态修改为已支付，并做响应的后续处理，比如通知业务方等。
• 本地已支付，支付渠道已支付，但是金额不同，这个需要人工核查。
• 本地已支付，但是支付渠道中无记录；或者本地无记录，支付渠道有记录。在排除跨日因素外，这种情况非常少见，需要了解具体原因后做处理。

针对退款的对账处理，主要有如下情况：

• 本地未退款，支付渠道已退款，则以支付渠道为准，修改本地为已退款状态，并触发后续处理。
• 本地已退款、支付渠道已退款，但是金额不同，需要人工核查；
• 本地已退款，但是支付渠道无记录；或者支付渠道有记录，但是本地没有。 在排除跨日因素外， 这种情况非常少见，需要了解具体原因后做处理。

 比如微信的对账单，他是csv格式的，包括如下信息：

1. 交易时间：这是在微信侧的支付完成的时间。 这个时间会成为一个陷阱。
2. 公众账号ID，商户号,子商户号,设备号： 这些信息需要做验证，确保是自己的单子，不要让微信把老王家的单子也给发过来了；
3. 微信订单号,商户订单号： 这两个是对单的核心。前者是微信侧产生的订单号，在微信支付接口返回值中有。但是万一收不到这个返回值，那在本地记录中可能就空了。 后者是我们发送给微信的订单号，一般用这个来做对单依据。两边的数据中都会有这个值。
4. 用户标识,交易类型,交易状态,付款银行,货币种类,总金额,企业红包金额： 这几个就是对单的核心字段，必须确保双方是一致的。
5. 商品名称,商户数据包,手续费,费率：这些是可选验证

任务进度：任务10

任务开始时间：2018.11.15

任务结束时间：2018.11.22

是否延期：是

预计延期时间至：2018.11.30

原因：还有许多问题没搞明白

第二次延期：2018.12.05

原因：做项目

第三次延期：2018.12.10

原因：做项目

项目进度：开发期

项目开始时间：2018.12.01

预计上线时间：2018.12.16

是否延期：否