获得徽章 0
#每天一个知识点#
数据库隔离级别：
- 读未提交（read uncommitted），指一个事务还没提交时，它做的变更就能被其他事务看到；
- 读提交（read committed），指一个事务提交之后，它做的变更才能被其他事务看到；
- 可重复读（repeatable read），指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，MySQL InnoDB 引擎的默认隔离级别；
- 串行化（serializable）；会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行；
读提交以上，可解决脏读问题
可重复读以上，可解决不可重复读问题
串行化才能完全解决幻读现象，但是可重复读已经能很大程度避免幻读
可重复读的幻读现象出现在A先快照读，B提交，A再当前读，就会前后读取结果不一样，应当先当前读，让其加上记录锁和间隙锁，禁止插入，就能避免幻读。
数据库隔离级别：
- 读未提交（read uncommitted），指一个事务还没提交时，它做的变更就能被其他事务看到；
- 读提交（read committed），指一个事务提交之后，它做的变更才能被其他事务看到；
- 可重复读（repeatable read），指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，MySQL InnoDB 引擎的默认隔离级别；
- 串行化（serializable）；会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行；
读提交以上，可解决脏读问题
可重复读以上，可解决不可重复读问题
串行化才能完全解决幻读现象，但是可重复读已经能很大程度避免幻读
可重复读的幻读现象出现在A先快照读，B提交，A再当前读，就会前后读取结果不一样，应当先当前读，让其加上记录锁和间隙锁，禁止插入，就能避免幻读。
展开
评论
点赞
#每天一个知识点#
"RESTful"是一种设计和构建网络应用程序的软件架构风格。它是“Representational State Transfer（表征状态转移）”的简称。RESTful API（也称为REST API）是一种遵循REST原则的应用程序编程接口。
RESTful API基于以下几个关键原则：
资源（Resources）：在RESTful设计中，所有的数据都被视为资源。每个资源都有一个唯一的标识符（通常是URL），可以使用HTTP方法（如GET、POST、PUT、DELETE）对其进行操作。
状态转移（State Transfer）：客户端可以通过向服务器发送HTTP请求来执行某些操作，这些操作将导致资源的状态发生转移。常见的操作包括获取资源、创建资源、更新资源和删除资源。
表征（Representation）：资源可以具有不同的表征形式，如JSON、XML、HTML等。客户端可以根据需要选择合适的表征形式来进行交互。
通过遵循RESTful原则，API在设计和使用上更加简洁、可读性更强，易于扩展和维护。RESTful API通常使用HTTP协议作为通信协议，并以JSON格式或XML格式传输数据。
例如，如果要获取某个用户的信息，可以使用GET方法发送HTTP请求到对应的URL（如/api/users/1），服务器将返回表示该用户信息的JSON或XML数据。
总而言之，RESTful风格的API是一种采用URL和HTTP方法来操作资源的软件架构，它提供了一种规范化的方式来设计和访问网络应用程序的接口。
"RESTful"是一种设计和构建网络应用程序的软件架构风格。它是“Representational State Transfer（表征状态转移）”的简称。RESTful API（也称为REST API）是一种遵循REST原则的应用程序编程接口。
RESTful API基于以下几个关键原则：
资源（Resources）：在RESTful设计中，所有的数据都被视为资源。每个资源都有一个唯一的标识符（通常是URL），可以使用HTTP方法（如GET、POST、PUT、DELETE）对其进行操作。
状态转移（State Transfer）：客户端可以通过向服务器发送HTTP请求来执行某些操作，这些操作将导致资源的状态发生转移。常见的操作包括获取资源、创建资源、更新资源和删除资源。
表征（Representation）：资源可以具有不同的表征形式，如JSON、XML、HTML等。客户端可以根据需要选择合适的表征形式来进行交互。
通过遵循RESTful原则，API在设计和使用上更加简洁、可读性更强，易于扩展和维护。RESTful API通常使用HTTP协议作为通信协议，并以JSON格式或XML格式传输数据。
例如，如果要获取某个用户的信息，可以使用GET方法发送HTTP请求到对应的URL（如/api/users/1），服务器将返回表示该用户信息的JSON或XML数据。
总而言之，RESTful风格的API是一种采用URL和HTTP方法来操作资源的软件架构，它提供了一种规范化的方式来设计和访问网络应用程序的接口。
展开
评论
点赞
#挑战每日一条沸点#
func reverseBetween(head *ListNode, left int, right int) *ListNode {
cnt := 1
pre, cur := &ListNode{}, head
for ; cur != nil && cnt != left; cnt++ {
pre = cur
cur = cur.Next
}
l, r := pre, cur
pre = nil
for ; cnt != right; cnt++ {
nex := cur.Next
cur.Next = pre
pre, cur = cur, nex
}
nex := cur.Next
cur.Next = pre
l.Next, r.Next = cur, nex
if r == head {
return cur
}
return head
}
func reverseBetween(head *ListNode, left int, right int) *ListNode {
cnt := 1
pre, cur := &ListNode{}, head
for ; cur != nil && cnt != left; cnt++ {
pre = cur
cur = cur.Next
}
l, r := pre, cur
pre = nil
for ; cnt != right; cnt++ {
nex := cur.Next
cur.Next = pre
pre, cur = cur, nex
}
nex := cur.Next
cur.Next = pre
l.Next, r.Next = cur, nex
if r == head {
return cur
}
return head
}
展开
评论
点赞
#每天一个知识点#
HTTPS 如何解决安全问题：
HTTP 不安全的问题有：
通信采用明文，内容可能会被窃听，账号信息容易泄露
不验证通信方的身份，因此有可能遭遇伪装，会访问假淘宝等
无法验证报文的完整性，所以有可能已遭篡改
针对以上问题，HTTPS 在 HTTP 与 TCP 之间加入 SSL/TLS 协议
1、信息加密：交互信息无法被窃取 -> 混合加密的方式实现了信息的机密性，解决了窃听的风险
2、校验机制：无法篡改通信内容，篡改了就不能正常显示 -> 摘要算法实现了完整性
3、身份证书：证明所访问的淘宝是真淘宝 -> 将服务器公钥放入到数字证书中，解决了冒充的风险
2 不能保证身份，即使有公钥私钥，但对方能够自己伪造，只有经由 3 的第三方机构验证数字证书权威性才能保证身份正确
HTTPS 如何解决安全问题：
HTTP 不安全的问题有：
通信采用明文，内容可能会被窃听，账号信息容易泄露
不验证通信方的身份，因此有可能遭遇伪装，会访问假淘宝等
无法验证报文的完整性，所以有可能已遭篡改
针对以上问题，HTTPS 在 HTTP 与 TCP 之间加入 SSL/TLS 协议
1、信息加密：交互信息无法被窃取 -> 混合加密的方式实现了信息的机密性，解决了窃听的风险
2、校验机制：无法篡改通信内容，篡改了就不能正常显示 -> 摘要算法实现了完整性
3、身份证书：证明所访问的淘宝是真淘宝 -> 将服务器公钥放入到数字证书中，解决了冒充的风险
2 不能保证身份，即使有公钥私钥，但对方能够自己伪造，只有经由 3 的第三方机构验证数字证书权威性才能保证身份正确
展开
评论
点赞
#每天一个知识点#
输入网址到网页显示：
应用层上，浏览器解析 URL，确定了 web 服务器域名和文件名，生成 HTTP 请求信息。同时，通过 DNS 协议查询 DNS 服务器所要发送的 web 服务器域名对应的 IP 地址，以委托操作系统发送。而后传输层进行 TCP 三次握手，双方确认后开始拆分数据包生成 TCP 报文，并委托网络层 IP 模块将数据封装成网络包。通过路由表选择一个网卡作为源地址 IP ，生成 IP 数据包。接下来交由网络接口层。网络接口层通过查询 ROM 获得网卡对应的本机 MAC 地址，通过 ARP 协议获得接收方的MAC地址以加上 MAC 头部，封装成数据帧发送到网络上。网卡驱动收到网络包后，将其复制到网卡内的缓存区中，在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列，并将数字信号转为电信号通过网线发送出去。经由交换机与路由器发送到对方服务器。对方服务器从底层往上，层层拆包，获取到 HTTP 请求信息，HTTP服务进程发现请求是为了访问一个页面，将网页封装在 HTTP 响应报文，又经由与上述相似的传输过程，客户端收到了 HTTP 响应报文，交给浏览器去渲染界面，至此网页显示了出来。
输入网址到网页显示：
应用层上，浏览器解析 URL，确定了 web 服务器域名和文件名，生成 HTTP 请求信息。同时，通过 DNS 协议查询 DNS 服务器所要发送的 web 服务器域名对应的 IP 地址，以委托操作系统发送。而后传输层进行 TCP 三次握手，双方确认后开始拆分数据包生成 TCP 报文，并委托网络层 IP 模块将数据封装成网络包。通过路由表选择一个网卡作为源地址 IP ，生成 IP 数据包。接下来交由网络接口层。网络接口层通过查询 ROM 获得网卡对应的本机 MAC 地址，通过 ARP 协议获得接收方的MAC地址以加上 MAC 头部，封装成数据帧发送到网络上。网卡驱动收到网络包后，将其复制到网卡内的缓存区中，在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列，并将数字信号转为电信号通过网线发送出去。经由交换机与路由器发送到对方服务器。对方服务器从底层往上，层层拆包，获取到 HTTP 请求信息，HTTP服务进程发现请求是为了访问一个页面，将网页封装在 HTTP 响应报文，又经由与上述相似的传输过程，客户端收到了 HTTP 响应报文，交给浏览器去渲染界面，至此网页显示了出来。
展开
评论
点赞
#每天一个知识点#
Redis AOF重写
由于 AOF 是一个文件，随着执行的写操作命令越来越多，文件越来越大。当整个文件过大，重启读 AOF 内容恢复就会很慢。为避免文件过大，启用 AOF 重写机制压缩 AOF 文件。
#### 何为重写
前后执行 set var 1 与 set var 2 两条命令，原 AOF 文件会有两条。 开启重写机制后，读取 var 最新 value，用一条 set var 2 命令记录到新的 AOF 文件。
#### 重写过程
由后台**子进程**完成，主进程可以继续处理命令请求，从而避免阻塞主进程。子进程带有数据副本，当父进程修改数据，发生写时复制，于是都有了独立的数据副本，**如果采用多线程，还需加锁确保数据安全，会降低性能**。
由于重写时，主进程依然处理命令。那么重写的 AOF 日志就会与原 AOF 日志产生差异。为解决数据不一致问题，设置 AOF 重写缓冲区。
于是在重写 AOF 期间，当 Redis 执行完一个写命令之后，它会同时将这个写命令写入到 AOF 缓冲区 和 AOF 重写缓冲区。
重写工作完成后，向主进程发送一条信号。而后主进程调用一个信号处理函数，将 AOF 重写缓冲区的所有内容追加到新的 AOF 的文件中，使得新旧两个 AOF 文件所保存的数据库状态一致。新的 AOF 文件改名，覆盖现有 AOF 文件。
Redis AOF重写
由于 AOF 是一个文件，随着执行的写操作命令越来越多，文件越来越大。当整个文件过大，重启读 AOF 内容恢复就会很慢。为避免文件过大，启用 AOF 重写机制压缩 AOF 文件。
#### 何为重写
前后执行 set var 1 与 set var 2 两条命令，原 AOF 文件会有两条。 开启重写机制后，读取 var 最新 value，用一条 set var 2 命令记录到新的 AOF 文件。
#### 重写过程
由后台**子进程**完成，主进程可以继续处理命令请求，从而避免阻塞主进程。子进程带有数据副本，当父进程修改数据，发生写时复制，于是都有了独立的数据副本，**如果采用多线程，还需加锁确保数据安全，会降低性能**。
由于重写时，主进程依然处理命令。那么重写的 AOF 日志就会与原 AOF 日志产生差异。为解决数据不一致问题，设置 AOF 重写缓冲区。
于是在重写 AOF 期间，当 Redis 执行完一个写命令之后，它会同时将这个写命令写入到 AOF 缓冲区 和 AOF 重写缓冲区。
重写工作完成后，向主进程发送一条信号。而后主进程调用一个信号处理函数，将 AOF 重写缓冲区的所有内容追加到新的 AOF 的文件中，使得新旧两个 AOF 文件所保存的数据库状态一致。新的 AOF 文件改名，覆盖现有 AOF 文件。
展开
评论
点赞
#每天一个知识点#
## 模型
**Redis-server** : Redis的主线程，主要负责执行命令
**bio_close_file, bio_aof_fsync, bio_lazy_free** : 三个后台线程，分别异步处理关闭文件任务、AOF刷盘任务、释放内存任务
**io_thd_1, io_thd_2, io_thd_3** : 三个 I/O 线程，io-threads 默认是 4 ，所以会启动 3（4-1，主线程被隐含算入）个 I/O 多线程，用来分担 Redis 网络 I/O 的压力
## 演变
redis 2.6，启动 2 个后台线程，分别处理关闭文件、AOF刷盘两个任务
redis 4.0 之后，新增一个后台线程，用来异步释放 Redis 内存
redis 6.0 之后，新增三个IO线程，用来分担网络 I/O 的压力
## 问题
**为什么 6.0 之前使用单线程？**
- 因为 CPU 不是制约 Redis 性能表现的瓶颈所在，更多情况受内存大小和网络I/O的限制。
- 且单线程可维护性高，没有多线程并发读写的一系列问题。也没有线程切换，加锁解锁与死锁带来的性能损耗。
而后随着网络硬件的升级，Redis 的性能瓶颈有时会出现在网络 I/O 的处理上，故引入 I/O 线程。
**为什么之前 Redis 单线程还这么快?**
- Redis大部分内容在内存中完成
- 采用了高效的数据结构
- 单线程模型避免了多线程之间的竞争，省去多线程切换的开销
- 采用了 I/O 多路复用机制处理大量用户的客户端 Socket 请求
## 模型
**Redis-server** : Redis的主线程，主要负责执行命令
**bio_close_file, bio_aof_fsync, bio_lazy_free** : 三个后台线程，分别异步处理关闭文件任务、AOF刷盘任务、释放内存任务
**io_thd_1, io_thd_2, io_thd_3** : 三个 I/O 线程，io-threads 默认是 4 ，所以会启动 3（4-1，主线程被隐含算入）个 I/O 多线程，用来分担 Redis 网络 I/O 的压力
## 演变
redis 2.6，启动 2 个后台线程，分别处理关闭文件、AOF刷盘两个任务
redis 4.0 之后，新增一个后台线程，用来异步释放 Redis 内存
redis 6.0 之后，新增三个IO线程，用来分担网络 I/O 的压力
## 问题
**为什么 6.0 之前使用单线程？**
- 因为 CPU 不是制约 Redis 性能表现的瓶颈所在，更多情况受内存大小和网络I/O的限制。
- 且单线程可维护性高，没有多线程并发读写的一系列问题。也没有线程切换，加锁解锁与死锁带来的性能损耗。
而后随着网络硬件的升级，Redis 的性能瓶颈有时会出现在网络 I/O 的处理上，故引入 I/O 线程。
**为什么之前 Redis 单线程还这么快?**
- Redis大部分内容在内存中完成
- 采用了高效的数据结构
- 单线程模型避免了多线程之间的竞争，省去多线程切换的开销
- 采用了 I/O 多路复用机制处理大量用户的客户端 Socket 请求
展开
评论
点赞
#挑战每日一条沸点#
力扣每日一题：445 两数相加
复习了一下反转链表的迭代写法。在最开始设立一个空的前节点，每次循环将现节点的next指为前节点，之后前节点变为现节点，现节点变为其最初的next即可。
此题要求用两条链表代表的整数进行相加。由于加法是从低位到高位相加，因此需要先反转链表再相加，或者直接取出所有数到栈里再加（但这样就太简单了）。相加阶段最开始想着取两条链中最长的那一条来加。这样需要在反转阶段进行计数，而且后续还有swap操作，不够简洁。后面直接新设一条链来记录和，就好写很多。最后返回结果还需要再反转链表。
但是这样交上去运行时间稍长，发现是中间的取模以及除法耗时长，改为if判断，直接取进位，就快了很多，速度超过100%。
从这题复习了go语言创建结构体的几种方法
code.juejin.cn
力扣每日一题：445 两数相加
复习了一下反转链表的迭代写法。在最开始设立一个空的前节点，每次循环将现节点的next指为前节点，之后前节点变为现节点，现节点变为其最初的next即可。
此题要求用两条链表代表的整数进行相加。由于加法是从低位到高位相加，因此需要先反转链表再相加，或者直接取出所有数到栈里再加（但这样就太简单了）。相加阶段最开始想着取两条链中最长的那一条来加。这样需要在反转阶段进行计数，而且后续还有swap操作，不够简洁。后面直接新设一条链来记录和，就好写很多。最后返回结果还需要再反转链表。
但是这样交上去运行时间稍长，发现是中间的取模以及除法耗时长，改为if判断，直接取进位，就快了很多，速度超过100%。
从这题复习了go语言创建结构体的几种方法
code.juejin.cn
展开
评论
点赞
