七．充足准备

1．对资金预算和资金剧本进行合理的建模

首先，面对如此大量的资金和复杂的资金剧本，如何准确高效地管理和控制逻辑呢？要杜绝傻大黑粗，我们需要一个优雅的解决方案——建模。（见图3）

对资金预算和资金剧本进行合理的建模，让模型涵盖、掌管、控制一切——让工具基于模型进行自动化的处理和校验，这里需要做的就是：

落地该模型的设计，让一切围着模型转；

· 按规定的格式文件导入预算和配置，进行数据和逻辑合理性校验；

· 一切利用工具进行处理，资金的支付、退款、红包的随机生成和多商户随机打散、预红包文件分割、预红包数据的校验，减少人为过程导致的潜在失误；

· 优化红包随机算法和文件处理方法，将红包随机分割和多商户随机打散算法的n^2时间复杂度优化n，压测30亿红包的生成时间为2～3小时，极大缩减准备时间，增加方案调整的回旋时间，可以让更多的资金上车。

其次，前边提到方案有如此多的变数、调整、变更，如何支持？还是回归模型，建模时就要考虑支持同样的预算多套资金配置方案。（见图4）

同样的资金预算，同时或依次生成多套预红包数据文件，提前做多手准备，方便方案变更。

再次，如此大量的资金就意味着如此大量的诱惑，会不会出问题呢？

· 方案预红包数据未提前落地DB，导致拆红包时缺少一次红包数据有效性的检验；

· 预红包数据存放在微信接入机上，存在被攻陷获取或篡改的可能；

· 红包数据在传输的过程中存在系统异常或恶意攻击，导致数据错误特别是金额错误的可能；

· 系统内部可能存在恶意人员直接调用拆红包的接口写入不存在的红包。

墨菲定律要求我们必须重视以上安全隐患，解决方案就是加密——对预红包数据进行加密，加密库和解密库独立维护保证密钥不被泄漏，通过工具生成预红包数据时用密钥进行加密，预红包数据在部署存储和传输的过程中保持加密状态，仅在拆红包的逻辑中编译二进制紧密库进行解密。

同时，鸡蛋也不能放在一个篮子里，为了控制密钥泄漏导致的影响，确保资金风险可控，整个预生成的红包数据可能分别使用了几百到几千个密钥进行加密，一个密钥加密的红包资金量在20～30万。解密库还需要能设置密钥ID的白名单和黑名单，确保未被使用的密钥不能被利用，确认泄漏的密钥可以进行拦截。

2．极限压缩

如果是百亿个红包，那么产生预红包数据文件的大小不经过压缩是非常恐怖的，传输部署几百GB或几TB的数据是很艰苦的，一旦发生调整变更会变得非常艰难，所以需要对数据进行极限的压缩。

· 对于支付单号、商户号、红包账户等信息，由工具导成配置文件，配置到拆红包逻辑中，加密的红包数据中仅用一个批次ID表达；

· 拆分红包ID，部分分段同样转为ID，解密库解密后利用配置进行还原；

· 加密部分（Ticket）：红包ID、金额、批次ID、密钥ID，压缩到16字节；

· 单条红包记录二进制表达，压缩到26字节。

3．对账

上面所有都做到就安全了么？真的就有人写了一个不存在红包进来会怎样？是否还有其他未考虑到的潜在风险？所以我们需要一个兜底——对账，把一切都要对清楚才放心。

对账后再入账的时效在30～60分钟，会造成不好的用户体验。为了提升用户体验，将大额的预红包数据（占比10%左右）导入KV（高速缓存），拆红包时进行即时校验，即时进行转账入账，未命中KV的红包则等待对账后异步完成入账。

· 资金配置与资金预算要总分对账；

· 红包数据文件与资金剧本进行总分对账；

· 红包数据进行全局去重验证；

· 红包数据进行解密验证和金额验证；

· 如果密钥泄漏红包金额等被篡改，兜底要进行红包DB中已拆红包数据与预红包数据的对账后，才能实际进行转账入账。