php面试相关

php

幂等设计的应用场景主要包括以下几个方面‌：

• 在线支付‌：在在线支付系统中，幂等设计可以避免用户多次点击支付按钮导致的重复扣款问题。当用户多次点击支付按钮时，系统能够识别重复请求并避免重复扣款，确保支付的幂等性‌
• ‌银行交易‌：在银行交易系统中，幂等设计可以确保同一笔交易不会因为网络重试等原因被执行多次。通过幂等设计，即使交易请求多次发送，系统也能保证交易只执行一次，避免资金重复扣除‌
• ‌票务系统‌：在线购票平台在用户购票时，通过幂等设计检查所选座位是否已被重复预订。这可以防止用户在重复提交购票请求时导致座位被重复预订的情况‌
• ‌通信服务‌：在短信或通话服务中，幂等设计可以确保相同内容的请求只被计费一次。通过检查是否已经为相同内容的请求计费，可以避免重复计费的情况‌
• ‌任务调度‌：在定时任务或批处理系统中，幂等设计可以确保任务不会因为重启或重试而重复执行相同的操作。这有助于维护系统的稳定性和一致性‌
• ‌用户注册‌：在用户注册过程中，幂等设计可以防止因重复提交表单而导致用户信息被创建多次。通过识别重复请求并避免重复处理，可以确保每个用户只被注册一次‌
• ‌消息中间件‌：在使用消息中间件时，幂等设计可以防止消息重复消费。当消息中间件出现错误未及时提交消费信息时，幂等设计可以确保相同消息只被消费一次‌
• ‌第三方平台接口‌：例如支付成功回调接口，由于异常可能导致多次异步回调。通过幂等设计，可以确保接口只被调用一次，避免重复处理‌

【分布式架构学习】初探幂等性

php7 和 php5 区别

1. 性能提升：php7 比 php5 性能提升了 2 倍；
2. php5 的许多致命错误，php7 改成抛出异常；
3. php7 比 php5 移除了一些老的不支持 SAPI；
4. php7 新增一些运算符；太空船运算 $a <=> $b; 相当于 ($a < $b) ? -1 : (($a > $b) ? 1 : 0); 空合并运算符：$d = $a ?? $b ?? $c ; // $d = 1, 空合并运算从左到右取第一个非 null 值
5. php7 新增增加了函数的返回类型申明；
6. php7 新增了参数类型申明；
7. php7 新增匿名类名；
8. 错误处理和 64 位支持；

为什么 php7 比 php5 性能提升了 2 倍呢？

1. 变量存储字节减少，减少内存占用，替身变量操作速度；
2. 改善数组结构，数组元素和 hash 映射表被分配在同一块内存里，降低内存占用，提升了 cpu 缓存命中率
3. 改进函数的调用机制，通过优化参数传递的环节，减少了一些指令，提高执行效率；

php-fpm模式下PHP请求的生命周期

在 PHP-FPM（FastCGI Process Manager）环境中，PHP 请求的生命周期涉及到多个组件和步骤。PHP-FPM 是一个用于运行 PHP 脚本的守护进程管理器，它通过 FastCGI 协议与 Web 服务器（如 Nginx 或 Apache）交互，以处理动态内容
下面是 PHP-FPM 下 PHP 请求的生命周期的详细步骤：

1. Web 服务器接收请求
   当用户通过浏览器访问一个 PHP 页面时，请求首先被 Web 服务器（如 Nginx 或 Apache）接收。
2. Web 服务器转发请求到 PHP-FPM
   Web 服务器配置为将 PHP 请求转发给 PHP-FPM。这通常是通过 FastCGI 协议实现的。
3. PHP-FPM 管理进程池
   PHP-FPM 管理着一个或多个进程池（pool），每个池包含多个子进程（worker processes）。这些子进程负责处理传入的请求。
4. 选择一个可用的子进程
   当一个请求到达时，PHP-FPM 会从相应的池中选择一个可用的子进程来处理这个请求。这通常是通过负载均衡机制完成的，例如，使用轮询、最少连接数等策略。
5. 子进程处理请求
   选中的子进程会：

• 解析请求：解析 HTTP 请求头部和体部。
• 初始化环境：设置必要的环境变量，如 $_SERVER 超全局变量。
• 执行 PHP 脚本：加载和执行 PHP 脚本，处理逻辑，生成响应。
• 生成响应：将处理结果转换成 HTTP 响应格式。

6. 将响应返回给 Web 服务器
   处理完请求后，子进程将生成的响应数据通过 FastCGI 协议发送回 Web 服务器。
7. Web 服务器发送响应给客户端
   Web 服务器接收到来自 PHP-FPM 的响应后，将其发送回客户端浏览器，用户就可以看到最终的页面内容了。
8. 子进程回收或继续等待新请求
   根据 PHP-FPM 的配置，子进程可能会被回收（如果达到最大请求数或空闲时间），或者继续等待新的请求。

优化和监控
为了提高性能和稳定性，可以配置和优化 PHP-FPM 的各种参数，如：

• pm：设置进程管理器类型（例如 static, dynamic, ondemand）。
• pm.max_children：设置最大子进程数。
• pm.start_servers, pm.min_spare_servers, pm.max_spare_servers：动态模式下控制进程数量。
• request_terminate_timeout：设置每个请求的最大执行时间。
• rlimit_files：设置每个子进程可以打开的最大文件数。

通过监控工具（如 New Relic, Prometheus 等）可以跟踪和优化 PHP-FPM 的性能和资源使用情况。
通过理解这些步骤和配置选项，你可以更好地管理和优化你的 PHP 应用在 PHP-FPM 环境下的表现。

解释OPCache如何优化PHP性能？

OPcache（PHP Opcode Cache）是一种开源的PHP缓存技术，旨在提高PHP应用的性能。它通过将编译后的PHP代码（opcode）缓存到共享内存中来减少PHP脚本的编译时间，从而提高执行速度。以下是OPcache如何优化PHP性能的一些关键方面

1. 减少编译时间
   每次PHP脚本被请求时，PHP解释器都会将源代码编译成机器可执行的opcode。这个过程称为“编译”。使用OPcache后，首次编译的结果可以被缓存，后续的请求可以直接从内存中读取已编译的opcode，而无需重新编译，从而显著减少处理时间。
2. 提升执行速度
   由于减少了编译步骤，PHP脚本的执行速度得到了提升。这对于那些需要频繁执行但又不需要频繁修改的脚本尤其重要，比如大多数的生产环境中的Web应用。
3. 减少内存使用
   虽然OPcache缓存了编译后的代码，但它也支持配置以限制每个脚本占用的内存量。这样可以避免单个脚本占用过多内存资源，从而在多脚本环境中保持更好的内存管理。
4. 配置优化
   OPcache提供了多种配置选项来优化性能：
   opcache.memory_consumption：设置OPcache共享内存的大小。
   opcache.interned_strings_buffer：设置用于存储字符串副本的内存量。
   opcache.max_accelerated_files：设置可以缓存的最大文件数。
   opcache.revalidate_freq：设置文件更新检查的频率，单位为秒。
   opcache.validate_timestamps：是否检查文件时间戳以确定是否需要重新编译。在生产环境中，通常设置为0以提高性能，但在开发环境中可能需要设置为1以便于调试。
   opcache.fast_shutdown：设置为1可以加快脚本结束时的清理过程。
5. 预热（Warming Up）
   在生产环境中，可以通过预热（warming up）机制预先加载常用的脚本到OPcache中。这可以通过编写脚本来循环请求这些页面或使用专门的工具如apc_compile_file()（在较新版本的PHP中已废弃，可以使用opcache_compile_file()）来实现。
6. 监控和日志记录
   OPcache还提供了状态信息，可以通过opcache.statistics启用统计信息收集，并通过opcache_get_status()函数获取详细的运行状态，如缓存命中率、缓存大小等，从而帮助开发者进行性能调优。

结论:

通过以上方式，OPcache能够有效提升PHP应用的性能和响应速度。合理配置OPcache参数并根据应用的具体需求进行优化，可以显著提高生产环境的稳定性和效率。

当代码更新后OPCache可能会导致什么问题？

1. ‌缓存不一致‌：当PHP代码更新后，如果OPCache的配置不当，可能会导致缓存的内容仍然是旧的代码，导致请求的内容仍然是更新前的旧内容。这通常是因为OPCache没有及时检测到代码的更新。例如，opcache.revalidate_freq设置为0会导致OPCache不会定期检查文件时间戳，从而可能导致缓存内容不更新‌1。

2. ‌配置不当‌：OPCache的配置不当也可能导致问题。例如，opcache.validate_timestamps设置为0会导致OPCache不会检查脚本的时间戳，从而无法检测到文件的更新。这需要在配置文件中正确设置这些参数，以确保OPCache能够及时检测到代码的更新‌1。

3. ‌性能问题‌：虽然OPCache可以提高PHP的执行效率，但在某些情况下可能会影响性能。例如，首次请求时由于需要编译和缓存脚本，性能提升可能不明显。此外，OPCache需要一定的内存来存储缓存的opcode，如果配置不当可能会导致内存使用过高，影响系统性能‌

如何安全的清理OPCache?

1. ‌修改php.ini配置文件‌：找到php.ini文件中的opcache.enable配置项，将其设置为0或者注释掉，然后重启服务器即可完全清理OPCache缓存‌12。
2. ‌使用opcache_reset()函数‌：在PHP脚本中调用opcache_reset()函数，这会清除所有缓存并重新编译所有脚本‌13。
3. ‌重启PHP-FPM进程或Web服务器‌：重启PHP-FPM进程或者Web服务器，这会强制刷新整个缓存‌3。
4. ‌修改配置项‌：在php.ini中设置opcache.validate_timestamps=0和opcache.revalidate_freq=0，然后重启服务器，这样可以确保OPCache不会缓存旧的代码文件‌45。

‌注意事项‌：

• 清理OPCache缓存可能会影响系统性能，建议选择合适的时间进行操作。
• 在开发环境中，可以将opcache.revalidate_freq设置为较小的值（如1秒），以便更快地更新缓存‌6。
• 在生产环境中，确保在维护窗口期间进行缓存清理操作，以减少对用户的影响‌2。

简述一下PHP的垃圾回收机制

php 中的变量存储在变量容器 zval 中，zval 中除了存储变量类型和值外，还有is_ref 和*refcount *字段。refcount 表示指向变量的元素个数，is_ref 表示变量是否有别名。
如果 refcount 为 0 时，就回收该变量容器。如果一个 zval 的 refcount 减 1 之后大于 0，它就会进入垃圾缓冲区。当缓冲区达到最大值后，回收算法会循环遍历 zval，判断其是否为垃圾，并进行释放处理

一致性哈希算法的用途主要包括以下几个方面‌：

‌分布式缓存‌：一致性哈希算法广泛应用于分布式缓存系统中，如Memcached和Redis。通过将数据映射到哈希环上，当增加或删除服务器时，能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系，从而保证系统的稳定性和高效性‌

‌负载均衡‌：在负载均衡场景中，一致性哈希算法可以帮助将请求均匀地分配到不同的服务器上。通过哈希环和虚拟节点的机制，可以有效解决服务器节点分布不均匀的问题，提高负载均衡的效率和准确性‌

‌数据库分片‌：一致性哈希算法也适用于数据库分片，如MySQL和MongoDB等。通过将数据映射到哈希环上，可以实现数据的均匀分布和高效管理，提高数据库的扩展性和可用性‌

‌一致性哈希算法的基本原理‌：

一致性哈希算法的核心思想是将数据映射到一个固定范围的哈希环上，服务器节点也映射到这个哈希环上。数据根据哈希值顺时针查找距离最近的服务器节点，从而完成数据的存储和访问。为了解决服务器节点分布不均匀的问题，一致性哈希引入了虚拟节点的概念，每个物理节点对应多个虚拟节点，数据映射到虚拟节点上，从而实现数据的均匀分布‌

‌与传统哈希算法的区别‌：

传统哈希算法在增加或删除节点时，会导致大量数据的重新映射，影响系统的稳定性和效率。而一致性哈希算法通过哈希环和虚拟节点的机制，能够在增加或删除节点时，尽可能小地改变已存在的映射关系，从而保证系统的稳定性和高效性‌

什么是 fastcgi?

1. FastCGI（Fast Common Gateway Interface）是一种协议，用于改善Web服务器和应用程序之间的通信效。它是CGI（Common Gateway Interface）的改进版本，旨在解决CGI在处理大量并发请求时存在的性能问.
2. FastCGI 进程管理器自身初始化，包括 master 和 worker 进程两部分，master 进程监听端口，接收来自 Web Server 请求，worker 进程一般具有多个，每个 worker 进程都有一个 cgi 进程解释器，用来执行 php 代码，等待来自 Web Server 的连接。
3. 当客户端请求到达 Web Server 时，FastCGI 进程管理器选择并连接到一个 CGI 解释器。Web Server 将 CGI 环境变量和标准输入发送到 FastCGI 子进程 php-cgi
4. FastCGI 子进程完成处理后将标准输出和错误信息从同一连接返回 Web Server。当 FastCGI 子进程关闭连接时，请求便告知处理完成。FastCGI 子进程接着等待并处理来自 FastCGI 继承管理器的下一个连接。

php-fpm

PHP-FPM 是多进程模式，master 进程管理 worker 进程，进程的数量，都可以通过 php-fpm.conf 做具体配置，而 PHP-FPM 的进程，亦可以分为动态模式及静态模式。

①：静态（static）：直接开启指定数量的 php-fpm 进程，不再增加或者减少；启动固定数量的进程，占用内存高。但在用户请求波动大的时候，对 Linux 操作系统进程的处理上耗费的系统资源低。
②：动态（dynamic）：开始的时候开启一定数量的 php-fpm 进程，当请求量变大的时候，动态的增加 php-fpm 进程数到上限，当空闲的时候自动释放空闲的进程数到一个下限。动态模式，会根据 max、min、idle children 配置，动态的调整进程数量。在用户请求较为波动，或者瞬间请求增高的时候，进行大量进程的创建、销毁等操作，而造成 Linux 负载波动升高，简单来说，请求量少，PHP-FPM 进程数少，请求量大，进程数多。优势就是，当请求量小的时候，进程数少，内存占用也小。

• pm.max_chidren：可以同时存活的子进程的最大数量 （一般 php-fpm 进程占用 20~30m 左右的内存就按 30m 算。如果单独跑 php-fpm，动态方式起始值可设置物理内存 Mem/30M，由于大家一般 Nginx、MySQL 都在一台机器上，于是预留一半给它们，即 php-fpm 进程数为 $Mem/2/30。）
• pm.start_servers：启动时创建的子进程数量，默认值为：min_spare_servers + (max_spare_servers - min_spare_servers) / 2
• pm.min_spare_servers：处于空闲状态 (等待处理) 的子进程的最小数量。如果空闲进程的数目小于这个数目，那么将会创建一些子进程。
• pm.max_spare_servers：处于空闲状态 (等待处理) 的子进程的最大数量。如果空闲进程的数目大于这个数目，那么一些子进程将被杀死。

③：按需模式（ondemand）：这种模式下，PHP-FPM 的 master 不会 fork 任何的子进程，纯粹就是按需启动子进程，这种模式很少使用，因为这种模式，基本上是无法适应有一定量级的线上业务的。由于 php-fpm 是短连接的，所以每次请求都会先建立连接，建立连接的过程必然会触发上图的执行步骤，所以，在大流量的系统上 master 进程会变得繁忙，占用系统 cpu 资源，不适合大流量环境的部署。这种模式，贴一个简单的网络上的图来说明：

• 内存比较少，并发量不是很大的应用，可以考虑采用 dynamic 的方式，这样可以控制 php-fpm 所消耗的总内存数。
• 在并发高或者流量波动大的情况下，使用 static 可以在高并发下获得比 dynamic 更快的响应速度。
• 可配置进程数量 = php-fpm 可配置内存 / （php-fpm 子进程的内存占用 * 1.2） 2. 最大处理请求数

php-fpm 如何优化

①：对于计算性能来说，使用 Zend OPcache 扩展，缓存字节码。
②：对于 IO 性能来说，使用文件 cache 或者 memcached 减轻对网络 Cache 的压力；使用 Yac 减轻对 Cache 层的压力；在同一次请求中；复用链接不要每次都用新的；合理设计日志组件类库，优化 Logger 减少对文件操作的次数来减少 IO 的压力。

关于设计一个合格的 Logger 组件，我们需要注意几个点：

①：每次请求，只做一次日志写操作，不要每次别人调用你的函数，你都去执行一次类似 file_put_contents 的操作。
②：兼容各种类似错误，换句话说，即使 PHP fatal error 了，你也得能把知名错误之前的日志记录下来。这个实现，可以借助 PHP 类的析构方法来做。也可以使用更好的 register_shutdown_function 来注册一个钩子，在 PHP 请求结束的时候，回调此钩子，完成做最后的日志操作。

3. 最长执行时间

最大执行时间在 php.ini 和 php-fpm.conf 里都可以配置，配置项分别为 max_execution_time 和 request_terminate_timeout

常见异常
502 Bad Gateway 在 php.ini 和 php-fpm.conf 中分别有这样两个配置项：max_execution_time 和 request_terminate_timeout。 这两项都是用来配置一个 PHP 脚本的最大执行时间的。当超过这个时间时，PHP-FPM 不只会终止脚本的执行，还会终止执行脚本的 Worker 进程。所以 Nginx 会发现与自己通信的连接断掉了，就会返回给客户端 502 错误。
504 错误 504 Gateway Time-out 由于程序执行时间过长导致响应超时，例如程序需要执行 90 秒，而 nginx 最大响应等待时间为 30 秒，这样就会出现超时。
PHP-FPM 设置的脚本最大执行时间已经够长了，但执行耗时 PHP 脚本时，发现 Nginx 报错从 502 变为 504 了。这是为什么呢？

因为我们修改的只是 PHP 的配置，Nginx 中也有关于与上游服务器通信超时时间的配置 factcgi_connect/read/send_timeout。

fastcgi_connect_timeout 
fastcgi连接超时时间，默认60秒
fastcgi_send_timeout 
nginx 进程向 fastcgi 进程发送请求过程的超时时间，默认值60秒
fastcgi_read_timeout 
fastcgi 进程向 nginx 进程发送输出过程的超时时间，默认值60秒

http 状态码有哪些？

1. 1XX：消息状态码。
2. 2XX：成功状态码。
3. 3XX：重定向状态码。
4. 4XX：客户端错误状态码。
5. 5XX：服务端错误状态码。

• 100：Continue 继续。客户端应继续其请求。
• 101：Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到 HTTP 的新版本协议。
• 200：OK 请求成功。一般用于 GET 与 POST 请求。
• 201：Created 已创建。成功请求并创建了新的资源。
• 202：Accepted 已接受。已经接受请求，但未处理完成。
• 203：Non-Authoritative Information 非授权信息。请求成功。但返回的 meta 信息不在原始的服务器，而是一个副本。
• 204：No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档。
• 205：Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域。
• 206：Partial Content 部分内容。服务器成功处理了部分 GET 请求。
• 300：Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择。
• 301：Moved Permanently 永久移动。请求的资源已被永久的移动到新 URI，返回信息会包括新的 URI，浏览器会自动定向到新 URI。今后任何新的请求都应使用新的 URI 代替。
• 302：Found 临时移动，与 301 类似。但资源只是临时被移动。客户端应继续使用原有 URI。
• 303：See Other 查看其它地址。与 301 类似。使用 GET 和 POST 请求查看。
• 304：Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。
• 305：Use Proxy 使用代理。所请求的资源必须通过代理访问。
• 306：Unused 已经被废弃的 HTTP 状态码。
• 307：Temporary Redirect 临时重定向。与 302 类似。使用 GET 请求重定向
• 400：Bad Request 客户端请求的语法错误，服务器无法理解。
• 401：Unauthorized 请求要求用户的身份认证。
• 402：Payment Required 保留，将来使用。
• 403：Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求。
• 404：Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置” 您所请求的资源无法找到” 的个性页面。
• 405：Method Not Allowed 客户端请求中的方法被禁止。
• 406：Not Acceptable 服务器无法根据客户端请求的内容特性完成请求。
• 407：Proxy Authentication Required 请求要求代理的身份认证，与 401 类似，但请求者应当使用代理进行授权。
• 408：Request Time-out 服务器等待客户端发送的请求时间过长，超时。
• 409：Conflict 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突。
• 410：Gone 客户端请求的资源已经不存在。410 不同于 404，如果资源以前有现在被永久删除了可使用 410 代码，网站设计人员可通过 301 代码指定资源的新位置。
• 411：Length Required 服务器无法处理客户端发送的不带 Content-Length 的请求信息。
• 412：Precondition Failed 客户端请求信息的先决条件错误。
• 413：Request Entity Too Large 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个 Retry-After 的响应信息。
• 414：Request-URI Too Large 请求的 URI 过长（URI 通常为网址），服务器无法处理。
• 415：Unsupported Media Type 服务器无法处理请求附带的媒体格式。
• 416：Requested range not satisfiable 客户端请求的范围无效。
• 417：Expectation Failed 服务器无法满足 Expect 的请求头信息。
• 500：Internal Server Error 服务器内部错误，无法完成请求。
• 501：Not Implemented 服务器不支持请求的功能，无法完成请求。
• 502：Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应。
• 503：Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的 Retry-After 头信息中。
• 504：Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求。
• 505：HTTP Version not supported 服务器不支持请求的 HTTP 协议的版本，无法完成处理。

Tcp 为什么 3 次握手

• 三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

1. 第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
2. 第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
3. 第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

• TCP 的
• 优点：可靠，稳定 TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。
• 缺点： 慢，效率低，占用系统资源高，易被攻击 TCP 在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的 CPU、内存等硬件资源。 而且，因为 TCP 有确认机制、三次握手机制，这些也导致 TCP 容易被人利用，实现 DOS、DDOS、CC 等攻击。

为什么要四次挥手

TCP 是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。

举个例子：A 和 B 打电话，通话即将结束后。

1. 第一次挥手 ：A 说 “我没啥要说的了”
2. 第二次挥手 ：B 回答 “我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
3. 第三次挥手 ：于是 B 可能又巴拉巴拉说了一通，最后 B 说 “我说完了”
4. 第四次挥手 ：A 回答 “知道了”，这样通话才算结束。

常用的网络攻击手段有哪些？

1.什么是 SQL 注入攻击？如何防止 SQL 注入攻击？

SQL 注入攻击是指攻击者通过向 Web 应用程序的输入框中插入恶意 SQL 语句来执行未经授权的操作。防止 SQL 注入攻击的方法包括使用参数化查询和输入验证，以及避免使用动态 SQL 语句。

2.什么是跨站点脚本攻击（XSS）？如何防止 XSS 攻击？

跨站点脚本攻击是指攻击者通过向 Web 应用程序的输入框中插入恶意脚本来窃取用户数据或执行未经授权的操作。防止 XSS 攻击的方法包括对输入数据进行验证和转义、使用内容安全策略（CSP）以及限制 Cookie 的范围。

3.什么是跨站请求伪造（CSRF）攻击？如何防止 CSRF 攻击？

跨站请求伪造攻击是指攻击者利用用户已经通过身份验证的会话执行未经授权的操作。防止 CSRF 攻击的方法包括使用同步令牌和使用双重身份验证。

HTTP 和 HTTPS 有什么区别？

• 端口号：HTTP 默认是 80，HTTPS 默认是 443。
• URL 前缀：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。
• 安全性和资源消耗 ：HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。
• SEO（搜索引擎优化）：搜索引擎通常会更青睐使用 HTTPS 协议的网站，因为 HTTPS 能够提供更高的安全性和用户隐私保护。使用 HTTPS 协议的网站在搜索结果中可能会被优先显示，从而对 SEO 产生影响。

网络

• TCP（Transmission Control Protocol，传输控制协议 ）：提供 面向连接 的，可靠 的数据传输服务。
• UDP（User Datagram Protocol，用户数据协议）：提供 无连接 的，尽最大努力 的数据传输服务（不保证数据传输的可靠性），简单高效。
• HTTP（Hypertext Transfer Protocol，超文本传输协议）：基于 TCP 协议，是一种用于传输超文本和多媒体内容的协议，主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的。
• DNS（Domain Name System，域名管理系统）: 基于 UDP 协议，用于解决域名和 IP 地址的映射问题。

缓存

1. 缓存击穿 是指热点 key 在某个时间点过期的时候，而恰好在这个时间点对这个 Key 有大量的并发请求过来，从而大量的请求打到 db。

   解决方案：

• 若缓存的数据是基本不会发⽣更新的，则可尝试将该热点数据设置为永不过期。
• 使用互斥锁

2. 缓存雪崩是指在某一时间段，缓存集中失效，导致大量请求直接走数据库，有可能对数据库造成巨大压力，甚至使其宕机，从而使整个服务瘫痪。

   解决方案：

• 使用互斥锁
• 缓存的失效时间再加上一个随机值
• Redis cluster，避免全盘崩溃

3. 缓存穿透 主要指查询的数据在缓存和数据库中都不存在的情况。在这种情况下，客户端仍然会不断地发起请求，导致每次请求都会压向数据库

   解决方案：

• 将此 key 对应的 value 设置为一个默认的值，比如设置为空 (NULL)，并设置一个缓存的失效时间
• 布隆过滤器
• 使用互斥锁

Redis Cluster

1. ⾃动将数据进⾏分⽚，每个 master 上放⼀部分数据
2. 提供内置的⾼可⽤⽀持，部分 master 不可⽤时，还是可以继续⼯作的

分布式寻址算法、hash 算法（⼤量缓存重建）、⼀致性 hash 算法（⾃动缓存迁移）+ 虚拟节点（⾃动负载均衡）、Redis cluster 的 hash slot 算法、Redis cluster 的⾼可⽤与主备切换原理，Redis cluster 的⾼可⽤的原理，⼏乎跟哨兵是类似的

从节点选举

每个从节点，都根据⾃⼰对 master 复制数据的 offset，来设置⼀个选举时间，offset 越⼤（复制数据越多）的从节点，选举时间越靠前，优先进⾏选举。所有的 master node 开始 slave 选举投票，给要进⾏选举的 slave 进⾏投票，如果⼤部分 master node （N/2 + 1） 都投票给了某个从节点，那么选举通过，那个从节点可以切换成 master。从节点执⾏主备切换，从节点切换为主节点

秒杀系统设计

秒杀系统设计

• 业务特点：
  1、瞬时并发量大，秒杀时会有大量用户在同一时间进行抢购，瞬时并发访问量突增几倍、甚至几十倍以上
  2、库存量少，一般秒杀活动商品量很少，这就导致了只有极少量用户能成功购买到。
  3、业务和流程较为简单，一般都是下订单、扣库存、支付订单。
• 技术难点：
  1、若秒杀活动若与其他营销活动同时进行，可能会对其他活动造成冲击，极端情况下可能导致整个服务宕机。
  2、页面流量突增，秒杀活动用户访问量会突增。需确保访问量的突增不会对服务器、数据库、Redis 等造成过大的压力。
  3、秒杀活动库存量小，瞬时下单量大，易造成超卖现象
• 架构设计思想
  1、限流：由于库存量很少，对应的只有少部分用户才能秒杀成功。所以要限制大部分用户流量，只准少量用户流量进入后端服务器。
  2、削峰：秒杀开始瞬间，大量用户进来会有一个瞬间流量峰值。把瞬间峰值变得更平缓是设计好秒杀系统关键因素。一般的采用缓存和 MQ 实现流量的削峰填谷。
  3、异步：秒杀可以当做高并发系统处理。即可以从业务上考虑，将同步的业务，设计成异步处理的任务。
  4、缓存：秒杀瓶颈主要体现在下单、扣库存的数据操作中。关系型数据库写入和读取效率较低。若将部分操作放到缓存中能极大提高并发效率 (如使用 Redis 操作库存)
• 客户端优化
  1、秒杀页面：
  如果秒杀页面的资源，如：CSS、JS、图片、商品详情等都经后端，服务肯定承受不住。如果将这个页面进行静态化，秒杀时肯定能起到压力分散的作用。
  2、防止提前下单：
  使用 JS 控制提交订单按钮，如果秒杀时间，就不能点击该按钮。
• 服务端优化
  1、对查询秒杀商品进行优化
  将首次查询到的商品信息进行数据放入缓存，后面再访问时直接返回缓存的信息。
  2、对库存的优化
  在设置秒杀活动时就将商品库存放于 Redis 中，在下单扣库存时，直接对 Redis 进行操作。
  3、后端流量控制优化（参加用户量过大时）
  使用消息队列、异步处理等方式解决。即超过系统水位线的请求直接拒绝掉。

核心思想：
1、层层过滤，逐渐递减瞬时访问，降低下游的压力，减少最终对数据库的冲击
2、充分利用缓存与消息队列，提高请求处理速度以及削峰填谷的作用

本作品采用《CC 协议》，转载必须注明作者和本文链接