“常见问题”的版本间的差异

来自YS的笔记
跳到导航 跳到搜索
(Yaosong移动页面面试常见问题
(没有差异)

2019年9月2日 (一) 17:59的版本

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请求不会保留在浏览器历史记录中
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对比

  • 丰富的数据类型
  • 支持数据持久化

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会不停的写一些临时文件,这样会导致磁盘不停的去读写