问题汇总

一、TCP的粘包和拆包问题？

TCP在发送和接受数据的时候，有一个滑动窗口来控制接受数据的大小，这个滑动窗口你就可以理解为一个缓冲区的大小。缓冲区满了就会把数据发送，数据包的大小是不固定的，有时候比缓冲区大有时候小。

如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题；

如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包，也就是将一个大的包拆分为多个小包进行发送。

TCP会发生粘包问题：TCP 是面向连接的传输协议，TCP 传输的数据是以流的形式，而流数据是没有明确的开始结尾边界，所以 TCP 也没办法判断哪一段流属于一个消息；TCP协议是流式协议；流式协议是协议的内容是像流水一样的字节流，内容与内容之间没有明确的分界标志，需要认为手动地去给这些协议划分边界。
粘包时：发送方每次写入数据 < 接收方套接字(Socket)缓冲区大小。
拆包时：发送方每次写入数据 > 接收方套接字(Socket)缓冲区大小。

UDP不会发生粘包问题：UDP具有保护消息边界,在每个UDP包中就有了消息头(UDP长度、源端口、目的端口、校验和)。

粘包拆包问题在数据链路层、网络层以及传输层都有可能发生。日常的网络应用开发大都在传输层进行，由于UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中。

对于粘包和拆包问题，常见的解决方案有四种：

  1. 客户端在发送数据包的时候，每个包都固定长度，比如1024个字节大小，如果客户端发送的数据长度不足1024个字节，则通过补充空格的方式补全到指定长度；
  2. 客户端在每个包的末尾使用固定的分隔符，例如\r\n，如果一个包被拆分了，则等待下一个包发送过来之后找到其中的\r\n，然后对其拆分后的头部部分与前一个包的剩余部分进行合并，这样就得到了一个完整的包；
  3. 将消息分为头部和消息体，在头部中保存有当前整个消息的长度，只有在读取到足够长度的消息之后才算是读到了一个完整的消息；
  4. 通过自定义协议进行粘包和拆包的处理。

HTTP如何解决粘包问题的？

http请求报文格式
1）请求行：以\r\n结束；
2）请求头：以\r\n结束；
3）\r\n；
3）数据；

http响应报文格式
1）响应行：以\r\n结束；
2）响应头：以\r\n结束；
3）\r\n；
4）数据；

读取请求行/请求头、响应行/响应头

  • 遇到第一个\r\n表示读取请求行或响应行结束；
  • 遇到\r\n\r\n表示读取请求头或响应头结束；


读取body数据

  • HTTP协议通常使用Content-Length来标识body的长度。在服务器端，需要先申请对应长度的buffer，然后再赋值。
  • 如果需要一边生产数据一边发送数据，就需要使用"Transfer-Encoding: chunked" 来代替Content-Length，也就是对数据进行分块传输。

Content-Length 描述

http server接收数据时，发现header中有Content-Length属性，则读取Content-Length的值，确定需要读取body的长度。
http server发送数据时，根据需要发送byte的长度，在header中增加Content-Length项，其中value为byte的长度，然后将byte数据当做body发送到客户端。

chunked描述
http server接收数据时，发现header中有Transfer-Encoding: chunked，则会按照chunked协议分批读取数据。
http server发送数据时，如果需要分批发送到客户端，则需要在header中加上Transfer-Encoding:chunked，然后按照chunked协议分批发送数据。

  1. 主要包含三部分: chunk，last-chunk和trailer。如果分多次发送，则chunk有多份。
  2. chunk主要包含大小和数据，大小表示这个这个chunk包的大小，使用16进制标示。其中chunk之间的分隔符为CRLF。
  3. 通过last-chunk来标识chunk发送完成。一般读取到last-chunk(内容为0)的时候，代表chunk发送完成。
  4. trailer表示增加header等额外信息，一般情况下header是空。通过CRLF来标识整个chunked数据发送完成。
  • 优点
  1. 假如body的长度是10K，对于Content-Length则需要申请10K连续的buffer，而对于Transfer-Encoding:chunked可以申请1k的空间，然后循环使用10次。节省了内存空间的开销。
  2. 如果内容的长度不可知，则可使用chunked方式能有效的解决Content-Length的问题
  3. http服务器压缩可以采用分块压缩，而不是整个块压缩。分块压缩可以一边进行压缩，一般发送数据，来加快数据的传输时间。
  • 缺点
  1. chunked协议解析比较复杂。
  2. 在http转发的场景下(比如nginx)难以处理，比如如何对分块数据进行转发。

二、HTTP和HTTPS的区别

  1. URL不同；
  2. 默认端口不同，HTTP 是80，HTTPS 是443；
  3. HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+TLS+HTTP） 数据传输过程是加密的，安全性较好；
  4. 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用；
  5. HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上TLS握手需要的 9 个包，所以一共是 12 个包；
  6. HTTPS 其实是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比 HTTP 要更耗费服务器资源。

SSL/TLS 协议基本流程：

  • 客户端向服务器索要并验证服务器的公钥。
  • 双方协商生产「会话秘钥」。
  • 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。

TLS 的握手阶段涉及四次通信，使用不同的密钥交换算法，TLS 握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA 算法 (opens new window)和ECDHE 算法 (opens new window)。

SSL/TLS协议通过3点解决HTTP 原有的3大风险：

  1. 加密传播，防窃听
  2. 校验机制，防篡改
  3. CA证书，解决冒充风险

三、TCP如何去抓包

tcpdump 和 Wireshark 就是最常用的网络抓包和分析工具，更是分析网络性能必不可少的利器。

  • tcpdump 仅支持命令行格式使用，常用在 Linux 服务器中抓取和分析网络包。
  • Wireshark 除了可以抓包外，还提供了可视化分析网络包的图形页面。

四、MySQL中主从架构如何保证数据一致性

在写redo log 和 binlog 这两份日志的时候，如果出现半成功的状态，就会造成主从环境的数据不一致性。这是因为 redo log 影响主库的数据，binlog 影响从库的数据，所以 redo log 和 binlog 必须保持一致才能保证主从数据一致。

  1. 在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。
  2. 在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread，其中 io_thread 负责与主库的 dump_thread 建立连接。
  3. 主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B。
  4. 备库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。
  5. sql_thread 读取中转日志，解析出日志里的命令，并执行。

从图中可看出，事务的提交过程有两个阶段，就是将 redo log 的写入拆成了两个步骤：prepare 和 commit，中间再穿插写入binlog，具体如下：

prepare 阶段：将 XID（内部 XA 事务的 ID） 写入到 redo log，同时将 redo log 对应的事务状态设置为 prepare，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；

commit 阶段：把 XID 写入到 binlog，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事务接口，将 redo log 状态设置为 commit，此时该状态并不需要持久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事务已经执行成功；

两阶段提交是以 binlog 写成功为事务提交成功的标识，因为 binlog 写成功了，就意味着能在 binlog 中查找到与 redo log 相同的 XID。

XID 是 binlog 与 redo log 共同的数据字段，崩溃恢复的时候，会按顺序扫描 redo log

  • 如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
  • 如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。

在我们真实的开发场景中，往往主库不会一直是主库，从库不会一直是从库。为了保证安全性，往往是这样设计的。

这样的就会出现另一个问题。业务逻辑在节点 A 上更新了一条语句，然后再把生成的 binlog 发给节点 B，节点 B 执行完这条更新语句后也会生成 binlog。（建议把参数 log_slave_updates 设置为 on，表示备库执行 relay log 后生成 binlog）。

那么，如果节点 A 同时是节点 B 的备库，相当于又把节点 B 新生成的 binlog 拿过来执行了一次，然后节点 A 和 B 间，会不断地循环执行这个更新语句，也就是循环复制了。这个要怎么解决呢？

解决方案：

  1. 规定两个库的 server id 必须不同，如果相同，则它们之间不能设定为主备关系；
  2. 一个备库接到 binlog 并在重放的过程中，生成与原 binlog 的 server id 相同的新的 binlog；
  3. 每个库在收到从自己的主库发过来的日志后，先判断 server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃这个日志。

按照这个逻辑，如果设置了双 M 结构，日志的执行流就会变成这样：

  1. 从节点 A 更新的事务，binlog 里面记的都是 A 的 server id；
  2. 传到节点 B 执行一次以后，节点 B 生成的 binlog 的 server id 也是 A 的 server id；
  3. 再传回给节点 A，A 判断到这个 server id 与自己的相同，就不会再处理这个日志。

所以，死循环在这里就断掉了。

防止主从数据的丢失

在MySQL中，一次事务提交后，需要写undo、写redo、写binlog，写数据文件等等。在这个过程中，可能在某个步骤发生crash，就有可能导致主从数据的不一致。为了避免这种情况，我们需要调整主从上面相关选项配置，确保即便发生crash了，也不能发生主从复制的数据丢失。

  • 在master上修改配置

上述两个选项的作用是：保证每次事务提交后，都能实时刷新到磁盘中，尤其是确保每次事务对应的binlog都能及时刷新到磁盘中，只要有了binlog，InnoDB就有办法做数据恢复，不至于导致主从复制的数据丢失。

  • 在slave上修改配置

上述前两个选项的作用是：确保在slave上和复制相关的数据表也采用InnoDB引擎，受到InnoDB事务安全的保护，而后一个选项的作用是开启relay log自动修复机制，发生crash时，会自动判断哪些relay log需要重新从master上抓取回来再次应用，以此避免部分数据丢失的可能性。

五、算法题

给定一个数组，同时多次给定不同的区间下标i和j（下标从0开始），快速求这些区间和。

解决思路：要快速求多个区间的和，可以使用前缀和（Prefix Sum）的方法。前缀和是指从数组的第一个元素开始，依次累加到当前位置的元素之和。通过计算出数组的前缀和，可以在O(1)的时间内求出任意区间的和，而不需要每次都重新计算。

#include <iostream>
#include <vector>using namespace std;vector<int> prefix_sum(const vector<int>& arr) {int n = arr.size();vector<int> prefix(n + 1, 0);// 计算前缀和for (int i = 1; i <= n; i++) {prefix[i] = prefix[i - 1] + arr[i - 1];}return prefix;
}int interval_sum(const vector<int>& prefix, int i, int j) {// 区间和等于前缀和j处的值减去前缀和i处的值return prefix[j + 1] - prefix[i];
}int main() {// 示例数组vector<int> arr = {1, 2, 3, 4, 5};// 计算前缀和vector<int> prefix = prefix_sum(arr);// 获取区间和int i = 1;int j = 3;cout << "区间[" << i << ", " << j << "]的和为: " << interval_sum(prefix, i, j) << endl;return 0;
}

六、如何解决MySQL深分页问题

日常做分页需求时，一般会用limit实现，但是当偏移量特别大的时候，查询效率就变得低下。

CREATE TABLE account (id int(11) NOT NULL AUTO_INCREMENT COMMENT '主键Id',name varchar(255) DEFAULT NULL COMMENT '账户名',balance int(11) DEFAULT NULL COMMENT '余额',create_time datetime NOT NULL COMMENT '创建时间',update_time datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',PRIMARY KEY (id),KEY idx_name (name),KEY idx_update_time (update_time) //索引
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT='账户表';

假设深分页的执行SQL如下：

select id,name,balance from account where update_time> '2020-09-19' limit 100000,10;

执行完需要0.742秒，深分页为什么会变慢呢？如果换成 limit 0,10，只需要0.006秒哦

先来看下这个SQL的执行流程：

  1. 通过普通二级索引树idx_update_time，过滤update_time条件，找到满足条件的记录ID。
  2. 通过ID，回到主键索引树，找到满足记录的行，然后取出展示的列（回表）
  3. 扫描满足条件的100010行，然后扔掉前100000行，返回后10条。

SQL变慢原因有两个：

  1. limit语句会先扫描offset+n行，然后再丢弃掉前offset行，返回后n行数据。也就是说limit 100000,10，就会扫描100010行，而limit 0,10，只扫描10行。
  2. limit 100000,10 扫描更多的行数，也意味着回表更多的次数。

通过子查询优化

因为以上的SQL，回表了100010次，实际上，我们只需要10条数据，也就是我们只需要10次回表其实就够了。因此，我们可以通过减少回表次数来优化。

回顾B+ 树结构

那么，如何减少回表次数呢？我们先来复习下B+树索引结构哈~

InnoDB中，索引分主键索引（聚簇索引）和二级索引

  • 主键索引，叶子节点存放的是整行数据
  • 二级索引，叶子节点存放的是主键的值

把条件转移到主键索引树

如果我们把查询条件，转移回到主键索引树，那就可以减少回表次数啦。转移到主键索引树查询的话，查询条件得改为主键id了，之前SQL的update_time这些条件咋办呢？抽到子查询那里嘛~

子查询那里怎么抽的呢？因为二级索引叶子节点是有主键ID的，所以我们直接根据update_time来查主键ID即可，同时我们把 limit 100000的条件，也转移到子查询，完整SQL如下：

select id,name,balance FROM account where id >= (select a.id from account a where a.update_time >= '2020-09-19' limit 100000, 1) LIMIT 10;

由执行计划得知，子查询 table a查询是用到了idx_update_time索引。首先在索引上拿到了聚集索引的主键ID,省去了回表操作，然后第二查询直接根据第一个查询的 ID往后再去查10个就可以了。

INNER JOIN(内连接) 延迟关联

延迟关联的优化思路，跟子查询的优化思路其实是一样的：都是把条件转移到主键索引树，然后减少回表。不同点是，延迟关联使用了inner join代替子查询。

优化后的SQL如下：

SELECT  acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.update_time >= '2020-09-19' ORDER BY a.update_time LIMIT 100000, 10) AS  acct2 on acct1.id= acct2.id;

查询思路就是，先通过idx_update_time二级索引树查询到满足条件的主键ID，再与原表通过主键ID内连接，这样后面直接走了主键索引了，同时也减少了回表。

标签记录法

limit 深分页问题的本质原因就是：偏移量（offset）越大，mysql就会扫描越多的行，然后再抛弃掉，这样就导致查询性能的下降。

其实我们可以采用标签记录法，就是标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描。就好像看书一样，上次看到哪里了，你就折叠一下或者夹个书签，下次来看的时候，直接就翻到啦。

假设上一次记录到100000，则SQL可以修改为：

select  id,name,balance FROM account where id > 100000 order by id limit 10;

这样的话，后面无论翻多少页，性能都会不错的，因为命中了id主键索引。但是这种方式有局限性：需要一种连续自增的字段（一般是 order by 主键，使其具有顺序）。

使用between...and...

很多时候，可以将limit查询转换为已知位置的查询，这样MySQL通过范围扫描between...and，就能获得到对应的结果。

如果知道边界值为100000，100010后，就可以这样优化：

select  id,name,balance FROM account where id between 100000 and 100010 order by id;

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/616279.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

蓝桥杯简单STL

蓝桥杯简单STL

目录 vector vector定义 vector访问 常用函数 size() ​编辑 push_back(num) pop_back() clear 迭代器&#xff08;iterator) 迭代器定义 遍历数组示例 insert(it, element) erase(it) 标准模板库--STL&#xff0c;它包含了多种预定义的容器、算法和迭代器&…
阅读更多...
【深度学习实战（3）】打印自己模型的推理帧率

【深度学习实战（3）】打印自己模型的推理帧率

一、FPS(每秒传输帧数-Frames Per Second) FPS就是目标网络每秒可以处理&#xff08;检测&#xff09;多少帧(多少张图片),FPS简单来理解就是图像的刷新频率&#xff0c;也就是每秒多少帧,假设目标检测网络处理1帧要0.02s&#xff0c;此时FPS就是1/0.0250 其中Processing tim…
阅读更多...
Unity之C#面试题（二）

Unity之C#面试题（二）

内容将会持续更新&#xff0c;有错误的地方欢迎指正&#xff0c;谢谢! Unity之C#面试题&#xff08;二&#xff09; TechX 坚持将创新的科技带给世界&#xff01; 拥有更好的学习体验 —— 不断努力&#xff0c;不断进步&#xff0c;不断探索 TechX —— 心探索、心进取&a…
阅读更多...
5分钟手把手教你 Guitar Pro v8.1.1 Build 17 中文完整激活版(附教程) 64位

5分钟手把手教你 Guitar Pro v8.1.1 Build 17 中文完整激活版(附教程) 64位

吉他爱好者必备神器&#xff1a;Guitar Pro v8.1.1 Build 17深度解析 随着数字音乐制作和学习的日益普及&#xff0c;越来越多的吉他爱好者开始寻找能够帮助他们提升技能、创作音乐的专业工具。在众多吉他制作软件中&#xff0c;Guitar Pro因其强大的功能和易用的界面备受推崇…
阅读更多...
电子章是怎么盖上去的?

电子章是怎么盖上去的?

电子章是怎么盖上去的呢&#xff0c;本文介绍利e-章宝(易友EU3000智能盖章软件)盖电子骑缝章的方法。如下&#xff1a; 1.在软件中导入待批量盖章的PDF文件 如下图&#xff0c;在“待盖章PDF文件”区域&#xff0c;点“添加”&#xff0c;导入待盖章PDF文件。 如上图&#xf…
阅读更多...
Postman接口测试 - 全局变量/接口关联/加密/解密

Postman接口测试 - 全局变量/接口关联/加密/解密

&#x1f345; 视频学习&#xff1a;文末有免费的配套视频可观看 &#x1f345; 点击文末小卡片&#xff0c;免费获取软件测试全套资料&#xff0c;资料在手&#xff0c;涨薪更快 全局变量和环境变量 全局变量&#xff1a;在postman全局生效的变量&#xff0c;全局唯一 环境变…
阅读更多...
腾讯云服务器搭建网站教程，新手跟着流程一步步操作

腾讯云服务器搭建网站教程，新手跟着流程一步步操作

使用腾讯云服务器搭建网站全流程&#xff0c;包括轻量应用服务器和云服务器CVM建站教程&#xff0c;轻量可以使用应用镜像一键建站&#xff0c;云服务器CVM可以通过安装宝塔面板的方式来搭建网站&#xff0c;腾讯云服务器网txyfwq.com整理使用腾讯云服务器建站教程&#xff0c;…
阅读更多...
mybatis 枚举值，映射为枚举类型，使用typehandle

mybatis 枚举值，映射为枚举类型，使用typehandle

要在存储到 MySQL 时使用枚举的代码值，然后在读取时将其转换为枚举对象，你可以使用 MyBatis 的类型处理器（TypeHandler）来实现这一点。在你的情况下，你已经有了一个 PersonIdTypeHandler 类，这是一个类型处理器，用于处理 PersonIdType 枚举类型。 确保 PersonIdTypeHan…
阅读更多...
基于Springboot+Vue的Java项目-在线视频教育平台系统(附演示视频+源码+LW)

基于Springboot+Vue的Java项目-在线视频教育平台系统(附演示视频+源码+LW)

大家好&#xff01;我是程序员一帆&#xff0c;感谢您阅读本文&#xff0c;欢迎一键三连哦。 &#x1f49e;当前专栏&#xff1a;Java毕业设计 精彩专栏推荐&#x1f447;&#x1f3fb;&#x1f447;&#x1f3fb;&#x1f447;&#x1f3fb; &#x1f380; Python毕业设计 &am…
阅读更多...
TiDB存储引擎TiKV揭秘

TiDB存储引擎TiKV揭秘

目录 一、TiKV 介绍 二、RocksDB 三、TiKV 与 RocksDB 架构 3.1 用户数据保存 3.2 TiKV 中 Region 一、TiKV 介绍 TiKV 是一个分布式事务型的键值数据库&#xff0c;提供了满足 ACID 约束的分布式事务接口&#xff0c;并且通过 Raft 协议保证了多副本数据一致性以及高可用。…
阅读更多...
量子信息产业生态研究（一）：关于《量子技术公司营销指南（2023）》的讨论

量子信息产业生态研究（一）：关于《量子技术公司营销指南（2023）》的讨论

写在前面。量子行业媒体量子内参&#xff08;Quantum Insider&#xff09;编制的《量子技术公司营销指南》是一本实用的英文手册&#xff0c;它旨在帮助量子科技公司建立有效的营销策略&#xff0c;同时了解如何将自己定位成各自的行业专家。本文对这篇指南的主要内容进行了翻译…
阅读更多...
两步解决 Flutter Your project requires a newer version of the Kotlin Gradle plugin

两步解决 Flutter Your project requires a newer version of the Kotlin Gradle plugin

在开发Flutter项目的时候，遇到这个问题Flutter Your project requires a newer version of the Kotlin Gradle plugin 解决方案分两步： 1、在android/build.gradle里配置最新版本的kotlin 根据提示的kotlin官方网站搜到了Kotlin的最新版本是1.9.23,如下图所示： 同时在Ko…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023