这些年背过的面试题——个人项目篇 - 生活资讯 - 生活信息

阿里妹导读

本文是技术人面试系列个人项目篇，作者总结了一些自己的实战项目经验，一文带你详细了解，欢迎收藏！

一、一站到底

采用SpringBoot构建项目，主要通过分布式缓存、队列、限流保证系统高可用，Netty、缓存、反向代理保证高并发。

双人对战答题、公司对战抢答。

1、如何设计排行榜

性能优化过程

第一条需求很简单，使用了Redis的Zset实现不过这里总得分采用了基于分数、时间、次数和正确率的混合加权。考虑到数据的持久化，以及关系数据库和缓存的一致性导致的设计的复杂性，使用了谷歌开源的JamsRanking。

优点是可以直接使用现成的setScores和getRanking接口封装了Redis和Mysql和消息队列的完成事务和一致性的使用细节。缺点是并发比较低使用Jmeter进行压测，单机只有20左右的TPS。

后来看了下源码，主要是它针对每一次设置都进行了分布式事务处理，并且会返回事务提交或回滚的结果。了解了底层实现以后就去谷歌的开源社区去查阅了相关的解决方案，当时官方对这个问题并没有通过配置能直接解决问题的快捷方式，不过推荐了使用者自身如果对响应时间不高的场景下可以采用批量合并事务的方式进行优化。基于这个思路，我们把写操作进行了封装并放入了队列，然后在消费者端批量取得数据后进行事务的批量处理，压测环境下整体性能达到了500TPS。已经基本满足了线上更新的需求，但是当时压测的过程中，队列偶尔的吞吐量会大范围波动，经常会持续数十秒，然后业务一次性处理完再响应，导致局部响应时间大幅度增长。

后来也是在官网上查询，了解到谷歌开源组件使用的队列服务底层是使用BigTable作为持久层，但是当BigTable分片过大时，会触发再分片的过程，再分片的过程中，是不会进行任务分发的，所以就会导致先前的问题。针对这个问题，谷歌官方的建议是提前配置队列的数量、负载策略和最大容量等信息，保证所有队列不同时触发再分片。

进行两次优化后，压测环境已经基本可以满足预期了，在实际生产环境的部署中，发现对于事务更新失败时，JamsRanking会对失败的事务进行切分和重试，整个过程对于研发人员是透明的，不利于线上问题排查，所以我们当时特地写了一个watchdog的工具，监控事务回滚达到十次以上的事务，查明原因后通过后台管理系统进行相应补偿，保证最终一致性。

最终结果：

针对这个缺点谷歌官方也是给出了使用分片树和近似排名的解决方案，当然复杂的方案有更高的运维成本，所以我们优化工作也就到此为止。

方案优化过程

方案1：每日一个滚动榜，当日汇聚（费时间）

首先记录每天的排行榜和一个滚动榜，加分时同时写入这两个榜单，每日零点后跑工具将前几天数据累加写入当日滚动榜，该方案缺点是时间复杂度高，7天榜还好，只需要读过去6天数据，如果是100天榜，该方案需要读过去99天榜，显然不可接受。

方案2：全局N个滚动榜同时写（费空间）

要做到每日零点后榜单实时生效，而不需要等待离线作业的完成，一种方案是预写未来的榜单。可以写当天的滚动榜的同时，写往后N-1天的滚动榜一起写入该方案不仅能脱离离线作业做到实时更新，且可以省略每天的日榜。但缺点也不难看出，对于7天滚动榜，每次写操作需要更新7个榜单，但是对于百日榜，空间消耗无法接受，1000万榜单大约消耗1G内存。

方案3：实时更新，常数次写操作

有不有办法做到既能实时更新，写榜数量也不随N的增加而增加呢？

仍然是记录每天的排行榜和一个滚动榜，加分操作也还是同时操作当日榜和全局榜，但每日零点的离线作业改为从全局榜中减去之前过期的数据，从而实现先滚动更新。此方案每次只需读取一个日榜做减法，时间复杂度为O(1)；但是无法做到实时更新。这个方案的优点是在十二点前提前准备好差分榜，到了十二点直接加上当天数据就是滚动榜内容，这样就在常数次写操作的前提下，实现了滚动榜的实时更新。

2、如何解决重复答题

利用setnx防止重复答题

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。利用Redis的单线程特性对共享资源进行串行化处理。

3、一个题目被多个人抢答

利用redis来实现乐观锁（抢答），好处是答错的人不影响状态，第一个秒杀答对的人才能得分。

1、利用redis的watch功能，监控这个 Corp:Activ:Qust: 的状态值；
2、获取Corp:Activ:Qust: 的值，创建redis事务，给这个key的值-1；
3、执行这个事务，如果key的值被修改过则回滚，key不变；

4、如何管理昵称重复

使用布隆过滤器：

它实际上是一个很长的二进制矢量数组和 K 个哈希函数。当一个昵称加入布隆过滤器中的时候，会进行如下操作：

用户新增昵称时需要首先计算K个哈希值，如果K个哈希值有一个不为0则通过，否则不通过，不通过时通过加随机字符串再次检验，检测通过后返回给前端，帮助用户自动填写。

布隆过滤器的好处是它可以用来判断一个元素是否在一个集合中。它的优势是只需要占用很小的内存空间以及有着高效的查询效率。对于布隆过滤器而言，它的本质是一个位数组：位数组就是数组的每个元素都只占用 1 bit ，并且每个元素只能是 0 或者 1。

BloomFilter 的优势是，全内存操作，性能很高。另外空间效率非常高，要达到 1% 的误判率，平均单条记录占用 1.2 字节即可。而且，平均单条记录每增加 0.6 字节，还可让误判率继续变为之前的 1/10，即平均单条记录占用 1.8 字节，误判率可以达到 1/1000；平均单条记录占用 2.4 字节，误判率可以到 1/10000，以此类推。这里的误判率是指，BloomFilter 判断某个 key 存在，但它实际不存在的概率，因为它存的是 key 的 Hash 值，而非 key 的值，所以有概率存在这样的 key，它们内容不同，但多次 Hash 后的 Hash 值都相同。对于 BloomFilter 判断不存在的 key ，则是 100% 不存在的，反证法，如果这个 key 存在，那它每次 Hash 后对应的 Hash 值位置肯定是 1，而不会是 0。

5、如何管理出题定时任务

压测环境中服务器通过Netty的主从Reactor多路复用NIO事件模型，单机可以轻松应对十万长连接，但是每个业务中，由于每个用户登录系统后需要按照指定顺序答题，例如一共要答十道，那么服务器针对这一个用户就会产生十个定时任务，所以对于系统来说，定时器的数量就是百万级别的。

通过压测结果发现：JDK自带的Timer，在大概三万并发时性能就急剧下降了。也是此时根据业务场景的需要，将定时任务改成了Netty自带的HashedWheelTimer时间轮方案，通过压测单机在50万级别下依然能够平滑的执行。

也是这个强烈的反差，使我在强烈的好奇心促使下，阅读源码了解到常规的JDK 的Timer 和 DelayedQueue 等工具类，可实现简单的定时任务，单底层用的是堆数据结构，存取复杂度都是 O(NlogN)，无法支撑海量定时任务。Netty经典的时间轮方案，正是通过将任务存取及取消操作时间复杂度降为 O(1)，而广泛应用在定时任务量大、性能要求高的场景中。

基于Netty的Websocket底层，服务器端维护一个高效批量管理定时任务的调度模型。时间轮一般会实现成一个环形数组结构，类似一个时钟，分为很多槽，一个槽代表一个时间间隔，每个槽使用双向链表存储定时任务。指针周期性地跳动，跳动到一个槽位，就执行该槽位的定时任务。

单层时间轮的容量和精度都是有限的，对于精度要求特别高、时间跨度特别大或是海量定时任务需要调度的场景，可以考虑使用多级时间轮以及持久化存储与时间轮结合的方案。时间轮的定时任务处理逻辑如下：

6、如何解决客户端断连

使用Netty的重连检测狗ConnectionWatchdog

服务端定义refreshTime，当我们从channel中read到了服务端发来的心跳响应消息的话，就刷新refreshTime为当前时间。

客户端在state是WRITER_IDLE的时候每隔一秒就发送一个心跳包到sever端，告诉server端我还活着。

当重连成功时，会触发channelActive方法，在这里我们开启了一个定时任务去判断refreshTime和当前时间的时间差，超过5秒说明断线了，要进行重连，最后计算重连次数，尝试连接2次以上连不上就会修改header信息强制重连去连另一个服务器。

二、秒杀项目

技术选型

秒杀用到的基础组件，主要有框架、KV 存储、关系型数据库、MQ。

框架主要有 Web 框架和 RPC 框架。

其中，Web 框架主要用于提供 HTTP 接口给浏览器访问，所以 Web 框架的选型在秒杀服务中非常重要。在这里，我推荐Gin，它的性能和易用性都不错，在 GitHub 上的 Star 达到了 44k。对比性能最好的 fasthttp，虽然 fasthttp 在请求延迟低于 10ms 时性能优势明显，但其底层使用的对象池容易让人踩坑，导致其易用性较差，所以没必要过于追求性能而忽略了稳定性。

至于 RPC 框架，我推荐选用 gRPC，因为它的扩展性和性能都非常不错。在秒杀系统中，Redis 中的数据主要是给秒杀接口服务使用，以便将配置从管理后台同步到 Redis 缓存中。

KV 存储方面，秒杀系统中主要是用 Redis 缓存活动配置，用 etcd 存储集群信息。

关系型数据库中，MySQL 技术成熟且稳定可靠，秒杀系统用它存储活动配置数据很合适。主要原因还是秒杀活动信息和库存数据都缓存在 Redis 中，活动过程中秒杀服务不操作数据库，使用 MySQL 完全能够满足需求。

MQ 有很多种，其中 Kafka 在业界认可度最高，技术也非常成熟，性能很不错，非常适合用在秒杀系统中。Kafka 支持自动创建队列，秒杀服务各个节点可以用它自动创建属于自己的队列。

IP限流 | 验证码 | 单用户 | 单设备 | IMEI | 源IP |均设置规则

redis集群+本地缓存+限流+key加随机值分布在多个实例中：

1、缓存集群可以单节点进行主从复制和垂直扩容；

2、利用应用内的前置缓存，但是需注意需要设置上限；

3、延迟不敏感，定时刷新，实时感知用主动刷新；

4、和缓存穿透一样，限制逃逸流量，单请求进行数据回源并刷新前置；

5、无论如何设计，最后都要写一个兜底逻辑，千万级流量说来就来；

使用缓存策略将请求挡在上层中的缓存中

使用CDN，能静态化的数据尽量做到静态化

加入限流（比如对短时间之内来自某一个用户，某一个IP、某个设备的重复请求做丢弃处理）。

资源隔离限流会将对应的资源按照指定的类型进行隔离，比如线程池和信号量。

对于一段时间内的秒杀活动，需要保证写成功，我们可以使用消息队列。

削去秒杀场景下的峰值写流量

通过异步处理简化秒杀请求中的业务流程

先处理主要的业务，异步处理次要的业务。

解耦

实现秒杀系统模块之间松耦合将秒杀数据同步给数据团队，有两种思路：

CacheAside旁路缓存读请求不命中查询数据库，查询完成写入缓存，写请求更新数据库后删除缓存数据。

为防缓存失效这一信息丢失，可用消息队列确保。

订阅binlog程序在mysql中有现成的中间件叫canal，重试机制，主要采用的是消息队列的方式。

终极方案：请求串行化

真正靠谱非秒杀的方案：将访问操作串行化

需要解决的问题：

由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。哨兵模式适合读请求远多于写请求的业务场景，比如在秒杀系统中用来缓存活动信息。如果写请求较多，当集群 Slave 节点数量多了后，Master 节点同步数据的压力会非常大。

当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。

秒杀服务单节点需要处理的请求 QPS 可能达到 10 万以上。一个请求从进入秒杀服务到处理失败或者成功，至少会产生两条日志。也就是说，高峰期间，一个秒杀节点每秒产生的日志可能达到 30 万条以上。

一块性能比较好的固态硬盘，每秒写的IOPS 大概在 3 万左右。也就是说，一个秒杀节点的每秒日志条数是固态硬盘 IOPS 的 10 倍，磁盘都扛不住，更别说通过网络写入到监控系统中。

解决方案

10、池化技术

通常可以采用循环队列来保存空闲连接。使用的时候，可以从队列头部取出连接，用完后将空闲连接放到队列尾部。Netty中利用带缓冲区的 channel 来充当队列。

三、即时通信

1、单聊消息可靠传输

TCP保证消息可靠传输三板斧：超时、重传、确认。服务端和客户端通信MSG和ACK的共计6个报文。

在线消息流程：

A 消息请求 MSG:R => S 消息应答 MSG:A => S 消息通知B MSG:N

S 确认通知 ACK:N <= S 确认应答 ACK:A <= B确认请求S ACK:R

超时与重传、确认和去重：

A发出了 MSG:R ，收到了MSG:A之后，在一个期待的时间内，如果没有收到ACK:N，A会尝试将 MSG:R 重发。可能A同时发出了很多消息，所以A需要在本地维护一个等待ack队列，并配合timer超时机制，来记录哪些消息没有收到ACK:N，定时重发。确认ACK保证必达，去重保证唯一

离线消息流程

原方案：根据离线好友的标识，交互拉取指定的消息。

图片来源于网络

优化的方案：

2、群聊消息如何保证不丢不重

在线的群友能第一时间收到消息；
离线的群友能在登陆后收到消息。

图片来源于网络

对于同一份群消息的内容，多个离线用户存储了很多份。假设群中有200个用户离线，离线消息则冗余了200份，这极大的增加了数据库的存储压力

4、推拉结合

历史方案：

“消息风暴扩散系数”是指一个消息发出时，变成N个消息的扩散系数，这个系数与业务及数据相关，一定程度上它的大小决定了技术采用推送还是拉取。

优化方案：

5、好友推荐

Neo4j 图谱数据库

四、智慧社区

18年初，针对我们Dubbo框架的智慧楼宇项目的单体服务显得十分笨重，需要采用微服务的形式进行架构的重新设计，当时，我阅读了Eric Evans 写的《领域驱动设计：软件核心复杂性应对之道》和Martin fowler的《微服务架构：Microservice》两本重量级书籍，书中了解到转型微服务的重要原因之一就是利用分治的思想减少系统的复杂性，是一种针对复杂问题的宏观设计，来应对系统后来规模越来越大，维护越来越困难的问题。然而，拆分成微服务以后，并不意味着每个微服务都是各自独立地运行，而是彼此协作地组织在一起。这就好像一个团队，规模越大越需要一些方法来组织，这正是我们需要DDD模型为我们的架构设计提供理论并实践的方法。

当时每次版本更新迭代动辄十几个微服务同时修改，有时一个简单的数据库字段变更，也需要同时变更多个微服务，引起了团队的反思：微服务化看上去并没有减少我们的工作量。《企业架构设计》中对于微服务的定义是小而专，但在起初的设计时，我们只片面的理解了小却忽视了专，此时我们才意识到拆分的关键是要保证微服务内高内聚，微服务间低耦合。

物联网平台接入

向下连接海量设备，支撑设备数据采集上云；

向上通过调用云端API将指令下发至设备端，实现远程控制。

上行数据链路

下行指令链路

门锁接入

WIFI门锁：非保活平常处于断电休眠状态，需要MCU 唤醒才能传输和发送数据；

蓝牙门锁：MCU串口对接和SDK对接，近距离单点登录和远距离网关登录；

Zigbee门锁：非保活但是保持心跳，MCU对接，Zigbee协议控制；

NB-Iot门锁：可以通过公网连接，把门禁变成SAAS服务，MCU；

各种协议

HTTP协议（CS用户上网）

HTTP协议是典型的CS通讯模式，由客户端主动发起连接，向服务器请求XML或JSON数据。该协议最早是为了适用web浏览器的上网浏览场景和设计的，目前在PC、手机、pad等终端上都应用广泛，但并不适用于物联网场景。

RESTAPI（松耦合调用）

REST/HTTP主要为了简化互联网中的系统架构，快速实现客户端和服务器之间交互的松耦合，降低了客户端和服务器之间的交互延迟。因此适合在物联网的应用层面，通过REST开放物联网中资源，实现服务被其他应用所调用。

CoAP协议（无线传感）

简化了HTTP协议的RESTful API，它适用于在资源受限的通信的IP网络。

MQTT协议（低带宽）

MQTT协议采用发布/订阅模式，物联网终端都通过TCP连接到云端，云端通过主题的方式管理各个设备关注的通讯内容，负责将设备与设备之间消息的转发。

适用范围：在低带宽、不可靠的集中星型网络架构（hub-and-spoke），不适用设备与设备之间通信，设备控制能力弱，另外实时性较差，一般都在秒级。协议要足够轻量，方便嵌入式设备去快速地解析和响应。具备足够的灵活性，使其足以为 IoT 设备和服务的多样化提供支持。应该设计为异步消息协议，这么做是因为大多数 IoT 设备的网络延迟很可能非常不稳定，若使用同步消息协议，IoT 设备需要等待服务器的响应，必须是双向通信，服务器和客户端应该可以互相发送消息。

AMQP协议（互操作性）

用于业务系统例如PLM，ERP，MES等进行数据交换。

适用范围：最早应用于金融系统之间的交易消息传递，在物联网应用中，主要适用于移动手持设备与后台数据中心的通信和分析。

XMPP协议（即时通信）

开源形式组织产生的网络即时通信协议。被IETF国际标准组织完成了标准化工作。

适用范围：即时通信的应用程序，还能用在协同工具、游戏等。

XMPP在通讯的业务流程上是更适合物联网系统的，开发者不用花太多心思去解决设备通讯时的业务通讯流程，相对开发成本会更低。但是HTTP协议中的安全性以及计算资源消耗的硬伤并没有得到本质的解决。

JMS （Java消息服务）

Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。

Zigbee协议

低功耗，它保持IEEE 802.15.4（2003）标准

IOT流量洪峰

智慧社区IOT领域，不管是嵌入式芯片还是应用服务器都需要传递消息，常见上行的消息有：人脸识别开门、烟感雾感告警、共享充电桩充电，下行的广告下发、NB门禁开门指令、超级门板显示等，由于物联网设备时不时会故障和断网导致大量的流量洪峰，传统消息队列需要针对性优化。

图片来源于网络

如果解决海量Topic

首先要做的就是分区、分组等水平拆分的方式，接下来考虑单实例如何处理更多Topic，传统消息队列在海量Topic下顺序写会退化成随机写，性能大幅下降

针对单个Topic海量订阅的问题，可以在上层封装广播组件来协调批量发送。

图片来源于网络

社区直播带货

使用端 / 边 / 云三级架构，客户端加密传输，边缘节点转发、云侧转码并持久化。

产品的背景

上线时间，从调研到正式上线用了 3个月时间，上线后一个月内就要经历双十二挑战。在这么紧的上线时间要求下，需要用到公司提供的所有优势，包括cdn网络，直播牌照等。

面临的挑战

协议的比较

整体流程

RTMPS：基于TCP实时传输消息协议，更安全更可靠

MPEG-DASH：是一种基于HTTP协议自适应比特率流媒体技术，应对复杂的环境

直播流程

播放流程

收获

直播高可用方案

网络可靠性：

惊群效应：

性能优化方案

数据库优化： 数据库是最容易成为瓶颈的组件，考虑从 SQL 优化或者数据库本身去提高它的性能。如果瓶颈依然存在，则会考虑分库分表将数据打散，如果这样也没能解决问题，则可能会选择缓存组件进行优化。

集群最优：存储节点的问题解决后，计算节点也有可能发生问题。一个集群系统如果获得了水平扩容的能力，就会给下层的优化提供非常大的时间空间，由最初的 3 个节点，扩容到最后的 200 多个节点，但由于人力问题，服务又没有什么新的需求，下层的优化就一直被搁置着。

硬件升级：水平扩容不总是有效的，原因在于单节点的计算量比较集中，或者 JVM 对内存的使用超出了宿主机的承载范围。在动手进行代码优化之前，我们会对节点的硬件配置进行升级。

代码优化：代码优化是提高性能最有效的方式，但需要收集一些数据，这个过程可能是服务治理，也有可能是代码流程优化。比如JavaAgent 技术，会无侵入的收集一些 profile 信息，供我们进行决策。

并行优化：并行优化是针对速度慢的接口进行并行调用。所以我们通常使用 ContDownLatch 对需要获取的数据进行并行处理，效果非常不错，比如在 200ms 内返回对 50 个耗时 100ms 的下层接口的调用。

JVM 优化： JVM 发生问题时，优化会获得巨大的性能提升。但在 JVM 不发生问题时，它的优化效果有限。但在代码优化、并行优化、JVM 优化的过程中，JVM 的知识却起到了关键性的作用。

操作系统优化：操作系统优化是解决问题的杀手锏，比如像 HugePage、SWAP、“CPU 亲和性”这种比较底层的优化。但就计算节点来说，对操作系统进行优化并不是很常见。运维在背后会做一些诸如文件句柄的调整、网络参数的修改，这对于我们来说就已经够用了。

流量回放自动化测试

系统级的重构，测试回归的工作量至少都是以月为单位，对于人力的消耗巨大。一种应对方案是，先不改造，到系统实在扛不住了再想办法。另一种应对方案是，先暂停需求，全力进行改造。但在实际工作场景中，上述应对策略往往很难实现。

场景：

1、读服务均是查询，它是无状态的。

2、不管是架构升级还是日常需求，读服务对外接口的出入参格式是没有变化的。

本文地址：http://ww.kub2b.com/tnews/4710.html 企库往 http://ww.kub2b.com/ , 查看更多

特别提示：本信息由相关用户自行提供，真实性未证实，仅供参考。请谨慎采用，风险自负。

更多>同类生活信息

文章列表

相关文章

最新动态

推荐图文

生活信息

点击排行

• 耐水弹力海棉	• 耐水高强度海棉
• 防潮耐水EVA材料	• 耐油耐水海绵
• 供应耐水海绵	• 看了OPPO、vivo的新旗舰手机样张后，决定还是继
• 微信借钱不求人，6个步骤轻松搞定...手机微信怎	• 小米8系列手机，有它才叫防摔保护手机爆屏「小
• 米其林指南开启江苏篇章，“江苏味”如何与世界	• 重磅发布！5.4%！