- 说说你最近做的这个项目的背景?
- 随着中国通信行业竞争程度的加剧,竞争的形态也发生了巨大的变化,从以产品、价格为主的竞争转向以服务为主的竞争,服务成为主导竞争格局的重要因素。渠道作为企业完成客户沟通、产品/服务交换过程以及实现价值、产生效益的重要载体,发挥了采集、传达客户和竞争对手等市场信息,为买卖双方提供便利,协调供需矛盾,为客户提供合适的产品与服务,向客户传递产品/服务信息,实现营销/服务目标等重要的功能。
- 小蜜蜂商城,一方面可以带动传统业务绩效提升,增强客户满意度和粘性,另一方面,也为基于互联网的商务模式创新奠定基础。
- 针对上述行业环境变化和业务战略目标,上家公司在网上终端预约销售基础上,即将启动网上商城建设项目,用于建立网上终端、营销案在线销售及相关辅助功能,包含商品管理、订单管理、类目管理、客户管理、合作商管理、客服管理、购物平台、内容管理等,很大程度上分担了人工的压力,对提高客户服务效率和客户满意度能够起到较好的作用
电商的两种运行模式:
B2C:商家对用户
B2B:商家对商家,再对用户
- 整个项目的功能架构如何?
系统前台:
- 单品页面(终端+营销案)2、购物车(面试经常问)3、首页4、用户中心
系统后台【对账管理:每天都要进行下单与银行的钱是否一致】
1、订单管理2、今天发布3、商品管理
- 这个项目为用户提供了哪些服务?包括哪些模块?
- 后台包含商品管理、订单管理、类目管理、客户管理、合作商管理、客服管理、支付平台、内容管理等,很大程度上分担了人工的压力,
- 前台包括个人中心,购物车,商城首页,商品详情页(静态化),提交订单页,支付页面等页面构成,对提高客户服务效率和客户满意度能够起到较好的作用。
- 你承担这个项目的哪些核心模块?
- 购物车模块(登录前的购物车,登录后的购物车)
- 订单模块(防止超卖,校验库存)
- 这些模块的实现思路说一下
- 订单模块
-
- 购物车模块
- 登录前,购物选择商品加入购物车存放在cookie
- 登录后,将redis中的购物车取出来,整合cookie中的购物车
- 购物车信息存在redis,设置失效时间为30天,30天未购买将失效重选规格
- 购物车模块
- 项目中哪些功能模块设计了大数据访问,怎么解决?
系统前台是互联网上的用户访问的,会有大量用户来访问。
- 假定有1w个人打开你的网站来订商品,问你如何解决并发问题(可扩展到任何高并发网站要考虑的并发读写问题)
问题,1w个人来访问,商品没出去前要保证大家都能看到有商品,不可能一个人在看到商品的时候别人就不能看了。到底谁能抢到,那得看这个人的“运气”(网络快慢等)
其次考虑的问题,并发,1w个人同时点击购买,到底谁能成交?总共只有一张商品。
解决方案:这种高并发我们可以用锁 同步
同步更多指的是应用程序的层面,多个线程进来,只能一个一个的访问,java中指的是syncrinized关键字。
锁也有2个层面:
一个是java中谈到的对象锁,用于线程同步;
另外一个层面是数据库的锁;如果是分布式的系统,显然只能利用数据库端的锁来实现。
假定我们采用了同步机制或者数据库物理锁机制,如何保证1w个人还能同时看到有商品,显然会牺牲性能,在高并发网站中是不可取的。使用hibernate后我们提出了另外一个概念:乐观锁(一定要用)、悲观锁(即传统的物理锁);
采用乐观锁即可解决此问题。乐观锁意思是不锁定表的情况下,利用业务的控制来解决并发问题,这样即保证数据的并发可读性又保证保存数据的排他性,保证性能的同时解决了并发带来的脏数据问题。
- 你碰到了哪些问题?你是怎么解决的?
- 上线的时候一定要把支付的假接口换成真接口。
- 项目中用到了曾经没有用过的技术,解决方式:用自己的私人时间主动学习
- 订单提交时由于本地bug或者意外故障导致用户钱支付了但是订单不成功,采用对账方式来解决。
- 做完这个项目有哪些收获?
首先,在数据库方面,我现在是真正地体会到数据库的设计真的是一个程序或软件设计的重要和根基。因为数据库怎么设计,直接影响到一个程序或软件的功能的实现方法、性能和维护。由于我做的模块是要对数据库的数据进行计算和操作的,所以我对数据库的设计对程序的影响是深有体会,就是因为我们的数据库设计得不好,搞得我在对数据库中的数据进行获取和计算利润、总金时,非常困难,而且运行效率低,时间和空间的复杂也高,而且维护起来很困难,过了不久,即使自己有注释,但是也要认真地看自己的代码才能明白自己当初的想法和做法。加上师兄的解说,让我对数据库的重要的认识更深一层,数据库的设计真的是重中之重。
其次,就是分工的问题。俗话也说,分工合作,分好了工,才能合作。我们在分工之前分好了模块,每个模块实现什么功能,每个人负责哪些模块。本以为我们的分工是明确的,后来才发现,我们的分工是那么的一踏糊涂,一些功能上紧密相连的模块分给了两个人来完成,使两个人都感到迷惘,不知道自己要做什么,因为两个人做的东西差不多。我做的,他也在做,那我是否要继续做下去?总是有这样的疑问。从而导致了重复工作,浪费时间和精力,并打击了队员的激情,因为自己辛辛苦苦写的代码,最后可能没有派上用场。我也知道,没有一点经验的我犯这样的错是在所难免,我也不过多地怪责自己,吸取这次的教训就好。分工也是一门学问。
还有就是做项目时要抓准客户的要求,不要自以为是,自己觉得这样好,那样好就把客户的需求改变,项目就是项目,就要根据客户的要求来完成。
- 项目介绍
小蜜蜂商城项目打造的是“社区+电商”的模式,用户不只是在社区中有自己的圈子,还可以将电商加入到社区中,整个电商网站实现的功能非常之多,采用分布式的架构设计,包括后台管理、前台系统、订单系统、单点登录系统、搜索系统、会员系统等。
①该项目是自己公司的产品,我们公司负责整个网站的运营,属于B2C平台;
②系统的用途,主要是提供B2C的平台,其中自营商品也有商家入住,类似天猫。
③系统架构,采用分布式的系统架构,其中前台系统和单点登录系统采用了集群的方式部署,在后台管理系统中采用了Maven的多模块化的管理,其中采用了水平切分的方式,将pojo、dao、service分层开发,这样做的好处就是可以重用性更高。
系统之间的通知机制采用MQ的方式,使用RabbitMQ的实现,使用了RabbitMQ的消息订阅模式的消息机制;
部署方面,采用了Nginx+tomcat的模式,其中nginx的作用一方面是做反向代理、负载均衡、另一方面是做图片等静态资源的服务器。
技术架构:使用市场上比较主流的spring+springmvc+springboot+mybatis进行开发,采用分布式的系统架构,前台系统和单点登录系统采用了集群的方式部署,后台管理系统中采用了Maven的多模块化的管理,其中采用了水平切分的方式,将pojo、dao、service分层开发,这样做的好处就是可以重用性更高。搜索系统使用了solr实现,在保证系统高性能的前提下,尽可能为公司节约成本,我们使用MySQL数据库进行集群(oracle收费)。在部署方面,采用了Nginx+tomcat的模式,其中nginx的作用一方面是做反向代理、负载均衡、另一方面是做图片等静态资源的服务器。
功能架构:分布式系统架构图
谈到分布式架构,我们必须对比传统架构才能彰显其优势。
①最为明显的一点,在传统的架构中,如果某个功能需要进行维护,那么我们必须停掉整个服务,这对于公司的运营会造成损失。分布式系统在核心功能模块使用单独服务器,维护部分模块不影响用户的其他操作。
②在海量数据处理方面,传统架构显得比较乏力;分布式系统架构采用服务器集群,使用负载均衡,海量数据处理游刃有余!
③在性能(检索)以及维护方面,分布式系统架构也有较为明显的优势。
传统架构图:
- 介绍项目的步骤
- 我的项目是***商城,该项目是给***专卖店做的电商项目,电商项目分为b2b2c,b2c。
- 项目的用途:***网上商城项目,用于建立网上终端、营销案在线销售及相关辅助功能,在网上来卖鞋类,服装类,以及开展一些团购,秒杀一些活动,给中国特步公司带来最大的利润。
- 项目的模块:商品管理、订单管理、类目管理、客户管理、合作商管理、客服管理、支付平台、内容管理等,很大程度上分担了人工的压力,前台包括个人中心,购物车,商城首页,频道页,商品详情页,提交订单页,支付页面等页面构成
- 我所负责的模块:订单管理 ,购物车
订单管理的设计思路描述: