2024年2月

在昨天的
博文
中,我们通过 Semantic Kernel 调用了自己部署的通义千问开源大模型,但是自己部署通义千问对服务器的配置要求很高,即使使用抢占式按量实例,每次使用时启动服务器,使用完关闭服务器,也比较麻烦,而且越高级的大模型对服务器的配置越高。所以昨天的博文中使用了很低级的
Qwen-7B-Chat
模型,结果回答问题的效果很不理想,连博客园的网站域名都弄错了。

于是改变路线,尝试使用阿里云提供的模型服务灵积(
DashScope
),但是灵积没有提供兼容 OpenAI api 的 api,虽然提供了 SDK,但仅支持 Python 与 Java,望 SDK 心叹的同时准备今天试试自己写 C# 代码调用灵积提供的通义千问 api。

在动手写代码之前,不抱任何希望地去 nuget 官网碰碰运气,搜了搜
qwen
,竟然惊喜地出现了一个搜索结果

有人在2个月之前就开始开发灵积的非官方 .NET SDK ——
Sdcb.DashScope
,而且1个月之前发布了1.0版,真是及时雨,给作者点赞。

通过这 nuget 包的 Source repository 链接找到对应的 github 仓库
https://github.com/sdcb/Sdcb.DashScope
,立即签出代码,其中有单元测试代码,先跑一个测试体验一下。

先到阿里云灵积控制台的“API-KEY管理”中创建 api key,然后在自己的电脑上通过 user-secrets 保存 api key

dotnet user-secrets init
dotnet user-secrets set DashScopeApiKey sk-xxxxxxxxxxx

选择其中一个测试

[Fact]
public async Task OnlineChatTest()
{
    using DashScopeClient c = new(_apiKey);
    ResponseWrapper<ChatOutput, ChatTokenUsage> result = await c.TextGeneration.Chat("qwen-turbo", [ChatMessage.FromUser("今天长沙天气如何?")], new ChatParameters
    {
        EnableSearch = true
    });
    _console.WriteLine(result.ToString());
}

跑一下

dotnet test --filter OnlineChatTest

输出结果如下

ResponseWrapper { RequestId = 89e760f7-dc21-9461-8144-68629fa1ad00, Output = ChatOutput { Text = 今天是2024年2月11日,星期日,长沙的天气情况为晴朗。具体来说,湿度为75%,最低气温为3.0摄氏度,最高气温可达18.0摄氏度。风向以东南风为主,白天气温适宜,风力较小,仅为1级。夜间依然保持晴朗,风向转为东南风,风力同样维持在1级。建议外出时注意保暖,因为虽然白天阳光明媚,但早晚温差较大。空气质量评分为良,空气质量指数为97,相对较好。, FinishReason = stop }, Usage = ChatTokenUsage { OutputTokens = 126, InputTokens = 5 } }

接着,自己写个 .NET 控制台程序体验一下

准备控制台项目

dotnet new console -n dashscop-sample
cd  dashscop-sample
dotnet add package Sdcb.DashScope
dotnet user-secrets init
dotnet user-secrets set DashScopeApiKey sk-xxxxxxxxxxx

添加 FrameworkReference

<ItemGroup>
  <FrameworkReference Include="Microsoft.AspNetCore.App"></FrameworkReference>
</ItemGroup>

在 Progam.cs 写实现代码,使用
qwen-max
通义千问千亿级别大规模回答一个简单的问题
博客园是什么网站
,看看效果

using Microsoft.Extensions.Configuration;
using Sdcb.DashScope;
using Sdcb.DashScope.TextGeneration;

IConfiguration config = new ConfigurationBuilder()
    .AddUserSecrets<Program>()
    .Build();

string apiKey = config.GetValue<string>("DashScopeApiKey") ?? "";

using DashScopeClient client = new(apiKey);

var result = await client.TextGeneration.Chat(
    "qwen-max",
    [ChatMessage.FromUser("博客园是什么网站")]);

Console.WriteLine(result.Output.Text);

public partial class Program
{ }

注:Sdcb.DashScope 贴心地提供了
ChatMessage.FromUser
方法

运行代码看看千亿级通义千问的回答(运行3次)

第1次的回答:

博客园是一个面向软件开发者的技术写作与分享平台,成立于2004年。它主要为程序员提供一个记录和分享技术知识、经验和见解的空间,内容涵盖编程语言、软件架构、算法、数据库、操作系统等多个领域。博客园在中国开发者社区中具有较高的知名度和影响力,吸引了大量IT从业人员和技术爱好者在此交流和学习。

第2次的回答:

博客园(www.cnblogs.com)是一个面向软件开发者的中文技术社区网站,创建于2004年。该网站主要提供博客空间服务,用户以软件开发者、IT从业人员以及对相关技术感兴趣的人员为主,他们在这里发表、分享和交流编程技术、架构设计、软件开发心得等各种专业技术文章。博客园在中国IT技术圈内具有较高的知名度和影响力。

第3次的回答:

博客园是一个专注于技术分享的中文博客平台,创建于2004年。该网站主要面向软件开发人员、IT专业人士以及对技术和知识分享感兴趣的人群,提供了一个发表和阅读原创技术文章的空间。用户可以在博客园上撰写和发布有关编程、系统架构、数据库、人工智能、云计算等各种IT技术领域的文章和心得,并与其他用户进行交流和讨论。

在博客园,许多知名的技术专家和行业大牛都有自己的博客空间,通过分享高质量的技术内容,博客园在IT技术领域内具有较高的影响力和知名度。

qwen-max
的回答果然比
Qwen-7B-Chat
强很多。

感谢
ZHOU Jie
给 .NET 社区带来的
Sdcb.DashScope

由于两个月的奋战,导致很久没更新了。就是上回老周说的那个产线和机械手搬货的项目,好不容易等到工厂放假了,我就偷偷乐了。当然也过年了,老周先给大伙伴们拜年了,P话不多讲,就祝大家身体健康、生活愉快。其实生活和健康是密不可分的,想活得好,就得健康。包括身体健康、思想健康、心理健康、精神健康。不能以为我无病无痛就很健康,你起码要全方位健康。

不管你的工作是什么,忙或者不忙,报酬高或低,但是,人,总得活,总得过日子。咱们最好多给自己点福利,多整点可以自娱自乐的东西,这就是生活。下棋、打游戏、绘画、书法、钓鱼、飙车、唢呐……不管玩点啥,只要积极正向的就好,可以大大降低得抑郁症、高血压的机率;可以减少70%无意义的烦恼;可以降低跳楼风险;在这个礼崩乐坏的社会环境中,可以抵御精神污染……总之,益处是大大的有。

然后老周再说一件事,一月份的时候常去工厂调试,也认识了机械臂厂商派的技术支持——吴大工程师。由于工厂所处地段非常繁华,因此每次出差,午饭只能在附近一家四川小吃店解决。毕竟这方圆百十里也仅此一家。不去那里吃饭除非自带面包蹲马路边啃,工厂不供食也不供午休场所。刚开始几次出差还真的像个傻子似的蹲马路边午休。后来去多了,直接钻进工厂的会议室睡午觉。

有一天吃午饭时,吴老师说:你说什么样的人编程水平最高?

我直接从潜意识深处回答他:我做一个排序,仅供参考。编程水平从高到低排行:

1、黑客。虽然大家都说黑客一代不如一代,但目前来说,这群人还是最强的;

2、纯粹技术爱好者;

3、著名开源项目贡献者。毕竟拿不出手的代码也不好意思与人分享;

4、做过许多项目的一线开发者。我强调的项目数量多,而不是长年只维护一个项目的。只有数量多你学到的才多;

5、社区贡献较多者,这个和3差不多。不过,老周认为的社区贡献就是不仅提供代码,还提供文档、思路、技巧等;

6、刚入坑但基础较好的开发者;

7、培训机构的吹牛专业户;

8、大学老师/教授;

9、短视频平台上的砖家、成宫人士;

10、刚学会写 main 函数的小朋友。

==========================================================================================================

下面进入主题,咱们今天聊聊 IChangeToken。它的主要功能是提供更改通知。比如你的配置源发生改变了,要通知配置的使用者重新加载。你可能会疑惑,这货跟使用事件有啥区别?这个老周也不好下结论,应该是为异步代码准备的吧。

下面是 IChangeToken 接口的成员:

bool HasChanged { get; }bool ActiveChangeCallbacks { get; }
IDisposable RegisterChangeCallback(Action
<object?> callback, object? state);

这个 Change Token 思路很清奇,实际功能类似事件,就是更改通知。咱们可以了解一下其原理,但如果你觉得太绕,不想了解也没关系的。在自定义配置源时,咱们是不需要自己写 Change Token 的,框架已有现成的。我们只要知道要触发更改通知时调用相关成员就行。

如果你想看源码的话,老周可以告你哪些文件(github 项目是 dotnet\runtime):

1、runtime-main\src\libraries\Common\src\Extensions\ChangeCallbackRegistrar.cs:这个主要是 UnsafeRegisterChangeCallback 方法,用于注册回调委托;

2、runtime-main\src\libraries\Microsoft.Extensions.Primitives\src\ChangeToken.cs:这个类主要是提供静态的辅助方法,用于注册回调委托。它的好处是可以循环——注册回调后,触发后委托被调用;调用完又自动重新注册,使得 Change Token 可以多次触发;

3、runtime-main\src\libraries\Microsoft.Extensions.Primitives\src\CancellationChangeToken.cs:这个类是真正实现 IChangeToken 接口的;

4、runtime-main\src\libraries\Microsoft.Extensions.Configuration\src\ConfigurationReloadToken.cs:这个也是实现 IChangeToken 接口,而且它才是咱们今天的主角,该类就是为重新加载配置数据而提供的。调用它的 OnReload 方法可以触发更改通知。

看了上面这些,你可能更疑惑了。啥原理?为啥 Token 只能触发一次?为何要重新注册回调?

咱们用一个简单例子演练一下。

static void Main(string[] args)
{
CancellationTokenSource cs
= new();//这里获取token CancellationToken token =cs.Token;//token 可以注册回调 token.Register(() =>{
Console.WriteLine(
"你按下了【K】键");
});
//启动一个新task Task myTask = Task.Run(() =>{//等待输入,如果按下【K】键,就让CancellationTokenSource取消 ConsoleKeyInfo keyInfo;while(true)
{
keyInfo
= Console.ReadKey(true);if(keyInfo.Key ==ConsoleKey.K)
{
//取消 cs.Cancel();break;
}
}
});
//主线程等待任务完成 Task.WaitAll(myTask);
}

CancellationTokenSource 类表示一个取消任务的标记,访问它的 Token 属性可以获得一个 CancellationToken 结构体实例,可以检索它的 IsCancellationRequested 属性以明确是否有取消请求(有则true,无则false)。

还有更重要的,CancellationToken 结构体的 Register 方法可以注册一个委托作为回调,当收到取消请求后会触发这个委托。对的,这个就是 Change Token 灵魂所在了。一旦回调被触发后,CancellationTokenSource 就处于取消状态了,你无法再次触发,除非重置或重新实例化。这就是回调只能触发一次的原因。

下面,咱们完成一个简单的演示——用数据库做配置源。在 SQL Server 里面随便建个数据库,然后添加一个表,名为 tb_configdata。它有四个字段:

CREATE TABLE [dbo].[tb_configdata]([ID] [int] NOT NULL,[config_key] [nvarchar](15) NOT NULL,[config_value] [nvarchar](30) NOT NULL,[remark] [nvarchar](50) NULL,CONSTRAINT [PK_tb_configdata] PRIMARY KEY CLUSTERED([ID] ASC,[config_key] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY])ON [PRIMARY]
GO

ID和config_key设为主键,config_value 是配置的值,remark 是备注。备注字段其实可以不用,但实际应用的时候,可以用来给配置项写点注释。

然后,在程序里面咱们用到 EF Core,故要先生成与表对应的实体类。这里老周就不用工具了,直接手写更有效率。

//实体类
public classMyConfigData
{
public int ID { get; set; }public string ConfigKey { get; set; } = string.Empty;public string ConfigValue { get; set; } = string.Empty;public string? Remark { get; set; }
}
//数据库上下文对象 public classDemoConfigDBContext : DbContext
{
public DbSet<MyConfigData> ConfigData => Set<MyConfigData>();protected override voidOnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(
"Data Source=DEV-PC\\SQLTEST;Initial Catalog=Demo;Integrated Security=True;Connect Timeout=30;Encrypt=True;Trust Server Certificate=True;Application Intent=ReadWrite;Multi Subnet Failover=False");
}
protected override voidOnModelCreating(ModelBuilder modelbd)
{
modelbd.Entity
<MyConfigData>()
.ToTable(
"tb_configdata")
.HasKey(c
=> new{ c.ID, c.ConfigKey });
modelbd.Entity
<MyConfigData>()
.Property(c
=>c.ConfigKey)
.HasColumnName(
"config_key");
modelbd.Entity
<MyConfigData>()
.Property(c
=>c.ConfigValue)
.HasColumnName(
"config_value");
modelbd.Entity
<MyConfigData>()
.Property(c
=>c.Remark)
.HasColumnName(
"remark");
}
}

上述代码的情况特殊,实体类的名称和成员名称与数据表并不一致,所以在重写 OnModelCreating 方法时,需要进行映射。

1、ToTable("tb_configdata") 告诉 EF 实体类对应的数据表是 tb_configdata;

2、HasKey(c => new { c.ID, c.ConfigKey }):表明该实体有两个主键——ID和ConfigKey。这里指定的是实体类的属性,而不是数据表的字段名,因为后面咱们会进行列映射;

3、HasColumnName("config_key"):告诉 EF,实体的 ConfigKey 属性对应的是数据表中 config_key。后面的几个属性的道理一样,都是列映射。

做映射就类似于填坑,如果你不想挖坑,那就直接让实体类名与表名一样,属性名与表字段(列)一样,这样就省事多了。不过,在实际使用中真没有那么美好。很多时候数据库是小李负责的,人家早就建好了,存储过程都写了几万个了。后面前台程序是老张来开发,对老张来说,要么把实体的命名与数据库的一致,要么就做一下映射。多数情况下是要映射的,毕竟很多时候数据库对象的命名都比较奇葩。尤其有上千个表的时候,为了看得顺眼,很多人喜欢这样给数据表命名:ta_XXX、ta_YYY、tb_ZZZ、tc_FFF、tx_PPP、ty_EEE、tz_WWW。还有这样命名的:m1_Report、m2_ReportDetails…… m105_TMD、m106_WNM、m107_DOUBI。

这种命名用在实体类上面确实很不优雅,所以映射就很必要了。

此处咱们不用直接实现 IConfigurationProvider 接口,而是从 ConfigurationProvider 类派生就行了。自定义配置源的东东老周以前写过,只是当时没有实现更改通知。

public classMyConfigurationProvider : ConfigurationProvider, IDisposable
{
privateSystem.Threading.Timer theTimer;publicMyConfigurationProvider()
{
theTimer
= new Timer(OnTimer, null, 100, 10000);
}
private void OnTimer(object?state)
{
//先调用Load方法,然后用OnReload触发更新通知 Load();
OnReload();
}
public voidDispose()
{
theTimer
?.Change(0, 0);
theTimer
?.Dispose();
}
public override voidLoad()
{
//先读取一下 using DemoConfigDBContext dbctx = new();//如果无数据,先初始化 if(dbctx.ConfigData.Count() == 0)
{
InitData(dbctx.ConfigData);
}
//加载数据 Data = dbctx.ConfigData.ToDictionary(k => k.ConfigKey, k => (string?)k.ConfigValue);//本地函数 void InitData(DbSet<MyConfigData> set)
{
int _id = 1;set.Add(new()
{
ID
=_id,
ConfigKey
= "page_size",
ConfigValue
= "25"});
_id
+= 1;set.Add(new()
{
ID
=_id,
ConfigKey
= "format",
ConfigValue
= "xml"});
_id
+= 1;set.Add(new()
{
ID
=_id,
ConfigKey
= "limited_height",
ConfigValue
= "1450"});
_id
+= 1;set.Add(new()
{
ID
=_id,
ConfigKey
= "msg_lead",
ConfigValue
= "TDXA_"});//保存数据 dbctx.SaveChanges();
}
}

}

由于老周不知道怎么监控数据库更新,最简单的办法就是用定时器循环检查。重点是重写 Load 方法,完成加载配置的逻辑。Load 方法覆写后不需要调用 base 的 Load 方法,因为基类的方法是空的,调用了也没毛用。

在 Timer 对象调用的方法(OnTimer)中,先调用 Load 方法,再调用 OnReload 方法。这样就可以在加载数据后触发更改通知。

然后实现 IConfigurationSource 接口,提供 MyConfigurationProvider 实例。

public classMyConfigurationSource : IConfigurationSource
{
publicIConfigurationProvider Build(IConfigurationBuilder builder)
{
return newMyConfigurationProvider();
}
}

默认的配置源有JSON文件、命令行、环境变量等,为了排除干扰,便于查看效果,在 Main 方法中咱们先把配置源列表清空,再添加咱们自定义的配置源。

var builder =WebApplication.CreateBuilder(args);//清空配置源
builder.Configuration.Sources.Clear();//添加配置源到Sources
builder.Configuration.Sources.Add(newMyConfigurationSource());var app = builder.Build();

最后,可以做个简单测试,直接注入 Mini-API 中读取配置。

app.MapGet("/", (IConfiguration config) =>{
StringBuilder bd
= new();foreach(var kp inconfig.AsEnumerable())
{
bd.AppendLine($
"{kp.Key} = {kp.Value}");
}
returnbd.ToString();
});

运行效果如下:

这时候咱们到数据库里把配置值改一下。

updatetb_configdataset config_value = N'55'
    where config_key = N'page_size'

updatetb_configdataset config_value = N'1900'
    where config_key = N'limited_height'

接着回应用程序的页面,刷新一下,配置值已更新。

这里你可能会有个疑问:连接字符串硬编码了不太好,要不写在配置文件中,可是,写在JSON文件中咱们怎么获取呢?毕竟 ConfigurationProvider 不使用依赖注入。

IConfigurationSource 不是有个 Build 方法吗?Build 方法不是有个参数是 IConfigurationBuilder 吗?用它,用它,狠狠地用它。

public classMyConfigurationSource : IConfigurationSource
{
publicIConfigurationProvider Build(IConfigurationBuilder builder)
{
//此处可以临时build一个配置树,就能获取到JSON配置文件里面的连接字符串了 var config =builder.Build();string connStr = config["ConnectionStrings:test"]!;return newMyConfigurationProvider(connStr);
}
}

前面定义的一些类也要改一下。

先是 MyConfigurationProvider 的构造函数。

public classMyConfigurationProvider : ConfigurationProvider, IDisposable
{
privateSystem.Threading.Timer theTimer;private stringconnectString;public MyConfigurationProvider(stringcnnstr)
{
connectString
=cnnstr;
……
}

……
}

DemoConfigDBContext 类是连接字符串的最终使用者,所以也要改一下。

public classDemoConfigDBContext : DbContext
{
private stringconnStr;public DemoConfigDBContext(stringconnectionString)
{
connStr
=connectionString;
}

……
protected override voidOnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(connStr);
}
}

在appsettings.json 文件中配置连接字符串。

{"Logging": {
……
},
"AllowedHosts": "*","ConnectionStrings": {"test": "Data Source=DEV-PC\\SQLTEST;Initial Catalog=Demo;Integrated Security=True;Connect Timeout=30;Encrypt=True;Trust Server Certificate=True;Application Intent=ReadWrite;Multi Subnet Failover=False"}
}

回到 Main 方法,咱们还得加上 JSON 配置源。

var builder =WebApplication.CreateBuilder(args);//清空配置源
builder.Configuration.Sources.Clear();//添加配置源到Sources
builder.Configuration.AddJsonFile("appsettings.json");
builder.Configuration.Sources.Add(
newMyConfigurationSource());var app = builder.Build();

其他的不变。

-----------------------------------------------------------------------------------------------------

接下来,咱们弄个一对多的例子。逻辑是这样的:启动程序显示主窗口,接着创建五个子窗口。主窗口上有个大大的按钮,点击后,五个子窗口会收到通知。大概就这个样子:

子窗口名为 TextForm,代码如下:

internal classTestForm : Form
{
privateIDisposable _changeTokenReg;privateTextBox _txtMsg;public TestForm(Func<IChangeToken?>getToken)
{
//初始化子级控件 _txtMsg = new()
{
Dock
=DockStyle.Fill,
Margin
= new Padding(5),
Multiline
= true,
ScrollBars
=ScrollBars.Vertical
};
Controls.Add(_txtMsg);

_changeTokenReg
=ChangeToken.OnChange(getToken, OnCallback);
}
//回调方法 voidOnCallback()
{
DateTime curtime
=DateTime.Now;string str = $"{curtime.ToLongTimeString()} 新年快乐\r\n";
_txtMsg.BeginInvoke(()
=>{
_txtMsg.AppendText(str);
});
}
protected override void Dispose(booldisposing)
{
//释放对象 if(disposing)
{
_changeTokenReg
?.Dispose();
}
base.Dispose(disposing);
}
}

窗口上只放了一个文本框。上面代码中,使用了 ChangeToken.OnChange 静态方法,为 Change Token 注册回调委托,本例中回调委托绑定的是 OnCallback 方法,也就是说:当 Change Token 触发后会在文本框中追加文本。OnChange 静态方法有两个重载:

//咱们示例中用的是这个版本
static IDisposable OnChange(Func<IChangeToken?>changeTokenProducer, Action changeTokenConsumer);//这是另一个重载
static IDisposable OnChange<TState>(Func<IChangeToken?> changeTokenProducer, Action<TState> changeTokenConsumer, TState state);

上述例子用的是第一个,其实里面调用的也是第二个重载,只是把咱们传递的 OnCallback 方法当作 TState 传进去了。

请大伙伴暂时记住 changeTokenProducer 和 changeTokenConsumer 这两参数。changeTokenProducer 也是一个委托,返回 IChangeToken。用的时候一定要注意,每次触发之前,Change Token 要先创建新实例。注意是先创建新实例再触发,否则会导致无限。尽管内部会判断 HasChanged 属性,可问题是这个判断是在注册回调之后的。这个是跟 Change Token 的清奇逻辑有关,咱们看看 OnChage 的源代码就明白了。

 public static IDisposable OnChange<TState>(Func<IChangeToken?> changeTokenProducer, Action<TState>changeTokenConsumer, TState state)
{
if (changeTokenProducer is null)
{
ThrowHelper.ThrowArgumentNullException(ExceptionArgument.changeTokenProducer);
}
if (changeTokenConsumer is null)
{
ThrowHelper.ThrowArgumentNullException(ExceptionArgument.changeTokenConsumer);
}
return new ChangeTokenRegistration<TState>(changeTokenProducer, changeTokenConsumer, state);
}

简单来说,就是返回一个 ChangeTokenRegistration 实例,这是个私有类,咱们是访问不到的,以 IDisposable 接口公开。其中,它有两个方法是递归调用的:

private voidOnChangeTokenFired()
{
//The order here is important. We need to take the token and then apply our changes BEFORE //registering. This prevents us from possible having two change updates to process concurrently.// //If the token changes after we take the token, then we'll process the update immediately upon//registering the callback. IChangeToken? token =_changeTokenProducer(); try{
_changeTokenConsumer(_state);
}
finally{//We always want to ensure the callback is registered RegisterChangeTokenCallback(token);
}
}
private void RegisterChangeTokenCallback(IChangeToken?token)
{
if (token is null)
{
return;
}
IDisposable registraton
= token.RegisterChangeCallback(s => ((ChangeTokenRegistration<TState>?)s)!.OnChangeTokenFired(), this);if (token.HasChanged &&token.ActiveChangeCallbacks)
{
registraton
?.Dispose();return;
}
SetDisposable(registraton);
}

在 ChangeTokenRegistration 类的构造函数中,先调用 RegisterChangeTokenCallback 方法,开始了整个递归套娃的过程。在 RegisterChangeTokenCallback 方法中,为 token 注册的回调就是调用 OnChangeTokenFired 方法。

而 OnChangeTokenFired 方法中,是
先获取新的 Change Token,再触发旧 token
。最后,又调用 RegisterChangeTokenCallback 方法,实现了无限套娃的逻辑。

因此,咱们在用的时候,必须先创建新的 Change Token 实例,然后再调用 RegisterChangeTokenCallback 实例的 Cancel 方法。不然这无限套娃会一直进行到栈溢出,除非你提前把 ChangeTokenRegistration 实例 Dispose 掉(由 OnChange 静态方法返回)。可是那样的话,你就不能多次接收更改了。

下面就是主窗口部分,也是最危险的部分——必须按照咱们上面分析的顺序进行,不然会 Stack Overflow。

public partial classForm1 : Form
{
privateCancellationTokenSource _cancelTkSource; privateCancellationChangeToken _changeToken; publicForm1()
{
InitializeComponent();
_cancelTkSource
= newCancellationTokenSource();
_changeToken
= new(_cancelTkSource.Token);
button1.Click
+=OnButton1Click;
button2.Click
+=OnButton2Click;
}
private void OnButton2Click(object?sender, EventArgs e)
{
for(int t= 0; t < 5; t++)
{
TestForm frm
= new(GetChangeToken);
frm.Text
= "窗口" + (t + 1);
frm.Size
= new Size(300, 240);
frm.StartPosition
=FormStartPosition.CenterParent;
frm.Show(
this);
}
}
//这个地方就是触发token了,所以要先换上新的实例 private void OnButton1Click(object?sender, EventArgs e)
{
//先创建新的实例 var oldsource = Interlocked.Exchange(ref _cancelTkSource, newCancellationTokenSource());
Interlocked.Exchange(
ref _changeToken, newCancellationChangeToken(_cancelTkSource.Token));//只要CancellationTokenSource一取消,其他客户端会收到通知 oldsource.Cancel();
}
//这个方法传递给 TestForm 构造函数,再传给 OnChange 静态方法 public IChangeToken?GetChangeToken()
{
return_changeToken;
}
}

按钮1的单击事件处理方法就是触发点,所以,CancellationTokenSource、CancellationChangeToken 要先换成新的实例,然后再用旧的实例去 Cancel。这里用 Interlocked 类会好一些,毕竟要考虑异步的情况,虽然咱这里都是在UI线程上传递的,但还是遵守这个习惯好一些。

这样处理就能避免栈溢出了。运行后,先打开五个子窗口(多点击一次就能创建十个子窗口)。接着点击大大按钮,五个子窗口就能收到通知了。

好了,这次就聊到这儿了。

原文 | Máňa,Natalia Kondratyeva

翻译 | 郑子铭

随着新的
.NET 版本的发布
,发布有关网络空间中新的有趣变化的博客文章已成为一种传统。今年,我们希望引入
HTTP
空间的变化、新添加的
指标
、新的
HttpClientFactory
API 等。

HTTP协议

指标

.NET 8 使用 .NET 6 中引入的
System.Diagnostics.Metrics API
将内置 HTTP 指标添加到 ASP.NET Core 和 HttpClient。指标 API 和新内置指标的语义都是在与 OpenTelemetry 密切合作,确保新指标符合标准,并与
Prometheus

Grafana
等流行工具良好配合。

System.Diagnostics.Metrics API 引入了许多 EventCounters 所缺少的新功能。新的内置指标广泛利用了这些功能,从而通过更简单、更优雅的仪器集实现了更广泛的功能。举几个例子:

  • 直方图
    使我们能够报告持续时间,例如。请求持续时间 (
    http.client.request.duration
    ) 或连接持续时间 (
    http.client.connection.duration
    )。这些是没有 EventCounter 对应项的新指标。
  • 多维性
    允许我们将标签(又名属性或标签)附加到测量值上,这意味着我们可以报告诸如 server.address (标识
    URI 来源
    )或 error.type (描述请求失败时的错误原因)之类的信息测量值。多维还可以实现简化:报告打开的 HTTP 连接数 SocketsHttpHandler 使用 3 个 EventCounters:
    http11-connections-current-total、http20-connections-current-total 和 http30-connections-current-total
    ,而 Metrics 相当于这些counters 是一个单一的工具,
    http.client.open_connections
    ,其中 HTTP 版本是使用 network.protocol.version 标签报告的。
  • 为了帮助内置标签不足以对传出 HTTP 请求进行分类的用例,http.client.request.duration 指标支持注入用户定义的标签。这称为
    浓缩
  • IMeterFactory 集成
    可以隔离用于发出 HTTP 指标的
    Meter
    实例,从而更轻松地编写针对内置测量运行验证的测试,并实现此类测试的并行执行。
  • 虽然这并不是特定于内置网络指标,但值得一提的是 System.Diagnostics.Metrics 中的集合 API 也更高级:它们是强类型的且性能更高,并允许多个同时侦听器和侦听器访问未聚合的测量结果。

这些优势共同带来了更好、更丰富的指标,这些指标可以通过 Prometheus 等第三方工具更有效地收集。得益于
PromQL(Prometheus 查询语言)
的灵活性,它允许针对从 .NET 网络堆栈收集的多维指标创建复杂的查询,用户现在可以深入了解 HttpClient 和 SocketsHttpHandler 实例的状态和运行状况,其级别如下:以前是不可能的。

不利的一面是,我们应该提到,.NET 8 中只有 System.Net.Http 和 System.Net.NameResolution 组件使用 System.Diagnostics.Metrics 进行检测,这意味着您仍然需要使用 EventCounters 从较低层提取计数器堆栈的级别,例如 System.Net.Sockets。虽然仍然支持以前版本中存在的所有内置 EventCounters,但 .NET 团队预计不会对 EventCounters 进行大量新投资,并且在未来版本中将使用 System.Diagnostics.Metrics 添加新的内置检测。

有关使用内置 HTTP 指标的更多信息,请阅读我们
有关 .NET 中的网络指标
的教程。它包括有关使用 Prometheus 和 Grafana 进行收集和报告的示例,还演示了如何丰富和测试内置 HTTP 指标。有关内置工具的完整列表,请参阅
System.Net 指标
的文档。如果您对服务器端更感兴趣,请阅读有关
ASP.NET Core 指标
的文档。

扩展遥测

除了新指标之外,
.NET 5
中引入的现有基于 EventSource 的遥测事件还增加了有关 HTTP 连接的更多信息 (
dotnet/runtime#88853
):

- ConnectionEstablished(byte versionMajor, byte versionMinor)
+ ConnectionEstablished(byte versionMajor, byte versionMinor, long connectionId, string scheme, string host, int port, string? remoteAddress)

- ConnectionClosed(byte versionMajor, byte versionMinor)
+ ConnectionClosed(byte versionMajor, byte versionMinor, long connectionId)

- RequestHeadersStart()
+ RequestHeadersStart(long connectionId)

现在,当建立新连接时,该事件会记录其连接 ID 及其方案、端口和对等 IP 地址。这使得可以通过 RequestHeadersStart 事件将请求和响应与连接关联起来(当请求关联到池连接并开始处理时发生),该事件还记录关联的 ConnectionId。这在用户想要查看为其 HTTP 请求提供服务的服务器的 IP 地址的诊断场景中尤其有价值,这是添加项背后的主要动机 (
dotnet/runtime#63159
)。

事件可以通过多种方式使用,请参阅
.NET 中的网络遥测
– 事件。但为了进程内增强日志记录,可以使用自定义
EventListener
将请求/响应对与连接数据相关联:

using IPLoggingListener ipLoggingListener = new();
using HttpClient client = new();

// Send requests in parallel.
await Parallel.ForAsync(0, 1000, async (i, ct) =>
{
    // Initialize the async local so that it can be populated by "RequestHeadersStart" event handler.
    RequestInfo info = RequestInfo.Current;
    using var response = await client.GetAsync("https://testserver");
    Console.WriteLine($"Response {response.StatusCode} handled by connection {info.ConnectionId}. Remote IP: {info.RemoteAddress}");

    // Process response...
});

internal sealed class RequestInfo
{
    private static readonly AsyncLocal<RequestInfo> _asyncLocal = new();
    public static RequestInfo Current => _asyncLocal.Value ??= new();

    public string? RemoteAddress;
    public long ConnectionId;
}

internal sealed class IPLoggingListener : EventListener
{
    private static readonly ConcurrentDictionary<long, string> s_connection2Endpoint = new ConcurrentDictionary<long, string>();

    // EventId corresponds to [Event(eventId)] attribute argument and the payload indices correspond to the event method argument order.

    // See: https://github.com/dotnet/runtime/blob/a6e4834d53ac591a4b3d4a213a8928ad685f7ad8/src/libraries/System.Net.Http/src/System/Net/Http/HttpTelemetry.cs#L100-L101
    private const int ConnectionEstablished_EventId = 4;
    private const int ConnectionEstablished_ConnectionIdIndex = 2;
    private const int ConnectionEstablished_RemoteAddressIndex = 6;

    // See: https://github.com/dotnet/runtime/blob/a6e4834d53ac591a4b3d4a213a8928ad685f7ad8/src/libraries/System.Net.Http/src/System/Net/Http/HttpTelemetry.cs#L106-L107
    private const int ConnectionClosed_EventId = 5;
    private const int ConnectionClosed_ConnectionIdIndex = 2;

    // See: https://github.com/dotnet/runtime/blob/a6e4834d53ac591a4b3d4a213a8928ad685f7ad8/src/libraries/System.Net.Http/src/System/Net/Http/HttpTelemetry.cs#L118-L119
    private const int RequestHeadersStart_EventId = 7;
    private const int RequestHeadersStart_ConnectionIdIndex = 0;

    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        if (eventSource.Name == "System.Net.Http")
        {
            EnableEvents(eventSource, EventLevel.LogAlways);
        }
    }

    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        ReadOnlyCollection<object?>? payload = eventData.Payload;
        if (payload == null) return;

        switch (eventData.EventId)
        {
            case ConnectionEstablished_EventId:
                // Remember the connection data.
                long connectionId = (long)payload[ConnectionEstablished_ConnectionIdIndex]!;
                string? remoteAddress = (string?)payload[ConnectionEstablished_RemoteAddressIndex];
                if (remoteAddress != null)
                {
                    Console.WriteLine($"Connection {connectionId} established to {remoteAddress}");
                    s_connection2Endpoint.TryAdd(connectionId, remoteAddress);
                }
                break;
            case ConnectionClosed_EventId:
                connectionId = (long)payload[ConnectionClosed_ConnectionIdIndex]!;
                s_connection2Endpoint.TryRemove(connectionId, out _);
                break;
            case RequestHeadersStart_EventId:
                // Populate the async local RequestInfo with data from "ConnectionEstablished" event.
                connectionId = (long)payload[RequestHeadersStart_ConnectionIdIndex]!;
                if (s_connection2Endpoint.TryGetValue(connectionId, out remoteAddress))
                {
                    RequestInfo.Current.RemoteAddress = remoteAddress;
                    RequestInfo.Current.ConnectionId = connectionId;
                }
                break;
        }
    }
}

此外,重定向事件已扩展为包含重定向 URI:

-void Redirect();
+void Redirect(string redirectUri);

HTTP 错误代码

HttpClient 的诊断问题之一是,在发生异常时,不容易以编程方式区分错误的确切根本原因。区分其中许多的唯一方法是解析来自
HttpRequestException
的异常消息。此外,其他 HTTP 实现(例如带有
ERROR_WINHTTP_*
错误代码的 WinHTTP)以数字代码或枚举的形式提供此类功能。因此.NET 8引入了类似的枚举,并在HTTP处理抛出的异常中提供它,它们是:

dotnet/runtime#76644
API 提案中描述了
HttpRequestError
枚举的设计以及如何将其插入 HTTP 异常。

现在,HttpClient 方法的使用者可以更轻松、更可靠地处理特定的内部错误:

using HttpClient httpClient = new();

// Handling problems with the server:
try
{
    using HttpResponseMessage response = await httpClient.GetAsync("https://testserver", HttpCompletionOption.ResponseHeadersRead);
    using Stream responseStream = await response.Content.ReadAsStreamAsync();
    // Process responseStream ...
}
catch (HttpRequestException e) when (e.HttpRequestError == HttpRequestError.NameResolutionError)
{
    Console.WriteLine($"Unknown host: {e}");
    // --> Try different hostname.
}
catch (HttpRequestException e) when (e.HttpRequestError == HttpRequestError.ConnectionError)
{
    Console.WriteLine($"Server unreachable: {e}");
    // --> Try different server.
}
catch (HttpIOException e) when (e.HttpRequestError == HttpRequestError.InvalidResponse)
{
    Console.WriteLine($"Mangled responses: {e}");
    // --> Block list server.
}

// Handling problems with HTTP version selection:
try
{
    using HttpResponseMessage response = await httpClient.SendAsync(new HttpRequestMessage(HttpMethod.Get, "https://testserver")
    {
        Version = HttpVersion.Version20,
        VersionPolicy = HttpVersionPolicy.RequestVersionExact
    }, HttpCompletionOption.ResponseHeadersRead);
    using Stream responseStream = await response.Content.ReadAsStreamAsync();
    // Process responseStream ...
}
catch (HttpRequestException e) when (e.HttpRequestError == HttpRequestError.VersionNegotiationError)
{
    Console.WriteLine($"HTTP version is not supported: {e}");
    // Try with different HTTP version.
}

HTTPS 代理支持

此版本实现的最受欢迎的功能之一是支持 HTTPS 代理 (
dotnet/runtime#36666663
)。现在可以使用代理通过 HTTPS 处理请求,这意味着与代理的连接是安全的。这并没有说明来自代理的请求本身,它仍然可以是 HTTP 或 HTTPS。如果是纯文本 HTTP 请求,与 HTTPS 代理的连接是安全的(通过 HTTPS),然后是从代理到目标的纯文本请求。如果是 HTTPS 请求(代理隧道),打开隧道的初始 CONNECT 请求将通过安全通道 (HTTPS) 发送到代理,然后通过隧道将 HTTPS 请求从代理发送到目的地。

要利用该功能,只需在设置代理时使用 HTTPS 方案即可:

using HttpClient client = new HttpClient(new SocketsHttpHandler()
{
    Proxy = new WebProxy("https://proxy.address:12345")
});

using HttpResponseMessage response = await client.GetAsync("https://httpbin.org/");

HttpClientFactory

.NET 8 扩展了配置
HttpClientFactory
的方式,包括客户端默认设置、自定义日志记录和简化的 SocketsHttpHandler 配置。这些 API 在 Microsoft.Extensions.Http 包中实现,该包可在 NuGet 上获取,并包含对 .NET Standard 2.0 的支持。因此,此功能不仅适用于 .NET 8 上的客户,而且适用于所有版本的 .NET,包括 .NET Framework(唯一的例外是仅适用于 .NET 5+ 的 SocketsHttpHandler 相关 API)。

为所有客户端设置默认值

.NET 8 添加了设置默认配置的功能,该配置将用于 HttpClientFactory (
dotnet/runtime#87914
) 创建的所有 HttpClient。当所有或大多数注册客户端包含相同的配置子集时,这非常有用。

考虑一个定义了两个命名客户端的示例,并且它们的消息处理程序链中都需要 MyAuthHandler。

services.AddHttpClient("consoto", c => c.BaseAddress = new Uri("https://consoto.com/"))
    .AddHttpMessageHandler<MyAuthHandler>();

services.AddHttpClient("github", c => c.BaseAddress = new Uri("https://github.com/"))
    .AddHttpMessageHandler<MyAuthHandler>();

要提取公共部分,您现在可以使用
ConfigureHttpClientDefaults
方法:

services.ConfigureHttpClientDefaults(b => b.AddHttpMessageHandler<MyAuthHandler>());

// both clients will have MyAuthHandler added by default
services.AddHttpClient("consoto", c => c.BaseAddress = new Uri("https://consoto.com/"));
services.AddHttpClient("github", c => c.BaseAddress = new Uri("https://github.com/"));

与 AddHttpClient 一起使用的所有
IHttpClientBuilder
扩展方法也可以在 ConfigureHttpClientDefaults 中使用。

默认配置 (ConfigureHttpClientDefaults) 在客户端特定 (AddHttpClient) 配置之前应用于所有客户端;他们在注册中的相对位置并不重要。配置HttpClientDefaults可以注册多次,在这种情况下,配置将按照注册的顺序一一应用。配置的任何部分都可以在特定于客户端的配置中覆盖或修改,例如,您可以为 HttpClient 对象或主处理程序设置其他设置,删除以前添加的其他处理程序等。

请注意,从 8.0 开始,
ConfigureHttpMessageHandlerBuilder
方法已被弃用。您应该改用
ConfigurePrimaryHttpMessageHandler(Action<HttpMessageHandler,IServiceProvider>)

ConfigureAdditionalHttpMessageHandlers
方法来分别修改先前配置的主处理程序或附加处理程序列表。

// by default, adds User-Agent header, uses HttpClientHandler with UseCookies=false
// as a primary handler, and adds MyAuthHandler to all clients
services.ConfigureHttpClientDefaults(b =>
    b.ConfigureHttpClient(c => c.DefaultRequestHeaders.UserAgent.ParseAdd("HttpClient/8.0"))
     .ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler() { UseCookies = false })
     .AddHttpMessageHandler<MyAuthHandler>());

// HttpClient will have both User-Agent (from defaults) and BaseAddress set
// + client will have UseCookies=false and MyAuthHandler from defaults
services.AddHttpClient("modify-http-client", c => c.BaseAddress = new Uri("https://httpbin.org/"))

// primary handler will have both UseCookies=false (from defaults) and MaxConnectionsPerServer set
// + client will have User-Agent and MyAuthHandler from defaults
services.AddHttpClient("modify-primary-handler")
    .ConfigurePrimaryHandler((h, _) => ((HttpClientHandler)h).MaxConnectionsPerServer = 1);

// MyWrappingHandler will be inserted at the top of the handlers chain
// + client will have User-Agent, UseCookies=false and MyAuthHandler from defaults
services.AddHttpClient("insert-handler-into-chain"))
    .ConfigureAdditionalHttpMessageHandlers((handlers, _) =>
        handlers.Insert(0, new MyWrappingHandler());

// MyAuthHandler (initially from defaults) will be removed from the handler chain
// + client will still have User-Agent and UseCookies=false from defaults
services.AddHttpClient("remove-handler-from-chain"))
    .ConfigureAdditionalHttpMessageHandlers((handlers, _) =>
        handlers.Remove(handlers.Single(h => h is MyAuthHandler)));

原文链接

.NET 8 Networking Improvements

知识共享许可协议

本作品采用
知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议
进行许可。

欢迎转载、使用、重新发布,但务必保留文章署名 郑子铭 (包含链接:
http://www.cnblogs.com/MingsonZheng/
),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。

如有任何疑问,请与我联系 (
MingsonZheng@outlook.com
)

春节之前被
Semantic Kernel
所吸引,开始了解它,学习它。

在写这篇博文之前读了一些英文博文,顺便在这里分享一下:

为了方便学习与体验以及写代码实践 Semantic Kernel,打算自己部署一个对中文友好的开源大模型,于是选择了
通义千问

根据通义千问开源仓库中的 README,经过一番折腾,终于部署成功,详见博文
以容器方式部署通义千问 Qwen

紧接着就是尝试通过 Semantic Kernel 与自己部署的通义千问进行对话,在昨天晚上睡觉前初步尝试成功,通过这篇博文记录一下。

主要面临的问题是 Semantic Kernel 与通义千问之间互不支持(内置支持),Semantic Kernel 目前只内置支持 OpenAI 与 Azure OpenAI。幸运的是,通义千问实现了一个四两拔千斤的巧妙能力——提供了兼容 OpenAI api 的 api,于是这个大问题迎刃而解为一个小问题——如何欺骗 Semantic Kernel 让它在请求 OpenAI api 时改道请求自己部署的通义千问模型服务?

在 Semantic Kernel github issue 的
一个评论
中发现了一个移花接木的巧妙方法——通过
DelegatingHandler
修改 HttpClient 请求的 url。

对应到这里的场景就是修改所请求的 OpenAI api url 中的
scheme

host
,也就是将
https://api.openai.com
替换为
http://localhost:8901
,实现代码如下

class QwenRedirectingHandler() : DelegatingHandler(new HttpClientHandler())
{
    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        request.RequestUri = new UriBuilder(request.RequestUri!) { Scheme = "http", Host = "localhost", Port = 8901 }.Uri;
        return base.SendAsync(request, cancellationToken);
    }
}

移花接木之后本以为初步体验小功告成,却遇到一个小挫折,在用下面的代码发送 prompt 时报错

var prompt = @"博客园是什么网站";
var result = await kernel.InvokePromptAsync(prompt);
Console.WriteLine(result);

错误来自通义千问的响应

{"detail":"Invalid request: Expecting at least one user message."}

后来参考公众号文章
利用阿里通义千问和Semantic Kernel,10分钟搭建知识助手
中的代码解决了

var prompt = @"<message role=""user"">博客园是什么网站</message>";
var summarize = kernel.CreateFunctionFromPrompt(prompt);
var result = kernel.InvokeStreamingAsync(summarize);

await foreach (var item in result)
{
    Console.Write(item.ToString());
}

解决这个问题后,控制台就能看到来自通义千问慢吞吞的吐字回答:

博客园(CNG.cn)是中国最大的IT社区,也是一个专业的程序员学习交流的平台。它提供了一个可以让程序员交流思想、分享经验的环境,并且有多重功能支持用户创建个人博客和参与讨论。

注:这里使用的通义千问模型版本是
Qwen-7B-Chat

到此,初步体验 Semantic Kernel 就小功告成了,下面是完整代码。

using Microsoft.Extensions.DependencyInjection;
using Microsoft.SemanticKernel;

var builder = Kernel.CreateBuilder();
builder.AddOpenAIChatCompletion("gpt-3.5-turbo", "***");
builder.Services.ConfigureHttpClientDefaults(b =>
    b.ConfigurePrimaryHttpMessageHandler(() => new QwenRedirectingHandler()));

var kernel = builder.Build();

var prompt = @"<message role=""user"">博客园是什么网站</message>";
var summarize = kernel.CreateFunctionFromPrompt(prompt);
var result = kernel.InvokeStreamingAsync(summarize);

await foreach (var item in result)
{
    Console.Write(item.ToString());
}

class QwenRedirectingHandler() : DelegatingHandler(new HttpClientHandler())
{
    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        request.RequestUri = new UriBuilder(request.RequestUri!) { Scheme = "http", Host = "localhost", Port = 8901 }.Uri;
        return base.SendAsync(request, cancellationToken);
    }
}

概述

所谓接口幂等性就是:在特定场景下,同一条件的多次接口调用,保证操作只执行一次,如果接口没有保证幂等性,在以下场景就会产生问题

  • 前端重复提交:用户进行注册、创建个人信息等操作,由于网络抖动导致页面没有及时响应,用户认为没有成功而多次点击提交按钮,发生重复提交表单请求
  • 接口超时重试:提供外部系统调用的接口,因为网络抖动等原因执行成功但没能及时响应,外部系统发起重试,导致重复调用
  • 消息重复消费:使用消息中间件时,消费者手动 ack 确认消息被正常消费时,消费者突然断开连接,已经执行的消息会重新放回队列,被其他消费者重新消费


如何实现接口幂等性?

1. 防重 Token 令牌

具体流程如下:

  • 客户端获取 token,服务端将 token 保存在 redis 中,token 需保证全局唯一
  • 之后客户端发起请求时必须携带 token
  • 服务端校验 token,如果成功则执行业务,并删除 redis 中的 token,否则为重复操作,直接返回结果

这种方式需保证同一请求都携带同一 token,比如同一订单的支付操作都使用同一 token 请求。另外,在并发情况下,Redis 查找数据与删除需要保证原子性,可以使用或 Lua 脚本保证

2. 使用 Redis 实现

这种实现方式是基于 redis 的 setnx 命令实现的,作用是如果 key 不存在,将 key 赋值为 value 并返回 1,若 key 已存在,则不做操作并返回 0

具体流程如下:

  • 客户端请求服务端,将能代表这次请求的唯一标识以 setnx 的方式存入 redis,并根据业务设置相应的超时时间
  • 如果设置成功,代表是第一次请求,执行后续业务逻辑
  • 如果设置失败,代表已经执行过请求,直接返回

redis 是单线程的,所以不会有并发问题

3. 加锁实现

具体流程如下:

  • 客户端请求服务端,对能代表这次请求的唯一标识加锁,保证同一时刻同一请求只有一个能被执行
  • 服务端根据唯一标识判断是否第一次请求,比如查询数据库是否已存在该唯一标识的记录,或者该唯一标识对应记录状态是否为【已完成】
  • 如果是第一次请求,执行后续业务逻辑,否则直接返回

4. 幂等表

加锁会影响性能,我们可以建一张幂等表,为能代表这次请求的唯一标识建立唯一约束

具体流程如下:

  • 客户端请求服务端,服务端会将本次请求的信息插入幂等表
  • 因为有唯一约束,如果幂等表中不存在本次请求记录,则插入成功,执行后续业务逻辑,插入失败,则直接返回

使用这种方式,每次请求都会幂等表新建一条记录,为了避免表数据过大,可以定期进行清理,或者使用流水表来代替幂等表。使用插入而不是查询,也能有效避免并发问题