抢红包(多个小红包、总金额固定红包),用户投资收益结算三个场景的技术解决方案思路

第一个场景,p2p公司在每天的1点,3点,5点整把标的放出来,一个标的200万金额,每个用户都可以抢随机金额投资,比如可以买5千,买1万等,抢红包的人数高峰期有30万,这个标的不限制抢购人数,直到这个标的被抢完为止,要防止并发,又要扛得住用户数,这个场景用什么方案

第二个场景,p2p公司搞活动抢红包,红包总金额5千万,分成100万个小红包,每个小红包金额随机,每个用户可以抢多个红包,同时抢红包的用户数量有30万,如何解决并发的问题
 
第三个场景,分布式计算收益,类似于余额宝,每天需要用Job定时去给每个投资用户做收益统计,总投资用户数有5千万,为了提高可靠性和加快计算时间,需要开多台Job服务器分批对用户进行收益计算,每个用户只能计算一次收益,不能被多台Job服务器重复计算,如果某些用户的收益计算失败或一定时间内没有计算完成,需要有补偿机制,这个方案如何设计
 
解决思路:
 
红包业务两个场景的方案
第一个场景解决方案,用一个固定金额的redis key把余额存起来,然后对余额做incr操作,拿到剩余数据大于等于0的可以做下单业务。
 
第二个场景解决方案,用1000万个redis队列,出列成功可以做抢红包业务。
 
第三个场景解决方案
分布式收益结算处理方案

1.用定时任务中心将要结算收益的用户发送到MQ队列中,用户数据从数据库拉取,拉取的时候按userId升序排序
2.将用户数据推送到MQ后,要记录最后入列的userId,任务中断时,重启任务后可以从最后入列成功的userId处继续入列MQ
3.MQ出列的时候,获取一个得到任务的Redis锁
4.每天一个收益表,用userId作为主键插入一条统计数据,做幂等处理
5.验证数据库的收益计算状态,做幂等处理,防止重复计算收益
6.业务处理
7.业务处理成功需要更新状态
8.消息通知业务
9.补偿计算收益,定时Job对比基础users表与userStat表的数据,users表存在但userStat表不存在,说明漏掉了计算收益,
  userStat表的状态不等于2,说明收益处理失败,都需要重新计算

出列
onConsumer((message) =>{
  if(redisCache.Add(得到任务_@userId,1,When.NotExist, 30秒过期) == false)
  {
    return;
  }
  //userId设为主键,用主键约束一条数据只能统计一次
  if(insert usersStat_20190816(userId,createTime,state,amount,income) values(@userId,now(),0,@amount,0) == 0)
  {
     return;
  }
  var data = select * from usersStat where userId=@userId and state=0;  

  //数据库要验证状态,因为用redis集群可能会有多个线程同时拿到锁
  if(data != null && (update usersStat_20190816 set state=1 where userId=@userId and state=0) >=1)
  {
         //处理业务        
         //处理完成回写表
         var rows = update usersStat_20190816 set state=2,income=@income where userId=@userId and state=1;
         if(rows >= 1)
         {

             //处理成功,做其它非收益功能业务,比如消息通知,消息通知用MQ解藕
         }
         else{
           //重复计算收益了,回滚
         }
  }

});
原文地址:https://www.cnblogs.com/yyee/p/12779291.html