From b6c47701db1d56630b83b39eb5d5e396504b3aea Mon Sep 17 00:00:00 2001
From: whx123 <327658337@qq.com>
Date: Sun, 20 Jun 2021 09:44:13 +0800
Subject: [PATCH 01/51] =?UTF-8?q?m=E5=87=8F=E5=B0=91bug?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
...345\260\221bug\345\221\242\357\274\237.md" | 663 ++++++++++++++++++
...260\221bug\345\221\242\357\274\237.md.bak" | 0
2 files changed, 663 insertions(+)
create mode 100644 "\345\267\245\344\275\234\346\200\273\347\273\223/\350\201\212\350\201\212\346\227\245\345\270\270\345\274\200\345\217\221\344\270\255\357\274\214\345\246\202\344\275\225\345\207\217\345\260\221bug\345\221\242\357\274\237.md"
create mode 100644 "\345\267\245\344\275\234\346\200\273\347\273\223/\350\201\212\350\201\212\346\227\245\345\270\270\345\274\200\345\217\221\344\270\255\357\274\214\345\246\202\344\275\225\345\207\217\345\260\221bug\345\221\242\357\274\237.md.bak"
diff --git "a/\345\267\245\344\275\234\346\200\273\347\273\223/\350\201\212\350\201\212\346\227\245\345\270\270\345\274\200\345\217\221\344\270\255\357\274\214\345\246\202\344\275\225\345\207\217\345\260\221bug\345\221\242\357\274\237.md" "b/\345\267\245\344\275\234\346\200\273\347\273\223/\350\201\212\350\201\212\346\227\245\345\270\270\345\274\200\345\217\221\344\270\255\357\274\214\345\246\202\344\275\225\345\207\217\345\260\221bug\345\221\242\357\274\237.md"
new file mode 100644
index 0000000..0c47dce
--- /dev/null
+++ "b/\345\267\245\344\275\234\346\200\273\347\273\223/\350\201\212\350\201\212\346\227\245\345\270\270\345\274\200\345\217\221\344\270\255\357\274\214\345\246\202\344\275\225\345\207\217\345\260\221bug\345\221\242\357\274\237.md"
@@ -0,0 +1,663 @@
+## 前言
+
+大家好呀~ 我是捡田螺的小男孩，今天跟大家聊聊日常开发中，如何减少bug？本文将从**数据库、代码层面、缓存使用篇**3个大方向，总结出一共60多个注意点，助大家成为开发质量之星。
+
+
+- 欢迎关注公众号：**捡田螺的小男孩**
+- [github地址](https://github.com/whx123/JavaHome)，感谢每一颗star
+
+## 1. 数据库篇
+
+
+
+数据库篇的话，哪些地方容易导致bug出现呢？我总结了7个方面：**慢查询、数据库字段注意点、事务失效的场景、死锁、主从延迟、新老数据兼容、一些SQL经典注意点**。
+
+### 1.1 慢查询
+
+
+
+#### 1.1.1 是否命中索引
+提起慢查询，我们马上就会想到加索引。如果一条SQL没加索引，或者没有命中索引的话，就会产生慢查询。
+
+**索引哪些情况会失效？**
+
+- 查询条件包含or，可能导致索引失效
+- 如何字段类型是字符串，where时一定用引号括起来，否则索引失效
+- like通配符可能导致索引失效。
+- 联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
+- 在索引列上使用mysql的内置函数，索引失效。
+- 对索引列运算（如，+、-、*、/），索引失效。
+- 索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
+- 索引字段上使用is null， is not null，可能导致索引失效。
+- 左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
+- mysql估计使用全表扫描要比使用索引快,则不使用索引。
+
+
+#### 1.1.2 数据量大，考虑分库分表
+
+单表数据量太大，就会影响SQL执行性能。我们知道索引数据结构一般是B+树，一棵高度为3的B+树，大概可以存储两千万的数据。超过这个数的话，B+树要变高，查询性能会下降。
+
+因此，数据量大的时候，建议分库分表。分库分表的中间件有**mycat、sharding-jdbc**
+
+
+#### 1.1.3 不合理的SQL
+
+日常开发中，笔者见过很多不合理的SQL：比如一个SQL居然用了**6个表连接**,连表太多会影响查询性能；再比如一个表，居然加了**10个索引**等等。索引是会降低了插入和更新SQL性能，所以索引一般不建议太多，一般不能超过五个。
+
+
+### 1.2 数据库字段注意点
+
+数据库字段这块内容，很容易出bug。比如，你测试环境修改了表结构，加了某个字段，忘记把脚本带到生产环境，那发版肯定有问题了。
+
+#### 1.2.1 字段是否会超长
+
+假设你的数据库字段是：
+
+```
+`name` varchar(255) DEFAULT NOT NULL
+```
+
+如果请求参数来了变量name，字段长度是300，那插入表的时候就**报错**了。所以需要校验参数，防止字段超长。
+
+#### 1.2.2 字段为空，是否会导致空指针等
+
+我们设计数据库表字段的时候,尽量把字段设置为**not null**。
+
+- 如果是整形，我们一般使用0或者-1作为默认值。
+- 如果字符串，默认空字符串
+
+如果数据库字段设置为```NULL```值，容易导致程序空指针；如果数据库字段设置为```NULL```值，需要注意**count(具体列)** 的使用，会有坑。
+
+#### 1.2.3 字段缺失
+
+我们的日常开发任务，如果在测试环境，对表进行修改，比如添加了一个新字段，必须要把SQL脚本带到生产环境，否则字段缺失，发版就有问题啦。
+
+
+#### 1.2.4 字段类型是否支持表情
+
+如果一个表字段需要支持表情存储，使用**utf8mb4**。
+
+#### 1.2.5 谨慎使用text、blob字段
+
+如果你要用一个字段存储文件，考虑**存储文件的路径**，而不保存整个文件下去。使用text时，涉及查询条件时，注意创建**前缀索引**。
+
+### 1.3 事务失效的场景
+
+#### 1.3.1 @Transactional 在非public修饰的方法上失效
+
+
+@Transactional注解，加在非public修饰的方法上，事务是不会生效的。spring事务是借鉴了AOP的思想，也是通过动态代理来实现的。spring事务自己在调用动态代理之前，已经对非public方法过滤了，所以非public方法，事务不生效。
+
+#### 1.3.2 本地方法直接调用
+以下这个场景， @Transactional事务也是无效的
+```
+public class TransactionTest{
+ public void A(){
+ //插入一条数据
+ //调用方法B (本地的类调用，事务失效了)
+ B();
+ }
+
+ @Transactional
+ public void B(){
+ //插入数据
+ }
+}
+```
+
+#### 1.3.3 异常被try...catch吃了，导致事务失效。
+
+
+```
+@Transactional
+public void method(){
+ try{
+ //插入一条数据
+ insertA();
+ //更改一条数据
+ updateB();
+ }catch(Exception e){
+ logger.error("异常被捕获了，那你的事务就失效咯",e);
+ }
+}
+
+```
+
+#### 1.3.4 rollbackFor属性设置错误
+
+Spring默认抛出了未检查```unchecked```异常（继承自RuntimeException 的异常）或者Error才回滚事务；其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常，就需要指定```rollbackFor```属性。
+
+#### 1.3.5 底层数据库引擎不支持事务
+
+MyISAM存储引擎不支持事务，InnoDb就支持事务
+
+#### 1.3.6 spring事务和业务逻辑代码必须在一个线程中
+
+业务代码要和spring事务的源码在同一个线程中，才会受spring事务的控制。比如下面代码，方法mothed的子线程，内部执行的事务操作，将不受mothed方法上spring事务的控制，这一点大家要注意。这是因为spring事务实现中使用了ThreadLocal，实现同一个线程中数据共享。
+
+```
+@Transactional
+public void mothed() {
+ new Thread() {
+ 事务操作
+ }.start();
+}
+```
+
+
+### 1.4 死锁
+
+死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。
+
+
+
+
+MySQL内部有一套死锁检测机制，一旦发生死锁会立即回滚一个事务，让另一个事务执行下去。但死锁有**资源的利用率降低、进程得不到正确结果**等危害。
+
+#### 1.4.1 9种情况的SQL加锁分析
+
+要避免死锁，需要学会分析：一条SQL的加锁是如何进行的?一条SQL加锁，可以分9种情况进行探讨：
+
+- 组合一：id列是主键，RC隔离级别
+- 组合二：id列是二级唯一索引，RC隔离级别
+- 组合三：id列是二级非唯一索引，RC隔离级别
+- 组合四：id列上没有索引，RC隔离级别
+- 组合五：id列是主键，RR隔离级别
+- 组合六：id列是二级唯一索引，RR隔离级别
+- 组合七：id列是二级非唯一索引，RR隔离级别
+- 组合八：id列上没有索引，RR隔离级别
+- 组合九：Serializable隔离级别
+
+
+#### 1.4.2 如何分析解决死锁？
+
+分析解决死锁的步骤如下：
+
+- 模拟死锁场景
+- show engine innodb status;查看死锁日志
+- 找出死锁SQL
+- SQL加锁分析，这个可以去官网看哈
+- 分析死锁日志（持有什么锁，等待什么锁）
+- 熟悉锁模式兼容矩阵，InnoDB存储引擎中锁的兼容性矩阵。
+
+有兴趣的小伙伴，可以看下我之前写的这篇文章：[手把手教你分析Mysql死锁问题](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247487979&idx=1&sn=588c83d77a8851f3b3c18cd68ed9c454&chksm=cf21cec2f85647d4a77cc239ae9a4cfd31bb8832be3d98540a08ea8b4a1f46b38cf736210a02&token=1327808550&lang=zh_CN#rd)
+
+
+### 1.5 主从延迟问题考虑
+
+先插入，接着就去查询,这类代码逻辑比较常见，这可能会有问题的。一般数据库都是有主库，从库的。写入的话是写主库，读一般是读从库。如果发生主从延迟，，很可能出现你插入成功了，但是你查询不到的情况。
+
+
+
+
+#### 1.5.1 要求强一致性，考虑读主库
+
+如果是重要业务，要求强一致性，考虑直接读主库
+
+#### 1.5.2 不要求强一致性，读从库
+
+如果是一般业务，可以接受短暂的数据不一致的话，优先考虑读从库。因为从库可以分担主库的读写压力，提高系统性能。
+
+### 1.6 新老数据兼容
+
+#### 1.6.1 新加的字段，考虑存量数据的默认值
+
+我们日常开发中，随着业务需求变更，经常需要给某个数据库表添加个字段。比如在某个APP配置表，需要添加个场景号字段，如```scene_type```,它的枚举值是 ```01、02、03```，那我们就要跟业务对齐，新添加的字段，老数据是什么默认值，是为空还是默认01，如果是为```NULL```的话，程序代码就要做好空指针处理。
+
+#### 1.6.2 如果新业务用老的字段，考虑老数据的值是否有坑
+
+如果我们开发中，需要沿用数据库表的老字段，并且有存量数据，那就需要考虑老存量数据库的值是否有坑。比如我们表有个user_role_code 的字段，老的数据中，它枚举值是 ``` 01：超级管理员 02：管理员 03：一般用户```。假设业务需求是**一般用户**拆分为**03查询用户和04操作用户**，那我们在开发中，就要考虑老数据的问题啦。
+
+### 1.7 一些SQL的经典注意点
+
+#### 1.7.1 limit大分页问题
+
+limit大分页是一个非常经典的SQL问题，我们一般有这3种对应的解决方案
+
+**方案一：** 如果id是连续的，可以这样，返回上次查询的最大记录(偏移量)，再往下limit
+
+
+```
+select id,name from employee where id>1000000 limit 10.
+```
+
+**方案二:** 在业务允许的情况下限制页数：
+
+建议跟业务讨论，有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。谷歌搜索页也是限制了页数，因此不存在limit大分页问题。
+
+**方案三：** 利用延迟关联或者子查询优化超多分页场景。（先快速定位需要获取的id段，然后再关联）
+
+```
+SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id=b.id
+```
+
+#### 1.7.2 修改、查询数据量多时，考虑分批进行。
+
+我们更新或者查询数据库数据时，尽量避免循环去操作数据库，可以考虑分批进行。比如你要插入10万数据的话，可以一次插入500条
+
+**正例：**
+```
+remoteBatchQuery(param);
+```
+**反例：**
+
+```
+
+for(int i=0;i<100000;i++){
+ remoteSingleQuery(param)
+}
+```
+
+
+## 2. 代码层面篇
+
+
+
+### 2.1 编码细节
+
+
+
+#### 2.1.1 六大典型空指针问题
+
+我们编码的时候，需要注意这六种类型的空指针问题
+
+- 包装类型的空指针问题
+- 级联调用的空指针问题
+- Equals方法左边的空指针问题
+- ConcurrentHashMap 类似容器不支持 k-v为 null。
+- 集合，数组直接获取元素
+- 对象直接获取属性
+
+
+```
+if(object!=null){
+ String name = object.getName();
+}
+```
+
+#### 2.1.2 线程池使用注意点
+
+- 使用 Executors.newFixedThreadPool，可能会出现OOM问题，因为它使用的是无界阻塞队列
+- 建议使用自定义的线程池，最好给线程池一个清晰的命名，方便排查问题
+- 不同的业务，最好做线程池隔离，避免所有的业务公用一个线程池。
+- 线程池异常处理要考虑好
+
+#### 2.1.3 线性安全的集合、类
+
+在高并发场景下，```HashMap```可能会出现死循环。因为它是非线性安全的，可以考虑使用```ConcurrentHashMap```。所以我们使用这些集合的时候，需要注意是不是线性安全的。
+
+- Hashmap、Arraylist、LinkedList、TreeMap等都是线性不安全的；
+- Vector、Hashtable、ConcurrentHashMap等都是线性安全的
+
+#### 2.1.4 日期格式，金额处理精度等
+
+日常开发，经常需要对日期格式化，但是呢，年份设置为YYYY大写的时候，是有坑的哦。
+
+
+```
+Calendar calendar = Calendar.getInstance();
+calendar.set(2019, Calendar.DECEMBER, 31);
+
+Date testDate = calendar.getTime();
+
+SimpleDateFormat dtf = new SimpleDateFormat("YYYY-MM-dd");
+System.out.println("2019-12-31 转 YYYY-MM-dd 格式后 " + dtf.format(testDate));
+```
+运行结果：
+
+```
+2019-12-31 转 YYYY-MM-dd 格式后 2020-12-31
+```
+
+还有金额计算也比较常见，我们要注意精度问题：
+
+
+```
+public class DoubleTest {
+ public static void main(String[] args) {
+ System.out.println(0.1+0.2);
+ System.out.println(1.0-0.8);
+ System.out.println(4.015*100);
+ System.out.println(123.3/100);
+
+ double amount1 = 3.15;
+ double amount2 = 2.10;
+ if (amount1 - amount2 == 1.05){
+ System.out.println("OK");
+ }
+ }
+}
+
+```
+运行结果：
+
+
+```
+0.30000000000000004
+0.19999999999999996
+401.49999999999994
+1.2329999999999999
+```
+
+
+
+#### 2.1.5 大文件处理
+
+
+读取大文件的时候，不要```Files.readAllBytes```直接读到内存，会OOM的，建议使用```BufferedReader ```一行一行来，或者使用```NIO```
+
+
+#### 2.1.6 使用完IO资源流，需要关闭
+
+
+使用try-with-resource，读写完文件，需要关闭流
+
+```
+/*
+ * 关注公众号，捡田螺的小男孩
+ */
+try (FileInputStream inputStream = new FileInputStream(new File("jay.txt")) {
+ // use resources
+} catch (FileNotFoundException e) {
+ log.error(e);
+} catch (IOException e) {
+ log.error(e);
+}
+```
+
+
+#### 2.1.7 try...catch异常使用的一些坑
+
+- 尽量不要使用e.printStackTrace()打印，可能导致字符串常量池内存空间占满
+- catch了异常，使用log把它打印出来
+- 不要用一个Exception捕捉所有可能的异常
+- 不要把捕获异常当做业务逻辑来处理
+
+
+#### 2.1.8 先查询，再更新/删除的并发一致性
+
+
+日常开发中，这种代码实现经常可见：先查询是否有剩余可用的票，再去更新票余量。
+
+
+```
+if(selectIsAvailable(ticketId){
+ 1、deleteTicketById(ticketId)
+ 2、给现金增加操作
+}else{
+ return “没有可用现金券”
+}
+```
+
+如果是并发执行，很可能有问题的，应该利用数据库更新/删除的原子性，正解如下：
+
+```
+if(deleteAvailableTicketById(ticketId) == 1){
+ 1、给现金增加操作
+}else{
+ return “没有可用现金券”
+}
+```
+
+
+### 2.2 提供对外接口
+
+
+
+
+
+#### 2.2.1 校验参数合法性
+
+我们提供对外的接口，不管是提供给客户端、还是前端，又或是别的系统调用，都需要校验一下入参的合法性。
+
+> 如果你的数据库字段设置为varchar(16),对方传了一个32位的字符串过来，你不校验参数长度，插入数据库直接异常了。
+
+
+
+#### 2.2.2 新老接口兼容
+
+很多bug都是因为修改了对外老接口，但是却不做兼容导致的。关键这个问题多数是比较严重的，可能直接导致系统发版失败的。新手程序员很容易犯这个错误哦~
+
+比如我们有个dubbo的分布式接口，本次你修改了入参，就需要考虑新老接口兼容。原本是只接收A，B参数，现在你加了一个参数C，就可以考虑这样处理。
+
+
+```
+//老接口
+void oldService(A,B){
+ //兼容新接口，传个null代替C
+ newService(A,B,null);
+}
+
+//新接口，暂时不能删掉老接口，需要做兼容。
+void newService(A,B,C);
+```
+
+
+
+#### 2.2.3 限流，防止大流量压垮系统
+
+如果瞬间的大流量请求过来，容易压垮系统。所以为了保护我们的系统，一般要做限流处理。可以使用**guava ratelimiter** 组件做限流，也可以用阿里开源的**Sentinel**
+
+#### 2.2.4 接口安全性，加签验签，鉴权
+
+
+我们转账等类型的接口，一定要注意安全性。一定要鉴权，**加签验签**，为用户交易保驾护航。
+
+
+#### 2.2.5 考虑接口幂等性
+
+接口是需要考虑幂等性的，尤其抢红包、转账这些重要接口。最直观的业务场景，就是**用户连着点击两次**，你的接口有没有hold住。
+
+> 1. 幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
+> 2. 在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。
+
+
+一般「幂等技术方案」有这几种:
+
+1. 查询操作
+2. 唯一索引
+3. token机制，防止重复提交
+4. 数据库的delete删除操作
+5. 乐观锁
+6. 悲观锁
+7. Redis、zookeeper 分布式锁（以前抢红包需求，用了Redis分布式锁）
+8. 状态机幂等
+
+
+
+### 2.3 调用第三方接口
+
+
+
+
+#### 2.3.1 超时处理
+
+我们调用别人的接口，如果超时了怎么办呢？
+
+> 举个例子，我们调用一个远程转账接口，A客户给B客户转100万，成功的时候就把本地转账流水置为成功，失败的时候就把本地流水置为失败。如果调用转账系统超时了呢，我们怎么处理呢？置为成功还是失败呢？这个**超时处理可要考虑好**，要不然就资金损失了。这种场景下，调接口超时，我们就可以先**不更新本地转账流水**状态，而是重新发起查询远程转账请求，查询到转账成功的记录，再更新本地状态状态
+
+
+
+#### 2.3.2 考虑重试机制
+
+如果我们调用一个远程http或者dubbo接口，调用失败了，我们可以考虑引入重试机制。有时候网路抖动一下，接口就调失败了，引入重试机制可以提高用户体验。但是这个重试机制需要评估次数，或者有些接口不支持幂等，就不适合重试的。
+
+#### 2.3.3 考虑是否降级处理
+
+
+假设我们系统是一个提供注册的服务：用户注册成功之后，调远程A接口发短信，调远程B接口发邮件，最后更新注册状态为成功。
+
+
+
+
+
+如果调用接口B发邮件失败，那用户就注册失败，业务可能就不会同意了。这时候我们可以考虑给B接口**降级处理**，提供**有损服务**。也就是说，如果调用B接口失败，那先不发邮件，而是先让用户注册成功，后面搞个定时补发邮件就好啦。
+
+#### 2.3.4 考虑是否异步处理
+
+我还是使用上个小节的**用户注册**的例子。我们可以开个异步线程去调A接口发短信，异步调B接口发邮件，那即使A或者B接口调失败，我们还是可以保证用户先注册成功。
+
+把发短信这些通知类接口，放到异步线程处理，可以降低接口耗时，提升用户体验哦。
+
+
+
+
+
+
+#### 2.3.5 调接口异常处理
+
+如果我们调用一个远程接口，一般需要思考以下：如果别人接口异常，我们要怎么处理，怎么兜底，是重试还是当做失败？怎么保证数据的最终一致性等等。
+
+
+## 3. 缓存篇
+
+
+
+### 3.1 数据库与缓存一致性
+
+使用缓存，可以降低耗时，提供系统吞吐性能。但是，使用缓存，会存在数据一致性的问题。
+
+#### 3.1.1 几种缓存使用模式
+
+- Cache-Aside Pattern，旁路缓存模式
+- Read-Through/Write-Through（读写穿透）
+- Write- behind （异步缓存写入）
+
+一般我们使用缓存，都是**旁路缓存模式**，读请求流程如下:
+
+
+
+
+
+- 读的时候，先读缓存，缓存命中的话，直接返回数据
+- 缓存没有命中的话，就去读数据库，从数据库取出数据，放入缓存后，同时返回响应。
+
+旁路缓存模式的写流程：
+
+
+
+#### 3.1.2 删除缓存呢，还是更新缓存？
+
+我们在操作缓存的时候，到底应该删除缓存还是更新缓存呢？我们先来看个例子：
+
+
+
+
+
+1. 线程A先发起一个写操作，第一步先更新数据库
+2. 线程B再发起一个写操作，第二步更新了数据库
+3. 由于网络等原因，线程B先更新了缓存
+4. 线程A更新缓存。
+
+这时候，缓存保存的是A的数据（老数据），数据库保存的是B的数据（新数据），数据不一致了，脏数据出现啦。如果是删除缓存取代更新缓存则不会出现这个脏数据问题。
+
+
+#### 3.1.3 先操作数据库还是先操作缓存
+
+双写的情况下，先操作数据库还是先操作缓存？我们再来看一个例子：假设有A、B两个请求，请求A做更新操作，请求B做查询读取操作。
+
+
+
+1. 线程A发起一个写操作，第一步del cache
+2. 此时线程B发起一个读操作，cache miss
+3. 线程B继续读DB，读出来一个老数据
+4. 然后线程B把老数据设置入cache
+5. 线程A写入DB最新的数据
+
+酱紫就有问题啦，缓存和数据库的数据不一致了。缓存保存的是老数据，数据库保存的是新数据。因此，Cache-Aside缓存模式，选择了先操作数据库而不是先操作缓存。
+
+
+#### 3.1.4 如何保证最终一致性
+
+- 缓存延时双删
+- 删除缓存重试机制
+- 读取biglog异步删除缓存
+
+
+
+### 3.2 缓存穿透
+
+> 缓存穿透：指查询一个一定不存在的数据，由于缓存不命中时，需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。
+
+缓存穿透一般都是这几种情况产生的：**业务不合理的设计、业务/运维/开发失误的操作、黑客非法请求攻击**。
+如何避免缓存穿透呢？ 一般有三种方法。
+
+- 如果是非法请求，我们在API入口，**对参数进行校验**，过滤非法值。
+- 如果查询数据库为空，我们可以**给缓存设置个空值，或者默认值**。但是如有有写请求进来的话，需要更新缓存哈，以保证缓存一致性，同时，最后给缓存设置适当的过期时间。（业务上比较常用，简单有效）
+- 使用**布隆过滤器**快速判断数据是否存在。即一个查询请求过来时，先通过布隆过滤器判断值是否存在，存在才继续往下查。
+
+### 3.3 缓存雪崩
+
+> 缓存雪崩：指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。
+
+- 缓存雪奔一般是由于大量数据同时过期造成的，对于这个原因，可通过**均匀设置过期时间解决，即让过期时间相对离散一点**。如采用一个较大固定值+一个较小的随机值，5小时+0到1800秒酱紫。
+- **Redis 故障宕机也可能引起缓存雪奔**。这就需要构造Redis高可用集群啦。
+
+
+### 3.4 缓存机击穿
+
+> 缓存击穿： 指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。
+
+缓存击穿看着有点像缓存雪崩，其实它两区别是，缓存雪奔是指数据库压力过大甚至down机，缓存击穿只是大量并发请求到了DB数据库层面。可以认为击穿是缓存雪奔的一个子集吧。有些文章认为它俩区别，是在于击穿针对某一热点key缓存，雪奔则是很多key。
+
+
+解决方案就有两种：
+
+1. **使用互斥锁方案**。缓存失效时，不是立即去加载db数据，而是先使用某些带成功返回的原子操作命令，如(Redis的setnx）去操作，成功的时候，再去加载db数据库数据和设置缓存。否则就去重试获取缓存。
+2. **“永不过期”**，是指没有设置过期时间，但是热点数据快要过期时，异步线程去更新和设置过期时间。
+
+
+### 3.5 缓存热Key
+
+在Redis中，我们把访问频率高的key，称为热点key。如果某一热点key的请求到服务器主机时，由于请求量特别大，可能会导致主机资源不足，甚至宕机，从而影响正常的服务。
+
+如何解决热key问题？
+
+- **Redis集群扩容**：增加分片副本，均衡读流量；
+- **对热key进行hash散列**，比如将一个key备份为key1,key2……keyN，同样的数据N个备份，N个备份分布到不同分片，访问时可随机访问N个备份中的一个，进一步分担读流量；
+- **使用二级缓存**，即JVM本地缓存,减少Redis的读请求。
+
+### 3.6 缓存容量内存考虑
+
+#### 3.6.1 评估容量，合理利用
+
+如果我们使用的是Redis，而Redis的内存是比较昂贵的，我们不要什么数据都往Redis里面塞，一般Redis只缓存查询比较频繁的数据。同时，我们要合理评估Redis的容量，也避免频繁set覆盖，导致设置了过期时间的key失效。
+
+如果我们使用的是本地缓存，如guava的本地缓存，也要评估下容量。避免容量不够。
+
+
+#### 3.6.2 Redis的八种内存淘汰机制
+
+为了避免Redis内存不够用，Redis用8种内存淘汰策略保护自己~
+
+> - volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU（最近最少使用）算法进行淘汰；
+> - allkeys-lru：当内存不足以容纳新写入数据时，从所有key中使用LRU（最近最少使用）算法进行淘汰。
+> - volatile-lfu：4.0版本新增，当内存不足以容纳新写入数据时，在过期的key中，使用LFU算法进行删除key。
+> - allkeys-lfu：4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法进行淘汰；
+> - volatile-random：当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据；。
+> - allkeys-random：当内存不足以容纳新写入数据时，从所有key中随机淘汰数据。
+> - volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰；
+> - noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。
+
+#### 3.6.3 不同的业务场景，Redis选择适合的数据结构
+
+- 排行榜适合用zset
+- 缓存用户信息一般用hash
+- 消息队列，文章列表适用用list
+- 用户标签、社交需求一般用set
+- 计数器、分布式锁等一般用String类型
+
+### 3.7 Redis一些有坑的命令
+
+1. 不能使用 keys指令
+2. 慎用O(n)复杂度命令，如hgetall等
+3. 慎用Redis的monitor命令
+4. 禁止使用flushall、flushdb
+5. 注意使用del命令
+
+## 最后
+
+本文总结了60多个减少bug的编码注意点，都是日常开发经典的范例，希望对大家有帮助哈。另外，
+关注公众号：**捡田螺的小男孩**，回复**思维导图**，可以**领取本文的高清思维导图**。
+
+
diff --git "a/\345\267\245\344\275\234\346\200\273\347\273\223/\350\201\212\350\201\212\346\227\245\345\270\270\345\274\200\345\217\221\344\270\255\357\274\214\345\246\202\344\275\225\345\207\217\345\260\221bug\345\221\242\357\274\237.md.bak" "b/\345\267\245\344\275\234\346\200\273\347\273\223/\350\201\212\350\201\212\346\227\245\345\270\270\345\274\200\345\217\221\344\270\255\357\274\214\345\246\202\344\275\225\345\207\217\345\260\221bug\345\221\242\357\274\237.md.bak"
new file mode 100644
index 0000000..e69de29
From 33784b8a311b182ef7ed2c7e3daf01f66be7de14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E6=8D=A1=E7=94=B0=E8=9E=BA=E7=9A=84=E5=B0=8F=E7=94=B7?=
=?UTF-8?q?=E5=AD=A9?= <327658337@qq.com>
Date: Sun, 11 Jul 2021 21:09:56 +0800
Subject: [PATCH 02/51] Add files via upload
---
...\350\256\25615\350\277\236\351\227\256.md" | 395 ++++++++++++++++++
1 file changed, 395 insertions(+)
create mode 100644 "Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234/TCP\345\215\217\350\256\25615\350\277\236\351\227\256.md"
diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234/TCP\345\215\217\350\256\25615\350\277\236\351\227\256.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234/TCP\345\215\217\350\256\25615\350\277\236\351\227\256.md"
new file mode 100644
index 0000000..eae7eec
--- /dev/null
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\350\256\241\347\256\227\346\234\272\347\275\221\347\273\234/TCP\345\215\217\350\256\25615\350\277\236\351\227\256.md"
@@ -0,0 +1,395 @@
+### 鍓嶈█
+
+TCP鍗忚鏄ぇ鍘傞潰璇曞繀闂殑鐭ヨ瘑鐐广傛暣鐞嗕簡15閬撻潪甯哥粡鍏哥殑TCP闈㈣瘯棰橈紝甯屾湜澶у閮芥壘鍒扮悊鎯崇殑offer鍛
+
+
+
+
+
+- 鍏紬鍙凤細**鎹＄敯铻虹殑灏忕敺瀛**
+
+### 1. 璁蹭笅TCP涓夋鎻℃墜娴佺▼
+
+
+
+寮濮嬪鎴风鍜屾湇鍔″櫒閮藉浜嶤LOSED鐘舵侊紝鐒跺悗鏈嶅姟绔紑濮嬬洃鍚煇涓鍙ｏ紝杩涘叆LISTEN鐘舵
+
+- 绗竴娆℃彙鎵(SYN=1, seq=x)锛屽彂閫佸畬姣曞悗锛屽鎴风杩涘叆 SYN_SEND 鐘舵
+- 绗簩娆℃彙鎵(SYN=1, ACK=1, seq=y, ACKnum=x+1)锛 鍙戦佸畬姣曞悗锛屾湇鍔″櫒绔繘鍏 SYN_RCVD 鐘舵併
+- 绗笁娆℃彙鎵(ACK=1锛孉CKnum=y+1)锛屽彂閫佸畬姣曞悗锛屽鎴风杩涘叆 ESTABLISHED 鐘舵侊紝褰撴湇鍔″櫒绔帴鏀跺埌杩欎釜鍖呮椂,涔熻繘鍏 ESTABLISHED 鐘舵侊紝TCP 鎻℃墜锛屽嵆鍙互寮濮嬫暟鎹紶杈撱
+
+### 2.TCP鎻℃墜涓轰粈涔堟槸涓夋锛屼笉鑳芥槸涓ゆ锛熶笉鑳芥槸鍥涙锛
+
+TCP鎻℃墜涓轰粈涔堟槸涓夋鍛紵涓轰簡鏂逛究鐞嗚В锛屾垜浠互璋堟亱鐖变负渚嬪瓙锛氫袱涓汉鑳借蛋鍒颁竴璧凤紝鏈閲嶈鐨勪簨鎯呭氨鏄浉鐖憋紝灏辨槸**鎴戠埍浣狅紝骞朵笖鎴戠煡閬擄紝浣犱篃鐖辨垜**锛屾帴涓嬫潵鎴戜滑浠ユ鏉ユā鎷熶笁娆℃彙鎵嬬殑杩囩▼锛
+
+
+
+
+
+**涓轰粈涔堟彙鎵嬩笉鑳芥槸涓ゆ鍛紵**
+
+濡傛灉鍙湁涓ゆ鎻℃墜锛屽コ瀛╁瓙鍙兘灏变笉鐭ラ亾锛屽ス鐨勯偅鍙**鎴戜篃鐖变綘**锛岀敺瀛╁瓙鏄惁**鏀跺埌**锛屾亱鐖卞叧绯诲氨涓嶈兘鎰夊揩灞曞紑銆
+
+**涓轰粈涔堟彙鎵嬩笉鑳芥槸鍥涙鍛紵**
+
+鍥犱负鎻℃墜涓嶈兘鏄洓娆″憿锛熷洜涓轰笁娆″凡缁忓浜嗭紝涓夋宸茬粡鑳借鍙屾柟閮界煡閬擄細浣犵埍鎴戯紝鎴戜篃鐖变綘銆傝屽洓娆″氨澶氫綑浜嗐
+
+### 3. 璁蹭笅TCP鍥涙鎸ユ墜杩囩▼
+
+
+
+1. 绗竴娆℃尌鎵(FIN=1锛宻eq=u)锛屽彂閫佸畬姣曞悗锛屽鎴风杩涘叆FIN_WAIT_1 鐘舵
+2. 绗簩娆℃尌鎵(ACK=1锛宎ck=u+1,seq =v)锛屽彂閫佸畬姣曞悗锛屾湇鍔″櫒绔繘鍏LOSE_WAIT 鐘舵侊紝瀹㈡埛绔帴鏀跺埌杩欎釜纭鍖呬箣鍚庯紝杩涘叆 FIN_WAIT_2 鐘舵
+3. 绗笁娆℃尌鎵(FIN=1锛孉CK1,seq=w,ack=u+1)锛屽彂閫佸畬姣曞悗锛屾湇鍔″櫒绔繘鍏AST_ACK 鐘舵侊紝绛夊緟鏉ヨ嚜瀹㈡埛绔殑鏈鍚庝竴涓狝CK銆
+4. 绗洓娆℃尌鎵(ACK=1锛宻eq=u+1,ack=w+1)锛屽鎴风鎺ユ敹鍒版潵鑷湇鍔″櫒绔殑鍏抽棴璇锋眰锛屽彂閫佷竴涓‘璁ゅ寘锛屽苟杩涘叆 TIME_WAIT鐘舵侊紝**绛夊緟浜嗘煇涓浐瀹氭椂闂达紙涓や釜鏈澶ф鐢熷懡鍛ㄦ湡锛2MSL锛2 Maximum Segment Lifetime锛変箣鍚**锛屾病鏈夋敹鍒版湇鍔″櫒绔殑 ACK 锛岃涓烘湇鍔″櫒绔凡缁忔甯稿叧闂繛鎺ワ紝浜庢槸鑷繁涔熷叧闂繛鎺ワ紝杩涘叆 CLOSED 鐘舵併傛湇鍔″櫒绔帴鏀跺埌杩欎釜纭鍖呬箣鍚庯紝鍏抽棴杩炴帴锛岃繘鍏 CLOSED 鐘舵併
+
+### 4. TCP鎸ユ墜涓轰粈涔堥渶瑕佸洓娆″憿锛
+
+涓句釜渚嬪瓙鍚!
+
+> 灏忔槑鍜屽皬绾㈡墦鐢佃瘽鑱婂ぉ锛岄氳瘽宸笉澶氳缁撴潫鏃讹紝灏忕孩璇粹滄垜娌″暐瑕佽鐨勪簡鈥濓紝灏忔槑鍥炵瓟鈥滄垜鐭ラ亾浜嗏濄備絾鏄皬鏄庡彲鑳借繕浼氭湁瑕佽鐨勮瘽锛屽皬绾笉鑳借姹傚皬鏄庤窡鐫鑷繁鐨勮妭濂忕粨鏉熼氳瘽锛屼簬鏄皬鏄庡彲鑳藉張鍙藉徑姝璇翠簡涓閫氾紝鏈鍚庡皬鏄庤鈥滄垜璇村畬浜嗏濓紝灏忕孩鍥炵瓟鈥滅煡閬撲簡鈥濓紝杩欐牱閫氳瘽鎵嶇畻缁撴潫銆
+
+
+
+### 5. TIME-WAIT 鐘舵佷负浠涔堥渶瑕佺瓑寰 2MSL
+
+
+
+2MSL锛2 Maximum Segment Lifetime锛屽嵆涓や釜鏈澶ф鐢熷懡鍛ㄦ湡
+
+> - 1涓 MSL 淇濊瘉鍥涙鎸ユ墜涓富鍔ㄥ叧闂柟鏈鍚庣殑 ACK 鎶ユ枃鑳芥渶缁堝埌杈惧绔
+> - 1涓 MSL 淇濊瘉瀵圭娌℃湁鏀跺埌 ACK 閭ｄ箞杩涜閲嶄紶鐨 FIN 鎶ユ枃鑳藉鍒拌揪
+
+### 6.TCP 鍜 UDP 鐨勫尯鍒
+
+1. TCP闈㈠悜杩炴帴锛堬紙濡傛墦鐢佃瘽瑕佸厛鎷ㄥ彿寤虹珛杩炴帴锛;UDP鏄棤杩炴帴鐨勶紝鍗冲彂閫佹暟鎹箣鍓嶄笉闇瑕佸缓绔嬭繛鎺ャ
+2. TCP瑕佹眰瀹夊叏鎬э紝鎻愪緵鍙潬鐨勬湇鍔★紝閫氳繃TCP杩炴帴浼犻佺殑鏁版嵁锛屼笉涓㈠け銆佷笉閲嶅銆佸畨鍏ㄥ彲闈犮傝孶DP灏芥渶澶у姫鍔涗氦浠橈紝鍗充笉淇濊瘉鍙潬浜や粯銆
+3. TCP鏄偣瀵圭偣杩炴帴鐨勶紝UDP涓瀵逛竴锛屼竴瀵瑰锛屽瀵瑰閮藉彲浠
+4. TCP浼犺緭鏁堢巼鐩稿杈冧綆,鑰孶DP浼犺緭鏁堢巼楂橈紝瀹冮傜敤浜庡楂橀熶紶杈撳拰瀹炴椂鎬ф湁杈冮珮鐨勯氫俊鎴栧箍鎾氫俊銆
+5. TCP閫傚悎鐢ㄤ簬缃戦〉锛岄偖浠剁瓑;UDP閫傚悎鐢ㄤ簬瑙嗛锛岃闊冲箍鎾瓑
+6. TCP闈㈠悜瀛楄妭娴侊紝UDP闈㈠悜鎶ユ枃
+
+### 7. TCP鎶ユ枃棣栭儴鏈夊摢浜涘瓧娈碉紝璇磋鍏朵綔鐢
+
+
+
+
+- **16浣嶇鍙ｅ彿**锛氭簮绔彛鍙凤紝涓绘満璇ユ姤鏂囨鏄潵鑷摢閲岋紱鐩爣绔彛鍙凤紝瑕佷紶缁欏摢涓笂灞傚崗璁垨搴旂敤绋嬪簭
+- **32浣嶅簭鍙**锛氫竴娆CP閫氫俊锛堜粠TCP杩炴帴寤虹珛鍒版柇寮锛夎繃绋嬩腑鏌愪竴涓紶杈撴柟鍚戜笂鐨勫瓧鑺傛祦鐨勬瘡涓瓧鑺傜殑缂栧彿銆
+- **32浣嶇‘璁ゅ彿**锛氱敤浣滃鍙︿竴鏂瑰彂閫佺殑tcp鎶ユ枃娈电殑鍝嶅簲銆傚叾鍊兼槸鏀跺埌鐨凾CP鎶ユ枃娈电殑搴忓彿鍊煎姞1銆
+- **4浣嶅ご閮ㄩ暱搴**锛氳〃绀簍cp澶撮儴鏈夊灏戜釜32bit瀛楋紙4瀛楄妭锛夈傚洜涓4浣嶆渶澶ц兘鏍囪瘑15锛屾墍浠CP澶撮儴鏈闀挎槸60瀛楄妭銆
+- **6浣嶆爣蹇椾綅**锛歎RG(绱фユ寚閽堟槸鍚︽湁鏁)锛孉Ck锛堣〃绀虹‘璁ゅ彿鏄惁鏈夋晥锛夛紝PSH锛堢紦鍐插尯灏氭湭濉弧锛夛紝RST锛堣〃绀鸿姹傚鏂归噸鏂板缓绔嬭繛鎺ワ級锛孲YN锛堝缓绔嬭繛鎺ユ秷鎭爣蹇楁帴锛夛紝FIN锛堣〃绀哄憡鐭ュ鏂规湰绔鍏抽棴杩炴帴浜嗭級
+- **16浣嶇獥鍙ｅぇ灏**锛氭槸TCP娴侀噺鎺у埗鐨勪竴涓墜娈点傝繖閲岃鐨勭獥鍙ｏ紝鎸囩殑鏄帴鏀堕氬憡绐楀彛銆傚畠鍛婅瘔瀵规柟鏈鐨凾CP鎺ユ敹缂撳啿鍖鸿繕鑳藉绾冲灏戝瓧鑺傜殑鏁版嵁锛岃繖鏍峰鏂瑰氨鍙互鎺у埗鍙戦佹暟鎹殑閫熷害銆
+- **16浣嶆牎楠屽拰**锛氱敱鍙戦佺濉厖锛屾帴鏀剁瀵筎CP鎶ユ枃娈垫墽琛孋RC绠楁硶浠ユ楠孴CP鎶ユ枃娈靛湪浼犺緭杩囩▼涓槸鍚︽崯鍧忋傛敞鎰忥紝杩欎釜鏍￠獙涓嶄粎鍖呮嫭TCP澶撮儴锛屼篃鍖呮嫭鏁版嵁閮ㄥ垎銆傝繖涔熸槸TCP鍙潬浼犺緭鐨勪竴涓噸瑕佷繚闅溿
+- **16浣嶇揣鎬ユ寚閽**锛氫竴涓鐨勫亸绉婚噺銆傚畠鍜屽簭鍙峰瓧娈电殑鍊肩浉鍔犺〃绀烘渶鍚庝竴涓揣鎬ユ暟鎹殑涓嬩竴瀛楄妭鐨勫簭鍙枫傚洜姝わ紝纭垏鍦拌锛岃繖涓瓧娈垫槸绱фユ寚閽堢浉瀵瑰綋鍓嶅簭鍙风殑鍋忕Щ锛屼笉濡ㄧО涔嬩负绱фュ亸绉汇俆CP鐨勭揣鎬ユ寚閽堟槸鍙戦佺鍚戞帴鏀剁鍙戦佺揣鎬ユ暟鎹殑鏂规硶銆
+
+### 8. TCP 鏄浣曚繚璇佸彲闈犳х殑
+
+
+
+
+
+- 棣栧厛锛孴CP鐨勮繛鎺ユ槸鍩轰簬**涓夋鎻℃墜**锛岃屾柇寮鍒欐槸**鍥涙鎸ユ墜**銆傜‘淇濊繛鎺ュ拰鏂紑鐨勫彲闈犳с
+- 鍏舵锛孴CP鐨勫彲闈犳э紝杩樹綋鐜板湪**鏈夌姸鎬**;TCP浼氳褰曞摢浜涙暟鎹彂閫佷簡锛屽摢浜涙暟鎹鎺ュ彈浜嗭紝鍝簺娌℃湁琚帴鍙楋紝骞朵笖淇濊瘉鏁版嵁鍖呮寜搴忓埌杈撅紝淇濊瘉鏁版嵁浼犺緭涓嶅嚭宸敊銆
+- 鍐嶆锛孴CP鐨勫彲闈犳э紝杩樹綋鐜板湪**鍙帶鍒**銆傚畠鏈夋姤鏂囨牎楠屻丄CK搴旂瓟銆**瓒呮椂閲嶄紶(鍙戦佹柟)**銆佸け搴忔暟鎹噸浼狅紙鎺ユ敹鏂癸級銆佷涪寮冮噸澶嶆暟鎹佹祦閲忔帶鍒讹紙婊戝姩绐楀彛锛夊拰鎷ュ鎺у埗绛夋満鍒躲
+
+### 9. TCP 閲嶄紶鏈哄埗
+
+#### 瓒呮椂閲嶄紶
+TCP 涓轰簡瀹炵幇鍙潬浼犺緭锛屽疄鐜颁簡閲嶄紶鏈哄埗銆傛渶鍩烘湰鐨勯噸浼犳満鍒讹紝灏辨槸**瓒呮椂閲嶄紶**锛屽嵆鍦ㄥ彂閫佹暟鎹姤鏂囨椂锛岃瀹氫竴涓畾鏃跺櫒锛屾瘡闂撮殧涓娈垫椂闂达紝娌℃湁鏀跺埌瀵规柟鐨凙CK纭搴旂瓟鎶ユ枃锛屽氨浼氶噸鍙戣鎶ユ枃銆
+
+杩欎釜闂撮殧鏃堕棿锛屼竴鑸缃负澶氬皯鍛紵鎴戜滑鍏堟潵鐪嬩笅浠涔堝彨**RTT锛圧ound-Trip Time锛屽線杩旀椂闂达級**銆
+
+
+
+RTT灏辨槸锛屼竴涓暟鎹寘浠庡彂鍑哄幓鍒板洖鏉ョ殑鏃堕棿锛屽嵆**鏁版嵁鍖呯殑涓娆″線杩旀椂闂**銆傝秴鏃堕噸浼犳椂闂达紝灏辨槸Retransmission Timeout 锛岀畝绉**RTO**銆
+
+**RTO璁剧疆澶氫箙鍛紵**
+- 濡傛灉RTO姣旇緝灏忥紝閭ｅ緢鍙兘鏁版嵁閮芥病鏈変涪澶憋紝灏遍噸鍙戜簡锛岃繖浼氬鑷寸綉缁滈樆濉烇紝浼氬鑷存洿澶氱殑瓒呮椂鍑虹幇銆
+- 濡傛灉RTO姣旇緝澶э紝绛夊埌鑺卞効閮借阿浜嗚繕鏄病鏈夐噸鍙戯紝閭ｆ晥鏋滃氨涓嶅ソ浜嗐
+
+涓鑸儏鍐典笅锛孯TO鐣ュぇ浜嶳TT锛屾晥鏋滄槸鏈濂界殑銆備竴浜涘皬浼欎即浼氶棶锛岃秴鏃舵椂闂存湁娌℃湁璁＄畻鍏紡鍛?鏈夌殑锛佹湁涓爣鍑嗘柟娉曠畻RTO鐨勫叕寮忥紝涔熷彨**Jacobson / Karels 绠楁硶**銆傛垜浠竴璧锋潵鐪嬩笅璁＄畻RTO鐨勫叕寮
+
+**1. 鍏堣绠桽RTT锛堣绠楀钩婊戠殑RTT锛**
+
+```
+SRTT = (1 - 伪) * SRTT + 伪 * RTT //姹 SRTT 鐨勫姞鏉冨钩鍧
+```
+
+**2. 鍐嶈绠桼TTVAR (round-trip time variation)**
+
+
+```
+RTTVAR = (1 - 尾) * RTTVAR + 尾 * (|RTT - SRTT|) //璁＄畻 SRTT 涓庣湡瀹炲肩殑宸窛
+```
+
+**3. 鏈缁堢殑RTO**
+
+```
+RTO = 碌 * SRTT + 鈭 * RTTVAR = SRTT + 4路RTTVAR
+```
+
+鍏朵腑锛宍``伪 = 0.125锛屛 = 0.25锛 渭 = 1锛屸垈 = 4```锛岃繖浜涘弬鏁伴兘鏄ぇ閲忕粨鏋滃緱鍑虹殑鏈浼樺弬鏁般
+
+浣嗘槸锛岃秴鏃堕噸浼犱細鏈夎繖浜涚己鐐癸細
+> - 褰撲竴涓姤鏂囨涓㈠け鏃讹紝浼氱瓑寰呬竴瀹氱殑瓒呮椂鍛ㄦ湡鐒跺悗鎵嶉噸浼犲垎缁勶紝澧炲姞浜嗙鍒扮鐨勬椂寤躲
+> - 褰撲竴涓姤鏂囨涓㈠け鏃讹紝鍦ㄥ叾绛夊緟瓒呮椂鐨勮繃绋嬩腑锛屽彲鑳戒細鍑虹幇杩欑鎯呭喌锛氬叾鍚庣殑鎶ユ枃娈靛凡缁忚鎺ユ敹绔帴鏀朵絾鍗磋繜杩熷緱涓嶅埌纭锛屽彂閫佺浼氳涓轰篃涓㈠け浜嗭紝浠庤屽紩璧蜂笉蹇呰鐨勯噸浼狅紝鏃㈡氮璐硅祫婧愪篃娴垂鏃堕棿銆
+
+骞朵笖锛孴CP鏈変釜绛栫暐锛屽氨鏄秴鏃舵椂闂撮棿闅斾細鍔犲嶃傝秴鏃堕噸浼犻渶瑕**绛夊緟寰堥暱鏃堕棿**銆傚洜姝わ紝杩樺彲浠ヤ娇鐢**蹇熼噸浼**鏈哄埗銆
+
+#### 蹇熼噸浼
+
+**蹇熼噸浼**鏈哄埗锛屽畠涓嶄互鏃堕棿椹卞姩锛岃屾槸浠ユ暟鎹┍鍔ㄣ傚畠鍩轰簬鎺ユ敹绔殑鍙嶉淇℃伅鏉ュ紩鍙戦噸浼犮
+
+涓璧锋潵鐪嬩笅蹇熼噸浼犳祦绋嬶細
+
+
+
+濡備笂鍥句腑锛屽彂閫佺鏀跺埌浜嗕笁娆″悓鏍风殑ACK=30鐨勭‘璁ゆ姤鏂囷紝浜庢槸灏变細瑙﹀彂蹇熼噸鍙戞満鍒讹紝閫氳繃SACK淇℃伅鍙戠幇鍙湁```30~39```杩欐鏁版嵁涓㈠け锛屼簬鏄噸鍙戞椂灏卞彧閫夋嫨浜嗚繖涓猔``30~39```鐨凾CP鎶ユ枃娈佃繘琛岄噸鍙戙
+
+#### D-SACK
+
+ D-SACK锛屽嵆Duplicate SACK锛堥噸澶峉ACK锛夛紝鍦⊿ACK鐨勫熀纭涓婂仛浜嗕竴浜涙墿灞曪紝锛屼富瑕佺敤鏉ュ憡璇夊彂閫佹柟锛屾湁鍝簺鏁版嵁鍖呰嚜宸遍噸澶嶆帴鍙椾簡銆侱SACK鐨勭洰鐨勬槸甯姪鍙戦佹柟鍒ゆ柇锛屾槸鍚﹀彂鐢熶簡鍖呭け搴忋丄CK涓㈠け銆佸寘閲嶅鎴栦吉閲嶄紶銆傝TCP鍙互鏇村ソ鐨勫仛缃戠粶娴佹帶銆傛潵鐪嬩釜鍥惧惂锛
+
+
+
+- 铏氱嚎鐭╁舰妗嗭紝灏辨槸鍙戦佺獥鍙ｃ
+- SND.WND: 琛ㄧず鍙戦佺獥鍙ｇ殑澶у皬,涓婂浘铏氱嚎妗嗙殑鏍煎瓙鏁板氨鏄14涓
+- SND.UNA: 涓涓粷瀵规寚閽堬紝瀹冩寚鍚戠殑鏄凡鍙戦佷絾鏈‘璁ょ殑绗竴涓瓧鑺傜殑搴忓垪鍙枫
+- SND.NXT锛氫笅涓涓彂閫佺殑浣嶇疆锛屽畠鎸囧悜鏈彂閫佷絾鍙互鍙戦佺殑绗竴涓瓧鑺傜殑搴忓垪鍙枫
+
+鎺ユ敹鏂圭殑婊戝姩绐楀彛鍖呭惈涓夊ぇ閮ㄥ垎锛屽涓嬶細
+- 宸叉垚鍔熸帴鏀跺苟纭
+- 鏈敹鍒版暟鎹絾鍙互鎺ユ敹
+- 鏈敹鍒版暟鎹苟涓嶅彲浠ユ帴鏀剁殑鏁版嵁
+
+
+
+- 铏氱嚎鐭╁舰妗嗭紝灏辨槸鎺ユ敹绐楀彛銆
+- REV.WND: 琛ㄧず鎺ユ敹绐楀彛鐨勫ぇ灏,涓婂浘铏氱嚎妗嗙殑鏍煎瓙灏辨槸9涓
+- REV.NXT:涓嬩竴涓帴鏀剁殑浣嶇疆锛屽畠鎸囧悜鏈敹鍒颁絾鍙互鎺ユ敹鐨勭涓涓瓧鑺傜殑搴忓垪鍙枫
+
+### 11. 鑱婅亰TCP鐨勬祦閲忔帶鍒
+
+TCP涓夋鎻℃墜锛屽彂閫佺鍜屾帴鏀剁杩涘叆鍒癊STABLISHED鐘舵侊紝瀹冧滑鍗冲彲浠ユ剦蹇湴浼犺緭鏁版嵁鍟︺
+
+浣嗘槸鍙戦佺涓嶈兘鐤媯鍦板悜鎺ユ敹绔彂閫佹暟鎹紝鍥犱负鎺ユ敹绔帴鏀朵笉杩囨潵鐨勮瘽锛屾帴鏀舵柟鍙兘鎶婂鐞嗕笉杩囨潵鐨勬暟鎹瓨鍦ㄧ紦瀛樺尯閲屻傚鏋滅紦瀛樺尯閮芥弧浜嗭紝鍙戦佹柟杩樺湪鐤媯鍙戦佹暟鎹殑璇濓紝鎺ユ敹鏂瑰彧鑳芥妸鏀跺埌鐨勬暟鎹寘涓㈡帀锛岃繖灏辨氮璐逛簡缃戠粶璧勬簮鍟︺
+
+> TCP 鎻愪緵涓绉嶆満鍒跺彲浠ヨ鍙戦佺鏍规嵁鎺ユ敹绔殑瀹為檯鎺ユ敹鑳藉姏鎺у埗鍙戦佺殑鏁版嵁閲忥紝杩欏氨鏄**娴侀噺鎺у埗**銆
+
+TCP閫氳繃婊戝姩绐楀彛鏉ユ帶鍒舵祦閲忥紝鎴戜滑鐪嬩笅娴侀噺鎺у埗鐨**绠瑕佹祦绋**鍚э細
+
+棣栧厛鍙屾柟涓夋鎻℃墜锛屽垵濮嬪寲鍚勮嚜鐨勭獥鍙ｅぇ灏忥紝鍧囦负 400 涓瓧鑺傘
+
+
+
+
+鍙戦佹柟缁存姢涓涓**鎷ュ绐楀彛cwnd锛坈ongestion window锛** 鐨勫彉閲忥紝鐢ㄦ潵浼扮畻鍦ㄤ竴娈垫椂闂村唴杩欐潯閾捐矾锛堟按绠★級鍙互鎵胯浇鍜岃繍杈撶殑鏁版嵁锛堟按锛夌殑鏁伴噺銆傚畠澶у皬浠ｈ〃鐫缃戠粶鐨勬嫢濉炵▼搴︼紝骞朵笖鏄姩鎬佸彉鍖栫殑锛屼絾鏄负浜嗚揪鍒版渶澶х殑浼犺緭鏁堢巼锛屾垜浠濡備綍鐭ラ亾杩欐潯姘寸鐨勮繍閫佹晥鐜囨槸澶氬皯鍛紵
+
+涓涓瘮杈冪畝鍗曠殑鏂规硶灏辨槸涓嶆柇澧炲姞浼犺緭鐨勬按閲忥紝鐩村埌姘寸蹇鐖嗚涓烘锛堝搴斿埌缃戠粶涓婂氨鏄彂鐢熶涪鍖咃級锛岀敤 TCP 鐨勬弿杩板氨鏄細
+> 鍙缃戠粶涓病鏈夊嚭鐜版嫢濉烇紝鎷ュ绐楀彛鐨勫煎氨鍙互鍐嶅澶т竴浜涳紝浠ヤ究鎶婃洿澶氱殑鏁版嵁鍖呭彂閫佸嚭鍘伙紝浣嗗彧瑕佺綉缁滃嚭鐜版嫢濉烇紝鎷ュ绐楀彛鐨勫煎氨搴旇鍑忓皬涓浜涳紝浠ュ噺灏戞敞鍏ュ埌缃戠粶涓殑鏁版嵁鍖呮暟銆
+
+瀹為檯涓婏紝鎷ュ鎺у埗涓昏鏈夎繖鍑犵甯哥敤绠楁硶
+- 鎱㈠惎鍔
+- 鎷ュ閬垮厤
+- 鎷ュ鍙戠敓
+- 蹇熸仮澶
+
+#### 鎱㈠惎鍔ㄧ畻娉
+
+鎱㈠惎鍔ㄧ畻娉曪紝琛ㄩ潰鎰忔濆氨鏄紝鍒ユ參鎱㈡潵銆傚畠琛ㄧずTCP寤虹珛杩炴帴瀹屾垚鍚庯紝涓寮濮嬩笉瑕佸彂閫佸ぇ閲忕殑鏁版嵁锛岃屾槸鍏堟帰娴嬩竴涓嬬綉缁滅殑鎷ュ绋嬪害銆傜敱灏忓埌澶ч愭笎澧炲姞鎷ュ绐楀彛鐨勫ぇ灏忥紝濡傛灉娌℃湁鍑虹幇涓㈠寘锛**姣忔敹鍒颁竴涓狝CK锛屽氨灏嗘嫢濉炵獥鍙wnd澶у皬灏卞姞1锛堝崟浣嶆槸MSS锛**銆**姣忚疆娆**鍙戦佺獥鍙ｅ鍔犱竴鍊嶏紝鍛堟寚鏁板闀匡紝濡傛灉鍑虹幇涓㈠寘锛屾嫢濉炵獥鍙ｅ氨鍑忓崐锛岃繘鍏ユ嫢濉為伩鍏嶉樁娈点
+
+- TCP杩炴帴瀹屾垚锛屽垵濮嬪寲cwnd = 1锛岃〃鏄庡彲浠ヤ紶涓涓狹SS鍗曚綅澶у皬鐨勬暟鎹
+- 姣忓綋鏀跺埌涓涓狝CK锛宑wnd灏卞姞涓;
+- 姣忓綋杩囦簡涓涓猂TT锛宑wnd灏卞鍔犱竴鍊; 鍛堟寚鏁拌鍗
+
+
+
+涓轰簡闃叉cwnd澧為暱杩囧ぇ寮曡捣缃戠粶鎷ュ锛岃繕闇璁剧疆涓涓**鎱㈠惎鍔ㄩ榾鍊約sthresh**锛坰low start threshold锛夌姸鎬佸彉閲忋傚綋```cwnd```鍒拌揪璇ラ榾鍊煎悗锛屽氨濂藉儚姘寸琚叧灏忎簡姘撮緳澶翠竴鏍凤紝鍑忓皯鎷ュ鐘舵併傚嵆褰**cwnd >ssthresh**鏃讹紝杩涘叆浜**鎷ュ閬垮厤**绠楁硶銆
+
+
+#### 鎷ュ閬垮厤绠楁硶
+
+涓鑸潵璇达紝鎱㈠惎鍔ㄩ榾鍊約sthresh鏄65535瀛楄妭锛宍``cwnd```鍒拌揪**鎱㈠惎鍔ㄩ榾鍊**鍚
+- 姣忔敹鍒颁竴涓狝CK鏃讹紝cwnd = cwnd + 1/cwnd
+- 褰撴瘡杩囦竴涓猂TT鏃讹紝cwnd = cwnd + 1
+
+鏄剧劧杩欐槸涓涓嚎鎬т笂鍗囩殑绠楁硶锛岄伩鍏嶈繃蹇鑷寸綉缁滄嫢濉為棶棰樸
+
+
+
+#### 鎷ュ鍙戠敓
+
+褰撶綉缁滄嫢濉炲彂鐢**涓㈠寘**鏃讹紝浼氭湁涓ょ鎯呭喌锛
+
+- RTO瓒呮椂閲嶄紶
+- 蹇熼噸浼
+
+濡傛灉鏄彂鐢熶簡**RTO瓒呮椂閲嶄紶**锛屽氨浼氫娇鐢ㄦ嫢濉炲彂鐢熺畻娉
+
+- 鎱㈠惎鍔ㄩ榾鍊約shthresh = cwnd /2
+- cwnd 閲嶇疆涓 1
+- 杩涘叆鏂扮殑鎱㈠惎鍔ㄨ繃绋
+
+
+
+
+杩欑湡鐨勬槸**杈涜緵鑻﹁嫤鍑犲崄骞达紝涓鏈濆洖鍒拌В鏀惧墠**銆傚叾瀹炶繕鏈夋洿濂界殑澶勭悊鏂瑰紡锛屽氨鏄**蹇熼噸浼**銆傚彂閫佹柟鏀跺埌3涓繛缁噸澶嶇殑ACK鏃讹紝灏变細蹇熷湴閲嶄紶锛屼笉蹇呯瓑寰**RTO瓒呮椂**鍐嶉噸浼犮
+
+
+
+鎱㈠惎鍔ㄩ榾鍊約sthresh 鍜 cwnd 鍙樺寲濡備笅锛
+
+- 鎷ュ绐楀彛澶у皬 cwnd = cwnd/2
+- 鎱㈠惎鍔ㄩ榾鍊 ssthresh = cwnd
+- 杩涘叆蹇熸仮澶嶇畻娉
+
+#### 蹇熸仮澶
+
+蹇熼噸浼犲拰蹇熸仮澶嶇畻娉曚竴鑸悓鏃朵娇鐢ㄣ傚揩閫熸仮澶嶇畻娉曡涓猴紝杩樻湁3涓噸澶岮CK鏀跺埌锛岃鏄庣綉缁滀篃娌￠偅涔堢碂绯曪紝鎵浠ユ病鏈夊繀瑕佸儚RTO瓒呮椂閭ｄ箞寮虹儓銆
+
+姝ｅ鍓嶉潰鎵璇达紝杩涘叆蹇熸仮澶嶄箣鍓嶏紝cwnd 鍜 sshthresh宸茶鏇存柊锛
+```
+- cwnd = cwnd /2
+- sshthresh = cwnd
+```
+
+鐒跺悗锛岀湡姝ｇ殑蹇熺畻娉曞涓嬶細
+
+- cwnd = sshthresh + 3
+- 閲嶄紶閲嶅鐨勯偅鍑犱釜ACK锛堝嵆涓㈠け鐨勯偅鍑犱釜鏁版嵁鍖咃級
+- 濡傛灉鍐嶆敹鍒伴噸澶嶇殑 ACK锛岄偅涔 cwnd = cwnd +1
+- 濡傛灉鏀跺埌鏂版暟鎹殑 ACK 鍚, cwnd = sshthresh銆傚洜涓烘敹鍒版柊鏁版嵁鐨 ACK锛岃〃鏄庢仮澶嶈繃绋嬪凡缁忕粨鏉燂紝鍙互鍐嶆杩涘叆浜嗘嫢濉為伩鍏嶇殑绠楁硶浜嗐
+
+
+
+### 13. 鍗婅繛鎺ラ槦鍒楀拰 SYN Flood 鏀诲嚮鐨勫叧绯
+
+TCP杩涘叆涓夋鎻℃墜鍓嶏紝鏈嶅姟绔細浠**CLOSED**鐘舵佸彉涓**LISTEN**鐘舵,鍚屾椂鍦ㄥ唴閮ㄥ垱寤轰簡涓や釜闃熷垪锛氬崐杩炴帴闃熷垪锛圫YN闃熷垪锛夊拰鍏ㄨ繛鎺ラ槦鍒楋紙ACCEPT闃熷垪锛夈
+
+浠涔堟槸**鍗婅繛鎺ラ槦鍒楋紙SYN闃熷垪锛** 鍛? 浠涔堟槸**鍏ㄨ繛鎺ラ槦鍒楋紙ACCEPT闃熷垪锛** 鍛紵鍥炲繂涓婽CP涓夋鎻℃墜鐨勫浘锛
+
+
+
+- TCP涓夋鎻℃墜鏃讹紝瀹㈡埛绔彂閫丼YN鍒版湇鍔＄锛屾湇鍔＄鏀跺埌涔嬪悗锛屼究鍥炲**ACK鍜孲YN**锛岀姸鎬佺敱**LISTEN鍙樹负SYN_RCVD**锛屾鏃惰繖涓繛鎺ュ氨琚帹鍏ヤ簡**SYN闃熷垪**锛屽嵆鍗婅繛鎺ラ槦鍒椼
+- 褰撳鎴风鍥炲ACK, 鏈嶅姟绔帴鏀跺悗锛屼笁娆℃彙鎵嬪氨瀹屾垚浜嗐傝繖鏃惰繛鎺ヤ細绛夊緟琚叿浣撶殑搴旂敤鍙栬蛋锛屽湪琚彇璧颁箣鍓嶏紝瀹冭鎺ㄥ叆ACCEPT闃熷垪锛屽嵆鍏ㄨ繛鎺ラ槦鍒椼
+
+SYN Flood鏄竴绉嶅吀鍨嬬殑DoS (Denial of Service锛屾嫆缁濇湇鍔) 鏀诲嚮锛屽畠鍦ㄧ煭鏃堕棿鍐咃紝浼**涓嶅瓨鍦ㄧ殑IP鍦板潃**,鍚戞湇鍔″櫒澶ч噺鍙戣捣SYN鎶ユ枃銆傚綋鏈嶅姟鍣ㄥ洖澶峉YN+ACK鎶ユ枃鍚庯紝涓嶄細鏀跺埌ACK鍥炲簲鎶ユ枃锛屽鑷存湇鍔″櫒涓婂缓绔嬪ぇ閲忕殑鍗婅繛鎺ュ崐杩炴帴闃熷垪婊′簡锛岃繖灏辨棤娉曞鐞嗘甯哥殑TCP璇锋眰鍟︺
+
+涓昏鏈 **syn cookie**鍜**SYN Proxy闃茬伀澧**绛夋柟妗堝簲瀵广
+
+- **syn cookie**锛氬湪鏀跺埌SYN鍖呭悗锛屾湇鍔″櫒鏍规嵁涓瀹氱殑鏂规硶锛屼互鏁版嵁鍖呯殑婧愬湴鍧銆佺鍙ｇ瓑淇℃伅涓哄弬鏁拌绠楀嚭涓涓猚ookie鍊间綔涓鸿嚜宸辩殑SYNACK鍖呯殑搴忓垪鍙凤紝鍥炲SYN+ACK鍚庯紝鏈嶅姟鍣ㄥ苟涓嶇珛鍗冲垎閰嶈祫婧愯繘琛屽鐞嗭紝绛夋敹鍒板彂閫佹柟鐨凙CK鍖呭悗锛岄噸鏂版牴鎹暟鎹寘鐨勬簮鍦板潃銆佺鍙ｈ绠楄鍖呬腑鐨勭‘璁ゅ簭鍒楀彿鏄惁姝ｇ‘锛屽鏋滄纭垯寤虹珛杩炴帴锛屽惁鍒欎涪寮冭鍖呫
+
+- **SYN Proxy闃茬伀澧**锛氭湇鍔″櫒闃茬伀澧欎細瀵规敹鍒扮殑姣忎竴涓猄YN鎶ユ枃杩涜浠ｇ悊鍜屽洖搴旓紝骞朵繚鎸佸崐杩炴帴銆傜瓑鍙戦佹柟灏咥CK鍖呰繑鍥炲悗锛屽啀閲嶆柊鏋勯燬YN鍖呭彂鍒版湇鍔″櫒锛屽缓绔嬬湡姝ｇ殑TCP杩炴帴銆
+
+### 14. Nagle 绠楁硶涓庡欢杩熺‘璁
+
+#### Nagle绠楁硶
+
+濡傛灉鍙戦佺鐤媯鍦板悜鎺ユ敹绔彂閫佸緢灏忕殑鍖咃紝姣斿灏1涓瓧鑺傦紝閭ｄ箞浜茬埍鐨勫皬浼欎即锛屼綘浠寰椾細鏈変粈涔堥棶棰樺憿锛
+
+> TCP/IP鍗忚涓紝鏃犺鍙戦佸灏戞暟鎹紝鎬绘槸瑕佸湪鏁版嵁鍓嶉潰鍔犱笂鍗忚澶达紝鍚屾椂锛屽鏂规帴鏀跺埌鏁版嵁锛屼篃闇瑕佸彂閫丄CK琛ㄧず纭銆備负浜嗗敖鍙兘鐨勫埄鐢ㄧ綉缁滃甫瀹斤紝TCP鎬绘槸甯屾湜灏藉彲鑳界殑鍙戦佽冻澶熷ぇ鐨勬暟鎹**Nagle绠楁硶**灏辨槸涓轰簡灏藉彲鑳藉彂閫佸ぇ鍧楁暟鎹紝閬垮厤缃戠粶涓厖鏂ョ潃璁稿灏忔暟鎹潡銆
+
+Nagle绠楁硶鐨勫熀鏈畾涔夋槸锛**浠绘剰鏃跺埢锛屾渶澶氬彧鑳芥湁涓涓湭琚‘璁ょ殑灏忔**銆 鎵璋撯滃皬娈碘濓紝鎸囩殑鏄皬浜嶮SS灏哄鐨勬暟鎹潡锛屾墍璋撯滄湭琚‘璁も濓紝鏄寚涓涓暟鎹潡鍙戦佸嚭鍘诲悗锛屾病鏈夋敹鍒板鏂瑰彂閫佺殑ACK纭璇ユ暟鎹凡鏀跺埌銆
+
+Nagle绠楁硶鐨勫疄鐜拌鍒欙細
+
+- 濡傛灉鍖呴暱搴﹁揪鍒癕SS锛屽垯鍏佽鍙戦侊紱
+- 濡傛灉璇ュ寘鍚湁FIN锛屽垯鍏佽鍙戦侊紱
+- 璁剧疆浜員CP_NODELAY閫夐」锛屽垯鍏佽鍙戦侊紱
+- 鏈缃甌CP_CORK閫夐」鏃讹紝鑻ユ墍鏈夊彂鍑哄幓鐨勫皬鏁版嵁鍖咃紙鍖呴暱搴﹀皬浜嶮SS锛夊潎琚‘璁わ紝鍒欏厑璁稿彂閫侊紱
+- 涓婅堪鏉′欢閮芥湭婊¤冻锛屼絾鍙戠敓浜嗚秴鏃讹紙涓鑸负200ms锛夛紝鍒欑珛鍗冲彂閫併
+
+#### 寤惰繜纭
+
+濡傛灉鎺ュ彈鏂瑰垰鎺ユ敹鍒板彂閫佹柟鐨勬暟鎹寘锛屽湪寰堢煭寰堢煭鐨勬椂闂村唴锛屽張鎺ユ敹鍒扮浜屼釜鍖呫傞偅涔堣闂帴鏀舵柟鏄竴涓竴涓湴鍥炲濂界偣锛岃繕鏄悎骞朵竴璧峰洖澶嶅ソ鍛紵
+
+> 鎺ユ敹鏂规敹鍒版暟鎹寘鍚庯紝濡傛灉鏆傛椂娌℃湁鏁版嵁瑕佸彂缁欏绔紝瀹冨彲浠ョ瓑涓娈垫椂鍐嶇‘璁わ紙Linux涓婇粯璁ゆ槸40ms锛夈傚鏋滆繖娈垫椂闂村垰濂芥湁鏁版嵁瑕佷紶缁欏绔紝ACK灏遍殢鐫鏁版嵁浼犺緭锛岃屼笉闇瑕佸崟鐙彂閫佷竴娆CK銆傚鏋滆秴杩囨椂闂磋繕娌℃湁鏁版嵁瑕佸彂閫侊紝涔熷彂閫丄CK锛岄伩鍏嶅绔互涓轰涪鍖呫
+
+浣嗘槸鏈変簺鍦烘櫙涓嶈兘寤惰繜纭锛屾瘮濡傚彂鐜颁簡**涔卞簭鍖**銆**鎺ユ敹鍒颁簡澶т簬涓涓 frame 鐨勬姤鏂囷紝涓旈渶瑕佽皟鏁寸獥鍙ｅぇ灏**绛夈
+
+涓鑸儏鍐典笅锛**Nagle绠楁硶鍜屽欢杩熺‘璁**涓嶈兘涓璧蜂娇鐢紝Nagle绠楁硶鎰忓懗鐫寤惰繜鍙戯紝**寤惰繜纭**鎰忓懗鐫寤惰繜鎺ユ敹锛岄叡绱氨浼氶犳垚鏇村ぇ鐨勫欢杩燂紝浼氫骇鐢熸ц兘闂銆
+
+### 15. TCP鐨勭矘鍖呭拰鎷嗗寘
+
+TCP鏄潰鍚戞祦锛屾病鏈夌晫闄愮殑涓涓叉暟鎹俆CP搴曞眰骞朵笉浜嗚В涓婂眰涓氬姟鏁版嵁鐨勫叿浣撳惈涔夛紝瀹冧細鏍规嵁TCP缂撳啿鍖虹殑瀹為檯鎯呭喌杩涜鍖呯殑鍒掑垎锛屾墍浠ュ湪涓氬姟涓婅涓猴紝涓**涓畬鏁寸殑鍖呭彲鑳戒細琚玊CP鎷嗗垎鎴愬涓寘杩涜鍙戦**锛**涔熸湁鍙兘鎶婂涓皬鐨勫寘灏佽鎴愪竴涓ぇ鐨勬暟鎹寘鍙戦**锛岃繖灏辨槸鎵璋撶殑TCP绮樺寘鍜屾媶鍖呴棶棰樸
+
+
+
+
+**涓轰粈涔堜細浜х敓绮樺寘鍜屾媶鍖呭憿?**
+
+- 瑕佸彂閫佺殑鏁版嵁灏忎簬TCP鍙戦佺紦鍐插尯鐨勫ぇ灏忥紝TCP灏嗗娆″啓鍏ョ紦鍐插尯鐨勬暟鎹竴娆″彂閫佸嚭鍘伙紝灏嗕細鍙戠敓绮樺寘锛
+- 鎺ユ敹鏁版嵁绔殑搴旂敤灞傛病鏈夊強鏃惰鍙栨帴鏀剁紦鍐插尯涓殑鏁版嵁锛屽皢鍙戠敓绮樺寘锛
+- 瑕佸彂閫佺殑鏁版嵁澶т簬TCP鍙戦佺紦鍐插尯鍓╀綑绌洪棿澶у皬锛屽皢浼氬彂鐢熸媶鍖咃紱
+- 寰呭彂閫佹暟鎹ぇ浜嶮SS锛堟渶澶ф姤鏂囬暱搴︼級锛孴CP鍦ㄤ紶杈撳墠灏嗚繘琛屾媶鍖呫傚嵆TCP鎶ユ枃闀垮害-TCP澶撮儴闀垮害>MSS銆
+
+**瑙ｅ喅鏂规锛**
+
+- 鍙戦佺灏嗘瘡涓暟鎹寘灏佽涓哄浐瀹氶暱搴
+- 鍦ㄦ暟鎹熬閮ㄥ鍔犵壒娈婂瓧绗﹁繘琛屽垎鍓
+- 灏嗘暟鎹垎涓轰袱閮ㄥ垎锛屼竴閮ㄥ垎鏄ご閮紝涓閮ㄥ垎鏄唴瀹逛綋锛涘叾涓ご閮ㄧ粨鏋勫ぇ灏忓浐瀹氾紝涓旀湁涓涓瓧娈靛０鏄庡唴瀹逛綋鐨勫ぇ灏忋
+
+### 鍙傝冧笌鎰熻阿
+- [TCP 鐨勯偅浜涗簨鍎匡紙涓嬶級](https://coolshell.cn/articles/11609.html "TCP 鐨勯偅浜涗簨鍎匡紙涓嬶級")
+- [闈㈣瘯澶存潯浣犻渶瑕佹噦鐨 TCP 鎷ュ鎺у埗鍘熺悊](https://zhuanlan.zhihu.com/p/76023663 "闈㈣瘯澶存潯浣犻渶瑕佹噦鐨 TCP 鎷ュ鎺у埗鍘熺悊")
+- [30寮犲浘瑙ｏ細 TCP 閲嶄紶銆佹粦鍔ㄧ獥鍙ｃ佹祦閲忔帶鍒躲佹嫢濉炴帶鍒跺彂鎰乚(https://zhuanlan.zhihu.com/p/133307545 "30寮犲浘瑙ｏ細 TCP 閲嶄紶銆佹粦鍔ㄧ獥鍙ｃ佹祦閲忔帶鍒躲佹嫢濉炴帶鍒跺彂鎰")
+- [TCP鍗忚鐏甸瓊涔嬮棶锛屽珐鍥轰綘鐨勭綉璺簳灞傚熀纭](https://juejin.cn/post/6844904070889603085 "TCP鍗忚鐏甸瓊涔嬮棶锛屽珐鍥轰綘鐨勭綉璺簳灞傚熀纭")
+- [TCP绮樺寘鍜屾媶鍖匽(https://blog.csdn.net/ailunlee/article/details/95944377 "TCP绮樺寘鍜屾媶鍖")
+- 鐧惧害鐧剧
+
+
+
From 726441dc408342ae76d78f1d738457a75094e410 Mon Sep 17 00:00:00 2001
From: whx123 <327658337@qq.com>
Date: Sun, 11 Jul 2021 21:24:19 +0800
Subject: [PATCH 03/51] =?UTF-8?q?Redis=E5=BF=AB?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
...10\350\277\231\344\271\210\345\277\253.md" | 175 ++++++++++++++++++
1 file changed, 175 insertions(+)
create mode 100644 "Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\344\270\272\344\273\200\344\271\210\350\277\231\344\271\210\345\277\253.md"
diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\344\270\272\344\273\200\344\271\210\350\277\231\344\271\210\345\277\253.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\344\270\272\344\273\200\344\271\210\350\277\231\344\271\210\345\277\253.md"
new file mode 100644
index 0000000..a3f6b30
--- /dev/null
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\344\270\272\344\273\200\344\271\210\350\277\231\344\271\210\345\277\253.md"
@@ -0,0 +1,175 @@
+
+## 鍓嶈█
+
+澶у濂藉憖锛屾垜鏄崱鐢拌灪鐨勫皬鐢峰銆傛垜浠兘鐭ラ亾Redis寰堝揩锛屽畠QPS鍙揪10涓囷紙姣忕璇锋眰鏁帮級銆**Redis涓轰粈涔堣繖涔堝揩鍛**,鏈枃灏嗚窡澶у涓璧峰涔犮
+
+
+
+
+- 鍏紬鍙凤細**鎹＄敯铻虹殑灏忕敺瀛**
+- [github鍦板潃](https://github.com/whx123/JavaHome)锛屾劅璋㈡瘡涓棰梥tar
+
+## 鍩轰簬鍐呭瓨瀹炵幇
+
+鎴戜滑閮界煡閬撳唴瀛樿鍐欐槸姣旂鐩樿鍐欏揩寰堝鐨勩俁edis鏄熀浜庡唴瀛樺瓨鍌ㄥ疄鐜扮殑鏁版嵁搴擄紝鐩稿浜庢暟鎹瓨鍦ㄧ鐩樼殑鏁版嵁搴擄紝灏辩渷鍘荤鐩樼鐩業/O鐨勬秷鑰椼侻ySQL绛夌鐩樻暟鎹簱锛岄渶瑕佸缓绔嬬储寮曟潵鍔犲揩鏌ヨ鏁堢巼锛岃孯edis鏁版嵁瀛樻斁鍦ㄥ唴瀛橈紝鐩存帴鎿嶄綔鍐呭瓨锛屾墍浠ュ氨寰堝揩銆
+
+
+
+## 楂樻晥鐨勬暟鎹粨鏋
+
+鎴戜滑鐭ラ亾锛孧ySQL绱㈠紩涓轰簡鎻愰珮鏁堢巼锛岄夋嫨浜咮+鏍戠殑鏁版嵁缁撴瀯銆傚叾瀹炲悎鐞嗙殑鏁版嵁缁撴瀯锛屽氨鏄彲浠ヨ浣犵殑搴旂敤/绋嬪簭鏇村揩銆傚厛鐪嬩笅Redis鐨勬暟鎹粨鏋&鍐呴儴缂栫爜鍥撅細
+
+
+
+
+
+### SDS绠鍗曞姩鎬佸瓧绗︿覆
+
+
+
+
+```
+struct sdshdr { //SDS绠鍗曞姩鎬佸瓧绗︿覆
+ int len; //璁板綍buf涓凡浣跨敤鐨勭┖闂
+ int free; // buf涓┖闂茬┖闂撮暱搴
+ char buf[]; //瀛樺偍鐨勫疄闄呭唴瀹
+}
+```
+
+
+#### 瀛楃涓查暱搴﹀鐞
+
+鍦–璇█涓紝瑕佽幏鍙朻``鎹＄敯铻虹殑灏忕敺瀛ー``杩欎釜瀛楃涓茬殑闀垮害锛岄渶瑕佷粠澶村紑濮嬮亶鍘嗭紝澶嶆潅搴︿负O锛坣锛;
+鍦≧edis涓紝 宸茬粡鏈変竴涓**len**瀛楁璁板綍褰撳墠瀛楃涓茬殑闀垮害鍟︼紝鐩存帴鑾峰彇鍗冲彲锛屾椂闂村鏉傚害涓篛(1)銆
+
+#### 鍑忓皯鍐呭瓨閲嶆柊鍒嗛厤鐨勬鏁
+
+鍦–璇█涓紝淇敼涓涓瓧绗︿覆锛岄渶瑕侀噸鏂板垎閰嶅唴瀛橈紝淇敼瓒婇绻侊紝鍐呭瓨鍒嗛厤灏辫秺棰戠箒锛岃屽垎閰嶅唴瀛樻槸浼**娑堣楁ц兘**鐨勩傝屽湪Redis涓紝SDS鎻愪緵浜嗕袱绉嶄紭鍖栫瓥鐣ワ細绌洪棿棰勫垎閰嶅拰鎯版х┖闂撮噴鏀俱
+
+**绌洪棿棰勫垎閰**
+
+褰揝DS绠鍗曞姩鎬佸瓧绗︿覆淇敼鍜岀┖闂存墿鍏呮椂锛岄櫎浜嗗垎閰嶅繀闇鐨勫唴瀛樼┖闂达紝杩樹細棰濆鍒嗛厤鏈娇鐢ㄧ殑绌洪棿銆傚垎閰嶈鍒欐槸閰辩传鐨勶細
+
+> - SDS淇敼鍚庯紝len鐨勯暱搴﹀皬浜1M锛岄偅涔堝皢棰濆鍒嗛厤涓巐en鐩稿悓闀垮害鐨勬湭浣跨敤绌洪棿銆傛瘮濡俵en=100锛岄噸鏂板垎閰嶅悗锛宐uf 鐨勫疄闄呴暱搴︿細鍙樹负100(宸蹭娇鐢ㄧ┖闂)+100(棰濆绌洪棿)+1(绌哄瓧绗)=201銆
+> - SDS淇敼鍚, len闀垮害澶т簬1M锛岄偅涔堢▼搴忓皢鍒嗛厤1M鐨勬湭浣跨敤绌洪棿銆
+
+**鎯版х┖闂撮噴鏀**
+
+褰揝DS缂╃煭鏃讹紝涓嶆槸鍥炴敹澶氫綑鐨勫唴瀛樼┖闂达紝鑰屾槸鐢╢ree璁板綍涓嬪浣欑殑绌洪棿銆傚悗缁啀鏈変慨鏀规搷浣滐紝鐩存帴浣跨敤free涓殑绌洪棿锛屽噺灏戝唴瀛樺垎閰嶃
+
+#### 鍝堝笇
+
+Redis 浣滀负涓涓狵-V鐨勫唴瀛樻暟鎹簱锛屽畠浣跨敤鐢ㄤ竴寮犲叏灞鐨勫搱甯屾潵淇濆瓨鎵鏈夌殑閿煎銆傝繖寮犲搱甯岃〃锛屾湁澶氫釜鍝堝笇妗剁粍鎴愶紝鍝堝笇妗朵腑鐨別ntry鍏冪礌淇濆瓨浜哷``*key```鍜宍``*value```鎸囬拡锛屽叾涓璥``*key```鎸囧悜浜嗗疄闄呯殑閿紝```*value```鎸囧悜浜嗗疄闄呯殑鍊笺
+
+
+
+鍝堝笇琛ㄦ煡鎵鹃熺巼寰堝揩鐨勶紝鏈夌偣绫讳技浜嶫ava涓殑**HashMap**锛屽畠璁╂垜浠湪**O(1)** 鐨勬椂闂村鏉傚害蹇熸壘鍒伴敭鍊煎銆傞鍏堥氳繃key璁＄畻鍝堝笇鍊硷紝鎵惧埌瀵瑰簲鐨勫搱甯屾《浣嶇疆锛岀劧鍚庡畾浣嶅埌entry锛屽湪entry鎵惧埌瀵瑰簲鐨勬暟鎹
+
+鏈変簺灏忎紮浼村彲鑳戒細鏈夌枒闂細浣犲線鍝堝笇琛ㄤ腑鍐欏叆澶ч噺鏁版嵁鏃讹紝涓嶆槸浼氶亣鍒**鍝堝笇鍐茬獊**闂鍢涳紝閭ｆ晥鐜囧氨浼氶檷涓嬫潵鍟︺
+> **鍝堝笇鍐茬獊锛** 閫氳繃涓嶅悓鐨刱ey锛岃绠楀嚭涓鏍风殑鍝堝笇鍊硷紝瀵艰嚧钀藉湪鍚屼竴涓搱甯屾《涓
+
+Redis涓轰簡瑙ｅ喅鍝堝笇鍐茬獊锛岄噰鐢ㄤ簡**閾惧紡鍝堝笇**銆傞摼寮忓搱甯屾槸鎸囧悓涓涓搱甯屾《涓紝澶氫釜鍏冪礌鐢ㄤ竴涓摼琛ㄦ潵淇濆瓨锛屽畠浠箣闂翠緷娆＄敤鎸囬拡杩炴帴銆
+
+
+
+鏈変簺灏忎紮浼村彲鑳借繕浼氭湁鐤戦棶锛氬搱甯屽啿绐侀摼涓婄殑鍏冪礌鍙兘閫氳繃鎸囬拡閫愪竴鏌ユ壘鍐嶆搷浣溿傚綋寰鍝堝笇琛ㄦ彃鍏ユ暟鎹緢澶氾紝鍐茬獊涔熶細瓒婂锛屽啿绐侀摼琛ㄥ氨浼氳秺闀匡紝閭ｆ煡璇㈡晥鐜囧氨浼氶檷浣庝簡銆
+
+涓轰簡淇濇寔楂樻晥锛孯edis 浼氬鍝堝笇琛ㄥ仛**rehash鎿嶄綔**锛屼篃灏辨槸澧炲姞鍝堝笇妗讹紝鍑忓皯鍐茬獊銆備负浜唕ehash鏇撮珮鏁堬紝Redis杩橀粯璁や娇鐢ㄤ簡涓や釜鍏ㄥ眬鍝堝笇琛紝涓涓敤浜庡綋鍓嶄娇鐢紝绉颁负涓诲搱甯岃〃锛屼竴涓敤浜庢墿瀹癸紝绉颁负澶囩敤鍝堝笇琛ㄣ
+
+#### 璺宠穬琛
+
+璺宠穬琛ㄦ槸Redis鐗规湁鐨勬暟鎹粨鏋勶紝瀹冨叾瀹炲氨鏄湪**閾捐〃鐨勫熀纭涓婏紝澧炲姞澶氱骇绱㈠紩**锛屼互鎻愰珮鏌ユ壘鏁堢巼銆傝烦璺冭〃鐨勭畝鍗曞師鐞嗗浘濡備笅:
+
+
+
+- 姣忎竴灞傞兘鏈変竴鏉℃湁搴忕殑閾捐〃锛屾渶搴曞眰鐨勯摼琛ㄥ寘鍚簡鎵鏈夌殑鍏冪礌銆
+- 璺宠穬琛ㄦ敮鎸佸钩鍧 O锛坙ogN锛,鏈鍧 O锛圢锛夊鏉傚害鐨勮妭鐐规煡鎵撅紝杩樺彲浠ラ氳繃椤哄簭鎬ф搷浣滄壒閲忓鐞嗚妭鐐广
+
+
+#### 鍘嬬缉鍒楄〃ziplist
+
+鍘嬬缉鍒楄〃ziplist鏄垪琛ㄩ敭鍜屽瓧鍏搁敭鐨勭殑搴曞眰瀹炵幇涔嬩竴銆傚畠鏄敱涓绯诲垪鐗规畩缂栫爜鐨勫唴瀛樺潡鏋勬垚鐨勫垪琛紝 涓涓獄iplist鍙互鍖呭惈澶氫釜entry锛 姣忎釜entry鍙互淇濆瓨涓涓暱搴﹀彈闄愮殑瀛楃鏁扮粍鎴栬呮暣鏁帮紝濡備笅锛
+
+
+
+
+- zlbytes 锛氳褰曟暣涓帇缂╁垪琛ㄥ崰鐢ㄧ殑鍐呭瓨瀛楄妭鏁
+- zltail: 灏捐妭鐐硅嚦璧峰鑺傜偣鐨勫亸绉婚噺
+- zllen : 璁板綍鏁翠釜鍘嬬缉鍒楄〃鍖呭惈鐨勮妭鐐规暟閲
+- entryX: 鍘嬬缉鍒楄〃鍖呭惈鐨勫悇涓妭鐐
+- zlend : 鐗规畩鍊0xFF(鍗佽繘鍒255)锛岀敤浜庢爣璁板帇缂╁垪琛ㄦ湯绔
+
+鐢变簬鍐呭瓨鏄**杩炵画鍒嗛厤**鐨勶紝鎵浠ラ亶鍘嗛熷害寰堝揩銆傘
+
+
+## 鍚堢悊鐨勬暟鎹紪鐮
+
+Redis鏀寔澶氱鏁版嵁鍩烘湰绫诲瀷锛屾瘡绉嶅熀鏈被鍨嬪搴斾笉鍚岀殑鏁版嵁缁撴瀯锛屾瘡绉嶆暟鎹粨鏋勫搴斾笉涓鏍风殑缂栫爜銆備负浜嗘彁楂樻ц兘锛孯edis璁捐鑰呮荤粨鍑猴紝鏁版嵁缁撴瀯鏈閫傚悎鐨勭紪鐮佹惌閰嶃
+
+Redis鏄娇鐢ㄥ璞★紙redisObject锛夋潵琛ㄧず鏁版嵁搴撲腑鐨勯敭鍊硷紝褰撴垜浠湪 Redis 涓垱寤轰竴涓敭鍊煎鏃讹紝鑷冲皯鍒涘缓涓や釜瀵硅薄锛屼竴涓璞℃槸鐢ㄥ仛閿煎鐨勯敭瀵硅薄锛屽彟涓涓槸閿煎鐨勫煎璞°
+```
+//鍏虫敞鍏紬鍙凤細鎹＄敯铻虹殑灏忕敺瀛
+typedef struct redisObject{
+ //绫诲瀷
+ unsigned type:4;
+ //缂栫爜
+ unsigned encoding:4;
+ //鎸囧悜搴曞眰鏁版嵁缁撴瀯鐨勬寚閽
+ void *ptr;
+ //...
+ }robj;
+```
+
+redisObject涓紝**type** 瀵瑰簲鐨勬槸瀵硅薄绫诲瀷锛屽寘鍚玈tring瀵硅薄銆丩ist瀵硅薄銆丠ash瀵硅薄銆丼et瀵硅薄銆亃set瀵硅薄銆**encoding** 瀵瑰簲鐨勬槸缂栫爜銆
+
+- String锛氬鏋滃瓨鍌ㄦ暟瀛楃殑璇濓紝鏄敤int绫诲瀷鐨勭紪鐮;濡傛灉瀛樺偍闈炴暟瀛楋紝灏忎簬绛変簬39瀛楄妭鐨勫瓧绗︿覆锛屾槸embstr锛涘ぇ浜39涓瓧鑺傦紝鍒欐槸raw缂栫爜銆
+- List锛氬鏋滃垪琛ㄧ殑鍏冪礌涓暟灏忎簬512涓紝鍒楄〃姣忎釜鍏冪礌鐨勫奸兘灏忎簬64瀛楄妭锛堥粯璁わ級锛屼娇鐢▃iplist缂栫爜锛屽惁鍒欎娇鐢╨inkedlist缂栫爜
+- Hash锛氬搱甯岀被鍨嬪厓绱犱釜鏁板皬浜512涓紝鎵鏈夊煎皬浜64瀛楄妭鐨勮瘽锛屼娇鐢▃iplist缂栫爜,鍚﹀垯浣跨敤hashtable缂栫爜銆
+- Set锛氬鏋滈泦鍚堜腑鐨勫厓绱犻兘鏄暣鏁颁笖鍏冪礌涓暟灏忎簬512涓紝浣跨敤intset缂栫爜锛屽惁鍒欎娇鐢╤ashtable缂栫爜銆
+- Zset锛氬綋鏈夊簭闆嗗悎鐨勫厓绱犱釜鏁板皬浜128涓紝姣忎釜鍏冪礌鐨勫煎皬浜64瀛楄妭鏃讹紝浣跨敤ziplist缂栫爜锛屽惁鍒欎娇鐢╯kiplist锛堣烦璺冭〃锛夌紪鐮
+
+## 鍚堢悊鐨勭嚎绋嬫ā鍨
+
+
+### 鍗曠嚎绋嬫ā鍨嬶細閬垮厤浜嗕笂涓嬫枃鍒囨崲
+
+Redis鏄崟绾跨▼鐨勶紝鍏跺疄鏄寚**Redis鐨勭綉缁淚O鍜岄敭鍊煎璇诲啓**鏄敱涓涓嚎绋嬫潵瀹屾垚鐨勩備絾Redis鐨勫叾浠栧姛鑳斤紝姣斿鎸佷箙鍖栥佸紓姝ュ垹闄ゃ侀泦缇ゆ暟鎹悓姝ョ瓑绛夛紝瀹為檯鏄敱棰濆鐨勭嚎绋嬫墽琛岀殑銆
+
+Redis鐨勫崟绾跨▼妯″瀷锛岄伩鍏嶄簡**CPU涓嶅繀瑕佺殑涓婁笅鏂囧垏鎹**鍜**绔炰簤閿佺殑娑堣**銆備篃姝ｅ洜涓烘槸鍗曠嚎绋嬶紝濡傛灉鏌愪釜鍛戒护鎵ц杩囬暱锛堝hgetall鍛戒护锛夛紝浼氶犳垚闃诲銆俁edis鏄潰鍚戝揩閫熸墽琛屽満鏅殑鍐呭瓨鏁版嵁搴擄紝鎵浠ヨ鎱庣敤濡俵range鍜宻members銆乭getall绛夊懡浠ゃ
+
+浠涔堟槸**涓婁笅鏂囧垏鎹**锛熶妇涓矡瀛愶細
+
+> - 姣斿浣犲湪鐪嬩竴鏈嫳鏂囧皬璇达紝浣犵湅鍒版煇涓椤碉紝鍙戠幇鏈変釜鍗曡瘝涓嶄細璇伙紝浣犲姞浜嗕釜涔︾锛岀劧鍚庡幓鏌ュ瓧鍏搞傛煡瀹屽瓧鍏稿悗锛屼綘鍥炴潵浠庝功绛鹃偅閲岀户缁紑濮嬭锛岃繖涓祦绋嬪氨寰堣垝鐣呫
+> - 濡傛灉浣犱竴涓汉璇昏繖鏈功锛岃偗瀹氭病鍟ラ棶棰樸備絾鏄鏋滀綘鍘绘煡瀛楀吀鐨勬椂鍊欙紝鍒殑灏忎紮浼寸炕浜嗕竴涓嬩綘鐨勪功锛岀劧鍚庢簻浜嗐備綘鍐嶅洖鏉ョ湅鐨勬椂鍊欙紝鍙戠幇涔︿笉鏄綘鐪嬬殑閭ｄ竴椤典簡锛屼綘寰楄姳鏃堕棿鎵惧埌浣犵殑閭ｄ竴椤点
+> - 涓鏈功锛屼綘涓涓汉鎬庝箞鐪嬫庝箞鎵撴爣绛鹃兘娌′簨锛屼絾鏄汉澶氫簡缈绘潵缈诲幓锛岃繖鏈功鍚勭鏍囪灏卞緢涔变簡銆傚彲鑳借繖涓В閲婂緢绮楃硻锛屼絾鏄亾鐞嗗簲璇ユ槸涓鏍风殑銆
+
+
+
+### I/O 澶氳矾澶嶇敤
+
+浠涔堟槸I/O澶氳矾澶嶇敤锛
+- I/O 锛氱綉缁 I/O
+- 澶氳矾 锛氬涓綉缁滆繛鎺
+- 澶嶇敤锛氬鐢ㄥ悓涓涓嚎绋嬨
+- IO澶氳矾澶嶇敤鍏跺疄灏辨槸涓绉嶅悓姝O妯″瀷锛屽畠瀹炵幇浜嗕竴涓嚎绋嬪彲浠ョ洃瑙嗗涓枃浠跺彞鏌勶紱涓鏃︽煇涓枃浠跺彞鏌勫氨缁紝灏辫兘澶熼氱煡搴旂敤绋嬪簭杩涜鐩稿簲鐨勮鍐欐搷浣滐紱鑰屾病鏈夋枃浠跺彞鏌勫氨缁椂,灏变細闃诲搴旂敤绋嬪簭锛屼氦鍑篶pu銆
+
+
+
+
+
+> 澶氳矾I/O澶嶇敤鎶鏈彲浠ヨ鍗曚釜绾跨▼楂樻晥鐨勫鐞嗗涓繛鎺ヨ姹傦紝鑰孯edis浣跨敤鐢╡poll浣滀负I/O澶氳矾澶嶇敤鎶鏈殑瀹炵幇銆傚苟涓擱edis鑷韩鐨勪簨浠跺鐞嗘ā鍨嬪皢epoll涓殑杩炴帴銆佽鍐欍佸叧闂兘杞崲涓轰簨浠讹紝涓嶅湪缃戠粶I/O涓婃氮璐硅繃澶氱殑鏃堕棿銆
+
+## 铏氭嫙鍐呭瓨鏈哄埗
+
+Redis鐩存帴鑷繁鏋勫缓浜哣M鏈哄埗 锛屼笉浼氬儚涓鑸殑绯荤粺浼氳皟鐢ㄧ郴缁熷嚱鏁板鐞嗭紝浼氭氮璐逛竴瀹氱殑鏃堕棿鍘荤Щ鍔ㄥ拰璇锋眰銆
+
+**Redis鐨勮櫄鎷熷唴瀛樻満鍒舵槸鍟ュ憿锛**
+> 铏氭嫙鍐呭瓨鏈哄埗灏辨槸鏆傛椂鎶婁笉缁忓父璁块棶鐨勬暟鎹(鍐锋暟鎹)浠庡唴瀛樹氦鎹㈠埌纾佺洏涓紝浠庤岃吘鍑哄疂璐电殑鍐呭瓨绌洪棿鐢ㄤ簬鍏跺畠闇瑕佽闂殑鏁版嵁(鐑暟鎹)銆傞氳繃VM鍔熻兘鍙互瀹炵幇鍐风儹鏁版嵁鍒嗙锛屼娇鐑暟鎹粛鍦ㄥ唴瀛樹腑銆佸喎鏁版嵁淇濆瓨鍒扮鐩樸傝繖鏍峰氨鍙互閬垮厤鍥犱负鍐呭瓨涓嶈冻鑰岄犳垚璁块棶閫熷害涓嬮檷鐨勯棶棰樸
+
+### 鍙傝冧笌鎰熻阿
+
+- [Redis涔媀M鏈哄埗](https://www.codenong.com/cs106843764/)
+- [涓鏂囨彮绉樺崟绾跨▼鐨凴edis涓轰粈涔堣繖涔堝揩?](https://zhuanlan.zhihu.com/p/57089960)
+- [娲炲療|Redis鏄崟绾跨▼鐨勶紝浣哛edis涓轰粈涔堣繖涔堝揩锛焆(https://zhuanlan.zhihu.com/p/42272979)
+
+
From 1b8d1314deb883bc8dcf1ba547334a82d9f0e5e7 Mon Sep 17 00:00:00 2001
From: whx123 <327658337@qq.com>
Date: Sun, 11 Jul 2021 21:26:23 +0800
Subject: [PATCH 04/51] =?UTF-8?q?Redis=E5=BF=AB?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
.../order by\350\257\246\350\247\243.md" | 348 ++++++++++++++++++
1 file changed, 348 insertions(+)
create mode 100644 "Mysql\345\237\272\347\241\200\345\255\246\344\271\240/order by\350\257\246\350\247\243.md"
diff --git "a/Mysql\345\237\272\347\241\200\345\255\246\344\271\240/order by\350\257\246\350\247\243.md" "b/Mysql\345\237\272\347\241\200\345\255\246\344\271\240/order by\350\257\246\350\247\243.md"
new file mode 100644
index 0000000..3aeda16
--- /dev/null
+++ "b/Mysql\345\237\272\347\241\200\345\255\246\344\271\240/order by\350\257\246\350\247\243.md"
@@ -0,0 +1,348 @@
+## 鍓嶈█
+
+鏃ュ父寮鍙戜腑锛屾垜浠粡甯镐細浣跨敤鍒皁rder by锛屼翰鐖辩殑灏忎紮浼达紝浣犳槸鍚︾煡閬搊rder by 鐨勫伐浣滃師鐞嗗憿锛無rder by鐨勪紭鍖栨濊矾鏄庢牱鐨勫憿锛熶娇鐢╫rder by鏈夊摢浜涙敞鎰忕殑闂鍛紵鏈枃灏嗚窡澶у涓璧锋潵瀛︿範锛屾敾鍏媜rder by~
+
+
+
+
+- 寰俊鍏紬鍙凤細**鎹＄敯铻虹殑灏忕敺瀛**
+- [github鍦板潃锛屾劅璋㈡瘡涓棰梥tar](https://github.com/whx123/JavaHome)
+- 濡傛灉瑙夊緱鏈夋敹鑾凤紝甯繖鐐硅禐锛岃浆鍙戜笅鍝堬紝鎰熻阿鎰熻阿
+
+
+## 涓涓娇鐢╫rder by 鐨勭畝鍗曚緥瀛
+
+鍋囪鐢ㄤ竴寮犲憳宸ヨ〃锛岃〃缁撴瀯濡備笅锛
+
+```
+CREATE TABLE `staff` (
+`id` BIGINT ( 11 ) AUTO_INCREMENT COMMENT '涓婚敭id',
+`id_card` VARCHAR ( 20 ) NOT NULL COMMENT '韬唤璇佸彿鐮',
+`name` VARCHAR ( 64 ) NOT NULL COMMENT '濮撳悕',
+`age` INT ( 4 ) NOT NULL COMMENT '骞撮緞',
+`city` VARCHAR ( 64 ) NOT NULL COMMENT '鍩庡競',
+PRIMARY KEY ( `id`),
+INDEX idx_city ( `city` )
+) ENGINE = INNODB COMMENT '鍛樺伐琛';
+
+```
+
+琛ㄦ暟鎹涓嬶細
+
+
+
+
+鎴戜滑鐜板湪鏈夎繖涔堜竴涓渶姹傦細**鏌ヨ鍓10涓紝鏉ヨ嚜娣卞湷鍛樺伐鐨勫鍚嶃佸勾榫勩佸煄甯傦紝骞朵笖鎸夌収骞撮緞灏忓埌澶ф帓搴**銆傚搴旂殑 SQL 璇彞灏卞彲浠ヨ繖涔堝啓锛
+
+```
+select name,age,city from staff where city = '娣卞湷' order by age limit 10;
+```
+
+杩欐潯璇彞鐨勯昏緫寰堟竻妤氾紝浣嗘槸瀹冪殑**搴曞眰鎵ц娴佺▼**鏄庢牱鐨勫憿锛
+
+## order by 宸ヤ綔鍘熺悊
+
+
+
+### explain 鎵ц璁″垝
+
+鎴戜滑鍏堢敤**Explain**鍏抽敭瀛楁煡鐪嬩竴涓嬫墽琛岃鍒
+
+
+
+
+- 鎵ц璁″垝鐨**key**杩欎釜瀛楁锛岃〃绀轰娇鐢ㄥ埌绱㈠紩idx_city
+- Extra 杩欎釜瀛楁鐨 **Using index condition** 琛ㄧず绱㈠紩鏉′欢
+- Extra 杩欎釜瀛楁鐨 **Using filesort**琛ㄧず鐢ㄥ埌鎺掑簭
+
+鎴戜滑鍙互鍙戠幇锛岃繖鏉QL浣跨敤鍒颁簡绱㈠紩锛屽苟涓斾篃鐢ㄥ埌鎺掑簭銆傞偅涔堝畠鏄**鎬庝箞鎺掑簭**鐨勫憿锛
+
+### 鍏ㄥ瓧娈垫帓搴
+
+MySQL 浼氱粰姣忎釜鏌ヨ绾跨▼鍒嗛厤涓鍧楀皬**鍐呭瓨**锛岀敤浜**鎺掑簭**鐨勶紝绉颁负 **sort_buffer**銆備粈涔堟椂鍊欐妸瀛楁鏀捐繘鍘绘帓搴忓憿锛屽叾瀹炴槸閫氳繃```idx_city```绱㈠紩鎵惧埌瀵瑰簲鐨勬暟鎹紝鎵嶆妸鏁版嵁鏀捐繘鍘诲暒銆
+
+鎴戜滑鍥為【涓嬬储寮曟槸鎬庝箞鎵惧埌鍖归厤鐨勬暟鎹殑锛岀幇鍦ㄥ厛鎶婄储寮曟爲鐢诲嚭鏉ュ惂锛**idx_city**绱㈠紩鏍戝涓嬶細
+
+
+
+
+idx_city绱㈠紩鏍戯紝鍙跺瓙鑺傜偣瀛樺偍鐨勬槸**涓婚敭id**銆 杩樻湁涓妫礽d涓婚敭鑱氭棌绱㈠紩鏍戯紝鎴戜滑鍐嶇敾鍑鸿仛鏃忕储寮曟爲鍥惧惂锛
+
+
+
+
+
+**鎴戜滑鐨勬煡璇㈣鍙ユ槸鎬庝箞鎵惧埌鍖归厤鏁版嵁鐨勫憿**锛熷厛閫氳繃**idx_city**绱㈠紩鏍戯紝鎵惧埌瀵瑰簲鐨勪富閿甶d锛岀劧鍚庡啀閫氳繃鎷垮埌鐨勪富閿甶d锛屾悳绱**id涓婚敭绱㈠紩鏍**锛屾壘鍒板搴旂殑琛屾暟鎹
+
+鍔犱笂**order by**涔嬪悗锛屾暣浣撶殑鎵ц娴佺▼灏辨槸锛
+
+1. MySQL 涓哄搴旂殑绾跨▼鍒濆鍖**sort_buffer**锛屾斁鍏ラ渶瑕佹煡璇㈢殑name銆乤ge銆乧ity瀛楁锛
+2. 浠**绱㈠紩鏍慽dx_city**锛 鎵惧埌绗竴涓弧瓒 city='娣卞湷鈥欐潯浠剁殑涓婚敭 id锛屼篃灏辨槸鍥句腑鐨刬d=9锛
+3. 鍒**涓婚敭 id 绱㈠紩鏍**鎷垮埌id=9鐨勮繖涓琛屾暟鎹紝 鍙杗ame銆乤ge銆乧ity涓変釜瀛楁鐨勫硷紝瀛樺埌sort_buffer锛
+4. 浠**绱㈠紩鏍慽dx_city** 鎷垮埌涓嬩竴涓褰曠殑涓婚敭 id锛屽嵆鍥句腑鐨刬d=13锛
+5. 閲嶅姝ラ 3銆4 鐩村埌**city鐨勫间笉绛変簬娣卞湷**涓烘锛
+6. 鍓嶉潰5姝ュ凡缁忔煡鎵惧埌浜嗘墍鏈**city涓烘繁鍦**鐨勬暟鎹紝鍦 sort_buffer涓紝灏嗘墍鏈夋暟鎹牴鎹產ge杩涜鎺掑簭锛
+7. 鎸夌収鎺掑簭缁撴灉鍙栧墠10琛岃繑鍥炵粰瀹㈡埛绔
+
+鎵ц绀烘剰鍥惧涓嬶細
+
+
+
+灏嗘煡璇㈡墍闇鐨勫瓧娈靛叏閮ㄨ鍙栧埌sort_buffer涓紝灏辨槸**鍏ㄥ瓧娈垫帓搴**銆傝繖閲岄潰锛屾湁浜涘皬浼欎即鍙兘浼氭湁涓枒闂,鎶婃煡璇㈢殑鎵鏈夊瓧娈甸兘鏀惧埌sort_buffer锛岃宻ort_buffer鏄竴鍧楀唴瀛樻潵鐨勶紝濡傛灉鏁版嵁閲忓お澶э紝sort_buffer鏀句笉涓嬫庝箞鍔炲憿锛
+
+### 纾佺洏涓存椂鏂囦欢杈呭姪鎺掑簭
+
+瀹為檯涓婏紝sort_buffer鐨勫ぇ灏忔槸鐢变竴涓弬鏁版帶鍒剁殑锛**sort_buffer_size**銆傚鏋滆鎺掑簭鐨勬暟鎹皬浜巗ort_buffer_size锛屾帓搴忓湪**sort_buffer** 鍐呭瓨涓畬鎴愶紝濡傛灉瑕佹帓搴忕殑鏁版嵁澶т簬sort_buffer_size锛屽垯**鍊熷姪纾佺洏鏂囦欢鏉ヨ繘琛屾帓搴**
+
+濡備綍纭畾鏄惁浣跨敤浜嗙鐩樻枃浠舵潵杩涜鎺掑簭鍛紵 鍙互浣跨敤浠ヤ笅杩欏嚑涓懡浠
+
+```
+## 鎵撳紑optimizer_trace锛屽紑鍚粺璁
+set optimizer_trace = "enabled=on";
+## 鎵цSQL璇彞
+select name,age,city from staff where city = '娣卞湷' order by age limit 10;
+## 鏌ヨ杈撳嚭鐨勭粺璁′俊鎭
+select * from information_schema.optimizer_trace
+```
+
+鍙互浠 **number_of_tmp_files** 涓湅鍑猴紝鏄惁浣跨敤浜嗕复鏃舵枃浠躲
+
+
+
+
+
+**number_of_tmp_files** 琛ㄧず浣跨敤鏉ユ帓搴忕殑纾佺洏涓存椂鏂囦欢鏁般傚鏋渘umber_of_tmp_files>0锛屽垯琛ㄧず浣跨敤浜嗙鐩樻枃浠舵潵杩涜鎺掑簭銆
+
+浣跨敤浜嗙鐩樹复鏃舵枃浠讹紝鏁翠釜鎺掑簭杩囩▼鍙堟槸鎬庢牱鐨勫憿锛
+
+1. 浠**涓婚敭Id绱㈠紩鏍**锛屾嬁鍒伴渶瑕佺殑鏁版嵁锛屽苟鏀惧埌**sort_buffer鍐呭瓨**鍧椾腑銆傚綋sort_buffer蹇婊℃椂锛屽氨瀵箂ort_buffer涓殑鏁版嵁鎺掑簭锛屾帓瀹屽悗锛屾妸鏁版嵁涓存椂鏀惧埌纾佺洏涓涓皬鏂囦欢涓
+2. 缁х画鍥炲埌涓婚敭 id 绱㈠紩鏍戝彇鏁版嵁锛岀户缁斁鍒皊ort_buffer鍐呭瓨涓紝鎺掑簭鍚庯紝涔熸妸杩欎簺鏁版嵁鍐欏叆鍒扮鐩樹复鏃跺皬鏂囦欢涓
+3. 缁х画寰幆锛岀洿鍒板彇鍑烘墍鏈夋弧瓒虫潯浠剁殑鏁版嵁銆傛渶鍚庢妸纾佺洏鐨勪复鏃舵帓濂藉簭鐨勫皬鏂囦欢锛屽悎骞舵垚涓涓湁搴忕殑澶ф枃浠躲
+
+
+**TPS:** 鍊熷姪纾佺洏涓存椂灏忔枃浠舵帓搴忥紝瀹為檯涓婁娇鐢ㄧ殑鏄**褰掑苟鎺掑簭**绠楁硶銆
+
+灏忎紮浼翠滑鍙兘浼氭湁涓枒闂紝鏃㈢劧**sort_buffer**鏀句笉涓嬶紝灏遍渶瑕佺敤鍒颁复鏃剁鐩樻枃浠讹紝杩欎細褰卞搷鎺掑簭鏁堢巼銆傞偅涓轰粈涔堣繕瑕佹妸鎺掑簭涓嶇浉鍏崇殑瀛楁锛坣ame锛宑ity锛夋斁鍒皊ort_buffer涓憿锛熷彧鏀炬帓搴忕浉鍏崇殑age瀛楁锛屽畠**涓嶉**鍚楋紵 鍙互浜嗚В涓**rowid 鎺掑簭**銆
+
+
+### rowid 鎺掑簭
+
+rowid 鎺掑簭灏辨槸锛屽彧鎶婃煡璇QL**闇瑕佺敤浜庢帓搴忕殑瀛楁鍜屼富閿甶d**锛屾斁鍒皊ort_buffer涓傞偅鎬庝箞纭畾璧扮殑鏄叏瀛楁鎺掑簭杩樻槸rowid 鎺掑簭鎺掑簭鍛紵
+
+瀹為檯涓婃湁涓弬鏁版帶鍒剁殑銆傝繖涓弬鏁板氨鏄**max_length_for_sort_data**锛屽畠琛ㄧずMySQL鐢ㄤ簬鎺掑簭琛屾暟鎹殑闀垮害鐨勪竴涓弬鏁帮紝濡傛灉鍗曡鐨勯暱搴﹁秴杩囪繖涓硷紝MySQL 灏辫涓哄崟琛屽お澶э紝灏辨崲rowid 鎺掑簭銆傛垜浠彲浠ラ氳繃鍛戒护鐪嬩笅杩欎釜鍙傛暟鍙栧笺
+
+
+```
+show variables like 'max_length_for_sort_data';
+```
+
+
+
+**max_length_for_sort_data** 榛樿鍊兼槸1024銆傚洜涓烘湰鏂囩ず渚嬩腑name,age,city闀垮害=64+4+64 =132 < 1024, 鎵浠ヨ蛋鐨勬槸鍏ㄥ瓧娈垫帓搴忋傛垜浠潵鏀逛笅杩欎釜鍙傛暟锛屾敼灏忎竴鐐癸紝
+
+```
+## 淇敼鎺掑簭鏁版嵁鏈澶у崟琛岄暱搴︿负32
+set max_length_for_sort_data = 32;
+## 鎵ц鏌ヨSQL
+select name,age,city from staff where city = '娣卞湷' order by age limit 10;
+```
+
+浣跨敤rowid 鎺掑簭鐨勮瘽锛屾暣涓猄QL鎵ц娴佺▼鍙堟槸鎬庢牱鐨勫憿锛
+
+1. MySQL 涓哄搴旂殑绾跨▼鍒濆鍖**sort_buffer**锛屾斁鍏ラ渶瑕佹帓搴忕殑age瀛楁锛屼互鍙婁富閿甶d锛
+2. 浠**绱㈠紩鏍慽dx_city**锛 鎵惧埌绗竴涓弧瓒 city='娣卞湷鈥欐潯浠剁殑涓婚敭 id锛屼篃灏辨槸鍥句腑鐨刬d=9锛
+3. 鍒**涓婚敭 id 绱㈠紩鏍**鎷垮埌id=9鐨勮繖涓琛屾暟鎹紝 鍙朼ge鍜屼富閿甶d鐨勫硷紝瀛樺埌sort_buffer锛
+4. 浠**绱㈠紩鏍慽dx_city** 鎷垮埌涓嬩竴涓褰曠殑涓婚敭 id锛屽嵆鍥句腑鐨刬d=13锛
+5. 閲嶅姝ラ 3銆4 鐩村埌**city鐨勫间笉绛変簬娣卞湷**涓烘锛
+6. 鍓嶉潰5姝ュ凡缁忔煡鎵惧埌浜嗘墍鏈塩ity涓烘繁鍦崇殑鏁版嵁锛屽湪 **sort_buffer**涓紝灏嗘墍鏈夋暟鎹牴鎹產ge杩涜鎺掑簭锛
+7. 閬嶅巻鎺掑簭缁撴灉锛屽彇鍓10琛岋紝骞舵寜鐓 id 鐨勫**鍥炲埌鍘熻〃**涓紝鍙栧嚭city銆乶ame 鍜 age 涓変釜瀛楁杩斿洖缁欏鎴风銆
+
+
+鎵ц绀烘剰鍥惧涓嬶細
+
+
+
+
+
+瀵规瘮涓涓**鍏ㄥ瓧娈垫帓搴**鐨勬祦绋嬶紝rowid 鎺掑簭澶氫簡涓娆**鍥炶〃**銆
+
+> 浠涔堟槸鍥炶〃锛熸嬁鍒颁富閿啀鍥炲埌涓婚敭绱㈠紩鏌ヨ鐨勮繃绋嬶紝灏卞彨鍋氬洖琛
+
+
+鎴戜滑閫氳繃**optimizer_trace**锛屽彲浠ョ湅鍒版槸鍚︿娇鐢ㄤ簡rowid鎺掑簭鐨勶細
+
+
+```
+## 鎵撳紑optimizer_trace锛屽紑鍚粺璁
+set optimizer_trace = "enabled=on";
+## 鎵цSQL璇彞
+select name,age,city from staff where city = '娣卞湷' order by age limit 10;
+## 鏌ヨ杈撳嚭鐨勭粺璁′俊鎭
+select * from information_schema.optimizer_trace
+
+```
+
+
+
+
+### 鍏ㄥ瓧娈垫帓搴忎笌rowid鎺掑簭瀵规瘮
+
+
+- 鍏ㄥ瓧娈垫帓搴忥細 sort_buffer鍐呭瓨涓嶅鐨勮瘽锛屽氨闇瑕佺敤鍒扮鐩樹复鏃舵枃浠讹紝閫犳垚**纾佺洏璁块棶**銆
+- rowid鎺掑簭锛 sort_buffer鍙互鏀炬洿澶氭暟鎹紝浣嗘槸闇瑕佸啀鍥炲埌鍘熻〃鍘诲彇鏁版嵁锛屾瘮鍏ㄥ瓧娈垫帓搴忓涓娆**鍥炶〃**銆
+
+涓鑸儏鍐典笅锛屽浜嶪nnoDB瀛樺偍寮曟搸锛屼細浼樺厛浣**鐢ㄥ叏瀛楁**鎺掑簭銆傚彲浠ュ彂鐜 **max_length_for_sort_data** 鍙傛暟璁剧疆涓1024锛岃繖涓暟姣旇緝澶х殑銆備竴鑸儏鍐典笅锛屾帓搴忓瓧娈典笉浼氳秴杩囪繖涓硷紝涔熷氨鏄兘浼氳蛋**鍏ㄥ瓧娈**鎺掑簭銆
+
+
+## order by鐨勪竴浜涗紭鍖栨濊矾
+
+鎴戜滑濡備綍浼樺寲order by璇彞鍛紵
+
+
+- 鍥犱负鏁版嵁鏄棤搴忕殑锛屾墍浠ュ氨闇瑕佹帓搴忋傚鏋滄暟鎹湰韬槸鏈夊簭鐨勶紝閭ｅ氨涓嶇敤鎺掍簡銆傝岀储寮曟暟鎹湰韬槸鏈夊簭鐨勶紝鎴戜滑閫氳繃寤虹珛**鑱斿悎绱㈠紩**锛屼紭鍖杘rder by 璇彞銆
+- 鎴戜滑杩樺彲浠ラ氳繃璋冩暣**max_length_for_sort_data**绛夊弬鏁颁紭鍖栵紱
+
+
+### 鑱斿悎绱㈠紩浼樺寲
+
+鍐嶅洖椤句笅绀轰緥SQL鐨勬煡璇㈣鍒
+
+```
+explain select name,age,city from staff where city = '娣卞湷' order by age limit 10;
+```
+
+
+
+鎴戜滑缁欐煡璇㈡潯浠禶``city```鍜屾帓搴忓瓧娈礰``age```锛屽姞涓仈鍚堢储寮**idx_city_age**銆傚啀鍘绘煡鐪嬫墽琛岃鍒
+
+```
+alter table staff add index idx_city_age(city,age);
+explain select name,age,city from staff where city = '娣卞湷' order by age limit 10;
+```
+
+
+
+鍙互鍙戠幇锛屽姞涓**idx_city_age**鑱斿悎绱㈠紩锛屽氨涓嶉渶瑕**Using filesort**鎺掑簭浜嗐備负浠涔堝憿锛熷洜涓**绱㈠紩鏈韩鏄湁搴忕殑**锛屾垜浠彲浠ョ湅涓**idx_city_age**鑱斿悎绱㈠紩绀烘剰鍥撅紝濡備笅锛
+
+
+
+
+
+鏁翠釜SQL鎵ц娴佺▼鍙樻垚閰辩传锛
+1. 浠庣储寮昳dx_city_age鎵惧埌婊¤冻**city='娣卞湷鈥** 鐨勪富閿 id
+2. 鍒**涓婚敭 id绱㈠紩**鍙栧嚭鏁磋锛屾嬁鍒 name銆乧ity銆乤ge 涓変釜瀛楁鐨勫硷紝浣滀负缁撴灉闆嗙殑涓閮ㄥ垎鐩存帴杩斿洖
+3. 浠庣储寮**idx_city_age**鍙栦笅涓涓褰曚富閿甶d
+4. 閲嶅姝ラ 2銆3锛岀洿鍒版煡鍒**绗10鏉**璁板綍锛屾垨鑰呮槸**涓嶆弧瓒砪ity='娣卞湷鈥** 鏉′欢鏃跺惊鐜粨鏉熴
+
+娴佺▼绀烘剰鍥惧涓嬶細
+
+
+
+
+浠庣ず鎰忓浘鐪嬫潵锛岃繕鏄湁涓娆″洖琛ㄦ搷浣溿傞拡瀵规湰娆＄ず渚嬶紝鏈夋病鏈夋洿楂樻晥鐨勬柟妗堝憿锛熸湁鐨勶紝鍙互浣跨敤**瑕嗙洊绱㈠紩**锛
+
+> 瑕嗙洊绱㈠紩锛氬湪鏌ヨ鐨勬暟鎹垪閲岄潰锛屼笉闇瑕佸洖琛ㄥ幓鏌ワ紝鐩存帴浠庣储寮曞垪灏辫兘鍙栧埌鎯宠鐨勭粨鏋溿傛崲鍙ヨ瘽璇达紝浣燬QL鐢ㄥ埌鐨勭储寮曞垪鏁版嵁锛岃鐩栦簡鏌ヨ缁撴灉鐨勫垪锛屽氨绠椾笂瑕嗙洊绱㈠紩浜嗐
+
+鎴戜滑缁檆ity锛宯ame锛宎ge 缁勬垚涓涓仈鍚堢储寮曪紝鍗冲彲鐢ㄥ埌浜嗚鐩栫储寮曪紝杩欐椂鍊橲QL鎵ц鏃讹紝杩炲洖琛ㄦ搷浣滈兘鍙互鐪佸幓鍟︺
+
+### 璋冩暣鍙傛暟浼樺寲
+
+鎴戜滑杩樺彲浠ラ氳繃璋冩暣鍙傛暟锛屽幓浼樺寲order by鐨勬墽琛屻傛瘮濡傚彲浠ヨ皟鏁磗ort_buffer_size鐨勫笺傚洜涓簊ort_buffer鍊煎お灏忥紝鏁版嵁閲忓ぇ鐨勮瘽锛屼細鍊熷姪纾佺洏涓存椂鏂囦欢鎺掑簭銆傚鏋淢ySQL鏈嶅姟鍣ㄩ厤缃珮鐨勮瘽锛屽彲浠ヤ娇鐢ㄧ◢寰皟鏁村ぇ鐐广
+
+鎴戜滑杩樺彲浠ヨ皟鏁磎ax_length_for_sort_data鐨勫硷紝杩欎釜鍊煎お灏忕殑璇濓紝order by浼氳蛋rowid鎺掑簭锛屼細鍥炶〃锛岄檷浣庢煡璇㈡ц兘銆傛墍浠ax_length_for_sort_data鍙互閫傚綋澶т竴鐐广
+
+褰撶劧锛屽緢澶氭椂鍊欙紝杩欎簺MySQL鍙傛暟鍊硷紝鎴戜滑鐩存帴閲囩敤榛樿鍊煎氨鍙互浜嗐
+
+## 浣跨敤order by 鐨勪竴浜涙敞鎰忕偣
+
+### 娌℃湁where鏉′欢锛宱rder by瀛楁闇瑕佸姞绱㈠紩鍚
+
+鏃ュ父寮鍙戣繃绋嬩腑锛屾垜浠彲鑳戒細閬囧埌娌℃湁where鏉′欢鐨刼rder by锛岄偅涔堬紝杩欐椂鍊檕rder by鍚庨潰鐨勫瓧娈垫槸鍚﹂渶瑕佸姞绱㈠紩鍛€傚鏈夎繖涔堜竴涓猄QL锛宑reate_time鏄惁闇瑕佸姞绱㈠紩锛
+
+```
+select * from A order by create_time;
+```
+
+鏃犳潯浠舵煡璇㈢殑璇濓紝鍗充娇create_time涓婃湁绱㈠紩,涔熶笉浼氫娇鐢ㄥ埌銆傚洜涓篗ySQL浼樺寲鍣ㄨ涓鸿蛋鏅氫簩绾х储寮曪紝鍐嶅幓鍥炶〃鎴愭湰姣斿叏琛ㄦ壂鎻忔帓搴忔洿楂樸傛墍浠ラ夋嫨璧板叏琛ㄦ壂鎻,鐒跺悗鏍规嵁鍏ㄥ瓧娈垫帓搴忔垨鑰卹owid鎺掑簭鏉ヨ繘琛屻
+
+濡傛灉鏌ヨSQL淇敼涓涓嬶細
+
+```
+select * from A order by create_time limit m;
+```
+- 鏃犳潯浠舵煡璇,濡傛灉m鍊艰緝灏,鏄彲浠ヨ蛋绱㈠紩鐨.鍥犱负MySQL浼樺寲鍣ㄨ涓猴紝鏍规嵁绱㈠紩鏈夊簭鎬у幓鍥炶〃鏌ユ暟鎹,鐒跺悗寰楀埌m鏉℃暟鎹,灏卞彲浠ョ粓姝㈠惊鐜,閭ｄ箞鎴愭湰姣斿叏琛ㄦ壂鎻忓皬,鍒欓夋嫨璧颁簩绾х储寮曘
+
+
+### 鍒嗛〉limit杩囧ぇ鏃讹紝浼氬鑷村ぇ閲忔帓搴忔庝箞鍔?
+
+鍋囪SQL濡備笅锛
+```
+select * from A order by a limit 100000,10
+```
+
+- 鍙互璁板綍涓婁竴椤垫渶鍚庣殑id锛屼笅涓椤垫煡璇㈡椂锛屾煡璇㈡潯浠跺甫涓奿d锛屽锛 where id > 涓婁竴椤垫渶鍚巌d limit 10銆
+- 涔熷彲浠ュ湪涓氬姟鍏佽鐨勬儏鍐典笅锛岄檺鍒堕〉鏁般
+
+
+### 绱㈠紩瀛樺偍椤哄簭涓巓rder by涓嶄竴鑷达紝濡備綍浼樺寲锛
+
+鍋囪鏈夎仈鍚堢储寮 idx_age_name, 鎴戜滑闇姹備慨鏀逛负杩欐牱锛**鏌ヨ鍓10涓憳宸ョ殑濮撳悕銆佸勾榫勶紝骞朵笖鎸夌収骞撮緞灏忓埌澶ф帓搴忥紝濡傛灉骞撮緞鐩稿悓锛屽垯鎸夊鍚嶉檷搴忔帓**銆傚搴旂殑 SQL 璇彞灏卞彲浠ヨ繖涔堝啓锛
+
+```
+select name,age from staff order by age ,name desc limit 10;
+```
+鎴戜滑鐪嬩笅鎵ц璁″垝锛屽彂鐜颁娇鐢ㄥ埌**Using filesort**銆
+
+
+
+杩欐槸鍥犱负锛宨dx_age_name绱㈠紩鏍戜腑锛宎ge浠庡皬鍒板ぇ鎺掑簭锛屽鏋**age鐩稿悓锛屽啀鎸塶ame浠庡皬鍒板ぇ鎺掑簭**銆傝宱rder by 涓紝鏄寜age浠庡皬鍒板ぇ鎺掑簭锛屽鏋**age鐩稿悓锛屽啀鎸塶ame浠庡ぇ鍒板皬鎺掑簭**銆備篃灏辨槸璇达紝绱㈠紩瀛樺偍椤哄簭涓巓rder by涓嶄竴鑷淬
+
+鎴戜滑鎬庝箞浼樺寲鍛紵濡傛灉MySQL鏄8.0鐗堟湰锛屾敮鎸**Descending Indexes**锛屽彲浠ヨ繖鏍蜂慨鏀圭储寮曪細
+
+```
+CREATE TABLE `staff` (
+ `id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT '涓婚敭id',
+ `id_card` varchar(20) NOT NULL COMMENT '韬唤璇佸彿鐮',
+ `name` varchar(64) NOT NULL COMMENT '濮撳悕',
+ `age` int(4) NOT NULL COMMENT '骞撮緞',
+ `city` varchar(64) NOT NULL COMMENT '鍩庡競',
+ PRIMARY KEY (`id`),
+ KEY `idx_age_name` (`age`,`name` desc) USING BTREE
+) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8 COMMENT='鍛樺伐琛';
+```
+
+
+### 浣跨敤浜唅n鏉′欢澶氫釜灞炴ф椂锛孲QL鎵ц鏄惁鏈夋帓搴忚繃绋
+
+濡傛灉鎴戜滑鏈**鑱斿悎绱㈠紩idx_city_name**锛屾墽琛岃繖涓猄QL鐨勮瘽锛屾槸涓嶄細璧版帓搴忚繃绋嬬殑锛屽涓嬶細
+
+```
+select * from staff where city in ('娣卞湷') order by age limit 10;
+```
+
+
+
+
+
+浣嗘槸锛屽鏋滀娇鐢╥n鏉′欢锛屽苟涓旀湁澶氫釜鏉′欢鏃讹紝灏变細鏈夋帓搴忚繃绋嬨
+
+```
+ explain select * from staff where city in ('娣卞湷','涓婃捣') order by age limit 10;
+```
+
+
+
+杩欐槸鍥犱负:in鏈変袱涓潯浠讹紝鍦ㄦ弧瓒虫繁鍦虫椂锛宎ge鏄帓濂藉簭鐨勶紝浣嗘槸鎶婃弧瓒充笂娴风殑age涔熷姞杩涙潵锛屽氨涓嶈兘淇濊瘉婊¤冻鎵鏈夌殑age閮芥槸鎺掑ソ搴忕殑銆傚洜姝ら渶瑕乁sing filesort銆
+
+## 鏈鍚
+
+- 濡傛灉瑙夊緱鏈夋敹鑾凤紝甯繖鐐硅禐锛岃浆鍙戜笅鍝堬紝鎰熻阿鎰熻阿
+- 寰俊鎼滅储鍏紬鍙凤細**鎹＄敯铻虹殑灏忕敺瀛**锛屽姞涓ソ鍙嬶紝杩涙妧鏈氦娴佺兢
+
+
+### 鍙傝冧笌鎰熻阿
+
+- MySQL瀹炴垬45璁
+
+
+
From 46430483bac498e923f85ac4768040d32e72eff8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E6=8D=A1=E7=94=B0=E8=9E=BA=E7=9A=84=E5=B0=8F=E7=94=B7?=
=?UTF-8?q?=E5=AD=A9?= <327658337@qq.com>
Date: Sun, 10 Oct 2021 23:16:51 +0800
Subject: [PATCH 05/51] Add files via upload
---
...23\345\215\260\350\247\204\350\214\203.md" | 269 ++++++++++++++++++
1 file changed, 269 insertions(+)
create mode 100644 "\345\267\245\344\275\234\346\200\273\347\273\223/\346\227\245\345\277\227\346\211\223\345\215\260\350\247\204\350\214\203.md"
diff --git "a/\345\267\245\344\275\234\346\200\273\347\273\223/\346\227\245\345\277\227\346\211\223\345\215\260\350\247\204\350\214\203.md" "b/\345\267\245\344\275\234\346\200\273\347\273\223/\346\227\245\345\277\227\346\211\223\345\215\260\350\247\204\350\214\203.md"
new file mode 100644
index 0000000..4577332
--- /dev/null
+++ "b/\345\267\245\344\275\234\346\200\273\347\273\223/\346\227\245\345\277\227\346\211\223\345\215\260\350\247\204\350\214\203.md"
@@ -0,0 +1,269 @@
+## 前言
+
+大家好，我是**捡田螺的小男孩**。日志是快速定位问题的好帮手，是**撕逼和甩锅**的利器！打印好日志非常重要。今天我们来聊聊**日志打印**的15个好建议~
+
+- 公众号：**捡田螺的小男孩**
+
+
+## 1. 选择恰当的日志级别
+
+常见的日志级别有5种，分别是error、warn、info、debug、trace。日常开发中，我们需要选择恰当的日志级别，不要反手就是打印info哈~
+
+
+
+- error：错误日志，指比较严重的错误，对正常业务有影响，需要**运维配置监控的**；
+- warn：警告日志，一般的错误，对业务影响不大，但是需要**开发关注**；
+- info：信息日志，记录排查问题的关键信息，如调用时间、出参入参等等；
+- debug：用于开发DEBUG的，关键逻辑里面的运行时数据；
+- trace：最详细的信息，一般这些信息只记录到日志文件中。
+
+
+## 2. 日志要打印出方法的入参、出参
+
+我们并不需要打印很多很多日志，只需要打印可以**快速定位问题的有效日志**。有效的日志，是甩锅的利器！
+
+
+
+哪些算得的上**有效关键**的日志呢？比如说，方法进来的时候，打印**入参**。再然后呢，在方法返回的时候，就是**打印出参，返回值**。入参的话，一般就是**userId或者bizSeq这些关键**信息。正例如下：
+
+```
+public String testLogMethod(Document doc, Mode mode){
+ log.debug(“method enter param：{}”,userId);
+ String id = "666";
+ log.debug(“method exit param：{}”,id);
+ return id;
+}
+```
+
+
+## 3. 选择合适的日志格式
+
+理想的日志格式，应当包括这些最基本的信息：如当**前时间戳**（一般毫秒精确度）、**日志级别**，**线程名字**等等。在logback日志里可以这么配置：
+
+```
+
+
+ %d{HH:mm:ss.SSS} %-5level [%thread][%logger{0}] %m%n
+
+
+```
+
+如果我们的日志格式，连当前时间都沒有记录，那**连请求的时间点都不知道了**？
+
+
+
+
+## 4. 遇到if...else...等条件时，每个分支首行都尽量打印日志
+
+当你碰到**if...else...或者switch**这样的条件时，可以在分支的首行就打印日志，这样排查问题时，就可以通过日志，确定进入了哪个分支，代码逻辑更清晰，也更方便排查问题了。
+
+
+
+
+正例：
+```
+if(user.isVip()){
+ log.info("该用户是会员,Id:{},开始处理会员逻辑",user,getUserId());
+ //会员逻辑
+}else{
+ log.info("该用户是非会员,Id:{},开始处理非会员逻辑",user,getUserId())
+ //非会员逻辑
+}
+```
+
+## 5.日志级别比较低时，进行日志开关判断
+
+对于trace/debug这些比较低的日志级别，必须进行日志级别的开关判断。
+
+正例：
+```
+User user = new User(666L, "公众号", "捡田螺的小男孩");
+if (log.isDebugEnabled()) {
+ log.debug("userId is: {}", user.getId());
+}
+```
+
+因为当前有如下的日志代码：
+```
+logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);
+```
+
+如果**配置的日志级别是warn**的话，上述日志不会打印，但是会执行字符串拼接操作，如果```symbol```是对象，
+还会执行```toString()```方法，浪费了系统资源，执行了上述操作，最终日志却没有打印，因此建议**加日志开关判断。**
+
+## 6. 不能直接使用日志系统（Log4j、Logback）中的 API，而是使用日志框架SLF4J中的API。
+
+SLF4J 是门面模式的日志框架，有利于维护和各个类的日志处理方式统一，并且可以在保证不修改代码的情况下，很方便的实现底层日志框架的更换。
+
+
+
+正例：
+```
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+private static final Logger logger = LoggerFactory.getLogger(TianLuoBoy.class);
+```
+
+## 7. 建议使用参数占位{}，而不是用+拼接。
+
+反例：
+```
+logger.info("Processing trade with id: " + id + " and symbol: " + symbol);
+```
+
+上面的例子中，使用```+```操作符进行字符串的拼接，有一定的**性能损耗**。
+
+正例如下：
+```
+logger.info("Processing trade with id: {} and symbol : {} ", id, symbol);
+```
+我们使用了大括号```{}```来作为日志中的占位符，比于使用```+```操作符，更加优雅简洁。并且，**相对于反例**，使用占位符仅是替换动作，可以有效提升性能。
+
+## 8. 建议使用异步的方式来输出日志。
+
+- 日志最终会输出到文件或者其它输出流中的，IO性能会有要求的。如果异步，就可以显著提升IO性能。
+- 除非有特殊要求，要不然建议使用异步的方式来输出日志。以logback为例吧，要配置异步很简单，使用AsyncAppender就行
+```
+
+
+
+```
+
+## 9. 不要使用e.printStackTrace()
+
+
+
+
+
+反例：
+```
+try{
+ // 业务代码处理
+}catch(Exception e){
+ e.printStackTrace();
+}
+```
+正例：
+```
+try{
+ // 业务代码处理
+}catch(Exception e){
+ log.error("你的程序有异常啦",e);
+}
+```
+
+**理由：**
+
+- e.printStackTrace()打印出的堆栈日志跟业务代码日志是交错混合在一起的，通常排查异常日志不太方便。
+- e.printStackTrace()语句产生的字符串记录的是堆栈信息，如果信息太长太多，字符串常量池所在的内存块没有空间了,即内存满了，那么，用户的请求就卡住啦~
+
+## 10. 异常日志不要只打一半，要输出全部错误信息
+
+
+
+反例1：
+
+```
+try {
+ //业务代码处理
+} catch (Exception e) {
+ // 错误
+ LOG.error('你的程序有异常啦');
+}
+
+```
+- 异常e都没有打印出来，所以压根不知道出了什么类型的异常。
+
+反例2：
+```
+try {
+ //业务代码处理
+} catch (Exception e) {
+ // 错误
+ LOG.error('你的程序有异常啦', e.getMessage());
+}
+```
+
+- ```e.getMessage()```不会记录详细的堆栈异常信息，只会记录错误基本描述信息，不利于排查问题。
+
+正例：
+
+```
+try {
+ //业务代码处理
+} catch (Exception e) {
+ // 错误
+ LOG.error('你的程序有异常啦', e);
+}
+```
+
+## 11. 禁止在线上环境开启 debug
+
+禁止在线上环境开启debug，这一点非常重要。
+
+
+因为一般系统的debug日志会很多，并且各种框架中也大量使用 debug的日志，线上开启debug不久可能会打满磁盘，影响业务系统的正常运行。
+
+## 12.不要记录了异常，又抛出异常
+
+
+
+
+
+反例如下：
+```
+log.error("IO exception", e);
+throw new MyException(e);
+```
+
+- 这样实现的话，通常会把栈信息打印两次。这是因为捕获了MyException异常的地方，还会再打印一次。
+- 这样的日志记录，或者包装后再抛出去，不要同时使用！否则你的日志看起来会让人很迷惑。
+
+
+## 13.避免重复打印日志
+
+避免重复打印日志，酱紫会浪费磁盘空间。如果你已经有一行日志清楚表达了意思，**避免再冗余打印**，反例如下：
+
+```
+if(user.isVip()){
+ log.info("该用户是会员,Id:{}",user,getUserId());
+ //冗余，可以跟前面的日志合并一起
+ log.info("开始处理会员逻辑,id:{}",user,getUserId());
+ //会员逻辑
+}else{
+ //非会员逻辑
+}
+```
+
+如果你是使用log4j日志框架，务必在```log4j.xml```中设置 additivity=false，因为可以避免重复打印日志
+
+正例：
+```
+
+```
+
+## 14.日志文件分离
+
+
+
+
+
+- 我们可以把不同类型的日志分离出去，比如access.log，或者error级别error.log，都可以单独打印到一个文件里面。
+- 当然，也可以根据不同的业务模块，打印到不同的日志文件里，这样我们排查问题和做数据统计的时候，都会比较方便啦。
+
+
+## 15. 核心功能模块，建议打印较完整的日志
+
+
+
+
+
+- 我们日常开发中，如果核心或者逻辑复杂的代码，建议添加详细的注释，以及较详细的日志。
+- 日志要多详细呢？脑洞一下，如果你的核心程序哪一步出错了，通过日志可以定位到，那就可以啦。
+
+
+
+
+
+
From 93194b68365941438a9d904fa1b3e9c258f7e28a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E6=8D=A1=E7=94=B0=E8=9E=BA=E7=9A=84=E5=B0=8F=E7=94=B7?=
=?UTF-8?q?=E5=AD=A9?= <327658337@qq.com>
Date: Sun, 10 Oct 2021 23:17:47 +0800
Subject: [PATCH 06/51] Update README.md
---
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README.md b/README.md
index 6018cc3..214c8ab 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
## 涓汉鍏紬鍙
-
+寰俊鎼滐細鎹＄敯铻虹殑灏忕敺瀛
- 濡傛灉浣犳槸涓埍瀛︿範鐨勫ソ瀛╁瓙锛屽彲浠ュ叧娉ㄦ垜鍏紬鍙凤紝涓璧峰涔犺璁哄搱~~
From 6cd2682a3f262f88a9db736c5402df01c6aefc20 Mon Sep 17 00:00:00 2001
From: whx123 <327658337@qq.com>
Date: Mon, 6 Jun 2022 08:23:10 +0800
Subject: [PATCH 07/51] mhouduansiwei
---
...36\344\270\252\351\224\246\345\233\212.md" | 540 ++++++++++++++++
...03\347\224\250\346\250\241\346\235\277.md" | 599 ++++++++++++++++++
2 files changed, 1139 insertions(+)
create mode 100644 "\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207/\345\220\216\347\253\257\346\200\235\347\273\264\344\270\200\357\274\232\350\256\276\350\256\241\346\216\245\345\217\243\347\232\20436\344\270\252\351\224\246\345\233\212.md"
create mode 100644 "\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207\344\272\214\357\274\232\346\211\213\346\212\212\346\211\213\346\225\231\344\275\240\345\256\236\347\216\260\344\270\200\344\270\252\345\271\266\350\241\214\350\260\203\347\224\250\346\250\241\346\235\277.md"
diff --git "a/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207/\345\220\216\347\253\257\346\200\235\347\273\264\344\270\200\357\274\232\350\256\276\350\256\241\346\216\245\345\217\243\347\232\20436\344\270\252\351\224\246\345\233\212.md" "b/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207/\345\220\216\347\253\257\346\200\235\347\273\264\344\270\200\357\274\232\350\256\276\350\256\241\346\216\245\345\217\243\347\232\20436\344\270\252\351\224\246\345\233\212.md"
new file mode 100644
index 0000000..f999d6b
--- /dev/null
+++ "b/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207/\345\220\216\347\253\257\346\200\235\347\273\264\344\270\200\357\274\232\350\256\276\350\256\241\346\216\245\345\217\243\347\232\20436\344\270\252\351\224\246\345\233\212.md"
@@ -0,0 +1,540 @@
+## 前言
+
+大家好，我是捡田螺的小男孩。作为后端开发，不管是什么语言，```Java```、```Go```还是```C++```，其背后的后端思想都是类似的。后面打算出一个后端思想的技术专栏，主要包括后端的一些设计、或者后端规范相关的，希望对大家日常工作有帮助哈。
+
+我们做后端开发工程师，主要工作就是：**如何把一个接口设计好**。所以，今天就给大家介绍，设计好接口的36个锦囊。本文就是后端思想专栏的第一篇哈。
+
+
+
+
+- 公众号：捡田螺的小男孩
+
+
+## 1. 接口参数校验
+
+入参出参校验是每个程序员必备的基本素养。你设计的接口，必须先校验参数。比如入参是否允许为空，入参长度是否符合你的预期长度。这个要养成习惯哈，日常开发中，很多低级bug都是不校验参数导致的。
+
+> 比如你的数据库表字段设置为```varchar(16)```,对方传了一个32位的字符串过来，如果你不校验参数，**插入数据库直接异常了**。
+
+出参也是，比如你定义的接口报文，参数是不为空的，但是你的接口返回参数，没有做校验，因为程序某些原因，直返回别人一个```null```值。。。
+
+
+
+## 2. 修改老接口时，注意接口的兼容性
+
+很多bug都是因为修改了对外旧接口，但是却**不做兼容**导致的。关键这个问题多数是比较严重的，可能直接导致系统发版失败的。新手程序员很容易犯这个错误哦~
+
+
+
+所以，如果你的需求是在原来接口上修改，尤其这个接口是对外提供服务的话，一定要考虑接口兼容。举个例子吧，比如dubbo接口，原本是只接收A，B参数，现在你加了一个参数C，就可以考虑这样处理：
+
+```
+//老接口
+void oldService(A,B){
+ //兼容新接口，传个null代替C
+ newService(A,B,null);
+}
+
+//新接口，暂时不能删掉老接口，需要做兼容。
+void newService(A,B,C){
+ ...
+}
+```
+
+## 3. 设计接口时，充分考虑接口的可扩展性
+
+要根据实际业务场景设计接口，充分考虑接口的可扩展性。
+
+比如你接到一个需求：是用户添加或者修改员工时，需要刷脸。那你是反手提供一个员工管理的提交刷脸信息接口？还是先思考：提交刷脸是不是通用流程呢？比如转账或者一键贴现需要接入刷脸的话，你是否需要重新实现一个接口呢？还是当前按业务类型划分模块，复用这个接口就好，保留接口的可扩展性。
+
+如果按模块划分的话，未来如果其他场景比如一键贴现接入刷脸的话，不用再搞一套新的接口，只需要新增枚举，然后复用刷脸通过流程接口，实现一键贴现刷脸的差异化即可。
+
+
+
+
+## 4.接口考虑是否需要防重处理
+
+如果前端重复请求，你的逻辑如何处理？是不是考虑接口去重处理。
+
+当然，如果是查询类的请求，其实不用防重。如果是更新修改类的话，尤其金融转账类的，就要过滤重复请求了。简单点，你可以使用Redis防重复请求，同样的请求方，一定时间间隔内的相同请求，考虑是否过滤。当然，转账类接口，并发不高的话，**推荐使用数据库防重表**，以**唯一流水号作为主键或者唯一索引**。
+
+
+
+
+## 5. 重点接口，考虑线程池隔离。
+
+一些登陆、转账交易、下单等重要接口，考虑线程池隔离哈。如果你所有业务都共用一个线程池，有些业务出bug导致线程池阻塞打满的话，那就杯具了，**所有业务都影响了**。因此进行线程池隔离，重要业务分配多一点的核心线程，就更好保护重要业务。
+
+
+
+
+## 6. 调用第三方接口要考虑异常和超时处理
+
+如果你调用第三方接口，或者分布式远程服务的的话，需要考虑：
+
+- 异常处理
+
+> 比如，你调别人的接口，如果异常了，怎么处理，是重试还是当做失败还是告警处理。
+
+- 接口超时
+
+> 没法预估对方接口一般多久返回，一般设置个超时断开时间，以保护你的接口。**之前见过一个生产问题**，就是http调用不设置超时时间，最后响应方进程假死，请求一直占着线程不释放，拖垮线程池。
+
+- 重试次数
+> 你的接口调失败，需不需要重试？重试几次？需要站在业务上角度思考这个问题
+
+
+
+
+## 7. 接口实现考虑熔断和降级
+
+当前互联网系统一般都是分布式部署的。而分布式系统中经常会出现某个基础服务不可用，最终导致整个系统不可用的情况, 这种现象被称为**服务雪崩效应**。
+
+比如分布式调用链路```A->B->C....```，下图所示：
+
+
+
+> 如果服务C出现问题，比如是**因为慢SQL导致调用缓慢**，那将导致B也会延迟，从而A也会延迟。堵住的A请求会消耗占用系统的线程、IO等资源。 当请求A的服务越来越多，占用计算机的资源也越来越多，最终会导致系统瓶颈出现，造成其他的请求同样不可用，最后导致业务系统崩溃。
+
+为了应对服务雪崩, 常见的做法是**熔断和降级**。最简单是加开关控制，当下游系统出问题时，开关降级，不再调用下游系统。还可以选用开源组件```Hystrix```。
+
+## 8. 日志打印好，接口的关键代码，要有日志保驾护航。
+
+关键业务代码无论身处何地，都应该有足够的日志保驾护航。
+比如：你实现转账业务，转个几百万，然后转失败了，接着客户投诉，然后你还没有打印到日志，想想那种水深火热的困境下，你却毫无办法。。。
+
+那么，你的转账业务都需要那些日志信息呢？至少，方法调用前，入参需要打印需要吧，接口调用后，需要捕获一下异常吧，同时打印异常相关日志吧，如下：
+```
+public void transfer(TransferDTO transferDTO){
+ log.info("invoke tranfer begin");
+ //打印入参
+ log.info("invoke tranfer,paramters:{}",transferDTO);
+ try {
+ res= transferService.transfer(transferDTO);
+ }catch(Exception e){
+ log.error("transfer fail,account：{}",
+ transferDTO.getAccount（）)
+ log.error("transfer fail,exception:{}",e);
+ }
+ log.info("invoke tranfer end");
+ }
+```
+
+之前写过一篇打印日志的15个建议，大家可以看看哈：[工作总结！日志打印的15个建议](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247494838&idx=1&sn=cdb15fd346bddf3f8c1c99f0efbd67d8&chksm=cf22339ff855ba891616c79d4f4855e228e34a9fb45088d7acbe421ad511b8d090a90f5b019f&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
+
+## 9. 接口的功能定义要具备单一性
+
+单一性是指接口做的事情比较单一、专一。比如一个登陆接口，它做的事情就只是校验账户名密码，然后返回登陆成功以及```userId```即可。**但是如果你为了减少接口交互，把一些注册、一些配置查询等全放到登陆接口，就不太妥。**
+
+其实这也是微服务一些思想，接口的功能单一、明确。比如订单服务、积分、商品信息相关的接口都是划分开的。将来拆分微服务的话，是不是就比较简便啦。
+
+
+## 10.接口有些场景，使用异步更合理
+
+举个简单的例子，比如你实现一个用户注册的接口。用户注册成功时，发个邮件或者短信去通知用户。这个邮件或者发短信，就更适合异步处理。因为总不能一个通知类的失败，导致注册失败吧。
+
+至于做异步的方式，简单的就是**用线程池**。还可以使用消息队列，就是用户注册成功后，生产者产生一个注册成功的消息，消费者拉到注册成功的消息，就发送通知。
+
+
+
+
+不是所有的接口都适合设计为同步接口。比如你要做一个转账的功能，如果你是单笔的转账，你是可以把接口设计同步。用户发起转账时，客户端在静静等待转账结果就好。如果你是批量转账，一个批次一千笔，甚至一万笔的，你则可以把接口设计为异步。就是用户发起批量转账时，持久化成功就先返回受理成功。然后用户隔十分钟或者十五分钟等再来查转账结果就好。又或者，批量转账成功后，再回调上游系统。
+
+
+
+
+
+## 11. 优化接口耗时，远程串行考虑改并行调用
+
+假设我们设计一个APP首页的接口，它需要查用户信息、需要查banner信息、需要查弹窗信息等等。那你是一个一个接口串行调，还是并行调用呢？
+
+
+
+
+如果是串行一个一个查，比如查用户信息200ms，查banner信息100ms、查弹窗信息50ms，那一共就耗时```350ms```了，如果还查其他信息，那耗时就更大了。这种场景是可以改为并行调用的。也就是说查用户信息、查banner信息、查弹窗信息，可以同时发起。
+
+
+
+
+在Java中有个异步编程利器：```CompletableFuture```，就可以很好实现这个功能。有兴趣的小伙伴可以看我之前这个文章哈：[CompletableFuture详解](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247490456&idx=1&sn=95836324db57673a4d7aea4fb233c0d2&chksm=cf21c4b1f8564da72dc7b39279362bcf965b1374540f3b339413d138599f7de59a5f977e3b0e&token=1260947715&lang=zh_CN#rd)
+
+## 12. 接口合并或者说考虑批量处理思想
+
+数据库操作或或者是远程调用时，能批量操作就不要for循环调用。
+
+
+一个简单例子，我们平时一个列表明细数据插入数据库时，不要在for循环一条一条插入，建议一个批次几百条，进行批量插入。同理远程调用也类似想法，比如你查询营销标签是否命中，可以一个标签一个标签去查，也可以批量标签去查，那批量进行，效率就更高嘛。
+
+```
+//反例
+for(int i=0;i 比如一些平时变动很小或者说几乎不会变的商品信息，可以放到缓存，请求过来时，先查询缓存，如果没有再查数据库，并且把数据库的数据更新到缓存。但是，使用缓存增加了需要考虑这些点：缓存和数据库一致性如何保证、集群、缓存击穿、缓存雪奔、缓存穿透等问题。
+
+- 保证数据库和缓存一致性：**缓存延时双删、删除缓存重试机制、读取biglog异步删除缓存**
+- 缓存击穿：设置数据永不过期
+- 缓存雪奔：Redis集群高可用、均匀设置过期时间
+- 缓存穿透：接口层校验、查询为空设置个默认空值标记、布隆过滤器。
+
+一般用```Redis```分布式缓存，当然有些时候也可以考虑使用本地缓存，如```Guava Cache、Caffeine```等。使用本地缓存有些缺点，就是无法进行大数据存储，并且应用进程的重启，缓存会失效。
+
+## 14. 接口考虑热点数据隔离性
+
+瞬时间的高并发，可能会打垮你的系统。可以做一些热点数据的隔离。比如**业务隔离、系统隔离、用户隔离、数据隔离**等。
+
+- 业务隔离性，比如12306的分时段售票，将热点数据分散处理，降低系统负载压力。
+- 系统隔离：比如把系统分成了用户、商品、社区三个板块。这三个块分别使用不同的域名、服务器和数据库，做到从接入层到应用层再到数据层三层完全隔离。
+- 用户隔离：重点用户请求到配置更好的机器。
+- 数据隔离：使用单独的缓存集群或者数据库服务热点数据。
+
+## 15. 可变参数配置化，比如红包皮肤切换等
+
+假如产品经理提了个红包需求，圣诞节的时候，红包皮肤为圣诞节相关的，春节的时候，为春节红包皮肤等。
+
+如果在代码写死控制，可有类似以下代码：
+```
+if(duringChristmas){
+ img = redPacketChristmasSkin;
+}else if(duringSpringFestival){
+ img = redSpringFestivalSkin;
+}
+```
+如果到了元宵节的时候，运营小姐姐突然又有想法，红包皮肤换成灯笼相关的，这时候，是不是要去修改代码了，重新发布了？
+
+从一开始接口设计时，可以实现**一张红包皮肤的配置表**，将红包皮肤做成配置化呢？更换红包皮肤，只需修改一下表数据就好了。
+
+当然，还有一些场景适合一些配置化的参数：一个分页多少数量控制、某个抢红包多久时间过期这些，都可以搞到参数配置化表里面。**这也是扩展性思想的一种体现。**
+
+## 16.接口考虑幂等性
+
+接口是需要考虑幂等性的，尤其抢红包、转账这些重要接口。最直观的业务场景，就是**用户连着点击两次**，你的接口有没有**hold住**。或者消息队列出现重复消费的情况，你的业务逻辑怎么控制？
+
+回忆下，**什么是幂等？**
+
+> 计算机科学中，幂等表示一次和多次请求某一个资源应该具有同样的副作用，或者说，多次请求所产生的影响与一次请求执行的影响效果相同。
+
+大家别搞混哈，**防重和幂等设计其实是有区别的**。防重主要为了避免产生重复数据，把重复请求拦截下来即可。而幂等设计除了拦截已经处理的请求，还要求每次相同的请求都返回一样的效果。不过呢，很多时候，它们的处理流程、方案是类似的哈。
+
+
+
+
+接口幂等实现方案主要有8种：
+
+- select+insert+主键/唯一索引冲突
+- 直接insert + 主键/唯一索引冲突
+- 状态机幂等
+- 抽取防重表
+- token令牌
+- 悲观锁
+- 乐观锁
+- 分布式锁
+
+大家可以看我这篇文章哈：[聊聊幂等设计](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247497427&idx=1&sn=2ed160c9917ad989eee1ac60d6122855&chksm=cf2229faf855a0ecf5eb34c7335acdf6420426490ee99fc2b602d54ff4ffcecfdab24eeab0a3&token=1260947715&lang=zh_CN#rd)
+
+## 17. 读写分离，优先考虑读从库，注意主从延迟问题
+
+我们的数据库都是集群部署的，有主库也有从库，当前一般都是读写分离的。比如你写入数据，肯定是写入主库，但是对于读取实时性要求不高的数据，则优先考虑读从库，因为可以分担主库的压力。
+
+如果读取从库的话，需要考虑主从延迟的问题。
+
+## 18.接口注意返回的数据量，如果数据量大需要分页
+
+一个接口返回报文，不应该包含过多的数据量。过多的数据量不仅处理复杂，并且数据量传输的压力也非常大。因此数量实在是比较大，可以分页返回，如果是功能不相关的报文，那应该考虑接口拆分。
+
+## 19. 好的接口实现，离不开SQL优化
+
+我们做后端的，写好一个接口，离不开SQL优化。
+
+SQL优化从这几个维度思考：
+
+- explain 分析SQL查询计划（重点关注type、extra、filtered字段）
+- show profile分析，了解SQL执行的线程的状态以及消耗的时间
+- 索引优化 （覆盖索引、最左前缀原则、隐式转换、order by以及group by的优化、join优化）
+- 大分页问题优化（延迟关联、记录上一页最大ID）
+- 数据量太大（**分库分表**、同步到es，用es查询）
+
+## 20.代码锁的粒度控制好
+
+什么是加锁粒度呢？
+
+> 其实就是就是你要锁住的范围是多大。比如你在家上卫生间，你只要锁住卫生间就可以了吧，不需要将整个家都锁起来不让家人进门吧，卫生间就是你的加锁粒度。
+
+我们写代码时，如果不涉及到共享资源，就没有必要锁住的。这就好像你上卫生间，不用把整个家都锁住，锁住卫生间门就可以了。
+
+比如，在业务代码中，有一个ArrayList因为涉及到多线程操作，所以需要加锁操作，假设刚好又有一段比较耗时的操作（代码中的```slowNotShare```方法）不涉及线程安全问题，你会如何加锁呢？
+
+反例：
+```
+//不涉及共享资源的慢方法
+private void slowNotShare() {
+ try {
+ TimeUnit.MILLISECONDS.sleep(100);
+ } catch (InterruptedException e) {
+ }
+}
+
+//错误的加锁方法
+public int wrong() {
+ long beginTime = System.currentTimeMillis();
+ IntStream.rangeClosed(1, 10000).parallel().forEach(i -> {
+ //加锁粒度太粗了，slowNotShare其实不涉及共享资源
+ synchronized (this) {
+ slowNotShare();
+ data.add(i);
+ }
+ });
+ log.info("cosume time:{}", System.currentTimeMillis() - beginTime);
+ return data.size();
+}
+```
+
+正例：
+```
+public int right() {
+ long beginTime = System.currentTimeMillis();
+ IntStream.rangeClosed(1, 10000).parallel().forEach(i -> {
+ slowNotShare();//可以不加锁
+ //只对List这部分加锁
+ synchronized (data) {
+ data.add(i);
+ }
+ });
+ log.info("cosume time:{}", System.currentTimeMillis() - beginTime);
+ return data.size();
+}
+```
+
+## 21.接口状态和错误需要统一明确
+
+提供必要的接口调用状态信息。比如你的一个转账接口调用是成功、失败、处理中还是受理成功等，需要明确告诉客户端。如果接口失败，那么具体失败的原因是什么。这些必要的信息都必须要告诉给客户端，因此需要定义明确的错误码和对应的描述。同时，尽量对报错信息封装一下，不要把后端的异常信息完全抛出到客户端。
+
+
+
+
+## 22.接口要考虑异常处理
+
+实现一个好的接口，离不开优雅的异常处理。对于异常处理，提十个小建议吧：
+
+- 尽量不要使用```e.printStackTrace()```,而是使用```log```打印。因为```e.printStackTrace()```语句可能会导致内存占满。
+- ```catch```住异常时，建议打印出具体的```exception```，利于更好定位问题
+- 不要用一个```Exception```捕捉所有可能的异常
+- 记得使用```finally```关闭流资源或者直接使用```try-with-resource```
+- 捕获异常与抛出异常必须是完全匹配，或者捕获异常是抛异常的父类
+- 捕获到的异常，不能忽略它，至少打点日志吧
+- 注意异常对你的代码层次结构的侵染
+- 自定义封装异常，不要丢弃原始异常的信息```Throwable cause```
+- 运行时异常```RuntimeException``` ，不应该通过```catch```的方式来处理，而是先预检查，比如：```NullPointerException```处理
+- 注意异常匹配的顺序，优先捕获具体的异常
+
+小伙伴们有兴趣可以看下我之前写的这篇文章哈：[Java 异常处理的十个建议](https://mp.weixin.qq.com/s/3mqY77c8iXWvJFzkVQi9Og)
+
+## 23. 优化程序逻辑
+
+优化程序逻辑这块还是挺重要的，也就是说，你实现的业务代码，**如果是比较复杂的话，建议把注释写清楚**。还有，代码逻辑尽量清晰，代码尽量高效。
+
+> 比如，你要使用用户信息的属性，你根据session已经获取到```userId```了，然后就把用户信息从数据库查询出来，使用完后，后面可能又要用到用户信息的属性，有些小伙伴没想太多，反手就把```userId```再传进去，再查一次数据库。。。我在项目中，见过这种代码。。。直接把用户对象传下来不好嘛。。
+
+反例伪代码：
+
+```
+public Response test(Session session){
+ UserInfo user = UserDao.queryByUserId(session.getUserId());
+
+ if(user==null){
+ reutrn new Response();
+ }
+
+ return do(session.getUserId());
+}
+
+public Response do(String UserId){
+ //多查了一次数据库
+ UserInfo user = UserDao.queryByUserId(session.getUserId());
+ ......
+ return new Response();
+}
+
+```
+
+正例：
+
+```
+public Response test(Session session){
+ UserInfo user = UserDao.queryByUserId(session.getUserId());
+
+ if(user==null){
+ reutrn new Response();
+ }
+
+ return do(session.getUserId());
+}
+
+//直接传UserInfo对象过来即可，不用再多查一次数据库
+public Response do(UserInfo user){
+ ......
+ return new Response();
+}
+```
+
+当然，这只是一些很小的一个例子，还有很多类似的例子，需要大家开发过程中，多点思考的哈。
+
+
+## 24. 接口实现过程汇中，注意大文件、大事务、大对象
+
+- 读取大文件时，不要```Files.readAllBytes```直接读取到内存，这样会OOM的，建议使用```BufferedReader```一行一行来。
+- 大事务可能导致死锁、回滚时间长、主从延迟等问题，开发中尽量避免大事务。
+- 注意一些大对象的使用，因为大对象是直接进入老年代的，会触发fullGC
+
+## 25. 你的接口，需要考虑限流
+
+如果你的系统每秒扛住的请求是1000，如果一秒钟来了十万请求呢？换个角度就是说，高并发的时候，流量洪峰来了，超过系统的承载能力，怎么办呢？
+
+如果不采取措施，所有的请求打过来，系统CPU、内存、Load负载飚的很高，最后请求处理不过来，所有的请求无法正常响应。
+
+针对这种场景，我们可以采用限流方案。就是为了保护系统，多余的请求，直接丢弃。
+
+限流定义：
+> 在计算机网络中，限流就是控制网络接口发送或接收请求的速率，它可防止DoS攻击和限制Web爬虫。限流，也称流量控制。是指系统在面临高并发，或者大流量请求的情况下，限制新的请求对系统的访问，从而保证系统的稳定性。
+
+可以使用Guava的```RateLimiter```单机版限流，也可以使用```Redis```分布式限流，还可以使用阿里开源组件```sentinel```限流
+
+大家可以看下我之前这篇文章哈：[4种经典限流算法讲解](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247490393&idx=1&sn=98189caa486406f8fa94d84ba0667604&chksm=cf21c470f8564d665ce04ccb9dc7502633246da87a0541b07ba4ac99423b28ce544cdd6c036b&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
+
+
+## 26.代码实现时，注意运行时异常（比如空指针、下标越界等）
+
+日常开发中，我们需要采取措施**规避数组边界溢出，被零整除，空指针**等运行时错误。类似代码比较常见：
+```
+String name = list.get(1).getName(); //list可能越界，因为不一定有2个元素哈
+```
+
+应该采取措施，预防一下数组边界溢出。正例如下：
+```
+if(CollectionsUtil.isNotEmpty(list)&& list.size()>1){
+ String name = list.get(1).getName();
+}
+```
+
+
+
+## 27.保证接口安全性
+
+如果你的API接口是对外提供的，需要保证接口的安全性。保证接口的安全性有**token机制和接口签名**。
+
+**token机制身份验证**方案还比较简单的，就是
+
+
+
+1. 客户端发起请求，申请获取token。
+2. 服务端生成全局唯一的token，保存到redis中（一般会设置一个过期时间），然后返回给客户端。
+3. 客户端带着token，发起请求。
+4. 服务端去redis确认token是否存在，一般用 redis.del(token)的方式，如果存在会删除成功，即处理业务逻辑，如果删除失败不处理业务逻辑，直接返回结果。
+
+**接口签名**的方式，就是把接口请求相关信息（请求报文，包括请求时间戳、版本号、appid等），客户端私钥加签，然后服务端用公钥验签，验证通过才认为是合法的、没有被篡改过的请求。
+
+有关于加签验签的，大家可以看下我这篇文章哈：[程序员必备基础：加签验签](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247488022&idx=1&sn=70484a48173d36006c8db1dfb74ab64d&chksm=cf21cd3ff8564429a1205f6c1d78757faae543111c8461d16c71aaee092fe3e0fed870cc5e0e&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
+
+处了**加签验签和token机制，接口报文一般是要加密的**。当然，用https协议是会对报文加密的。如果是我们服务层的话，如何加解密呢？
+> 可以参考HTTPS的原理，就是服务端把公钥给客户端，然后客户端生成对称密钥，接着客户端用服务端的公钥加密对称密钥，再发到服务端，服务端用自己的私钥解密，得到客户端的对称密钥。这时候就可以愉快传输报文啦，客户端用**对称密钥加密请求报文**，**服务端用对应的对称密钥解密报文**。
+
+有时候，接口的安全性，还包括**手机号、身份证等信息的脱敏**。就是说，**用户的隐私数据，不能随便暴露**。
+
+## 28.分布式事务，如何保证
+
+> 分布式事务：就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单来说，分布式事务指的就是分布式系统中的事务，它的存在就是为了保证不同数据库节点的数据一致性。
+
+分布式事务的几种解决方案：
+- 2PC(二阶段提交)方案、3PC
+- TCC（Try、Confirm、Cancel）
+- 本地消息表
+- 最大努力通知
+- seata
+
+大家可以看下这篇文章哈：[看一遍就理解：分布式事务详解](https://mp.weixin.qq.com/s/3r9MfIz2RAtdFhYzwwZxjA)
+
+## 29. 事务失效的一些经典场景
+
+我们的接口开发过程中，经常需要使用到事务。所以需要避开事务失效的一些经典场景。
+
+- 方法的访问权限必须是public，其他private等权限，事务失效
+- 方法被定义成了final的，这样会导致事务失效。
+- 在同一个类中的方法直接内部调用，会导致事务失效。
+- 一个方法如果没交给spring管理，就不会生成spring事务。
+- 多线程调用，两个方法不在同一个线程中，获取到的数据库连接不一样的。
+- 表的存储引擎不支持事务
+- 如果自己try...catch误吞了异常，事务失效。
+- 错误的传播特性
+
+推荐大家看下这篇文章：[聊聊spring事务失效的12种场景，太坑了](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247494570&idx=2&sn=17357bcd328b2d1d83f4a72c47daac1b&chksm=cf223483f855bd95351a778d5f48ddd37917ce2790ebbbcd1d6ee4f27f7f4b147f0d41101dcc&token=2044040586&lang=zh_CN&scene=21#wechat_redirect)
+
+
+## 30. 掌握常用的设计模式
+
+把代码写好，还是需要熟练常用的设计模式，比如策略模式、工厂模式、模板方法模式、观察者模式等等。设计模式，是代码设计经验的总结。使用设计模式可以可重用代码、让代码更容易被他人理解、保证代码可靠性。
+
+我之前写过一篇总结工作中常用设计模式的文章，写得挺不错的，大家可以看下：[实战！工作中常用到哪些设计模式](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247495616&idx=1&sn=e74c733d26351eab22646e44ea74d233&chksm=cf2230e9f855b9ffe1ddb9fe15f72a273d5de02ed91cc97f3066d4162af027299718e2bf748e&token=1260947715&lang=zh_CN#rd)
+
+## 31. 写代码时，考虑线性安全问题
+
+在**高并发**情况下，```HashMap```可能会出现死循环。因为它是非线性安全的，可以考虑使用```ConcurrentHashMap```。所以这个也尽量养成习惯，不要上来反手就是一个```new HashMap()```;
+
+> - Hashmap、Arraylist、LinkedList、TreeMap等都是线性不安全的；
+> - Vector、Hashtable、ConcurrentHashMap等都是线性安全的
+
+
+
+
+## 32.接口定义清晰易懂，命名规范。
+
+我们写代码，不仅仅是为了实现当前的功能，也要有利于后面的维护。说到维护，代码不仅仅是写给自己看的，也是给别人看的。所以接口定义要清晰易懂，命名规范。
+
+## 33. 接口的版本控制
+
+接口要做好版本控制。就是说，请求基础报文，应该包含```version```接口版本号字段，方便未来做接口兼容。其实这个点也算接口扩展性的一个体现点吧。
+
+比如客户端APP某个功能优化了，新老版本会共存，这时候我们的```version```版本号就派上用场了，对```version```做升级，做好版本控制。
+
+## 34. 注意代码规范问题
+
+注意一些常见的代码坏味道：
+- 大量重复代码（抽公用方法，设计模式）
+- 方法参数过多（可封装成一个DTO对象）
+- 方法过长（抽小函数）
+- 判断条件太多（优化if...else）
+- 不处理没用的代码
+- 不注重代码格式
+- 避免过度设计
+
+代码的坏味道，这里我都写到啦：[25种代码坏味道总结+优化示例](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247490148&idx=1&sn=00a181bf74313f751b3ea15ebc303545&chksm=cf21c54df8564c5bc5b4600fce46619f175f7ae557956f449629c470a08e20580feef4ea8d53&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
+
+## 35.保证接口正确性，其实就是保证更少的bug
+
+保证接口的正确性，换个角度讲，就是保证更少的bug，甚至是没有bug。所以接口开发完后，一般需要开发**自测一下**。然后的话，接口的正确还体现在，多线程并发的时候，**保证数据的正确性**,等等。比如你做一笔转账交易，扣减余额的时候，可以通过CAS乐观锁的方式保证余额扣减正确吧。
+
+如果你是实现秒杀接口，得防止超卖问题吧。你可以使用Redis分布式锁防止超卖问题。使用Redis分布式锁，有几个注意要点，大家可以看下我之前这篇文章哈：[七种方案！探讨Redis分布式锁的正确使用姿势](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247488142&idx=1&sn=79a304efae7a814b6f71bbbc53810c0c&chksm=cf21cda7f85644b11ff80323defb90193bc1780b45c1c6081f00da85d665fd9eb32cc934b5cf&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
+
+## 36.学会沟通，跟前端沟通，跟产品沟通
+
+我把这一点放到最后，学会沟通是非常非常重要的。比如你开发定义接口时，**一定不能上来就自己埋头把接口定义完了**，**需要跟客户端先对齐接口**。遇到一些难点时，跟技术leader对齐方案。实现需求的过程中，有什么问题，及时跟产品沟通。
+
+总之就是，开发接口过程中，一定要沟通好~
+
+
+## 最后(求关注，别白嫖我)
+
+如果这篇文章对您有所帮助，或者有所启发的话，欢迎关注我的公众号：捡田螺的小男孩
+
+
diff --git "a/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207\344\272\214\357\274\232\346\211\213\346\212\212\346\211\213\346\225\231\344\275\240\345\256\236\347\216\260\344\270\200\344\270\252\345\271\266\350\241\214\350\260\203\347\224\250\346\250\241\346\235\277.md" "b/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207\344\272\214\357\274\232\346\211\213\346\212\212\346\211\213\346\225\231\344\275\240\345\256\236\347\216\260\344\270\200\344\270\252\345\271\266\350\241\214\350\260\203\347\224\250\346\250\241\346\235\277.md"
new file mode 100644
index 0000000..762cb1b
--- /dev/null
+++ "b/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207/\345\220\216\347\253\257\346\200\235\347\273\264\347\257\207\344\272\214\357\274\232\346\211\213\346\212\212\346\211\213\346\225\231\344\275\240\345\256\236\347\216\260\344\270\200\344\270\252\345\271\266\350\241\214\350\260\203\347\224\250\346\250\241\346\235\277.md"
@@ -0,0 +1,599 @@
+## 前言
+
+大家好，我是捡田螺的小男孩。
+
+本文是后端思维专栏的第二篇哈。上一篇[36个设计接口的锦囊](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247499388&idx=1&sn=49a22120a3238e13ad7c3d3b73d9e453&chksm=cf222155f855a8434026b2c460d963c406186578c2527ca8f2bb829bbe849d87a2392a525a9b&token=1380536362&lang=zh_CN#rd)，得到非常多小伙伴的认可。
+36个设计接口的锦囊中也提到一个点：就是**使用并行调用优化接口**。所以接下来就快马加鞭，写第二篇：手把手教你写一个并行调用模板。
+
+- 一个串行调用的例子（App首页信息查询）
+- CompletionService实现并行调用
+- 抽取通用的并行调用方法
+- 代码思考以及设计模式应用
+- 思考总结
+- 公众号：**捡田螺的小男孩**
+
+
+## 1. 一个串行调用的例子
+
+如果让你设计一个APP首页查询的接口，它需要查用户信息、需要查```banner```信息、需要查标签信息等等。一般情况，小伙伴会实现如下：
+
+```
+public AppHeadInfoResponse queryAppHeadInfo(AppInfoReq req) {
+ //查用户信息
+ UserInfoParam userInfoParam = buildUserParam(req);
+ UserInfoDTO userInfoDTO = userService.queryUserInfo(userInfoParam);
+ //查banner信息
+ BannerParam bannerParam = buildBannerParam(req);
+ BannerDTO bannerDTO = bannerService.queryBannerInfo(bannerParam);
+ //查标签信息
+ LabelParam labelParam = buildLabelParam(req);
+ LabelDTO labelDTO = labelService.queryLabelInfo(labelParam);
+ //组装结果
+ return buildResponse(userInfoDTO,bannerDTO,labelDTO);
+}
+```
+
+这段代码会有什么问题嘛？ 其实这是一段挺正常的代码，但是这个方法实现中，查询用户、banner、标签信息，**是串行的**，如果查询用户信息```200ms```，查询banner信息```100ms```，查询标签信息```200ms```的话，耗时就是```500ms```啦。
+
+
+
+其实为了优化性能，我们可以修改为**并行调用**的方式，耗时可以降为```200ms```，如下图所示：
+
+
+
+
+
+## 2. CompletionService实现并行调用
+
+对于上面的例子，**如何实现并行调用呢？**
+
+有小伙伴说，可以使用```Future+Callable```实现多个任务的并行调用。但是线程池执行批量任务时，返回值用```Future的get()```获取是阻塞的，如果前一个任务执行比较耗时的话，```get（）```方法会阻塞，形成排队等待的情况。
+
+而```CompletionService```是对定义```ExecutorService```进行了包装，可以一边生成任务,一边获取任务的返回值。让这两件事分开执行,任务之间不会互相阻塞，可以获取最先完成的任务结果。
+
+
+> ```CompletionService```的实现原理比较简单，底层通过FutureTask+阻塞队列，实现了任务先完成的话，可优先获取到。也就是说任务执行结果按照完成的先后顺序来排序，先完成可以优化获取到。内部有一个先进先出的阻塞队列，用于保存已经执行完成的Future，你调用```CompletionService```的poll或take方法即可获取到一个已经执行完成的Future，进而通过调用Future接口实现类的```get```方法获取最终的结果。
+
+
+
+
+接下来，我们来看下，如何用```CompletionService```，实现并行查询APP首页信息哈。思考步骤如下：
+
+1. 我们先把查询用户信息的任务，放到线程池，如下：
+```
+ExecutorService executor = Executors.newFixedThreadPool(10);
+//查询用户信息
+CompletionService userDTOCompletionService = new ExecutorCompletionService(executor);
+Callable userInfoDTOCallableTask = () -> {
+ UserInfoParam userInfoParam = buildUserParam(req);
+ return userService.queryUserInfo(userInfoParam);
+ };
+userDTOCompletionService.submit(userInfoDTOCallableTask);
+```
+
+2. 但是如果想把查询```banner```信息的任务，也放到这个线程池的话，发现不好放了，因为返回类型不一样，一个是```UserInfoDTO```，另外一个是```BannerDTO```。那这时候，我们是不是把泛型声明为Object即可，因为所有对象都是继承于Object的？如下：
+
+```
+ExecutorService executor = Executors.newFixedThreadPool(10);
+//查询用户信息
+CompletionService