个人评价
安全狗主要还是做安全的，所以java开发约即是小厂。后端开发主要使用的技能栈技能ssh+jsp。
技能可谓是先当的古老，本次口试内容主要以项目为主。也是初次收到口试官的夸奖，口试下来也是非常开心的。
介绍一下实习项目吧？ （归并写哀求）
我的实习项目主要就是做C端的在线教诲项目，并且呢，它接纳的基于alibaba那套落地的微服务方案。大概也是因为我是实现生的源固，我没有负责黄金链路，从用户登录到用户下单再到用户观看视频的整个流程，我主要负责的就是负责辅助模块的开发。批评区，点赞，排行榜模块的开发。
那我给您介绍一下我记得比力清楚的难点吧。
其时要做一个续播功能，也就是用户切换其他设备的时候也能从对应的位置上继续观看，本质上就是去修改数据库中观看记录表的数据，在公刚开始的想法就是直接去操作数据库，对了，每个用户前端每隔15秒会提交一次观看位置的哀求，并且上级这边说qps会达到3000左右，也就是同时观看人数最多会有3000人左右，因此我们要进行优化，我们会发现这些哀求中只有末了一次的观看位置是有用的，所以计划的解决方案就是使用redis的hash结构+延长消息来实现的。Hash结构中，使用大key存储课表Id,课表用来关联userId和课程的Id，使用小key存储节Id，value存储观看位置的数据，在每次哀求进来后直接修改Hash中的数据，并且每次发送一个延长消息，使用Redis的死信发送一个延长15秒消息，并且也是当前的节点去监听该消息，监听到消息后，使用监听到的观看位置和当前在Hash结构中的观看位置进行比力，假如发现二者的雷同，阐明在这15秒内没有再次进行观看了，这个时候就去修改数据库。反之，假如不雷同的话，阐明此时用户还在进行观看，我们就直接丢掉消息。最终减少99%的DB操作。
那我在做完这个业务之后，也在思索，因为我们使用的是RabbitMq来存储观看位置的消息，此时大概就会出现标题，消耗者的消耗速度小于生成者生成速度。我现在主要了解到的解决方案就是增加消耗者的个数，因为接纳的是微服务的落地方案，所以我们可以增加消耗者的个数。提升消耗者的消耗能力，我会创建线程池，使用多线程来消耗消息，对消息队列进行扩容，我们可以使用惰性队列来存储消息，因为惰性队列使用磁盘进行存储，就导致它的容量非常大，但是呢，涉及到大量的文件IO操作，所以在速度上效率是比力低的。
还有没有其他的难点？
我记得比力深刻的就是这个批评模块，那批评模块有点类似B站，我以为比力难过就是点赞模块，再计划上，我们并没有直接操作数据库中点赞记录表，主要还是怕恶意的哀求，大量的点赞和取消赞哀求，我们主要的解决方案就是redis的set结构 + zset结构+定时任务来解决的，set结构用来存储userId和业务的点赞关系，zset结构用来统计每一个业务对应的点赞数目(key存储业务类型，member存储业务id，scope存储点赞数)。在发送点赞哀求后，我们会修改set中的数据，使用scard方法统计点赞数（因为set结构中存在一个位置存储count，所以调用scard方法的效率为O(N),效率非常的高），修改zset中的总点赞数。并且使用xxl-job做定时任务，调用popmin方法，每隔15秒就从zset中去30条数据做批量修改的操作，最终完成点赞模块。
在该业务完成后，我也在思索，点赞业务本来就是一个低频的业务，所以我自己认为其实没有必要做这个优化的，直接打db比力合适一点，这样也不必要RabbitMq。
HashMap是线程安全的吗？那要怎么保证线程安全？
HashMap不是线程安全的，解决线程安全的方法，我现在知道的就是SynchronziedMap和ConcurrentHashMap。ConcurrentHashMap的底层我也是有了解过的，在JDK1.8之前底层使用的Segement数组+数组来实现的。Segement数组中的每一个节点又是肯定范围的数组数据，在进行上锁的时候锁住的是Segement节点，锁的粒度是比力大的，而在JDK1.8之后底层使使用Hash数组+链表+红黑树来实现的，在每次进行上锁的时候锁住的是数组节点或链表头或红黑树根。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
