推广活动自贩机购买与抽奖集卡系统设计与实现文献综述

1. 文献综述（或调研报告）：

本项目基于SSM框架进行前后端分离开发，使用kafka消息队列解决注册、购买等高并发的操作，并使用redis缓存进行存储和读取以降低从数据库读取数据的频率，提高效率。算法方面，使用在微信端进行抽奖的设计理念，并通过离散算法进行改编达到对中奖总数进行限制：即单个用户抽中某奖项次数和奖品总量均有上限。最后使用evosuite工具生成单元测试代码，与手动编写的测试代码配合运行完成覆盖率要求。

通过前后端分离模式的选择，在降低了后端重复开发的同时，又可以避免前后端功能的互相依赖，从而可以实现前后端工程师并行进行开发，降低了程序的开发周期，提高了程序的开发效率^[1]。同时通过对@GetMapping、@PostMapping、@PutMapping 和@DeleteMapping四个注解的使用，完成前端对应的get、post、put和 delete四种请求方式，^[1]同时本项目可使用h5端作为前端与后端的中间网关接口，将数据打包为json类进行传输。

而SSM框架中，主要采取了注入依赖模式，采用注入容器的方式，实现控制反转（ioc）：对于面向对象的开发，这是一个用于减少代码之间的关联。IoC将设计一个类来实现类内的控制，而是由系统来控制。^[2]

Mybatis使用XML并置文件映射javabean、映射等等将数据类型(整数、字符串等)，并通过xml文件将sql表结构与mapper和bean文件对应，完成javabean和mapper的映射，现在IDEA工具中的mybatis generator即可完成这一过程，完成了mapper的基本接口和bean层的基本数据。

同时，与面向对象编程思想不同，ssm框架采取面向切面编程（AOP）：使用动态代理来封装多个系统级服务的行为(例如将日志、事务等)转换为可重用模块，以实现业务逻辑的松散耦合系统级服务，降低代码重复率，实现动态织入。^[2]

Kafka遵循先入先出原则，由多个生产者（producer）和消费者（comsumer）同时工作。生产者（producer）和消费者（consumer）部署在各个业务逻辑中被频繁的调用，三者通过 zookeeper管理协调请求和转发。它不需要等待代理确认，消息直接以代理的最快速度发送。^[3]比起其他的消息队列（rocket、rabbit等），kafka在高吞吐、高并发场景下优势明显，且有很好的分布式扩容能力。^[4]在本次活动中，购买、注册等操作的并发量会极高，因此选用kafka作为消息队列工具。

redis可以周期性地写

将内存中的数据存入磁盘或在补充日志文件中写入修改操作。通过这种方式,redis不会在停机时丢失数据，可以快速将上次快照的数据从磁盘加载到内存。^[5]如图所示（图1.redis总体架构

，源自^[6]）。

微信端进行抽奖的设计理念中，整个系统由微信公众号、服务器端微信接口、抽奖算法、数据库、控制台、中奖列表页面等部分组成。以微信公众号为用户入口，以服务器端微信接口处理用户发送消息、调用算法模块并返回用户相应消息，以算法模块接收抽奖指令、结合设置参数完成抽奖算法、将中奖信息存入数据库，以数据库存储抽奖过程中的中间参数及中奖结果，以控制台设置某次抽奖过程的所有参数，以中奖列表短时间间隔定时同步数据库中中奖情况信息。^[7]考虑到整个项目中不同的用户进行抽奖的时间点也有所不同，故采用不放回抽样之离散算法。在介绍离散算法前，先要介绍不放回抽样一般算法：产生-张容量为N的列表，其中前n1项标记为一-等奖、接着n2项标记为二等奖、接着n3项标记为三等奖，剩余m项标记为空。产生[1,N]区间上的随机整数，查看对应奖项标记。而离散算法在此基础上进行了改进，依奖品种类及奖品数目，划分列表为奖品种类对应的区间。产生[1,N]区间上的随机整数，分别与区间边界0，n1, n1 n2, n1 n2 n3， N进行大小比较，判断奖券所在范围，而非对列表中的每一项都进行标记。^[7]在此基础上，采取了以下算法改写：首先，抽取的物理随机数高于N-T（根据活动需求自行设置），即为不中奖。另外，由于对单一奖项的中奖次数有限制，会使用SQL数据库进行记录，当不满足需求时，即将奖品置空（即未中奖）。