开始我们的表演！！！
遇到的问题直接丢在评论里面
演员的自我修养之路---------
1.freemarker生成的静态化页面，如果商品的信息更改以后，会不会生成新的静态化化页面，freemarker静态化页面的数据是从哪里调用出来的，如果不是从数据里面掉的数据的，这个地方需要用到同步，和谁同步
答案:
1.如果商品信息更改以后，是需要生成新的静态化页面。（注意：淘淘商城中没有修改商品然后生成新的静态化页面的逻辑，实际中是需要这一部分逻辑的）;
2.freemarker模块页面中的数据是在创建静态化页面的时候获取到的，那么这部分数据如果真采取淘淘商城中发mq去从数据库中查询，那也就不用担心这么多数据，从数据库中获取不是性能很慢。这个就不是本问题所涉及的了。如果不发mq也行啊，直接现存的数据为啥不行呢？
3.对于数据库高并发，缓解数据库查询压力，我们从业务设计角度分商品详情页面内容缓存和页面静态化处理两个维度去讲解。静态化页面是在商品新增或者修改的时候产生新的静态化页面。这个问题，是假设了商品数据放到某一个地方存起来，然后从存的地方取出来作为模板中的数据。这个设计我不敢苟同。设计上有漏洞，实现上没有一点优势。通过查看京东
商品的详情页，F12可以看到整个详情页面也是应用了静态化页面，通过nginx去找页面。
******************************************************************************************
2.如果数据库的信息更改以后，那么索引库和缓存库里面的信息是怎么更新的？不可能每次都去访问数据库吧。
答案:
a>该问题前提是商品详情页面如果采取的是缓存商品数据这种设计的话，那么当商品信息更改以后，索引和缓
存中数据更新同步逻辑在淘淘商城中设计是采取了发mq异步从数据库中查询的。如果从数据库中根据发mq发来
的商品主键id来查询数据库不是不可以。如果数据库查询很慢，性能很低，那么就设计到优化该逻辑的设计
了。比如：是否可以采取新增商品临时表，发的mq就从临时表中去取；还比如索引和缓存的数据不多，我也可
以直接通过mq把商品内容发过来啊。我甚至，可以不采用发mq直接去同步。
***********************************************************************
3.消息队列MQ，如果消息丢失了怎么办，我怎么能知道消息有没有丢失，遇到这种问题我怎么处理
答案:a>消息丢失可以分为消息生产者丢失和消息消费者丢失；消息丢监控中心看不到消息，且会报异常。 常规做法是开启事务+设置持久化。 对于消费端需要mit()，提价事务。另外除了Session.AUTO_ACKNOWLEDGE还有分别如下设置： b>注意对于业务中依赖消息的且高密度，高并发的场景，我们推荐使用RabbitMQ，该mq提供了解决生成者和消费者消息丢失的解决方案；主要思路主要是放在怎么确认消息已经收到，也就是针对不同生产者和消费者提供了确认机制.请参考：/Leo_wl/p/6581989.html c>还可以设计一张路由表，消费者消费成功之后就会修改该表中记录状态
******************************************************************************************
4.如果两个人，两台电脑同时登录同一个帐号，同时对同一个账单提交，账单同时被服务器处理，那服务器应该先处理谁的，或者怎么规避这个问题。非单点登录，重定向，stoken拦截器的问题
答案:
a>现在购物app和desktop都会同时存在，且有的电商是允许统一账号在不同电商上登录的。以京东为例，在本地不同电脑使用同一个账号登录，是可以的。
b>通过实际演示，A，B两台电脑登录同一个账号，同时对同一件商品提交订单时，如果A电脑先下订单，那么B再下订单也会产生订单。这就好比你买了2件商品一样，实际过程中京东没有因为是同一账号，不同电脑上提交同一商品而规避用户重复购买。因为下订单也是先后顺序的。
c>通过实际演示，A，B两台电脑登录同一个账号，对同一件商品同时删除，如果A电商先删除该商品，B电脑再删除该商品，那么B电商点击删除操作之后，会弹出删除失败提示框。
d>通过springmvc HandlerInterceptor拦截器配置，preHandle()方法去检查客户机请求是否携带token，京东就是这样做的。
******************************************************************************************
5.用户购买商品时，什么时候才减少库存。
答：a>提交订单，支付状态由未付款改成支付成功后，才会减少库存。仓库系统
不会根据用户临时行为去减少库存商品数量。这样带来的数据变动太大。而是会根据下单后
商品支付成功状态来减少库存。
******************************************************************************************
7.日志文件的管理。
答：
a>一般大型的电商系统都会将各个子系统的中后台操作进行监控，随时能够查看系统运行状态。那么其后台管
理系统的日志可以设计日志表来专门存储后台操作。这一类日志称之为自定义日志信息；
b>除此之外，还有我们各个服务产生的日志，例如tomcat,solr等日志这些日志也可以分布式日志框架收集。
c>将我们自定的日志信息和系统服务日志信息收集之后，就可以通过日志架构，来搭建日志管理系统了。这些
日志信息可以都存储在日志服务器中。有专门的报表及其报警系统组成。
******************************************************************************************
8.项目中用到了多少台服务器，测试环境和正式环境各有多少台。
答：视项目规模来看。
a>一个门户网站的uv量月统计达到几十万，至少也得部署4台，这样也能够应该理论值1000-2000并发量。另外还得看服务器性能和架构，所以单纯要问有多少台，没有多少意义。真要是说，将项目定位成小型-中型-大型-超大型系统。那么算上其他系统所需要的服务器依次需要4-6台---6-10台—至少20台---数据节点，上千。
b>测试环境主要是供RD和QA使用，一般都会各自分配一台。正式环境就是上面所说的了。
******************************************************************************************
9.从一般的商城来看，可以分为B2C与C2C，也就是单商城系统和多商城系统。单商城的系统，基本上就是全部商品生成一个订单，根据订单号支付，如果是多商城系统，假定我们使用微信支付，微信支付每次下单只能使用唯一一个单号，那么我们只能把不同的店铺，例如店铺A和店铺B的所有商品，都统一放到一个订单号去微信下单支付。但是，这样子又违反了订单规则：不同的店铺存在着不同的订单业务，店铺和订单是一对多的关系，而且每个订单号必须是唯一的。怎么办？这个地方需要用到拆单，怎么拆
答案:暂时先待定
******************************************************************************************
10.商品修改以后，购物车里面的价格是怎么处理的！！
答：该问题假设的情景是用户添加了一件商品，那么此时商品价格修改了。此时下订单以什么为准？该问题分为下订单前和下订单后。
a>一旦下了订单，那么订单中就有了该商品的金额，及时修改了商品价格，也是按照订单来支付的。
b>如果没有下订单，那么在下订单的时候，是按照最新修改的商品价格来计算该商品金额的。
******************************************************************************************
11.商品修改之后，怎么同步的！！！
答：商品修改之后，需要同步的是什么？
a>如果按照淘淘商城中，新增商品同步到solr索引，同步到redis中。那么就可以在修改商品的时候，add(document),set(item)。淘淘商城中采取的策略是发mq，根据id查询，这种方式去同步的，对于redis就是直接删除，然后新增。
******************************************************************************************
12.在项目中并发是怎么解决的，用到哪些技术，具体是怎么实现的，原理是什么！
答：这里谈到的并发，指的是在同一时刻服务器应该能够同时处理的请求的量。解决并发可以从如下角度去解决：
a>购买高性能服务器和数据库（不能从根本上解决高并发）
b>页面静态化处理
静态化页面效率高消耗最小，避免大量数据库访问量。
c>图片服务器分离（基本网站都采取的策略）
使用独立的图片服务器降低提供页面访问请求的服务器系统压力并且可以保证系统不会因为图片问题而崩溃，在应用服务器
和图片服务器上，可以进行不同的配置优化，
d>集群架构
增加一台服务器分担原有服务器访问和存储压力来改善负载压力。比较成熟的集群架构要保证可伸缩性：如图
e>负载均衡（软件和硬件的负载，一般使用软件负载更多）
可将用户浏览器访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多用户，就在集群中加入更多的服务器，使用应用服务器服务器的负载压力不再成为整个网站的瓶颈。
f>特定业务功能可以考虑使用多线程去处理
g>缓存
减少数据库访问压力
h>读写分离，分库分表
i>代码优化
备注：以上问题解答，在淘淘商品教学过程中，部分已经说明。咱们这个课程只是粗陋仅仅从技术角度中去看。很多业务逻辑上的设计与实际相差甚远。就业指导老师收集这些问题来自我们的学生在面试和实际过程遇到的。作为教学导师，我们有责任将这些问题进行及时解决，当然解决这些问题，仅仅是从想法+思路上以及所见所闻上谈到一些看法。欢迎更多老师讨论。
