一、项目描述：

随着娱乐行业的迅速发展，为满足客户的购票以及演出查询等仿照“大麦”研发了“绿萌”。一期主要包含：账号、分类、即时消息、个人中心、购票等几项主体功能。

 

二、软件架构

后端：springboot、springcloud、mybatis、springSecurity、redis、rocketMQ、Quartz、maven、Git、MySQL、Cassandra、webservice等；

前端：Layui、jQuery、node.js等（因前期属于试运营故未做单独的Android与iOS开发，将项目打包成APP进行发行的）

 

三、功能及技术应用

1、通过springSecurity进行权限模块的研发；

2、MQ以及redis作为数据缓存以及同步实现单点登录功能的研发和数据的并发式访问；

3、Hystrix熔断器的应用也在一定程度上缓解了并发；

4、Quartz定时器做抢票定时器方面的实现；

5、图片上传、存储在华为服务器上；

6、消息、评论等功能主要通过Cassandra数据库进行实现。

 

四、二期规划

1、并发方案的优化；

2、用户兴趣爱好的推荐——建立用户兴趣库；

3、多平台接口对接的优化；

4、发票模块的开发；

5、后端数据运营板块的完善；

6、第三方支付功能的完善等。

 

五、信息结构图

六、项目重点难点分析

1、生产事故，几百万数据在消息队列中积压了几个小时！

关于这个事儿，我们一个一个来梳理吧，先假设一个场景，我们现在消费端出故障了，然后大量消息在mq里积压，现在事故了，慌了

（1）大量消息在mq里积压了几个小时了还没解决
几千万条数据在MQ里积压了七八个小时，从下午4点多，积压到了晚上很晚，10点多，11点多

这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复consumer的问题，让他恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。

一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条

所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来

一般这个时候，只能操作临时紧急扩容了，具体操作步骤和思路如下：

1）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉
2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

（2）这里我们假设再来第二个坑
假设你用的是rabbitmq，rabbitmq是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。

这个情况下，就不是说要增加consumer消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。

这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。

假设1万个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次

（3）然后我们再来假设第三个坑
如果走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。

 

七、项目中的其他内容点

高并发的处理方案

1、redis哨兵机制；

2、redis集群的搭建；

3、redis中数据丢失后数据的恢复；

4、ES查询的优化；

5、乐观锁在并发情况下的应用；

6、熔断器处理高并发；

7、服务前置等。

公众号：Java面试百分百