1.1 SOA

面向服务架构，服务之间通过定义良好的接口进行通信，dubbo就是soa的典型实现

特点：松散耦合，可重用服务，标准化服务接口

1.2分布式

将不同的业务模块拆分到不同的机器上，解决高并发问题

1.3 Nginx集群

将同一个业务部署在多台机器上，提高系统的高可用性

1.4 项目里面遇到的最大的问题是什么

新技术的学习吧，比如redis，事务什么的，用redis处理抢购

1.5你觉得开发中什么最重要

概念一定要理清，不能想当然

逻辑要清晰，严谨

抽象能力要强

看清问题本质，提高效率

编码规范

1.6开发怎么提高效率，性能

概念清晰，逻辑一定要清晰严谨

使用工具类，比如说mybatis逆向工程生成映射文件

性能的话能用最简便的方法不使用繁琐的逻辑

1.7网站并发数

支持3000左右的并发，可以满足目前的业务需求。由于系统是分布式架构，支持水平扩展，如果将来并发量提高的话，可以增加服务器来提高并发量

1.8人员配置

l 产品经理：1人，确定需求以及给出产品原型图。

l 项目经理：1人，项目管理。

l 前端团队：3人，根据产品经理给出的原型制作静态页面。

l 后端团队：8人，实现产品功能。

l 测试团队：3人，测试所有的功能。

l 运维团队：2人，项目的发布以及维护。

1.9开发周期

迭代开发，一个月迭代一次,每一次迭代都包括了需求分析、设计、编码和测试，在一次迭代中完成系统的一部分功能或业务逻辑

2.0项目的开发流程

需求分析，概要设计，详细设计，开发，测试

2.2 服务器宕机怎么看

服务器上有运行服务检测工具或者脚本，自动检测，有异常就会报告，具体怎么做的可以说有运维做

2.3 安全性问题（别的网站使用爬虫技术爬你的网站怎么办？有没有安全措施）

单位时间内请求次数超过某个阈值就让输入验证码，可以极大降低抓取的速度，如果多次超过某个阈值可以加入黑名单。还有就是页面内容使用json返回，数据经常变一变格式，或者js动态生成页面内容

2.4订单表的数据量太大,我把订单分到许多表中,那么我我想用一条sql查处所有的订单,怎么解决?

分库情况下：可以使用mycat数据库中间件实现多个表的统一管理。虽然物理上是把一个表中的数据保存到多个数据库中，但是逻辑上还是一个表，使用一条sql语句就可以把数据全部查询出来。

单库情况下：需要动态生成sql语句。先查询订单相关的表，然后将查询多个表的sql语句使用union连接即可

2.5对数据库只是采用了读写分离,并没有完全解决数据库的压力,那么有什么办法解决

如果数据库压力确实很大的情况下可以考虑数据库分片，就是将数据库中表拆分到不同的数据库中保存，可以使用mycat中间件

2.6商品存入数据库怎么保证数据库数据安全

数据库定期备份

用户安全管理：用户操作数据库时，必须通过数据库访问的身份认证

数据加密

日志追踪：追踪对数据库的操作

2.7 Tomcat启动容量，初始值

tomcat默认初始的内存值xms是128m，需要调整的话就改变JAVA_OPTS 增加参数：JAVA_OPTS='-Xms256m -Xmx512m'

2.8前端有哪些控件

Ocupload：一键上传

Kindeditor：富文本编辑器

Ztree：树控件

City-picker：省市联动

2.9 bootstrap相较于其他前端框架有什么优势

简单，好用，模板可以直接套用

栅格化系统，能自适应移动端

文档丰富

3.0事务一定要在业务层加吗

一般配置在业务层，只有配置在业务层，出现异常时才会自动回滚

配置在dao层的话，只有数据库操作异常时会回滚

配置到web层的话，也可以，但是引起异常的情况就更多，除非安全性特别高，而且controller层只支持注解式的事务

3.1用了什么bug管理工具

Teambition  禅道

3.2 你最近在研究什么技术

Nosql，大数据

3.3 系统功能

本商城系统是一个综合性的B2C平台，类似京东商城、天猫商城。

·       会员可以在商城浏览商品、下订单，以及参加各种活动。

·       商家可以在入住淘淘商城，在该平台上开店出售自己的商品，并且得到淘淘商城提供的可靠的服务。

·       管理员、运营可以在平台后台管理系统中管理商品、订单、会员等。

·       客服可以在后台管理系统中处理用户的询问以及投诉。

3.4电商行业技术特点

①技术新：(NoSql推广首在社区网站和电商项目)，发展快，需求推动技术的革新。

②技术范围广：除了java，像淘宝前端还使用了PHP，数据库MySQL或者oracle，nosql，服务器端使用Linux，服务器安全、系统安全

③分布式：以前是在一台机器上做运算，现在是分散到很多机器上，最后汇总起来。(集中式向分布式进行考虑)由需求来推动

④高并发、集群、负载均衡、高可用：由并发问题采用集群进行处理，其中，集群会涉及服务器的主从以及分布问题，使用负载均衡。(权重高低)高可用是对用户而言，用户的服务不中断(系统升级，服务不中断，淘宝每周更新2次)。

⑤海量数据：双11,570亿的背后，订单有多少？浏览次数有多少？商品会有多少？活动相关数据？

⑥业务复杂：不要简单的认为是：商品展示出来后，加入购物车后购买就完成了。后台特别复杂，比如优惠(包邮、满减)

⑦系统安全：系统上线必须通过系统安全部门审核通过。前年CSDN数据泄露。快捷酒店数据泄露(通过身份证就可以查看你的开房记录)。近几年，安全意识逐步在提高。

3.6商品搜索框的搜索联想如何实现？比如输入“羽绒” ，然后输入框下会列出很多关于羽绒服的搜索条件 “羽绒服男正品折扣 ”等等。

     可以用搜索的模糊查询，把查询出来的结果放到redis中缓存，

3.7做促销时，商品详情页面的静态页面如何处理价格问题。

京东商品详情页虽然仅是单个页面，但是其数据聚合源是非常多的，除了一些实时性要求比较高的如价格、库存、服务支持等通过AJAX异步加载加载之外，其他的数据都是在后端做数据聚合然后拼装网页模板的。整个京东有数亿商品，如果每次动态获取如上内容进行模板拼装，数据来源之多足以造成性能无法满足要求；最初的解决方案是生成静态页，但是静态页的最大的问题：

1、无法迅速响应页面需求变更；

2、很难做多版本线上对比测试。如上两个因素足以制约商品页的多样化发展，因此静态化技术不是很好的方案。

数据主要分为四种：商品页基本信息、商品介绍（异步加载）、其他信息（分类、品牌、店铺等）、其他需要实时展示的数据（价格、库存等）。而其他信息如分类、品牌、店铺是非常少的，完全可以放到一个占用内存很小的Redis中存储；而商品基本信息我们可以借鉴静态化技术将数据做聚合存储，这样的好处是数据是原子的，而模板是随时可变的，吸收了静态页聚合的优点，弥补了静态页的多版本缺点；另外一个非常严重的问题就是严重依赖这些相关系统，如果它们挂了或响应慢则商品页就挂了或响应慢；商品介绍我们也通过AJAX技术惰性加载（因为是第二屏，只有当用户滚动鼠标到该屏时才显示）；而实时展示数据通过AJAX技术做异步加载

1、接收商品变更消息，做商品基本信息的聚合，即从多个数据源获取商品相关信息如图片列表、颜色尺码、规格参数、扩展属性等等，聚合为一个大的JSON数据做成数据闭环，以key-value存储；因为是闭环，即使依赖的系统挂了我们商品页还是能继续服务的，对商品页不会造成任何影响；

2、接收商品介绍变更消息，存储商品介绍信息；

3、介绍其他信息变更消息，存储其他信息

技术选型

MQ可以使用如Apache ActiveMQ；

Worker/动态服务可以通过如Java技术实现；

RPC可以选择如alibaba Dubbo；

KV持久化存储可以选择SSDB（如果使用SSD盘则可以选择SSDB+RocksDB引擎）或者ARDB（LMDB引擎版）；

缓存使用Redis；

SSDB/Redis分片使用如Twemproxy，这样不管使用Java还是Nginx+Lua，它们都不关心分片逻辑；

前端模板拼装使用Nginx+Lua；

数据集群数据存储的机器可以采用RAID技术或者主从模式防止单点故障；

因为数据变更不频繁，可以考虑SSD替代机械硬盘。

核心流程

1、首先我们监听商品数据变更消息；

2、接收到消息后，数据聚合Worker通过RPC调用相关系统获取所有要展示的数据，此处获取数据的来源可能非常多而且响应速度完全受制于这些系统，可能耗时几百毫秒甚至上秒的时间；

3、将数据聚合为JSON串存储到相关数据集群；

4、前端Nginx通过Lua获取相关集群的数据进行展示；商品页需要获取基本信息+其他信息进行模板拼装，即拼装模板仅需要两次调用（另外因为其他信息数据量少且对一致性要求不高，因此我们完全可以缓存到Nginx本地全局内存，这样可以减少远程调用提高性能）；当页面滚动到商品介绍页面时异步调用商品介绍服务获取数据；

5、如果从聚合的SSDB集群/Redis中获取不到相关数据；则回源到动态服务通过RPC调用相关系统获取所有要展示的数据返回（此处可以做限流处理，因为如果大量请求过来的话可能导致服务雪崩，需要采取保护措施），此处的逻辑和数据聚合Worker完全一样；然后发送MQ通知数据变更，这样下次访问时就可以从聚合的SSDB集群/Redis中获取数据了。

基本流程如上所述，主要分为Worker、动态服务、数据存储和前端展示；因为系统非常复杂，只介绍动态服务和前端展示、数据存储架构；Worker部分不做实现。

3.8.点一个链接访问到一个页面，这个页面上既有静态数据，又有动态数据（需要查数据库的），打开这个页面的时候就是很慢但是也能打开。怎么解决这个问题，怎么优化？

如果要静态页面的话 那就得用freemarker或者通过ajax异步,通过js操作异步刷新表单,通过js对返回结果组装成html。

缓存、动态页面静态化：

所谓缓存, 是指将那些经常重复的操作结果暂时存放起来, 在以后的执行过程中, 只要使用前面的暂存结果即可.

那么在我们开发Web网站的过程中, 到底有多少工作可以采用用缓存呢? 或者说, 我们可以在哪些地方使用缓存呢? 见下图: 下图是客户端浏览器和Web服务器之间的一次完整的通信过程, 红色圆圈标示了可以采用缓存的地方.

首先, 最好的情况是客户端不发送任何请求直接就能获得数据, 这种情况下, 用于缓存的数据保存在客户端浏览器的缓存中.

其次, 在具有代理服务器的网络环境中, 代理服务器可以针对那些经常访问的网页制作缓存, 当局域网中第一台主机请求了某个网页并返回结果后, 局域网中的第二台主机再请求同一个网页, 这时代理服务器会直接返回上一次缓存的结果, 并不会向网络中的IIS服务器发送请求, 例如: 现在的连接电信和网通线路的加速器等. 但是代理服务器通常有自己专门的管理软件和管理系统, 作为网站开发人员对代理服务器的控制能力有限.

再次, 前面也说过, 当用户将请求地址发送到IIS服务器时, IIS服务器会根据请求地址选择不同的行为, 如: 对于*.aspx页面会走应用程序管道, 而对*.html、*.jpg等资源会直接返回资源, 那么我们可以把那些频繁访问的页面做成*.html文件, 这样用户请求*.html, 将不用再走应用程序管道, 因此会提升效率. 例如: 网站首页、或某些突发新闻或突发事件等, 可以考虑做成静态网页. 就拿”天气预报的发布页面”打比方: 天气预报的发布页面的访问用户非常多, 我们可以考虑将发布页做成静态的*.html网页, 之后在整个网站程序启动时, 在Gboabl.asax的Application_Start事件处理器中, 创建子线程以实现每3个小时重新获取数据生成新的天气发布页面内容.

之后的asp.net的处理流程, 作为程序员我们是无法干涉的. 直到启动HttpApplication管道后, 我们才可以通过Global.asax或IHttpModule来控制请求处理过程, 在应用程序管道中适合做整页或用户控件的缓存. 如: 缓存热门页面, 我们可以自动缓存整个网站中访问量超过一定数值(阀值)的页面, 其中为了减小IO操作, 将缓存的页面放在内容中.

3.9 .你们怎么做退款功能的，要多长时间才能把钱退回给用户？

用户申请退款后，经过客服审核通过会将退款请求提交到易宝，具体到账时间要看易宝的处理。

4.0 付款成功后易宝会有数据返回吗？如果付款后易宝没有返回，或者返回超时了，但是钱又已经扣了，你怎么办？

①我们请求了易宝，但是没有接受到响应，我们就认为该订单没有支付成功，并且将订单标识为异常状态；
②使用定时任务处理；

③做一个对账的任务，实时处理异常状态的订单。

4.1 你们使用什么做支付的？如果使用易宝做支付，请求超时了怎么处理？

①重试，一般三次，每次重试都要停顿一会，比如，以第一次停顿1秒，第二次停顿2秒，第三次停顿3秒；
②给订单标识付款异常状态，并且发出警告(邮件、短信)给相关人员。

③写个定时任务，定时处理异常状态的订单。

4.2你们服务器不止一台吧，那么你们的session是怎么同步的？

如果购物车使用session做的话，此问题极易被问到。

Session放到redis里面，使用单点登录系统。购物车设计思路：未登录(先写到cookie中，登录后写到数据库表中)；已登录(直接写到数据库，而不会写到cookie)实际项目是不使用session的，使用redis集中处理处理数据，取代session的作用，应用在单点登录、购物车等。

4.3.你们生产环境的服务器有多少台？

面试前要数好，一般是十几到二十台。(用在哪里？这是重点)

Nginx至少2台

Tomcat至少3台以上

数据库至少2台

Redis至少一台

4.4.如何解决并发问题的？

集群，负载均衡，nginx(主备，一般主在工作，备闲置；资源浪费)，lvs(在2个Nginx前做一个拦截，接收后进行分工)。有问题，如果nginx挂掉，整个系统就挂了。可以主备解决，可以前面搭一个lvs。这块不是你做的，但是你知道怎么解决(非常复杂，但是必须了解。针对具体的情况去具体对待，CPU，内存，不要一刀切。)

4.6 你们这个项目中订单ID是怎么生成的？我们公司最近打算做一个电商项目，如果让你设计这块，你会考虑哪些问题？

生成订单ID的目的是为了使订单不重复，本系统订单ID生成规则：

    用户ID+当前系统的时间戳

.        String orderId = order.getUserId() + "" + System.currentTimeMillis();

设计的时候我会考虑：

订单ID不能重复

订单ID尽可能的短（占用存储空间少，实际使用方便，客服相关）

订单ID要求是全数字（客服）

4.7.你这个项目中CMS系统是如何设计的，简单的说一下其设计思想？

隐藏在内容管理系统(CMS)之后的基本思想是分离内容的管理和设计。页面设计存储在模板里，而内容存储在数据库或独立的文件中。当一个用户请求页面时，各部分联合生成一个标准的HTML（标准通用标记语言下的一个应用）页面。

内容管理系统被分离成以下几个层面：各个层面优先考虑的需求不同

    1，后台业务子系统管理（管理优先：内容管理）：新闻录入系统，BBS论坛子系统，全文检索子系统等，针对不同系统的方便管理者的内容录入：所见即所得的编辑管理界面等，清晰的业务逻辑：各种子系统的权限控制机制等；

    2，Portal系统（表现优先：模板管理）：大部分最终的输出页面：网站首页，子频道/专题页，新闻详情页一般就是各种后台子系统模块的各种组合，这种发布组合逻辑是非常丰富的，Portal系统就是负责以上这些后台子系统的组合表现管理；

    3，前台发布（效率优先：发布管理）：面向最终用户的缓存发布，和搜索引擎spider的URL设计等……

    内容管理和表现的分离：很多成套的CMS系统没有把后台各种子系统和Portal分离开设计，以至于在Portal层的模板表现管理和新闻子系统的内容管理逻辑混合在一起，甚至和BBS等子系统的管理都耦合的非常高，整个系统会显得非常庞杂。而且这样的系统各个子系统捆绑的比较死，如果后台的模块很难改变。但是如果把后台各种子系统内容管理逻辑和前台的表现/发布分离后，Portal和后台各个子系统之间只是数据传递的关系：Portal只决定后台各个子系统数据的取舍和表现，而后台的各个子系统也都非常容易插拔。

    内容管理和数据分发的分离：需要要Portal系统设计的时候注意可缓存性（Cache Friendly）性设计：CMS后台管理和发布机制，本身不要过多考虑"效率"问题，只要最终页面输出设计的比较Cacheable，效率问题可通过更前端专门的缓存服务器解决。

    此外，就是除了面向最终浏览器用户外，还要注意面向搜索引擎友好(Searchengine Friendly)的URL设计：通过 URLREWRITE转向或基于PATH_INFO的参数解析使得动态网页在链接（URI）形式上更像静态的目录结构，方便网站内容被搜索引擎收录；

4.9什么是rpc协议

RPC（RemoteProcedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

有多种 RPC模式和执行。最初由 Sun 公司提出。IETFONC 宪章重新修订了 Sun 版本，使得 ONCRPC 协议成为 IETF标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。

5.0 服务器宕机怎么办

可以说我们用的是aliyun服务器，如果服务器异常宕机阿里云监控平台会通知我们。

如果是某一个服务的话，可以说服务器上有运行服务检测工具或者脚本，自动检测，有异常就会报告，具体怎么做的可以说有运维做

5.1 Jsonp的原理

js不可以跨域请求数据，但是可以跨域加载js文件；script标签src属性中的链接可以访问跨域的js脚本，利用这个特性，服务端不再返回JSON格式的数据，而是返回一段调用某个函数的js代码，在src中进行了调用，这样实现了跨域。

5.2 Tomcat的启动容量和初始值

tomcat默认初始的内存值xms是128m。需要调整的话就改变JAVA_OPTS 增加参数：JAVA_OPTS='-Xms256m -Xmx512m'

1.1 SOA

面向服务架构，服务之间通过定义良好的接口进行通信，dubbo就是soa的典型实现

特点：松散耦合，可重用服务，标准化服务接口

1.2分布式

将不同的业务模块拆分到不同的机器上，解决高并发问题

1.3 Nginx集群

将同一个业务部署在多台机器上，提高系统的高可用性

1.4 项目里面遇到的最大的问题是什么

新技术的学习吧，比如redis，事务什么的，用redis处理抢购

1.5你觉得开发中什么最重要

概念一定要理清，不能想当然

逻辑要清晰，严谨

抽象能力要强

看清问题本质，提高效率

编码规范

1.6开发怎么提高效率，性能

概念清晰，逻辑一定要清晰严谨

使用工具类，比如说mybatis逆向工程生成映射文件

性能的话能用最简便的方法不使用繁琐的逻辑

1.7网站并发数

支持3000左右的并发，可以满足目前的业务需求。由于系统是分布式架构，支持水平扩展，如果将来并发量提高的话，可以增加服务器来提高并发量

1.8人员配置

l 产品经理：1人，确定需求以及给出产品原型图。

l 项目经理：1人，项目管理。

l 前端团队：3人，根据产品经理给出的原型制作静态页面。

l 后端团队：8人，实现产品功能。

l 测试团队：3人，测试所有的功能。

l 运维团队：2人，项目的发布以及维护。

1.9开发周期

迭代开发，一个月迭代一次,每一次迭代都包括了需求分析、设计、编码和测试，在一次迭代中完成系统的一部分功能或业务逻辑

2.0项目的开发流程

需求分析，概要设计，详细设计，开发，测试

2.2 服务器宕机怎么看

服务器上有运行服务检测工具或者脚本，自动检测，有异常就会报告，具体怎么做的可以说有运维做

2.3 安全性问题（别的网站使用爬虫技术爬你的网站怎么办？有没有安全措施）

单位时间内请求次数超过某个阈值就让输入验证码，可以极大降低抓取的速度，如果多次超过某个阈值可以加入黑名单。还有就是页面内容使用json返回，数据经常变一变格式，或者js动态生成页面内容

2.4订单表的数据量太大,我把订单分到许多表中,那么我我想用一条sql查处所有的订单,怎么解决?

分库情况下：可以使用mycat数据库中间件实现多个表的统一管理。虽然物理上是把一个表中的数据保存到多个数据库中，但是逻辑上还是一个表，使用一条sql语句就可以把数据全部查询出来。

单库情况下：需要动态生成sql语句。先查询订单相关的表，然后将查询多个表的sql语句使用union连接即可

2.5对数据库只是采用了读写分离,并没有完全解决数据库的压力,那么有什么办法解决

如果数据库压力确实很大的情况下可以考虑数据库分片，就是将数据库中表拆分到不同的数据库中保存，可以使用mycat中间件

2.6商品存入数据库怎么保证数据库数据安全

数据库定期备份

用户安全管理：用户操作数据库时，必须通过数据库访问的身份认证

数据加密

日志追踪：追踪对数据库的操作

2.7 Tomcat启动容量，初始值

tomcat默认初始的内存值xms是128m，需要调整的话就改变JAVA_OPTS 增加参数：JAVA_OPTS='-Xms256m -Xmx512m'

2.8前端有哪些控件

Ocupload：一键上传

Kindeditor：富文本编辑器

Ztree：树控件

City-picker：省市联动

2.9 bootstrap相较于其他前端框架有什么优势

简单，好用，模板可以直接套用

栅格化系统，能自适应移动端

文档丰富

3.0事务一定要在业务层加吗

一般配置在业务层，只有配置在业务层，出现异常时才会自动回滚

配置在dao层的话，只有数据库操作异常时会回滚

配置到web层的话，也可以，但是引起异常的情况就更多，除非安全性特别高，而且controller层只支持注解式的事务

3.1用了什么bug管理工具

Teambition  禅道

3.2 你最近在研究什么技术

Nosql，大数据

3.3 系统功能

本商城系统是一个综合性的B2C平台，类似京东商城、天猫商城。

·       会员可以在商城浏览商品、下订单，以及参加各种活动。

·       商家可以在入住淘淘商城，在该平台上开店出售自己的商品，并且得到淘淘商城提供的可靠的服务。

·       管理员、运营可以在平台后台管理系统中管理商品、订单、会员等。

·       客服可以在后台管理系统中处理用户的询问以及投诉。

3.4电商行业技术特点

①技术新：(NoSql推广首在社区网站和电商项目)，发展快，需求推动技术的革新。

②技术范围广：除了java，像淘宝前端还使用了PHP，数据库MySQL或者oracle，nosql，服务器端使用Linux，服务器安全、系统安全

③分布式：以前是在一台机器上做运算，现在是分散到很多机器上，最后汇总起来。(集中式向分布式进行考虑)由需求来推动

④高并发、集群、负载均衡、高可用：由并发问题采用集群进行处理，其中，集群会涉及服务器的主从以及分布问题，使用负载均衡。(权重高低)高可用是对用户而言，用户的服务不中断(系统升级，服务不中断，淘宝每周更新2次)。

⑤海量数据：双11,570亿的背后，订单有多少？浏览次数有多少？商品会有多少？活动相关数据？

⑥业务复杂：不要简单的认为是：商品展示出来后，加入购物车后购买就完成了。后台特别复杂，比如优惠(包邮、满减)

⑦系统安全：系统上线必须通过系统安全部门审核通过。前年CSDN数据泄露。快捷酒店数据泄露(通过身份证就可以查看你的开房记录)。近几年，安全意识逐步在提高。

3.6商品搜索框的搜索联想如何实现？比如输入“羽绒” ，然后输入框下会列出很多关于羽绒服的搜索条件 “羽绒服男正品折扣 ”等等。

     可以用搜索的模糊查询，把查询出来的结果放到redis中缓存，

3.7做促销时，商品详情页面的静态页面如何处理价格问题。

京东商品详情页虽然仅是单个页面，但是其数据聚合源是非常多的，除了一些实时性要求比较高的如价格、库存、服务支持等通过AJAX异步加载加载之外，其他的数据都是在后端做数据聚合然后拼装网页模板的。整个京东有数亿商品，如果每次动态获取如上内容进行模板拼装，数据来源之多足以造成性能无法满足要求；最初的解决方案是生成静态页，但是静态页的最大的问题：

1、无法迅速响应页面需求变更；

2、很难做多版本线上对比测试。如上两个因素足以制约商品页的多样化发展，因此静态化技术不是很好的方案。

数据主要分为四种：商品页基本信息、商品介绍（异步加载）、其他信息（分类、品牌、店铺等）、其他需要实时展示的数据（价格、库存等）。而其他信息如分类、品牌、店铺是非常少的，完全可以放到一个占用内存很小的Redis中存储；而商品基本信息我们可以借鉴静态化技术将数据做聚合存储，这样的好处是数据是原子的，而模板是随时可变的，吸收了静态页聚合的优点，弥补了静态页的多版本缺点；另外一个非常严重的问题就是严重依赖这些相关系统，如果它们挂了或响应慢则商品页就挂了或响应慢；商品介绍我们也通过AJAX技术惰性加载（因为是第二屏，只有当用户滚动鼠标到该屏时才显示）；而实时展示数据通过AJAX技术做异步加载

1、接收商品变更消息，做商品基本信息的聚合，即从多个数据源获取商品相关信息如图片列表、颜色尺码、规格参数、扩展属性等等，聚合为一个大的JSON数据做成数据闭环，以key-value存储；因为是闭环，即使依赖的系统挂了我们商品页还是能继续服务的，对商品页不会造成任何影响；

2、接收商品介绍变更消息，存储商品介绍信息；

3、介绍其他信息变更消息，存储其他信息

技术选型

MQ可以使用如Apache ActiveMQ；

Worker/动态服务可以通过如Java技术实现；

RPC可以选择如alibaba Dubbo；

KV持久化存储可以选择SSDB（如果使用SSD盘则可以选择SSDB+RocksDB引擎）或者ARDB（LMDB引擎版）；

缓存使用Redis；

SSDB/Redis分片使用如Twemproxy，这样不管使用Java还是Nginx+Lua，它们都不关心分片逻辑；

前端模板拼装使用Nginx+Lua；

数据集群数据存储的机器可以采用RAID技术或者主从模式防止单点故障；

因为数据变更不频繁，可以考虑SSD替代机械硬盘。

核心流程

1、首先我们监听商品数据变更消息；

2、接收到消息后，数据聚合Worker通过RPC调用相关系统获取所有要展示的数据，此处获取数据的来源可能非常多而且响应速度完全受制于这些系统，可能耗时几百毫秒甚至上秒的时间；

3、将数据聚合为JSON串存储到相关数据集群；

4、前端Nginx通过Lua获取相关集群的数据进行展示；商品页需要获取基本信息+其他信息进行模板拼装，即拼装模板仅需要两次调用（另外因为其他信息数据量少且对一致性要求不高，因此我们完全可以缓存到Nginx本地全局内存，这样可以减少远程调用提高性能）；当页面滚动到商品介绍页面时异步调用商品介绍服务获取数据；

5、如果从聚合的SSDB集群/Redis中获取不到相关数据；则回源到动态服务通过RPC调用相关系统获取所有要展示的数据返回（此处可以做限流处理，因为如果大量请求过来的话可能导致服务雪崩，需要采取保护措施），此处的逻辑和数据聚合Worker完全一样；然后发送MQ通知数据变更，这样下次访问时就可以从聚合的SSDB集群/Redis中获取数据了。

基本流程如上所述，主要分为Worker、动态服务、数据存储和前端展示；因为系统非常复杂，只介绍动态服务和前端展示、数据存储架构；Worker部分不做实现。

3.8.点一个链接访问到一个页面，这个页面上既有静态数据，又有动态数据（需要查数据库的），打开这个页面的时候就是很慢但是也能打开。怎么解决这个问题，怎么优化？

如果要静态页面的话 那就得用freemarker或者通过ajax异步,通过js操作异步刷新表单,通过js对返回结果组装成html。

缓存、动态页面静态化：

所谓缓存, 是指将那些经常重复的操作结果暂时存放起来, 在以后的执行过程中, 只要使用前面的暂存结果即可.

那么在我们开发Web网站的过程中, 到底有多少工作可以采用用缓存呢? 或者说, 我们可以在哪些地方使用缓存呢? 见下图: 下图是客户端浏览器和Web服务器之间的一次完整的通信过程, 红色圆圈标示了可以采用缓存的地方.

首先, 最好的情况是客户端不发送任何请求直接就能获得数据, 这种情况下, 用于缓存的数据保存在客户端浏览器的缓存中.

其次, 在具有代理服务器的网络环境中, 代理服务器可以针对那些经常访问的网页制作缓存, 当局域网中第一台主机请求了某个网页并返回结果后, 局域网中的第二台主机再请求同一个网页, 这时代理服务器会直接返回上一次缓存的结果, 并不会向网络中的IIS服务器发送请求, 例如: 现在的连接电信和网通线路的加速器等. 但是代理服务器通常有自己专门的管理软件和管理系统, 作为网站开发人员对代理服务器的控制能力有限.

再次, 前面也说过, 当用户将请求地址发送到IIS服务器时, IIS服务器会根据请求地址选择不同的行为, 如: 对于*.aspx页面会走应用程序管道, 而对*.html、*.jpg等资源会直接返回资源, 那么我们可以把那些频繁访问的页面做成*.html文件, 这样用户请求*.html, 将不用再走应用程序管道, 因此会提升效率. 例如: 网站首页、或某些突发新闻或突发事件等, 可以考虑做成静态网页. 就拿”天气预报的发布页面”打比方: 天气预报的发布页面的访问用户非常多, 我们可以考虑将发布页做成静态的*.html网页, 之后在整个网站程序启动时, 在Gboabl.asax的Application_Start事件处理器中, 创建子线程以实现每3个小时重新获取数据生成新的天气发布页面内容.

之后的asp.net的处理流程, 作为程序员我们是无法干涉的. 直到启动HttpApplication管道后, 我们才可以通过Global.asax或IHttpModule来控制请求处理过程, 在应用程序管道中适合做整页或用户控件的缓存. 如: 缓存热门页面, 我们可以自动缓存整个网站中访问量超过一定数值(阀值)的页面, 其中为了减小IO操作, 将缓存的页面放在内容中.

3.9 .你们怎么做退款功能的，要多长时间才能把钱退回给用户？

用户申请退款后，经过客服审核通过会将退款请求提交到易宝，具体到账时间要看易宝的处理。

4.0 付款成功后易宝会有数据返回吗？如果付款后易宝没有返回，或者返回超时了，但是钱又已经扣了，你怎么办？

①我们请求了易宝，但是没有接受到响应，我们就认为该订单没有支付成功，并且将订单标识为异常状态；
②使用定时任务处理；

③做一个对账的任务，实时处理异常状态的订单。

4.1 你们使用什么做支付的？如果使用易宝做支付，请求超时了怎么处理？

①重试，一般三次，每次重试都要停顿一会，比如，以第一次停顿1秒，第二次停顿2秒，第三次停顿3秒；
②给订单标识付款异常状态，并且发出警告(邮件、短信)给相关人员。

③写个定时任务，定时处理异常状态的订单。

4.2你们服务器不止一台吧，那么你们的session是怎么同步的？

如果购物车使用session做的话，此问题极易被问到。

Session放到redis里面，使用单点登录系统。购物车设计思路：未登录(先写到cookie中，登录后写到数据库表中)；已登录(直接写到数据库，而不会写到cookie)实际项目是不使用session的，使用redis集中处理处理数据，取代session的作用，应用在单点登录、购物车等。

4.3.你们生产环境的服务器有多少台？

面试前要数好，一般是十几到二十台。(用在哪里？这是重点)

Nginx至少2台

Tomcat至少3台以上

数据库至少2台

Redis至少一台

4.4.如何解决并发问题的？

集群，负载均衡，nginx(主备，一般主在工作，备闲置；资源浪费)，lvs(在2个Nginx前做一个拦截，接收后进行分工)。有问题，如果nginx挂掉，整个系统就挂了。可以主备解决，可以前面搭一个lvs。这块不是你做的，但是你知道怎么解决(非常复杂，但是必须了解。针对具体的情况去具体对待，CPU，内存，不要一刀切。)

4.6 你们这个项目中订单ID是怎么生成的？我们公司最近打算做一个电商项目，如果让你设计这块，你会考虑哪些问题？

生成订单ID的目的是为了使订单不重复，本系统订单ID生成规则：

    用户ID+当前系统的时间戳

.        String orderId = order.getUserId() + "" + System.currentTimeMillis();

设计的时候我会考虑：

订单ID不能重复

订单ID尽可能的短（占用存储空间少，实际使用方便，客服相关）

订单ID要求是全数字（客服）

4.7.你这个项目中CMS系统是如何设计的，简单的说一下其设计思想？

隐藏在内容管理系统(CMS)之后的基本思想是分离内容的管理和设计。页面设计存储在模板里，而内容存储在数据库或独立的文件中。当一个用户请求页面时，各部分联合生成一个标准的HTML（标准通用标记语言下的一个应用）页面。

内容管理系统被分离成以下几个层面：各个层面优先考虑的需求不同

    1，后台业务子系统管理（管理优先：内容管理）：新闻录入系统，BBS论坛子系统，全文检索子系统等，针对不同系统的方便管理者的内容录入：所见即所得的编辑管理界面等，清晰的业务逻辑：各种子系统的权限控制机制等；

    2，Portal系统（表现优先：模板管理）：大部分最终的输出页面：网站首页，子频道/专题页，新闻详情页一般就是各种后台子系统模块的各种组合，这种发布组合逻辑是非常丰富的，Portal系统就是负责以上这些后台子系统的组合表现管理；

    3，前台发布（效率优先：发布管理）：面向最终用户的缓存发布，和搜索引擎spider的URL设计等……

    内容管理和表现的分离：很多成套的CMS系统没有把后台各种子系统和Portal分离开设计，以至于在Portal层的模板表现管理和新闻子系统的内容管理逻辑混合在一起，甚至和BBS等子系统的管理都耦合的非常高，整个系统会显得非常庞杂。而且这样的系统各个子系统捆绑的比较死，如果后台的模块很难改变。但是如果把后台各种子系统内容管理逻辑和前台的表现/发布分离后，Portal和后台各个子系统之间只是数据传递的关系：Portal只决定后台各个子系统数据的取舍和表现，而后台的各个子系统也都非常容易插拔。

    内容管理和数据分发的分离：需要要Portal系统设计的时候注意可缓存性（Cache Friendly）性设计：CMS后台管理和发布机制，本身不要过多考虑"效率"问题，只要最终页面输出设计的比较Cacheable，效率问题可通过更前端专门的缓存服务器解决。

    此外，就是除了面向最终浏览器用户外，还要注意面向搜索引擎友好(Searchengine Friendly)的URL设计：通过 URLREWRITE转向或基于PATH_INFO的参数解析使得动态网页在链接（URI）形式上更像静态的目录结构，方便网站内容被搜索引擎收录；

4.9什么是rpc协议

RPC（RemoteProcedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

有多种 RPC模式和执行。最初由 Sun 公司提出。IETFONC 宪章重新修订了 Sun 版本，使得 ONCRPC 协议成为 IETF标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。

5.0 服务器宕机怎么办

可以说我们用的是aliyun服务器，如果服务器异常宕机阿里云监控平台会通知我们。

如果是某一个服务的话，可以说服务器上有运行服务检测工具或者脚本，自动检测，有异常就会报告，具体怎么做的可以说有运维做

5.1 Jsonp的原理

js不可以跨域请求数据，但是可以跨域加载js文件；script标签src属性中的链接可以访问跨域的js脚本，利用这个特性，服务端不再返回JSON格式的数据，而是返回一段调用某个函数的js代码，在src中进行了调用，这样实现了跨域。

5.2 Tomcat的启动容量和初始值

tomcat默认初始的内存值xms是128m。需要调整的话就改变JAVA_OPTS 增加参数：JAVA_OPTS='-Xms256m -Xmx512m'