使用流程：

第一步：要在系统中使用dubbo应该先搭建一个注册中心，一般推荐使用zookeeper。

第二步：有了注册中心然后是发布服务，发布服务需要使用spring容器和dubbo标签来发布服务。并且发布服务时需要指定注册中心的位置。

第三步：服务发布之后就是调用服务。一般调用服务也是使用spring容器和dubbo标签来引用服务，这样就可以在客户端的容器中生成一个服务的代理对象，在action或者Controller中直接调用service的方法即可。

Zookeeper注册中心的作用主要就是注册和发现服务的作用。类似于房产中介的作用，在系统中并不参与服务的调用及数据的传输。

1）Redis是key-value形式的nosql数据库。可以快速的定位到所查找的key，并把其中的value取出来。并且redis的所有的数据都是放到内存中，存取的速度非常快，一般都是用来做缓存使用。

2）项目中使用redis一般都是作为缓存来使用的，缓存的目的就是为了减轻数据库的压力提高存取的效率。

3）在互联网项目中只要是涉及高并发或者是存在大量读数据的情况下都可以使用redis作为缓存。当然redis提供丰富的数据类型，除了缓存还可以根据实际的业务场景来决定redis的作用。例如使用redis保存用户的购物车信息、生成订单号、访问量计数器、任务队列、排行榜等。

acitveMQ的作用、原理？（生产者。消费者。 p2p、订阅实现流程）
Activemq的作用就是系统之间进行通信。当然可以使用其他方式进行系统间通信，如果使用Activemq的话可以对系统之间的调用进行解耦，实现系统间的异步通信。原理就是生产者生产消息，把消息发送给activemq。Activemq接收到消息，然后查看有多少个消费者，然后把消息转发给消费者，此过程中生产者无需参与。消费者接收到消息后做相应的处理和生产者没有任何关系。
当技术面试官问到你某个技术点更深层次研究时，自己没有深入了解怎么回答？
如果没有深入研究就直接回答不知道就可以了。
solr怎么设置搜索结果排名靠前（得分）？
可以设置文档中域的boost值，boost值越高计算出来的相关度得分就越高，排名也就越靠前。此方法可以把热点商品或者是推广商品的排名提高。

solr的原理

Solr是基于Lucene开发的全文检索服务器，而Lucene就是一套实现了全文检索的api，其本质就是一个全文检索的过程。全文检索就是把原始文档根据一定的规则拆分成若干个关键词，然后根据关键词创建索引，当查询时先查询索引找到对应的关键词，并根据关键词找到对应的文档，也就是查询结果，最终把查询结果展示给用户的过程。
solr里面IK分词器的原理
IK分析器的分词原理本质上是词典分词。现在内存中初始化一个词典，然后在分词过程中逐个读取字符，和字典中的字符相匹配，把文档中的所有的词语拆分出来的过程。

支付接口是怎么做的？

面试中可以说支付这部分不是我们做的，我们项目中并没有涉及支付部分的处理。如果想了解支付是如何实现可以参考之前学过的易宝支付相关处理以及支付宝、微信支付相关文档。
支付宝：
https://doc.open.alipay.com/doc2/apiDetail.htm?spm=a219a.7629065.0.0.eeTXH8&apiId=850&docType=4#
微信支付：
https://mp.weixin.qq.com/cgi-bin/readtemplate?t=business/faq_tmpl

activeMQ在项目中如何应用的？

Activemq在项目中主要是完成系统之间通信，并且将系统之间的调用进行解耦。例如在添加、修改商品信息后，需要将商品信息同步到索引库、同步缓存中的数据以及生成静态页面一系列操作。在此场景下就可以使用activemq。一旦后台对商品信息进行修改后，就向activemq发送一条消息，然后通过activemq将消息发送给消息的消费端，消费端接收到消息可以进行相应的业务处理。

activeMQ如果数据提交不成功怎么办？

Activemq有两种通信方式，点到点形式和发布订阅模式。如果是点到点模式的话，如果消息发送不成功此消息默认会保存到activemq服务端知道有消费者将其消费，所以此时消息是不会丢失的。
如果是发布订阅模式的通信方式，默认情况下只通知一次，如果接收不到此消息就没有了。这种场景只适用于对消息送达率要求不高的情况。如果要求消息必须送达不可以丢失的话，需要配置持久订阅。每个订阅端定义一个id，在订阅是向activemq注册。发布消息和接收消息时需要配置发送模式为持久化。此时如果客户端接收不到消息，消息会持久化到服务端，直到客户端正常接收后为止。

当被问到某个模快存在安全性问题（sso单点登录系统）时，如何回答？

目前淘淘商城的sso系统的解决方案中直接把token保存到cookie中，确实存在安全性问题。但是实现简单方便。如果想提高安全性可以使用cas框架实现单点登录。
https://www.apereo.org/projects/cas

业务如何说？先说业务、说表、说具体实现？

先说总体的业务流程，然后再说具体业务的实现方法及使用的技术。最后说你在系统中负责的内容。不需要说表结构。

你做过电商项目，那么你说说sku的几种常用设计方法，你们的sku是怎么设计的？
SKU属性的设计，可以分为两类：
1）通过属性集关联SKU属性
　　适合品类较少的网站，管理容易些。
    如麦包包等专卖箱包或者服饰类的网站。一般就是颜色+尺码两种。而且由于品类很少，为了方便管理，可以将SKU属性纳入到属性
集中管理，这样产品关联了属性集后，自然就关联了普通属性、查询属性、SKU属性和评论属性了。
如果该网站产品种类很少，比如只卖服装，那么可以做进一步的简化，即直接将SKU属性从属关联属性集，去掉”属性集关联SKU“。

基于本设计的管理方式：
     按品类创建属性集，如箱包、鞋子、服装、文胸等。然后创建多个SKU属性，即使针对内涵相似的，但是可选项不同的也创建
多个，如尺码，用在箱包和用在服装上是完全不同的。这些分别创建，并关联不同的属性集。
      产品创建时，关联一个属性集，通过属性集关联了1~N个SKU属性，然后选项这些SKU属性的组合，如2个颜色*3个尺码，即6个组合，然后可以根据需要删除不支持的组合，这样最终得出了一个组合列表，点击”生成SKU“，就根据组合数量创建了产品
SKU，每个产品SKU对应一个组合，存储在产品SKU选项值表中。对于某些SKU，可以设置专门的选项配图。

2）产品和SKU属性直接关联

适合品类很多网站，比较灵活，但是维护起来数据量比较大。
      为了简化，我增加SKU属性关联产品分类（可为空，表示是全局的），这样在创建产品时，可以只列出全局的+本产品分类的SKU属性，这样就不会一下子列出很多SKU属性了。SKU属性分为前端名称和后台名称两个，方便不同业务含义的SKU属性，在前端也能够用同一个名称显示，如颜色、容量等。另外在操作上可以做些优化，比如用下拉列表显示可选的SKU属性时，可以同时显示该属性的属性描述，供产品维护人员参考。
基于SKU方式来管理产品时，产品的价格、库存和图片等信息必然是放在产品SKU表中处理的，和订单、购物车等表的关联，也是通过产品SKU表，而不是产品表。至于产品表，实际上是一个总的业务汇总和外部关联表，但实际销售的并不是它。我们网站做的更细些，会就每个产品SKU生成独立的URL（伪静态），但从SEO方面考虑，每个产品SKU拥有独立

单点登录具体实现了什么功能？
1. 去登陆页面
2. 提交登陆页面
3. 用户名、密码、验证码的校验
4. 错误信息的回显
5. 保存用户到Session中
6. 重定向到登陆之前的访问页面
7. Ajax跨域判断用户是否登陆

Redis在其中是怎么用的？起了什么作用？
redis中存储的都是key-value格式的。拿商品数据来说，key就是商品id，value是商品相关信息的json数据。
在商城系统中当并发量比较高，频繁的对数据库进行读操作的时候都需要添加缓存。例如页面中内容数据的缓存、商品数据的缓存以及用户数据的缓存等。
做商品数据的缓存时，因为商品的数据量很大，而且缓存是把数据保存到内存中，此时不可能把所有的商品数据都放到缓存中。所以需要设置商品数据缓存的有效期，当用户访问到非热点数据后，此数据放到缓存中，当缓存到期后就从缓存中删除，而且长时间不会添加到缓存。而热点数据一旦从缓存中删除会马上又添加到缓存。这样可以提高缓存的利用率，同时也减轻了数据库的压力。

插入商品的话，要求级联插入几张表，你们当时是怎么实现的？
通过Redis生成商品编号（ID）
保存商品表
再保存Sku表（此表中外键，是商品表的ID）