之前写过一篇红包算法的内容，最后采用了微信的方案，没有使用预分配的方式。今天这篇会介绍下红包业务处理中的更多细节，以及过程迭代中遇到的一些问题和对应处理。
红包业务逻辑简述
首先，和微信红包一样，我在处理红包时，也先做状态检查，可客户端合作，在点击时，先做check，然后根据状态进行对应的操作。如是否过期，是否符合条件，是否已经抢过，以及最终可以抢红包的结果状态，返回列表，计算手气最佳等。这里有个比较特殊的是，一般红包是由用户自己触发，目前有限制，只有两次机会。还有一种是主动发送，称为定时奖励红包，是全量的。这个后面会详细说到。
红包逻辑和状态处理
红包ID
这里是比较复杂的一块，首先说下红包id的生成，用userId+chartId+timestamp+KEY => md5 生成，标记唯一的一个红包。加时间戳和userId， chartId也是为了验证，包括一个私有的KEY作为一定的安全防范措施，防止恶意生成和领取。
生成红包
- 生成id
- 根据策略生成红包数量，总金额 ，如群人数，固定的比例。 2.1 获取群聊数量 2.2 根据不同类型计算数目，金额 2.3 保存红包记录。 2.3.1 红包 id 为key， size 红包id + remainCoin作为两个值 ，存在Redis，过期时间为1天，数据只有红包数量和总金币，结构简单。Redis存储可以提供一致性和大的并发量，为后续抢红包做准备。 2.3.2 保存数据库记录 。创建时间，名称，类型，消息。 发送者， 目标方，红包总数，总金额(不返回给用户)等，这里单独存储到数据库，做记录。 2.4 返回红包结果 注：这里用服务端返回给客户端结果，也可以考虑直接用Sdk作为消息发给客户端处理。
领取红包
分成两个步骤。 入参: 红包id,用户id, 群聊id, 创建时间 1 如上所述，先检查红包状态 1.1 根据红包id 查库， 获取红包，如果没有则记录不正确。 1.2 检查参数 查库拿到的红包创建者id 和 群聊id ，创建时间 再次生成红包id ， 是否与参数红包id 相等，否则表示非法红包参数，这块作为安全验证。 1.3 检查状态 业务状态判断，这里是红包额外的一些业务限制检查，是否满足规定条件。 1.4 获取红包详情 根据红包id 从Redis获取， 红包 id + size 红包id + remainCoin 。 得到 该红包总数，总金额。 1.5 是否已空 该红包剩余的size 和 金币是否>0 1.6 获取红包领取记录 查询红包记录，通过红包id查询。 1.7 是否领取完毕 如果领取记录数 等于 1.4 获取的总数。 或者 1.5条件成立，则是已经领取完毕。 1.8 是否有当前用户领取记录 根据红包领取记录过滤，有当前记录则为有领取记录。 1.9 根据当前已知状态，最终返回状态。 红包非空 1.5 1.7 有当前用户记录 1.8 - 返回已经领取过。 没有当前用户领取记录 1.8 红包过期， 创建时间超过1天。 # 返回过期 红包没有过期 #返回可以领取。 红包已空 1.5 1.7 有当前用户记录 - 返回已经领取过 没有当前用户记录 红包过期， 创建时间超过1天。 # 返回过期 红包没有过期 #返回手慢了，领没了。 1.10 根据状态做对应的展示。
2 根据1中获得的状态，执行后续操作。 2.1 根据红包id 查库， 获取红包，如果没有则记录不正确。 2.2 检查红包参数 ， 同1.2中处理。 2.3 查询领取记录 2.3.1 是否匹配到记录 2.3.2 红包是否过期 处理过期 过期：有匹配记录 - 返回消息为金币数 没有匹配记录 记录数等于红包总数 # 红包n个，已经抢光 ， 标记手气最佳 - n个红包，已领取m个红包 最终返回状态为 # 过期 2.3.3 没有过期 2.3.4 检查是否足够时长 - 足够 继续 - 不足 返回状态为不足阅读时长 2.3.5 是否领取完毕 2.3.5.1 为空（总数==领取记录数） 如果记录包含当前用户，- 返回成功，用户金币数，已被抢光。 不包含当前用户 - 返回失败 标记手气最佳 检查是否领取过。 2.3.5.2 不为空，进行领取 1-1 记录包含当前用户 。 # 金币数 ， 提示n个红包，已经领取m 个，状态为已经领取过 1-2 不包含当前用户 *********计算红包 得到单个金额 redis减少总数和金额，成功 减少成功，写入记录。增加金币，金币系统（加失败重试），最终失败回退 # 返回领取失败 返回剩余金币 - 返回 redis减少总数和金额，失败 状态红包已经被抢光 标记手气最佳 标记领取过
遇到的问题
以上比较仓促，细节对应到逻辑图会更好。红包自测试完备上线后，一直稳定运行，在1-3个月总数据量也到了千万级，不过限于业务限制，并发不高。其中定时红包在群总数逐渐增多后，遇到了几个问题。首先依赖的外部接口流控，导致很多超时，这块最后改为从本地的缓存获取每个群人数，目前看效果良好；其次，由于使用了一个封装好的Redis工具类，没有太注意相关参数，导致后面量增大之后，会有maxRedirection的异常，坑的是工具类的对应参数没法设置，只能自己做了更新，将底层jedis的maxAttempts修改为可配置，同时增大到10解决，之前是5，默认值；最后，定时红包按需求要保证100%的送达，目前遇到两个可能改进的点：一是在单机失败后，加到延迟队列或者在一段时间之后重试，这里延迟是防止当前压力过大，导致滚雪球效应。第二个是目前消息消息触发执行任务，有消息丢失的可能。这块看是否要自己支持结果回调，还是消息系统已经支持对应功能。
以上就是这篇总结，最近做的事，更加深入认识到业务量级所带来的不同挑战，同时也意识到做对应的技术积累和沉淀，未雨绸缪是很重要的事，否则只能被动，而且也不仅是个人，团队，部门，大到公司，集团都是如此，这是后话了。
