Nebula1805
获得徽章 1
#青训营笔记创作活动#
2月13日 打卡Day30
今日学习 深入数据库底层揭开索引机制的神秘面纱！
聚簇索引和非聚簇索引的根本区别：
- 聚簇索引中，表数据和索引数据是按照相同顺序存储的，非聚簇索引则不是。
- 聚簇索引在一张表中是唯一的，只能有一个，非聚簇索引则可以存在多个。
- 聚簇索引在逻辑+物理上都是连续的，非聚簇索引则仅是逻辑上的连续。
- 聚簇索引中找到了索引键就找到了行数据，但非聚簇索引还需要做一次回表查询。
`InnoDB`-非聚簇索引与`MyISAM`-非聚簇索引的区别：
- `InnoDB`中的非聚簇索引是以聚簇索引的索引键，与具体的行数据建立关联关系的。
- `MyISAM`中的非聚簇索引是以行数据的地址指针，与具体的行数据建立关联关系的。
一般来说，由于`MyISAM`引擎中的索引可以根据指针直接获取数据，不需要做二次回表查询，因此从整体查询效率来看，会比`InnoDB`要快上不少。
2月13日 打卡Day30
今日学习 深入数据库底层揭开索引机制的神秘面纱！
聚簇索引和非聚簇索引的根本区别：
- 聚簇索引中，表数据和索引数据是按照相同顺序存储的，非聚簇索引则不是。
- 聚簇索引在一张表中是唯一的，只能有一个，非聚簇索引则可以存在多个。
- 聚簇索引在逻辑+物理上都是连续的，非聚簇索引则仅是逻辑上的连续。
- 聚簇索引中找到了索引键就找到了行数据，但非聚簇索引还需要做一次回表查询。
`InnoDB`-非聚簇索引与`MyISAM`-非聚簇索引的区别：
- `InnoDB`中的非聚簇索引是以聚簇索引的索引键，与具体的行数据建立关联关系的。
- `MyISAM`中的非聚簇索引是以行数据的地址指针，与具体的行数据建立关联关系的。
一般来说，由于`MyISAM`引擎中的索引可以根据指针直接获取数据，不需要做二次回表查询，因此从整体查询效率来看，会比`InnoDB`要快上不少。
展开
评论
点赞
#青训营笔记创作活动#
2月12日 打卡Day29
今日学习 全解MySQL之死锁问题分析、事务隔离与锁机制的底层原理剖析
在本篇中补齐了`MySQL`死锁分析、锁实现原理、事务隔离机制原理等内容，也结合事务、锁、`MVCC`机制三者的知识点，彻底理清楚了`MySQL`不同隔离级别下的实现，最后做个简单的小总结：
- RU级别：读操作不加锁，写操作加排他锁。
- RC级别：读操作使用`MVCC`机制，每次`SELECT`生成快照，写操作加排他锁。
- RR级别：读操作使用`MVCC`机制，首次`SELECT`生成快照，写操作加临键锁。
- 序列化级别：读操作加共享锁，写操作加临键锁。
2月12日 打卡Day29
今日学习 全解MySQL之死锁问题分析、事务隔离与锁机制的底层原理剖析
在本篇中补齐了`MySQL`死锁分析、锁实现原理、事务隔离机制原理等内容，也结合事务、锁、`MVCC`机制三者的知识点，彻底理清楚了`MySQL`不同隔离级别下的实现，最后做个简单的小总结：
- RU级别：读操作不加锁，写操作加排他锁。
- RC级别：读操作使用`MVCC`机制，每次`SELECT`生成快照，写操作加排他锁。
- RR级别：读操作使用`MVCC`机制，首次`SELECT`生成快照，写操作加临键锁。
- 序列化级别：读操作加共享锁，写操作加临键锁。
展开
评论
点赞
#青训营笔记创作活动#
2月10日 打卡Day28
今日学习 什么是跨域问题？如何解决？
跨域问题的本质是浏览器为了保证用户的一种安全拦截机制，想要解决跨域问题，只需要告诉浏览器“我是自己人，不要拦我”就行。它的常见实现方式有 5 种：通过注解实现局部跨域、通过配置文件实现全局跨域、通过 CorsFilter 对象实现全局跨域、通过 Response 对象实现局部跨域，通过 ResponseBodyAdvice 实现全局跨域。
2月10日 打卡Day28
今日学习 什么是跨域问题？如何解决？
跨域问题的本质是浏览器为了保证用户的一种安全拦截机制，想要解决跨域问题，只需要告诉浏览器“我是自己人，不要拦我”就行。它的常见实现方式有 5 种：通过注解实现局部跨域、通过配置文件实现全局跨域、通过 CorsFilter 对象实现全局跨域、通过 Response 对象实现局部跨域，通过 ResponseBodyAdvice 实现全局跨域。
展开
评论
点赞
#青训营笔记创作活动#
2月9日 打卡Day27
今日学习 好好的系统，为什么要分库分表？
分库分表是在海量数据下，由于单库、表数据量过大，导致数据库性能持续下降的问题，演变出的技术方案。
分库分表是由`分库`和`分表`这两个独立概念组成的，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。
通过一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。
单机数据库的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。
一旦数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候就需要进行分库分表。
2月9日 打卡Day27
今日学习 好好的系统，为什么要分库分表？
分库分表是在海量数据下，由于单库、表数据量过大，导致数据库性能持续下降的问题，演变出的技术方案。
分库分表是由`分库`和`分表`这两个独立概念组成的，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。
通过一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。
单机数据库的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。
一旦数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候就需要进行分库分表。
展开
评论
点赞
#青训营笔记创作活动#
2月8日 打卡Day26
今日学习 聊一聊缓存和数据库不一致性问题的产生及主流解决方案以及扩展的思考
无论选择下列那种方式
- 先更新缓存，再更新数据库
- 先更新数据库，再更新缓存
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
如果是在多服务或是并发情况下，其实都有可能产生数据不一致性。
不过在这四种选择中，平常都会优先考虑后两种方式。并且市面上对于这后两种选择，也已经有一些解决方案。
2月8日 打卡Day26
今日学习 聊一聊缓存和数据库不一致性问题的产生及主流解决方案以及扩展的思考
无论选择下列那种方式
- 先更新缓存，再更新数据库
- 先更新数据库，再更新缓存
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
如果是在多服务或是并发情况下，其实都有可能产生数据不一致性。
不过在这四种选择中，平常都会优先考虑后两种方式。并且市面上对于这后两种选择，也已经有一些解决方案。
展开
评论
点赞
#青训营笔记创作活动#
2月7日 打卡Day25
今日学习 聊聊高并发系统基石之一的缓存
在服务端开发中，**缓存**常常被当做系统_性能扛压_的不二之选。在实施方案上，缓存使用策略虽有一定普适性，却也并非完全绝对，需要结合实际的项目诉求与场景进行综合权衡与考量，进而得出符合自己项目的最佳实践。
2月7日 打卡Day25
今日学习 聊聊高并发系统基石之一的缓存
在服务端开发中，**缓存**常常被当做系统_性能扛压_的不二之选。在实施方案上，缓存使用策略虽有一定普适性，却也并非完全绝对，需要结合实际的项目诉求与场景进行综合权衡与考量，进而得出符合自己项目的最佳实践。
展开
评论
点赞
#青训营笔记创作活动#
2月6日 打卡Day24
今日学习 高并发下秒杀商品，你必须知道的9个细节
1 .瞬时高并发
2.页面静态化
3.秒杀按钮
4.读多写少
5.缓存问题
6.库存问题
7.分布式锁
8.mq异步处理
9.如何限流？
2月6日 打卡Day24
今日学习 高并发下秒杀商品，你必须知道的9个细节
1 .瞬时高并发
2.页面静态化
3.秒杀按钮
4.读多写少
5.缓存问题
6.库存问题
7.分布式锁
8.mq异步处理
9.如何限流？
展开
评论
点赞
#青训营笔记创作活动#
2月5日 打卡Day23
今日学习 为什么用公钥加密却不能用公钥解密？
- 大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在**特定情况**下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。
- HTTPS相当于HTTP+TLS，目前主流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。
- TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。
- TLS四次握手背起来会挺难受的，建议关注三个随机数的流向，以此作为基础去理解，大概就能记下来了。
2月5日 打卡Day23
今日学习 为什么用公钥加密却不能用公钥解密？
- 大数取模运算是不可逆的，因此他人无法暴力解密。但是结合欧拉定理，我们可以选取出合适的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在**特定情况**下，变得有那么点“可逆”的味道。数学原理决定了我们用公钥加密的数据，只有私钥能解密。反过来，用私钥加密的数据，也只有公钥能解密。
- HTTPS相当于HTTP+TLS，目前主流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。
- TLS四次握手的过程中涉及到两对私钥和公钥。分别是服务器本身的私钥和公钥，以及CA的私钥和公钥。
- TLS四次握手背起来会挺难受的，建议关注三个随机数的流向，以此作为基础去理解，大概就能记下来了。
展开
评论
点赞
#青训营笔记创作活动#
2月4日 打卡Day22
今日学习 刨根问底 Redis， 面试过程真好使
随着互联网时代的崛起，人们对于网站访问速度有着越来越高的要求，直接使用关系型数据库的方案在性能上就出现了瓶颈。因此在客户端与数据层之间就需要一个缓存层来分担请求压力，而 Redis 作为一款优秀的缓存中间件，在企业级架构中占有重要的地位。
## 1.什么是 Redis
Redis（Remote Dictionary Server）是一个开源的、键值对型的数据存储系统。使用C语言编写，遵守BSD协议，可基于内存也可持久化的日志型数据库，提供了多种语言的API，被广泛用于数据库、缓存和消息中间件。并且支持多种类型的数据结构，用于应对各种不同场景。可以存储多种不同类型值之间的映射，支持事务，持久化，LUA 脚本以及多种集群方案等。
## 2. Redis优缺点
**优点：**
1. 完全基于内存操作，性能极高，读写速度快，Redis 能够支持超过 100KB/s 的读写速率
2. 支持高并发，支持10万级别的并发读写
3. 支持主从模式，支持读写分离与分布式
4. 具有丰富的数据类型与丰富的特性（发布订阅模式）
5. 支持持久化操作，不会丢失数据
**缺点：**
1. 数据库容量受到物理内存的限制，不能实现海量数据的高性能读写
2. 相比关系型数据库，不支持复杂逻辑查询，且存储结构相对简单
3. 虽然提供持久化能力，但实际更多是一个 disk-backed 功能，与传统意义上的持久化有所区别
3.Redis 高性能的原因
- 完全基于内存
- 数据结构简单，操作方便，并且不同数据结构能够应对于不同场景
- 采用单线程（网络请求模块使用单线程，其他模块仍用了多线程），避免了不必要的上下文切换和竞争条件，也不存在多进程或多线程切换导致CPU消耗，不需要考虑各种锁的问题。
- 使用多路I/O复用模型，为非阻塞I/O
- Redis 本身设定了 VM 机制，没有使用 OS 的Swap，可以实现冷热数据分离，避免因为内存不足而造成访问速度下降的问题
2月4日 打卡Day22
今日学习 刨根问底 Redis， 面试过程真好使
随着互联网时代的崛起，人们对于网站访问速度有着越来越高的要求，直接使用关系型数据库的方案在性能上就出现了瓶颈。因此在客户端与数据层之间就需要一个缓存层来分担请求压力，而 Redis 作为一款优秀的缓存中间件，在企业级架构中占有重要的地位。
## 1.什么是 Redis
Redis（Remote Dictionary Server）是一个开源的、键值对型的数据存储系统。使用C语言编写，遵守BSD协议，可基于内存也可持久化的日志型数据库，提供了多种语言的API，被广泛用于数据库、缓存和消息中间件。并且支持多种类型的数据结构，用于应对各种不同场景。可以存储多种不同类型值之间的映射，支持事务，持久化，LUA 脚本以及多种集群方案等。
## 2. Redis优缺点
**优点：**
1. 完全基于内存操作，性能极高，读写速度快，Redis 能够支持超过 100KB/s 的读写速率
2. 支持高并发，支持10万级别的并发读写
3. 支持主从模式，支持读写分离与分布式
4. 具有丰富的数据类型与丰富的特性（发布订阅模式）
5. 支持持久化操作，不会丢失数据
**缺点：**
1. 数据库容量受到物理内存的限制，不能实现海量数据的高性能读写
2. 相比关系型数据库，不支持复杂逻辑查询，且存储结构相对简单
3. 虽然提供持久化能力，但实际更多是一个 disk-backed 功能，与传统意义上的持久化有所区别
3.Redis 高性能的原因
- 完全基于内存
- 数据结构简单，操作方便，并且不同数据结构能够应对于不同场景
- 采用单线程（网络请求模块使用单线程，其他模块仍用了多线程），避免了不必要的上下文切换和竞争条件，也不存在多进程或多线程切换导致CPU消耗，不需要考虑各种锁的问题。
- 使用多路I/O复用模型，为非阻塞I/O
- Redis 本身设定了 VM 机制，没有使用 OS 的Swap，可以实现冷热数据分离，避免因为内存不足而造成访问速度下降的问题
展开
评论
点赞
#青训营笔记创作活动#
2月3日 打卡Day21
今日学习 MySQL之索引初识篇：索引机制、索引分类、索引使用与管理综述
**索引就是用来帮助表快速检索目标数据的**
数据库是基于磁盘工作的，所有的数据都会放到磁盘上存储，而索引也是数据的一种，因此与表数据相同，最终创建出的索引也会在磁盘生成本地文件。
索引本质上和表是一样的，都是磁盘中的文件，那也就代表着创建一个索引，并不像单纯的给一张表加个约束那么简单，而是会基于原有的表数据，重新在磁盘中创建新的本地索引文件。假设表中有一千万条数据，那创建索引时，就需要将索引字段上的`1000W`个值全部拷贝到本地索引文件中，同时做好排序并与表数据产生映射关系。
索引建立后也会在磁盘生成索引文件，那每个具体的索引节点该如何在本地文件中存放呢？这点是由索引的数据结构来决定的。比如索引的底层结构是数组，那所有的索引节点都会以`Node1→Node2→Node3→Node4....`这样的形式，存储在磁盘同一块物理空间中，不过`MySQL`的索引不支持数组结构，或者说数组结构不适合作为索引结构，`MySQL`索引支持的数据结构如下：
- `B+Tree`类型：`MySQL`中最常用的索引结构，大部分引擎支持，有序。
- `Hash`类型：大部分存储引擎都支持，字段值不重复的情况下查询最快，无序。
- `R-Tree`类型：`MyISAM`引擎支持，也就是空间索引的默认结构类型。
- `T-Tree`类型：`NDB-Cluster`引擎支持，主要用于`MySQL-Cluster`服务中。
在上述的几种索引结构中，`B+`树和哈希索引是最常见的索引结构，几乎大部分存储引擎都实现了，对于后续两种索引结构在某些情况下也较为常见，但除开列出的几种索引结构外，`MySQL`索引支持的数据结构还有`R+、R*、QR、SS、X`树等结构。
2月3日 打卡Day21
今日学习 MySQL之索引初识篇：索引机制、索引分类、索引使用与管理综述
**索引就是用来帮助表快速检索目标数据的**
数据库是基于磁盘工作的，所有的数据都会放到磁盘上存储，而索引也是数据的一种，因此与表数据相同，最终创建出的索引也会在磁盘生成本地文件。
索引本质上和表是一样的，都是磁盘中的文件，那也就代表着创建一个索引，并不像单纯的给一张表加个约束那么简单，而是会基于原有的表数据，重新在磁盘中创建新的本地索引文件。假设表中有一千万条数据，那创建索引时，就需要将索引字段上的`1000W`个值全部拷贝到本地索引文件中，同时做好排序并与表数据产生映射关系。
索引建立后也会在磁盘生成索引文件，那每个具体的索引节点该如何在本地文件中存放呢？这点是由索引的数据结构来决定的。比如索引的底层结构是数组，那所有的索引节点都会以`Node1→Node2→Node3→Node4....`这样的形式，存储在磁盘同一块物理空间中，不过`MySQL`的索引不支持数组结构，或者说数组结构不适合作为索引结构，`MySQL`索引支持的数据结构如下：
- `B+Tree`类型：`MySQL`中最常用的索引结构，大部分引擎支持，有序。
- `Hash`类型：大部分存储引擎都支持，字段值不重复的情况下查询最快，无序。
- `R-Tree`类型：`MyISAM`引擎支持，也就是空间索引的默认结构类型。
- `T-Tree`类型：`NDB-Cluster`引擎支持，主要用于`MySQL-Cluster`服务中。
在上述的几种索引结构中，`B+`树和哈希索引是最常见的索引结构，几乎大部分存储引擎都实现了，对于后续两种索引结构在某些情况下也较为常见，但除开列出的几种索引结构外，`MySQL`索引支持的数据结构还有`R+、R*、QR、SS、X`树等结构。
展开
评论
点赞
#青训营笔记创作活动#
2月2日 打卡Day20
今日学习 MySQL索引应用篇：建立索引的正确姿势与使用索引的最佳指南
引入索引机制后，能够给数据库带来的优势很明显：
- ①整个数据库中，数据表的查询速度直线提升，数据量越大时效果越明显。
- ②通过创建唯一索引，可以确保数据表中的数据唯一性，无需额外建立唯一约束。
- ③在使用分组和排序时，同样可以显著减少`SQL`查询的分组和排序的时间。
- ④连表查询时，基于主外键字段上建立索引，可以带来十分明显的性能提升。
- ⑤索引默认是`B+Tree`有序结构，基于索引字段做范围查询时，效率会明显提高。
- ⑥从`MySQL`整体架构而言，减少了查询`SQL`的执行时间，提高了数据库整体吞吐量。
弊端，如：
- ①建立索引会生成本地磁盘文件，需要额外的空间存储索引数据，磁盘占用率会变高。
- ②写入数据时，需要额外维护索引结构，增、删、改数据时，都需要额外操作索引。
- ③写入数据时维护索引需要额外的时间开销，执行写`SQL`时效率会降低，性能会下降。
2月2日 打卡Day20
今日学习 MySQL索引应用篇：建立索引的正确姿势与使用索引的最佳指南
引入索引机制后，能够给数据库带来的优势很明显：
- ①整个数据库中，数据表的查询速度直线提升，数据量越大时效果越明显。
- ②通过创建唯一索引，可以确保数据表中的数据唯一性，无需额外建立唯一约束。
- ③在使用分组和排序时，同样可以显著减少`SQL`查询的分组和排序的时间。
- ④连表查询时，基于主外键字段上建立索引，可以带来十分明显的性能提升。
- ⑤索引默认是`B+Tree`有序结构，基于索引字段做范围查询时，效率会明显提高。
- ⑥从`MySQL`整体架构而言，减少了查询`SQL`的执行时间，提高了数据库整体吞吐量。
弊端，如：
- ①建立索引会生成本地磁盘文件，需要额外的空间存储索引数据，磁盘占用率会变高。
- ②写入数据时，需要额外维护索引结构，增、删、改数据时，都需要额外操作索引。
- ③写入数据时维护索引需要额外的时间开销，执行写`SQL`时效率会降低，性能会下降。
展开
评论
点赞