业务系统记录操作日志的几种方式

最近的一个业务系统，需要实现一套操作日志的记录方式。这篇日志算是对各种实现的一个思考。

一 每个操作记录流水
这种方式非常适合每一步操作都非常重要的系统。比如常见的金融操作系统。在一般的场景下，我们只会对涉及金钱的操作记录这种流水日志，比如转账，扣款等。
在设计账户流水表的时候，需要有以下几个必须的字段：
(1) instruction_id 流水号
(2) amount 金额
(3) operation_type 操作类型(转账or扣款)
(4) before_balance 操作前账户余额
(5) after_balance 操作后账户余额
(6) time 操作时间
第一个字段，流水号，是主键。这个字段的必要性在于，它能维护该记录修改的幂等性。简单的实现，流水号可以使用uuid。
当前端发起一个充值的操作时，首先在前端产生一个流水号，然后将其他的用户填写的参数通过rpc请求发送到后端。后端的处理流程如下：
(1) 开启事务
(2) 从db中查询账户余额
(3) 修改账户余额
(4) 记录流水
(5) 提交事务
假设在执行过程中，出现了网络问题，该执行结果处于未知状态，那么前端可以通过刚才的uuid反复重试，直到得到一个确定的结果为止。
我们可以对流水表稍做改进，以适应普遍的情况。字段如下:
(1) instruction_id 流水号(在对可靠性要求不太高的场景下，可使用数据库自增id)
(2) operation_type 操作类型
(3) before (一个json，描述修改前的该行记录)
(4) after (json, 描述修改后的该行记录)
(5) time
还有一些可选的字段，比如 input_param(输入参数)，操作人等等。
这种基于流水的方式优点有：
1 可靠性很高
2 实现方式确定，可以基于接口做注解实现
3 可以基于该流水，实现业务层的操作回滚
但是它的缺点也很明显：
1 增加开发量，需要额外增加记录写入
2 降低运行效率，需要多一到两次查询(before, after)
3 和业务绑定的比较紧

二 基于数据库的binlog实现
第二种方式是基于mysql的binlog来实现。这种方式最大的好处是可以和业务完全的解耦，而且统计的结果是完全准确的(相比于有些完全基于业务代码的实现来说，这类实现一般是对执行前后查询两次)。
关于binlog的定义及获取，可以参考

http://www.jianshu.com/p/1f7889273845

binlog可以描述为下面这种model:

@Data
public class RowDiffModel {
    long timestamp;
    String tableName;
    List pkColumnName = new ArrayList<>();  //主键列
    List