查看“常见问题”的源代码

== cookie 和 session 的区别 ==
* 作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
* 存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
* 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
* 隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
* 存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。


分布式session

ip_hash 
Session 复制
缓存中间件

== post 和 get 的区别 ==
https://www.w3school.com.cn/tags/html_ref_httpmethods.asp

GET 用于获取信息，是无副作用的，是幂等的，且可缓存
POST 用于修改服务器上的数据，有副作用，非幂等，不可缓存
* 安全？post请求不会保留在浏览器历史记录中

{|class="wikitable"
!colspan="2"|GET
|POST
|-
|后退按钮/刷新
|	无害	
|数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
|-
|书签	
|可收藏为书签	
|不可收藏为书签
|-
|缓存	
|能被缓存	
|不能缓存
|-
|编码类型
|	application/x-www-form-urlencoded	
|application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
|-
|历史	
|参数保留在浏览器历史中。	
|参数不会保存在浏览器历史中。
|-
|对数据长度的限制	
|是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。	
|无限制。
|-
|对数据类型的限制	
|只允许 ASCII 字符。	
|没有限制。也允许二进制数据。
|-
|安全性	
|与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。
在发送密码或其他敏感信息时绝不要使用 GET ！
|POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
|-
|可见性	
|数据在 URL 中对所有人都是可见的。	
|数据不会显示在 URL 中。
|}

== 转发和重定向的区别 ==
转发

1. 是服务器内部的重定向，服务器直接访问目标地址的 url网址，把里面的东西读取出来，但是客户端并不知道，因此用forward的话，客户端浏览器的网址是不会发生变化的。
 
2. 关于request: 由于在整个定向的过程中用的是同一个request，因此forward会将request的信息带到被重定向的地址中。

重定向

1.是客户端的重定向，是完全的跳转。即服务器返回的一个url给客户端浏览器，然后客户端浏览器会重新发送一次请求，到新的url里面，因此浏览器中显示的url网址会发生变化。 

2.因为这种方式比forward多了一次网络请求，因此效率会低于forward。

== 堆栈区别  ==
== 并发和并行的区别 ==
行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔发生。

== 索引 ==
=== 不走索引 ===
=== 行级锁和表级锁 ===

行级锁定的优点：

·         当在许多线程中访问不同的行时只存在少量锁定冲突。

·         回滚时只有少量的更改。

·         可以长时间锁定单一的行。

行级锁定的缺点：

·         比页级或表级锁定占用更多的内存。

·         当在表的大部分中使用时，比页级或表级锁定速度慢，因为你必须获取更多的锁。

·         如果你在大部分数据上经常进行GROUP BY操作或者必须经常扫描整个表，比其它锁定明显慢很多。

·         用高级别锁定，通过支持不同的类型锁定，你也可以很容易地调节应用程序，因为其锁成本小于行级锁定。

== 存储引擎 ==
* InnoDB
== 数据库，事务，隔离级别，存储引擎  ==
* 数据库，三大范式
== redis，有什么优势 -memcache对比 ==
数据存储位置
* redis： 内存、磁盘(数据持久化)
* memcache: 内存

存储数据的类型（都是键值对的形式）值的类型：
* redis：list、set、hash、string、zset等
* memcache：string

== http\https ==
* 默认端口不同80：443
* https需要颁发证书
* HTTPS协议的安全性更高
* https缺点
** 速度慢
** 服务器成本

== 数据库的存储引擎应用场景，索引结构  ==

MyISAM表使用B型树索引。 读取场景下性能好，表锁，不能事务

InnoDB是为处理巨大数据量时的最大性能设计。B树。由于是行锁，写入、更新速度可能会快。

MEMORY表被存储在内存中，且默认使用哈希索引


为什么索引结构默认使用B-Tree，而不是hash，二叉树，红黑树？
* hash：虽然可以快速定位，但是没有顺序，IO复杂度高。
* 二叉树：树的高度不均匀，不能自平衡，查找效率跟数据有关（树的高度），并且IO代价高。
* 红黑树：树的高度随着数据量增加而增加，IO代价高。

为什么建议使用自增长主键作为索引。

结合B+Tree的特点，自增主键是连续的，在插入过程中尽量减少页分裂，即使要进行页分裂，也只会分裂很少一部分。并且能减少数据的移动，每次插入都是插入到最后。总之就是减少分裂和移动的频率。

== 大数据量的优化 ==
* 分区、分表、分库

== 设计一个权限系统  ==
== 算法题 ==
== 红黑树  ==
== 多线程，sleep，wait，yield  ==
== restful ==
== 设计模式，单例模式，适配器模式  ==
== 操作系统，死锁  ==
== 快排时间复杂度  ==
== nginx可承受的压力  ==
== 项目 ==
* 项目难点 
* 架构优化
* 难点
* 主要业务
== 服务调用超时可能由什么造成  ==

* 网络问题，是否繁忙？
* cpu、内存排查，cpu消耗高，处理不过来
* 服务端有没有收到请求，看请求响应时间
* 客服端网络、cpu等有问题

== 进程间的通信方式  ==
== fpm ==
* 合适的超时时间request_terminate_timeout、max_execution_time
* 看服务器性能，设置进程数量max_children
* fpm进程处理最大请求数max_requests


== nginx ==

* worker_processes 8; #nginx进程数，建议按照cpu数目来指定，一般为它的倍数,平时设置为2倍。

* 静态资源缓存

* nginx打开文件的最大个数

* buffer： 如果buffer太小，Nginx会不停的写一些临时文件，这样会导致磁盘不停的去读写



== php array 结构 ==

hashtable+映射表的方式

hash=>映射表=>bucket

映射表与bucket长度相同

hash冲突的情况：链地址法。next设置为相同hash的索引，然后在映射表里的值替换成当前元素在bucket中的位置。

== 处理负载，高并发？==

# HTML静态化
  效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的 网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。
# 图片服务器分离
  把图片单独存储，尽量减少图片等大流量的开销，可以放在一些相关的平台上，如七牛等
# 数据库集群和库表散列及缓存
  数据库的并发连接为100，一台数据库远远不够，可以从读写分离、主从复制，数据库集群方面来着手。另外尽量减少数据库的访问，可以使用缓存数据库如memcache、redis。
# 镜像：
  尽量减少下载，可以把不同的请求分发到多个镜像端。
# 负载均衡：
  Apache的最大并发连接为1500，只能增加服务器，可以从硬件上着手，如F5服务器。当然硬件的成本比较高，我们往往从软件方面着手。



== Laravel请求生命周期 ==

# index.php
# app.php 获取app实例
# http kernel 或者 console kernel
    # bootstrappers，执行请求之前运行的数组，配置错误处理、配置日志记录、检测应用程序环境 以及执行其他需要完成的任务
    # 中间件列表
    # handle处理请求，Request，返回Response

# 服务提供器，负责引导所有框架的各种组件