80.session共享的方案
1.广播:会造成内网网络风暴,大量占用内网宽带
2.IP_hash:在nginx中配置和,相同的ip找固定的同一台服务器,这种方案会造成服务能力差
3.使用第三方中间件(数据库,redis),我们是使用redis
82.高并发问题:索引库同步
1.硬编码：在相应的代码中增加索引库同步的代码。不过，这种方法耦合度太高，将原本不相关的系统耦合在了一起，容易造成不可预估的错误，是电商项目的大忌。
2.spring的aop：编写一个索引库同步的方法，利用aop的形式，将它和数据库数据更新的方法联系起来。这种方式也会造成耦合。
3.消息队列：不过，这个方法会造成一个问题，那就是消息消费失败问题。
:解决两个系统间的通信问题。
消息消费失败：集中同步索引库，做一个定时任务。在消息队列所在的服务器上加一个数据库，我们使用的是redis缓存。消息队列中每发一条信息，就将这条信息持久化进redis中。接着定时（我们是在晚上，用户量少的时候）从redis中将消息列表取出来，批量同步索引库。
85.为什么服务层之间调用的activeMq会是在controller层发消息？
因为事务！如果是在controller层发送消息，那么controller层调用的service一定是完成了事务提交操作的。如果是在service层发送消息，那么事务可能会没有提交，会造成空指针异常。
86.索引库同步时为什么使用activemq的queue方式？（使用queue的好处）
1.不需要考虑消息没有被消费问题
2.queue方式，自带持久化机制
3.业务更加单一，相对来说比较安全
87.消息队列问题：同步索引库时，传输的内容为什么是商品信息，而不适用商品id？
传送商品id：
好处：传送的是商品id，传输的内容少，效率相对较高，不会产生消息阻塞。
缺点：消费方需要再次查询数据库取出商品信息，和数据库多了一次交互。
传送商品信息：
好处：这样消费者就不需要再次从数据库中查询商品信息数据，减少了与数据库的交互。
缺点：传输的是商品信息，传输内容相对较少（原因：文本信息在网络传输中占用的网络资源最少），可能会产生消息阻塞的问题，但是由于我们的消息的发送不是连续的，不会有太高的并发量（原因：消息的发送时需要运营商平台审核通过后才发送的。）