:docs:kafka

Author: Jstarfish

docs/.DS_Store

@@ -37,7 +37,7 @@
             "state": {
               "type": "markdown",
               "state": {
-                "file": "data-structure-algorithms/soultion/Binary-Tree-Solution.md",
+                "file": "data-management/Redis/Redis-Datatype.md",
                 "mode": "source",
                 "source": false
               }
@@ -150,7 +150,7 @@
             "state": {
               "type": "backlink",
               "state": {
-                "file": "data-structure-algorithms/soultion/Binary-Tree-Solution.md",
+                "file": "data-management/Redis/Redis-Datatype.md",
                 "collapseAll": true,
                 "extraContext": false,
                 "sortOrder": "alphabetical",
@@ -167,7 +167,7 @@
             "state": {
               "type": "outgoing-link",
               "state": {
-                "file": "data-structure-algorithms/soultion/Binary-Tree-Solution.md",
+                "file": "data-management/Redis/Redis-Datatype.md",
                 "linksCollapsed": false,
                 "unlinkedCollapsed": true
               }
@@ -190,7 +190,7 @@
             "state": {
               "type": "outline",
               "state": {
-                "file": "data-structure-algorithms/soultion/Binary-Tree-Solution.md"
+                "file": "data-management/Redis/Redis-Datatype.md"
               }
             }
           }
@@ -213,6 +213,15 @@
   },
   "active": "e24a131a4a8c13f9",
   "lastOpenFiles": [
+    "data-management/Redis/Redis-Database.md",
+    "data-management/Redis/Nosql-Overview.md",
+    "data-management/Redis/Nosql-Overview~.md",
+    "data-management/Redis/reproduce/Cache-Design.md",
+    "data-management/Redis/reproduce/Redis为什么变慢了-常见延迟问题定位与分析.md",
+    "data-management/Redis/reproduce/Key 寻址算法.md",
+    "interview/Redis-FAQ.md",
+    "data-structure-algorithms/soultion/Binary-Tree-Solution.md",
+    "未命名文件夹",
     "java/IO~.md",
     "java/IO.md",
     "java/未命名.md",
@@ -231,14 +240,6 @@
     "data-management/MySQL/MySQL-Lock.md",
     "framework/SpringWebFlux/响应式编程.md",
     "java/JVM/JVM性能监控和故障处理工具.md",
-    "sidebar.md",
-    "data-structure-algorithms/algorithm/Backtracking.md",
-    "data-structure-algorithms/algorithm/Dynamic-Programming.md",
-    "data-structure-algorithms/algorithm/DFS.md",
-    "data-management/MySQL/MySQL-Select.md",
-    "java/JVM/Runtime-Data-Areas.md",
-    "java/JVM/JVM-Java.md",
-    "java/JVM/Java-Object.md",
     "Untitled.canvas",
     "data-structure-algorithms/algorithm",
     "data-structure-algorithms/未命名文件夹"

docs/.obsidian/workspace.json

@@ -1 +1 @@
-Subproject commit 6ed390e03ee34a03da02242e98620c01dec36087
+Subproject commit 4cc6204ab4f695ada243316f8c92e754fb34c945

docs/.vuepress/.DS_Store

@@ -1,5 +1,3 @@
-![nosql-index.jpg](http://ww1.sinaimg.cn/large/9b9f09a9ly1g9yp975bslj211c0fq75c.jpg)
-
 # NoSQL的前世今生
 
 ### 啥玩意：
@@ -12,35 +10,35 @@ NoSQL(NoSQL = Not Only SQL )，“不仅仅是SQL”，泛指**非关系型的
 
 #### 1. 单机MySQL的美好年代
 
-​		在以前，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。上述架构下，我们来看看数据存储的瓶颈是什么？
+在以前，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。上述架构下，我们来看看数据存储的瓶颈是什么？
 
 - 数据量的总大小 一个机器放不下时
 - 数据的索引（B+ Tree）一个机器的内存放不下时
 - 访问量(读写混合)一个实例不能承受
 
 #### 2. Memcached(缓存)+MySQL+垂直拆分
 
-​       后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用**缓存技术**来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过**文件缓存**来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。
+后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用**缓存技术**来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过**文件缓存**来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。
 
-​		Memcached作为一个**独立的分布式的缓存服务器**，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端
+Memcached作为一个**独立的分布式的缓存服务器**，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端
 
 #### 3. Mysql主从读写分离
 
-​		由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始**使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性**。**Mysql的master-slave模式**成为这个时候的网站标配了。
+由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始**使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性**。**Mysql的master-slave模式**成为这个时候的网站标配了。
 
 #### 4. 分表分库+水平拆分+mysql集群 
 
-​		在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于**MyISAM**使用**表锁**，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用**InnoDB**引擎代替MyISAM。
+在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于**MyISAM**使用**表锁**，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用**InnoDB**引擎代替MyISAM。
 
-​		同时，开始流行**使用分表分库来缓解写压力和数据增长的扩展问题**。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。
+同时，开始流行**使用分表分库来缓解写压力和数据增长的扩展问题**。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。
 
 #### 5. MySQL的扩展性瓶颈
 
-​		MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
+MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
 
 #### 6. 为什么用NoSQL
 
-​		今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的**访问和抓取数据**（爬虫私密信息有风险哈）。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也不能很好的处理这些大的数据。
+今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的**访问和抓取数据**（爬虫私密信息有风险哈）。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也不能很好的处理这些大的数据。
 
 ![](https://i.loli.net/2019/11/17/WvJC95bHnUjGuF2.png)
 

docs/.vuepress/dist

@@ -103,6 +103,8 @@ Redis 作为庞大的键值数据库，可以说遍地都是知识，一抓一
 
 
 
+
+
 ## 推荐阅读
 
 [《我是如何学习Redis的？高效学习Redis的路径和方法分享》](http://kaito-kidd.com/2020/09/09/how-i-learned-redis/)