前言

最近在公司部署项目时遇上了一点关于nginx的问题，于是就想着写一篇关于nginx的文章...

主要给小白朋友分享，nginx是什么，nginx有什么用，最后到nginx的实际应用，项目部署。

nginx

公司项目刚刚上线，用户量少访问量不大，并发量低，一个jar包启动应用就能够解决问题了。但是随着项目的不断扩大，用户体量大增加，一台服务器可能就无法满足我们的需求了（当初是一个人用一个服务器，现在是多人用一个服务器，时间长了服务器都要红温）。

于是乎，我们就会想着增加服务器，那么我们多个项目就启动在多个服务器上面，用户需要访问，就需要做一个代理服务器，通过代理请求服务器来做前后端之间的转发和请求包括跨域等等问题。

那么到这就不得不说一下nginx的反向代理了，正向代理指的其实就是比如我们通过VPN去请求xxx，这里就是因为用到了其他地方的代理服务器，这是一个从客户端到服务端的过程，然而反向代理其实就是，因为我们有多个服务器，最后都映射到了代理服务器身上，客户端最终访问的都是例如：baidu.com，但是事实上他底下是有多台服务器的。

既然他有多台服务器，每台服务器的性能，各种条件都是不同的，这里就要说到nginx的另一个能力---负载均衡，可以给不同的服务器增加不同的权重，能力更强的服务器可以增大他的负荷，减轻其他服务器的负荷

这就是大家常说的nginx:Nginx 是一个高性能的 HTTP 和反向代理服务器，它还支持 IMAP/POP3/SMTP 代理服务器。

nginx的特点：

nginx下载

nginx.org/ 大家自行下载，我下载的是一个稳定版本，以防万一。下载完毕之后大家自行解压即可（默认大家是windows系统），解压完毕之后，可以看到nginx.exe就是我们的启动文件，conf就是配置文件，nginx.config中可以看到server的listen监听端口为80，这意味着当我们访问了80端口就会被nginx拦截，首先启动nginx，可以直接双击nginx.exe也可以通过cmd命令行直接输入nginx.exe运行（推荐，因为这样不会关闭窗口，双击的话就是一闪而过了）

接下来我们浏览器访问localhost:80

启动成功。

nginx常用命令

停止：nginx.exe -s stop
安全退出：nginx.exe -s quit
重新加载配置文件：nginx.exe -s reload（常用）例如我们更改了端口
查看nginx进程：ps aux|grep nginx

实际应用

下载完毕后打开可以看到：

于是我们建立aa、bb两个文件夹，我们将index.html 分别放入aa和bb，这两个页面都打上自己的标记aa/bb

然后我们对nginx进行配置 nginx.conf

server {

       listen       8001;

       server_name  localhost;



       location / {

           root   html/aa;

           index  index.html index.htm;

       }

    }



    server {

       listen       8002;

       server_name  localhost;



       location / {

           root   html/bb;

           index  index.html index.htm;

       }

    }

如果没结束，记得reload

nginx.exe -s reload

接下来我们放一个项目进去，打包后放入html中

修改配置文件，然后reload

 server {

        listen       80;

        server_name  localhost;



        #charset koi8-r;



        #access_log  logs/host.access.log  main;



        location / {

            root   html/dist;

            index  index.html index.htm;

        }

然后我们访问localhost，端口默认是80所以不用写，如果失败，可能是reload失败，再次reload就可

其他配置问题

Nginx的主配置文件(conf/nginx.conf)按以下结构组织：

• 全局块 与Nginx运行相关的全局设置


• events 与网络连接有关的设置


• http 代理、缓存、日志、虚拟主机等的配置


• server 虚拟主机的参数设置（一个http块可包含多个server块）


• location 定义请求路由及页面处理方式

前端开发中经常会遇到跨域问题，nginx可以做代理轻松解决，事实上原理和cors一样，设置请求头

server {

    location /api {

        proxy_pass http://backend_server;

        add_header Access-Control-Allow-Origin *;

        add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';

        add_header Access-Control-Allow-Headers 'Origin, Content-Type, Accept';

    }

}

缓存问题：

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;



server {

    location / {

        proxy_cache my_cache;

        proxy_pass http://backend;

        add_header X-Cache-Status $upstream_cache_status;

    }

}

https提升安全性

server {

    listen 443 ssl;

    server_name example.com;



    ssl_certificate /etc/nginx/ssl/example.com.crt;

    ssl_certificate_key /etc/nginx/ssl/example.com.key;



    location / {

        proxy_pass http://backend_server;

    }

}

一个比较全面的配置

# 全局段配置

# ------------------------------



# 指定运行nginx的用户或用户组，默认为nobody。

#user administrator administrators;



# 设置工作进程数，通常设置为等于CPU核心数。

#worker_processes 2;



# 指定nginx进程的PID文件存放位置。

#pid /nginx/pid/nginx.pid;



# 指定错误日志的存放路径和日志级别。

error_log log/error.log debug;



# events段配置信息

# ------------------------------

events {

    # 设置网络连接序列化，用于防止多个进程同时接受到新连接的情况，这种情况称为"惊群"。

    accept_mutex on;



    # 设置一个进程是否可以同时接受多个新连接。

    multi_accept on;



    # 设置工作进程的最大连接数。

    worker_connections  1024;

}



# http配置段，用于配置HTTP服务器的参数。

# ------------------------------

http {

    # 包含文件扩展名与MIME类型的映射。

    include       mime.types;



    # 设置默认的MIME类型。

    default_type  application/octet-stream;



    # 定义日志格式。

    log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for';



    # 指定访问日志的存放路径和使用的格式。

    access_log log/access.log myFormat;



    # 允许使用sendfile方式传输文件。

    sendfile on;



    # 限制每次调用sendfile传输的数据量。

    sendfile_max_chunk 100k;



    # 设置连接的保持时间。

    keepalive_timeout 65;



    # 定义一个上游服务器组。

    upstream mysvr {   

      server 127.0.0.1:7878;

      server 192.168.10.121:3333 backup;  #此服务器为备份服务器。

    }



    # 定义错误页面的重定向地址。

    error_page 404 https://www.baidu.com;



    # 定义一个虚拟主机。

    server {

        # 设置单个连接上的最大请求次数。

        keepalive_requests 120;



        # 设置监听的端口和地址。

        listen       4545;

        server_name  127.0.0.1;



        # 定义location块，用于匹配特定的请求URI。

        location  ~*^.+$ {

           # 设置请求的根目录。

           #root path;



           # 设置默认页面。

           #index vv.txt;



           # 将请求转发到上游服务器组。

           proxy_pass  http://mysvr;



           # 定义访问控制规则。

           deny 127.0.0.1;

           allow 172.18.5.54;          

        } 

    }

}

如果有不明白的地方，遇到问题可以通过ai去迅速了解，在ai时代，我们的学习成本也大大下降了。

小结

本次主要带小白朋友学习nginx是什么、用于做什么，nginx的常用命令，nginx如何进行配置，最后实际操作一次简单的nginx。

嗨，你好，我是猿java

在很长一段时间里，ZooKeeper都是 Kafka的标配，现如今，Kafka官方已经在慢慢去除ZooKeeper，Kafka 为什么要抛弃 Zookeeper？这篇文章我们来聊聊其中的缘由。

Kafka 和 ZooKeeper 的关系

ZooKeeper 是一个分布式协调服务，常用于管理配置、命名和同步服务。长期以来，Kafka 使用 ZooKeeper 负责管理集群元数据、控制器选举和消费者组协调等任务理，包括主题、分区信息、ACL（访问控制列表）等。

ZooKeeper 为 Kafka 提供了选主（leader election）、集群成员管理等核心功能，为 Kafka提供了一个可靠的分布式协调服务，使得 Kafka能够在多个节点之间进行有效的通信和管理。然而，随着 Kafka的发展，其对 ZooKeeper的依赖逐渐显露出一些问题，这些问题也是下面 Kafka去除 Zookeeper的原因。

抛弃ZooKeeper的原因

1. 复杂性增加

ZooKeeper 是独立于 Kafka 的外部组件，需要单独部署和维护，因此，使用 ZooKeeper 使得 Kafka的运维复杂度大幅提升。运维团队必须同时管理两个分布式系统（Kafka和 ZooKeeper），这不仅增加了管理成本，也要求运维人员具备更高的技术能力。

2. 性能瓶颈

作为一个协调服务，ZooKeeper 并非专门为高负载场景设计， 因此，随着集群规模扩大，ZooKeeper在处理元数据时的性能问题日益突出。例如，当分区数量增加时，ZooKeeper需要存储更多的信息，这导致了监听延迟增加，从而影响Kafka的整体性能34。在高负载情况下，ZooKeeper可能成为系统的瓶颈，限制了Kafka的扩展能力。

3. 一致性问题

Kafka 内部的分布式一致性模型与 ZooKeeper 的一致性模型有所不同。由于 ZooKeeper和 Kafka控制器之间的数据同步机制不够高效，可能导致状态不一致，特别是在处理集群扩展或不可用情景时，这种不一致性会影响消息传递的可靠性和系统稳定性。

4. 发展自己的生态

Kafka 抛弃 ZooKeeper，我个人觉得最核心的原因是：Kafka生态强大了，需要自立门户，这样就不会被别人卡脖子。纵观国内外，有很多这样鲜活的例子，当自己弱小时，会先选择使用别家的产品，当自己羽翼丰满时，再选择自建完善自己的生态圈。

引入KRaft

为了剥离和去除 ZooKeeper，Kafka 引入了自己的亲儿子 KRaft（Kafka Raft Metadata Mode）。KRaft 是一个新的元数据管理架构，基于 Raft 一致性算法实现的一种内置元数据管理方式，旨在替代 ZooKeeper 的元数据管理功能。其优势在于：

KRaft的设计细节

下面给出一张 Zookeeper 和 KRaft的对比图：

总结

本文，我们分析了为什么 Kafka 要移除 ZooKeeper，主要原因有两个：ZooKeeper不能满足 Kafka的发展以及 Kafka想创建自己的生态。在面临越来越复杂的数据流处理需求时，KRaft 模式为 Kafka 提供了一种更高效、简洁的架构方案。不论结局如何，Kafka 和 ZooKeeper曾经也度过了一段美好的蜜月期，祝福 Kafka 在 KRaft模式越来越强大，为使用者带来更好的体验。

学习交流

如果你觉得文章有帮助，请帮忙转发给更多的好友，或关注公众号：猿java，持续输出硬核文章。

今天本能是想测试一个PDO持久化，会不会带来会话混乱的问题
先贴一下PHP代码, 代码丑了点，但是坚持能run就行，反正就是做个测试。

<?php

$dsn = 'mysql:host=localhost;dbname=test;charset=utf8';

$user = 'root';

$password = 'root';



// 设置 PDO 选项，启用持久化连接

$options = [

    PDO::ATTR_PERSISTENT => true,

    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION

];



try {

    // 创建持久化连接

    $pdo = new PDO($dsn, $user, $password, $options);



    $stmt = $pdo->prepare("INSERT INTO test_last_insert_id (uni) VALUES (:uni);");

    $uni = uniqid('', true);

    $stmt->bindValue(':uni', $uni);

    $aff = $stmt->execute(); //

    if ($aff === false) {

        throw new Exception("insert fail:");

    }

    $id = $pdo->lastInsertId();





    function getExecutedSql($stmt, $params)

    {

        $sql = $stmt->queryString;

        $keys = array();

        $values = array();



        // 替换命名占位符 :key with ?

        $sql = preg_replace('/\:(\w+)/', '?', $sql);



        // 绑定的参数可能包括命名占位符，我们需要将它们转换为匿名占位符

        foreach ($params as $key => $value) {

            $keys[] = '/\?/';

            $values[] = is_string($value) ? "'$value'" : $value;

        }



        // 替换占位符为实际参数

        $sql = preg_replace($keys, $values, $sql, 1, $count);



        return $sql;

    }





    $stmt = $pdo->query("SELECT id FROM test_last_insert_id WHERE uni = '{$uni}'", PDO::FETCH_NUM);

    $row = $stmt->fetch();

    $value = $row[0];

    if ($value != $id) {

        throw new Exception("id is diff");

    }



    echo "success" . PHP_EOL;



} catch (PDOException $e) {

    header('HTTP/1.1 500 Internal Server Error');

    file_put_contents('pdo_perisistent.log', $e->getMessage() . PHP_EOL);

    die('Database connection failed: ' . $e->getMessage());

} catch (Exception $e) {

    header('HTTP/1.1 500 Internal Server Error');

    file_put_contents('pdo_perisistent.log', $e->getMessage() . PHP_EOL);

    die('Exception: ' . $e->getMessage());

}

用wrk压测，一开始uniqid因为少了混淆参数还报了500，加了一下参数，用来保证uni值

% ./wrk -c100 -t2 -d3s --latency  "http://localhost/pdo_perisistent.php"

Running 3s test @ http://localhost/pdo_perisistent.php

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    52.17ms    7.48ms 103.38ms   80.57%

    Req/Sec     0.96k   133.22     1.25k    75.81%

  Latency Distribution

     50%   51.06ms

     75%   54.17ms

     90%   59.45ms

     99%   80.54ms

  5904 requests in 3.10s, 1.20MB read

Requests/sec:   1901.92

Transfer/sec:    397.47KB

1900 ～ 2600 之间的QPS，其实这个数值还是相当满意的，测试会话会不会混乱的问题也算完结了。
但是好奇心突起，之前一直没做过go和php执行sql下的对比，正好做一次对比压测

package main



import (

    "database/sql"

    "fmt"

    "net/http"

    "sync/atomic"

    "time"



    _ "github.com/go-sql-driver/mysql"

    "log"

)



var id int64 = time.Now().Unix() * 1000000



func generateUniqueID() int64 {

    return atomic.AddInt64(&id, 1)

}



func main() {

    dsn := "root:root@tcp(localhost:3306)/test?charset=utf8"

    db, err := sql.Open("mysql", dsn)

    if err != nil {

       log.Fatalf("Error opening database: %v", err)

    }

    defer func() { _ = db.Close() }()



    //// 设置连接池参数

    //db.SetMaxOpenConns(100)          // 最大打开连接数

    //db.SetMaxIdleConns(10)           // 最大空闲连接数

    //db.SetConnMaxLifetime(time.Hour) // 连接最大存活时间



    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {

       var err error

       uni := generateUniqueID()



       // Insert unique ID int0 the database

       insertQuery := `INSERT INTO test_last_insert_id (uni) VALUES (?)`

       result, err := db.Exec(insertQuery, uni)

       if err != nil {

          log.Fatalf("Error inserting data: %v", err)

       }



       lastInsertID, err := result.LastInsertId()

       if err != nil {

          log.Fatalf("Error getting last insert ID: %v", err)

       }



       // Verify the last insert ID

       selectQuery := `SELECT id FROM test_last_insert_id WHERE uni = ?`

       var id int64

       err = db.QueryRow(selectQuery, uni).Scan(&id)

       if err != nil {

          log.Fatalf("Error selecting data: %v", err)

       }



       if id != lastInsertID {

          log.Fatalf("ID mismatch: %d != %d", id, lastInsertID)

       }



       fmt.Println("success")

    })



    _ = http.ListenAndServe(":8080", nil)



}

truncate表压测结果，这低于预期了吧

% ./wrk -c100 -t2 -d3s --latency  "http://localhost:8080"

Running 3s test @ http://localhost:8080

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    54.05ms   36.86ms 308.57ms   80.77%

    Req/Sec     0.98k   243.01     1.38k    63.33%

  Latency Distribution

     50%   43.70ms

     75%   65.42ms

     90%   99.63ms

     99%  190.18ms

  5873 requests in 3.01s, 430.15KB read

Requests/sec:   1954.08

Transfer/sec:    143.12KB

开个连接池，清表再测，结果半斤八两

% ./wrk -c100 -t2 -d3s --latency  "http://localhost:8080"

Running 3s test @ http://localhost:8080

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    54.07ms   35.87ms 281.38ms   79.84%

    Req/Sec     0.97k   223.41     1.40k    60.00%

  Latency Distribution

     50%   44.91ms

     75%   66.19ms

     90%   99.65ms

     99%  184.51ms

  5818 requests in 3.01s, 426.12KB read

Requests/sec:   1934.39

Transfer/sec:    141.68KB

然后开启不清表的情况下，php和go的交叉压测

% ./wrk -c100 -t2 -d3s --latency  "http://localhost:8080"

Running 3s test @ http://localhost:8080

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    52.51ms   43.28ms 436.00ms   86.91%

    Req/Sec     1.08k   284.67     1.65k    65.00%

  Latency Distribution

     50%   40.22ms

     75%   62.10ms

     90%  102.52ms

     99%  233.98ms

  6439 requests in 3.01s, 471.61KB read

Requests/sec:   2141.12

Transfer/sec:    156.82KB



% ./wrk -c100 -t2 -d3s --latency  "http://localhost/pdo_perisistent.php"

Running 3s test @ http://localhost/pdo_perisistent.php

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    41.41ms   10.44ms  77.04ms   78.07%

    Req/Sec     1.21k   300.99     2.41k    73.77%

  Latency Distribution

     50%   38.91ms

     75%   47.62ms

     90%   57.38ms

     99%   69.84ms

  7332 requests in 3.10s, 1.50MB read

Requests/sec:   2363.74

Transfer/sec:    493.98KB



// 这里骤降是我很不理解的不明白是因为什么

% ./wrk -c100 -t2 -d3s --latency  "http://localhost:8080"               

Running 3s test @ http://localhost:8080

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency   156.72ms   75.48ms 443.98ms   66.10%

    Req/Sec   317.93     84.45   480.00     71.67%

  Latency Distribution

     50%  155.21ms

     75%  206.36ms

     90%  254.32ms

     99%  336.07ms

  1902 requests in 3.01s, 139.31KB read

Requests/sec:    631.86

Transfer/sec:     46.28KB



% ./wrk -c100 -t2 -d3s --latency  "http://localhost/pdo_perisistent.php"

Running 3s test @ http://localhost/pdo_perisistent.php

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    43.47ms   10.04ms 111.41ms   90.21%

    Req/Sec     1.15k   210.61     1.47k    72.58%

  Latency Distribution

     50%   41.17ms

     75%   46.89ms

     90%   51.27ms

     99%   95.07ms

  7122 requests in 3.10s, 1.45MB read

Requests/sec:   2296.19

Transfer/sec:    479.87KB



% ./wrk -c100 -t2 -d3s --latency  "http://localhost:8080"               

Running 3s test @ http://localhost:8080

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency   269.08ms  112.17ms 685.29ms   73.69%

    Req/Sec   168.22    125.46   520.00     79.59%

  Latency Distribution

     50%  286.58ms

     75%  335.40ms

     90%  372.61ms

     99%  555.80ms

  1099 requests in 3.02s, 80.49KB read

Requests/sec:    363.74

Transfer/sec:     26.64KB



% ./wrk -c100 -t2 -d3s --latency  "http://localhost/pdo_perisistent.php"

Running 3s test @ http://localhost/pdo_perisistent.php

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    41.74ms    9.67ms 105.86ms   91.72%

    Req/Sec     1.20k   260.04     2.24k    80.33%

  Latency Distribution

     50%   38.86ms

     75%   46.77ms

     90%   49.02ms

     99%   83.01ms

  7283 requests in 3.10s, 1.49MB read

Requests/sec:   2348.07

Transfer/sec:    490.71KB



% ./wrk -c100 -t2 -d3s --latency  "http://localhost:8080"               

Running 3s test @ http://localhost:8080

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency   464.85ms  164.66ms   1.06s    71.97%

    Req/Sec   104.18     60.01   237.00     63.16%

  Latency Distribution

     50%  467.00ms

     75%  560.54ms

     90%  660.70ms

     99%  889.86ms

  605 requests in 3.01s, 44.31KB read

Requests/sec:    200.73

Transfer/sec:     14.70KB



% ./wrk -c100 -t2 -d3s --latency  "http://localhost/pdo_perisistent.php"

Running 3s test @ http://localhost/pdo_perisistent.php

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    50.62ms    9.16ms  85.08ms   75.74%

    Req/Sec     0.98k   170.66     1.30k    69.35%

  Latency Distribution

     50%   47.93ms

     75%   57.20ms

     90%   61.76ms

     99%   79.90ms

  6075 requests in 3.10s, 1.24MB read

Requests/sec:   1957.70

Transfer/sec:    409.13KB



% ./wrk -c100 -t2 -d3s --latency  "http://localhost:8080"               

Running 3s test @ http://localhost:8080

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency   568.84ms  160.91ms   1.04s    66.38%

    Req/Sec    81.89     57.59   262.00     67.27%

  Latency Distribution

     50%  578.70ms

     75%  685.85ms

     90%  766.72ms

     99%  889.39ms

  458 requests in 3.01s, 33.54KB read

Requests/sec:    151.91

Transfer/sec:     11.13KB

go 的代码随着不断的测试，很明显处理速度在不断的下降，这说实话有点超出我的认知了。
PHP那边却是基本稳定的，go其实一开始我还用gin测试过，发现测试结果有点超出预料，还改了用http库来测试，这结果属实差强人意了。

突然明白之前经常看到别人在争论性能问题的时候，为什么总有人强调PHP性能并不差。
或许PHP因为fpm的关系导致每次加载大量文件导致的响应相对较慢，比如框架laravel 那个QPS只有一两百的家伙，但其实这个问题要解决也是可以解决的，也用常驻内存的方式就好了。再不行还有phalcon

我一直很好奇一直说PHP性能问题的到底是哪些人， 不会是从PHP转到其他语言的吧。

% php -v

PHP 8.3.12 (cli) (built: Sep 24 2024 18:08:04) (NTS)

Copyright (c) The PHP Gr0up

Zend Engine v4.3.12, Copyright (c) Zend Technologies

    with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans

    with Zend OPcache v8.3.12, Copyright (c), by Zend Technologies



% go version

go version go1.23.1 darwin/amd64

这结果，其实不太能接受，甚至都不知道原因出在哪了，有大佬可以指出问题一下吗

加一下时间打印再看看哪里的问题

package main



import (

    "database/sql"

    "fmt"

    "net/http"

    "sync/atomic"

    "time"



    _ "github.com/go-sql-driver/mysql"

    "log"

)



var id int64 = time.Now().Unix() * 1000000



func generateUniqueID() int64 {

    return atomic.AddInt64(&id, 1)

}



func main() {

    dsn := "root:root@tcp(localhost:3306)/test?charset=utf8"

    db, err := sql.Open("mysql", dsn)

    if err != nil {

       log.Fatalf("Error opening database: %v", err)

    }

    defer func() { _ = db.Close() }()



    // 设置连接池参数

    db.SetMaxOpenConns(100)          // 最大打开连接数

    db.SetMaxIdleConns(10)           // 最大空闲连接数

    db.SetConnMaxLifetime(time.Hour) // 连接最大存活时间



    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {

       reqStart := time.Now()

       var err error

       uni := generateUniqueID()



       start := time.Now()

       // Insert unique ID int0 the database

       insertQuery := `INSERT INTO test_last_insert_id (uni) VALUES (?)`

       result, err := db.Exec(insertQuery, uni)

       fmt.Printf("insert since: %v uni:%d \n", time.Since(start), uni)

       if err != nil {

          log.Fatalf("Error inserting data: %v", err)

       }



       lastInsertID, err := result.LastInsertId()

       if err != nil {

          log.Fatalf("Error getting last insert ID: %v", err)

       }



       selectStart := time.Now()

       // Verify the last insert ID

       selectQuery := `SELECT id FROM test_last_insert_id WHERE uni = ?`

       var id int64

       err = db.QueryRow(selectQuery, uni).Scan(&id)

       fmt.Printf("select since:%v uni:%d \n", time.Since(selectStart), uni)

       if err != nil {

          log.Fatalf("Error selecting data: %v", err)

       }



       if id != lastInsertID {

          log.Fatalf("ID mismatch: %d != %d", id, lastInsertID)

       }



       fmt.Printf("success req since:%v uni:%d \n", time.Since(reqStart), uni)

    })



    _ = http.ListenAndServe(":8080", nil)



}

截取了后面的一部分输出，这不会是SQL库的问题吧，

success req since:352.310146ms uni:1729393975000652 

insert since: 163.316785ms uni:1729393975000688 

insert since: 154.983173ms uni:1729393975000691 

insert since: 158.094503ms uni:1729393975000689 

insert since: 136.831695ms uni:1729393975000697 

insert since: 141.857079ms uni:1729393975000696 

insert since: 128.115216ms uni:1729393975000702 

select since:412.94524ms uni:1729393975000634 

success req since:431.383768ms uni:1729393975000634 

select since:459.596445ms uni:1729393975000601 

success req since:568.576336ms uni:1729393975000601 

insert since: 134.39147ms uni:1729393975000700 

select since:390.926517ms uni:1729393975000643 

success req since:391.622183ms uni:1729393975000643 

select since:366.098937ms uni:1729393975000648 

success req since:373.490764ms uni:1729393975000648 

insert since: 136.318919ms uni:1729393975000699 

select since:420.626209ms uni:1729393975000640 

success req since:425.243441ms uni:1729393975000640 

insert since: 167.181068ms uni:1729393975000690 

select since:272.22808ms uni:1729393975000671 

单次请求的时候输出结果是符合预期的， 但是并发SQL时会出现执行慢的问题，这就很奇怪了

% curl localhost:8080

insert since: 1.559709ms uni:1729393975000703 

select since:21.031284ms uni:1729393975000703 

success req since:22.62274ms uni:1729393975000703

经群友提示还和唯一键的区分度有关，两边算法一致有点太难了，Go换了雪法ID之后就正常了。
因为之前 Go这边生成的uni值是递增的导致区分度很低，最终导致并发写入查询效率变低。

% ./wrk -c100 -t2 -d3s --latency  "http://localhost:8080"

Running 3s test @ http://localhost:8080

  2 threads and 100 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency    44.51ms   24.87ms 187.91ms   77.98%

    Req/Sec     1.17k   416.31     1.99k    66.67%

  Latency Distribution

     50%   37.46ms

     75%   54.55ms

     90%   80.44ms

     99%  125.72ms

  6960 requests in 3.01s, 509.77KB read

Requests/sec:   2316.02

Transfer/sec:    169.63KB

2024-10-23 更新

今天本来是想验证一下有关，并发插入自增有序的唯一键高延迟的问题，发现整个有问题的只有一行代码。
就是在查询时，类型转换的问题，插入和查询都转换之后，空表的情况下QPS 可以到4000多。即使在已有大数据量（几十万）的情况也有两千多的QPS。
现在又多了一个问题，为什么用雪花ID时不会有这样的问题。雪花ID也是int64类型的，这是为什么呢。

// 旧代码

err = db.QueryRow(selectQuery, uni).Scan(&id) 

if err != nil { 

    log.Fatalf("Error selecting data: %v", err) 

}



  

// 新代码 变化只有一个就是把uni 转成字符串之后就没有问题了

var realId int64

err = db.QueryRow(selectQuery, fmt.Sprintf("%d", uni)).Scan(&realId)

if err != nil {

    log.Fatalf("Error selecting data: %v", err)

}

前言

hi，大家好，我是大鱼七成饱。

前几天同事review我的代码，发现mapstruct有这么多好用的技巧，遇到POJO转换的问题经常过来沟通。考虑到不可能每次都一对一，所以我来梳理五个场景，谁在过来问，直接甩出总结。

环境准备

由于日常使用都是spring，所以后面的示例都是在springboot框架中运行的。关键pom依赖如下：

<properties>

        <java.version>1.8</java.version>

        <org.mapstruct.version>1.5.5.Final</org.mapstruct.version>

        <org.projectlombok.version>1.18.30</org.projectlombok.version>

    </properties>

    <dependencies>



        <dependency>

            <groupId>org.mapstruct</groupId>

            <artifactId>mapstruct</artifactId>

            <version>${org.mapstruct.version}</version>

        </dependency>

        <dependency>

            <groupId>org.mapstruct</groupId>

            <artifactId>mapstruct-processor</artifactId>

            <version>${org.mapstruct.version}</version>

        </dependency>



        <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok</artifactId>

            <optional>true</optional>

            <scope>provided</scope>

        </dependency>



        <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok-mapstruct-binding</artifactId>

            <version>0.2.0</version>

        </dependency>



        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter</artifactId>

        </dependency>



        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-test</artifactId>

            <scope>test</scope>

        </dependency>

    </dependencies>



    <build>

        <plugins>

            <plugin>

                <groupId>org.springframework.boot</groupId>

                <artifactId>spring-boot-maven-plugin</artifactId>

            </plugin>

        </plugins>

    </build>

场景一：常量转换

这是最简单的一个场景，比如需要设置字符串、整形和长整型的常量，有的又需要日期，或者新建类型。下面举个例子，演示如何转换

//实体类

@Data

public class Source {

    private String stringProp;

    private Long longProp;

}

@Data

public class Target {

    private String stringProperty;

    private long longProperty;

    private String stringConstant;

    private Integer integerConstant;

    private Long  longWrapperConstant;

    private Date dateConstant;

}

• 设置字符串常量


• 设置long常量


• 设置java内置类型默认值，比如date

那么mapper这么设置就可以

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface SourceTargetMapper {



    @Mapping(target = "stringProperty", source = "stringProp", defaultValue = "undefined")

    @Mapping(target = "longProperty", source = "longProp", defaultValue = "-1l")

    @Mapping(target = "stringConstant", constant = "Constant Value")

    @Mapping(target = "integerConstant", constant = "14")

    @Mapping(target = "longWrapperConstant", constant = "3001L")

    @Mapping(target = "dateConstant", dateFormat = "yyyy-MM-dd", constant = "2023-09-")

    Target sourceToTarget(Source s);

}

解释下，constant用来设置常量值，source的值如果没有设置，则会使用defaultValue的值，日期可以按dateFormat解析。

Talk is cheap, show me the code !废话不多说，自动生成的转换类如下：

@Component

public class SourceTargetMapperImpl implements SourceTargetMapper {

    public SourceTargetMapperImpl() {

    }



    public Target sourceToTarget(Source s) {

        if (s == null) {

            return null;

        } else {

            Target target = new Target();

            if (s.getStringProp() != null) {

                target.setStringProperty(s.getStringProp());

            } else {

                target.setStringProperty("undefined");

            }



            if (s.getLongProp() != null) {

                target.setLongProperty(s.getLongProp());

            } else {

                target.setLongProperty(-1L);

            }



            target.setStringConstant("Constant Value");

            target.setIntegerConstant(14);

            target.setLongWrapperConstant(3001L);



            try {

                target.setDateConstant((new SimpleDateFormat("dd-MM-yyyy")).parse("09-01-2014"));

                return target;

            } catch (ParseException var4) {

                throw new RuntimeException(var4);

            }

        }

    }

}

是不是一目了然

场景二：转换中调用表达式

比如id不存在使用UUID生成一个，或者使用已有参数新建一个对象作为属性。当然可以用after mapping，qualifiedByName等实现，感觉还是不够优雅，这里介绍个雅的（代码少点的）。

实体类如下：

@Data

public class CustomerDto {

    public Long id;

    public String customerName;



    private String format;

    private Date time;

}

@Data

public class Customer {

    private String id;

    private String name;

    private TimeAndFormat timeAndFormat;

}

@Data

public class TimeAndFormat {

    private Date time;

    private String format;



    public TimeAndFormat(Date time, String format) {

        this.time = time;

        this.format = format;

    }

}

Dto转customer，加创建TimeAndFormat作为属性，mapper实现如下：

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING, imports = UUID.class)

public interface CustomerMapper {



    @Mapping(target = "timeAndFormat",

            expression = "java( new TimeAndFormat( s.getTime(), s.getFormat() ) )")

    @Mapping(target = "id", source = "id", defaultExpression = "java( UUID.randomUUID().toString() )")

    Customer toCustomer(CustomerDto s);



}

解释下，id为空则走默认的defaultExpression，通过imports引入，java括起来调用。新建对象直接new TimeAndFormat。有的小伙伴喜欢用qualifiedByName自定义方法，可以对比下，哪个合适用哪个，都能调用转换方法。

生成代码如下：

@Component

public class CustomerMapperImpl implements CustomerMapper {

    public CustomerMapperImpl() {

    }



    public Customer toCustomer(CustomerDto s) {

        if (s == null) {

            return null;

        } else {

            Customer customer = new Customer();

            if (s.getId() != null) {

                customer.setId(String.valueOf(s.getId()));

            } else {

                customer.setId(UUID.randomUUID().toString());

            }



            customer.setTimeAndFormat(new TimeAndFormat(s.getTime(), s.getFormat()));

            return customer;

        }

    }

}

场景三：类共用属性，如何复用

比如下面的Bike和车辆类，都有id和creationDate属性，我又不想重复写mapper属性注解

public class Bike {

    /**

     * 唯一id

     */

    private String id;



    private Date creationDate;



    /**

     * 品牌

     */

    private String brandName;

}



public class Car {

    /**

     * 唯一id

     */

    private String id;



    private Date creationDate;

    /**

     * 车牌号

     */

    private String chepaihao;

 }

解决起来很简单，写个共用的注解，使用的时候引入就可以，示例如下：

//通用注解

@Retention(RetentionPolicy.CLASS)

//自动生成当前日期

@Mapping(target = "creationDate", expression = "java(new java.util.Date())")

//忽略id

@Mapping(target = "id", ignore = true)

public @interface ToEntity { }



//使用

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface TransportationMapper {

    @ToEntity

    @Mapping( target = "brandName", source = "brand")

    Bike map(BikeDto source);



    @ToEntity

    @Mapping( target = "chepaihao", source = "plateNo")

    Car map(CarDto source);

}

这里Retention修饰ToEntity注解，表示ToEntity注解被保留到class文件，但jvm加载class文件时候被遗弃，这是默认的生命周期，辅助生成mapper实现类。上面定义了creationDate和id的转换规则,新建日期，忽略id。

生成的mapper实现类如下：

@Component

public class TransportationMapperImpl implements TransportationMapper {

    public TransportationMapperImpl() {

    }



    public Bike map(BikeDto source) {

        if (source == null) {

            return null;

        } else {

            Bike bike = new Bike();

            bike.setBrandName(source.getBrand());

            bike.setCreationDate(new Date());

            return bike;

        }

    }



    public Car map(CarDto source) {

        if (source == null) {

            return null;

        } else {

            Car car = new Car();

            car.setChepaihao(source.getPlateNo());

            car.setCreationDate(new Date());

            return car;

        }

    }

}

坚持一下，还剩俩场景，剩下的俩更有意思

场景四：lombok和mapstruct冲突了

啥冲突？用了builder注解后，mapstuct转换不出来了。哎，这个问题困扰了我那同事两天时间。

解决方案如下：

 <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok-mapstruct-binding</artifactId>

            <version>0.2.0</version>

 </dependency>

加上lombok-mapstruct-binding就可以了，看下生成的效果：

@Builder

@Data

public class Person {

    private String name;

}

@Data

public class PersonDto {

    private String name;

}

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface PersonMapper {



    Person map(PersonDto dto);

}

@Component

public class PersonMapperImpl implements PersonMapper {

    public PersonMapperImpl() {

    }



    public Person map(PersonDto dto) {

        if (dto == null) {

            return null;

        } else {

            Person.PersonBuilder person = Person.builder();

            person.name(dto.getName());

            return person.build();

        }

    }

}

从上面可以看到，mapstruct匹配到了lombok的builder方法。

场景五：说个难点的，转换的时候，如何注入springBean

有时候转换方法比不是静态的，他可能依赖spring bean，这个如何导入？

这个使用需要使用抽象方法了，上代码：

@Component

public class SimpleService {

    public String formatName(String name) {

        return  "您的名字是：" + name;

    }

}

@Data

public class Student {

    private String name;

}

@Data

public class StudentDto {

    private String name;

}

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public abstract class StudentMapper {



    @Autowired

    protected SimpleService simpleService;



    @Mapping(target = "name", expression = "java(simpleService.formatName(source.getName()))")

    public abstract StudentDto map(StudentDto source);

}

接口是不支持注入的，但是抽象类可以，所以采用抽象类解决，后面expression直接用皆可以了，生成mapperimpl如下：

@Component

public class StudentMapperImpl extends StudentMapper {

    public StudentMapperImpl() {

    }



    public StudentDto map(StudentDto source) {

        if (source == null) {

            return null;

        } else {

            StudentDto studentDto = new StudentDto();

            studentDto.setName(this.simpleService.formatName(source.getName()));

            return studentDto;

        }

    }

}

思考

以上场景肯定还有其他解决方案，遵循合适的原则就可以。驾驭不了的代码，可能带来更多问题，先简单实现，后续在迭代优化可能适合更多的业务场景。

本文示例代码放在了github，需要的朋友请关注公众号大鱼七成饱,回复关键词MapStruct使用即可获得。

在 Spring Boot 框架中，内置了许多实用的功能，这些功能可以帮助开发者高效地开发和维护应用程序。

松哥来和大家列举几个。

一 请求数据记录

Spring Boot提供了一个内置的日志记录解决方案，通过 AbstractRequestLoggingFilter 可以记录请求的详细信息。

AbstractRequestLoggingFilter 有两个不同的实现类，我们常用的是 CommonsRequestLoggingFilter。

通过 CommonsRequestLoggingFilter 开发者可以自定义记录请求的参数、请求体、请求头和客户端信息。

启用方式很简单，加个配置就行了：

@Configuration

public class RequestLoggingConfig {

    @Bean

    public CommonsRequestLoggingFilter logFilter() {

        CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter();

        filter.setIncludeQueryString(true);

        filter.setIncludePayload(true);

        filter.setIncludeHeaders(true);

        filter.setIncludeClientInfo(true);

        filter.setAfterMessagePrefix("REQUEST ");

        return filter;

    }

}

接下来需要配置日志级别为 DEBUG，就可以详细记录请求信息：

logging.level.org.springframework.web.filter.CommonsRequestLoggingFilter=DEBUG

二 请求/响应包装器

2.1 什么是请求和响应包装器

在 Spring Boot 中，请求和响应包装器是用于增强原生 HttpServletRequest 和 HttpServletResponse 对象的功能。这些包装器允许开发者在请求处理过程中拦截和修改请求和响应数据，从而实现一些特定的功能，如请求内容的缓存、修改、日志记录，以及响应内容的修改和增强。

请求包装器

• ContentCachingRequestWrapper：这是 Spring 提供的一个请求包装器，用于缓存请求的输入流。它允许多次读取请求体，这在需要多次处理请求数据（如日志记录和业务处理）时非常有用。

响应包装器

• ContentCachingResponseWrapper：这是 Spring 提供的一个响应包装器，用于缓存响应的输出流。它允许开发者在响应提交给客户端之前修改响应体，这在需要对响应内容进行后处理（如添加额外的头部信息、修改响应体）时非常有用。

2.2 使用场景

2.3 具体用法

请求包装器的使用

import org.springframework.web.filter.OncePerRequestFilter;

import javax.servlet.FilterChain;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;



@Component

public class RequestWrapperFilter extends OncePerRequestFilter {

    @Override

    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)

            throws ServletException, IOException {

        ContentCachingRequestWrapper requestWrapper = new ContentCachingRequestWrapper(request);

        // 可以在这里处理请求数据

        byte[] body = requestWrapper.getContentAsByteArray();

        // 处理body，例如记录日志

        //。。。

        filterChain.doFilter(requestWrapper, response);

    }

}

响应包装器的使用

import org.springframework.web.filter.OncePerRequestFilter;

import javax.servlet.FilterChain;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;



@Component

public class ResponseWrapperFilter extends OncePerRequestFilter {

    @Override

    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)

            throws ServletException, IOException {

        ContentCachingResponseWrapper responseWrapper = new ContentCachingResponseWrapper(response);

        filterChain.doFilter(request, responseWrapper);



        // 可以在这里处理响应数据

        byte[] body = responseWrapper.getContentAsByteArray();

        // 处理body，例如添加签名

        responseWrapper.setHeader("X-Signature", "some-signature");



        // 必须调用此方法以将响应数据发送到客户端

        responseWrapper.copyBodyToResponse();

    }

}

在上面的案例中，OncePerRequestFilter 确保过滤器在一次请求的生命周期中只被调用一次，这对于处理请求和响应数据尤为重要，因为它避免了在请求转发或包含时重复处理数据。

通过使用请求和响应包装器，开发者可以在不改变原有业务逻辑的情况下，灵活地添加或修改请求和响应的处理逻辑。

三 单次过滤器

3.1 OncePerRequestFilter

OncePerRequestFilter 是 Spring 框架提供的一个过滤器基类，它继承自 Filter 接口。这个过滤器具有以下特点：

3.2 OncePerRequestFilter 使用场景

通过使用 OncePerRequestFilter，开发者可以确保过滤器逻辑在一次请求的生命周期内只执行一次，从而避免重复处理和潜在的性能问题。这使得 OncePerRequestFilter 成为处理复杂请求和响应逻辑时的一个非常有用的工具。

OncePerRequestFilter 的具体用法松哥就不举例了，第二小节已经介绍过了。

四 AOP 三件套

在 Spring 框架中，AOP（面向切面编程）是一个强大的功能，它允许开发者在不修改源代码的情况下，对程序的特定部分进行横向切入。AopContext、AopUtils 和 ReflectionUtils 是 Spring AOP 中提供的几个实用类。

我们一起来看下。

4.1 AopContext

AopContext 是 Spring 框架中的一个类，它提供了对当前 AOP 代理对象的访问，以及对目标对象的引用。

AopContext 主要用于获取当前代理对象的相关信息，以及在 AOP 代理中进行一些特定的操作。

常见方法有两个：

• getTargetObject(): 获取当前代理的目标对象。


• currentProxy(): 获取当前的代理对象。

其中第二个方法，在防止同一个类中注解失效的时候，可以通过该方法获取当前类的代理对象。

举个栗子：

public void noTransactionTask(String keyword){    // 注意这里 调用了代理类的方法

    ((YourClass) AopContext.currentProxy()).transactionTask(keyword);

}



@Transactional

void transactionTask(String keyword) {

    try {

        Thread.sleep(5000);

    } catch (InterruptedException e) {        //logger

        //error tracking

    }

    System.out.println(keyword);

}

同一个类中两个方法，noTransactionTask 方法调用 transactionTask 方法，为了使事务注解不失效，就可以使用 AopContext.currentProxy() 去获取当前代理对象。

4.2 AopUtils

AopUtils 提供了一些静态方法来处理与 AOP 相关的操作，如获取代理对象、获取目标对象、判断代理类型等。

常见方法有三个：

• getTargetObject(): 从代理对象中获取目标对象。


• isJdkDynamicProxy(Object obj): 判断是否是 JDK 动态代理。


• isCglibProxy(Object obj): 判断是否是 CGLIB 代理。

举个栗子：

import org.springframework.aop.framework.AopProxyUtils;

import org.springframework.aop.support.AopUtils;



public class AopUtilsExample {

    public static void main(String[] args) {

        MyService myService = ...

        // 假设 myService 已经被代理

        if (AopUtils.isCglibProxy(myService)) {

            System.out.println("这是一个 CGLIB 代理对象");

        }

    }

}

4.3 ReflectionUtils

ReflectionUtils 提供了一系列反射操作的便捷方法，如设置字段值、获取字段值、调用方法等。这些方法封装了 Java 反射 API 的复杂性，使得反射操作更加简单和安全。

常见方法：

• makeAccessible(Field field): 使私有字段可访问。


• getField(Field field, Object target): 获取对象的字段值。


• invokeMethod(Method method, Object target, Object... args): 调用对象的方法。

举个栗子：

import org.springframework.util.ReflectionUtils;



import java.lang.reflect.Field;

import java.util.Map;



public class ReflectionUtilsExample {

    public static void main(String[] args) throws Exception {

        ExampleBean bean = new ExampleBean();

        bean.setMapAttribute(new HashMap<>());



        Field field = ReflectionUtils.findField(ExampleBean.class, "mapAttribute");

        ReflectionUtils.makeAccessible(field);



        Object value = ReflectionUtils.getField(field, bean);

        System.out.println(value);

    }



    static class ExampleBean {

        private Map<String, String> mapAttribute;



        public void setMapAttribute(Map<String, String> mapAttribute) {

            this.mapAttribute = mapAttribute;

        }

    }

}

还有哪些实用内置类呢？欢迎小伙伴们留言～

大家好，我是徐徐。今天和大家谈谈我做 Electron 桌面端应用的这一两年，把一些经验和想法分享给大家。

前言

入职现在这家公司三年了，刚进公司的时候是 21 年年初，那时候会做一些稍微复杂的后台管理系统以及一些简单的 C 端 SDK。准备开始做 Electron 项目是因为我所在的是安全部门，急需一款桌面管控软件来管理（监控）员工的电脑安全以及入网准入，可以理解为一款零信任的桌面软件。其实之前公司也有一款安全管控的软件，但是Windows 和 Mac是分端构建的，而且维护成本极高，Windows 是使用的 C#, Mac 是用的 Objective-C，开发和发版效率低下，最后在研发老大的同意下，我和另外一个同事开始研究如何用 Electron 这个框架来做一款桌面端软件。

我们发起这个项目大概是在 21 年年底，Windows 版本上线是在上海疫情封城期间，2022年4月份的时候，疫情结束后由于事业部业务方向的调整，又被抽调到了另外一个组去做一个 C 端的创业项目，后面项目结束了，又回来做 Electron 相关的工作直到现在，之所以是一两年，其实就是这个时间线。

对桌面端开发的一些看法

如果你是前端的话，多一门桌面端开发的技能也不是坏事，相当是你的一个亮点，进可攻，退可守。因为桌面端开发到后期的架构可以非常的复杂，不亚于服务端（chromium 就是一个例子），当然也取决于你所应对的场景的挑战，如果所做的产品跟普通前端无异，那也不能说是一个亮点，但是如果你的工作已经触及到一些操作系统的底层，那肯定是一个亮点。

当然也有人说，做桌面端可能就路越走越窄了，但是我想说的是深度和广度其实也可以理解为一个维度，对于技术人来说，知道得越多就行，因为到后期你要成为某个方面的专家，就是可能会非常深入某一块，换一种思路其实也是叫知道得越多。所以，我觉得前端能有做桌面端的机会也是非常好的，即拓展了自己的技能，还能深入底层，因为现阶段由于业务方向的需要，我已经开始看 chromium 源码了，前端的老祖宗。当然，以上这些只代表自己的观点，大家自行斟酌。

谈谈 Electron

其实刚刚工作前两年我就知道这个框架了，当时也做过小 demo，而且还在当时的团队里面分享过这个技术，但是当时对这门技术的认知是非常浅薄的，就知道前端可以做桌面端了，好厉害，大概就停留在这个层面。后面在真正需要用到这门技术去做一个企业级的桌面应用的时候才去真正调研了一下这个框架，然后才发现它真的非常强大，强大到几乎可以实现你桌面端的任何需求。网上关于 Electron 与其他框架的对比实在是太多了，Google 或者 Baidu 都能找到你想要的答案，好与不好完全看自己的业务场景以及自己所在团队的情况。

谈谈自己的感受，什么情况下可以用这门框架

• 追求效率，节省人力财力


• 团队前端居多


• UI交互多

什么情况下不适合这门框架呢？

• 包体积限制


• 性能消耗较高的应用


• 多窗口应用

我们当时的情况就是要追求效率，双端齐头并进，所以最后经过综合对比，选择了 Electron。毕竟 Vscode 就是用它做的，给了我们十足的信心和勇气，一点都不虚。

一图抵千字，我拿出这张图你自己就有所判断了，还是那句话，仁者见仁，智者见智，完全看自己情况。

图片来源：http://www.electronjs.org/apps

技术整体架构

这里我画了一张我所从事 Electron 产品的整体技术架构图。

整个项目基于 Vite 开发构建的，基础设施就是常见的安全策略，然后加上一些本地存储方案，外加一个外部插件，这个插件是用 Tauri 做的 Webview，至于为什么要做这个插件我会在后面的段落说明。应用层面的框架主要是分三个大块，下面主要是为了构建一些基础底座，然后将架构进行分层设计，添加一些原生扩展，上面就是基础的应用管理和 GUI 相关的东西，有了这个整体的框架在后面实现一些业务场景的时候就会变得易如反掌（夸张了一点，因为有的技术细节真的很磨人😐）。

当然这里只是一个整体的架构图，其实还有很多技术细节的流程图以及业务场景图并没有在这里体现出来，不过我也会挑选一些方案在后面的篇幅里面做出相应的讲解。

挑战和方案

桌面端开发会遇到一些挑战，这些挑战大部分来源于特殊的业务场景，框架只能解决一些比较常见的应用场景，当然不仅仅是桌面端，其实移动端或者是 Web 端我相信大家都会遇到或多或少的挑战，我这里遇到的一些挑战和响应的方案不一定适合你，只是做单纯的记录分享，如果有帮助到你，我很开心。下面我挑选软件升级更新，任务队列设计，性能检测优化以及一些特殊的需求这几个方面来聊聊相应的挑战和方案。

软件升级更新

桌面端的软件更新升级是桌面端开发中非常重要的一环，一个好的商业产品必须有稳定好用的解决方案。桌面端的升级跟 C 端 App 的升级其实也是差不多的思路，虽然我所做的产品是公司内部人使用，但是用户也是你面向公司所有用户的，所以跟 C 端产品的解决思路其实是无异的。

升级更新主要是需要做到定向灰度。这个功能是非常重要的，应该大部分的应用都有定向灰度的功能，所以我们为了让软件能够平滑升级，第一步就是实现定向灰度，达到效果可回收，性能可监控，错误可告警的目的。定向更新的功能实现了之后，后面有再多的功能需要实现都有基础保障了，下面是更新相关的能力图。

整个更新模块的设计是分为两大块，一块是后台管理系统，一块是客户端。后台管理系统主要是维护相应的策略配置，比如哪些设备需要定向更新，哪些需要自动更新，不需要更新的白名单以及更新后是需要提醒用户相应的更新功能还是就静默更新。客户端主要就是拉取相应的策略，然后执行相应的更新动作。

由于我们的软件是比较特殊的一个产品，他是需要长期保活的，Mac 端上了文件锁是无法删除的。所以我们在执行更新的时候和常规的软件更新是不一样的，软件的更新下载是利用了 electron-update 相应的钩子，但是安装的时候并没有使用相应的钩子函数，而是自己研究了 electron 的更新源码后做了自己的更新脚本。 因为electron 的更新它自己也会注册一个保活的更新任务的服务，但是这个和我们的文件锁和保活是冲突的，所以是需要禁用掉它的保活服务，完成自己的更新。

整体来说，这一块是花了很多时间去研究的，windows 还好，没有破坏其整个生命周期，傻瓜式的配置一下electron-update 相关的函数钩子就可以了。Mac 的更新花了很多时间，因为破坏了文件的生命周期，再加上保活任务，所以会对 electron-update 的更新钩子进行毁灭性的破坏，最后也只能研究其源码然后自己去实现特殊场景下的更新了。

任务队列设计

任务模块的实现在我们这个软件里面也是非常重要的一环，因为客户端会跑非常多的定时任务。刚开始研发这个产品的时候其实还好，定时任务屈指可数，但是随着长时间的迭代，端上要执行的任务越来越多，每个任务的触发时间，触发条件都不一样，以及还要考虑任务的并发情况和对性能的影响，所以在中后期我们对整个任务模块都做了相应的改造。

下面是整个任务模块的核心能力图。

业界也有一些任务相关的开源工具包，比如 node-schedule、node-cron、cron，这些都是很优秀的库，但是我在使用过程中发现他们好像不具备并发限制的场景，比如有很多任务我们在开始设置的时候都会有个时间间隔，这些任务的时间间隔都是可以在后台随意配置的，如果端上不做并发限制会导致一个问题，就是用户某一瞬间会觉得电脑非常卡。

比如你有 4 个 10 分钟间隔的任务 和 2 个五分钟间隔的任务，那么到某一个时间段，他最大并发可能就是 6，如果刚好这 6 个任务都是非常耗费 CPU 的任务，那他们一起执行的时候就会导致整个终端CPU 飙升，导致用户感觉卡顿，这样就会收到相应的 Diss。

安全类的软件产品其实有的时候不需要太过醒目，后台默默运行就行，所以我们的宗旨就是稳定运行，不超载。为此我们就自己实现了相应的任务队列模式，然后去控制任务并发。其实底层逻辑也不难，就是一个 setInterval 的函数，然后不断的创建销毁，读取队列的函数，执行相应的函数。

性能优化

Electron相关的性能优化其实网上也有非常多的文章，我这里说说我的实践和感受。

首先，性能优化你需要优化什么？这个就是你的出发点了，我们要解决一个问题，首先得知道问题的现状，如果你都不知道现在的性能是什么样子，如何去优化呢？所以发现问题是性能优化的最重要的一步。

这里就推荐两个工具，一个是chrome dev-tool，一个是electron 的 inspector，第一个可以观测渲染进程相关的性能情况，第二个可以观测主进程相关的性能情况。

具体可参考以下网址：

• developer.chrome.com/docs/devtoo…


• http://www.electronjs.org/zh/docs/lat…

有了工具之后我们就需要用工具去分析一些数据和问题，这里面最重要的就是内存相关的分析，你通过内存相关的分析可以看到 CPU 占用高的动作，以及提前检测出内存泄漏的风险。只要把这两个关键的东西抓住了，应用的稳定性就可以得到保障了，我的经验就是每次发布之前都会跑一遍内存快照，内存没有异常才进行发布动作，内存泄漏是最后的底线。

我说说我大概的操作步骤。

• 通过Performance确认大体的溢出位置


• 使用Memory进行细粒度的问题分析


• 根据heap snapshot，判断内存溢出的代码位置


• 调试相应的代码块


• 循环往复上面的步骤

上面的步骤在主进程和渲染进程都适用，每一步实际操作在这里就不详细展开了，主要是提供一个思路和方法，因为 dev-tool 的面板东西非常多，扩展开来都可以当一个专题了。

然后我再说说桌面端什么地方可能会内存泄漏或者溢出，下面这些都是我血和泪的教训。

• 创建的子进程没有及时销毁：

如果子进程在完成任务后未被正确终止，这些进程会继续运行并占用系统资源，导致内存泄漏和资源浪费。

假设你的 Electron 应用启动了一个子进程来执行某些计算任务，但在计算完成后未调用
childProcess.kill() 或者未确保子进程已正常退出，那么这些子进程会一直存在，占用系统内存。

const { spawn } = require('child_process');

const child = spawn('someCommand');



child.on('exit', () => {

    console.log('Child process exited');

});



// 未正确终止子进程可能导致内存泄漏

• HTTP 请求时间过长没有正确处理：

长时间未响应的 HTTP 请求如果没有设定超时机制，会使得这些请求占用内存资源，导致内存泄漏。

在使用 fetch 或 axios 进行 HTTP 请求时，如果服务器长时间不响应且没有设置超时处理，内存会被这些未完成的请求占用。

const fetch = require('node-fetch');



fetch('https://example.com/long-request')

    .then(response => response.json())

    .catch(error => console.error('Error:', error));



// 应该设置请求超时

const controller = new AbortController();

const timeout = setTimeout(() => {

    controller.abort();

}, 5000); // 5秒超时



fetch('https://example.com/long-request', { signal: controller.signal })

    .then(response => response.json())

    .catch(error => console.error('Error:', error));

• 事件处理器没有移除

未正确移除不再需要的事件处理器会导致内存一直被占用，因为这些处理器仍然存在并监听事件。

在添加事件监听器后，未在适当时机移除它们会导致内存泄漏。

const handleEvent = () => {

    console.log('Event triggered');

};



window.addEventListener('resize', handleEvent);



// 在不再需要时移除事件监听器

window.removeEventListener('resize', handleEvent);

• 定时任务未被正确销毁

未在适当时候清除不再需要的定时任务（如 setInterval）会导致内存持续占用。

使用 setInterval 创建的定时任务，如果未在不需要时清除，会导致内存泄漏。

const intervalId = setInterval(() => {

    console.log('Interval task running');

}, 1000);



// 在适当时机清除定时任务

clearInterval(intervalId);

• JavaScript 对象未正确释放

长时间保留不再使用的 JavaScript 对象会导致内存占用无法释放，特别是当这些对象被全局变量或闭包引用时。

创建了大量对象但未在适当时机将它们置为 null 或解除引用。

let bigArray = new Array(1000000).fill('data');



// 当不再需要时，应释放内存

bigArray = null;

• 窗口实例未被正确销毁

未关闭或销毁不再使用的窗口实例会继续占用内存资源，即使用户已经关闭了窗口界面。

创建了一个新的 BrowserWindow 实例，但在窗口关闭后未销毁它。

const { BrowserWindow } = require('electron');

let win = new BrowserWindow({ width: 800, height: 600 });



win.on('closed', () => {

    win = null;

});



// 应确保在窗口关闭时正确释放资源

• 大文件或大数据量的处理

处理大文件或大量数据时，如果没有进行内存优化和分批处理，会导致内存溢出和性能问题。

在读取一个大文件时，未采用流式处理，而是一次性加载整个文件到内存中。

const fs = require('fs');



// 不推荐的方式：一次性读取大文件

fs.readFile('largeFile.txt', (err, data) => {

    if (err) throw err;

    console.log(data);

});



// 推荐的方式：流式读取大文件

const readStream = fs.createReadStream('largeFile.txt');

readStream.on('data', (chunk) => {

    console.log(chunk);

});

一些特殊的需求

做这个产品也遇到一些特殊的需求，有的需求还挺磨人的，这里也和大家分享一下。

• 保活和文件锁

作为一个前端，桌面端的保活和文件锁这种需求基本是之前不可能接触到的，为了做这个需求也去了解了一下业界的实现，其实实现都还好，主要是它会带来一些问题，诸如打包构建需要自定义前置脚本和后置脚本，root 用户环境下 mac 端无法输入中文，上面提到的用 Tauri 构建一个 webview 组件就是为了解决 root 用户无法输入中文的场景。

• 静默安装应用

这个需求也是很绝的一个需求。我想如果是做常规的前端开发，估计一般都不会遇到这种需求，你需要从头到尾实现一个下载器，一个软件安装器，而且还要双端适配，不仅如此，还需要实现 exe、zip、dmg、pkg 等各种软件格式的安装，里面包含重试机制，断点下载，队列下载等各种技术细节。当时接到这个需求头也特别大，不过技术方案做出来后感觉也还好，再复杂的需求只要能理清思路，其实都可以慢慢解决。

• VPN 和 访问记录监控

这种需求对一个前端来说更是无从入手，但是好在之前有老版本的 VPN 做参考，就是根据相应的代码翻译一遍也能实现，大部分可以用命令行解决。至于访问记录监控这个玩意咋说呢，客户端做其实也挺费神的，如果不借助第三方的开源框架，自己是非常难实现的，所以这种就是需要疯狂的翻国外的网站，就GitHub，Stackoverflow啰，总有一款适合你，这里就不具体说明了。

• 进程禁用

违规进程禁用其实在安全软件的应用场景是非常常见的，它需要实时性，而且对性能要求很高，一个是不能影响用户正常使用，还要精准杀掉后台配置的违规进程，这个地方其实也是做了很多版优化，但是最后的感觉还是觉得任务队列有性能瓶颈，无法达到要求，现阶段我们也在想用另外的方式去改造，要么就是上全局钩子，要么就是直接把相应的进程文件上锁或者改文件权限。

上面所提到的需求只是一小部例子，还好很多奇奇怪怪的需求没有举例，这些奇怪的需求就像小怪物，不断挑战我的边界，让我也了解和学习和很多奇奇怪怪的知识，有的时候我就会发出这样的感叹：我去，还能这样？

结语

洋洋洒洒，不知不觉已经写了 5000 字了，其实做 Electron 桌面端应用的这一两年自我感觉还是成长了不少，不管是技术方面还是产品设计方面，自己的能力都有所提升。但是同样会遇到瓶颈，就是一个东西一直做一直做，到后面创新会比较难，取得的成就也会慢慢变少。

另外就是安全类的桌面端产品在整个软件开发的里其实是非常冷门的一个领域，他有他的独特性，也有相应的价值，他需要默默的运行，稳定的运行，出问题可以监控到，该提醒的时候提醒用户。你说他低调吧，有时候也挺高调的，真的不好定论，你说没影响力吧，有的时候没他还真不行。让用户不反感这种软件，拥抱这种软件其实挺难的。从一个前端开发的视角来看，桌面端的体验的确很重要，不管是流畅度还是美观度，都不能太差，这也是我们现阶段追求的一个点，就是不断提升用户体验。

路漫漫其修远兮，吾将上下而求索。前端开发这条路的确很长，如果你想朝某个方面深度发展，你会发现边界是非常难触达的，当然也看所处的环境和对应的机遇，就从技术来说的话，前端的天花板也可以很高，不管是桌面端，服务端，移动端，Web端，每个方向前端的天花板都非常难触摸到。

最后，祝大家在自己的领域越来越深，早日触摸到天花板。

原文链接

mp.weixin.qq.com/s/SzN8wvqxj…

前言：

Seata是一款开源的分布式事务解决方案，提供高性能和简单易用的服务，确保微服务架构下的数据一致性， 本文章将依照本人的实际研究所得展开讲述，若有差错，敬请批评，还望海涵~

一、什么是分布式事务？

在分布式项目中，因为服务的拆分，每个服务单独管理自己的数据库。而一个业务操作往往涉及多个服务的数据落库，所以会出现某个服务出现业务异常而出现数据不一致的问题，为了避免数据库的数据不一致问题，分布式服务提供了全局事务，每个微服务作为分支事务，正是因为有全局事务的存在就可以保证了所有的分支事务能够同时成功或同时失败，能正确的进行数据的落库或回滚。

二、Seata解决分布式的四种方案

AT

第一阶段，在AT模式中TC(事务协调者)为包含在其中的多个RM（资源管理者）注册全局事务，然后调用分支事务注册到TC中，接着RM执行sql并提交到undo log(数据快照)中，数据此时处于一种中间状态（软状态），其中包含了事务执行前的旧数据，和事务执行之后的新数据，为保证数据一致性提供了保障。接着RM报告TC事务的执行状态。

第二阶段，TC判断事务是否全部执行成功，并对RM进行对应的提交事务或者回滚事务的通知。最后由TM（应用程序）提交或者回滚全局事务，TC再次进行检查分支事务的状态。

优点：AT模式以分二阶段提交事务，弥补了XA模型资源占用周期过长的缺陷，性能也得到了进一步的加强。

缺点：舍弃了XA的资源占用的同时，也不能保证事务的强一致性，会出现数据在转化过程中提前被用户访问的情况，导致用户得到的是旧数据。

Seata的AT模式的执行流程

XA ：

XA模式主要特点为两阶段事务提交，

第一阶段，TC(事务协调者）会通知每个分支事务RM（每个微服务）做好执行事务的准备工作，RM返回就绪信息。在此阶段事务执行但不提交，但是持有数据库锁，占用了数据库的连接。

第二阶段，TC（事务的协调者）会根据第一阶段的执行报告来进行下一步判断，若所有分支事务都能执行成功，那就提交事务，数据落库，否则回滚事务。

优点：1、保证了数据的强一致性，满足ACID原则

2、支持常用的数据库，实现简单，没有代码侵入

应用场景：银行业务、金融行业

缺点：1、若事务因为第一阶段分支事务的失败而长时间等待则会导致资源长时间不得释放，业务无法快速实现响应的问题。

2、依赖关系型数据库实现

TCC

TCC模式的核心思想是通过三个阶段来确保分布式事务的一致性：

在Try阶段中系统会检查业务是否可以执行，并操作对资源进行预留，但依旧没有真正操作和使用资源。

在Confirm阶段，预留资源在此阶段会真正的使用

在Cancel阶段，释放掉锁定的资源

优点：TCC模式对资源的锁定预留保证了强一致性

缺点：TCC模式需要额外的网络通信和预留的预留，导致性能开销大。

SAGA

Saga模式是一种分布式事务处理模式，它将一个大的事务分解为多个小的事务（子事务），每个子事务都是独立的本地事务，可以独立提交或回滚。如果在执行过程中某个子事务失败，Saga模式会触发补偿事务（Compensation Transaction）来撤销之前已经提交的子事务的影响，从而保持数据的一致性。

Visual Studio Code (VSCode)

是一个由微软开发的免费源代码编辑器，它在开发者社区中非常受欢迎。然而，对于那些寻求完全开源替代方案的人来说，VSCodium 成为了一个不错的选择。下面我将撰写一篇关于 VSCodium 的文章，并阐述它与 VSCode 的主要区别。

VSCodium：自由且开放的开发环境

VSCodium 是一个基于 Visual Studio Code（简称 VSCode）的开源版本控制集成开发环境（IDE）。它不仅提供了与 VSCode 相同的强大功能，还去除了专有软件组件，确保了软件的自由度和透明度。

VSCodium 的特点

• 完全开源：VSCodium 是完全基于 MIT 许可证发布的，这意味着它的源代码是完全公开的，用户可以自由地查看、修改和分发其副本。


• 无数据收集：与 VSCode 不同的是，VSCodium 默认不会发送遥测数据或任何其他信息到微软服务器，这对于注重隐私的开发者来说是一个重要的优势。


• 社区驱动：由于其开源性质，VSCodium 可以通过社区贡献来改进和发展，任何人都可以参与到项目的维护和发展中来。


• 跨平台支持：VSCodium 支持 Windows、macOS 和 Linux 操作系统，为不同平台上的开发者提供了一致的- - 使用体验。

VSCodium 与 VSCode 的主要区别

尽管 VSCodium 和 VSCode 在功能上非常相似，但它们之间存在一些关键差异：

许可证与所有权：

• VSCode 虽然也是免费的，但它使用的是专有的“源码可用”许可证，并且由微软拥有和维护。


• VSCodium 则是完全开源的，遵循 MIT 许可证。

数据收集：

• VSCode 默认会收集一些使用数据，虽然这些数据主要用于改善产品，但对于部分用户来说可能是一个隐私问题。


• VSCodium 去除了所有与数据收集相关的功能，保证用户的隐私不受侵犯。

扩展生态系统：

• VSCode 有一个庞大的官方市场，其中包含了大量的插件和扩展，这使得它成为很多开发者的首选。


• VSCodium 使用相同的扩展格式，但由于其相对较小的用户基数，某些插件可能首先发布在 VSCode 市场上。

更新和支持：

• VSCode 得到了微软的强大支持，通常会有更频繁的更新和新特性发布。


• VSCodium 的更新频率取决于社区贡献者的工作，虽然它通常会紧跟 VSCode 的步伐，但在某些情况下可能会稍微滞后。

下载和安装

github.com/VSCodium/vs…

使用

与vscode基本相同。

结论

选择 VSCodium 还是 VSCode 主要取决于个人的需求和价值观。如果你重视隐私并且希望使用完全开源的工具，那么 VSCodium 将是一个很好的选择。如果你更看重官方支持以及广泛的插件生态系统，那么 VSCode 仍然是一个强大的开发工具。无论选择哪一个，你都将获得一个功能强大、灵活且易于使用的 IDE。

JWT 在 web 开发中作用毋庸置疑。下面我们快速的了解 jwt 在 rust 中的使用。

JWT 基础知识

JWT 是一种用于安全传输信息的轻量级、无状态的标准，适用于身份验证和信息交换场景。通过签名验证和自包含的声明，它能够高效地传递用户信息，同时减少服务器负担。

JWT 组成

Header.Payload.Signature

• Header: 类型（typ）和算法（alg， 指定 hash 签名算法），Header 对象会被比 base64URL 编码。


• Payload：负载部分（事件传递的数据），可以分为三类：注册 Claims、公共 Claims以及私有 Claims,Payload 也会被 base64URL 编码。


• Signature： 签名部分，用于验证消息的完整性，并确保消息在传输过程中未被篡改。

他们直接通过点 . 链接

依赖

[dependencies]

chrono = "0.4.38"

dotenv = "0.15.0"

jsonwebtoken = { version = "9.3.0", features = [] }

serde = { version = "1.0.210", features = ["derive"] }

env 文件

使用 dotenv 将 jwt 需要 secet 放在 env 文件中

JWT_SECRET=your_secret_key

token 的创建和解析

生成解析 token 需要：

• Algorithm 算法


• Claims 有效负载数据。


• chrono 世间处理

实现

jwt 创建和解析十分重要，我们将 jwt 的单独封装到 utils/jwt.rs下

use jsonwebtoken::{encode, decode, Header, Validation, EncodingKey, DecodingKey, Algorithm, TokenData};

use serde::{Serialize, Deserialize};

use chrono::{Utc, Duration};

use std::error::Error;

use std::env;



// Define the claims structure

#[derive(Debug, Serialize, Deserialize)]

pub struct Claims {

    sub: String,          // Subject (user ID, email, etc.)

    exp: usize,           // Expiration time (as UTC timestamp)

}



pub fn create_jwt(sub: &str) -> Result<String, Box<dyn Error>> {

    let secret = env::var("JWT_SECRET").expect("JWT_SECRET must be set");

    // Define some claims

    let my_claims = Claims {

        sub: sub.to_owned(),

        exp: (Utc::now() + Duration::hours(24)).timestamp() as usize, // JWT expires in 24 hours

    };



    // Encoding the token

    let token = encode(

        &Header::default(),

        &my_claims,

        &EncodingKey::from_secret(secret.as_ref()),

    )?;



    Ok(token)

}



pub fn verify_jwt(token: &str) -> Result<TokenData<Claims>, Box<dyn Error>> {

    let secret = env::var("JWT_SECRET").expect("JWT_SECRET must be set");

    let token_data = decode::<Claims>(

        token,

        &DecodingKey::from_secret(secret.as_ref()),

        &Validation::new(Algorithm::HS256),

    )?;

    Ok(token_data)

}

• create_jwt 对外暴露，接受 sub 作为参数，传递给 Claims 结构体。然后使用 encode 进行加密即可。


• verify_jwt 一般是用在请求拦截器中，请求头中 headers 获取 token 进行解析。

小结

本文主要讲解 jwt 在 rust 中使用。本质就是 Claims 对象和 token 创建与解析。我们需要一些 web 组件像 jsonwebtoken、chrono、dotenv 和 serde 等。JWT 往往单独的放在一个单独的 utils 模块中方便能使用时调用。

背景

大家好，我是程序员 cq。

最近快国庆节了，很多平台为了促销都开始发放优惠券，连上海都发放了足足 5 亿元的消费券，当知道这个消息的时候，我差点都忘了自己没钱的事了。

言归正传，我们 网站 也准备做一个优惠券的功能，正好借此机会给大家分享下我们是怎么做的优惠券，下面是某一次需求评审会的对话：

产品小 y：最近国庆节快到了，咱们网站也要像其他网站学习，给用户发放优惠券，把我们的价格打下来！

开发小 c：我才不做，你直接把会员价格下调不就好了？要啥优惠券，不做不做。

产品小 y：诶，你这个小同志，我下调价格是简单，但是我下调之后怎么统计有多少人看了我们的商品没买呢（转化率）？

开发小 c：你统计这个干什么，让用户感觉到优惠不就行了？

产品小 y：我统计转化率肯定是有意义的呀，我给不同的推广渠道发放不同的优惠券，可以得到不同渠道的转化率，如果有的渠道转化率很差，那我下次就不在这个渠道里推广了，有的渠道转化率很好，那我后面就要在这个渠道里加大推广量。还有就是我直接改价要手动改，假期人工改价格很难保证准时开始活动。

开发小 c：好像有道理啊，而且直接改价格也会让用户感觉平台的价格不稳定，价格经常变动，导致用户总是处于观望的状态。

技术方案

需求分析

既然上面需求评审确定了我们要做优惠券功能，那我们就要先梳理下我们要做什么东西。

首先就是优惠券的优惠能力，我们第一期就做的简单些，只用完成直减券，也就是购买会员的时候可以直接抵扣金额的消费券。当然实际上优惠券不光有直减券，还有满减券、折扣券等等，我们的网站也不需要那么复杂，能做一个直减券就够应对会员降价的功能了。

其次就是优惠券的开始时间和结束时间，便于控制优惠的开始时间和结束时间。

最后还有对应的使用条件，比如我们的优惠券只允许新用户使用，便于拉新，之类的。

那我们就可以确定这个优惠券只需要有减免价格、优惠券名称、开始结束时间以及使用条件就好了。

这时候网站运营同学听到我的喃喃低语，头突然伸过来。

他高呼：你这样可不行啊，光有这些可不够，我还要有优惠券的浏览量、领取量、使用量算转化率的嘞！

我心神一动，喔喔喔，那这样的话就可以做一个漏斗：浏览量 > 领取量 > 使用量，「使用量 / 领取量」就可以得到这个优惠券的转化率，也就知道了这个营销渠道的效果。

想到这里，我果断开口，好好好，就宠你。

具体实现

ok，我们确定了我们要做的内容，也就是要给会员商品做一个优惠券，其中要可以控制减免的金额、优惠券的浏览量、领取量、使用量、还有优惠券的开始时间、结束时间以及使用条件。

业务流程

明确了要做的需求，那么我们就可以确定下我们的整个业务流程：

技术实现

其实上述流程中最复杂的地方还是用户领取优惠券和使用优惠券购买后的处理逻辑，下面我带大家看下我们都是怎么做的。

首先我们要对领取优惠券做幂等，确保用户只在第一次领取优惠券的时候可以领取成功，后续的领取都返回已领取。要实现这个效果，我们需要对用户领取优惠券加锁，也就是下面这样：

String lockKey = "coupon_receive_lock:" + userId + ":" + couponId;

synchronized (lockKey.intern()) {

    couponService.receiveCouponInner(loginUser, coupon);

}

但是由于我们公司是一个分布式的服务，所以本地锁其实是无效的，正好我们的服务用到了 redis，而且还引入了 redisson，那么就可以直接使用 redisson 的分布式锁，

String lockKey = RedisKeyConstant.COUPON_RECEIVE_LOCK + userId + ":" + couponId;

RLock lock = redissonClient.getLock(lockKey);

try {

    lock.lock();

    return couponService.receiveCouponInner(loginUser, coupon);

} finally {

    lock.unlock();

}

但是这样写就太 low 了，我不如直接封装一个方法，让后续再使用分布式锁更方便：

public  T blockExecute(String lockKey, Supplier supplier) {

    RLock lock = redissonClient.getLock(LOCK_KEY_PREFIX + lockKey);

    try {

        lock.lock();

        // 执行方法

        return supplier.get();

    } finally {

        lock.unlock();

    }

}

这样，我们在使用分布式锁的时候就更方便了：

String lockKey = RedisKeyConstant.COUPON_RECEIVE_LOCK + userId + ":" + couponId;

return redisLockUtil.blockExecute(lockKey,

                () -> couponService.receiveCouponInner(loginUser, coupon));

很好，在完成需求的时候又做了个基建工作，不愧是我。

其次就是在用户领取优惠券之后，我们的优惠券库存就应该对应的 -1，同时领取量对应 +1，那么这个 sql 就是这样的：

update coupon set leftNum = leftNum - 1, receiveNum = receiveNum + 1 where id = ?

这里可以确定数据不会出现混乱，因为在执行更新操作的时候，mysql 会有行锁，所以所有领取的用户都会在这里进行排队操作。

但是这样反而会出现问题，如果一瞬间领取优惠券的用户量激增，大家都在排队等库存量 - 1，就导致领取优惠券的时候用户会感觉很卡，也就是我们常说的热点行问题，不过像很多云厂商，都会针对热点行进行优化，比如某某云的 Inventory Hint 就可以实现快速提交 / 回滚事务，提高吞吐量，详细文章可以看下这篇文章：Inventory Hint，如果并发量真的很大的话，可以考虑用 redis 实现库存的 - 1，不过按照以往的经验来说不用 redis 也可以扛得住，这里就没必要再搞那么复杂了。

最后在领取优惠券之后，我们要接收来自支付中心的回调，根据用户的支付信息给用户赋予对应的会员权限，同时设置用户领取的优惠券为已使用，这样用户就不能再使用这个优惠券了，同时我们也可以关联查询到优惠券的使用量让运营同学进行分析。

了解领取优惠券的具体实现之后，后面的开发就简单了，这里就不再细说了，属于是商业机密了（其实就是代码写的太烂）。

优惠券到底带来了什么

优惠券的技术方案完成后，我们就应该深思一下，优惠券对我们来说到底有什么用，可以给我们带来什么好处？

对于用户而言自然是比之前便宜了许多，更省钱；用户觉得自己赚了，性价比高。

对于运营而言，可以对运营效果进行评估，比如销售变化、客户流失、获客成本等进而调整后续的营销活动；查看不同营销渠道表现，确定不同营销渠道优惠券效果；还可以利用历史数据预测未来的销售趋势，就像我们国庆节的优惠券就是参考了去年的优惠券使用情况来定的。

这也就是为什么运营同学会对优惠券这么痴迷了。

最后

通过这个优惠券功能的开发，其实大家也发现了，从最开始的直接改价到最后的优惠券，我们要做的不光是对商品的减免，还要做运营相关的功能。所以对于开发者而言，很多功能其实不仅要关注代码怎么写，更要考虑实现这个功能的意义，如果没意义，我就不用做了（bushi）。

了解功能实现的意义之后，我们身为开发就应该本能的想到，如何确定这个功能有多少人用，如何埋点，也就是为后续的运营计划以及后续的开发计划做准备。

前言

随着物联网（IoT）技术的飞速发展中，其应用规模和使用场景正在持续扩大，但它关键的流程仍然是围绕数据传输来进行的，因此设备通信协议选择至关重要。

作为两种主要的通信协议，MQTT 协议和 HTTP 协议各自拥有独特的优势和应用场景：MQTT 完全围绕物联网设计，拥有更灵活的使用方式，和诸多专为物联网场景设计的特性；而 HTTP 的诞生比它更早，并且被广泛应用在各类非物联网应用中，用户可能拥有更加丰富的开发和使用经验。

本文将深入探讨在物联网环境下，MQTT 和 HTTP 的不同特性、应用场景以及它们在实际应用中的表现。通过对这两种协议的比较分析，我们可以更好地理解如何根据具体需求选择合适的通信协议，以优化物联网系统的性能和可靠性。

MQTT 是什么

MQTT 是一种基于发布/订阅模式的轻量级消息传输协议，针对性地解决了物联网设备网络环境复杂而不可靠、内存和闪存容量小、处理器能力有限的问题，可以用极少的代码为联网设备提供实时可靠的消息服务。

在典型的 MQTT 使用方式中，所有需要通信的客户端（通常是硬件设备和应用服务）与同一个 MQTT 服务器（MQTT Broker）建立 TCP 长连接。发送消息的客户端（发布者）与接收消息的客户端（订阅者）不需要建立直接的连接，而是通过 MQTT 服务器实现消息的路由和分发工作。

实现这一操作的关键在于另一个概念 —— **主题（Topic），**主题是 MQTT 进行消息路由的基础，它类似 URL 路径，使用斜杠 / 进行分层，比如 sensor/1/temperature。订阅者订阅感兴趣的主题，当发布者向这个主题发布消息时，消息将按照主题进行转发。

一个主题可以有多个订阅者，服务器会将该主题下的消息转发给所有订阅者；一个主题也可以有多个发布者，服务将按照消息到达的顺序转发。同一个客户端，既能作为发布者，也能作为订阅者，双方根据主题进行通信，因此 MQTT 能够实现一对一、一对多、多对一的双向通信。

HTTP 是什么

HTTP 是一种基于请求/响应模式的应用层协议，尽管它主要针对传统的客户端-服务器架构而设计，但它在物联网应用中同样扮演着重要角色。

特别说明的是，本文对比的 HTTP 特指传统的请求/响应模式用例，基于 HTTP 协议扩展实现的 WebSocket 与 Server-Sent Events 协议不参与对比。

在典型的 HTTP 使用方式中，客户端（通常是浏览器或其他网络应用）向服务器发送请求以获取资源或提交数据，服务器接收到请求后，需要处理请求并返回响应，例如将提交的数据保存到数据库中，等待另一个客户端来请求获取。

HTTP 协议使用 URL 来标识资源路径，类似于 MQTT 中的主题（Topic）。例如，HTTP 请求中的 URL 可能是 http://example.com/api/sensor，这与 MQTT 中的 sensor/1/temperature 主题有相似的分层结构。

HTTP 每次通信都通过独立的请求和响应流程完成，因此它需要额外的开销，并且两个客户端之间无法直接通信，在实时性上稍有欠缺。

资源消耗对比

MQTT 和 HTTP 都是非常简单的协议，许多物联网硬件设备和嵌入式系统都同时提供了对两者的支持。实时上资源体积与运行内存通常不会限制两者的使用，但 MQTT 设计初衷和使用特性是针对物联网设计，因此长期使用中，它具有更小的资源消耗。

首先，MQTT 在连接方面具有较低的开销。MQTT 将协议本身占用的额外消耗最小化，消息头部最小只需要占用 2 个字节，连接建立时的握手过程相对简单，可稳定运行在带宽受限的网络环境下。

一旦建立连接，客户端和服务器之间可以保持长时间的持久连接，多个消息可以在同一连接上传输，从而减少了频繁建立和断开连接的开销。以向 topic/1 主题发布 HelloWorld 内容为例，其报文信息如下：

HTTP 在每个请求-响应周期中都需要建立和断开连接，会带来额外的服务器资源使用。相对来说，HTTP 协议较为复杂，消息头部较大。同时，由于它是无状态协议，因此每次连接时客户端都需要携带额外的身份信息，这会进一步增加带宽消耗。

以向 http://localhost:3000/topic URL 传输 HelloWorld 内容为例，在不携带身份凭证的情况下，其报文信息如下：

总结：

• MQTT 的连接开销较低，连接建立简单，报文头较小，适用于需要频繁通信或保持持久连接的场景。


• 相比之下，HTTP 需要在每次请求-响应周期中建立和关闭连接，报文头较大，在网络带宽有限的情况下可能会增加传输延迟和负担。

在报文尺寸和连接开销方面，MQTT 通常比 HTTP 更为高效，特别是在需要频繁通信、保持长连接或网络带宽有限的物联网场景下。

安全性对比

MQTT 和 HTTP 两者都是基于 TCP 的协议，并且在协议设计上都充分考虑了安全性。

SSL/TLS 加密

两者都能支持通过 SSL/TLS 进行加密通信：

• 可以保护数据在传输过程中的机密性和完整性；


• 可以防止数据被窃听、篡改或伪造。

多样化的认证授权机制

• MQTT 提供了用户名/密码认证，可以扩展支持 JWT 认证，也支持客户端和服务器之间的 X.509 证书认证；在授权方面，可以支持基于主题的发布订阅授权检查，取决于MQTT 服务器的实现，。


• HTTP 则提供了更灵活的选项，包括基本认证（Basic Auth）、令牌认证（Token Auth）、OAuth 认证；可以通过应用层的权限控制机制，通过访问令牌（Access Token）、会话管理等来控制资源的访问权限。

物联网特性对比

MQTT 协议是专为物联网而设计的通讯协议，内置了丰富的物联网场景特性，能够有效地帮助用户实现设备间稳定可靠的通讯、实时数据传输功能，满足灵活的业务场景需求。

断线重连与持久会话

MQTT 支持持久连接和断线重连，确保设备与服务器之间的稳定通信，即使在网络不稳定的情况下也能保持连接。客户端可以选择是否创建持久会话，在断线重连时恢复之前的会话状态，确保消息不会丢失。

QoS 控制

MQTT 提供三种 QoS 等级：

• QoS 0：最多一次传递，消息可能会丢失。


• QoS 1：至少一次传递，消息可能重复。


• QoS 2：只有一次传递，消息保证不丢失也不重复。

客户端可根据需求选择适当的 QoS 等级，确保消息传递的可靠性。

共享订阅

多个客户端可以订阅相同的主题，接收相同的消息，适用于多个设备间共享数据或订阅相同事件的场景。

保留消息

服务器可以保留指定主题最新的消息，当新的订阅者连接时立即发送，确保新订阅者获取最新数据。

遗嘱消息

客户端可以设置遗嘱消息，当客户端异常断开连接时，服务器会发布遗嘱消息，通知其他订阅者客户端已离线。

消息过期间隔

可以设置消息的过期时间，确保消息在一定时间内被消费，避免过期消息对系统造成不必要的负担。

尽管 HTTP 是 Web 应用中使用最广泛的协议之一，基于成熟的工具链和功能设计经验用户可以实现一些特性，但需要额外的开发工作。在物联网场景下，由于 MQTT 协议原生内置了许多适用于物联网的特性，使用 MQTT 可以降低开发成本，提高通信效率，更适合于物联网应用的需求。

对比总结

总而言之，MQTT 和 HTTP 在通信模型和物联网特性上有显著的区别：

• MQTT 基于发布订阅模型，HTTP 基于请求响应，因此 MQTT 支持双工通信。


• MQTT 可实时推送消息，但 HTTP 需要通过轮询获取数据更新。


• MQTT 是有状态的，但是 HTTP 是无状态的。


• MQTT 可从连接异常断开中恢复，HTTP 无法实现此目标。


• MQTT 支持更多开箱即用的物联网功能，HTTP 则没有针对性的设计。

这些差异将直接影响它们物联网中的使用场景选择：

• 实时通信： MQTT 在实时性要求较高的场景下更为适用。由于其基于发布/订阅模型，设备可以实时推送消息给服务器或其他设备，而不需要等待请求。例如，实时监测传感器数据、实时控制设备等场景下，MQTT 可以提供更快的响应速度。


• 轻量且频繁的通信： 对于带宽和资源有限的环境，MQTT 通常比 HTTP 更加高效。MQTT 不需要频繁建立连接，且消息头相对较小，通信开销较低；而 HTTP 同步的请求/响应模式则显得效率低下，每次通信都需要完整的请求和响应头，导致带宽和资源的浪费。


• 网络波动的场景： MQTT 支持客户端与服务器之间的持久连接，并且能够从连接异常中恢复，这意味着即使网络断开，设备重新连接后也能够恢复通信。而 HTTP 是无状态的，每次通信都是独立的，无法实现断线恢复。

另一个想法：MQTT 与 HTTP 集成使用

到目前为止，我们讨论的都是在物联网设备上更应该选择哪个协议的问题。实际上，在一个复杂的物联网应用中，不仅有硬件设备，还涉及到其他客户端角色和业务流程。MQTT 和 HTTP 作为物联网和互联网中最广泛使用的两种协议，在许多场景下可以互相补充使用，提高系统的效率和灵活性。

例如，在一个典型的车联网应用中，用户侧更适合使用 HTTP 协议：用户可以通过 App 中的"打开车门"按钮来控制停在车库中的汽车。这个过程中，App 与服务器之间并不是双向通信，使用 HTTP 也能实现更复杂和灵活的安全与权限检查。而服务器到车辆之间则依赖实时的双向通信：车辆需要确保任何时候都能够响应来自用户的操作。

车辆可以通过 MQTT 协议周期性的上报自身状态，服务器将其保存下来，当用户需要获取时，在 App 上通过 HTTP 协议完成请求即可。

在知名的 MQTT 服务器 EMQX 中，可以轻松、灵活地实现 MQTT 协议和 HTTP 协议的集成，从而实现这一过程。

EMQX 是一款大规模分布式 MQTT 物联网接入平台，为高可靠、高性能的物联网实时数据移动、处理和集成提供动力，助力企业快速构建物联网时代的关键应用。

HTTP → MQTT：

应用系统通过调用 EMQX 提供的 API，将 HTTP 请求转换为 MQTT 消息发送到指定设备，实现应用系统向设备发送控制指令或通知。

curl -X POST 'http://localhost:18083/api/v5/publish' \

  -H 'Content-Type: application/json' \

  -u '<appkey>:<secret>'

  -d '{

  "payload_encoding": "plain",

  "topic": "cmd/{CAR_TYPE}/{VIN}",

  "qos": 1,

  "payload": "{ \"oper\": \"unlock\" }",

  "retain": false

}'

MQTT → HTTP：

当设备发送 MQTT 消息到 EMQX 时，通过 EMQX 提供的 Webhook 可以将消息转发到 HTTP 服务器，实现设备数据的即时传输到应用系统。

配置界面如下：

在未来版本中，EMQX 还将提供提供扩展功能，能够将实时的 MQTT 消息保存到内置的消息队列（Message Queue）和流（Stream）中，并允许用户通过 HTTP 拉取的方式进行消费，更好地支持复杂的物联网应用场景，提供更强大的消息处理能力。

总结

总的来说，选择 MQTT 还是 HTTP 取决于具体的应用需求和场景特点。如果需要实时性好、双向通信、资源占用低的通信方式，可以选择 MQTT；只有简单的请求/响应通信，例如物联网客户端数据采集上报、主动拉取服务器数据，或者迫切希望使用现有的 Web 基础设施，那么可以选择 HTTP。

你好，我是猿java。

线程是 Java执行的最小单元，通常意义上来说，多个线程是为了加快速度且无需保序，这篇文章，我们来分析一道农业银行的面试题目：如要保证线程T1, T2, T3顺序执行？

考察意图

在面试中出现这道问题，通常是为了考察候选人的以下几个知识点：

1. 多线程基础知识： 希望了解候选人是否熟悉Java多线程的基本概念，包括线程的创建、启动和同步机制。

2. 同步机制的理解：候选人需要展示对Java中各种同步工具的理解，如join()、CountDownLatch、Semaphore、CyclicBarrier等，并知道如何在不同场景下应用这些工具。

3. 线程间通信：希望候选人理解线程间通信的基本原理，例如如何使用wait()和notify()来协调线程。

4. 对Java并发包的熟悉程度： 希望候选人了解Java并发包（java.util.concurrent）中的工具和类，展示其对现代Java并发编程的掌握。

保证线程顺序执行的方法

在分析完面试题的考察意图之后，我们再分析如何保证线程顺序执行，这里列举了几种常见的方式。

join()

join()方法是Thread类的一部分，可以让一个线程等待另一个线程完成执行。 当你在一个线程T上调用T.join()时，调用线程将进入等待状态，直到线程T完成（即终止）。因此，可以通过在每个线程启动后调用join()来实现顺序执行。

如下示例代码，展示了join()如何保证线程顺序执行：

Thread t1 = new Thread(() -> {

   // 线程T1的任务

});



Thread t2 = new Thread(() -> {

   // 线程T2的任务

});



Thread t3 = new Thread(() -> {

   // 线程T3的任务

});



t1.start();

t1.join(); // 等待t1完成



t2.start();

t2.join(); // 等待t2完成



t3.start();

t3.join(); // 等待t3完成

CountDownLatch

CountDownLatch通过一个计数器来实现，初始时，计数器的值由构造函数设置，每次调用countDown()方法，计数器的值减1。当计数器的值变为零时，所有等待在await()方法上的线程都将被唤醒，继续执行。

CountDownLatch是Java并发包（java.util.concurrent）中的一个同步辅助类，用于协调多个线程之间的执行顺序。它允许一个或多个线程等待另外一组线程完成操作。

如下示例代码，展示了CountDownLatch如何保证线程顺序执行：

CountDownLatch latch1 = new CountDownLatch(1);

CountDownLatch latch2 = new CountDownLatch(1);



Thread t1 = new Thread(() -> {

   // 线程T1的任务

   latch1.countDown(); // 完成后递减latch1

});



Thread t2 = new Thread(() -> {

   try {

       latch1.await(); // 等待T1完成

       // 线程T2的任务

       latch2.countDown(); // 完成后递减latch2

   } catch (InterruptedException e) {

       Thread.currentThread().interrupt();

   }

});



Thread t3 = new Thread(() -> {

   try {

       latch2.await(); // 等待T2完成

       // 线程T3的任务

   } catch (InterruptedException e) {

       Thread.currentThread().interrupt();

   }

});



t1.start();

t2.start();

t3.start();

CountDownLatch关键方法解析：

• CountDownLatch(int count) : 构造函数，创建一个CountDownLatch实例，计数器的初始值为count。


• void await() : 使当前线程等待，直到计数器的值变为零。


• boolean await(long timeout, TimeUnit unit) : 使当前线程等待，直到计数器的值变为零或等待时间超过指定的时间。


• void countDown() : 递减计数器的值。当计数器的值变为零时，所有等待的线程被唤醒。

Semaphore

Semaphore通过一个计数器来管理许可，计数器的初始值由构造函数指定，表示可用许可的数量。线程可以通过调用acquire()方法请求许可，如果许可可用则授予访问权限，否则线程将阻塞。使用完资源后，线程调用release()方法释放许可，从而允许其他阻塞的线程获取许可。

如下示例代码，展示了Semaphore如何保证线程顺序执行：

Semaphore semaphore1 = new Semaphore(0);

Semaphore semaphore2 = new Semaphore(0);



Thread t1 = new Thread(() -> {

   // 线程T1的任务

   semaphore1.release(); // 释放一个许可

});



Thread t2 = new Thread(() -> {

   try {

       semaphore1.acquire(); // 获取许可，等待T1完成

       // 线程T2的任务

       semaphore2.release(); // 释放一个许可

   } catch (InterruptedException e) {

       Thread.currentThread().interrupt();

   }

});



Thread t3 = new Thread(() -> {

   try {

       semaphore2.acquire(); // 获取许可，等待T2完成

       // 线程T3的任务

   } catch (InterruptedException e) {

       Thread.currentThread().interrupt();

   }

});



t1.start();

t2.start();

t3.start();

Semaphore关键方法分析：

• Semaphore(int permits) ：构造一个具有给定许可数的Semaphore。


• Semaphore(int permits, boolean fair) ：构造一个具有给定许可数的Semaphore，并指定是否是公平的。公平性指的是线程获取许可的顺序是否是先到先得。


• void acquire() ：获取一个许可，如果没有可用许可，则阻塞直到有许可可用。


• void acquire(int permits) ：获取指定数量的许可。


• void release() ：释放一个许可。


• void release(int permits) ：释放指定数量的许可。


• int availablePermits() ：返回当前可用的许可数量。


• boolean tryAcquire() ：尝试获取一个许可，立即返回true或false。


• boolean tryAcquire(long timeout, TimeUnit unit) ：在给定的时间内尝试获取一个许可。

单线程池

单线程池（Executors.newSingleThreadExecutor()）可以确保任务按提交顺序依次执行。所有任务都会在同一个线程中运行，保证了顺序性。

如下示例代码展示了单线程池如何保证线程顺序执行：

ExecutorService executor = Executors.newSingleThreadExecutor();

executor.submit(new T1());

executor.submit(new T2());

executor.submit(new T3());

executor.shutdown();

单线程这种方法简单易用，适合需要顺序执行的场景。

synchronized

synchronized 是Java中的一个关键字，用于实现线程同步，确保多个线程对共享资源的访问是互斥的。它通过锁机制来保证同一时刻只有一个线程可以执行被Synchronized保护的代码块，从而避免数据不一致和线程安全问题。

如下示例代码，展示了synchronized如何保证线程顺序执行：

class Task {

    synchronized void executeTask(String taskName) {

        System.out.println(taskName + " 执行");

    }

}



public class Main {

    public static void main(String[] args) {

        Task task = new Task();

        new Thread(() -> task.executeTask("T1")).start();

        new Thread(() -> task.executeTask("T2")).start();

        new Thread(() -> task.executeTask("T3")).start();

    }

}

总结

本文，我们分析了5种保证线程T1，T2，T3顺序执行的方法，依次如下：

在实际开发中，这种需要在业务代码中去保证线程执行顺序的情况几乎不会出现，因此，这个面试题其实缺乏实际的应用场景，纯粹是为了面试存在。尽管是面试题，还是可以帮助我们更好地去了解和掌握线程。