Jimmychoo商城系统总结

一、需求

1.游戏模块

①在进入H5之前,首先有一个动态的探照灯的动效,然后由“淡出”效果到H5首页。

②在点击“开始游戏”之后会有一段动画演示游戏内容,然后滑动开启游戏,开始计时。

③成功找到目标短语之后,进入下一关。总共5关,难度递增。

④滑错之后,会提示滑错惩罚,第一次计时加2秒,后面每次递增1秒。

⑤有“提示”按钮,有两次提示的机会,点击确定使用后会将正确的短语亮起荧光,两次机会用完提示按钮消失。

⑥5关全部成功之后,显示游戏成绩以及击败对手的百分数。可以查看排行榜,会显示前10名+个人成绩。

2.商城模块

I、打开首页,会有一段文字描述商城以及销售条款。点击“即刻拥有”开始购物流程。

II、点击“即刻拥有”之后,跳转到商品列表页面,会显示商品的品名,类型,图片。商品列表是下滑类型的页面。

III、点击每个商品可以查看商品详情,可以左右滑动查看3个视角的产品图片。鞋类的商品有选择尺码和尺码参考这两个功能,包类的没有。点击查看产品详情可以查看商品介绍,可以加入购物袋。

IV、选择尺码的时候列出所有的尺码,并且当这个码数只有一双的时候提示,仅剩一双。

V、点击“加入购物袋”,如果商品售罄会跳转至售罄页面,如果没有跳转至购物袋。

VI、购物袋页面,以列表的形式把购物袋内容显示出来,并且可以删除。如果其中某款商品无货,则该商品的背景成为灰色。可以点击“结算”按钮,如果结算成功跳转至支付页面。

VII、结算的过程中要实时的计算商品的库存,如果库存不足则不能结算成功,有多人同时结算同款产品的压力。

VIII、支付页面  分为配送方式、发票信息、支付方式三部分,配送方式是必填,支付方式固定是微信支付,发票信息选填。点击“支付”按钮,调起微信支付,支付成功跳转至订单页面。

IX、支付失败  会检测支付订单是否超时,如果超时跳转至首页。

X、订单页面,按照每个订单的商品分开显示,未支付的订单会有“付款”、“取消”两个按钮,支付的订单会有“收货地址”、“查看物流”、“申请售后”三个按钮。

XI、“取消”或者订单超时订单都会显示交易关闭,“付款”会跳转至付款页面,“收货地址”会显示用户的收货地址,“查看物流”会显示用户订单的真实物流信息,“申请售后”会显示售后电话。

 二、设计

1.游戏模块

 动画、效果方面主要由前端来实现,这里不做解释。后端在游戏部分主要包括三个方面:

①玩家在通关游戏之后的分数记录

②排行榜的计算

③游戏通关之后的分享和分享页面的显示

2.商城模块

 商城模块除了一些页面的排版、显示需要前端来实现,其他的功能全部交由后端。主要功能包括:

①商品列表的显示,以及从个kol进来之后各产品和导航的隐藏与显示

②商品单品页商品的各项属性显示,如价格、图片、模特图、产品介绍等

③购物袋页面,要显示客户购买的东西 ,可以删除商品,添加商品,结算购物袋

④结算页面,要显示与修改客户的收货地址、发票信息、以及折扣信息(后来加的)、微信H5内公众号支付

⑤结算成功后,跳到成功页面;结算失败后,跳到订单页面。

⑥订单页面,显示客户的所有订单号、订单状态,以及订单内的各个单品信息、收货地址、物流信息等

三、实现以及问题

1.游戏模块

  游戏部分是一个类似图案滑动解锁的游戏,在你触摸那些单词划过“I want choo”这几个单词的时候,就会过关。连续闯过5关,游戏结束。每一关的难度会有提升,每关游戏的图案是随机生成的,其中用到的技术(我知道的,因为我不是前端,只负责后端以及交互的 部分)有下面这些:

①图案解锁

  图案解锁用的是一个patternlock.js的插件,在已有插件的情况要考虑的就是这个游戏难度的事情。一开始应客户要求,最少要有50个以上的图案供玩家玩,结果一开始客户代表还准备傻傻的去画50种图案放上去。后来考虑到这个图案可能真的会画死人,最后决定用随机生成一个图案里面所有需要的字母,然后用canvas画在页面上。最后用patternlock.js这个js触摸解锁这个答案。效果如下:

在触摸滑动这些单词错误的时候会有错误的音效提示,在点击“提示”后会在正确的“i want choo”上面呈现粉色。

 ②计时器

  问题:

  1.香港客户反应,计时器走的很慢,不是正常的一个秒数转换,而且越走越慢。

  2.会出现完了00:00.00的用户

  原因:

  计时器的话,一开始用的是setinterval,让他1000毫秒的时候,秒数位置上加1;60秒的时候分钟上面+1;听起来是不是很合理没有一点毛病,然后只要计算出开始时间和结束时间,获得他们的差值就是这个人游戏时间。其实这是错误的。

  1.setinterval和settimeout的机制是把你要执行的代码在你设定的那个时间点插入js引擎维护的一个代码队列中,但是插入队列代码并不意味着马上执行,因为js解释引擎是单线程运行的。他会等到前面的代码先执行完之后才会来执行这个队列中的代码,因为平时页面代码很少,js执行很快,所以平时我们感觉到定时器在你设置的那一刻他就开始运行了,运行的很平稳,这是一种错觉。在你设置定时器的时候获取开始时间只是代码设置的时间,并不是定时器任务开始的时间。并且setInterval的回调函数并不是到时后立即执行,而是等系统计算资源空闲下来后才会执行.而下一次触发时间则是在setInterval回调函数执行完毕之后才开始计时,所以如果setInterval内执行的计算过于耗时,或者有其他耗时任务在执行,setInterval的计时会越来越不准,延迟很厉害.

  2.获取时间这里也是有漏洞的,我们平时用的Date.now()获取到的是从1970年1月1日00:00:00 UTC开始经过的毫秒数,他会根据系统时间来检索当前的时间戳。非常不幸的是,这个函数会因为用户代理不同而不一样,精度非常不可靠,在同一时间不同地方获取到的时间戳是不同的。

  3.说起来第一次看到出现00:00.00秒的用户,我的第一反应是我提交游戏数据的接口被攻击了,别人肯定是利用了其他的非法手段给我提交数据,我一点都没怀疑前端。我检查了后端的代码,有微信授权不太可能在微信之外的浏览器打开,但是微信授权是可以使用模拟器模拟出来的,我当时想的是他肯定是用模拟器抓包,然后提交到了我的接口导致了00:00.00的记录。后来去查看了当时记录数据的方法,结果真的有一点漏洞,虽然我验证了cookie和提交方式post,但是还是有漏洞的,cookie可以伪造,post也可以模拟提交。我以为我发现了真正的原因,并向他们保证肯定不会有问题。结果第二天测试的人一玩,又出现了00:00.00,瞬间打脸。我有点不知所措,这个时候才开始认真思考真正的漏洞在哪里,是我一开始想的太多了。出现这种情况无非原因有两种:①我的接口记录这一块出了问题导致记录成了00:00.00②前端传过来的时间就是00:00.00接口我仔细检查了代码是没有问题的,那就只有一种可能前端传过来的值就有问题。后来经过努力好不容易搞到了那台出问题手机的型号,系统版本号和微信版本号,我们拿相同的版本号测试发现,计时器他居然不走,一直是00:00.00所以才导致了这种事情。后面会写为什么出现这种情况,下面是后端的记录代码(tp5)

  解决方案

  1.时间精度不准的情况下,采用了H5的新接口Performance接口。Performance接口提供当前时间在毫秒级的分辨率,使他不受系统时间的偏斜或者调整,在2012年10月23日成为了W3C的推荐。Performance.now()获取到的是当前时间的毫秒数,他精确到了千分之一毫秒。这个新接口拥有这诸多好处,但是新生事物有一个缺点就是兼容性,支持该API的浏览器很少,IE10,firefox15+以及谷歌浏览器,ios系统必须在9以上,安卓必须在4.0以上。就是因为低版本系统不支持的原因,所以会有部分手机根本就没获取到开始时间导致了00:00.00的发生。后来我们提出建议,做一个补偿机制,就是在客户手机不支持这个最新接口的情况下,才用new Date().getTime()来获取时间,然后在计算他们之间的时间差,最后统一返回一个计算好的时间差。但是当时项目已经上线,客户表示这个修改很大怕影响在线的效果,才用了另外一种办法。如果客户的手机不支持最新接口,那么提示他升级系统之后再来玩,下面是测试支持情况的代码。

如果这个接口不被支持,那么就会返回null。

  2.针对setinterval机制的问题,我们采用了requestAnimationFrame。requestAnimationFrame采用系统时间间隔,保持最佳绘制效率,不会因为间隔时间过短,造成过度绘制,增加开销;也不会因为间隔时间太长,使用动画卡顿不流畅,让各种网页动画效果能够有一个统一的刷新机制,从而节省系统资源,提高系统性能,改善视觉效果。他不会去等待其他任务执行完才执行,有效的提高了计时的精度。

2.商城部分

  相信大部分人都做过商城,像商品列表,单品这种是肯定没有问题的,这里就不做介绍了,只介绍一些可能出问题的功能。

  1.购物袋功能

   问题

  在通过按钮加入购物袋这个操作,我们一般会用ajax提交到购物袋之后跳转到购物袋页面,但是对这个按钮的点击没有做限制,导致有时候客户感觉只点击了一次,但是却是加入了两件商品到购物车,客户体验很差。

  解决方案

  1.在提交到购物车页面这里,点击提交到购物车按钮才用同步提交到后台,等待后台返回的时候在进行下一步跳转到购物袋页面。2.就是用一个flag来控制提交,在提交的时候变成false,只有等待提交成功了变成true,才可以再次提交,但是这个只能在正常情况下使用。

  2.结算功能

  问题

  在购物袋页面,点击结算跳转到结算页面,然后在返回购物袋页面,这个时候购物袋页面应该是空的。这个操作在安卓上面是没有问题的,但是在iphone上面就有问题,在结算页面的时候,点击返回到上一页的时候,他读取了栈中的缓存,并没有重新加载那个页面。结果就成了点击返回,上一页被结算的那些商品还摆在那里,但是点击结算结算的数据也为空,点击删除的数据也是空的。

  解决方案

  这个问题就是在于iphone点击返回的时候,让他刷新返回的页面。在这里页面写js刷新是没用的,因为在点击返回的时候读取的是缓存,相当于在页面刚进来的刷新了,这个时候再返回它是不会刷新的。关键在于怎么捕捉iphone手机的返回事件。这里我采用的是H5的另外一个新接口history,在页面跳到下一个页面的时候在堆栈中replacestate替换掉这个页面,然后在用户点击返回的时候会触发popstate事件。这个时候因为在堆栈的history中页面已经被替换了,所以再返回的时候就会刷新这个页面。代码如下:

 

  3.支付页面

  问题

  在支付页面,用户填写了打折的手机号码的时候,会有一个优惠价给到客户,然后客户可以用优惠价来支付,但是支付的那些信息在页面加载的时候已经生成好了,里面包含了金额,如果有优惠价格的时候修改不了

  解决方案

  微信支付在生成prepay_id的时候,会涉及到商户订单号,价钱。这些东西在页面加载的时候已经生成并且显示到了页面上,如果这个人不是优惠客户,那么使用这个已经生成好的jsapi支付是可以的。如果这个人是优惠客户的时候,因为要修改价格,如果拿以前的订单号和价格去生成prepay_id,去调起微信的jsapi支付,就会报错商户订单号重复。这个时候我们可以重新生成一个订单号,然后用新的订单号和价格重新生成一个prepay_id来调起微信支付,代码如下

这里要注意的是返回的json信息要转换为json对象才可以成功的调起微信支付。

  4.支付回调

  问题

  在支付成功的时候,会触发微信的回调,这个时候才算真正的完成这个订单。但是有的时候回调成功,有些时候回调不成功,但是真实存在付款。

  解决方案

  微信支付回调的时候,回调的链接一定不能携带任何参数,不然就会导致回调失败。有时候回调成功,有时候回调不成功,可能的原因是你有构造函数或者其他验证的东西,微信在通过这些东西的时候被拦截了,并且跳到了其他的页面,我就是因为下面原因导致回调有时不成功:

  

  后来,我在另外一个单独的控制器中做了回调验证,这个问题就解决了。

  5.库存问题

  问题

  在商城中的很多商品是有库存的,他们不能超卖,因为没有那么多货品,要在售卖的时候保证出售的数量不能超过库存

  解决方案

  一般情况下是不会发生超卖这种事情的,因为在并发不是很高的情况下,mysql这类的关系型数据库也可以完全支撑。但是在高并发的情况下,数据库的读写速度太快的时候,会导致锁表。很多操作都在等待前面的执行完毕释放了之后才能执行,结果可能会导致数据库挂掉。这个时候就用到了我们的nosql。我在这里使用的是redis,他可以支撑10W的并发,足以应付很多场景。redis有两种办法可以控制库存,string和list,我推荐使用list。因为虽然redis的string也是原子性的操作,比如现在的库存是5,六个人同时买了之后,他肯定是-1,而不可能是其他数字。redis的string虽然可以当成数字来计算,可以使用incr和decr进行原子性的递增递减操作,但是它是可以见到负数的,你可以想象一下你的库存已经是负数了,它还在减是什么样的情况。这种情况很有可能发生。

  所以我用了list,在用户点击商品的时候,把该商品的对应信息加载到redis缓存list中。每次有人购买了商品,就用lpop弹出一个队列元素,如果队列的长度为0了,他就会返回false而不会继续减下去,很好的避免了在库存已经为0的情况下超卖出去。

  这里还有一个问题是如果购物车中的商品有很多种,每种商品的库存是不一样的,如果在结算的过程中,在没有结算完毕的情况下,某种商品没有库存了,这个结算不成功。这个时候需要告知客户那样商品没有了,并且分别返回他们各自的库存,因为有的结算了,有的没结算。这里大家可以使用事务来控制,逐条来结算购物车商品,如果有没有的商品就回滚,保证了数据库数据的完整性。但是redis这边没有这么完整的事务支持的,如果有某几件商品已经操作reidis减去库存了,这个时候怎么办呢?

  我在循环开始前,定义了一个数组$command。在循环操作redis的时候,每操作成功一条就把操作的这个key加入到$command这个数组中。一旦某件商品没有库存了,我就循环这个数组,把减去的库存全部加回来,比用数据库事务要方便点。

 

  

 

 

  小弟才疏学浅,文笔不精,哪里有写的不对的或者不好的地方,欢迎大家指正!

  

  

需求->设计->实现->测试->交付

转载于:https://www.cnblogs.com/lina520/p/7560569.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值