活动主页：查看地址
 
 
 

 
 
首页banner:
 

 
 

 
 
二级页面banner：
 

 
 

 
 
侧边栏banner：
 

 

核心代码实现
 
待续
 
数据库设计
 
待续
 
高并发下的优化
 
转载：http://blog.csdn.net/qq_16681169/article/details/53750704 
 一. 项目思考
 
由于项目发起了一个抽奖活动，发起活动之前给所有用户发短信提示他们购买了我们的产品有抽奖权益。然后用户上来进入抽奖页面点击爆增，过了一会儿页面就打不开了。后面查看了下各种日志，发现了瓶颈在数据库，由于读写冲突严重，导致响应变慢，有不少连接都超时了。后面看到监控和日志留下的数据，发现负责抽奖的微服务集群qps暴涨12倍，db的qps也涨了10倍。这很明显是一个高并发下如何摆脱数据库读写，I/O瓶颈的问题。 
 整点开抢后瞬时巨量的请求同时涌入，即使我们Nginx端做过初步限流，整个业务逻辑校验阶段运作良好，但是系统的瓶颈就转移到其他环节：大量的读写请求，导致后面的请求全部排队等待，等前面一个update完成释放行锁后才能处理下一个请求，大量请求等待，占用了数据库的连接！一旦数据库同一时间片内的连接数被打满，就会导致这个时间片内其他后来的全部请求因拿不到连接而超时，导致访问此数据库的其他环节也出现问题！所以RT就会异常飙高！ 
 于是我们在思考着怎么优化这个高并发下的抽奖问题
 
二. 优化思路
 
听了经验丰富的师兄的经验，也借鉴了下网上的一些思路，能采用的有效措施主要是:降级，限流，缓存，消息队列。主要原则是:尽量不暴露db,把大部分请求在服务的系统上层处理了。
 
三. 优化细节
 
抽奖详情页
 
a. 线上开启缓存 
 线上已写缓存逻辑，但是没有用switch开启。开启后可以减少数据库的并发IO压力，减少锁冲突。
 
b. 关于本地缓存淘汰策略的细节处理 
 缓存超过或等于限制大小全部清空。建议等于时不清空，而使用缓存淘汰算法:比如LRU,LFU,NRU等,这样不会出现缓存过大清空后，从数据库更新数据到缓存，缓存里数据依旧很大。导致缓存清空频率过高，反而降低系统的吞吐量。例如guava cache中的参数是 
 
//设置缓存容器的初始容量为10 
 initialCapacity(10) 
 //设置缓存最大容量为100，超过100之后就会按照LRU最近虽少使用算法来移除缓存项 
 maximumSize(100) 
 
抽奖逻辑
 
a.队列削峰 
 用额外的单进程处理一个队列，下单请求放到队列里，一个个处理，就不会有qps的高并发问题了。场景中抽奖用户会在到点的时间涌入，DB瞬间就接受暴击压力，hold不住就会宕机，然后影响整个业务。队列的长度保持固定，对于如果请求排队在队伍中靠后，比如奖品100个的情况下，中奖率10%，队列里请求任务超过1000时，就直接将后续的抽奖请求返回不中奖。用tair记录排队数，如果奖品没发完，再请空tair,允许请求继续入队列。这样队列起到了降级和削峰的作用。
 
b.将事务和行级悲观锁改成乐观锁 
 原来的代码是通过悲观锁来控制超发的情况。（比如一共有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。） 
 在原来的代码中用的是for update行锁，在高并发的情况下会很多这样的修改请求，每个请求都需要等待锁，某些线程可能永远都没有机会抢到这个锁，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。 
 可以采用乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。
 
c.对于与抽奖无直接关系的流程采用异步 
 比如抽奖成功之后的发短信功能另起一个线程池专门处理。这样可以提高请求的处理速率，提高qps上升后的乘载能力。
 
d.数据库的读写分离 
 现在的数据库查询都是读的主库。将数据库的大量查询改为从库，减轻主库的读写压力。主服务器进行写操作时，不影响查询应用服务器的查询性能，降低阻塞，提高并发。
 
e.同一时间片内，采用信号量机制 
 确保进来的人数不会过多导致系统响应超时： 信号量的采用，能够使得抽奖高峰期内，同一时间片内不会进入过多的用户，从底层实现上规避了系统处理大数据量的风险。这个可以配合队列进行限流处理。
 
f. 消息存储机制 
 将数据请求先添加到信息队列中（比如Tair存储的数据结构中），然后再写工具启动定时任务从Tair中取出数据去入库，这样对于db的并发度大大降低到了定时任务的频率。但是问题可能会出在保持数据的一致性和完整性上。
 
g.必要时候采用限流降级的测流 
 当并发过多时为了保证系统整体可用性，抛弃一些请求。对于被限流的请求视为抽不到奖。
 
３.额外考虑
 
a.防止黑客刷奖 
 防止黑客恶意攻击（比如cc攻击）导致qps过高，可以考虑策略在服务入口为相同uid的账户请求限制每秒钟的最高访问数。
 
b. 中奖数据预热 
 中奖只是少数，大部分人并不会中奖，所以可以在第一步便限制只有少数用户的请求能够打到真正抽奖逻辑上。是否可以考虑在抽奖之前先用随机算法生成一批中奖候选人。然后当用户请求过来时如果其中绝大多数请求都非中奖候选人，则直接返回抽奖失败，不走抽奖拿奖品的流程。少部分用户请求是中奖候选人，则进入队列，排在队列前面的获得奖品，发完为止，先到先得。 
 举个例子：10万个用户抽奖，奖品100个，先随机选出中奖候选人500个。用户请求过来时，不走抽奖查库逻辑的用户过滤掉99500个，剩余的候选人的请求用队列处理,先到先得。这样可以把绝大多数的请求拦截在服务上游不用查库，但是缺点是不能保证奖品一定会被抽完（可能抽奖候选人只有不到100人参与抽奖）。
 
四.设计架构图 
 
 
JS前端实现
 
 
核心函数是一个jQuery中旋转rotate插件 
 支持Internet Explorer 6.0+ 、Firefox 2.0 、Safari 3 、Opera 9 、Google Chrome，高级浏览器下使用Transform，低版本ie使用VML实现。
 
rotate（angle）angle参数：［Number］ – 默认为 0
 
根据给定的角度旋转图片例如：
 
$（"#img"）.rotate（45）;
或 $('#img').rotate({angle:45})
 
rotate(parameters)
 
parameters参数：[Object] 包含旋转参数的对象。支持的属性:
 
1.angle属性：[Number] – default 0 – 旋转的角度数，并且立即执行例如:
 
$("#img").rotate({angle:45});
 
2.bind属性：[Object] 对象，包含绑定到一个旋转对象的事件。事件内部的$(this)指向旋转对象-这样你可以在内部链式调用-$(this).rotate(…)。例如 (click on arrow):
 
$("#img").rotate({
bind: {
click: function () {
$(this).rotate({
angle: 0,
animateTo: 180
})
}
}
});
 
3.animateTo属性：[Number] – default 0 – 从当前角度值动画旋转到给定的角度值 （或给定的角度参数）例如: 结合上面的例子，请参阅使用。
 
4.duration属性：[Number] – 指定使用animateTo的动画执行持续时间例如 (click on arrow):
 
$("#img").rotate({
bind: {
click: function () {
$(this).rotate({
duration: 6000,
angle: 0,
animateTo: 100
})
}
}
});
 
5.step属性：[Function] – 每个动画步骤中执行的回调函数，当前角度值作为该函数的第一个参数
 
6.callback属性：[Function] 动画完成时执行的回调函数例如 (click on arrow):
 
$("#img").rotate({bind: {
click: function () {
$(this).rotate({
angle: 0,
animateTo: 180,
callback: function () {
alert(1)
}
})
}
}
});
 
getRotateAngle
 
这个函数只是简单地返回旋转对象当前的角度。
 
$("#img").rotate({
angle: 45,
bind: {
click: function () {
alert($(this).getRotateAngle());
}
}
});
 
stopRotate
 
这个函数只是简单地停止正在进行的旋转动画。
 
$("#img").rotate({
bind: {
click: function () {
$("#img").rotate({
angle: 0,
animateTo: 180,
duration: 6000
});
setTimeout(function () {
$("#img").stopRotate();
}, 1000);
}
}
});

 
 
一 项目背景
 
 
    略 公司内部资料以及安全红线 只讨论技术细节 不透漏相关交互和设计
 
 
二 交互以及视觉
 
 
    整体视觉：
 
 
    略
 
 
    抽奖模块：大概是以一个花朵的花瓣为抽奖背景，旋转的时候不同的花瓣点亮，省略视觉稿，只讨论技术实现细节
 
 
   
 
 
    交互：略
 
 
三 分析需要解决的问题
 
 
    当做一个没有做过的东西的时候，这时候应该分析下完成这个效果需要考虑的问题，然后分解分析，然后逐步实施，分析总结遇到过的问题，是否有没考虑到的。
 
 
    其实这种抽奖模块在现在的活动页中十分的常见，尤其是在活动页中。
 
 
    首先，整理了TODO List
 
 
 需要写成组件的形式，方便复用，需要考虑组件需要的传递的参数等等。
后端是接口的形式，也就是说，用户点击抽奖的时候，已经获得了中奖信息，前端需要执行一下抽奖轮转的动画，这个动画的时间、转动速率、转动期间禁止需要重复点击、初始的指针位置都需要前端来控制。
状态管理，针对不同抽奖次数、区分是否登陆、是否在APP内等相应的状态进行处理，弹窗或者跳转相应的URL
前端埋点相关和数据上报相关。
样式问题，设计交互的思路实际上是一个九宫格抽奖，但是视觉样式却是偏向指针类的轮盘抽奖，逻辑层面暂定的是按照九宫格的思路去实现，但是需要样式方面进行调整
抽奖的结果也需要写成一个弹窗组件，并且需要定义传入的参数
异常展示，当接口调用失败、后端数据库库存不足等等需要相应的warning弹窗组件


 
    大致交互流程如下
 
 
 四 具体设计
 
 
        4.1 封装成公共组件，主要是对组件传递的参数进行定义，首先在首页需要调用抽奖组件，必传的有三个参数
 
 
            showLuckDraw // 是否展示抽奖模块，如果用户已经抽过奖，默认不展示此模块，直接展示抽奖结果
 
 
            userStatus        // 用户状态：首页接口中会返回此信息，需要传入到组件中
 
 
            drawStatus       // 抽奖状态：
 
 
            此外还需要给抽奖组件的子组件–抽奖结果组件传递参数
 
 
            showSpecial&&type
 
 
 
 
 
 
        props: {
            // 是否展示抽奖模块，如果用户已经抽过奖，默认不展示此模块，直接展示抽奖结果
            showLuckDraw: {
                type: Boolean
            },
            // 用户状态
            userStatus: {
                type: Number,
                required: true
            },
            // 抽奖状态 0： 跳转活动页 1： 需要通过活动增加抽奖次数 3: 不可抽奖
            drawStatus: {
                type: Number,
                required: true
            },
            // 是否已登陆 未登陆吊起登陆组件
            hasLogin: {
                type: Boolean,
                required: true
            },
            // 特殊弹窗 展示抽奖的结果
            showSpecial: {
                type: Boolean,
                default: false
            },
            // 向抽奖结果弹窗 传的值 显示对应的抽奖结果
            type: {
                type: Number,
                required: true,
            }
        },
 
 
    4.2 抽奖动画（核心逻辑）
 
 
        核心的思路是，当点击抽奖的时候，调用后端接口，并且设置转盘所需要的初始参数，包括如下
 
 
diff               速度累加变量，控制逐渐加快/逐渐减慢
star              开始按钮点击态，如果用户已经无法抽奖，直接禁用
speed          抽奖初始速度
 
isDisable     是否禁用开始抽奖按钮，防止重复抽奖，保证在在抽奖动画结束后才能再次抽奖，避免重复调用后端接口        
 
 
drawStatus  设置抽奖状态初始值
 
startTime     记录转动开始时间，用来控制动画时长


 
      同时，设置一个定时器，轮盘的背景图片依次切换来实现动画的效果，利用定期器的milliseconds 时间间隔进行速度控制，当达到预设的转动时间时，开始做减速运动，且如果后端返回的奖品id和前端设置的奖品id能对应上时，清除定时器，同时return中止函数，且重新设置转盘的状态值，完成抽奖动画。
 
 
    html 部分使用的简洁的jade，虽然刚开始上手有些不适应，但是用惯了之后，感觉十分简洁干净，不需要在大段的html代码里寻找calss等
 
 
 
<template lang="jade">
    .award-box(v-if="showLuckDraw")
        .award-bg
            .award(:class="'active' + (current)")
        button.start-btn(
            @click="start",
            :disabled="isDisable",
            :class="star ? 'star': '' "
            )
        .award-num 当前抽奖次数  
            i.award-n {{ currentNum = +this.drawStatus === 2 ? 1 : 0 }}   
            i 次
        special-dialog(:show-special="showSpecial", :type="id")
</template>
 
 
 
 
 
 
        
        move() {
                let timeout = setTimeout( () => {
                    this.current++; // 切换背景图，初始值可以随意设置
                    if ( this.current > 4) { // 因为只有5个奖品，所以当current 从0开始大于4的时候，重新加载第一张图片
                        this.current = 0;
                    }
                    // 若抽中的奖品id存在，且转动时间大于2秒，则开始减速转动
                    if ( this.award.id && ( Date.now() - this.startTime ) / 1000 > 2 ) {
                        this.speed += this.diff; // 转动减速
                        //若转动超过4秒，并且奖品id等于格子的奖品id，则停下来
                        // this.awards 是从后端获取的中奖结果，如果和前端对应的奖品id对应上的话则为中奖
                        if ( ( Date.now() - this.startTime ) / 1000 > 4 && this.award.id == this.awards[this.current].id ) {
                            clearTimeout( timeout );
                            this.star        = false;
                            this.isDisable   = false;
                            this.showSpecial = true;    // 调用抽奖结果组件
                            this.type        = this.id; // 将中奖结果赋值给type，显示对应的抽奖结果组件
                            setTimeout( () => {
                                console.log(this.award.id);
                            },0);
                            return; // 抽中奖后停止定时器
                        }
                    //若抽中的奖品不存在，则加速转动    
                    } else { 
                        // todo:如果后端接口200且返回的中奖结果是错的，这里可以处理下异常
                        this.speed -= this.diff;
                    }
                    this.move();
                }, this.speed );
            },
 
 
    4.3 状态管理，在调用move() 抽奖动画的之前，就对相应的用户状态做处理，未登陆的吊起登陆，没有次数的去获取次数，不可抽奖调用弹窗等等
 
 
    4.4 埋点这里在工具函数里封装了一个公共的函数，直接调用传参记录埋点信息，关于埋点的话有空再展开
 
 
    4.5 样式方面，遇到了一些问题
 
 
最开始的想法是只改变花瓣的背景图,但是最后发现，图片是不规则的，是有角度的，难以定位准确。而且定位位置的计算在不同机型上有差异，所以采用整体图片的替换
整体图片的替换又遇到一个闪烁问题：
成因：因为当图片花瓣旋转时视觉上只是每个花瓣的变化，实际上是整张图片的变化，通过动态的切换calss来完成背景图片的替换。正因为这样，新的问题就产生了，当代码构建部署打包发不到线上时，静态资源一般会有单独的服务器，也就是说图片的资源请求会有一定延迟，这就导致了第一次加载点击抽奖的时候，页面花瓣转动会有闪烁，而第二次图片会走缓存，所以这个问题只出现一次，但是却是致命的
解决方法：把url改为base64的Data URL，实际上就是利用base64编码把图片数据翻译成标准ASCII字符，Data URL是在本地直接绘制图片，不是从服务器加载，所以节省了HTTP连接，起到加速网页的作用，但是弊端就是IE8以下浏览器不支持这种方法（当然app内肯定是支持的，绝大部分手机也是支持的）。用这种方法会加重客户端的CPU和内存负担，总之有利有弊，而且不适合大图片，针对这个图片找UI替换了体积更小的图片，以减轻客户端的内存负担。
 
    4.6 针对中奖结果的弹窗，封装另一个组件，只需要传递type的参数就显示不同的中奖结果，类似的还有挂在到全局的弹窗组件，异常的时候及时抛出错误弹窗
 
 
五 总结和反思
 
 
    虽然说现在活动页比较多且交互复杂，但是可以尽可能的封装一些公共的组件，提供基本的骨架，只需要修改一些css就能快速完成一个功能。
 
 
    还有对于没有做过的东西要具体分析，拆解成步骤，一步一步的完成，同时预留好一定的buffer时间，最重要的，经常总结与反思，查找自身的不足，在繁忙的工作中提升自己。
 
 
 
 
转载于:https://www.cnblogs.com/Sherlock09/p/11199980.html

 
现在的一些网络抽奖公平可信吗？你怎么看？
 
我本身就是长沙理工大学软件系的学HTML java 等专业。 抽奖平台一般都是网页设计的 理念的逻辑对于网页上的大量中奖什么贵重物品的选项一般后台设置的都是千万分之一的中奖率。所以我个人觉得娱乐一下就好了 没必要为了这个中大奖去“守株待兔”一样天天蹲在哪里
 
怎么用java或其他语言写出腾讯的抽奖系统？
 
e……
 
这么简单直接的问题完全把我难住了，腾讯的抽奖系统到底指的是哪个？
 
你问这种问题的话，很可能会得到一个思路，而具体实现还是需要自己去思考的，你不会是想要具体代码吧？
 
php抽奖系统怎么设计？
 
此时一位码农路过，并留下个人见解。
 
其实抽奖系统主要的就是一个概率问题。常规的做法主要有在后台设置商品之后可以设置概率，然后根据概率来获取区间，例如四个商品，抽中概率分别为10%，20%，30%，40%，则分别为这四个商品生成4个区间，分别是[1，10]，[11，30]，[31，60]，[61，100]，然后在抽的时候随机一个数，从1到100，然后循环从区间里匹配，看随机数是否在区间里，在的话就选择那个区间的产品。
 
最后，喜欢的小伙伴可以给我点赞或者是关注我哦。