成功的路上总是离不开贵人的帮助,名师的指点和小人的刺激。

莫怕,过了桥,就翻篇了

项目中遇到的问题总结

1.实现一个排期的问题(按天排期)

设计一个按天排期的任务,当保存发布的时候会一次性存进当天开始算的180天的库存记录,

每当过了一天,会在第二天定时任务插入一条顺延一天的记录,同时安插一张日志表,加入事务

控制,每天是否执行顺延一天,当中发现某几天的记录失败,可能是服务器Duang机导致,过了

时间点,没有执行定时任务,或者执行的时候抛出异常,

解决方案,可以再设置多次定时任务,每次去读日志表,发现没有记录,则执行操作,但是万一服务器维护

一天,还是没能补回顺延一天的记录, 这时考虑可以采取用户下单的时候,会选择一个时间段,通过时间段

可以计算出理论上有多少天,同时当减少库存的时候会去查那张表,如果两个长度对应不上,那么就说明有

一些天数没有定时任务执行成功,这时通过时间段计算出一个总日期集合,再通过已存在的日期集合,取其

差集,这时再通过批量插入的方式还原其正确的时间段。

2.排期得相关设计

要实现3种类型的排期

a.按时间段排期

b.按天排期

c.按月排期

a:按时间段排期是指当后台商家通过一天24小时的时间轴概念,可以任意选择营业时间范围,然后通过这个营业范围,假设

选取的时间点是从7:00-11:00,则会根据这个时间范围,生成一个个时间段,以半小时为计算点,这里就变成了7:00,7:30

8:00,...10:30,11:00,然后通过其后台设置的最大同时接单数,相当于每个时间点最多可接单的数量,相当于那个时间点的库存数量,

同时设有一个服务耗时的概念,指的是完成一项服务需要消耗的时间,但实际生活中完成一项服务,然后再实现下一个服务的时候,

中间会有一段服务间隔时间,所以继续加入一个服务间隙时长,这个时间必须大于服务耗时,同时考虑到服务时间点的下单会影响

到这个服务时间点上面和下面的当前库存量,这时先忽略对之前时间点的库存影响,譬如最大接单数是5,服务间隙是1小时,假设

买家在9点中下单2个数量,则9点库存变成3,9点半的库存也变成3,但是不考虑8点及7点半等的库存影响,之前设计的是商家发布

服务的时候,只记录他保存的当前营业时间点的库存记录,同时,当下完单后,对应去减少库存,同时展现给买家看到一个日历格式

的时间表,从这个表里就能看到,由于考虑到到了第二天就能看到新的排期时间库存,而且展现给买家的是2周的时间排期,所以设计

服务发布的时候,就生成从当天开始算14后的所有排期,数据库中有一个排期的时间记录,有一个日期及时间点,同时,随着时间的

推移,假设过了一天,买家能看到后面一天的记录,所以在每天的0:01分做了一个定时任务,通过这个定时任务,写一个sql脚本,

定期更新数据库插入顺延一天的记录。 以上方案看似已经很完美了,但是存在一个问题,假设后台商家又去修改了营业时间范围以及

最大接单数,怎么办,这时就会打破之前设计的所有逻辑,不知道该如何计算,这时考虑到这种情况,推翻之前的所有,设计两张表,一

张模板表,记录每个时间点的最大接单数量,而且时间点改成了0-23:30,而不是只记录有效营业时间,同时设置一个字段记录当前时间

有效还是无效,另外一张表就是记录当前某某日期下单的数量表,然后通过两表关联,实现排期数量的库存控制,同时废弃了定时任务。

b: 按天排期的逻辑,也设有1个最大接单笔数,同时不设定时间,考虑到后面的交易流程是一个连续的时间段,就相当于一个时间日历,

这个是采用上述的方案,只记录180内的时间,一个字段是最大接单数,另一个字段就是下单数量,减库存逻辑和上述一样,耗时是按1天算,

买家选择从哪天开始到哪天结束,即可计算出当前的哪几天减库存,这时,在通过上述按时间段排期的定时任务,顺延插入后一天的记录实现。

c:按月排期,商家后台设计一个最大接单数,同时还有一个开始时间起几个月,服务详情页面展示是一个日历,以及下面展示月份,买家可选择

一个开始时间以及服务时间月的数量,

有两种理解,1,商家设置的时间比如是2018.5.1开始3个月,则详情页展示的是一个日历2018.5.1到2018.8.1为可选的接单时间,下面的月份

默认设置为36个月,用户可自行选择,用户设置的最大接单数就是一个库存,直接根据下单量进行减少

2.商家设置的时间是一个有效的经营时间范围,买家可以在这段时间内进行下单,下单时候的月份数量选择是会根据时间的推移进行递减的,

同时库存数量的控制计算也是根据用户下单的数量及月份进行对应那些天数数量进行递减,由于计算复杂,没有采取这种方案,而是采用了方案1。

3.实现商品变体的问题

4.关于订单过期处理的问题

5.关于实现权限问题

业务场景:目前会员可以更改编辑自己之前编辑发布的服务信息,而员工可以去查看会员的编辑页面,之前是做两套代码,但是考虑到后面需求更改,

需要维护两套代码,这时,就采取nginx转发到同一个页面,但是需要保证员工不能操作会员编辑页的一些敏感信息,这时利用js的aop实现解耦,

不更改之前代码的情况下,添加一个前置判断方法,来做权限控制

6.关于使用dubbo的时候调用service层的时候,不能传递空,否则调用不到方法

7.mybatis高版本可支持传递表占位符,但是不支持了#{0}

8.关于订单提交加密算法,出现javamd5加密和jsmd5加密结果不一致,中文导致

 

posted on 2018-05-10 20:23  痞子陈2016  阅读(271)  评论(0编辑  收藏  举报

导航