今天收到一个需求,要求在flutter端把任意类型的图片,转换成bmp类型的图片,然后把 bmp位图发送到条码打印机,生成的 bmp图片是 1 位深度的,只有黑白两种像素颜色

包已经上传到 pub.dev,pub.dev/packages/ld…

效果图

1.生成插件包

crates.io地址: crates.io/crates/frb_…
安装命令

cargo install frb_plugin_tool

使用很简单,输入frb_plugin_tool即可

按照提示输入插件名
创建后的项目目录大概像这样

2. 编写 rust代码

我这里图片转 bmp工具用的是rust image这个包

添加依赖

cd rust && cargo add image

然后在 src/api目录下添加image.rs文件

use std::{io::Cursor, time::Instant};



use bytesize::ByteSize;

use humantime::format_duration;

use image::{GrayImage, Luma};

use indicatif::ProgressBar;

use log::debug;



use super::entitys::{LddImageType, ResizeOpt};



///任意图像转 1 位深度的数据

pub fn convert_to_1bit_bmp(

    input_data: &[u8],

    image_type: LddImageType,

    resize: Option<ResizeOpt>,

    is_apply_ordered_dithering: Option<bool>,

) -> Vec<u8> {

    let use_ordered_dithering = is_apply_ordered_dithering.map_or(false, |v| v);

    let start = Instant::now();

    debug!("开始转换,数据大小:{:?}", ByteSize(input_data.len() as u64));

    let mut img =

        image::load(Cursor::new(input_data), image_type.int0()).expect("Failed to load image");



    if let Some(size) = resize {

        debug!("开始格式化尺寸:{:?}", size);

        img = img.resize(size.width, size.height, size.filter.int0());

        debug!("✅格式化尺寸完成");

    }



    let mut gray_img = img.to_luma8(); // 转换为灰度图像

    if use_ordered_dithering {

        debug!("✅使用 h4x4a 抖动算法");

        gray_img = apply_ordered_dithering(&gray_img);

    }



    let (width, height) = gray_img.dimensions();

    let row_size = ((width + 31) / 32) * 4; // 每行字节数 4 字节对齐

    let mut bmp_data = vec![0u8; row_size as usize * height as usize];



    // 创建进度条

    let progress_bar = ProgressBar::new(height as u64);



    // 二值化处理并填充 BMP 数据（1 位深度）

    let threshold = 128;

    for y in 0..height {

        let inverted_y = height - 1 - y; // 倒置行顺序

        for x in 0..width {

            let pixel = gray_img.get_pixel(x, y)[0];

            if pixel >= threshold {

                bmp_data[inverted_y as usize * (row_size as usize) + (x / 8) as usize] |=

                    1 << (7 - (x % 8));

            }

        }

        progress_bar.inc(1); // 每处理一行，进度条增加一格

    }



    progress_bar.finish_with_message("Conversion complete!");



    // BMP 文件头和 DIB 信息头

    let file_size = 14 + 40 + 8 + bmp_data.len(); // 文件头 + DIB 头 + 调色板 + 位图数据

    let bmp_header = vec![

        0x42,

        0x4D, // "BM"

        (file_size & 0xFF) as u8,

        ((file_size >> 8) & 0xFF) as u8,

        ((file_size >> 16) & 0xFF) as u8,

        ((file_size >> 24) & 0xFF) as u8,

        0x00,

        0x00, // 保留字段

        0x00,

        0x00, // 保留字段

        54 + 8,

        0x00,

        0x00,

        0x00, // 数据偏移（54 字节 + 调色板大小）

    ];



    let dib_header = vec![

        40,

        0x00,

        0x00,

        0x00, // DIB 头大小（40 字节）

        (width & 0xFF) as u8,

        ((width >> 8) & 0xFF) as u8,

        ((width >> 16) & 0xFF) as u8,

        ((width >> 24) & 0xFF) as u8,

        (height & 0xFF) as u8,

        ((height >> 8) & 0xFF) as u8,

        ((height >> 16) & 0xFF) as u8,

        ((height >> 24) & 0xFF) as u8,

        1,

        0x00, // 颜色平面数

        1,

        0x00, // 位深度（1 位）

        0x00,

        0x00,

        0x00,

        0x00, // 无压缩

        0x00,

        0x00,

        0x00,

        0x00, // 图像大小（可为 0，表示无压缩）

        0x13,

        0x0B,

        0x00,

        0x00, // 水平分辨率（2835 像素/米）

        0x13,

        0x0B,

        0x00,

        0x00, // 垂直分辨率（2835 像素/米）

        0x02,

        0x00,

        0x00,

        0x00, // 调色板颜色数（2）

        0x00,

        0x00,

        0x00,

        0x00, // 重要颜色数（0 表示所有颜色都重要）

    ];



    // 调色板（黑白）

    let palette = vec![

        0x00, 0x00, 0x00, 0x00, // 黑色

        0xFF, 0xFF, 0xFF, 0x00, // 白色

    ];



    // 将所有部分组合成 BMP 文件数据

    let mut bmp_file_data = Vec::with_capacity(file_size);

    bmp_file_data.extend(bmp_header);

    bmp_file_data.extend(dib_header);

    bmp_file_data.extend(palette);

    bmp_file_data.extend(bmp_data);



    let duration = start.elapsed(); // 计算耗时

    debug!(

        "✅转换完成,数据大小:{:?},耗时:{}",

        ByteSize(bmp_file_data.len() as u64),

        format_duration(duration)

    );

    bmp_file_data

}



// 有序抖动矩阵（4x4 Bayer 矩阵）

const DITHER_MATRIX: [[f32; 4]; 4] = [

    [0.0, 8.0, 2.0, 10.0],

    [12.0, 4.0, 14.0, 6.0],

    [3.0, 11.0, 1.0, 9.0],

    [15.0, 7.0, 13.0, 5.0],

];



//h4x4a 抖动算法

fn apply_ordered_dithering(image: &GrayImage) -> GrayImage {

    let (width, height) = image.dimensions();

    let mut dithered_image = GrayImage::new(width, height);



    for y in 0..height {

        for x in 0..width {

            let pixel = image.get_pixel(x, y)[0];

            let threshold = DITHER_MATRIX[(y % 4) as usize][(x % 4) as usize] / 16.0 * 255.0;

            let new_pixel_value = if pixel as f32 > threshold { 255 } else { 0 };

            dithered_image.put_pixel(x, y, Luma([new_pixel_value]));

        }

    }



    dithered_image

}

生成 dart代码,在项目根目录下执行

flutter_rust_bridge_codegen generate

会在dart lib下生成对应的文件

在项目中使用

编写 example , main.dart.

import 'dart:io';

import 'dart:typed_data';



import 'package:file_picker/file_picker.dart';

import 'package:flutter/material.dart';

import 'package:ldd_bmp/api/entitys.dart';

import 'package:ldd_bmp/api/image.dart';

import 'package:ldd_bmp/ldd_bmp.dart';

import 'dart:async';



import 'package:path_provider/path_provider.dart';



const reSize = ResizeOpt(

  width: 200,

  height: 200,

  filter: LddFilterType.nearest,

);



Future<void> main() async {

  await bmpSdkInit();

  runApp(const MyApp());

}



class MyApp extends StatefulWidget {

  const MyApp({super.key});



  @override

  State<MyApp> createState() => _MyAppState();

}



class _MyAppState extends State<MyApp> {

  File? file;

  Uint8List? bmpData;

  @override

  void initState() {

    super.initState();

  }



  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      home: Scaffold(

        appBar: AppBar(

          title: const Text('Native Packages'),

        ),

        body: SingleChildScrollView(

          child: Column(

            children: [

              FilledButton(onPressed: selectFile, child: const Text('选择文件')),

              if (file != null)

                Image.file(

                  file!,

                  width: 200,

                  height: 200,

                ),

              ElevatedButton(

                  onPressed: file == null

                      ? null

                      : () async {

                          final bts = await file!.readAsBytes();

                          bmpData = await convertTo1BitBmp(

                              inputData: bts,

                              imageType: LddImageType.jpeg,

                              isApplyOrderedDithering: true,

                              resize: const ResizeOpt(

                                width: 200,

                                height: 200,

                                filter: LddFilterType.nearest,

                              ));

                          setState(() {});

                        },

                  child: const Text("转换")),

              ElevatedButton(

                  onPressed: bmpData == null

                      ? null

                      : () {

                          saveImageToFile(bmpData!);

                        },

                  child: const Text("保存图片"))

            ],

          ),

        ),

        floatingActionButton: bmpData != null

            ? ConstrainedBox(

                constraints:

                    const BoxConstraints(maxHeight: 300, maxWidth: 300),

                child: Card(

                  elevation: 10,

                  child: Padding(

                    padding: const EdgeInsets.all(8.0),

                    child: Column(

                      children: [

                        const Text('转换结果'),

                        Image.memory(bmpData!),

                      ],

                    ),

                  ),

                ),

              )

            : null,

      ),

    );

  }



  Future<void> selectFile() async {

    setState(() {

      file = null;

    });

    FilePickerResult? result = await FilePicker.platform.pickFiles();

    if (result != null) {

      file = File(result.files.single.path!);

      setState(() {});

    } else {

      // User canceled the picker

    }

  }

}



Future<void> saveImageToFile(Uint8List imageData) async {

  // 获取应用程序的文档目录

  final directory = await getApplicationDocumentsDirectory();



  // 设置文件路径和文件名

  final filePath = '${directory.path}/image.bmp';



  // 创建一个文件对象

  final file = File(filePath);



  // 将Uint8List数据写入文件

  await file.writeAsBytes(imageData);



  print('Image saved to $filePath');

}

转换速度还是挺快的,运行效果

上传到 pub.dev

这个包已经上传到仓库了,可以直接使用
pub.dev/packages/ld…

介绍

本篇文章主要以innodb存储引擎为主；在了解mysql的过程中经常能听到它内部有各种log以及缓冲区，他们在mysql中具有重要作用，例如binlog可以进行主从恢复，undo log可以进行数据回滚等。这篇文章主要讲解在mysql运气期间每个区域都是用来做什么的。

写入数据流程

对于mysql来讲，读写任何数据都是在内存中进行操作的；下图为mysql写入数据的详细流程：

undo log

undo log记录事务开始前的数据状态，它主要用于数据回滚和实现MVCC：

• 回滚操作：undo log记录了事务开始前的数据状态，当事务需要回滚时，以便可以恢复到原始状态。


• 多版本并发控制（MVCC） ：在读取历史数据时，undo log允许读取到事务开始前的数据版本，从而实现非锁定读取。

MVCC的具体实现可以查看:MVCC实现

buffer pool

innodb中无论是查询还是写绝大部分都是在buffer pool中进行操作的，它相当于innodb的缓存区，可以通过show engine innodb status来查看buffer pool的使用情况；可以通过innodb_buffer_pool_size来设置buffer pool的大小，线上不要吝啬给几个G内存都是正常的，但无论给多大内存都会有不够的时候，innodb采用了变种的LRU算法对数据页进行淘汰；如下图：

传统的LRU算法当碰到扫描一张大表时可能会直接把buffer pool中的所有页都更换为该表的数据，但这张表可能就使用一次，并不是热点数据；

innodb为了避免这种场景发生，会把整个buffer pool按照 5:3分成了young区域和old区域；其中绿色区域就是young区域也就是热点数据区域，紫色区域就是old区域也就是冷数据区域；整体的淘汰流程为：

在上图中可以看到除了LRU链表还有一个Flush链表，它是用来管理脏页的；在写入数据时绝大部分都会先写入buffer pool中，再更改buffer pool中的页数据时，该页就变成了脏页，此时就会被加入到flush链表中，定时会把flush中的脏页刷到.idb数据文件中。

change buffer

在介绍buffer pool时用的是绝大部分操作，是因为在innodb中还存在change buffer，还有一部分操作是写入change buffer的。change buffer的定义是当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，innodb会将这些更新操作缓存在change buffer中，这样就不需要从磁盘中加载这个数据页了，如果有查询需要访问这个数据页的时候，再将数据页读到内存中，然后执行change buffer中与这个页有关的操作，这样就能保证这个数据的正确性。change buffer用的是buffer pool中的内存，可以通过innodb_change_buffer_max_size来设置它占用buffer pool的内存比例。使用change buffer的前提条件是该数据页还没被加载到buffer pool中，并且如果是根据唯一索引进行更新，由于要检查数据的唯一性，必须把数据页加载到buffer pool中是无法享受change buffer带来的收益的。

redo log 与 redo log buffer

redo log是为了防止由于mysql异常退出导致buffer pool中还未持久化的数据丢失而诞生的；
它也是一个环形文件写数据写满时会覆盖历史的数据，它记录了数据页的物理变化，并且是顺序写入的提升了写入的性能；当mysql重启时可以使用redo log来恢复数据。

每次写redo log时并不是直接写入redo log文件，而是写入redo log buffer中，通过三种刷盘策略把数据同步到redo log中，可以通过innodb_flush_log_at_trx_commit参数来控制刷盘的时机

• 0：事务提交时，日志缓冲（log buffer）被写入到日志文件，但并不立即刷新到磁盘。日志文件的刷新操作由后台线程每隔一秒执行一次；


• 1：事务提交时，日志缓冲被写入到日志文件，并立即刷新到磁盘；


• 2：事务提交时，日志缓冲被写入到日志文件，但不立即刷新到磁盘。而是每秒由后台线程将日志文件刷新到磁盘。

如果对数据的正确性要求很高应该设置为1。

注：第一张图流程中，在第5步有二次commit，在数据恢复如果发现一个事务没有commit，则去binlog日志中查询，如果发现binlog中有相应数据则直接恢复，如果没有则丢弃。

binlog

binlog为了高效地记录和传输数据更改信息，它采用了二进制格式存储数据库的更改操作，这样还可以占用更小的存储空间；它可以实现数据恢复、数据同步等功能。默认mysql是关闭binlog日志的，可以通过
在[mysqlId]部分中设置log-bin和server-id来开启binlog日志。它也是在事务提交时才进行数据记录，它有以下三种数据格式：

• Statement：记录每一条执行的sql，但由于mysql中存在一些函数，例如一些随机生成函数，此时数据同步时会发生同步过去的数据不一致；


• Row：记录每行被修改成什么，这样可以解决statement带来的数据不一致问题，但由于记录的太详细如果出现了全表更新，那记录的数据量就会特别大；


• Mixed：Statement和Row的混合体，mysql会根据执行的每一条具体的SQL语句来区别对待记录的日志格式。

总结

为了实现更高的性能，在innodb中的任何操作都是优先在内存中操作的；为了支持数据的数据回滚、MVVC引入了undo log，进而可以实现查询历史版本或数据回滚；同时为了防止异常退出导致的数据丢失引入了redo log；为了支持数据同步等功能mysql引入了binlog日志。这就是各个区域的作用，由于篇幅原因本篇文章只对每个区域做了简单介绍，后续会写各个区域详细内容的文章。

创作不易，觉得文章写得不错帮忙点个赞吧！如转载请标明出处～

介绍解决该问题的基本概念和常见解决方案。

• Lockstep state update 锁步状态更新


• Client prediction 客户端预测


• server reconcilation 服务端和解

多人游戏的运作方式

游戏程序的玩家当前状态随时间和玩家的输入会进行变化。也就是说游戏是有状态的程序。多人游戏也不例外，但由于多人玩家之间存在交互，复杂性会更高。

例如贪吃蛇游戏，我们假设它的操作会发送到服务器，那它的核心游戏逻辑应该是：

服务端接收该消息做出对应的动作，这个过程会以固定的间隔运行。每一次循环都被称为 frame 或 tick。

客户端将解析服务端发送的消息，也就是每一帧的动作，渲染到游戏华中中。

锁步状态更新

为了确保所有客户端都同步帧，最简单的方法是让客户端以固定的间隔向服务器发送更新。发送的消息包含用户的输入，当然也可以发送 no user input。

服务器收集“所有用户”的输入后，就可以生成下一次 frame 帧。

上图演示了客户端与服务端的交互过程。T0 ~ T1 时间段，客户端保持等待，或者说空闲状态，直到服务器响应 frame，等待时间的大小取决于网络质量，约 50 毫秒到 500 毫秒，人眼能够注意到任何超过 100 毫秒的延迟，因此这个等待时间对于某些游戏来说是不可接受的。

锁步状态更新，还有一个问题。游戏的延迟来自最慢的用户 。

上图有两个客户端。客户端 B 的网络比较差，A 和 B 都在 T0 时间点向服务器发送了用户输入，A 的请求在 T1 到达服务端，B 的请求在 T2 到达服务端，前面我们提到，服务器需要收集“所有用户”的请求后才开始工作，因此需要到 T2 时间点才开始生成 frame。

因为 Client B 比较慢，我们“惩罚”了所有的玩家。

假如我们不等待所有客户端的用户输入，低延迟玩家又会获得优势，因为它的输入到达服务器的时间更短，会更快处理。例如，两个玩家 A、B 同时互相射击预期是同时死亡，但是 A 玩家延迟比 B 玩家更低，因此在处理 B 玩家的用户输入时，A 玩家已经干掉 B 玩家了。

小结一下，锁步状态更新存在的问题，如下。

• 游戏画面是否卡顿，取决于最慢的玩家


• 客户端需要等待来自服务器的响应，否则不会渲染画面


• 连接非常活跃，客户端需要定期发送一些无用的心跳包，以便服务器可以确定它拥有生成 frame 所需的所有信息

回合制类型的游戏大多数使用这种方法，因为玩家确实需要等待，例如《炉石传说》。

对于慢节奏的游戏，少量延迟也是可以接受的，例如《QQ农场》。

但是对于快节奏的游戏，锁步状态更新的这些问题都是致命的，不可能操纵游戏人物进入某一个建筑，500 毫秒后，我才能进入。我们一起来看看下一种方法。

客户端预测

客户端预测，在玩家的计算机上，运行游戏逻辑，来模拟游戏的行为，而不是等待服务器更新。

例如我们生成 Tn 时间点的游戏状态，我们需要 Tn-1 时间点的所有玩家状态和 Tn-1 时间点所有玩家的输入。

假设，我们现在的固定频率为 1 s，每 1s 需要给服务器发送一个请求，获取玩家状态并更新玩家的状态。

在 T0 时间点，客户端将用户的输入发送到服务器，用于获取 T1 时间点的游戏状态。在 T1 时间点，客户端已经可以渲染画面了，实际上客户端的响应是在 T3 时刻，也就是说客户端没有等待来自服务器的响应。

使用这个方法，需要满足一些前置条件：

• 客户端拥有游戏运行逻辑所需的所有条件


• 玩家状态的更新逻辑是确定性的，即没有随机性，或者可以以某种方式保证确定性，例如客户端和服务器使用同样的公式以及随机种子，可以保证具有随机性的同时，产生的结果具有确定性。这样保证了客户端和服务器在给定相同输入的情况下产生相同的游戏状态

满足这两点，客户端预测的结果也不一定总是对的。就比如刚提到的，使用相同的公式以及相同的随机种子，进行伪随机算法，但不同平台的浮点计算，可能会存在微小的差异。

再设想一个场景，如下图。

客户端 A 尝试使用 T0 时间点的信息模拟 T1 时间点上的游戏状态，但客户端 B 也在 T0 时间点提交了用户输入，客户端 A 并不知道这个用户输入。

这意味着客户端 A 对 T1 时间的预测将是错误的是，但！由于客户端 A 仍然从服务器接收 T1 时间点的状态，因此客户端有机会在 T3 时间点修正错误。

客户端需要知道，自己的预测是否正确，以及如何修正错误。

修正错误通常叫做 Reconcilation 和解。

需要根据上下文来实现和解部分，下面我们通过一个简单的例子来理解这个概念。这个例子只是抛弃我们的预测，并将其游戏状态替换为服务器响应的正确状态。

• 客户端需要维护 2 个缓冲区，一个用于预测 PredictionBuffer，一个用于用户输入 InputBuffer 。它们是预测这个行为需要的上下文，请记住，预测 Tn 时刻，需要 Tn-1 的状态和 Tn-1 时刻的用户输入。它们一开始都为空
  
  

  



• 玩家点击鼠标，移动游戏角色到下一个位置。此时，玩家输入的移动信息 Input 0 存储在 InputBuffer 中，客户端将生成预测 Prediction 1，存储在 PredictionBuffer 中，预测将展示在玩家画面中
  
  

  



• 客户端收到服务器响应的 State0 ，发现与客户端的预测不匹配，我们将Prediction 1 替换为 State 0，并使用 Input 0 和 State 0 重新计算，得到 Prediction 2，这个重新计算的过程，就是 Reconcilation 和解
  
  

  



• 和解后，我们从缓冲区中删除 State 0 和 Input 0
  
  

  

这种和解的方式有一个明显的缺点，如果服务器响应的游戏状态和客户端预测差异太大，则游戏画面可能会出现错误。例如我们预测敌人在 T0 时间点向南移动，但在 T3 时间点，我们意识到它在向北移动，然后通过使用服务器的响应进行和解，敌人将从北“飞到”正确的位置。

有一些方法可以解决此问题，这里不展开讨论，感兴趣可以搜一下实体插值 Entity Interpolation。

小结一下，客户端预测技术，让客户端以自己的更新频率运行，与服务器的更新频率无关，所以服务器如果出现阻塞，不会影响客户端的帧。

但它也带来复杂性，如下。

• 需要在客户端处理更多的状态和逻辑，比如我们前面提到的缓冲区和预测逻辑


• 需要和解来自服务器的状态（正确的游戏状态）与预测之前的冲突

还给我们带来了敌人从南飞到北的问题。

目前为止，我们都在讨论客户端，接下来看看服务端如何解决帧同步。

服务端和解

利用服务端解决帧同步问题，首先需要解决的是网络延迟带来的问题。如下图。

用户 A 在 T 处进行了操作（比如按下了一个技能键），该操作应该在 T+20ms 处理，但由于延迟，服务器在 T+120ms 才接收到输入。

在游戏中，用户做出指定操作后，应该立即有反应。立即有反应，这个立即是多久，取决于游戏的类型，比如之前我们提到的回合制，它的立即可能是几十秒。我们可以通过 T + X，表示立即反应的时间，T 代表用户的输入时刻，X 代表的是延迟。X 可以为 0，这代表真正的立即 :-)

解决这个问题的思路，与之前客户端预测中使用的办法类似，就是通过客户端的用户输入，来和解服务器中的玩家游戏状态。

所有的用户输入，都需要时间戳进行标记，该时间戳用于告诉服务器，什么时刻处理此用户输入。

为什么在同一水平线上，Client A 的时间是 Time X，而 Server 的时间是 Time Y？

因为客户端和服务端独立运行，通常时间会有所不同，在多人游戏中，我们可以特殊处理其中的差异。在特殊处理时，我们应该使客户端的时间大于服务端的时间，因为这样可以存在更大的灵活性

上图演示了一个客户端与服务端之间的交互。

服务端和解部分（上图红色底色部分），主要维护 3 个部分，如下。

• GameStateHistory，在一定时间范围内玩家在游戏中的状态


• ProcessedUserInput，在一定时间范围内处理的用户输入的历史记录


• UnprocessedUserInput，已收到但未处理的用户输入，也是在一定的时间内

服务端和解过程，如下。

我并没有做过这些工作，分享的知识都是我对它感兴趣，在网上看了许多经验后整理的。

如何让你喜欢的原神角色陪你写代码

每天上班，脑子里面就想着一件事，原神，啊不对，VsCode！启动！(doge 狗头保命)，那么如何将这两件事情结合起来呢？特别是原神里面有那么多我喜欢的角色。

最终效果预览

• 右下角固定一只小可爱
  
  
  
  
  • 
  
  
  
  


• 全屏一只小可爱
  
  
  
  
  • 
  
  
  
  

省流直接抄作业版

{

  "background.customImages": [

    "https://upload-bbs.miyoushe.com/upload/2023/02/24/196231062/8540249f2c0dd72f34c8236925ef45bc_3880538836005347690.png",

    "https://user-images.githubusercontent.com/41776735/163673800-0e575aa3-afab-405b-a833-212474a51adc.png"

  ],

  "background.enabled": true,

  "background.style": {

    "content": "''",

    "width": "30%",

    "height": "30%",

    "opacity": 0.3,

    "position": "absolute",

    "bottom": "0",

    "right": "7%",

    "z-index": "99999",

    "background-repeat": "no-repeat",

    "background-size": "contain",

    "pointer-events": "none"

  },

  "background.useDefault": false,

  "background.useFront": true

}

2.2 全屏图片配置

{

  "background.customImages": ["https://upload-bbs.miyoushe.com/upload/2024/01/15/196231062/1145c3a2f56b2f789a9be086b546305d_3972870625465222006.png"],

  "background.enabled": true,

  "background.style": {

    "content": "''",

    "pointer-events": "none",

    "position": "absolute",

    "z-index": "99999",

    "height": "100%",

    "width": "100%",

    "background-repeat": "no-repeat",

    "background-size": "cover",

    "background-position": "content",

    "opacity": 0.3

  },

  "background.useDefault": false,

  "background.useFront": true

}

详细说明版

第一步，你还是需要下载 background 这个插件。

• background 插件的官方中文文档

第二步，配置解析

我们看官方文档里面，有两个配置是需要说明一下的

• background.customImages:
  
  
  
  
  • 是一个数组，默认是用第一张图片做背景图，在分屏的时候第二屏就用的是数组的第二个元素，以此类推
  
  
  • 支持 https 协议和本地的 file 协议
    
    
    
    • 因为我有公司机器和自己电脑，所以本地协议不太适用我，但是我之前一直用的是本地协议，并且下面会教大家如何白嫖图床
    
    
    
    
  
  
  
  


• background.style:
  
  
  
  
  • 作为一个前端，看到上面的内容是不是十分的熟悉，其实这个插件的底层原理就是去改 vscode 的 css，所以你可以想想成一个需求，在一个界面上显示一张图片，css 可以怎么写，背景图就可以是啥样的
  
  
  • 如果你看不懂 css 代码，你可以直接复制我上面提供的两种配置，一个全屏的，一个是在右下角固定一小只的
  
  
  
  


• 如果你觉得背景图太亮了，有点看不清代码，你可以修改 background.style.opacity这个属性，降低图片的透明度。


• 发现最新版本支持 background.interval 来轮播背景图了

高清社死图片

OK，其实到这就没啥了，但是到这里和原神好像并没有什么太大的关系，那现在我就教你怎么白嫖米游社的图床，并且获取高清的原神图片

• 第一步，你需要有一个米游社的账号，当然，玩原神的不能没有吧


• 第二步，随便找个帖子进行评论回复，如果你怕麻烦别人，可以自己发一贴
  
  
  
  
  • 
  
  
  
  


• 第三步：新标签页打开
  
  
  
  
  • 
  
  
  
  


• 到这里，你就能白嫖米游社的图床了，如果你是评论的自己的图片，新标签页打开之后，删除 url 中 ? 后面所有的内容，就可以得到原图 https 的链接了


• 但是又遇到一个问题，我就是很喜欢米游社的图片，但是图片的分辨率太低了怎么办？
  
  
  
  
  • 提供两个用 ai 来放大图片的网站
  
  
  • waifu2x.udp.jp/
  
  
  • bigjpg.com/
  
  
  • 把图片放大之后，在用上面白嫖图床的方法就可以了
  
  
  
  

最后

水一期，求三连 + 可以在评论区分享你的背景图嘛

抛个砖头

不知道大家用了这么久的掘金，有没有对它文章中的阅读量的实现有过好奇呢？

想象一下，你每次打开一篇文章时，都会有一个数字告诉你多少人已经读过这篇文章。那么这个数字是怎么得出来的呢？

有些人可能会认为，每次有人打开文章，数字就加1，不是很简单吗？ 起初我也以为这样，哈哈（和大家站在同一个高度），但（好了，我不说了，继续往下看吧！）

引个玉

文章阅读量的统计看似简单，实则蕴含着巧妙的逻辑和高效的技术实现。我们想要得到的阅读量，并非简单的页面刷新次数，而是真正独立阅读过文章的人数。因此，传统的每次页面刷新加1的方法显然不够准确，它忽略了用户的重复访问。

同时，阅读作为一个高频操作，如果每次都直接写入数据库，无疑会给数据库带来巨大的压力，甚至可能影响到整个系统的性能和稳定性。这就需要我们寻找一种既能准确统计阅读量，又能减轻数据库压力的方法。

Redis，这个高性能的内存数据库，为我们提供了解决方案。我们可以利用Redis的键值对存储特性，将用户ID和文章ID的组合作为键，设置一个短暂的过期时间，比如15分钟。当用户首次访问文章时，我们在Redis中为这个键设置一个值，表示该用户已经阅读过这篇文章。如果用户在15分钟内再次访问，我们可以直接判断该键是否存在，如果存在，则不再增加阅读量，否则进行增加。

这种方法的优点在于，它能够准确地统计出真正阅读过文章的人数，而不是简单的页面刷新次数。同时，通过将阅读量先存储在Redis中，我们避免了频繁地写入数据库，从而大大减轻了数据库的压力。

最后，我们还需要考虑如何将Redis中的阅读量最终写入数据库。由于数据库的写入操作相对较重，我们不宜频繁进行。因此，我们可以选择在业务低峰期，比如凌晨2到4点，使用定时任务将Redis中的阅读量批量写入数据库。这样，既保证了阅读量的准确统计，又避免了频繁的数据库写入操作，实现了高效的系统运行。

思路梳理

代码层面

项目使用的后端框架为NestJS

配置下redis

一、安装redis plugin

npm install --save redis

二、创建redis模块

三、初始化连接redis相关配置

@Module({

  providers: [

    RedisService,

    {

      provide: 'REDIS_CLIENT',

      async useFactory(configService: ConfigService) {

        console.log(configService.get('redis_server_host'));

        const client = createClient({

          socket: {

            host: configService.get('redis_server_host'),

            port: configService.get('redis_server_port'),

          },

          database: configService.get('redis_server_db'),

        });

        await client.connect();

        return client;

      },

      inject: [ConfigService],

    },

  ],

  exports: [RedisService],

})

Redis是一个Key-Value型数据库，可以用作数据库，所有的数据以Key-Value的形式存在服务器的内存中，其中Value可以是多种数据结构，如字符串（String）、哈希（hashes）、列表（list）、集合（sets）和有序集合（sorted sets）等类型

在这里会用到字符串和哈希两种。

创建文章表和用户表

我的项目中创建有post.entity和user.entity这两个实体表，并为post文章表添加以下

这三个字段，在这里我们只拿 阅读量 说事。

访问文章详情接口-阅读量+1

  /**

   * @description 增加阅读量

   * @param id

   * @returns

   */

  @Get('xxx/:id')

  @RequireLogin()

  async frontIncreViews(@Param('id') id: string, @Req() _req: any,) {

    console.log('frontFindOne');

    return await this.postService.frontIncreViews(+id, _req?.user);

  }

前文已经说过，同一个用户多次刷新，如果不做处理，就会产生多次无效的阅读量。 因此，为了避免这种情况方式，我们需要为其增加一个用户文章id组合而成的标记，并设置在有效时间内不产生多次阅读量。

那么，有的掘友可能会产生一个疑问，如果用户未登录，那么以游客的身份去访问文章就不产生阅读记录了吗？

其实同理！

在我的项目中只是，要求需要用户登录后才能访问，
那么我这就会以 userID_postID_ 来组成标识区分用户和文章罢了。
而如果想以游客身份，我们可以获取用户 IP_postID 这样的组合来做标识即可

接下来说下postService中调用的frontIncreViews方法
直接贴代码：

 const res = await this.redisService.hashGet(`post_${id}`);



    if (res.viewCount === undefined) {

      const post = await this.postRepository.findOne({ where: { id } });



      post.viewCount++;



      await this.postRepository.update(id, { viewCount: post.viewCount });



      await this.redisService.hashSet(`post_${id}`, {

        viewCount: post.viewCount,

        likeCount: post.likeCount,

        collectCount: post.collectCount,

      });

      // 在用户访问文章的时候在 redis 存一个 10 分钟过期的标记，有这个标记的时候阅读量不增加

      await this.redisService.set(`user_${user.id}_post_${id}`, 1, 10);



      return post.viewCount;

    } else {

      const flag = await this.redisService.get(`user_${user.id}_post_${id}`);

      console.log(flag);

      if (flag) {

        return res.viewCount;

      }



      await this.redisService.hashSet(`post_${id}`, {

        ...res,

        viewCount: +res.viewCount + 1,

      });



      await this.redisService.set(`user_${user.id}_post_${id}`, 1, 10);

      return +res.viewCount + 1;

    }

  }

const res = await this.redisService.hashGet(`post_${id}`);

使用Redis的哈希表结构，从键post_${id}中获取文章的信息，其中可能包含阅读量（viewCount）、点赞数（likeCount）和收藏数（collectCount）。

2. 检查Redis中是否存在阅读量:

if (res.viewCount === undefined) {

如果Redis中没有阅读量数据，说明这篇文章的阅读量还没有被初始化。

3. 从数据库中获取文章并增加阅读量:

const post = await this.postRepository.findOne({ where: { id } });

post.viewCount++;

await this.postRepository.update(id, { viewCount: post.viewCount });

从数据库中获取文章，然后增加阅读量，并更新数据库中的文章阅读量。

4. 将更新后的文章信息存回Redis:

await this.redisService.hashSet(`post_${id}`, {

  viewCount: post.viewCount,

  likeCount: post.likeCount,

  collectCount: post.collectCount,

});

将更新后的文章信息（包括新的阅读量、点赞数和收藏数）存回Redis的哈希表中。

5. 设置用户访问标记:

await this.redisService.set(`user_${user.id}_post_${id}`, 1, 10);

在用户访问文章时，在Redis中设置一个带有10分钟过期时间的标记，用于防止在10分钟内重复增加阅读量。

6. 返回阅读量:

return post.viewCount;

返回更新后的阅读量。

7. 如果Redis中存在阅读量:

} else {

  const flag = await this.redisService.get(`user_${user.id}_post_${id}`);

  console.log(flag);

如果Redis中存在阅读量数据，则检查用户是否已经访问过该文章。

8. 检查用户访问标记:

if (flag) {

  return res.viewCount;

}

如果用户已经访问过该文章（标记存在），则直接返回当前阅读量，不增加。

9. 如果用户未访问过文章:

await this.redisService.hashSet(`post_${id}`, {

  ...res,

  viewCount: +res.viewCount + 1,

});

await this.redisService.set(`user_${user.id}_post_${id}`, 1, 10);

return +res.viewCount + 1;

如果用户未访问过该文章，则增加阅读量，并重新设置用户访问标记。然后返回更新后的阅读量。

简而言之，目的是在用户访问文章时，确保文章阅读量只增加一次，即使用户在短时间内多次访问。

NestJS使用定时任务包，实现redis数据同步到数据库中

有的掘友可能疑问，既然已经用redis来做阅读量记录了，为什么还要同步到数据库中，前文开始的时候，就已经提到过了，一旦我们的项目重启， redis 数据就没了，而数据库却有着“数据持久性的优良品质”。不像redis重启后，又是个新生儿。但是它们的互补，又是1+1大于2的那种。

好了，不废话了

一、引入定时任务包 @nestjs/schedule

npm install --save @nestjs/schedule

在 app.module.ts 引入

二、创建定时任务模块和服务

nest g module task 

nest g service task

你可以在同一个服务里面声明多个定时任务方法。在 NestJS 中，使用 @nestjs/schedule 库时，你只需要在服务类中为每个定时任务方法添加 @Cron() 装饰器，并指定相应的 cron 表达式。以下是一个示例，展示了如何在同一个服务中声明两个定时任务：

import { Injectable } from '@nestjs/common';

import { Cron, CronExpression } from '@nestjs/schedule';



@Injectable()

export class TasksService {

  // 第一个定时任务，每5秒执行一次

  @Cron(CronExpression.EVERY_5_SECONDS)

  handleEvery5Seconds() {

    console.log('Every 5 seconds task executed');

  }



  // 第二个定时任务，每10秒执行一次

  @Cron(CronExpression.EVERY_10_SECONDS)

  handleEvery10Seconds() {

    console.log('Every 10 seconds task executed');

  }

}

三、实现定时任务中同步文章阅读量的任务

更新文章的阅读数据

await this.postService.flushRedisToDB();

  // 查询出 key 对应的值，更新到数据库。 做定时任务的时候加上

  async flushRedisToDB() {

    const keys = await this.redisService.keys(`post_*`);

    console.log(keys);

    for (let i = 0; i < keys.length; i++) {

      const key = keys[i];



      const res = await this.redisService.hashGet(key);



      const [, id] = key.split('_');



      await this.postRepository.update(

        {

          id: +id,

        },

        {

          viewCount: +res.viewCount,

        },

      );

    }

  }

等到第二天，哈，数据就同步来了

访问：

而产生的后台数据：

抛出问题

如果能看到这里的掘友，若能接下这个问题，说明你已经掌握了吖

问题1：

如何实现一个批量返回redis键值对的方法（这个方法问题2需要用到）

问题2：

用户查询文章列表的时候，如何整理数据后返回文章阅读量呈现给用户查看

公众号：【可乐前端】，每天3分钟学习一个优秀的开源项目，分享web面试与实战知识。

前言

可乐是一名前端切图仔，最近他们团队需要做一个文章社区平台。由于人手不够，前后端部分都是由前端同学来实现，后端部分用的技术栈是 nest.js 。

某一个周一，领导希望做一个给文章点赞的功能，在文章列表页与文章详情页需要看到该文章的点赞总数，以及当前登录的用户有没有对该文章点赞，即用户与文章的点赞关系。

交代完之后，领导就去出差了。等领导回来时已是周五，他问可乐：这期的需求进展如何？

可乐回答：点赞的需求我做完了，其他的还没开始。

领导生气的说：为什么点赞这样的一个小功能你做了五天才做完？？？

可乐回答：领导息怒。。请听我细细道来

往期文章

仓库地址

• 切图仔做全栈：React&Nest.js 社区平台(一)——基础架构与邮箱注册、JWT 登录实现


• 切图仔做全栈：React&Nest.js社区平台(二)——👋手把手实现优雅的鉴权机制


• React&Nest.js全栈社区平台(三)——🐘对象存储是什么？为什么要用它？


• React&Nest.js社区平台(四)——✏️文章发布与管理实战


• React&Nest.js全栈社区平台(五)——👋封装通用分页Service实现文章流与详情

初步设计

对于上面的这个需求，我们提炼出来有三点最为重要的功能：

所以这里容易想到的是在文章表中冗余一个点赞数量字段 likes ，查询文章的时候一起把点赞总数带出来。

然后建一张 article_lile_relation 表，建立文章点赞与用户之间的关联关系。

上面的数据就表明了 id 为 2001 的用户点赞了 id 为 1001 的文章； id 为 2002 的用户对 id 为 1001 的文章取消了点赞。

这是对于这种关联关系需求最容易想到的、也是成本不高的解决方案，但在仔细思考了一番之后，我放弃了这种方案。原因如下：

基于上面的考虑，准备设计一个通用的点赞模块，以拓展后续各种业务的点赞需求。

表设计

首先来一张通用的点赞表， DDL 语句如下：

CREATE TABLE `like_records` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `user_id` int(11) DEFAULT NULL,

  `target_id` int(11) DEFAULT NULL,

  `type` int(4) DEFAULT NULL,

  `created_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP,

  `updated_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP,

  `value` int(4) DEFAULT '0',

  PRIMARY KEY (`id`),

  KEY `like_records_target_id_IDX` (`target_id`,`user_id`,`type`) USING BTREE,

  KEY `like_records_user_id_IDX` (`user_id`,`target_id`,`type`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;

解释一下上面各个字段的含义：

• id ：点赞记录的主键 id


• user_id ：点赞用户的 id


• target_id ：被点赞的文章 id


• type ：点赞类型：可能有文章、帖子、评论等


• value ：是否点赞， 1 点赞， 0 取消点赞


• created_time ：创建时间


• updated_time ：更新时间

前置知识

在设计好数据表之后，再来捋清楚这个业务的一些特定属性与具体实现方式：

所以可乐针对这样的业务特性上网查找了一些资料，发现有一些前置知识是他所欠缺的，我们一起来看看。

mysql事务

mysql 的事务是指一系列的数据库操作，这些操作要么全部成功执行，要么全部失败回滚。事务是用来确保数据库的完整性、一致性和持久性的机制之一。

在 mysql 中，事务具有以下四个特性，通常缩写为 ACID ：

这里以商品下单创建订单并扣除库存为例，演示一下 nest+typeorm 中的事务如何使用：

import { Injectable } from '@nestjs/common';

import { InjectEntityManager } from '@nestjs/typeorm';

import { EntityManager } from 'typeorm';

import { Order } from './order.entity';

import { Product } from './product.entity';



@Injectable()

export class OrderService {

  constructor(

    @InjectEntityManager()

    private readonly entityManager: EntityManager,

  ) {}



  async createOrderAndDeductStock(productId: number, quantity: number): Promise<Order> {

    return await this.entityManager.transaction(async transactionalEntityManager => {

      // 查找产品并检查库存是否充足

      const product = await transactionalEntityManager.findOne(Product, productId);

      if (!product || product.stock < quantity) {

        throw new Error('Product not found or insufficient stock');

      }



      // 创建订单

      const order = new Order();

      order.productId = productId;

      order.quantity = quantity;

      await transactionalEntityManager.save(order);



      // 扣除库存

      product.stock -= quantity;

      await transactionalEntityManager.save(product);



      return order;

    });

  }

}

this.entityManager.transaction 创建了一个事务，在异步函数中，如果发生错误， typeorm 会自动回滚事务；如果没有发生错误，typeorm 会自动提交事务。

在这个实例中，尝试获取库存并创建订单和减库存，如果任何一个地方出错异常抛出，则事务就会回滚，这样就保证了多表间数据的一致性。

分布式锁

分布式锁是一种用于在分布式系统中协调多个节点并保护共享资源的机制。在分布式系统中，由于涉及多个节点并发访问共享资源，因此需要一种机制来确保在任何给定时间只有一个节点能够访问或修改共享资源，以防止数据不一致或竞争条件的发生。

对于同一个用户对同一篇文章频繁的点赞/取消点赞请求，可以加分布式锁的机制，来规避一些问题：

在 redis 中实现分布式锁通常使用的是基于 SETNX 命令和 EXPIRE 命令的方式：

  async getLock(key: string) {

    const res = await this.redis.setnx(key, 'lock');

    if (res) {

        // 10秒锁过期

        await this.redis.expire(key, 10);

    }

    return res;

  }



  async unLock(key: string) {

    return this.del(key);

  }

redis中的set结构

redis 中的 set 是一种无序集合，用于存储多个不重复的字符串值，set 中的每个成员都是唯一的。

我们存储点赞关系的时候，需要用到 redis 中的 set 结构，存储的 key 与 value 如下：

article_1001:[uid1,uid2,uid3]

这就表示文章 id 为 1001 的文章，有用户 id 为 uid1 、 uid2 、 uid3 这三个用户点赞了。

常用的 set 结构操作命令包括：

• SADD key member [member ...]: 将一个或多个成员加入到集合中。


• SMEMBERS key: 返回集合中的所有成员。


• SISMEMBER key member: 检查成员是否是集合的成员。


• SCARD key: 返回集合元素的数量。


• SREM key member [member ...]: 移除集合中一个或多个成员。


• SPOP key [count]: 随机移除并返回集合中的一个或多个元素。


• SRANDMEMBER key [count]: 随机返回集合中的一个或多个元素，不会从集合中移除元素。


• SUNION key [key ...]: 返回给定所有集合的并集。


• SINTER key [key ...]: 返回给定所有集合的交集。


• SDIFF key [key ...]: 返回给定所有集合的差集。

下面举几个点赞场景的例子

redis事务

在 redis 中，事务是一组命令的有序序列，这些命令在执行时会被当做一个单独的操作来执行。即事务中的所有命令要么全部执行成功，要么全部执行失败，不存在部分执行的情况。

以下是 redis 事务的主要命令：

比如说下面的代码给集合增加元素，并更新集合的过期时间，可以如下使用 redis 的事务去执行它：

  const pipeline = this.redisService.multi();

  const setKey = this.getSetKey(targetId, type);

  if (value === ELike.LIKE) {

    pipeline.sadd(setKey, userId);

  } else {

    pipeline.srem(setKey, userId);

  }

  pipeline.expire(setKey, this.ttl);

  await pipeline.exec();

流程图设计

在了解完这些前置知识之后，可乐开始画一些实现的流程图。

首先是点赞/取消点赞接口的流程图：

简单解释下上面的流程图：

然后是获取点赞数量和点赞关系的接口

简单解释下上面的流程图：

代码实现

在所有的设计完毕之后，可以做最后的代码实现了。分别来实现点赞操作与点赞数量接口。这里主要关注 service 层的实现即可。

点赞/取消点赞接口

  async toggleLike(params: {

    userId: number;

    targetId: number;

    type: ELikeType;

    value: ELike;

  }) {

    const { userId, targetId, type, value } = params;

    const LOCK_KEY = `${userId}::${targetId}::${type}::toggleLikeLock`;

    const canGetLock = await this.redisService.getLock(LOCK_KEY);

    if (!canGetLock) {

      console.log('获取锁失败');

      await wait();

      return this.toggleLike(params);

    }

    const record = await this.likeRepository.findOne({

      where: { userId, targetId, type },

    });

    if (record && record.value === value) {

      await this.redisService.unLock(LOCK_KEY);

      throw Error('不可重复操作');

    }



    await this.entityManager.transaction(async (transactionalEntityManager) => {

      if (!record) {

        const likeEntity = new LikeEntity();

        likeEntity.targetId = targetId;

        likeEntity.type = type;

        likeEntity.userId = userId;

        likeEntity.value = value;

        await transactionalEntityManager.save(likeEntity);

      } else {

        const id = record.id;

        await transactionalEntityManager.update(LikeEntity, { id }, { value });

      }

      const isSuccess = await this.tryToFreshCache(params);



      if (!isSuccess) {

        await this.redisService.unLock(LOCK_KEY);

        throw Error('操作失败');

      }

    });

    await this.redisService.unLock(LOCK_KEY);

    return true;

  }

  

private async tryToFreshCache(

    params: {

      userId: number;

      targetId: number;

      type: ELikeType;

      value: ELike;

    },

    retry = 3,

  ) {

    if (retry === 0) {

      return false;

    }

    const { targetId, type, value, userId } = params;

    try {

      const pipeline = this.redisService.multi();

      const setKey = this.getSetKey(targetId, type);

      if (value === ELike.LIKE) {

        pipeline.sadd(setKey, userId);

      } else {

        pipeline.srem(setKey, userId);

      }

      pipeline.expire(setKey, this.ttl);

      await pipeline.exec();

      return true;

    } catch (error) {

      console.log('tryToFreshCache error', error);

      await wait();

      return this.tryToFreshCache(params, retry - 1);

    }

  }

可以参照流程图来看这部分实现代码，基本实现就是使用 mysql 事务去更新点赞信息表，然后去更新 redis 中的点赞信息，如果更新失败则回滚事务，保证数据的一致性。

获取点赞数量、点赞关系接口

  async getLikes(params: {

    targetId: number;

    type: ELikeType;

    userId: number;

  }) {

    const { targetId, type, userId } = params;

    const setKey = this.getSetKey(targetId, type);

    const cacheExsit = await this.redisService.exist(setKey);

    if (!cacheExsit) {

      await this.getLikeFromDbAndSetCache(params);

    }

    const count = await this.redisService.getSetLength(setKey);

    const isLike = await this.redisService.isMemberOfSet(setKey, userId);

    return { count, isLike };

  }



  private async getLikeFromDbAndSetCache(params: {

    targetId: number;

    type: ELikeType;

    userId: number;

  }) {

    const { targetId, type, userId } = params;

    const LOCK_KEY = `${targetId}::${type}::getLikesLock`;

    const canGetLock = await this.redisService.getLock(LOCK_KEY);

    if (!canGetLock) {

      console.log('获取锁失败');

      await wait();

      return this.getLikeFromDbAndSetCache(params);

    }

    const setKey = this.getSetKey(targetId, type);

    const cacheExsit = await this.redisService.exist(setKey);

    if (cacheExsit) {

      await this.redisService.unLock(LOCK_KEY);

      return true;

    }

    const data = await this.likeRepository.find({

      where: {

        targetId,

        userId,

        type,

        value: ELike.LIKE,

      },

      select: ['userId'],

    });

    if (data.length !== 0) {

      await this.redisService.setAdd(

        setKey,

        data.map((item) => item.userId),

        this.ttl,

      );

    }

    await this.redisService.unLock(LOCK_KEY);

    return true;

  }

由于读操作相当频繁，所以这里应当多使用缓存，少查询数据库。读点赞信息时，先查 redis 中有没有，如果没有，则从 mysql 同步到 redis 中，同步的过程中也使用到了分布式锁，防止一开始没缓存时请求大量打到 mysql 。

同时，如果所有文章的点赞信息都同时存在 redis 中，那 redis 的存储压力会比较大，所以这里会给相关的 key 设置一个过期时间。当用户重新操作点赞时，会更新这个过期时间。保障缓存的数据都是相对热点的数据。

通过组装数据，获取点赞信息的返回数据结构如下：

返回一个 map ，其中 key 文章 id ， value 里面是该文章的点赞数量以及当前用户是否点赞了这篇文章。

前端实现

文章流列表发生变化的时候，可以监听列表的变化，然后去获取点赞的信息：

useEffect(() => {

    if (!article.list) {

      return;

    }

    const shouldGetLikeIds = article.list

      .filter((item: any) => !item.likeInfo)

      .map((item: any) => item.id);

    if (shouldGetLikeIds.length === 0) {

      return;

    }

    console.log("shouldGetLikeIds", shouldGetLikeIds);

    getLikes({

      targetIds: shouldGetLikeIds,

      type: 1,

    }).then((res) => {

      const map = res.data;

      const newList = [...article.list];

      for (let i = 0; i < newList.length; i++) {

        if (!newList[i].likeInfo && map[newList[i].id]) {

          newList[i].likeInfo = map[newList[i].id];

        }

      }

      const newArticle = { ...article };

      newArticle.list = newList;

      setArticle(newArticle);

    });

  }, [article]);

点赞操作的时候前端也需要加锁，接口执行完毕了再把锁释放。

   <Space

    onClick={(e) => {

      e.stopPropagation();

      if (lockMap.current?.[item.id]) {

        return;

      }

      lockMap.current[item.id] = true;

      const oldValue = item.likeInfo.isLike;

      const newValue = !oldValue;

      const updateValue = (value: any) => {

        const newArticle = { ...article };

        const newList = [...newArticle.list];

        const current = newList.find(

          (_) => _.id === item.id

        );

        current.likeInfo.isLike = value;

        if (value) {

          current.likeInfo.count++;

        } else {

          current.likeInfo.count--;

        }

        setArticle(newArticle);

      };

      updateValue(newValue);

      toggleLike({

        targetId: item.id,

        value: Number(newValue),

        type: 1,

      })

        .catch(() => {

          updateValue(oldValue);

        })

        .finally(() => {

          lockMap.current[item.id] = false;

        });

    }}

  >

    <LikeOutlined

      style={

        item.likeInfo.isLike ? { color: "#1677ff" } : {}

      }

    />

    {item.likeInfo.count}

  </Space>

解释

可乐：从需求分析考虑、然后研究网上的方案并学习前置知识，再是一些环境的安装，最后才是前后端代码的实现，领导，我这花了五天不过份吧。

领导（十分无语）：我们平台本来就没几个用户、没几篇文章，本来就是一张关联表就能解决的问题，你又搞什么分布式锁又搞什么缓存，还花了那么多天时间。我不管啊，剩下没做的需求你得正常把它正常做完上线，今天周五，周末你也别休息了，过来加班吧。

最后

以上就是本文的全部内容，如果你觉得有意思的话，点点关注点点赞吧～

@RestControllerAdvice

public class GlobalExceptionHandler {



    /**

     *  参数校检异常

     * @param e

     * @return

     */

    @ExceptionHandler(value = MethodArgumentNotValidException.class)

    public ResponseResult handle(MethodArgumentNotValidException e) {

        BindingResult bindingResult = e.getBindingResult();



        StringJoiner joiner = new StringJoiner(";");



        for (ObjectError error : bindingResult.getAllErrors()) {

            String code = error.getCode();

            String[] codes = error.getCodes();



            String property = codes[1];

            property = property.replace(code ,"").replaceFirst(".","");



            String defaultMessage = error.getDefaultMessage();

            joiner.add(property+defaultMessage);

        }

        return handleException(joiner.toString());

    }



    private ResponseResult handleException(String msg) {

        ResponseResult result = new ResponseResult<>();

        result.setMessage(msg);

        result.setCode(500);

        return result;

    }

}

public interface CreationGr0up {

}

public interface UpdateGr0up {

}

创建一个UserBean用户类，分别校验 username 字段不能为空和id字段必须大于0，然后加上CreationGr0up和 UpdateGr0up 分组。

/**

 * @author 公众号-索码理(suncodernote)

 */

@Data

public class UserBean {



    @NotEmpty( groups = {CreationGr0up.class})

    private String username;



    @Min(value = 18)

    private Integer age;



    @Email(message = "邮箱格式不正确")

    private String email;



    @Min(value  = 1 ,groups = {UpdateGr0up.class})

    private Long id;

}

3. 创建接口

在ValidationController 中新建两个接口 updateUser 和 createUser：

@RestController

@RequestMapping("validation")

public class ValidationController {



    @GetMapping("updateUser")

    public UserBean updateUser(@Validated({UpdateGr0up.class})  UserBean userBean){

        return userBean;

    }



    @GetMapping("createUser")

    public UserBean createUser(@Validated({CreationGr0up.class})  UserBean userBean){

        return userBean;

    }

}

4. 测试

先对 createUser接口进行测试，我们将id的值设置为0，也就是不满足id必须大于0的条件，同样 username 不传值，即不满足 username 不能为空的条件。  通过测试结果我们可以看到，虽然id没有满足条件，但是并没有提示，只提示了username不能为空。

再对 updateUser接口进行测试，条件和测试 createUser接口的条件一样，再看测试结果，和 createUser接口测试结果完全相反，只提示了id最小不能小于1。 

至此，分组功能就演示完毕了。

嵌套校验

介绍嵌套校验之前先看一下两个概念：

有这样一个需求，在保存用户时，用户地址必须要填写。下面来简单看下示例：

在AddressBean 设置 country和city两个属性为必填项。

@Data

public class AddressBean {



    @NotBlank

    private String country;



    @NotBlank

    private String city;

}

2. 修改用户类，将AddressBean作为用户类的一个嵌套属性

特别提示：想要嵌套校验生效，必须在嵌套属性上加 @Valid 注解。

@Data

public class UserBean {



    @NotEmpty(groups = {CreationGr0up.class})

    private String username;



    @Min(value = 18)

    private Integer age;



    private String email;



    @Min(value  = 1 ,groups = {UpdateGr0up.class})

    private Long id;



	//嵌套验证必须要加上@Valid

    @Valid

    @NotNull

    private AddressBean address;

}

3. 创建一个嵌套校验测试接口

@PostMapping("nestValid")

public UserBean nestValid(@Validated @RequestBody UserBean userBean){

    System.out.println(userBean);

    return userBean;

}

4. 测试

我们在传参时，只传 country字段，通过响应结果可以看到提示了city 字段不能为空。 

可以看到使用了 @Valid 注解来对 Address 对象进行验证，这会触发对其中的 Address 对象的验证。通过这种方式，可以确保嵌套属性内部的对象也能够参与到整体对象的验证过程中，从而提高验证的完整性和准确性。

总结

本文介绍了@Valid注解和@Validated注解的不同，同时也进一步介绍了Springboot 参数校验的使用。不管是 JSR-303、JSR-380又或是 Hibernate Validator ，它们提供的参数校验注解都是有限的，实际工作中这些注解可能是不够用的，这个时候就需要我们自定义参数校验了。下篇文章将介绍一下如何自定义一个参数校验器。

MinIO： 数据宇宙的超级存储引擎，解锁云原生潜能- 精选真开源，释放新价值。

概览

MinIO，这一高性能分布式对象存储系统的佼佼者，正以开源的力量重塑企业数据存储的版图。它设计轻巧且完全兼容Amazon S3接口，成为连接全球开发者与企业的桥梁，提供了一个既强大又灵活的数据管理平台。超越传统存储桶的范畴，MinIO是专为应对大规模数据挑战而生，尤其适用于AI深度学习、大数据分析等高负载场景，其单个对象高达5TB的存储容量设计，确保了数据密集应用运行无阻，流畅高效。

无论是部署于云端、边缘计算环境还是本地服务器，MinIO展现了极高的适配性和灵活性。它以超简单的安装步骤、直观的管理界面以及平滑的扩展能力，极大地降低了企业构建复杂数据架构的门槛。利用MinIO，企业能够快速部署数据湖，以集中存储海量数据，便于分析挖掘；构建高效的内容分发网络（CDN），加速内容的全球分发；或建立可靠的备份存储方案，确保数据资产的安全无虞。

MinIO的特性还包括自动数据分片、跨区域复制、以及强大的数据持久性和高可用性机制，这些都为数据的全天候安全与访问提供了坚实保障。此外，其微服务友好的架构，使得集成到现有的云原生生态系统中变得轻而易举，加速了DevOps流程，提升了整体IT基础设施的响应速度和灵活性。

主要功能

你可以进入官方网站下载体验：min.io/download

• 高性能存储

• 分布式架构

• 全面的S3兼容性

• 安全与合规

• 简易管理与监控

信息

截至发稿概况如下：

• 软件地址：github.com/minio/minio


• 软件协议：AGPL 3.0


• 编程语言：

• 收藏数量：44.3K

面对不断增长的数据管理挑战，MinIO不仅是一个存储解决方案，更是企业在数字化转型旅程中的核心支撑力量，助力各行各业探索数据价值的无限可能。无论是优化存储成本、提升数据处理效率，还是确保数据安全与合规，MinIO持续推动技术边界，邀请每一位技术探索者加入其活跃的开源社区，共同参与讨论，贡献智慧，共同塑造数据存储的未来。

尽管MinIO凭借其卓越的性能与易于使用的特性在存储领域独树一帜，但面对数据量的指数级增长和环境的日益复杂，一系列新挑战浮出水面。首要任务是在海量数据中实现高效的数据索引与查询机制，确保信息的快速提取与分析。其次，在混合云及多云部署的趋势下，如何平滑实现数据在不同平台间的迁移与实时同步，成为提升业务连续性和灵活性的关键。再者，数据安全虽为根基，但在成本控制上也不可忽视，优化存储策略，在强化防护的同时降低开支，实现存储经济性与安全性的完美平衡，是当前亟待探讨与解决的课题。这些问题不仅考验着技术的极限，也为MinIO及其用户社区带来了新的研究方向与实践机遇。

热烈欢迎各位在评论区分享交流心得与见解！！！

这一章，我们将简单的介绍以太坊中的数字签名ECDSA，以及如何利用它发放NFT白名单。代码中的ECDSA库由OpenZeppelin的同名库简化而成。

数字签名

如果你用过opensea交易NFT，对签名就不会陌生。下图是小狐狸（metamask）钱包进行签名时弹出的窗口，它可以证明你拥有私钥的同时不需要对外公布私钥。

以太坊使用的数字签名算法叫双椭圆曲线数字签名算法（ECDSA），基于双椭圆曲线“私钥-公钥”对的数字签名算法。它主要起到了三个作用：

ECDSA合约

ECDSA标准中包含两个部分：

私钥: 0x227dbb8586117d55284e26620bc76534dfbd2394be34cf4a09cb775d593b6f2b

公钥: 0xe16C1623c1AA7D919cd2241d8b36d9E79C1Be2A2

消息: 0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c

以太坊签名消息: 0xb42ca4636f721c7a331923e764587e98ec577cea1a185f60dfcc14dbb9bd900b

签名: 0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

创建签名

1. 打包消息：  在以太坊的ECDSA标准中，被签名的消息是一组数据的keccak256哈希，为bytes32类型。我们可以把任何想要签名的内容利用abi.encodePacked()函数打包，然后用keccak256()计算哈希，作为消息。我们例子中的消息是由一个address类型变量和一个uint256类型变量得到的：

    /*

     * 将mint地址（address类型）和tokenId（uint256类型）拼成消息msgHash

     * _account: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4

     * _tokenId: 0

     * 对应的消息msgHash: 0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c

     */

    function getMessageHash(address _account, uint256 _tokenId) public pure returns(bytes32){

        return keccak256(abi.encodePacked(_account, _tokenId));

    }

2. 计算以太坊签名消息：  消息可以是能被执行的交易，也可以是其他任何形式。为了避免用户误签了恶意交易，EIP191提倡在消息前加上"\x19Ethereum Signed Message:\n32"字符，并再做一次keccak256哈希，作为以太坊签名消息。经过toEthSignedMessageHash()函数处理后的消息，不能被用于执行交易:

    /**

     * @dev 返回 以太坊签名消息

     * `hash`：消息

     * 遵从以太坊签名标准：https://eth.wiki/json-rpc/API#eth_sign[`eth_sign`]

     * 以及`EIP191`:https://eips.ethereum.org/EIPS/eip-191`

     * 添加"\x19Ethereum Signed Message:\n32"字段，防止签名的是可执行交易。

     */

    function toEthSignedMessageHash(bytes32 hash) internal pure returns (bytes32) {

        // 哈希的长度为32

        return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash));

    }

处理后的消息为：

以太坊签名消息: 0xb42ca4636f721c7a331923e764587e98ec577cea1a185f60dfcc14dbb9bd900b

3-1. 利用钱包签名：  日常操作中，大部分用户都是通过这种方式进行签名。在获取到需要签名的消息之后，我们需要使用metamask钱包进行签名。metamask的personal_sign方法会自动把消息转换为以太坊签名消息，然后发起签名。所以我们只需要输入消息和签名者钱包account即可。需要注意的是输入的签名者钱包account需要和metamask当前连接的account一致才能使用。

因此首先把例子中的私钥导入到小狐狸钱包，然后打开浏览器的console页面：Chrome菜单-更多工具-开发者工具-Console。在连接钱包的状态下（如连接opensea，否则会出现错误），依次输入以下指令进行签名：

ethereum.enable()

account = "0xe16C1623c1AA7D919cd2241d8b36d9E79C1Be2A2"

hash = "0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c"

ethereum.request({method: "personal_sign", params: [account, hash]})

在返回的结果中（Promise的PromiseResult）可以看到创建好的签名。不同账户有不同的私钥，创建的签名值也不同。利用教程的私钥创建的签名如下所示：

0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

3-2. 利用web3.py签名：  批量调用中更倾向于使用代码进行签名，以下是基于web3.py的实现。

from web3 import Web3, HTTPProvider

from eth_account.messages import encode_defunct



private_key = "0x227dbb8586117d55284e26620bc76534dfbd2394be34cf4a09cb775d593b6f2b"

address = "0x5B38Da6a701c568545dCfcB03FcB875f56beddC4"

rpc = 'https://rpc.ankr.com/eth'

w3 = Web3(HTTPProvider(rpc))



#打包信息

msg = Web3.solidityKeccak(['address','uint256'], [address,0])

print(f"消息：{msg.hex()}")

#构造可签名信息

message = encode_defunct(hexstr=msg.hex())

#签名

signed_message = w3.eth.account.sign_message(message, private_key=private_key)

print(f"签名：{signed_message['signature'].hex()}")

运行的结果如下所示。计算得到的消息，签名和前面的案例一致。

消息：0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c

签名：0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

验证签名

为了验证签名，验证者需要拥有消息，签名，和签名使用的公钥。我们能验证签名的原因是只有私钥的持有者才能够针对交易生成这样的签名，而别人不能。

4. 通过签名和消息恢复公钥： 签名是由数学算法生成的。这里我们使用的是rsv签名，签名中包含r, s, v三个值的信息。而后，我们可以通过r, s, v及以太坊签名消息来求得公钥。下面的recoverSigner()函数实现了上述步骤，它利用以太坊签名消息 _msgHash和签名 _signature恢复公钥（使用了简单的内联汇编）：

    // @dev 从_msgHash和签名_signature中恢复signer地址

    function recoverSigner(bytes32 _msgHash, bytes memory _signature) internal pure returns (address){

        // 检查签名长度，65是标准r,s,v签名的长度

        require(_signature.length == 65, "invalid signature length");

        bytes32 r;

        bytes32 s;

        uint8 v;

        // 目前只能用assembly (内联汇编)来从签名中获得r,s,v的值

        assembly {

            /*

            前32 bytes存储签名的长度 (动态数组存储规则)

            add(sig, 32) = sig的指针 + 32

            等效为略过signature的前32 bytes

            mload(p) 载入从内存地址p起始的接下来32 bytes数据

            */

            // 读取长度数据后的32 bytes

            r := mload(add(_signature, 0x20))

            // 读取之后的32 bytes

            s := mload(add(_signature, 0x40))

            // 读取最后一个byte

            v := byte(0, mload(add(_signature, 0x60)))

        }

        // 使用ecrecover(全局函数)：利用 msgHash 和 r,s,v 恢复 signer 地址

        return ecrecover(_msgHash, v, r, s);

    }

参数分别为：

// 以太坊签名消息

_msgHash：0xb42ca4636f721c7a331923e764587e98ec577cea1a185f60dfcc14dbb9bd900b

// 签名

_signature：0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

5. 对比公钥并验证签名：  接下来，我们只需要比对恢复的公钥与签名者公钥_signer是否相等：若相等，则签名有效；否则，签名无效：

    /**

     * @dev 通过ECDSA，验证签名地址是否正确，如果正确则返回true

     * _msgHash为消息的hash

     * _signature为签名

     * _signer为签名地址

     */

    function verify(bytes32 _msgHash, bytes memory _signature, address _signer) internal pure returns (bool) {

        return recoverSigner(_msgHash, _signature) == _signer;

    }

参数分别为：

_msgHash：0xb42ca4636f721c7a331923e764587e98ec577cea1a185f60dfcc14dbb9bd900b

_signature：0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

_signer：0xe16C1623c1AA7D919cd2241d8b36d9E79C1Be2A2

利用签名发放白名单

NFT项目方可以利用ECDSA的这个特性发放白名单。由于签名是链下的，不需要gas。方法非常简单，项目方利用项目方账户把白名单发放地址签名（可以加上地址可以铸造的tokenId）。然后mint的时候利用ECDSA检验签名是否有效，如果有效，则给他mint。

SignatureNFT合约实现了利用签名发放NFT白名单。

状态变量

合约中共有两个状态变量：

• signer：公钥，项目方签名地址。


• mintedAddress是一个mapping，记录了已经mint过的地址。

函数

合约中共有4个函数：

• 构造函数初始化NFT的名称和代号，还有ECDSA的签名地址signer。


• mint()函数接受地址address，tokenId和_signature三个参数，验证签名是否有效：如果有效，则把tokenId的NFT铸造给address地址，并将它记录到mintedAddress。它调用了getMessageHash()，ECDSA.toEthSignedMessageHash()和verify()函数。


• getMessageHash()函数将mint地址（address类型）和tokenId（uint256类型）拼成消息。


• verify()函数调用了ECDSA库的verify()函数，来进行ECDSA签名验证。

contract SignatureNFT is ERC721 {

    address immutable public signer; // 签名地址

    mapping(address => bool) public mintedAddress;   // 记录已经mint的地址



    // 构造函数，初始化NFT合集的名称、代号、签名地址

    constructor(string memory _name, string memory _symbol, address _signer)

    ERC721(_name, _symbol)

    {

        signer = _signer;

    }



    // 利用ECDSA验证签名并mint

    function mint(address _account, uint256 _tokenId, bytes memory _signature)

    external

    {

        bytes32 _msgHash = getMessageHash(_account, _tokenId); // 将_account和_tokenId打包消息

        bytes32 _ethSignedMessageHash = ECDSA.toEthSignedMessageHash(_msgHash); // 计算以太坊签名消息

        require(verify(_ethSignedMessageHash, _signature), "Invalid signature"); // ECDSA检验通过

        require(!mintedAddress[_account], "Already minted!"); // 地址没有mint过

        _mint(_account, _tokenId); // mint

        mintedAddress[_account] = true; // 记录mint过的地址

    }



    /*

     * 将mint地址（address类型）和tokenId（uint256类型）拼成消息msgHash

     * _account: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4

     * _tokenId: 0

     * 对应的消息: 0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c

     */

    function getMessageHash(address _account, uint256 _tokenId) public pure returns(bytes32){

        return keccak256(abi.encodePacked(_account, _tokenId));

    }



    // ECDSA验证，调用ECDSA库的verify()函数

    function verify(bytes32 _msgHash, bytes memory _signature)

    public view returns (bool)

    {

        return ECDSA.verify(_msgHash, _signature, signer);

    }

}

总结

这一讲，我们介绍了以太坊中的数字签名ECDSA，如何利用ECDSA创建和验证签名，还有ECDSA合约，以及如何利用它发放NFT白名单。代码中的ECDSA库由OpenZeppelin的同名库简化而成。

• 由于签名是链下的，不需要gas，因此这种白名单发放模式比Merkle Tree模式还要经济；


• 但由于用户要请求中心化接口去获取签名，不可避免的牺牲了一部分去中心化；


• 额外还有一个好处是白名单可以动态变化，而不是提前写死在合约里面了，因为项目方的中心化后端接口可以接受任何新地址的请求并给予白名单签名。