同步发表于个人博客，那里比较清静，木有广告：http://blog.lanjingdejia.com/articles/2019/01/18/1547811920520.html
17年12月开始维护打车结算系统，至今一年有余矣，些许心得，录于此处，望对后来者有所裨益。
清分、入账不在讨论范围内，此处结算付款只涉及到算钱、付款的流程。
业务特点：
当今社会，凡是和钱相关的，都是大问题。
从这个角度出发，付款系统有三个显著的特点
最直接，离钱最近，无丝毫转圜余地
不同于其他系统，发生错误、事故后，可以后各种补救措施。
订单、红包、风控、计费、导航等系统的错误（绕路，无法支付，算错钱，红包无法使用，长时间打不到车，奖励漏发，惩罚出错），可以采取各种手段安抚，给用户发红包，发代金券，等等等等。
说到底，大多都是间接和钱相关，间接的空间越大，可操作空间就越大，越容易弥补。
再来看看付款：
直接把钱打到用户银行卡，这是离钱最近的地方，其中没有哪怕一点点缓冲的空间，一旦出错，几乎不可挽回。
多发了，基本上就是公司损失了，要回来的概率基本可以忽略。
少发了，还好，被用户骂一通，补发，然后陪个红包啥的。
从这一点看，似乎没那个严重，但是，这里忽略了第二个特点：
数据量，雪崩类型的
订单都是一个一个发生的，一笔一笔发生的，单笔其实没多少，几十块而已。
但是付款，非常不同，那可是一个周期（比如一星期）累积起来的、上百倍的数量级，基本每笔付款都是少则成百，多则上千。
这还不是最恐怖的，最恐怖的是，这个成百上千还要乘一个几十万！
为什么呢？因为钱都是统一时间发出去的，比如每周二给司机们发钱，这一发就是十几万、几十万笔。
举个例子：
一个星期内，周一发现线上问题，报警几十个后，紧急修复上线，影响范围几十个用户，涉及资金几百元。
然后时间来到了周末，开始给司机们发钱了，我勒个去，开始报警了，紧急修复？来不及的。结果影响范围10万司机，涉及资金1亿元。。。
你以为到这里就完了吗？no！
时间敏感度
用户的习惯很容易就会被培养起来，此后一旦有些许改变，必然引来用户的疑问。
仍然举个例子：
平时都是上午10点发钱，因为某些原因（比如钱发不出去了，紧急修复一把，用了1个小时），延迟到11点发钱，那么这1个小时内，必然会有很多客诉。
如此，为之奈何？
解决办法
提醒/报警
不同于其他系统，通过一些离线任务，可以及时发现系统中潜在的bug，然后修复。
付款系统，事后的核对，有用，但是也仅仅是聊胜于无，等你发现问题，黄花菜都凉了。
所以，尽可能的事前报警，如果实在做不到，底线也是事中报警。
事前报警/提醒的方法有以下几种：
-
如果上午10点发钱，那么至少在9点钟知道要发多少钱，时间长了，一眼就能看出来这笔钱有没有问题，如果有问题，起码有时间在10点之前修复。
-
发邮件？APP报警？都不靠谱的，人不在公司，最简单直接的就是发短信！
-
如果哪天改过代码，那么请务必保证在打款日的9点左右能让自己处于一个可以改代码并发布的环境中。
-
不要吝啬error日志，但凡可能出问题的地方，请毫不留情的log.error，请务必保证error能触发报警。宁可错杀一千，不可放过一个。
安全第一，性能第二
-
写代码时，尽可能简单粗暴，怎么简单怎么来。当然前提是满足上面提到的用户的时间敏感度，毕竟你不能为了追求安全，全部加锁单线程，四五个小时才把10万笔钱发完。。。
-
尽可能少的使用一些华而不实的代码上的“技巧”。
-
不要吝啬使用锁，分布式锁、CAS锁、数据库悲观锁，等等，只要控制好锁的粒度，这些影响不了太多的性能，但是带来的安全性收益甚大。
如果可能，尽量留出一些可操作的空间
还是那句话，越间接，可操作空间就越大，问题就越来得及弥补。
比如10点发钱，你可以在2点就算出应该发多少钱，然后这期间，都可以用来发现和解决问题的。
事前，事前，事前
请不遗余力，无所不用其极的尽可能让问题在事前暴露出来，流计算，风控，用户画像，数据分析，异常检测等等，能想到的都可以考虑一把。
最后也是最重要的
淡定，无论何时，请淡定，务必保证头脑是清晰的。