# GoodKillAction

**Repository Path**: gabry/GoodKillAction

## Basic Information

- **Project Name**: GoodKillAction
- **Description**: 商品的抢购活动，akka实现
- **Primary Language**: Scala
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2018-09-20
- **Last Updated**: 2020-12-18

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# GoodKillAction

## 重要概念说明

在生成活动之前，用户ID和商品ID，都必须映射成从0开始的连续、自增整数，分别映射为UserKillId，GoodKillId。
每个活动对应的映射规则可以不同，也可以相同，但不同的活动都必须重新映射。
UserKillId，GoodKillId主要是为了分散压力，比如商品共计10个，编号分别是0,1,2,3,4,5,6,7,8,9。
共计20个用户，则编号为0和10的用户抢购编号为0的商品，编号为1和11的用户抢购编号为1的商品，依次类推。
注意，此方案，默认是认为参加抢购的用户数量大于商品数量的，如果不满足这一条件，就会出现有些用户抢购不到商品，
而此时还有剩余商品。

目前方案没有考虑到商品的类别信息，比如商品的颜色、大小、尺寸等，用户抢购时也不区分。但如果区分怎么办呢？
按照商品的类别信息，对商品进行分组，商品的类别数量一般都很小，十级别的数量。比如商品分为红黄蓝三种。
则需要将商品ID按照类别信息分别映射，每个类别内的商品编号都从0开始计数。
单独一个actor负责某一个商品类别，该actor从当前集群中按照某种策略选择若干物理节点，将属于该类别的商品，
平均分散到这些节点中。
一个用户请求过来，首先按照其抢购商品类别的商品数量进行取余，假设为97，然后再对节点个数（假设为3）进行取余，
结果为1，则将该请求路由到编号为1的节点，由该节点中ID为93的商品actor处理。
注意，上面的方案并不考虑商品actor漂移，也就是说，假设某个节点宕机，则属于该节点的所有商品都不能被抢购，
直至将这些商品重新在新节点生成后再次参加抢购。

#### 项目介绍
商品的抢购活动，akka实现

#### 软件架构
软件架构说明


#### 安装教程

1. xxxx
2. xxxx
3. xxxx

#### 使用说明

1. xxxx
2. xxxx
3. xxxx

#### 参与贡献

1. Fork 本项目
2. 新建 Feat_xxx 分支
3. 提交代码
4. 新建 Pull Request