项目（2）——某游戏*多语言版本十连抽的开发

需求主要描述:
    当前主流的放置类抽卡游戏，海外版的搞的营销活动。需要满足不同国家的，三种语言版本的切换，用户首先登录页面完成抽奖动画，同时拿到十连抽的奖品，一等奖品一份，2等奖品随机0-2份，3等奖品7-9份。用户完成抽奖之后，
需要邀请三个玩家助力，助力成功后，用户返回自己的抽奖界面，指定需要领取游戏的账号，发放游戏道具。

主要开发技术栈:

后端接口+后台  Tp6+layUI
 前端实现  VUE3

主要开发点:

1. 常规的调通谷歌/facebook/apple授权登录游戏接口，同时调通和游戏APP里面的交互逻辑
2. 实现多语言版本的识别，和无缝切换，同时不同语言版本的用户归属到不同用户群组里去，能查看用户发放的奖品
3. 游戏道具非常多，加上道具是有活动码/礼包码/授权码/服务器端识别码之类的，所以游戏配置工作量非常大，需要后台加上部分辅助功能
4. 十连抽的逻辑算法实现，因为是必须确保一等奖品一份，二等奖品0-2份，三等奖品7-9份，而且每个等级奖品里面，每个奖品的实现概率也是不同的，需要设计区分
5. 抽奖的时候，需要考虑到用户并发问题，助力的时候可能出现的锁问题

相关开发思路设计:
1.框架的多语言版本是需要制作不同的语言包，但是根据需求分析，我们只需要100个不到的提示和关键点是多语言版本。而且有些多语言版本并不是文字显示，是融入到背景里面的，所以这部分其实可以简化。也就是设计一张多语言对应版本的数据表，因为开发和初期测试都是我们内部，整个泰语和越南语，我们自己也是看的很费劲。当前端访问A语言网站的时候，参数的header里面会带一个我们约定的lang的字段，这样直接根据前端传递过来的头部字段就可以知道当前所属的语言版本。改装我们统一的API输出函数，让全部的API接口根据错误码，返回出对应语言的报错。关键点，头部header里面带有语言标志，返回结果不能按照之前统一输出，而是根据不同的语言种类和不同的错误码输出不同的语种文案提示。

2.游戏道具是一张很长不规范的EXCEL数据表，对相关EXCEL进行处理。使用phpOffice插件对excel进行处理，按照格式化后，导入到系统里面。由于不同的语言种类，不同道具的的卡密和活动码是不同的，包括每种语言的 名字 图片 标题 密码 称呼 都不一样，之前想拆开成每个语言的每个产品都单独管理，但是不方便后台人员编辑，最终决定合并成一张大数据表，40多个字段的大数据表，同时也方便EXCEL进行管理。

数据表的大表设计是禁忌区，一般表多了之后，会考虑拆表，不过这个场景有点特殊，因为总共就一百来个奖品，后面奖品几乎是不会变动，只是各个国家的礼包码和活动码，授权码之类的会变动。关键点:EXCEL规范化处理excel，同时设计一张大数据表，惯性思维会拆表，而其实我们频繁调用这些奖品的显示信息，我们是不更新的时候，是默认读取缓存里面的。

3.十连抽的算法设计  最开始不清楚规则的时候，以为是把一个方法循环读取十次随机。后面需要确保1-2-3等奖按照规则呈现。实际上分成了三个大组进行抽奖操作。也就是一个人进活动区里面触发了三个抽奖活动，而第三个活动是受到第二个活动的结果影响的。因为发放的是虚拟物品，所以是不存在库存概念的，只存在不同奖品的种类概念。
整理的抽奖逻辑是这样的:先抽奖1次品级1等奖区。然后2次抽2等奖区，这后面俩次抽奖结果完全独立，不受影响，根据拿到的结果。返回给3等奖抽奖区，而三等奖也设计一个抽奖区，考虑到三等奖组合是7-9个组合，抽奖可能性太多，产品对7个增加了3个类型奖品固定，8个增加了6个奖品候选组，9个奖品增加了9个奖品候选组。这样用户抽到的3等奖的奖品是按照我们希望呈现的方式出现的，而三等奖奖品是均分三区概率实现。这样其实只用一次抽奖就实现了循环7-9次的效果。关键点的开发:控制品级概率的设计，奖品组的抽奖简化了循环逻辑的循环

4. 邀请时候触发的锁问题，A/B/C用户同时点击D发出来的邀请,因为我们是新增了本次邀请活动的num人数的，这个时候，A/B/C同时给D助力了，但是D只增加了一个助力数据，导致出现了列表助力人数的时候，是对的上的，但是我们判断依赖的是num，导致逻辑对不上。这个地方，需要考虑到CAS算法+事物逻辑，助力失败让失败的用户重新助力即可，不会存在对不上数据情况。这样是以牺牲了用户的部分体验为代价，但是确保了数据的唯一性。
 简单CAS逻辑就是把 db->where(uid,$uid)->update([num=>$num+1]) 变成db->where([uid=>$uid,num=>num])->update([num=>$num+1])

确保了逻辑的完备性。

同样更新用户是否抽了奖的标记字段，

db->where([uid=>$uid has_draw=>0])->update([has_draw=>1])这样如果完成第一个抽奖，第二次抽奖必然是无法执行成功，导致并发绕过了第一层redis的锁的时候，防御第二层，第三层防御是mysql设计的时候，确定抽奖用户sid的本次活动的唯一性，利用唯一索引（唯一索引有个弊端就是自己测试逻辑的时候，每次都要去删除抽过的奖，否则执行失败，增加了测试需要反复测试概率的时候工作量）。 关键点: 理解事物的逻辑，理解锁的背后机制和原理，理解CAS算法的优越性还有带来的用户体验弊端。