积分是记流水还是只存一个余额，两种做法差很远
用户问那五百积分怎么少了，能不能答上来，取决于当初是记流水还是只存了一个余额。只存余额的做法，上线很快，出事的时候很难受。一、只存余额
一条记录一个数，加就加、减就减。写起来简单，读起来快，页面直接显示，几乎不用额外维护，初期确实省事。只存余额的做法，一开始看着够用，等业务方要按来源拆分的时候，才发现当初没记来源，只能从零开始补。这块的测试要造极端数据，零、负数、超大数各来一遍，正常数据测不出问题，测不出问题不等于没问题，等真出问题的时候，往往是几种情况撞在一起。
问题在查不出原因。少了就是少了，什么时候少的、为什么少的，一概不知，只能给用户一句稍等，然后自己去翻别的地方的记录。这套账要能对外解释，用户问起来，一句话能说清分是怎么变的，说不清就得翻记录，翻记录那几分钟，用户的火就上来了，上来之后说什么都难听。
二、记流水
每次变动写一行，谁、什么时候、加多少减多少、什么原因，都记下来。余额可以由流水加出来，加出来的数跟存的对一遍，就知道有没有漏。流水表要按时间分区，不分区的表跑到几千万行，查一次要几十秒，分区之后只扫一个月，几秒就出来。每月出一份简报，发给相关的人，数字有变化才有人关心，没人关心的数字，出了问题也没人及时发现，等发现的时候，差的已经不是一星半点。
好处是任何一笔都能追。坏处是流水会越积越多，加一遍越来越慢，得定期做汇总，汇总之后老流水归档，查老账再回归档里找。对账任务要跑在低峰，跑的时候限速，别把前台一起拖慢，拖慢一次就得半夜起来看监控，看监控还得先猜是哪块，猜错一次又是一小时。
三、两个一起用
流水照记，余额单独存一份，两者定期核对。核对不上就说明有一边漏了，能尽早发现，早发现的时候往往只错了几笔。两个一起用的时候，谁为准要写清楚，写不清楚的时候，两边不一致，处理的人各按各的，末了越修越乱。这块的文档要写清加减的时机，什么动作加、什么动作减、谁负责触发，写不清的时候，两个人各加一次，分就多出来了。
核对要自动跑，跑完出差异清单。靠人偶尔想起来对一次，等于没对，等想起来的时候，差异已经攒到查不动了。差异清单要有人看，没人看的清单等于没跑，跑完还得有人签字，签了字才有人对结果负责，不签字的时候，出了问题谁都说不是自己那一环。
四、幂等很重要
同一个动作重复提交，不能加两次。做法是每笔变动带一个少见标识，重复的直接忽略，忽略的时候也回一个成功，别让前端一直重试。
网络不好时用户会连点，没有幂等，一次操作变成三次，用户回头就来找，找的时候还得一笔笔核对，核对完再手动扣回去。改动之前先备份，账这种东西，改错了很难回头，回不了头就只能按流水一笔笔重算，重算一遍要几个小时，几个小时里业务那边只能等着。
五、负数怎么办
扣到零以下要不要允许。多数场景不允许，扣不动就拒绝，并且告诉用户还差多少，差多少这句话很重要，用户知道还差多少才知道该做什么。
允许负数的场景要少。一旦出现负余额，报表、兑换、等级计算全都要单独处理，每一处都得加一个判断，加漏一处就出错。规则要写在一处，散在几个页面，用户看到的和实际执行的对不上，对不上就会来问，问的时候还带着截图，截图一摆，解释起来更费劲。
六、过期怎么算
流水里要带有效期。算余额的时候把过期的剔掉，别等清零任务跑完才生效，任务跑得慢的时候，用户会看到还能用，用的时候又不行。
剔除要有顺序，先扣早过期的。顺序不对，用户会觉得自己的分莫名其妙少了，因为他记的是先前那笔分还没用。新功能接入要按同一套记账方式，各写各的，汇总的时候全是坑，坑还得一个个填，填的时候业务已经在催，催得越紧越容易填错。
流水是账本，余额是结论。账本能查，结论才可信，两者缺一个，用户迟早会来问，而且问的那一次往往正好是很忙的时候。 之前一直半知半解，看了你的解释一下子就明白了，讲得通俗易懂。 楼主的经历很有参考价值，给了我很多新的思考方向，非常感谢。
页:
[1]