点赞掉会员业务的场景与发红包类似，都是基于库存的抢操作，只是，点赞掉会员有概率机制。

具体概率算法不在此次总结范围内。

点赞掉会员与红包场景极大不同的是，点赞抽奖的前置条件较多，如：

1，存在未领奖的，

2，已经中了多次奖的，

3，观看时长不够的

4，库存不足的

5，最后还要进行概率事件抽奖

不过与红包场景相同的是，前置条件充分满足后，才进行后续核心操作。

以及库存判断操作同样是在redis中计算得出，库存够，才进行下一步抽奖操作。

目前业务量不大，前置条件验证，以及核心抽奖操作都是于同一个服务完成的。业务量大了后

两部分也可以分开处理：

1，前置服务：规则验证，库存验证，读请求量大，过滤无效请求，再将有效请求转发下一层

2，抽奖服务：执行核心抽奖处理，写请求量大，成功则通知IM消息，再通知用户。

因为库存量的限制，以及概率限制，计算概率还可使用RPC服务，由他服务实现，抽奖服务

只管更新库存，落地。

那块服务压力大了，就加哪里的机器。

点赞掉会员这块，由于成功率很低，平均3000次请求，才能触发一次更新库存的操作。所以这里

没有用redis做库存实时计算，而是先查库，后更新redis库存。此处redis库存操作只存了一个状态，有还是没有。而不是存的剩余数量。