22.3PHP面试反思总结

leonsxd

已于 2022-06-02 17:06:57 修改

阅读量276

点赞数

分类专栏：面试文章标签： php

于 2022-04-02 15:36:05 首次发布

本文链接：https://blog.csdn.net/weixin_43884797/article/details/123741160

版权

面试专栏收录该内容

2 篇文章 0 订阅

订阅专栏

GM个人总结反思

项目难点及难点解决

结合自己的实际项目经验叙述即可。

线上项目出现问题排查方向

我结合实际生产环境流程，简单叙述了几个方向

第一个查看阿里云ECS/RDS主机指标，指标如有异常进行相应的进程或slowsql进行定位分析解决。
主机指标无异常的情况下，定位具体问题端。前端or后端，后端定位到具体接口通过nginx 日志/fpm日志查看是否有超时被杀死的进程或者其他异常情况。
实际上项目出现了问题在实际工作中，如果你动了线上的项目比如新发版本或者修改了配置等之类导致了问题那么多半是因为你的操作，如果没有操作线上那么可能磁盘满了、流量飙高突然导致的。

灰度发布

灰度发布、蓝绿发布以及实现工具
上述文章提到利用脉冲云实现灰度发布(但是目前官网好像已经打不开了)，且可以匹配用户流量的HTTP请求头，还可以直接指定匹配请求头中的Cookie信息，进行特定的测试人员验证线上新版本情况。
借助Openresty+lua脚本实现灰度发布
 Openresty+lus另一个实例
这个文章找了一些三方软件进行实现。
我觉得这些基本还是靠nginx的代理转发策略去实现的，你可以调整后端新版本的服务权重，放一点流量进来且结合白名单等匹配策略让固定的测试人员去测试。

一次url请求全流程

一次http请求全流程
主要是域名解析->寻址->解析->返回。（解析这里可以结合lnmp进行扩展）
如果请求的资源nginx无法全部解析一般都是通过fastcgi协议进行通信转发给php-fpm进程管理器然后寻找空闲的php解释器进行php解析工作，然后组装最终结果给到用户。

常见的httpcode码

100：继续客户端应当继续发送请求。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。

101：转换协议在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似措施。

102：继续处理由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

200：请求成功处理方式：获得响应的内容，进行处理

201：请求完成，结果是创建了新资源。新创建资源的URI可在响应的实体中得到处理方式：爬虫中不会遇到

202：请求被接受，但处理尚未完成处理方式：阻塞等待

204：服务器端已经实现了请求，但是没有返回新的信息。如果客户是用户代理，则无须为此更新自身的文档视图。处理方式：丢弃

300：该状态码不被HTTP/1.0的应用程序直接使用，只是作为3XX类型回应的默认解释。存在多个可用的被请求资源。处理方式：若程序中能够处理，则进行进一步处理，如果程序中不能处理，则丢弃
301：请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此资源处理方式：重定向到分配的URL

302：请求到的资源在一个不同的URL处临时保存处理方式：重定向到临时的URL

304：请求的资源未更新处理方式：丢弃

400：非法请求处理方式：丢弃

401：未授权处理方式：丢弃

403：禁止处理方式：丢弃

404：没有找到处理方式：丢弃

500：服务器内部错误服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器端的源代码出现错误时出现。

501：服务器无法识别服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。

502：错误网关作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

503：服务出错由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。

502/503/504状态码多是什么影响的怎么排查解决

502原因排查解释
 lnmp架构运行流程/502/504问题排查解释
 503部分原因解释

504解释

cpu还有50但是出了504怎么办，根据上述几个文章得出504代表网关超时（Gateway timeout），是指服务器作为网关或代理，但是没有及时从上游服务器收到请求。这是可以理解为什么cpu没有满出现504的情况。

lnpm谁是网关

nginx

mysql隔离级别解决了哪些问题

| |脏读 | 不可重复读 | 幻读||
|–|–|–|–|–|–|–|–|
| 读未提交 read uncommitted | 是 | 是 | 是
| 读已提交 read committed | 否 | 是 | 是
| 可重复读 repeatable read | 否 | 否 | 是 | 默认隔离级别
| 串行化 serializable | 否 | 否 | 否

mysql使用RR隔离级别主要是历史原因，5.0版本以前的的binlog的只支持STATEMENT这种格式！而这种格式在读已提交(Read Commited)这个隔离级别下主从复制是有bug的，简单说就是master执行sql语句的顺序记录到binlog后从在复制时会不一致导致问题。
但是实际上项目开发过程中我们都会使用RC这个隔离级别。
缘由一：在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多！
缘由二：在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行
缘由三：在RC隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性！
不可重复读侧重于修改
幻读侧重于新增和删除
解决不可重复读的问题只需要锁住满足条件的行，解决幻读需要锁表
详细解释可以看这篇文章，以及示例

聚簇索引是什么拿数据的

mysql索引数据结构详解
 https://www.jianshu.com/p/486a514b0ded
这两篇文章比较仔细

qps怎么得出的

UV、PV等概念解释
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
QPS主要强调服务器的处理能力，我一般是统计业务高峰时间内的访问PV日志数量来估计这些。

R360

个人介绍
项目介绍

面试题

反转一个32-bit的有符号的整数
入参：-120 出参：-21
力扣7题

echo reverse(-120);
function reverse($x) {
        $rev = 0;
        while ($x !=0){
            $digit = $x % 10;
            $x = intval($x/10);
            $rev = $rev*10 + $digit;
        }
        if ($rev < pow(-2,31) || $rev > pow(2,31)-1)return 0;
        return $rev;
    }

已知一个字符串数组，找到最长左子串
入参：[“flower”,“flow”,“flight”] 出参：“fl”

力扣14题

    function longestCommonPrefix($strs) {
        if(count($strs)==0)return '';
        for($i = 0; $i<strlen($strs[0]);$i++)
        {
            for($j = 1;$j<count($strs);$j++)
            {
                if($i==strlen($strs[$j]) || $strs[$j][$i] != $strs[0][$i]){
                    return substr($strs[0],0,$i);
                }
            }
        }
        return $strs[0];
    }

输入一个整型数组，数组中的一个或连续多个整数组成一个子数组。求所有子数组的和的最大值。
要求时间复杂度为O(n)。
示例1:
输入: nums = [-2,1,-3,4,-1,2,1,-5,4]
输出: 6
解释: 连续子数组 [4,-1,2,1] 的和最大，为 6。
力扣剑指offer42 题，连续子数组的最大和

function maxSubArray($nums) {
        $count = count($nums);
        if($count<1)return 0;
        $max = $nums[0];
        for ($i=1;$i<$count;$i++)
        {
            if($nums[$i] + $nums[$i-1] > $nums[$i] ){
                $nums[$i] += $nums[$i-1];
            }
            if($nums[$i] > $max)$max = $nums[$i];
        }
        return $max;
    }

sql题：
表：

输入: 
Employee 表:
+----+-------+--------+-----------+
| id | name  | salary | managerId |
+----+-------+--------+-----------+
| 1  | Joe   | 70000  | 3         |
| 2  | Henry | 80000  | 4         |
| 3  | Sam   | 60000  | Null      |
| 4  | Max   | 90000  | Null      |
+----+-------+--------+-----------+
输出: 
+----------+
| Employee |
+----------+
| Joe      |
+----------+
解释: Joe 是唯一挣得比经理多的雇员。

该表的每一行都表示雇员的ID、姓名、工资和经理的ID。

编写一个SQL查询来查找收入比经理高的员工。

以任意顺序返回结果表。

select 
a.name as Employee 
from Employee as a 
left join Employee as b on a.managerId=b.id 
where a.salary>b.salary

redis其他数据类型

其实以下不能都算是严格意义上的“数据类型”
HyperLogLog：Redis 在 2.8.9 版本添加了 HyperLogLog 结构。
Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。场景可以是统计百度、谷歌这种每天十亿级的Uv访问量等。
位图：位图不是特殊的数据结构，它的内容其实就是普通的字符串，也就是 byte 数组。
应用场景：
用户签到：在我们平时开发过程中，会有一些 bool 型数据需要存取，比如用户一年的签到记录，
签了是 1，没签是 0，要记录 365 天。如果使用普通的 key/value，每个用户要记录 365 个，当用户上亿的时候，需要的存储空间是惊人的。为了解决这个问题，Redis 提供了位图数据结构，这样每天的签到记录只占据一个位，365 天就是 365 个位，46 个字节 (一个稍长一点的字符串) 就可以完全容纳下，这就大大节约了存储空间。
用户在线状态
统计活跃用户
各种状态值
自定义布隆过滤器
点赞功能。

pub/sub：Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
stream：Redis Stream 是 Redis 5.0 版本新增加的数据结构。
Redis Stream 主要用于消息队列（MQ，Message Queue），Redis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能，但它有个缺点就是消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。
简单来说发布订阅 (pub/sub) 可以分发消息，但无法记录历史消息。
而 Redis Stream 提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。
GEO：
Redis GEO 主要用于存储地理位置信息，并对存储的信息进行操作，该功能在 Redis 3.2 版本新增。
意味着我们可以使用 Redis 来实现
摩拜单车「附近的 Mobike」、美团和饿了么「附近的餐馆」这样的功能了

redis集群

https://www.cnblogs.com/vieta/p/11192137.html
http://redisdoc.com/topic/cluster-tutorial.html

redis高可用

https://zhuanlan.zhihu.com/p/112899242
https://blog.csdn.net/u014209205/article/details/82113258

mysql 隔离级别，为什么用读已提交这种级别

https://www.cnblogs.com/jian-gao/p/10795407.html
https://www.cnblogs.com/shoshana-kong/p/10516404.html

git、svn区别

https://blog.csdn.net/bruce_6/article/details/38299677

数据库优化了哪些方面，数据库分表怎么分的

https://www.cnblogs.com/sharpest/p/10390035.html
https://zhuanlan.zhihu.com/p/59818056

雪花算法，美团的雪花算法leaf

https://zhuanlan.zhihu.com/p/85837641
https://tech.meituan.com/2017/04/21/mt-leaf.html

php设计模式，手撸单例

https://www.cnblogs.com/yuanwanli/p/8796402.html
https://www.cnblogs.com/shamohai/p/11158206.html

ZZHL

医疗健康业务

一面：

const与define

参考:
详解PHP中const和define的区别

Mysql8.0与Mysql5.7select语句执行的区别

Mysql8.0删除了查询缓存层

Mysql select语句执行过参考:
MySQL Select语句是如何执行的
 mysql8.0和mysql5.7的区别是什么？

Mysql 主从复制实现

1. 解决的问题
    1. 数据分布
    2. 负载均衡
    3. 数据备份，高可用，避免单点失败
    4. 实现读写分离，缓解数据库压力
    5. 升级测试（使用高版本mysql当从库）
2. 支持的复制类型（binlog 的三种格式）
    1. 基于sql语句的复制
    2. 基于行的复制
    3. 混合型复制
3. 原理
    1. 基础概念
        1. 从库生成两个线程
            1. I/O线程
            2. SQL线程
        2. 主库生成线程
            1. log dumo 线程
    2. 流程（主节点必须开启bin log功能，）
        1. 从节点开启start slave 命令之后，创建一个IO进程连接到主节点
        2. 连接成功之后，主节点创建一个 log dump线程(主节点会为每一个从节点创一个log dump线程)
        3. 当binlog发生变化时，主节点的dump log线程会读取bin-log内容并发送给从节点
        4. 主节点dump log 线程读取bin-log 的内容时会对主节点的bin-log加锁，读取完成在发送给从节点之前释放锁
        5. 从节点的IO线程接收主节点发送的binlog内容，并将其写入本地relay log 文件中
        6. 主从节点通过binlog文件+position偏移量定位主从同步的位置，从节点会保存接收到的position偏移量，如果从节点发生宕机重启，自动从postion位置发起同步
        7. 从节点的SQL线程复制读取本地relay log的内容，解析成具体的操作并执行，保证主从数据一致性
    4. 主从复制的模式
        1. 异步模式（默认方式）
            1. 可能导致主从不一致（主从延时）
            2. 主节点接收到客户端提交的事务之后直接提交事务并返回给客户端
            3. 如果主节点事务提交之后，log dump还没来得及写入就宕机就会导致主从数据不一致
            4. 不用关心主从的同步操作，性能最好            
        2. 全同步模式
            1. 可靠更高，但是会影响主库相应时间
            2. 主节点接收到客户端提交的事务之后，必须等待binlog 发送给从库，并且所有从库全部执行完事务之后才返回给客户端
        3.  半同步模式
            1.  增加一部分可靠性，增加主库一部分相应时间
            2.  主节点接收到客户端提交的事务之后，等待binlog发送给至少一个从库并且成功保存到本地relay log中，此时主库提交事务并返回给客户端
        4. server-id的配置和server-uuid
            1. server-id用于标识数据库实例，防止在链式主从、多主多从拓扑中导致SQL语句的无限循环
            2. server-id默认值为0，对于主机来说依然会记录二进制日志，但是会拒绝所有的从机连接。
            2. server-id = 0 对于从机来说会拒绝连接其他实例
            3. server-id是一个全局变量，修改之hi偶必须重启服务
            4. 主库和从库的server-id重复时
                1. 默认replicate-same-server-id = 0，从库会跳过所有主从同步的数据，导致主从数据不一致
                2. replicate-same-server-id = 1，可能导致无线循环执行sql
            5. 两个从库（B、C）server-id重复会导致主从连接异常，时断时连
                1. 主库（A）发现相同的server-id会断开之前的连接，重新注册新的连接
                2. B、C从库的连接会周而复始的重连
            6. MySQL服务会自动创建并生成server-uuid配置
                1. 当主从同步时如果主从实例的server-uuid相同会报错退出，不过我们可以通过设置replicate-same-server-id=1来避免报错（不推荐）

     5. 读写分离 
         1. 基于代码实现，减少硬件开支
         2. 基于中间代理实现
         3. 主从延时
             1. 从库性能比主库差
             2. 大量查询导致从库压力大，消耗大量CPU资源，影响同步速度：一主多从
             3. 大事务执行：事务执行完之后才会写入binlog，从库读取延时
             4. 主库ddl（alter、drop、create）