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 01/47] 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 02/47] 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 03/47] 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