# Redpacket_redis_java

**Repository Path**: kaikz/redpacket_redis_java

## Basic Information

- **Project Name**: Redpacket_redis_java
- **Description**: Redis应用场景之抢红包系统
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 4
- **Forks**: 1
- **Created**: 2024-10-14
- **Last Updated**: 2025-07-10

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# Redpacket_redis_java

#### 介绍
Redis应用场景之抢红包系统

系统整体业务流程主要由两大业务组成:发红包和抢红包。

- 为了保证红包金额产生的随机性和概率平等性，我们使用了一种随机数生成算法:二倍均值法。在本系统中我们采用“预生成”的方式生成随机金额列表，这和微信红包实时产生金额的方式是不一样的(但是算法的核心思想却很类似)。最后，是抢红包系统两大核心业务模块的开发，包括“发红包”和“抢红包”两大业务模块，而且我们采用自测的方式对相应的接口进行了测试，最后针对高并发情况下使用分布式锁保证了数据的一致性

![输入图片说明](https://foruda.gitee.com/images/1728912946021942089/a87b6f0f_13983004.png "屏幕截图")
![输入图片说明](https://foruda.gitee.com/images/1728913029744665803/9dde05b3_13983004.png "屏幕截图")
![输入图片说明](https://foruda.gitee.com/images/1728913111423131392/0d9b4605_13983004.png "屏幕截图")

- 对“抢红包”业务模块发生高并发时出现数据不一致的现象进行分析，并得出其产生问题的原因在于没有加锁(同步操作)进行控制，从而导致多个线程访问共享资源或操作同一份代码时出现并发安全的现象。

    为此我们采用了基于Redis的分布式锁(子操作)，并以代码的方式对整体的核心业务处理逻辑进行了优化。当然，在实际生产环境中，分布式锁的实现方式还有许多种。

- 目前虽然系统整体的代码处理逻辑没有太大的问题，而且确实已经能扛得住秒级高并发的请求，然而从业务层面的角度看，这个抢红包系统还是存在着些许问题。该问题描述如下:
    当发出的红包没有被抢完时,请问该如何处理剩下的红包?如发出一个固定总金额为10元的红包，设定个数为10个，但是最终却只有6个被抢到，那么剩下的4个红包汇总的金额该如何处理?对于目前的系统而言，是暂时没有实现这一功能的，算是其中的不足之处吧。(提示:最终剩下的金额当然是归还给发红包者。)