21.商城秒杀的实现?
答:抢购、秒杀是如今很常见的一个运用处景，紧张须要办理的问题有两个：
1 高并发对数据库产生的压力2 竞争状态下如何办理库存的精确减少（\公众超卖\"大众问题）
对付第一个问题，已经很随意马虎想到用缓存来处理抢购，避免直接操作数据库，例如利用Redis。第二个问题，我们可以利用redis行列步队来完成，把要秒杀的商品放入到行列步队中，由于pop操作是原子的，纵然有很多用户同时到达，也是依次实行，文件锁和事务在高并发下性能低落很快，当然还要考虑其他方面的东西，比如抢购页面做成静态的，通过ajax调用接口，个中也可能会涌现一个用户抢多次的情形，这时候须要再加上一个排队行列步队和抢购结果行列步队及库存行列步队。高并发情形下，将用户进入排队行列步队，用一个线程循环处理从排队行列步队取出一个用户，判断用户是否已在抢购结果行列步队，如果在，则已抢购，否则未抢购，库存减1，写数据库，将用户入结果行列步队。
22.购物车的事理?
答:购物车相称于现实中超市的购物车，不同的是一个是实体车，一个是虚拟车而已。用户可以在购物网站的不同页面之间跳转，以选购自己喜好的商品，点击购买时，该商品就自动保存到你的购物车中，重复选购后，末了将选中的所有商品放在购物车中统一到付款台结账，这也是只管即便让客户体验到现实生活中购物的觉得。做事器通过追踪每个用户的行动，以担保在结账时每件商品都物有其主。
紧张涉及以下几点:
1、把商品添加到购物车，即订购 2、删除购物车中已定购的商品 3、修正购物车中某一本图书的订购数量 4、清空购物车 5、显示购物车中商品清单及数量、价格
实现购物车的关键在于做事器识别每一个用户并坚持与他们的联系。但是HTTP协议是一种“无状态(Stateless)”的协议，因而做事器不能记住是谁在购买商品，当把商品加入购物车时，做事器也不知道购物车里原来有些什么，使得用户在不同页面间跳转时购物车无法“随身携带”，这都给购物车的实现造成了一定的困难。
目前购物车的实现紧张是通过cookie、session或结合数据库的办法。下面剖析一下它们的机制及浸染。
cookie
cookie是由做事器产生，存储在客户真个一段信息。它定义了一种Web做事器在客户端存储和返复书息的机制，cookie文件它包含域、路径、生存期、和由做事器设置的变量值等内容。当用户往后访问同一个Web做事器时，浏览器会把cookie原样发送给做事器。通过让做事器读取原来保存到客户真个信息，网站能够为浏览者供应一系列的方便，例如在线交易过程中标识用户身份、安全哀求不高的场合避免用户重复输入名字和密码、门户网站的主页定制、有针对性地投放广告等等。利用cookie的特性，大大扩展了WEB运用程序的功能，不仅可以建立做事器与客户机的联系，由于cookie可以由做事器定制，因此还可以将购物信息天生cookie值存放在客户端，从而实现购物车的功能。用基于cookie的办法实现做事器与浏览器之间的会话或购物车，有以下特点：
1、cookie存储在客户端，且占用很少的资源，浏览器许可存放300个cookie，每个cookie的大小为4KB，足以知足购物车的哀求，同时也减轻了做事器的负荷；2、cookie为浏览器所内置，利用方便。即利用户欠妥心关闭了浏览器窗口，只要在cookie定义的有效期内，购物车中的信息也不会丢失；3、cookie不是可实行文件，以是不会以任何办法实行，因此也不会带来病毒或攻击用户的系统；4、基于cookie的购物车哀求用户浏览器必须支持并设置为启用cookie，否则购物车则失落效；5、存在着关于cookie陵犯访问者隐私权的辩论，因此有些用户会禁止本机的cookie功能。
session
session是实现购物车的另一种方法。session供应了可以保存和跟踪用户的状态信息的功能，使当前用户在session中定义的变量和工具能在页面之间共享，但是不能为运用中其他用户所访问，它与cookie最重大的差异是，session将用户在会话期间的私有信息存储在做事器端，提高了安全性。在做事器天生session后，客户端会天生一个sessionid识别号保存在客户端，以保持和做事器的同步。这个sessionid是只读的，如果客户端禁止cookie功能，session会通过在URL中附加参数，或隐含在表单中提交等其他办法在页面间传送。因此利用session履行对用户的管理则更为安全、有效。
同样，利用session也能实现购物车，这种办法的特点是：
1、session用新的机制保持与客户真个同步，不依赖于客户端设置；2、与cookie比较，session是存储在做事器真个信息，因此显得更为安全，因此可将身份标示，购物等信息存储在session中；3、session会占用做事器资源，加大做事器真个负载，尤其当并发用户很多时，会天生大量的session，影响做事器的性能；4、由于session存储的信息更敏感，而且因此文件形式保存在做事器中，因此仍旧存在着安全隐患。
结合数据库的办法
这也是目前较普遍的模式，在这种办法中，数据库承担着存储购物信息的浸染，session或cookie则用来跟踪用户。这种办法具有以下特点：
1、数据库与cookie分别卖力记录数据和坚持会话，能发挥各自的上风，使安全性和做事器性能都得到了提高；2、每一个购物的行为，都要直接建立与数据库的连接，直至对表的操作完成后，连接才开释。当并发用户很多时，会影响数据库的性能，因此，这对数据库的性能提出了更高的哀求；3、使cookie坚持会话有赖客户真个支持。
各种办法的选择：
虽然cookie可用来实现购物车，但必须得到浏览器的支持，再加上它是存储在客户真个信息，极易被获取，以是这也限定了它存储更多，更主要的信息。以是一样平常cookie只用来坚持与做事器的会话，例如海内最大确当当网络书店便是用cookie保持与客户的联系，但是这种办法最大的缺陷是如果客户端不支持cookie就会使购物车失落效。
Session能很好地与交易双方保持会话，可以忽略客户真个设置。在购物车技能中得到了广泛的运用。但session的文件属性使其仍旧留有安全隐患。
结合数据库的办法虽然在一定程度上办理了上述的问题，但从上面的例子可以看出：在这种购物流程中涉及到对数据库表的频繁操作，尤其是用户每选购一次商品，都要与数据库进行连接，当用户很多的时候就加大了做事器与数据库的负荷。
23.redis行列步队前辈先出须要把稳什么?
答:常日利用一个list来实现行列步队操作，这样有一个小限定，以是的任务统一都是前辈先出，如果想优先处理某个任务就不太好处理了，这就须要让行列步队有优先级的观点，我们就可以优先处理高等别的任务，实现办法有以下几种办法：
1）单一列表实现：行列步队正常的操作是 左进右出（lpush,rpop）为了先处理高优先级任务，在碰着高等别任务时，可以直接插队，直接放入行列步队头部（rpush），这样，从行列步队头部（右侧）获取任务时，取到的便是高优先级的任务（rpop）
2）利用两个行列步队，一个普通行列步队，一个高等行列步队，针对任务的级别放入不同的行列步队，获取任务时也很大略，redis的BRPOP命令可以按顺序从多个行列步队中取值，BRPOP会按照给出的 key 顺序查看，并在找到的第一个非空 list 的尾部弹出一个元素，redis> BRPOP list1 list2 0
list1 做为高优先级任务行列步队
list2 做为普通任务行列步队
这样就实现了先处理高优先级任务，当没有高优先级任务时，就去获取普通任务
办法1最大略，但实际运用比较局限，办法3可以实现繁芜优先级，但实现比较繁芜，不利于掩护
办法2是推举用法，实际运用最为得当
24.你卖力的模块有哪些难题?
答:在我卖力的B2B电商项目中，当时我卖力的是订单模块，由于客户一次选择了多家商户的商品，最终生成了一个订单，这样我们平台在给商户结算时涌现了不知道这比用度该当给哪个商户，这时候我们小组经由谈论，须要涉及到订单拆分，也便是说用户点击支付后,如果有多件商品,并且不是同一家店铺那么 就要用到订单的拆分,比如如果有两件商品,并且不是同一店铺 就在原来的订单号下 在天生两个子订单号 并修正订单表中两件商品的订单号。终极实现了商品的分配管理，办理了我们的难题。
我以为在开拓过程中，碰着的难题无非是两个，一个是技能层次的，我认为，只要你有恒心，有热心，没有以为不了的难题。另一个便是沟通问题，在任何地方任何时候沟通都是最主要的，尤其是我们做开拓的，不沟通好，会影响全体项目的进度，我本人是个非常还沟通的人，以是这点上也没多大问题。
25.用户下单是怎么处理的?
答:判断用户有没有登录，在没有登录的情形下，不许可下单。上岸后，可进行下单,并天生唯一的订单号，此时订单的状态为未支付。
26.电商的登录是怎么实现的?
答:分为普通登录和第三方登录 这边紧张说一下第三方登录吧，第三方上岸紧张利用的是author协议，我就以QQ的第三方上岸为例来进行解释：当用户在我们的站点要求QQ的第三方上岸时，我们站点会勾引用户跳转到QQ的上岸授权界面， 当用户输入QQ和密码成功登录往后会自动跳回到我们站点设置好的回调页面，并附带一个code参数，接着你利用code再次去要求QQ的授权页面，就可以从中获取到一个access token（访问令牌），通过这个access_token，我们可以调用QQ供应给我们的接口，比如获取open_id，可以获取用户的基本信息。获取到之后，我们须要拿用户的授权信息和open_id和我们平台的普通用户进行绑定。这样不管是普通用户上岸还是第三方上岸用户，都可以实现上岸。
27.接口安全方面是怎么处理的?
答:我们当时是这么做的，利用HTTP的POST办法,对固定参数+附加参数进行数字署名,利用的是md5加密,比如:我想通过标题获取一个信息,在客户端利用 信息标题+日期+双方约定好的一个key通过md5加密天生一个署名(sign),然后作为参数通报到做事器端,做事器端利用同样的方法进行校验,如何接管过来的sign和我们通过算法算的值相同，证明是一个正常的接口要求，我们才会返回相应的接口数据。
28.用的什么技能实现短信发送，在哪调用?
答:我紧张用的第三方短信接口，在申请接口时进行相应信息的配置，然后在我们站点须要用到短信验证的地方进行调用，我们常日在用户注册时利用到。
29.在事情中碰着什么困难?
答:总体来说：在事情我紧张碰着这几个问题比较难处理：
①我之前事情的时候创造常常会涌现一些临时需求打乱了我的操持，搞得有时候这个任务还没完成，又得去做其他的任务，末了一天下来，大大小小的东西是很多，但是没有完成得非常好的，后面我总结了一下，我会把这些都添加优先级，碰着临时需求，按照优先级重新将已有任务和临时任务进行排版，担保在规定韶光内有效率的完成优先级高的任务。
②在做项目需求时候，碰着理解能力欠佳的人，沟通时随意马虎被气到，影响自己的感情，末了反倒还不能到达须要的效果。后面，每次到这种时候，我一样平常会借助一些纸质的、更加形象的东西，让双方都认同的、都能明白的一种办法来进行沟通，后面减少了很多不必须的麻烦。大家都知道，对付程序员来说，改需求是一件很痛楚的事情，以是前期的沟通事情很主要。
③还有一件事时，我以前的领导不太懂技能，以是每次出一个新的需求出来，总是哀求我们在很短的韶光内完成，完不成我们就会被疑惑能力有问题。当然，每个领导都希望自己的员工能够尽快的完成任务，降落本钱，提高效率。这时候我会把我们的需求细化，把个中的重点、难点都列出来，做好韶光方案，耐心的跟领导沟通，项目每个点的主要性和韶光的花费比例，确保在这个方案的韶光点内保质保量的完成任务。逐步的也得到了领导的认可，实在领导也不是一味的不通情理，只要把东西操持好了，以最小的代价换取最高的代价，每个人都是很随意马虎理解得
30.用户不登录，怎么直接加入购物车的?
答:用户在不登录的情形下，可以把要购买商品的信息（如商品的ID，商品的价格、商品的sku_id,购买数量等关键数据）存到COOKIE里面，当上岸的情形下。把COOKIE里面的内容存到数据库，并打消cookie中的数据。
31.写过接口吗，怎么定义接口的?
答：写过。接口分为两种：一种是数据型接口，一种是运用型接口。
数据型接口：是比抽象类更抽象的某种“构造”——它实在不是类，但是跟类一样的某种语法构造，是一种构造规范，规范我们类要以什么格式进行定义，一样平常用于团队比较大，分支比较多的情形下利用。
运用型接口： API（application interface） 数据对外访问的一个入口
我紧张是参与的APP开拓中接口的编写，客户端须要什么样的数据，我们就给他们供应相应的数据，数据以json/xml的格式返回，并且配以相应的接口文档。
32.sku减库存?
答:SKU = Stock Keeping Unit (库存量单位)
即库存进出计量的单位，可以是以件，盒，托盘等为单位。SKU是库存量单位，区分单品。
在服装、鞋类商品中利用最多最普遍。 例如纺织品中一个SKU常日表示：规格、颜色、格局。
在设计表时，不仅仅只有商品表，商品表中有个总库存，我们还须要涉及一张SKU表，里面有SKU库存和单价字段，用户每购买一件商品，实际上购买的都是SKU商品，这样不才订单成功后，该当根据所购买的商品的唯一的SKU号来进行相应的SKU库存的减少，当然商品的总库存保存在商品主表中，也须要减少总库存中的库存量。
33.库存设置？
答:库存分为商品总库存和SKU库存，每每商品总库存的为SKU库存的总和。一样平常在商城的后台对货品设置最高库存及最低库存后，当前库存数量与最高、最低两者比较，超出库存或者低于库存的，则被统计成报脸色势反响，便于用户节制货品库存超、短缺状态及数量。
34.订单、库存两个表 如何担保数据的同等性？
答：在一个电子商务系统中，正常的该当是订单天生成功后，相应的库存进行减少必须要担保两者的同等性，但有时候由于某些缘故原由，比如程序逻辑问题，并发等问题，导致下单成功而库存没有减少的情形。这种情形我们是不许可发生的，MySQL的中的事务刚好可以办理这一问题，首先得选择数据库的存储引擎为InnoDB的，事务规定了只有下订单完成了，并且相应的库存减少了才许可提交事务，否则就事务回滚，确保数据同等性。
35.O2O用户下单，c端下单，如何担保ba端数据同等？
答：O2O为线上和线下模式，O2O模式奉行的是“线上支付+实体店消费”的消费模式，即消费者在网高下单完成支付后，凭消费凭据到实体店消费。 O2O模式是把商家书息和支付程序放在线上进行，而把商品和做事兑现放在线下，也便是说O2O模式适用于快递无法投递的有形产品。数据同等性的问题是O2O行业中最常见的问题，我们可以类似于数据库的主从复制的思路来办理这个问题.O2O有个供应商系统，类似于主理事器，在ç端（从做事器）下单时，数据同步更新到供应商系统端，b，a实时从供应商系统中拉取数据进行同步，比如利用定时任务，定时拉取数据进行同步。
36.Redis如何防止高并发?
答：实在redis是不会存在并发问题的，由于他是单进程的，再多的命令都是一个接一个地实行的。我们利用的时候，可能会涌现并发问题，比如得到和设定这一对。Redis的为什么 有高并发问题？Redis的的出身决定
Redis是一种单线程机制的nosql数据库，基于key-value，数据可持久化落盘。由于单线程以是redis本身并没有锁的观点，多个客户端连接并不存在竞争关系，但是利用jedis等客户端对redis进行并发访问时会涌现问题。发生连接超时、数据转换缺点、壅塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成。
同时，单线程的天性决定，高并发对同一个键的操作会排队处理，如果并发量很大，可能造成后来的要求超时。
在远程访问redis的时候，由于网络等缘故原由造成高并发访问延迟返回的问题。
办理办法
在客户端将连接进行池化，同时对客户端读写Redis操作采取内部锁synchronized。
做事器角度，利用setnx变向实现锁机制。
37.秒杀当中的细节你是怎么得出来的?
答:通过性能测试及仿照秒杀场景。每个问题都经由反复测试，不断的创造问题，不断的办理。
38.做秒杀用什么数据库，怎么实现的?
答:由于秒杀的一瞬间，并发非常大，如果同时要求数据库，会导致数据库的压力非常大，导致数据库的性能急剧低落，更严重的可能会导致数据库做事器宕机。这时候一样平常采取内存高速缓存数据库redis来实现的,redis是非关系型数据库，redis是单线程的，通过redis的行列步队可以完成秒杀过程。
39.支付宝流程怎么实现的?
答:首先要有一个支付宝账号，接下来向支付宝申请在线支付业务，签署协议。协议生效后有支付宝一方会给网站方一个互助伙伴ID,和安全校验码，有了这两样东西就可以按照支付宝接口文档开拓支付宝接口了，中间紧张涉及到一个安全问题。全体流程是这样的：我们的网站通过post通报相应的参数（如订单总金额，订单号）到支付页面，支付页面把一系列的参数经由处理，以post的办法提交给支付宝做事器，支付宝做事器进行验证，并对吸收的数据进行处理，把处理后的结果返回给我们网站设置的异步和同步回调地址，通过相应的返回参数，来处理相应的业务逻辑，比如返回的参数代表支付成功，变动订单状态。
40.什么是单点登录？
答:单点登录SSO（Single Sign On）说得大略点便是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也便是用户的一次登录能得到其他所有系统的信赖。
