频道导航

PHP-面试总结——高并发篇

2020-11-07 PHP面试题前端之家

前端之家收集整理的这篇文章主要介绍了PHP-面试总结——高并发篇，前端之家小编觉得挺不错的，现在分享给大家，也给大家做个参考。

1、什么是rabbitmq

@H_403_2@采用AMQP高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦

@H_403_2@ @H_403_2@

2、为什么要使用rabbitmq

@H_403_2@1. 在分布式系统下具备异步,削峰,负载均衡等一系列高级功能;

@H_403_2@2. 拥有持久化的机制，进程消息，队列中的信息也可以保存下来。

@H_403_2@3. 实现消费者和生产者之间的解耦。

@H_403_2@4. 对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作。

@H_403_2@可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单

3、使用rabbitmq的场景

@H_403_2@1. 服务间异步通信 @H_403_2@2. 顺序消费 @H_403_2@3. 定时任务 @H_403_2@4. 请求削峰 @H_403_2@ @H_403_2@

4、如何确保消息正确地发送至RabbitMQ？如何确保消息接收方消费了消息？

发送方确认模式

@H_403_2@将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。 @H_403_2@一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。 @H_403_2@如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。 @H_403_2@发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。 @H_403_2@ @H_403_2@

接收方确认机制

@H_403_2@接收方消息确认机制 @H_403_2@消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。 @H_403_2@这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性； @H_403_2@下面罗列几种特殊情况 @H_403_2@如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重） @H_403_2@如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。
@H_403_2@ @H_403_2@

5.如何避免消息重复投递或重复消费？

@H_403_2@在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列； @H_403_2@在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费。

6、消息基于什么传输？

@H_403_2@由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。 @H_403_2@

7、消息如何分发？

@H_403_2@若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。通过路由可实现多消费的功能 @H_403_2@ @H_403_2@ @H_403_2@

8、消息怎么路由？

@H_403_2@消息提供方->路由->一至多个队列消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。通过队列路由键，可以把队列绑定到交换器上。 @H_403_2@消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）； @H_403_2@常用的交换器主要分为一下三种 @H_403_2@· fanout：如果交换器收到消息，将会广播到所有绑定的队列上 @H_403_2@· direct：如果路由键完全匹配，消息就被投递到相应的队列 @H_403_2@· topic：可以使来自不同源头的消息能够到达同一个队列。使用topic交换器时，可以使用通配符 @H_403_2@ @H_403_2@ @H_403_2@

9、如何确保消息不丢失？

@H_403_2@消息持久化，当然前提是队列必须持久化 RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。 @H_403_2@一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。

10、使用RabbitMQ有什么好处？

@H_403_2@1、服务间高度解耦 2、异步通信性能高 3、流量削峰 @H_403_2@ @H_403_2@

11、rabbitmq的集群

@H_403_2@镜像集群模式 @H_403_2@你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。 @H_403_2@好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue

12.mq的缺点

@H_403_2@系统可用性降低 @H_403_2@系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。 @H_403_2@系统复杂性提高 @H_403_2@硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已

13.一致性问题

@H_403_2@A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。 @H_403_2@所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的

14. 分布式事务

@H_403_2@分段提交。会有一个仲裁者，然后给所有节点来发消息。当所有节点都ack之后，才会成功。否则就得等待重发。

15.针对直播这种突然@R_863_403@的情况，该怎么设计。

@H_403_2@1. Nginx加机器 @H_403_2@2. cdn缓存静态页面 @H_403_2@3. redis队列，让用户慢点进来。 @H_403_2@4. 加缓存。缓存用户数据，比如用户信息。 @H_403_2@5. 数据库使用主从 @H_403_2@6. 弹性扩容 @H_403_2@7. 限流熔断

@H_403_2@ @H_403_2@

我的官方群点击此处加入群聊【PHP/web/高级学习交流群】,一起学习，相互讨论。

群内已经有管理将知识体系整理好（源码，学习视频等资料），欢迎加群免费领取。

这套精品PHP教程绝不是市场上的那些妖艳贱货可比，作为web开发的佼佼者PHP并不逊色其他语言，加上Swoole后更加是如虎添翼！进军通信、物联网行业开发百度地图、百度订单中心、虎牙、战旗TV等！寒冬裁员期过后正是各大企业扩大招人的时期，现在市场初级程序员泛滥，进阶中高级程序员绝对是各大企业急需的人才，这套学习教程适合那些1-5年以内的PHP开发者正处于瓶颈期，想要突破自己进阶中高级、架构师！名额有限，先到先得！

部分资料截图：

@H_403_2@