当使用HTTP请求中的Authorization头时，表示传入的是认证信息。具体的认证类型由凭证前缀指明。以下是Authorization头中常见的几种认证机制：

以上的使用的scheme，如Basic，Bearer,Digest,ApiKey是约定俗成的，大家都这样使用，具体认证类型取决于服务器的要求和实现的协议，针对自己的业务也可以自定义scheme。也可以参考正在与之交互的服务或API的文档，以确定Authorization头的正确格式。

前言

最近学习部署的时候，发现前端部署可以通过多种方式来进行部署，web服务器,Docker,静态部署:Github page,网站托管平台:Vercel,还有一些自动化部署的东西目前还没有学到...

Docker开始

简介

Docker是一个应用打包，分发，部署的工具，它就相当于一个容器，将你想要的一些依赖、第三方库、环境啥的和代码进行一块打包为镜像，并上传到镜像仓库里面，这样别人可以直接从镜像仓库里面直接拉去这个代码来进行运行，可以适应不同的电脑环境，打造了一个完全封闭的环境。

• 打包：将软件运行所需要的依赖、第三方库、软件打包到一起，变成一个安装包


• 分发：将你打包好的安装包上传到一个镜像 仓库，其他人可以很方便的获取安装


• 部署：拿着安装包就可以一个命令运行起来你的应用，自动模拟出一摸一样的运行环境

为什么使用Docker

Docker 的出现主要是为了解决以下问题：“在我的机器上运行正常，但为什么到你的机器上就运行不正常了？”。

平常开发的时候，项目在本地跑的好好的，但是其他人想要在他的电脑上去跑你的应用程序，但是却跑不起来，他得配置数据库，Web 服务器，插件啥的，非常不方便。Docker的出现解决了这些问题。

基本术语

镜像：理解为软件安装包，可以方便的进行传播和安装,它包含了运行应用程序所需的所有元素，包括代码、运行时环境、库、环境变量和配置文件。

• 镜像可以通过Dockerfile来进行创建


• Dockerfile就相当于一个脚本，编写一些命令，他会识别这些命令并且执行

容器：软件安装后的状态，每个软件运行的环境都是独立的、隔离的，称之为容器。

仓库:仓库是存放 Docker 镜像的地方。仓库允许你分享你的镜像，你可以将你的镜像推送（push）到仓库，也可以从仓库拉取（pull）其他人分享的镜像。

• Docker 提供了一个公共的仓库 Docker Hub，你可以在上面上传你的镜像，或者寻找你需要的镜像。

常见命令

• docker run: 用于从 Docker 镜像启动一个容器。例如，docker run -p 8080:80 -d my-app 将从名为 "my-app" 的 Docker 镜像启动一个新的容器，并将容器的 8080 端口映射到主机的 80 端口。


• docker build: 用于从 Dockerfile 构建 Docker 镜像。例如，docker build -t my-app . 将使用当前目录中的 Dockerfile 构建一个名为 "my-app" 的 Docker 镜像。


• docker pull: 用于从 Docker Hub 或其他 Docker 注册服务器下载 Docker 镜像。例如，docker pull nginx 将从 Docker Hub 下载官方的 Nginx 镜像。


• docker push: 用于将 Docker 镜像推送到 Docker Hub 或其他 Docker 注册服务器。例如，docker push my-app 将名为 "my-app" 的 Docker 镜像推送到你的 Docker Hub 账户。


• docker ps: 用于列出正在运行的 Docker 容器。添加 -a 选项（docker ps -a）可以列出所有容器，包括已停止的。


• docker stop: 用于停止正在运行的 Docker 容器。例如，docker stop my-container 将停止名为 "my-container" 的 Docker 容器。


• docker rm: 用于删除 Docker 容器。例如，docker rm my-container 将删除名为 "my-container" 的 Docker 容器。


• docker rmi: 用于删除 Docker 镜像。例如，docker rmi my-app 将删除名为 "my-app" 的 Docker 镜像。


• docker logs: 用于查看 Docker 容器的日志。例如，docker logs my-container 将显示名为 "my-container" 的 Docker 容器的日志。


• docker exec: 用于在正在运行的 Docker 容器中执行命令。例如，docker exec -it my-container bash 将在名为 "my-container" 的 Docker 容器中启动一个 bash shell。
  

ps:不会使用就:docker load --help

编写Dockerfile

FROM nginx:latest

# 定义作者

MAINTAINER Merikle



#删除目录下的default.conf文件

#RUN rm /etc/nginx/conf.d/default.conf

#设置时区

RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezone



#将本地nginx.conf配置覆盖nginx配置

COPY nginx.conf /etc/nginx/nginx.conf

# 将dist文件中的内容复制到 /usr/share/nginx/html/ 这个目录下面

COPY dist/  /usr/share/nginx/html/

#声名端口

EXPOSE 8748



RUN echo 'web project build  success!!'

FROM:指定基础镜像

RUN:一般指安装的过程

COPY:拷贝本地文件到镜像的指定目录

ENV:环境变量

EXPOSE:指定容器运行时监听到的端口，是给镜像的使用者看的

ENTRYPOINT：镜像中应用的启动命令，容器运行时调用

编写完Dockerfile生成镜像:

docker build -t test:v1 .

运行镜像:

docker run -p 8080:8080 --name test-hello test:v1

意思:跑在8080端口将test:v1命名为text-hello

之后你可以发布到上面说的仓库里面

• 首先你要先 注册一个账号


• 创建一个镜像库
  

• 命令行登录账号： docker login -u username


• 新建一个tag，名字必须跟你注册账号一样 docker tag test:v1 username/test:v1


• 推上去 docker push username/test:v1


• 部署试下 docker run -dp 8080:8080 username/test:v1

实践一下Docker部署前端项目

核心思想:

将前端打包的dist放到nginx里面，然后添加一个nginx.conf文件。

docker的话就是多了一个Dockerfile文件来构建镜像而已。

nginx.conf文件的编写

#nginx.conf文件编写

#user  nobody;

worker_processes  1;



#error_log  logs/error.log;

#error_log  logs/error.log  notice;

#error_log  logs/error.log  info;



#pid        logs/nginx.pid;





events {

    worker_connections  1024;

}





http {

    include       mime.types;

    default_type  application/octet-stream;



    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

    #                  '$status $body_bytes_sent "$http_referer" '

    #                  '"$http_user_agent" "$http_x_forwarded_for"';



    #access_log  logs/access.log  main;



    sendfile        on;

    #tcp_nopush     on;



    #keepalive_timeout  0;

    keepalive_timeout  65;



    #gzip  on;



    server {

        #监听的端口

        listen       8748;

        #请填写绑定证书的域名或者IP

        server_name  121.199.29.3;

		

		gzip on;

		gzip_min_length 1k;

		gzip_comp_level 9;

		gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;

		gzip_vary on;

		gzip_disable "MSIE [1-6]\.";



        #charset koi8-r;



        #access_log  logs/host.access.log  main;



        location / {

            root   /usr/share/nginx/html;

        	index  index.html index.htm;

        	try_files $uri $uri/ /index.html;

        }



        #error_page  404              /404.html;



        # redirect server error pages to the static page /50x.html

        #

        error_page   500 502 503 504  /50x.html;

        location = /50x.html {

            root   html;

        }



        # proxy the PHP scripts to Apache listening on 127.0.0.1:80

        #

        #location ~ \.php$ {

        #    proxy_pass   http://127.0.0.1;

        #}



        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000

        #

        #location ~ \.php$ {

        #    root           html;

        #    fastcgi_pass   127.0.0.1:9000;

        #    fastcgi_index  index.php;

        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;

        #    include        fastcgi_params;

        #}



        # deny access to .htaccess files, if Apache's document root

        # concurs with nginx's one

        #

        #location ~ /\.ht {

        #    deny  all;

        #}

    }





    # another virtual host using mix of IP-, name-, and port-based configuration

    #

    #server {

    #    listen       8000;

    #    listen       somename:8080;

    #    server_name  somename  alias  another.alias;



    #    location / {

    #        root   html;

    #        index  index.html index.htm;

    #    }

    #}





    # HTTPS server

    #

    #server {

    #    listen       443 ssl;

    #    server_name  localhost;



    #    ssl_certificate      cert.pem;

    #    ssl_certificate_key  cert.key;



    #    ssl_session_cache    shared:SSL:1m;

    #    ssl_session_timeout  5m;



    #    ssl_ciphers  HIGH:!aNULL:!MD5;

    #    ssl_prefer_server_ciphers  on;



    #    location / {

    #        root   html;

    #        index  index.html index.htm;

    #    }

    #}



}

Dockerfile文件的编写

# Dockerfile文件



FROM nginx:latest

# 定义作者

MAINTAINER Merikle



#删除目录下的default.conf文件

#RUN rm /etc/nginx/conf.d/default.conf

#设置时区

RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo 'Asia/Shanghai' >/etc/timezone



#将本地nginx.conf配置覆盖nginx配置

COPY nginx.conf /etc/nginx/nginx.conf

# 将dist文件中的内容复制到 /usr/share/nginx/html/ 这个目录下面

COPY dist/  /usr/share/nginx/html/

#声名端口

EXPOSE 8748



RUN echo 'web project build  success!!'

然后将这些压缩成zip(或者本地打包为镜像，然后上传到镜像仓库里面，在服务器里面拉取镜像就可以了)，然后传到服务器中，进行解压，构建镜像并且运行镜像来进行前端部署。

部署node项目

Dockerfile的编写

FROM node:11

MAINTAINER Merikle



# 复制代码

ADD . /mongo-server



# 设置容器启动后的默认运行目录

WORKDIR  /mongo-server



# 运行命令，安装依赖

# RUN 命令可以有多个，但是可以用 && 连接多个命令来减少层级。

# 例如 RUN npm install && cd /app && mkdir logs

RUN npm install --registry=https://registry.npm.taobao.org



# CMD 指令只能一个，是容器启动后执行的命令，算是程序的入口。

# 如果还需要运行其他命令可以用 && 连接，也可以写成一个shell脚本去执行。

# 例如 CMD cd /app && ./start.sh

CMD node app.js

然后构建镜像

发布镜像到hub上面

在服务器上面进行拉取镜像并且运行镜像。

部署mongodb

这个还没有部署，之后再说啦。

最近看几个老项目的SQL条件中使用了1=1，想想自己也曾经这样写过，略有感触，特别拿出来说道说道。

编写SQL语句就像炒菜，每一种调料的使用都会影响菜品的最终味道，每一个SQL条件的加入也会影响查询的执行效率。那么 1=1 存在什么样的问题呢？为什么又会使用呢？

为什么会使用 1=1？

在动态构建SQL查询时，开发者可能会不确定最终需要哪些条件。这时候，他们就会使用“1=1”作为一个始终为真的条件，让接下来的所有条件都可以方便地用“AND”连接起来，就像是搭积木的时候先放一个基座，其他的积木块都可以在这个基座上叠加。

就像下边这样：

SELECT * FROM table WHERE 1=1

<if test="username != null">

    AND username = #{username}

</if>

<if test="age > 0">

    AND age = #{age}

</if>

这样就不用在增加每个条件之前先判断是否需要添加“AND”。

1=1 带来的问题

性能问题

我们先来了解一下数据库查询优化器的工作原理。查询优化器就像是一个聪明的图书管理员，它知道如何最快地找到你需要的书籍。当你告诉它所需书籍的特征时，它会根据这些信息选择最快的检索路径。比如你要查询作者是“谭浩强”的书籍，它就选择先通过作者索引找到书籍索引，再通过书籍索引找到对应的书籍，而不是费力的把所有的书籍遍历一遍。

但是，如果我们告诉它一些无关紧要的信息，比如“我要一本书，它是一本书”，这并不会帮助管理员更快地找到书，反而可能会让他觉得困惑。一个带有“1=1”的查询可能会让数据库去检查每一条记录是否满足这个始终为真的条件，这就像是图书管理员不得不检查每一本书来确认它们都是书一样，显然是一种浪费。

不过这实际上可能也不会产生问题，因为现代数据库的查询优化器已经非常智能，它们通常能够识别出像 1=1 这样的恒真条件，并在执行查询计划时优化掉它们。在许多情况下，即使查询中包含了1=1，数据库的性能也不会受到太大影响，优化器会在实际执行查询时将其忽略。

代码质量

不过，我们仍然需要避免在查询中包含 1=1，有以下几点考虑：

编写尽可能高效、清晰和准确的SQL语句，不仅有助于保持代码的质量，也让代码具有更好的可维护性和可扩展性。

替代 1=1 的更佳做法

现在开发者普遍使用ORM框架来操作数据库了，还在完全手写拼SQL的同学可能需要反思下了，这里给两个不同ORM框架下替代1=1的方法。

假设我们有一个用户信息表 user，并希望根据传入的参数动态地过滤用户。

首先是Mybatis：

<!-- MyBatis映射文件片段 -->

<select id="selectUsersByConditions" parameterType="map" resultType="com.example.User">

  SELECT * FROM user

  <where>

    <!-- 使用if标签动态添加条件 -->

    <if test="username != null and username != ''">

      AND username = #{username}

    </if>

    <if test="age > 0">

      AND age = #{age}

    </if>

    <!-- 更多条件... -->

  </where>

</select>

在 MyBatis 中，避免使用 WHERE 1=1 的典型方法是利用动态SQL标签（如 ）来构建条件查询。 标签会自动处理首条条件前的 AND 或 OR。当没有满足条件的 或其他条件标签时， 标签内部的所有内容将被忽略，从而不会生成多余的 AND 或 WHERE 子句。

再看看 Entity Framework 的方法：

var query = context.User.AsQueryable();

if (!string.IsNullOrEmpty(username))

{

    query = query.Where(b => b.UserName.Contains(username));

}

if (age>0)

{

    query = query.Where(b => b.Age = age);

}

var users = query.ToList();

这是一种函数式编程的写法，最终生成SQL时，框架会决定是否在条件前增加AND，而不需要人为的增加 1=1。

总结

“1=1”在SQL语句中可能看起来无害，但实际上它是一种不良的编程习惯，可能会导致性能下降。就像在做饭时不会无缘无故地多加调料一样，我们在编写SQL语句时也应该避免添加无意义的条件。

每一行代码都应该有它存在的理由，不要让你的数据库像一个困惑的图书管理员，浪费时间在不必要的事情上。

之前看过一篇文章讲代码封装的过程，下面从简述文章的内容开始梳理下自己对代码封装的一点思考.

--- 以下是之前文章内容简述 ---

在业务迭代的初期，代码中有一段业务逻辑A,由于A逻辑在项目中使用比较广泛，于是对A逻辑进行了代码逻辑的封装，包括参数的预设等



随着业务的发展，又出现了B模块，B模块中几乎可以直接使用A逻辑，但是需要对A逻辑进行一些小小的改动，比如入参的调整、逻辑分支的增加



这种通过修改较小范围代码就能实现功能的方式在实际开发中是很常规的操作，它并没有不好，只是当这种修改变的次数多的时候，最开始封装的逻辑A就变成了‘四不像’，它似乎可以服务于A模块，但是确有些冗余，出现了‘我好像看不懂这段代码’，‘这段代码还是别改了’，‘你改吧 我是改不了’的场景。在多次封装之后，逻辑A容易出现以下的问题

• 入参不可控


• 逻辑分支复杂，不清晰，修改范围不确定，容易对其他模块产生影响


• 复用度逐渐下降，解决方法
  
  
  
  
  1. 将就不再继续新增逻辑，变成'老大难'问题，总有爆发的一天
  
  
  2. 重写相关逻辑，功能回测范围大，影响范围不可控，容易出现漏测等
  
  
  
  

--- 以下是正文 ---

提前封装或者过度封装对实际业务的编写都有很大影响，最实际的感受就是这段代码不好写，这个逻辑看不懂。封装的代码逻辑是结果，封装的出发点是因，从出发点去看而不是面向结果的封装似乎更能编写出可维护性的代码。以下是自己对封装的一点思考。

降低复杂度

通过对业务中分散的相似逻辑提取，就能一定程度上降低项目的复杂度和重复度的问题。在修改相应的业务逻辑时候就相对集中和可控。新增逻辑的修改也能做到应用范围的同步。

解耦逻辑

在设计模式中需要设计的模块尽量遵循单一职责，但是在实际编写代码的过程中很容易出现模块功能的耦合，比如常见的:

• 视图层逻辑与数据层逻辑耦合


• 非相关逻辑的入侵 比如视图的逻辑需要感知请求状态的改变做相应的逻辑处理

通过将相关的逻辑都聚合到模块封装的内部，就能较低其他模块对不相关逻辑的感知，也就做到了解耦。在下面的例子中，通过将A逻辑的关联逻辑都封装进A模块中，降低了功能模块对封装逻辑的感知。

相关例子:

• 在ahooks中的useRequest中，就通过对请求状态和数据的操作就行封装，将数据相关操作做到了内聚，减轻了视图层的负担


• Antd pro components的table

分层

在例子中，通过将逻辑A中的相关逻辑提取到上层，分层的方式实现了模块功能的内聚与解耦。在前端的MVC中就通过将相关操作封装成Controller,来完成逻辑的解耦

复用(一致性，可控性)

从降低复杂度、逻辑结构、分层设计最终的目标是达到封装代码的复用。通过复用能控制代码的一致性，实现修改代码行为的可控。

• 在封装的实现上 可以逐渐的从项目内共享 -> 跨项目共享等


• 在分发共享逻辑上，有monorepo、模块联邦、npm包、微前端等方式.

-- 写在最后 --

代码的优化或者设计是应该在理解业务的基础上，从相对大的视角出发来看的。在实际做的时候容易出现缺少全局视角的设计缺失和不完善，也容易出现过度设计，需要仔细去把握这个度量。

前言

我们作为特色社会主义社会中的一份子，跟国外程序员不一样的地方在于，别人能轻松访问 github, 我们却要借梯子，或者用国产的 gitee。

作为有追求的程序员，作为成年人，当然是两个我都要！

那么如何优雅地把本地代码同时维护到 gitee 和 github上呢？这里带给大家2个方法。

push 2个 remote original

假如我们在 github 创建了一个仓库，那么本地 clone 下来后，主分支(main)是默认跟github 仓库的主分支(main) 关联的。这样直接在 VSCode 里面点 同步的圈圈 就会自动同步，如下图。

现在我又要推到 gitee，怎么办，很简单，新增一个 remote 源，并命名为 gitee，默认的 origin 已经跟 github 关联了。

git remote add gitee 

这样我们就有2个源，在 VSCode 的 Git Graph 中可以直接 push 到2个源中，2个都勾选上。

点击 Yes, push 就可以推上去了。爽歪歪

gitee 仓库镜像管理：gitee -> github

本来上面的方法用得好好的，但是我的梯子质量不好，时不时推不上 github ( gitee 倒是轻轻松松，没有失败过），然后我又得重新 push，有的时候要重试好多次才行，非常浪费时间！！

然后我就发现 gitee 原来是可以同步推到 github 的，根本就不用我们手动操作，点赞！

官方链接在这里 仓库镜像管理（Gitee<->Github 双向同步），我就不做搬运工了，给几个图：

其中还需要到 github 获取 token，方法如下：

官方链接在这里 如何申请 GitHub 私人令牌？

我设置成功如下图：

token生成的时候要设置过期时间，尽量设置长一点比如一年。

推到 gitee 的代码会自动同步到 github, 我们也可以手动点右侧的 更新 按钮，手动同步。

经我检测，是成功的，刚刚推不上去 github 的代码，通过 gitee 同步过去了，本地也能看到代码是同步的。

有一个需要注意的是，你只能推到你自己的github仓库，不能推到你的github组织的仓库。

以我的仓库为例：

• gitee.com/codercup/un… --> github.com/codercup/un… ✅


• gitee.com/my-org/unib… --> github.com/codercup/un… ✅


• gitee.com/codercup/un… --> github.com/my-org/unib… ❎


• gitee.com/my-org/unib… --> github.com/my-org/unib… ❎

因为选推送的目标仓库时压根就不能选组织，只能选个人！但是源仓库可以是个人的或者组织的。

总结

本文介绍了2种同步 gitee 和 github 仓库的方法，视情况选择：

• 当目标仓库是个人时，第二种会比较方便，推上到 gitee 后，会自动同步到 github。


• 当目标仓库是组织时，不能用第二种，只能用第一种，自己手动 push 到2个仓库，需要你的梯子质量好，不然可能推不上 github。

最后把我每天都看的美女分享给大家~养眼啊

Monaspace 是有 GitHub 开源的代码字体，包含 5 种变形字体的等宽代码字体家族，颜值 Up，很难不喜欢。

来看一下这 5 种字体分别是：

1️⃣ Radon 手写风格字体

2️⃣ Krypton 机械风格字体

3️⃣ Xenon 衬线风格字体

4️⃣ Argon 人文风格字体

5️⃣ Neon 现代风格字体

👉 项目地址：github.com/githubnext/…

下载方式

MacOS

使用 brew 安装：

brew tap homebrew/cask-fonts

brew install font-monaspace

Windows

下载该文件：github.com/githubnext/…

拖到 C:\Windows\Fonts 中，点击安装

下载好后，如果是 VSCode 文件，可以在设置中找到 font-family，改为：'Monaspace Radon', monospace

数据库所有表被删除了

这个程序员把我们的数据库表都删除了，然后新建了一个数据库redme_to_recover数据库

里面还有一张表，表里是让你支付，然后给你数据下载地址。

通过查看Docker里部署的PostgreSQL执行日志是没有操作记录的

根据数据库的日志确定，1月24号13点数据库被重启了。

25号的日志非常少，错误信息都是客户端连接失败，无法从客户端接收数据。（25号系统还是正常的）

26号02时的日志就显示tdd表没了（这时候应该是所有表都没了）。

中间没有删除表的操作日志，跟大佬请教了一下，确定应该是有人登录了我们的Linux系统。然后从Linux系统层面直接删除的表资源数据，没有通过PGSQL操作，没有删除操作记录。

我对黑客攻击的数据库进行了修改密码，然后发现密码失效了，无论输入什么密码，都能正常登录数据库。

我是怎么恢复的

1、将原来的PG数据库镜像删除，重新修改了端口号和数据库密码然后启动数据库容器。

docker ps -a 列出所有的Docker容器，包括正在运行和已经停止的容器。

docker rm [容器id/容器名称] 删除PostgreSQL容器。

docker run 启动一个新的容器。

2、将Linux账户登录密码修改。

3、修改端口号和数据库配置密码后，重新打包我们的数据处理程序。

4、修改Nacos里配置的接口服务程序的数据库连接配置。

5、将表结构恢复，系统表和业务表结构，系统表包括账户角色等信息（幸亏我们同事有备份）

6、丢失了历史业务数据

需求背景

接到重点业务需求要分轮次展示数据，预估最高承接 9w 的 QPS，作为后端工程师下意识的就是把接口写好，分级缓存、机器扩容、线程拉满等等一系列连招准备，再因为数据更新频次两只手都数得过来，我们采取了最稳妥的处理方式，直接生成静态文件拿 CDN 抗量

架构流程大致如下所示：

数据更新后会重新生成新一轮次的文件，刷新 CDN 的时候会触发大量回源请求，应用服务器极端情况得 hold 住这 9w 的 QPS

第一次压测

双机房一共 40 台 4C 的机器，25KB 数据文件，5w 的 QPS 直接把 CPU 打到 90%

这明显不符合业务需求啊，咋办？先无脑加机器试试呗

就在这时测试同学反馈压测的数据不对，最后一轮文件最大会有 125KB，雪上加霜

于是乎文件替换，机器数量整体翻一倍扩到 80 台，服务端 CPU 依然是瓶颈，QPS 加不上去了

到底是哪里在消耗 CPU 资源呢，整体架构已经简单到不能再简单了

这时候我们注意到为了节省网络带宽 nginx 开启了 gzip 压缩，是不是这小子搞的鬼

server

{

      listen 80;

      

      gzip on;

      gzip_disable "msie6";

      gzip_vary on;

      gzip_proxied any;

      gzip_comp_level 6;

      gzip_buffers 16 8k;

      gzip_http_version 1.1;

      gzip_types text/plain application/css text/css application/xml text/javascript application/javascript application/x-javascript;



......

}

第二次压测

为了验证这个猜想，我们把 nginx 中的 gzip 压缩率从 6 调成 2，以减少 CPU 的计算量

gzip_comp_level 2;

这轮压下来 CPU 还是很快被打满，但 QPS 勉强能达到 9w，坐实了确实是 gzip 在耗 CPU

nginx 作为家喻户晓的 web 服务器，以高性能高并发著称，区区一个静态数据文件就把应用服务器压的这么高，一定是哪里不对

第三次压测

明确了 gzip 在耗 CPU 之后我们潜下心来查阅了相关资料，发现了一丝进展

html/css/js 等静态文件通常包含大量空格、标签等重复字符，重复出现的部分使用「距离加长度」表达可以减少字符数，进而大幅降低带宽，这就是 gzip 无损压缩的基本原理

作为一种端到端的压缩技术，gzip 约定文件在服务端压缩完成，传输中保持不变，直到抵达客户端。这不妥妥的理论依据嘛～

nginx 中的 gzip 压缩分为动态压缩和静态压缩两种

•动态压缩

服务器给客户端返回响应时，消耗自身的资源进行实时压缩，保证客户端拿到 gzip 格式的文件

这个模块是默认编译的，详情可以查看 nginx.org/en/docs/htt…

•静态压缩

直接将预先压缩过的 .gz 文件返回给客户端，不再实时压缩文件，如果找不到 .gz 文件，会使用对应的原始文件

这个模块需要单独编译，详情可以查看 nginx.org/en/docs/htt…

如果开启了 gzip_static always，而且客户端不支持 gzip，还可以在服务端加装 gunzip 来帮助客户端解压，这里我们就不需要了

查了一下 jdos 自带的 nginx 已经编译了 ngx_http_gzip_static_module，省去了重新编译的麻烦事

接下来通过 GZIPOutputStream 在本地额外生成一个 .gz 的文件，nginx 配置上静态压缩再来一次

gzip_static on;

面对 9w 的QPS，40 台机器只用了 7% 的 CPU 使用率完美扛下

为了探底继续加压，应用服务器 CPU 增长缓慢，直到网络流出速率被拉到了 89MB/s，担心影响宿主机其他容器停止压力，此时 QPS 已经来到 27w

qps 5w->27w 提升 5 倍，CPU 90%->7% 降低 10 倍，整体性能翻了 50 倍不止，这回舒服了～

写在最后

经过一连串的分析实践，似乎静态压缩存在“压倒性”优势，那什么场景适合动态压缩，什么场景适合静态压缩呢？一番探讨后得出以下结论

纯静态不会变化的文件适合静态压缩，提前使用gzip压缩好避免CPU和带宽的浪费。动态压缩适合API接口返回给前端数据这种动态的场景，数据会发生变化，这时候就需要nginx根据返回内容动态压缩，以节省服务器带宽

作为一名后端工程师，nginx 是我们的老相识了，抬头不见低头见。日常工作中配一配转发规则，查一查 header 设置，基本都是把 nginx 作为反向代理使用。这次是直接访问静态资源，调整过程的一系列优化加深了我们对 gzip 的动态压缩和静态压缩的基本认识，这在 NG 老炮儿眼里显得微不足道，但对于我们来说却是一次难得的技能拓展机会

在之前的职业生涯里，我们一直聚焦于业务架构设计与开发，对性能的优化似乎已经形成思维惯性。面对大数据量长事务请求，减少循环变批量，增大并发，增加缓存，实在不行走异步任务解决，一般瓶颈都出现在 I/O 层面，毕竟磁盘慢嘛，减少与数据库的交互次数往往就有效果，其他大概率不是问题。这回有点儿不一样，CPU 被打起来的原因就是出现了大量数据计算，在高并发请求前，任何一个环节都可能产生性能问题

作者：京东零售 闫创

来源：京东云开发者社区 转载请注明来源

一、 概述

众所周知，用kotlin委托属性去封装KV存储库，可以优化数据的访问。

封装方法有多种，各有优劣。

通过反复实践，笔者摸索出一套比较好用的方案，借此文做个简单的分享。

代码已上传Github: github.com/BillyWei01/…

项目中是基于SharePreferences封装的，但这套方案也适用于其他类型的KV存储框架。

二、 封装方法

此方案封装了两类委托：

2.1 委托实现

基础类型：BasicDelegate.kt

扩展key的基础类型： ExtDelegate.kt

这里举例一下基础类型中的Boolean类型的委托实现：

class BooleanProperty(private val key: String, private val defValue: Boolean) :

    ReadWriteProperty<KVData, Boolean> {

    override fun getValue(thisRef: KVData, property: KProperty<*>): Boolean {

        return thisRef.kv.getBoolean(key, defValue)

    }



    override fun setValue(thisRef: KVData, property: KProperty<*>, value: Boolean) {

        thisRef.kv.putBoolean(key, value)

    }

}



class NullableBooleanProperty(private val key: String) :

    ReadWriteProperty<KVData, Boolean?> {

    override fun getValue(thisRef: KVData, property: KProperty<*>): Boolean? {

        return thisRef.kv.getBoolean(key)

    }



    override fun setValue(thisRef: KVData, property: KProperty<*>, value: Boolean?) {

        thisRef.kv.putBoolean(key, value)

    }

}

经典的 ReadWriteProperty 实现:

分别重写 getValue 和 setValue 方法，方法中调用KV存储的读写API。

由于kotlin区分了可空类型和非空类型，方案中也分别封装了可空和非空两种委托。

2.2 基类定义

实现了委托之后，我们将各种委托API封装到一个基类中：KVData

abstract class KVData {

    // 存储接口

    abstract val kv: KVStore



    // 基础类型

    protected fun boolean(key: String, defValue: Boolean = false) = BooleanProperty(key, defValue)

    protected fun int(key: String, defValue: Int = 0) = IntProperty(key, defValue)

    protected fun float(key: String, defValue: Float = 0f) = FloatProperty(key, defValue)

    protected fun long(key: String, defValue: Long = 0L) = LongProperty(key, defValue)

    protected fun double(key: String, defValue: Double = 0.0) = DoubleProperty(key, defValue)

    protected fun string(key: String, defValue: String = "") = StringProperty(key, defValue)

    protected fun stringSet(key: String, defValue: Set<String> = emptySet()) = StringSetProperty(key, defValue)

    protected fun <T> obj(key: String, encoder: ObjectEncoder<T>, defValue: T) = ObjectProperty(key, encoder, defValue)



    // 可空的基础类型

    protected fun nullableBoolean(key: String) = NullableBooleanProperty(key)

    protected fun nullableInt(key: String) = NullableIntProperty(key)

    protected fun nullableFloat(key: String) = NullableFloatProperty(key)

    protected fun nullableLong(key: String) = NullableLongProperty(key)

    protected fun nullableDouble(key: String) = NullableDoubleProperty(key)

    protected fun nullableString(key: String) = NullableStringProperty(key)

    protected fun nullableStringSet(key: String) = NullableStringSetProperty(key)

    protected fun <T> nullableObj(key: String, encoder: NullableObjectEncoder<T>) = NullableObjectProperty(key, encoder)



    // 扩展key的基础类型

    protected fun extBoolean(key: String, defValue: Boolean = false) = ExtBooleanProperty(key, defValue)

    protected fun extInt(key: String, defValue: Int = 0) = ExtIntProperty(key, defValue)

    protected fun extFloat(key: String, defValue: Float = 0f) = ExtFloatProperty(key, defValue)

    protected fun extLong(key: String, defValue: Long = 0L) = ExtLongProperty(key, defValue)

    protected fun extDouble(key: String, defValue: Double = 0.0) = ExtDoubleProperty(key, defValue)

    protected fun extString(key: String, defValue: String = "") = ExtStringProperty(key, defValue)

    protected fun extStringSet(key: String, defValue: Set<String> = emptySet()) = ExtStringSetProperty(key, defValue)

    protected fun <T> extObj(key: String, encoder: ObjectEncoder<T>, defValue: T) = ExtObjectProperty(key, encoder, defValue)



    // 扩展key的可空的基础类型

    protected fun extNullableBoolean(key: String) = ExtNullableBooleanProperty(key)

    protected fun extNullableInt(key: String) = ExtNullableIntProperty(key)

    protected fun extNullableFloat(key: String) = ExtNullableFloatProperty(key)

    protected fun extNullableLong(key: String) = ExtNullableLongProperty(key)

    protected fun extNullableDouble(key: String) = ExtNullableDoubleProperty(key)

    protected fun extNullableString(key: String) = ExtNullableStringProperty(key)

    protected fun extNullableStringSet(key: String) = ExtNullableStringSetProperty(key)

    protected fun <T> extNullableObj(key: String, encoder: NullableObjectEncoder<T>) = ExtNullableObjectProperty(key, encoder)

    

    // CombineKV 

    protected fun combineKV(key: String) = CombineKVProperty(key)

}

使用时，继承KVData，然后实现kv, 返回一个KVStore的实现类即可。

举例，如果用SharedPreferences实现KVStore，可如下实现：

class SpKV(name: String): KVStore {

    private val sp: SharedPreferences =

        AppContext.context.getSharedPreferences(name, Context.MODE_PRIVATE)

    private val editor: SharedPreferences.Editor = sp.edit()



    override fun putBoolean(key: String, value: Boolean?) {

        if (value == null) {

            editor.remove(key).apply()

        } else {

            editor.putBoolean(key, value).apply()

        }

    }



    override fun getBoolean(key: String): Boolean? {

        return if (sp.contains(key)) sp.getBoolean(key, false) else null

    }



    // ...... 其他类型 

}

更多实现可参考： SpKV

三、 使用方法

object LocalSetting : KVData("local_setting") {

    override val kv: KVStore by lazy {

        SpKV(name)

    }

    // 是否开启开发者入口

    var enableDeveloper by boolean("enable_developer")



    // 用户ID

    var userId by long("user_id")



    // id -> name 的映射。

    val idToName by extNullableString("id_to_name")



    // 收藏

    val favorites by extStringSet("favorites")



    var gender by obj("gender", Gender.CONVERTER, Gender.UNKNOWN)

}

定义委托属性的方法很简单：

• 和定义变量类似，需要声明变量名和类型；


• 和变量声明不同，需要传入key。


• 如果要定义自定义类型，需要传入转换器（实现字符串和对象类型的转换），以及默认值。

基本类型的读写，和变量的读写一样。

例如：

fun test1(){

    // 写入

    LocalSetting.userId = 10001L

    LocalSetting.gender = Gender.FEMALE



    // 读取

    val uid = LocalSetting.userId

    val gender = LocalSetting.gender

}

读写扩展key的基本类型，则和Map的语法类似:

fun test2() {

    if (LocalSetting.idToName[1] == null || LocalSetting.idToName[2] == null) {

        Log.d("TAG", "Put values to idToName")

        LocalSetting.idToName[1] = "Jonn"

        LocalSetting.idToName[2] = "Mary"

    } else {

        Log.d("TAG", "There are values in idToName")

    }

    Log.d("TAG", "idToName values: " +

                "1 -> ${LocalSetting.idToName[1]}, " +

                "2 -> ${LocalSetting.idToName[2]}"

    )

}

扩展key的基本类型，extKey是Any类型，也就是说，以上代码的[]，可以传入任意类型的参数。

四、数据隔离

4.1 用户隔离

不同环境（开发环境/测试环境），不同用户，最好数据实例是分开的，相互不干扰。

比方说有 uid='001' 和 uid='002' 两个用户的数据，如果需要隔离两者的数据，有多种方法，例如：

基于此分析，我们定义两种类型的基类：

• GlobalKV: 全局数据，切换环境和用户，不影响GlobalKV所访问的数据实例。


• UserKV: 用户数据，需要同时区分 “服务器环境“ 和 ”用户ID“。

open class GlobalKV(name: String) : KVData() {

    override val kv: KVStore by lazy {

        SpKV(name)

    }

}

abstract class UserKV(

    private val name: String,

    private val userId: Long

) : KVData() {

    override val kv: SpKV by lazy {

        // 拼接UID作为文件名

        val fileName = "${name}_${userId}_${AppContext.env.tag}"

        if (AppContext.debug) {

            SpKV(fileName)

        } else {

            // 如果是release包，可以对文件名做个md5，以便匿藏uid等信息

            SpKV(Utils.getMD5(fileName.toByteArray()))

        }

    }

}

UserKV实例：

/**

 * 用户信息

 */

class UserInfo(uid: Long) : UserKV("user_info", uid) {

    companion object {

        private val map = ArrayMap<Long, UserInfo>()

        

        // 返回当前用户的实例

        fun get(): UserInfo {

            return get(AppContext.uid)

        }



        // 根据uid返回对应的实例

        @Synchronized

        fun get(uid: Long): UserInfo {

            return map.getOrPut(uid) {

                UserInfo(uid)

            }

        }

    }

    

    var gender by intEnum("gender", Gender.CONVERTER)

    var isVip by boolean("is_vip")

    

    // ... 其他变量

}

UserKV的实例不能是单例（不同的uid对应不同的实例）。

因此，可以定义companion对象，用来缓存实例，以及提供获取实例的API。

保存和读取方法如下：

先调用get()方法获取，然后其他用法就和前面描述的用法一样了。

UserInfo.get().gender = Gender.FEMALE



val gender = UserInfo.get().gender

4.2 环境隔离

有一类数据，需要区分环境，但是和用户无关。

这种情况，可以用UserKV, 然后uid传0（或者其他的uid用不到的数值）。

/**

 * 远程设置

 */

object RemoteSetting : UserKV("remote_setting", 0L) {

    // 某项功能的AB测试分组

    val fun1ABTestGr0up by int("fun1_ab_test_group")

    

    // 服务端下发的配置项

    val setting by combineKV("setting")

}

五、小结

通过属性委托封装KV存储的API，可使原来“类名 + 操作 + key”的方式，变更为“类名 + 属性”的方式，从而简化KV存储的使用。
另外，这套方案也提到了保存不同用户数据到不同实例的演示。

方案内容不多，但其中包含一些比较实用的技巧，希望对各位读者有所帮助。

一、概述

后缀表达式（也称为逆波兰表达式）是一种数学表达式的表示方法，其中操作符位于操作数的后面。这种表示法消除了括号，并且在计算机科学和计算中非常有用，因为它更容易计算和解析。

与中缀表达式（通常我们使用的数学表达式，例如"a * (b + c)"）不同，后缀表达式的运算符放在操作数之后，例如：“a b c + *”。后缀表达式的计算方法是从左到右遍历表达式，遇到操作数时将其压入栈，遇到操作符时从栈中弹出所需数量的操作数进行计算，然后将结果重新压入栈。这个过程一直持续到整个表达式处理完毕，最终栈中只剩下一个结果，即表达式的计算结果。

后缀表达式具有以下优点：

转换中缀表达式为后缀表达式需要使用算法，通常是栈数据结构。

二、后缀表达式的运算顺序

后缀表达式的运算顺序是从左到右遍历表达式，遇到操作数时将其压入栈，遇到操作符时从栈中弹出所需数量的操作数进行计算，然后将计算结果重新压入栈。这个过程一直持续到整个表达式处理完毕，最终栈中只剩下一个结果，即表达式的计算结果。

后缀表达式的运算顺序是非常直观的，它遵循从左到右的顺序。当计算后缀表达式时，按照以下规则：

三、常规表达式转化为后缀表达式

• 创建两个栈，一个用于操作符（操作符栈），另一个用于输出后缀表达式（输出栈）。


• 从左到右遍历中缀表达式的每个元素。


• 如果是操作数，将其添加到输出栈。


• 如果是操作符：


• 如果操作符栈为空，直接将该操作符推入操作符栈。
  
  否则，比较该操作符与操作符栈栈顶的操作符的优先级。如果当前操作符的优先级较高，将其推入操作符栈。
  
  如果当前操作符的优先级较低或相等，从操作符栈中弹出并添加到输出栈，然后重复比较直到可以推入操作符栈。
  
  如果遇到左括号"(“，直接推入操作符栈。
  
  如果遇到右括号”)“，将操作符栈中的操作符弹出并添加到输出栈，直到遇到匹配的左括号”("。
  
  最后，将操作符栈中的剩余操作符全部弹出并添加到输出栈。
  
  完成遍历后，输出栈中的内容就是中缀表达式转化为后缀表达式的结果。

四、代码实现

/**

     * 定义操作符的优先级

     */

    private  Map<String, Integer> opList =

            Map.of("(",3,")",3,"*",2,"/",2,"+",1,"-",1);



    public List<String> getPostExp(List<String> source) {



        // 数字栈

        Stack<String> dataStack = new Stack<>();

        // 操作数栈

        Stack<String> opStack = new Stack<>();

        // 操作数集合

        for (int i = 0; i < source.size(); i++) {

            String d = source.get(i).trim();

            // 操作符的操作

            if (opList.containsKey(d)) {

                operHandler(d,opStack,dataStack);

            } else {

                // 操作数直接入栈

                dataStack.push(d);

            }

        }

        // 操作数栈中的数据，到压入到栈中

        while (!opStack.isEmpty()) {

            dataStack.push(opStack.pop());

        }

        List<String> result = new ArrayList<>();

        while (!dataStack.isEmpty()) {

            String pop = dataStack.pop();

            result.add(pop);

        }

        // 对数组进行翻转

        return CollUtil.reverse(result);

    }



    /**

     * 对操作数栈的操作

     * @param d，当前操作符

     * @param opStack 操作数栈

     */

    private void operHandler(String d, Stack<String> opStack,Stack<String> dataStack) {

        // 操作数栈为空

        if (opStack.isEmpty()) {

            opStack.push(d);

            return;

        }

        // 如果遇到左括号"(“，直接推入操作符栈。

        if (d.equals("(")) {

            opStack.push(d);

            return;

        }

        // 如果遇到右括号”)“，将操作符栈中的操作符弹出并添加到输出栈，直到遇到匹配的左括号”("。

        if (d.equals(")")) {

            while (!opStack.isEmpty()) {

                String pop = opStack.pop();

                // 不是左括号

                if (!pop.equals("(")) {

                    dataStack.push(pop);

                } else {

                    return;

                }

            }

        }

        // 操作数栈不为空

        while (!opStack.isEmpty()) {

            // 获取栈顶元素和优先级

            String peek = opStack.peek();

            Integer v = opList.get(peek);

            // 获取当前元素优先级

            Integer c = opList.get(d);

            // 如果当前操作符的优先级较低或相等，且不为（），从操作符栈中弹出并添加到输出栈，然后重复比较直到可以推入操作符栈

            if (c < v && v != 3) {

                // 出栈

                opStack.pop();

                // 压入结果集栈

                dataStack.push(peek);

            } else {

                // 操作符与操作符栈栈顶的操作符的优先级。如果当前操作符的优先级较高，将其推入操作符栈。

                opStack.push(d);

                break;

            }

        }

    }

测试代码如下：

PostfixExpre postfixExpre = new PostfixExpre();



List<String> postExp = postfixExpre.getPostExp(

        Arrays.asList("9", "+", "(" , "3", "-", "1", ")", "*", "3", "+", "10", "/", "2"));



System.out.println(postExp);

输出如下：

[9, 3, 1, -, 3, *, 10, 2, /, +, +]

五、求后缀表示值

使用栈来实现

    /****

     * 计算后缀表达式的值

     * @param source

     * @return

     */

    public double calcPostfixExpe(List<String> source) {



        Stack<String> data = new Stack<>();

        for (int i = 0; i < source.size(); i++) {

            String s = source.get(i);

            // 如果是操作数

            if (opList.containsKey(s)) {

                String d2 = data.pop();

                String d1 = data.pop();

                Double i1 = Double.valueOf(d1);

                Double i2 = Double.valueOf(d2);

                Double result = null;

                switch (s) {

                    case "+":

                        result = i1 + i2;break;

                    case "-":

                        result = i1 - i2;break;

                    case "*":

                        result = i1 * i2;break;

                    case "/":

                        result = i1 / i2;break;

                }

                data.push(String.valueOf(result));

            } else {

                // 如果是操作数，进栈操作

                data.push(s);

            }

        }

        // 获取结果

        String pop = data.pop();

        return Double.valueOf(pop);

    }

测试

PostfixExpre postfixExpre = new PostfixExpre();



List<String> postExp = postfixExpre.getPostExp(

        Arrays.asList("9", "+", "(" , "3", "-", "1", ")", "*", "3", "+", "10", "/", "2"));



System.out.println(postExp);



double v = postfixExpre.calcPostfixExpe(postExp);



System.out.println(v);

结果如下：

[9, 3, 1, -, 3, *, 10, 2, /, +, +]

20.0