在搜索的时候，商品已经修改了，跟我门搜索的东西不一致，这是不合适的，这得同步redis.
还有就是更改商品，动态页面也要变，什么时候更改索引库？
审核过的时候更改？还是上下架的时候更改？
最终上下架的时候更改，因为商家审核之后，还有一个环节就是商品的上下架。
1.不管上架还是下架都得修改 商品 的状态都得修改is_markertble：
2.同步更新（添加或修改） solr索引库
3.同步更新（同步或修改）静态页面
如下图所示，在商品管理的页面上，需要 增加如下功能，并且 需要依靠三个依赖，倘若直接添加依赖，就会导致耦合性太高，所以 需要怎么做？
而且下面这个图，如果第一个方法不执行成功，第二个方法就不会执行，那么太降低效率了！
怎么解决？
这三个方法都需要在一个方法内需要做的事，而且如下图一样，每个方法都需要时间，所以 怎么想办法，告诉页面修改成功 ？而不用等到用的时候再去查看页面有没有修改成功，再去继续下一步操作 ？
经过上面的问题剖析：我们需要解决的问题，就是降低耦合，改变原来的同步消息 为异步消息。
所以引出来一项技术：消息队列，什么是消息队列？
消息队列中间件是分布式系统中的重要的组件，主要解决应用耦合，异步消息，流量削峰。实现高可用可伸缩和最终一致性的架构。
使用较多的消息队列有ActiveMQ等。
应用举例：
经过 分析，将上面的三个同步并且耦合性较高的方法改造成如下图所示：
下面就是到了怎么应用ActiveMQ？
我们先暂时的把ActiveMQ理解成存储消息的一个经典软件。
继续分析：就是我们 先暂时把注册成功的信息放入到消息对列中，放入到mq中后，就可以直接响应给用户了，这样用户就可以用55ms的时间得到注册成功或者注册失败的消息。
然后发送邮件和发送短信什么时候发送呢？
我们需要再写两个功能，一个写发送邮件，一个写发送短信。
发送邮件的这个的这个功能，只要 一看到MQ中有消息，就取出来，并且消费掉（所谓的消费就是执行自己的功能）。
那么再继续分析下去，如果发送邮件失败也不会影响用户的注册成功。
如果邮件发送失败，那么就该异常写入日志，如果失败的话，就再继续发送。
那么这样解决的话 ，就会大大的提高我们的效率。
接下来我们再解析流量削峰
如果秒杀活动中，一下涌入进来10万个请求，怎么解决 ？
就是 我们把秒杀需要的100个请求，放入队列中，我们慢慢处理，其余的请求就不管了！
以这样的方法区解决流量削峰的高并发问题。
就比如地铁高峰，人来的再多，那也得放入排队中挨着解决。
然后我们回到我们最原始的那个问题中：
我们把同步更新的任务，直接放入到Mq中，让MQ去做。同时，那么shop_web也不用引入右下边的两个service项目了。看下图分析
然后在MQ中发布订阅模式，去让search方法和itempage_service监控着Mq，然后去取，并且消费！
当然这样做的好处就是，我们也不用再去王shop_web中写入依赖，那么也同时降低了耦合性，并且把同步消息改成了异步消息！大大提高了效率！
JMS规范
然后我们提到了这个MQ,因为有很多MQ类似的软件，我们用的ActiveMQ这个软件，但是我们都得遵守这个么JMS规范。这个JMS是操作Mq的，于是提供了一个操作Mq的一个接口。
它准备了两个模式：
Point to Point
发布订阅模式
问题
1、点对点模式，消费者那端代码执行过程中出异常了怎么处理？
一定要捕获异常，放到log中，并且放到表中，然后有我们开发人员解决。
2、发布订阅模式 MQ中的数据会越来越多，怎么处理？
a.定期处理，（弊端就是误删数据）
b.从内存读取到硬盘，（效率慢）