redis+MySQL+石英实施红色包传输功能

总结：

本文主要是对六个月前开发的红包模块进行分类，并介绍了主要的设计思路和具体的实现方案。如果设计和实施有缺陷，或者有漏洞，请批评和纠正这个问题。

红包函数对每个人都很熟悉，这是对红色包函数的简单描述…

功能描述：红色分组业务的主要功能包括四个部分：红包传输、红包接收、红包恢复和红包记录查询。

1）发送红包：发送者帐户>红色中间层

2）接收红包：红色层>收件人帐户

3）红包在中间层的回收：如果有红包保留了24个多小时，收回，中间一层红-发件人帐号。

在对函数进行描述之后，接下来是实现。

首先，给出了设计过程。这一部分将依次分析红包传输、红包接收和红包恢复的过程。

1。设计过程

第一个是发送红包，信封组为例，流程图如下所示：
图1红色包发送流程图

首先，使用基于高斯分布的方法，对100个随机分布为8的量，那么8份存储在redis缓存数据（列表），和队列的过期时间设置为24h；当考虑抢红包会有重复抓取问题，删除重复的方案是要维持一个分配在Redis缓存（套），内设商店已经收到红包的用户ID；此外，在大量用户同时抢红包，为优化考虑，才能起到限制作用，减少数据库的访问压力（考虑一下这样的场景：一段时间内，大量用户抢红包，在红色的配送时间的要求完成，将数据库访问的一些压力），实践是保持红旗已被分配在Redis缓存（核心价值），和0（分配）/ 1（分配）两种状态，从而限制了流动起一定的作用。

以下的缓存级别在MySQL数据库中的下一个阶段后，红包送表（account_coin_records_user_coin_package_send）在记录中产生的，在高斯的分配方法，8以上的金额同时插入红分配表（account_coin_records_user_coin_package_assign），初始分配的标记0（未分配），到目前为止，红包发送完成的过程。

然后是红色分组接收功能，其流程图如下所示：
图2红色包接收流程图

接收端发起请求（包括红包，用户请求ID请求）抢红包，首先需要一系列的验证，对Redis的缓存和基于验证数据的MySQL数据库验证操作是验证对应的红色ID，红色的包存在是否已经完成，分红已过期，接收机接收红包等重复。如果验证通过，则允许用户收到红包，其次是账户同步（红层- >用户帐户、交易处理），如果数据库操作成功，将获得成功，红包或失败，到目前为止，整个过程完成收红envel华保。

最后一个是红色包恢复功能，其流程图如下所示：
图3红色数据包恢复流程图

红色恢复使用定时调度策略启动5min不间断访问MySQL数据库的轮询间隔，查询是否被回收（红包已超过24h，在中间层和红包保留未分配完），如果有需要回收的红包，这时间效率的基础上使用多线程恢复运行的考虑，每个红色是一个线程，一个线程请求，策略，交易（本方案仅适用于可恢复红数不是很多的情况下）。（注：如果需要回收红很多，如果应用程序线程可能导致内存溢出的问题，然后具体分析，可以考虑生产者消费者模型）；分布式结构讲座，远程调用，下一个处理服务器接收红包恢复请求，标记帐户同步状态（红色标记为恢复），如果交易异常，然后回滚事务，在这个时候，红包是不能回收的，只能等待下一个5min后再次恢复。

在这里，这个过程基本上完成了，然后我们介绍了数据模型。

2。数据模型

数据库用于MySQL。红色数据包记录被持久化，用于查询红色包分发记录和后来的历史记录查询：
图4红色包分布数据模型

图4显示了一些重要的数据信息。表之间的关系是由红包ID建立的，它在红包记录和状态标志图中被标识。

在数据库级别，接收红包函数有一个并发性很高的问题，下面简要介绍如何处理并发性。

三.并行处理

你如何处理高并发问题

分析uff1a

首先，由于红包金额存储在redis缓存队列，因为redis是单线程的，在获得红包的相位不同步的问题。

然后，下一步是MySQL数据库中的一系列更新操作，具有很高的并发性问题。

最后，它是一个记录保存、插入操作，并且没有并发问题。

在数据库更新操作中，主要采用乐观锁和X锁两种方式保证数据的一致性。

4。并发测试

在并发测试期间，测试通过，不会出现数据不一致，红包恢复功能也可以正常执行。

目前，至少有3000的并发体积的红包操作在同一时间内不是问题。

总之，由于能力和技术的限制，目前的方案基本上适用于不太大的用户场景。后来，随着用户量的增加，它将进一步优化。

谢谢你的阅读。我希望你能帮助你，谢谢你对这个站的支持。