.net 温故知新【14】:Asp.Net Core WebAPI 缓存 - XSpringSun - 博客园

mikel阅读(223)

来源: .net 温故知新【14】:Asp.Net Core WebAPI 缓存 – XSpringSun – 博客园

一、缓存

缓存指在中间层中存储数据的行为,该行为可使后续数据检索更快。 从概念上讲,缓存是一种性能优化策略和设计考虑因素。 缓存可以显著提高应用性能,方法是提高不常更改(或检索成本高)的数据的就绪性。

二、RFC9111

在最新的缓存控制规范文件RFC9111中,详细描述了浏览器缓存和服务器缓存控制的规范,其中有一个最重要的响应报文头Cache-Control

该报文头的设置会影响我们的缓存,包括浏览器端和服务端。

RFC911:https://www.rfc-editor.org/rfc/rfc9111#name-cache-control

image

三、网页端缓存

Cache-Control中,如果设置max-age=10,则表示告诉浏览器缓存10s,而为什么浏览器要认这个表示呢,就是上面我们说的前后端都要根据RFC标准规范去实现,就是硬件的统一插口,不然其他生成出来的就用不了。

那么在ASP.NET Core 中只需要在接口上打上ResponseCacheAttribute并设置max-age的时间即可。

首先建一个ASP.NET Core WebAPI 项目,写一个获取学生的Get接口。

image

namespace WebAPI_Cache.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class CacheController : ControllerBase
    {

        public CacheController()
        {

        }

        [HttpGet]
        public ActionResult<Student> GetStudent()
        {

            return new Student()
            {
                Id = 1,
                Name = "Test",
                Age = Random.Shared.Next(0, 100),
            };
        }
    }
}
namespace WebAPI_Cache.Model
{
    public class Student
    {
        public int Id { get; set; }
        public string? Name { get; set; }
        public int Age { get; set; }
    }
}

在接口中我返回Studentage为1-100的随机数。启动项目测试,短时间内两次调用返回的age不一样

第一次age:

image

第二次age:

image

当我在接口方法打上[ResponseCache(Duration = 10)],再次调用接口返回的信息可以看到已经有了cache-control: public,max-age=10的Header。

image

并且我在10秒内的请求,只有第一次请求过服务器,其他都是从缓存中取的,查看edge浏览器网络访问如下:

image

四、服务器缓存

网页端缓存是放在浏览器端的,对于单点请求会有用,但是如果是多个不同前端请求呢。这个时候我们可以将缓存放置在后端服务中,在ASP.NET Core 中配置响应缓存中间件。

在 Program.cs中,将响应缓存中间件服务 AddResponseCaching 添加到服务集合,并配置应用,如果使用 CORS 中间件时,必须在 UseResponseCaching 之前调用 UseCors。

如果header包含 Authorization,Set-Cookie 标头,也不会缓存,因为这些用户信息缓存会引起数据混乱。

image

然后对于我们需要服务器缓存的接口打上ResponseCache属性,和设置浏览器缓存一样,还有其他参数可设置。我们通过两个进程来测试,一个用浏览器swagger,一个用postman,可以看到两个请求的age都是等于18的。所以可以确定服务器端确实存在缓存。

image

但是在用postman测试的时候记得在settings里面把Send no-cache header勾掉,如果不去掉,发送的时候就会在请求头里面包含Cache-Control:no-cache,这样服务端即便有缓存也不会使用缓存。

image

对于浏览器端相当于禁用缓存,如果禁用了缓存,发送的请求头也会带上Cache-Control:no-cache,服务端看到no-cache 后便不会再使用缓存进行响应。

而这个约定就是RFC9111的规范,所以这个后端缓存策略比较鸡肋,如果用户禁用缓存就没用了,因此我们还可以使用内存缓存。

五、内存缓存

内存缓存基于 IMemoryCache。 IMemoryCache 表示存储在 Web 服务器内存中的缓存。

  • 首先Nuget安装包
Install-Package Microsoft.Extensions.Caching.Memory
  • 在Program.cs中添加依赖
builder.Services.AddMemoryCache();
  • 缓存数据
    我添加一个Post方法模拟id查询Student

image

这样我就将数据缓存到了内存,可以设置缓存的绝对过期时间,也可以设置滑动过期,稍后我们会看到过期策略的使用。

六、缓存击穿

缓存击穿是指热点key在某个时间点过期的时候,而恰好在这个时间点对这个Key有大量的并发请求过来,或者是查询了不存在的数据,缓存里面没有,从而大量的请求打到数据库上形成数据库压力。

上面内存缓存中的写法我们可以看到,如果查询缓存等于null就会再去查询数据(我这里只是模拟,没有去写真的数据库查询),如果这样暴力请求攻击就会有问题。

对于这个问题我们可以使用ImemoryCacheGetOrCreate方法,当然它还有异步方式。通过该方法传入缓存的key和func 委托方法返回值来进行查询并缓存,如果没查询到返回的null也会存储在缓存中,防止恶意查询不存在的数据。

        [HttpPost]
        public ActionResult<Student> GetStudent2(int id)
        {
            //查询并创建缓存
            var student = _memoryCache.GetOrCreate("student_" + id, t =>
            {
                t.AbsoluteExpiration = DateTimeOffset.Now.AddSeconds(20);
                //模拟只有id=1有数据
                if (id == 1)
                {
                    return new Student()
                    {
                        Id = 1,
                        Name = "Test",
                        Age = Random.Shared.Next(0, 100),
                    };
                }
                else
                {
                    //其他的返回空,但是空值也会缓存,比如查询 id=2,id=3 都会缓存
                    return null;
                }

            });
            if (student == null)
            {
                return NotFound("未找到");
            }
            else
            {
                return student;
            }
        }

七、缓存雪崩

缓存雪崩是指缓存中数据大批量到过期时间,导致所有请求都会去查数据库,而查询数据量巨大,引起数据库压力过大甚至down机。

对于雪崩情况我们对缓存的策略主要是设置过期时间,部分不重要的站点,比如新闻网站我们将绝对过期时间AbsoluteExpiration设置的久一点。

对于要一定灵活性,能在请求不频繁的时候进行失效以更新数据的,我们可以用滑动过期时间,就是如果频繁请求就一值滑动过期时间。

当然为了避免滑动时间一直不过期,还可以两种方式混合使用。上面的例子,我们设置绝对过期时间是20秒,我们将滑动过期设置5秒,在5秒内有持续访问就一直续命,直到20秒绝对过期。

那么如果没人访问,在5秒后就过期了,这样数据下次访问也能及时查询最新数据。

image

八、分布式缓存

有了上面的缓存方案,对付一些小的简单业务系统完全够用了,但是如果你是分布式部署服务,那么像内存缓存访问的数据就是单个服务器的缓存。

你可能需要多个服务器的请求之间保持一致、在进行服务器重启和应用部署后仍然有效、不使用本地内存等情况。

这个时候我们可以使用第三方缓存,比如memecache,Redis等。Asp.Net Core 使用 IDistributedCache 接口与缓存进行交互。

  • NuGet安装包
Install-Package Microsoft.Extensions.Caching.StackExchangeRedis
  • 在 Program.cs 中注册 IDistributedCache 实现
    image

Configuration: 为连接配置。
InstanceName: 为存储键前缀。

编写测试方法GetStuden3

image

IDistributedCache 接受字符串键并以 byte[] 数组的形式添加或检索缓存项,所以数据是以byte[]形式访问,但是扩展了一个string类型的方法可以进行使用,我这里用字符串进行操作。

以上这些就是关于asp.net core 当中使用缓存的重要点和基础使用方法,详细参数和文档可参看官方文档:ASP.NET Core 中的缓存概述

.net 温故知新【13】:Asp.Net Core WebAPI 使用依赖注入DI - XSpringSun - 博客园

mikel阅读(215)

来源: .net 温故知新【13】:Asp.Net Core WebAPI 使用依赖注入DI – XSpringSun – 博客园

一、使用DI注入

在之前的文章中已经讲过DI的概念(.net 温故知新:【7】IOC控制反转,DI依赖注入),基于控制台程序演示了DI依赖注入的使用,基于Microsoft.Extensions.DependencyInjection完成。那在WebAPI中如何使用依赖注入呢?

首先新建一个WebAPI项目WebAPI_DI,框架.net 7,其实 webapi 项目也是控制台应用程序,只是在ASP.NET Core webapi框架中很多基础工作已经帮我们封装配置好了。

项目新建完成后在Program.cs 中自动生成如下代码:

namespace WebAPI_DI
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            // Add services to the container.

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();

            app.UseAuthorization();


            app.MapControllers();

            app.Run();
        }
    }
}

builder.Services 则是帮我已经创建好的IServiceCollection 对象。

我们再新建一个测试类 DITestClass:

    public class DITestClass
    {
        public int Add(int i, int n)
        {
            return i + n;
        }
    }

然后我们在builder.Services中进行注册

image

最后我们在默认的WeatherForecastController控制器里面加一个post方法,并用构造函数注入的方式将DITestClass注入进去。

image

swagger中调用测试:

image

二、[FromService] 注入

FromServicesAttribute 允许将服务直接注入到操作方法,而无需使用构造函数注入。
改属性的作用主要针对我们在依赖注入初始化对象(该对象初始化很耗时),这个时候不管请求的api方法有没有用到该对象都会等待很长时间。
所以使用FromService让接口在请求的时候再注入,从而不影响其他接口

image

三、多层架构注入

在多层架构中我们如果引用了其他项目,要使用其他项目中的类,那么要在主项目中进行DI注入,这样相当于所有其他模块或者其他人写的项目都需要主项目来维护注入,比如:

新建一个ClassLibrary1项目,Class1类,方法Sub:

image

我们在web项目里面引用ClassLibrary1项目,如果要使用Class1类就需要在 Programe.cs里面注册

builder.Services.AddScoped(typeof(Class1));

image

那么有没有方法让他们自己的项目自己管理注册呢,我们可以简单改造一下

  • 新建一个类库,定义一个公共接口,安装Microsoft.Extensions.DependencyInjection 包

image

  • 在ClassLibarary1里面定义实现接口类
    public class ModulInit : IModuleInit
    {
        public void Init(IServiceCollection service)
        {
            //所有需要DI的在此处注入
            service.AddScoped<Class1>();
        }
    }
  • 在Programe.cs里面调用引用项目的注册类

image

这样其他项目也按照这种方式,在主项目中只要调用一次注册管理。不过这是最简单的方式,你也可以使用反射来查找引用的项目继承了IModuleInit的类,然后进行Init方法调用,这样会更优雅一些。
当然你还可以使用其他依赖注入框架来取代Microsoft.Extensions.DependencyInjection,也许这个问题就不再是问题!

.net 温故知新【12】:Asp.Net Core WebAPI 中的Rest风格 - XSpringSun - 博客园

mikel阅读(216)

来源: .net 温故知新【12】:Asp.Net Core WebAPI 中的Rest风格 – XSpringSun – 博客园

RPC

RPC(Remote Procedure Call),远程过程调用),这种RPC形式的API组织形态是类和方法的形式。所以API的请求往往是一个动词用来标识接口的意思,比如 https://xxxx/GetStudent?id=1 和 https://xxxx/AddStudent 这种风格,并且往往没有规范需要我们去查看接口定义文档。HTTP方法基本只用GET和POST,没有使用HTTP的其它谓词设计比较简单。

Rest

Rest:按照Http的语义来使用HTTP协议的一种风格,Rest全称Representational State Transfer(表现层状态转换)。他是一种规范或者设计风格而不是特别的技术。REST形式的API组织形态是资源和实体,请求的路由可以看出对资源的访问,规范统一接口自解释。
比如 https://xxxx/Student/1 用Get方法调用就是获取编号为1的学生。 https://xxxx/Student/1 用Delete调用就是删除编号为1的学生,用delete调用就是删除该学生。
在HTTP中这些调用方法GET、POST、PUT、PATCH、DELETE 即HTTP谓词。GET用来获取资源,POST用来新建资源,PUT用来更新指定资源,PATCH用来批量更新资源,DELETE用来删除资源,通过谓词来表示请求动作或者意图,通过url定位资源。
在请求中GET、PUT、DELETE 请求是幂等的,也就是说可以重试请求。而POST不是幂等,因为POST意思是添加数据。
在Rest风格中使用状态码来标识返回结果,其中常用200、201、400、401、404、410、500等。

ASP.NET Core WebAPI接口

ASP.NET WebAPI中我们也能看到Rest的风格,理想很丰满,显示很骨干。如果我们严格的按照Rest风格设计接口的话,需要对技术人员有很高的要求,需要去划分不同业务不同的资源定位,而且有些业务也找不到准确的谓词去定义,响应状态码有限无法表达准确的意思,或者是时间上来不及等等原因。
而且这种方式更符合国外语言表达的方式,不太适合我国宝宝体质。
所以我们在设计接口的时候不用非要用Rest风格,我们可以靠近或者在特定的更适合使用Rest接口系统中使用。
本篇我们结合Rest看下接口如何设计和交互。

  • 在http接口请求中有三种方式传递参数或者数据。
  1. URL:资源定位,也就是Rest风格,在请求的url中包含信息,比如https://xxxx/Student/1 1就是学生编号。
  2. QueryString: URL之外的额外信息,比如RPC中https://xxxx/GetStudent?id=1 id=1就是QueryString
  3. 请求报文体:供PUT、POST提交提供数据,请求体有多种格式application/x-www-form-urlencoded、multipart/form-data、application/json、text/plain、application/xml。
  • 返回状态码
    在RPC中Post请求我们习惯如果请求已经在服务器处理,不管处理结果是否正确,我们都返回200状态码。然后在返回数据中用其它信息来标识业务结果。比如{code:1,msg:"成功"}或者{code:0,msg:"失败"}
    而在Rest 中Post通常用201返回新增成功,delete 删除的数据不存在返回404,但是404大家知道可能也许是url错误,所以表诉不清。
    因此我们在实际设计中可能会进行Rest裁剪,我们既使用RPC的返回结果,同时多用准确的状态码,不用什么都返回200。
    使用RPC风格,尽量使用合理谓词,不知道使用什么谓词的时候就用POST,Get Delete参数尽量用资源定位URL,业务错误服务端返回合适的状体吗,不知道返回什么就返回400,如果请求处理成功就用200同时返回结果数据。

在上一篇中遗留的这个问题 .net 温故知新【11】:Asp.Net Core WebAPI 入门使用及介绍

image

所以我们在Controller中Route配置为[Controller]则不管方法接口名称是什么,仍然以Rest的方式访问。

    [Route("[controller]")]
    [ApiController]
    public class RestCutController : ControllerBase
    {
        [HttpGet]
        public IEnumerable<string> GetStudents()
        {
            //获取所有学生
            return new string[] { "student1", "student2" };
        }

        [HttpGet("{id}")]
        public string GetStudent(int id)
        {
            //获取id的学生
            return "student"+id;
        }

        [HttpPost]
        public void PostStudent([FromBody] string value)
        {
            //新增
        }

        [HttpPut("{id}")]
        public void PutStudent(int id, [FromBody] string value)
        {
            //修改
        }

        [HttpDelete("{id}")]
        public void DeleteStudent(int id)
        {
            //删除id学生
        }
    }

image

当我们修改Rout按照RPC方式,[Route("[controller]/[action]")] 运行后发现swagger展示的接口方式就改变了。并且保留了参数URL的方式。

image

关于返回状态码的问题可以有两种方式,一种是直接在ControllerBase.Response 响应中指定返回状态码。

        [HttpDelete("{id}")]
        public string DeleteStudent(int id)
        {
            //删除id学生
            if (id == 1)
            {
                return "删除成功";
            }
            else {

                Response.StatusCode = 404;
                return "未找到!";
            }
        }

另外一种方式就是返回泛型ActionResult<string>,其中OKNotFound是继承自ActionResult然后隐式转换到泛型,也可以直接返回IActionResult或者ActionResult但是类型不确定这样swagger文档就不会解析出返回值,所以我们用ActionResult泛型。

        [HttpDelete("{id}")]
        public ActionResult<string> DeleteStudent(int id)
        {
            //删除id学生
            if (id == 1)
            {
                return Ok("删除成功");
            }
            else
            {
                return NotFound("未找到!");
            }
        }

image

        [HttpDelete("{id}")]
        public ActionResult DeleteStudent(int id) //返回ActionResult
        {
            //删除id学生
            if (id == 1)
            {
                return Ok("删除成功");
            }
            else
            {
                return NotFound("未找到!");
            }
        }

image

最后我们在总结下关于API参数获取的方式,在[HttpGet("{id}")]中我们看到有{id},这个就是占位符,从RUL中获取,不光可以配置占位符还可以配置路径的其它值,甚至可以随意组织,只要我们的参数明和占位符相同就行。

        [HttpDelete("number/{id}/Name/{name}")] //自己组织的URL
        public ActionResult<string> DeleteStudent(int id,string name)
        {
            //删除id学生
            if (id == 1)
            {
                return Ok("删除成功");
            }
            else
            {
                return NotFound("未找到!");
            }
        }

image

当然也可以使用[FromRoute]从route获取,另外我们还有一些Attribute用于从不同的地方获取参数,比如从QueryString获取。那么我的请求URL就应该是/RestCut/DeleteStudent?id=1

        [HttpDelete]
        public ActionResult<string> DeleteStudent([FromQuery] int id)
        {
            //删除id学生
            if (id == 1)
            {
                return Ok("删除成功");
            }
            else
            {
                return NotFound("未找到!");
            }
        }

image

最后还有[FromHeader][FromForm][FromBody]这些获取参数的方式,不清楚的使用的时候查询就行了。

.net 温故知新【11】:Asp.Net Core WebAPI 入门使用及介绍 - XSpringSun - 博客园

mikel阅读(241)

来源: .net 温故知新【11】:Asp.Net Core WebAPI 入门使用及介绍 – XSpringSun – 博客园

ASP.NET Core 上面由于现在前后端分离已经是趋势,所以ASP.NET core MVC用的没有那么多,主要以WebApi作为学习目标。

一、创建一个WebApi项目

我使用的是VS2022, .Net 7版本。
在创建界面有几项配置:

  • 配置Https
  • 启用Docker
  • 使用控制器
  • 启用OpenAPI支持
  • 不使用顶级语句

image

其中配置Https 是WebApi是否使用https协议,启用docker是配置服务是否docker部署支持。我们这边作为学习就先不管docker了。
然后下面还有三个配置,第一个是说是否使用控制器,如果使用接口服务放在Controllers文件夹下统一管理并且相关路由规则不一样。
第二个启用OpenAPI支持,如果启用OpenAPI说的是swagger支持,也就是说.net 自动集成了swagger。
第三个不使用顶级语句,如果勾选后则程序的Program类和Main方法完整。

那么我们看下上面配置是什么意思,第二个swagger支持我们就不管了默认开启。我建两个项目AspNetCoreWebAPI_1、AspNetCoreWebAPI_2,AspNetCoreWebAPI_1我们勾选上【使用控制器】、【不使用顶级语句】。AspNetCoreWebAPI_2项目这两项都不选。

先看下项目目录结构

不同在于AspNetCoreWebAPI_1项目多了Controllers文件夹和一个WeatherForecast类,WeatherForecast类是示例接口中有使用。

image

我们再对比一下 Program

可以看到在AspNetCoreWebAPI_1项目中Program类和Main方法完整,因为要使用Controller的原因,所以依赖注入了Controller服务。并且使用了MapControllers注册路由。

在AspNetCoreWebAPI_2项目中没有只有Main方法内的代码,这就是顶级语句。然后由于我们还使用了最小API,就是不使用Controller方式注册和配置路由,直接在代码中自己注册接口和实现接口处理的代理方法。

image

按照以前ASP.NET习惯和项目清晰度维护性我们一般是使用Controller的方式,并且不使用顶级语句。

而最小 API,是创建具有最小依赖项的 HTTP API。 它非常适合于需要在 ASP.NET Core 中仅包括最少文件、功能和依赖项的微服务和应用。

另外还有一个appsetting.json配置文件,这部分内容也在前面已经介绍过,欢迎了解:.net 温故知新:【8】.NET 中的配置从xml转向json

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}

二、WebApi运行

我们调试项目AspNetCoreWebAPI_1,此时会启动一个服务在后端,同时启动浏览器访问该站点的swagger,该swagger用于调我们调试webapi接口。
image

image

我们点击示例接口WeatherForecast,访问接口会返回json格式数据。响应的headers里面可以看到后端运行的服务器是Kestrel,和我们以前.net framework不一样的事需要借助IIS作为服务器。现在的Kestrel是包含在程序中的,这个Kestrel 以后再讨论。
image

三、WeatherForecastController

WeatherForecastController是在创建项目后默认生成的一个示例Controller。在该Controller中我们可以看到几个重点项。

using Microsoft.AspNetCore.Mvc;

namespace AspNetCoreWebAPI_1.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class WeatherForecastController : ControllerBase
    {
        private static readonly string[] Summaries = new[]
        {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    };

        private readonly ILogger<WeatherForecastController> _logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger)
        {
            _logger = logger;
        }

        [HttpGet(Name = "GetWeatherForecast")]
        public IEnumerable<WeatherForecast> Get()
        {
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                TemperatureC = Random.Shared.Next(-20, 55),
                Summary = Summaries[Random.Shared.Next(Summaries.Length)]
            })
            .ToArray();
        }
    }
}
  1. ControllerBase 基类
    web API 控制器通常应派生自 ControllerBase 而不是 Controller。 Controller 派生自 ControllerBase,并添加对视图的支持,因此它用于处理 Web 页面,而不是 Web API 请求。 如果同一控制器必须支持视图和 Web API,则派生自 Controller。
  2. [ApiController]
    [ApiController] 属性可应用于控制器类,以启用下述 API 特定的固定行为:
    1)属性路由要求:不能通过由 UseEndpoints、UseMvc 或 UseMvcWithDefaultRoute 定义的传统路由访问操作,传统路由就是以前老的路由规则,型如”{controller=Home}/{action=Index}/{id?}”。需要使用[Route(“XX”)]指定路由。
    自动 HTTP 400 响应:[ApiController] 属性使模型验证错误自动触发 HTTP 400 响应。
    2)绑定源参数推理:绑定源特性定义可找到操作参数值的位置,接口的参数通过推理规则应用于操作参数的默认数据源。
    3)Multipart/form-data 请求推理:[ApiController] 属性对 IFormFile 和 IFormFileCollection 类型的操作参数应用推理规则。 为这些类型推断 multipart/form-data 请求内容类型。
    4)、错误状态代码的问题详细信息: 将错误结果(状态代码为 400 或更高的状态码)转换为为 ProblemDetails 的结果。也就是说状态码会转换如下json格式返回信息。
{
  type: "https://tools.ietf.org/html/rfc7231#section-6.5.4",
  title: "Not Found",
  status: 404,
  traceId: "0HLHLV31KRN83:00000001"
}
  1. [Route(“[controller]”)]
    指定控制器上的属性路由,属性路由将应用的功能建模为一组资源,其中操作由 HTTP 谓词表示。也就是说路由该属性配置了路由,如上图请求时的路由https://localhost:7122/WeatherForecast,配置中“[controller]”为标记替换,为方便起见,属性路由支持标记替换,方法是将标记用方括号([、])括起来[controller]用于替换WeatherForecastController中WeatherForecast部分。
  2. [HttpGet(Name = “GetWeatherForecast”)]
    HttpGet指示Get方法为Route路由的操作,即使我们将Get方法改为其他名字仍然不影响请求路由https://localhost:7122/WeatherForecast,并且以Get方式。这种api风格即为Rest风格。Rest风格我们后面再学习。
    ASP.NET Core 具有以下 HTTP 谓词模板:

    • [HttpGet]
    • [HttpPost]
    • [HttpPut]
    • [HttpDelete]
    • [HttpHead]
    • [HttpPatch]
  3. logger日志记录
    日志记录是基础知识点,这部分内容在我们之前温故知新中已经详细介绍过,可移步了解:.net 温故知新:【9】.NET日志记录 ILogger使用和原理

以上为我们入门WebApi创建的一个默认项目,并对创建选项、项目结构、服务要点进行了分析,后面将更进一步学习分享其他asp.net core webapi重要知识。

.net 温故知新【17】:Asp.Net Core WebAPI 中间件 - XSpringSun - 博客园

mikel阅读(236)

来源: .net 温故知新【17】:Asp.Net Core WebAPI 中间件 – XSpringSun – 博客园

一、前言

到这篇文章为止,关于.NET “温故知新”系列的基础知识就完结了,从这一系列的系统回顾和再学习,对于.NET core、ASP.NET CORE又有了一个新的认识。

不光是从使用,还包括这些知识点的原理,虽然深入原理谈不上,但对于日常使用也够了,我想的是知其然,知其所以然。

在实际开发过程中可能是知道怎么使用就行,但系统学习了这些基本的框架、组件、或者说原理后,对于我们软件设计、开发、扩展和解决问题还是有帮助的。

刚好到2023新年前赶着写完,也算对自己这个系列的一个交代,实际上我平时基本不使用ASP.NET CORE,目前我主要开发桌面程序,还是用的winform。

写这个系列的初衷是想紧跟.NET的发展进程,同时储备基础知识,平时还搞一些微服务(Java)、NLP、OCR、知识图谱、前端(Vue3),只要需要反正啥都搞,没必要固执,技术只是手段,不是目的。

那么接下来就继续简单的梳理一下中间件,欢迎对这个系列拍砖!

二、中间件

中间件是一种装配到应用管道以处理请求和响应的软件。 每个组件:

  • 选择是否将请求传递到管道中的下一个组件。
  • 可在管道中的下一个组件前后执行工作。

这个是关于中间件概念的概括,官方的概括是相当精准,那么我们就围绕管道、传递、组件来看看中间件。

请求委托用于生成请求管道。 请求委托处理每个 HTTP 请求。使用 Run、Map 和 Use 扩展方法来配置请求委托。

我们照例新建一个ASP.NET CORE Web API 项目:WebAPI_Middleware

namespace WebAPI_Middleware
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            // Add services to the container.

            builder.Services.AddControllers();
            // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
            builder.Services.AddEndpointsApiExplorer();
            builder.Services.AddSwaggerGen();

            var app = builder.Build();

            // Configure the HTTP request pipeline.
            if (app.Environment.IsDevelopment())
            {
                app.UseSwagger();
                app.UseSwaggerUI();
            }

            app.UseHttpsRedirection();

            app.UseAuthorization();


            app.MapControllers();

            app.Run();
        }
    }
}

在Program.cs 中我们看到前面部分builder是配置依赖注入的东西,这部分可以参看.net 温故知新【13】:Asp.Net Core WebAPI 使用依赖注入DI 。

app 使用Use扩展用于中间件添加到管道中

Map 基于给定请求路径的匹配项来创建请求管道分支

Run 委托始终为终端,用于终止管道。

中间件的执行顺序过程如下:

image

三、Map

我们将上面自动创建的东西全都删除,用Map来匹配路由,然后通过不同的代理处理请求。

    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            var app = builder.Build();
           
            //匹配map1 请求
            app.Map("/map1", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map1 run");
                });
            }));
            //匹配map2 请求
            app.Map("/map2", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map2 run");
                });
            }));

            app.Run();
        }
    }
  • 请求map1 我们输出:map1 run

image

  • 请求map2 我们输出:map2 run

image

Asp.Net Core MapControllers 的扩展方法也是类似道理,用来匹配路由调用处理程序。

四、Run

在上面的 Map 后面我们使用的处理方法中 Run 用于终止管道。也就是说在该管道中如果调用了 Run 那么就直接返回了,即使你后面还添加了 Use 也不会执行。

app.Run(async context =>
{
    await context.Response.WriteAsync("map1 run");
});

Map 相当于是迎客进门,Map 上了就用指定的管道进行处理,如果没有 Map 上就调用主管道,也就是主管道上的其他中间件也会执行处理。比如我们再加一个 Run 用于没匹配上路由也输出点信息。

image

加了context.Response.ContentType = "text/plain; charset=utf-8"; 不然中文会乱码。

image

因为 Run 是终结点,那这个管道中我还想加其他处理怎么办呢,这个时候就该轮到 Use 出场了。

五、Use

用 Use 将多个请求委托链接在一起。 next 参数表示管道中的下一个委托。 可通过不调用 next 参数使管道短路。

首先我们在外面添加两个 Use,不放到 Map 中,这样的话就只有未匹配到的路由会调用

    public class Program
    {
        public static void Main(string[] args)
        {
            var builder = WebApplication.CreateBuilder(args);

            var app = builder.Build();

            

            app.Map("/map1", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map1 run");
                });
            }));

            app.Map("/map2", new Action<IApplicationBuilder>((app) =>
            {
                app.Run(async context =>
                {
                    await context.Response.WriteAsync("map2 run");
                });
            }));
            //Use1
            app.Use(async (context, next) =>
            {
                context.Response.ContentType = "text/plain; charset=utf-8";

                await context.Response.WriteAsync("第 1 个Use   开始!\r\n", Encoding.UTF8);

                await next();

                await context.Response.WriteAsync("第 1 个Use   结束!\r\n", Encoding.UTF8);

            });
            
            //Use2
            app.Use(async (context, next) =>
            {
                await context.Response.WriteAsync("第 2 个Use   开始!\r\n", Encoding.UTF8);

                await next();

                await context.Response.WriteAsync("第 2 个Use   结束!\r\n", Encoding.UTF8);

            });
            //结束管道处理
            app.Run(async context =>
            {
                await context.Response.WriteAsync("未匹配处理!\r\n", Encoding.UTF8);
            });

            app.Run();
        }
    }

最后执行的路径和最开始的图是一致的。

image

为什么将context.Response.ContentType = "text/plain; charset=utf-8"; 放到第一个 Use 呢,因为如果放到 Run 里面会报错,改变了 Header 标头。所以理论上也不要在 Use 里面发送响应WriteAsync,此处为了演示所以这么写。

image

六、中间件类

上面的代理方法可以移动到类中,这个类就是中间件类。中间件类需要如下要求:

  • 具有类型为 RequestDelegate 的参数的公共构造函数。
  • 名为 Invoke 或 InvokeAsync 的公共方法。 此方法必须:
    返回 Task。
    接受类型 HttpContext 的第一个参数。

构造函数和 Invoke/InvokeAsync 的其他参数由依赖关系注入 (DI) 填充。

将上面的未匹配路由处理逻辑移动到中间件类中:

  • TestMiddleware1:
    public class TestMiddleware1
    {
        private readonly RequestDelegate _next;

        public TestMiddleware1(RequestDelegate next)
        {
            _next = next;
        }

        public async Task InvokeAsync(HttpContext context)
        {

            context.Response.ContentType = "text/plain; charset=utf-8";

            await context.Response.WriteAsync("第 1 个Use   开始!\r\n", Encoding.UTF8);

            await _next(context);

            await context.Response.WriteAsync("第 1 个Use   结束!\r\n", Encoding.UTF8);
        }
    }
  • TestMiddleware2
    public class TestMiddleware2
    {
        private readonly RequestDelegate _next;

        public TestMiddleware2(RequestDelegate next)
        {
            _next = next;
        }

        public async Task InvokeAsync(HttpContext context)
        {


            await context.Response.WriteAsync("第 2 个Use   开始!\r\n", Encoding.UTF8);

            await _next(context);

            await context.Response.WriteAsync("第 2 个Use   结束!\r\n", Encoding.UTF8);
        }
    }
  • Program
    image
  • 运行
    image

此处的中间件使用有顺序问题,如果我先app.UseMiddleware<TestMiddleware2>() 因为 TestMiddleware1 修改了标头,根据约定是不允许的,所以程序是有报错。

image

因此中间件组件的顺序定义了针对请求调用这些组件的顺序,以及响应的相反顺序。 此顺序对于安全性、性能和功能至关重要。

七、中间件顺序

image

以上是内置中间件的默认顺序规则,具体如何使用内置中间件,可参阅官方资料。

八、写在最后

以上就是关于中间件的部分知识,结合我自己的理解做了前后衔接的梳理逻辑。

官方网站更多的是讲解每个知识点的细节,前后需要结合起来理解,当然我还是强烈建议跟着官方文档学习,而且是最权威最可信的:ASP.NET Core 中间件

这个系列历时2年,工作生活都比较忙,也有放纵啥事不相干的时候,中间断断续续的,总算是坚持完了。很多东西就是这样,累了就休息一下贵在坚持,即使再慢,积累的成果也有收获。

Redis系列:使用 Redis Module 扩展功能 - Hello-Brand - 博客园

mikel阅读(306)

来源: Redis系列:使用 Redis Module 扩展功能 – Hello-Brand – 博客园

1 啥是Redis Module

Redis Module是Redis的一种扩展模块,从 4.0版本开始,允许用户自定义扩展模块,在Redis内部实现新的数据类型和功能,使用统一的调用方式和传输协议格式扩展Redis的能力。它本身的设计目的就是在不同版本的Redis中运行,因此无需重新编译模块即可与特定版本(Redis > 4.0)一起运行。

通过使用Redis Module,可以在Redis中添加新的命令和数据类型,以实现更高级的功能。例如,一些第三方模块支持全文搜索、JSON数据的存储和查询、自定义分布式锁、时间序列数据的存储和查询等。我们也可以基于 Redis 去定制开发属于自己的 Module,来支撑自己的业务发展。

2 有哪些常见的Redis Module

目前,被 Redis 官方推荐的 Module 有:

2.1 RediSearch

一个功能齐全,可实现 快速检索、二次索引和全文搜索的搜索引擎模块
image
地址:https://github.com/RediSearch/RediSearch

2.2 RedisJSON

RedisJSON是一个用于处理 JSON 数据的模块,它实现了JSON数据交换标准,允许从Redis 文档中存储、更新和获取JSON值。
地址:https://github.com/RedisJSON/RedisJSON

2.3 RedisTimeSeries

RedisTimeSeries是Redis的一个时间序列数据库(TSDB)管理模块。RedisTimeSeries可以保存多个时间序列,每个时间序列都可以通过一个Redis键访问(类似于任何其他Redis数据结构)。
地址:https://github.com/RedisTimeSeries/RedisTimeSeries

2.4 RedisGraph

用于实现图形数据库的模块
https://github.com/RedisGraph/RedisGraph?tab=readme-ov-file#trying-redisgraph

2.5 RedisBloom

RedisBloom为Redis增加了一组概率数据结构,包括Bloom filter(布隆过滤器), Cuckoo filter, Count-min sketch, Top-K和t-digest。使用此功能,您可以查询流数据,而无需存储流的所有元素。每种概率数据结构都应对不同的业务场景。
地址:https://github.com/RedisBloom/RedisBloom

2.6 RedisCell

实现分布式限流能力的模块,使用了相对精妙的算法 generic cell rate algorithm (GCRA) 。
地址:https://github.com/brandur/redis-cell

2.7 RedisAI

RedisAI是一个Redis模块,用于执行深度学习/机器学习模型并管理其数据。它的目的是成为模型服务的“主力军”,为流行的DL/ML框架提供开箱即用的支持和无与伦比的性能。RedisAI坚持数据本地化原则,最大限度地提高了计算吞吐量,减少了延迟。
地址:https://github.com/RedisAI/RedisAI

上面给出的几个都是GitHub小星星比较高的模块,如果你想要了解很多的内容,可以参考官方文档:https://redis.io/modules。

3 Redis module 实践指南

3.1 安装Redis

因为这些扩展模块是依赖于Redis服务存在的,所以前提是Redis安装完成。
Redis官方安装指南:https://redis.io/docs/install/install-redis/

3.2 以RedisJson 为例子

3.2.1 下载RedisJSON

github上下载ReJSON的地址:https://github.com/RedisJSON/RedisJSON/releases
官方使用文档:https://redis.io/docs/data-types/json/
可以看到,最新的版本是 v2.6.8
image

3.2.2 安装

1、获取文件

在 redis 安装目录下新建 module 文件夹,把获取到的rejson.so文件 放到 module 文件夹中

# 先进入redis的安装目录
cd /usr/local/soft/redis-6.2.6/

# 然后新建一个module文件夹
mkdir module

# 最后rejson.so文件放到module文件夹即可

2、修改配置

# 进入到module目录下
cd ./module

# 为文件加X,即修改rejson.so为可执行文件
chmod +x rejson.so

# 修改 redis.conf,初始时自动 loadmodule
loadmodule /usr/local/soft/redis-6.2.6/module/rejson.so

# 重启 redis
redis-cli -a 123456 shutdown
redis-server conf/redis.conf
redis-cli -p 6379

3.2.3 RedisJSON操作实践

1、写入JSON.SET

语法解析

JSON.SET <key> <path> <json>  [NX | XX]
  • key:要操作的键。
  • path:JSON路径,用于指定要设置值的对象或数组的路径。
  • json:要设置的JSON值。
  • [NX | XX]:可选参数,用于指定操作的条件。
    • NX:仅当指定的键不存在时,才设置值。
    • XX:仅当指定的键存在时,才设置值。

比如下面,保存两条数据

# 保存两条记录
127.0.0.1:6379> JSON.SET user1 $ '{"name":"Brand", "age":18, "sex":"1"}'
127.0.0.1:6379> JSON.SET user2 $ '{"name":"Candy", "age":17, "sex":"0"}'

2、读取操作JSON.GET

语法解析

JSON.GET <key>
         [INDENT indentation-string]
         [NEWLINE line-break-string]
         [SPACE space-string]
         [path ...]
  • Key:要获取值的键
  • INDENT:查询结果替换掉默认缩进字符
  • NEWLINE:查询结果替换掉默认换行符
  • SPACE:查询结果替换掉默认空格
  • path:允许使用多个path进行查询
  • 获取JSON对象中的属性时需要以.开头

比如下面,获取相关信息

# 得到myjson的所有数据
127.0.0.1:6379> JSON.GET user1
1) '{"name":"Brand", "age":18, "sex":"1"}'

# 得到json数据中的键name的值
127.0.0.1:6379> JSON.GET user1 name
1) "Brand"

3、批量读取操作JSON.MGET

这是一个批量操作的语法,语法解析:

JSON.MGET <key> [key ...] <path>
  • key:是一个列表,指的是可以有多个key
  • path:指所有key的path,即遍历每一个key的path,如果不存在,则返回null

下面的语句演示MGET获取批量数据:

127.0.0.1:6379> JSON.MGET user1 user2 $.name
1) "Brand"
2) "Candy"

4、除操作JSON.DEL
这是删除操作的语法,语法解析:

JSON.DEL <key> [path]
  • path是可选参数,如果没有提供,则默认整个Key删除掉

下面语句中

# 删除整个Json
127.0.0.1:6379> JSON.DEL user1
(integer) 1

# 删除某个字段
127.0.0.1:6379> JSON.DEL user2  $.age
1) "17"

5、其他操作类行
除了上面的几种常见操作,官方还支持如下命令,官方命令地址:https://redis.io/docs/data-types/json/
常用命令(数字可以递增、相乘):

# JSON.NUMINCRBY,JSON.NUMMULTBY,JSON.STRAPPEND,JSON.STRLEN

> JSON.SET num $ 0
OK
> JSON.NUMINCRBY num $ 1
"[1]"
> JSON.NUMINCRBY num $ 1.5
"[2.5]"
> JSON.NUMINCRBY num $ -0.75
"[1.75]"
> JSON.NUMMULTBY num $ 24
"[42]"

数组命令:

#  JSON.ARRAPPEND,JSON.ARRINDEX,JSON.ARRINSERT,JSON.ARRLEN,JSON.ARRPOP,JSON.ARRTRIM

> JSON.SET arr $ []
OK
> JSON.ARRAPPEND arr $ 0
1) (integer) 1
> JSON.GET arr $
"[[0]]"
> JSON.ARRINSERT arr $ 0 -2 -1
1) (integer) 3
> JSON.GET arr $
"[[-2,-1,0]]"
> JSON.ARRTRIM arr $ 1 1
1) (integer) 1
> JSON.GET arr $
"[[-1]]"
> JSON.ARRPOP arr $
1) "-1"
> JSON.ARRPOP arr $
1) (nil)

对象命令(对象长度和key值输出):

#  JSON.OBJKEYS,JSON.OBJLEN

> JSON.SET obj $ '{"name":"Leonard Cohen","lastSeen":1478476800,"loggedOut": true}'
OK
> JSON.OBJLEN obj $
1) (integer) 3
> JSON.OBJKEYS obj $
1) 1) "name"
   2) "lastSeen"
   3) "loggedOut"

组件命令:
JSON.TYPE,JSON.Debug,JSON.FORGET,JSON.RESP

4 总结

本文介绍了Redis的扩展模块Redis Module,设计目的就是使用加载Redis Module,在Redis中添加新的命令和数据类型,以实现更高级的功能。
文章介绍了目前官方推荐的几个Module,并演示了RedisJSON的效果。

工作中使用Redis的10种场景 - 苏三说技术 - 博客园

mikel阅读(306)

来源: 工作中使用Redis的10种场景 – 苏三说技术 – 博客园

前言

Redis作为一种优秀的基于key/value的缓存,有非常不错的性能和稳定性,无论是在工作中,还是面试中,都经常会出现。

今天这篇文章就跟大家一起聊聊,我在实际工作中使用Redis的10种场景,希望对你会有所帮助。

1. 统计访问次数

对于很多官方网站的首页,经常会有一些统计首页访问次数的需求。

访问次数只有一个字段,如果保存到数据库中,再最后做汇总显然有些麻烦。

该业务场景可以使用Redis,定义一个key,比如:OFFICIAL_INDEX_VISIT_COUNT。

在Redis中有incr命令,可以实现给value值加1操作:

incr OFFICIAL_INDEX_VISIT_COUNT

当然如果你想一次加的值大于1,可以用incrby命令,例如:

incrby OFFICIAL_INDEX_VISIT_COUNT 5

这样可以一次性加5。

2. 获取分类树

在很多网站都有分类树的功能,如果没有生成静态的html页面,想通过调用接口的方式获取分类树的数据。

我们一般为了性能考虑,会将分类树的json数据缓存到Redis当中,为了后面在网站当中能够快速获取数据。

不然在接口中需要使用递归查询数据库,然后拼接成分类树的数据结构。

这个过程非常麻烦,而且需要多次查询数据库,性能很差。

因此,可以考虑用一个定时任务,异步将分类树的数据,直接缓存到Redis当中,定义一个key,比如:MALL_CATEGORY_TREE。

然后接口中直接使用MALL_CATEGORY_TREE这个key从缓存中获取数据即可。

可以直接用key/value字符串保存数据。

不过需要注意的是,如果分类树的数据非常多可能会出现大key的问题,优化方案可以参考我的另外一篇文章《分类树,我从2s优化到0.1s》。

3. 做分布式锁

分布式锁可能是使用Redis最常见的场景之一,相对于其他的分布式锁,比如:数据库分布式锁或者Zookeeper分布式锁,基于Redis的分布式锁,有更好的性能,被广泛使用于实际工作中。

我们使用下面这段代码可以加锁:

try{
  String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
  if ("OK".equals(result)) {
      return true;
  }
  return false;
} finally {
    unlock(lockKey);
}  

但上面这段代码在有些场景下,会有一些问题,释放锁可能会释放了别人的锁。

说实话Redis分布式锁虽说很常用,但坑也挺多的,如果用不好的话,很容易踩坑。

如果大家对Redis分布式锁的一些坑比较感兴趣,可以看看我的另一篇文章《聊聊redis分布式锁的8大坑》,文章中有非常详细的介绍。

4. 做排行榜

很多网站有排行榜的功能,比如:商城中有商品销量的排行榜,游戏网站有玩家获得积分的排行榜。

通常情况下,我们可以使用Sorted Set保存排行榜的数据。

使用ZADD可以添加排行榜的数据,使用ZRANGE可以获取排行榜的数据。

例如:

ZADD rank:score 100 "周星驰"
ZADD rank:score 90 "周杰伦"
ZADD rank:score 80 "周润发"
ZRANGE rank:score 0 -1 WITHSCORES

返回数据:

1) "周星驰"
2) "100"
3) "周杰伦"
4) "90"
5) "周润发"
6) "80"

5. 记录用户登录状态

通常下,用户登录成功之后,用户登录之后的状态信息,会保存到Redis中。

这样后面该用户访问其他接口的时候,会直接从Redis中查询用户登录状态,如果可以查到数据,说明用户已登录,则允许做后续的操作。

如果从Redis中没有查到用户登录状态,说明该用户没有登录,或者登录状态失效了,则直接跳转到用户登录页面。

使用Redis保存用户登录状态,有个好处是它可以设置一个过期时间,比如:该时间可以设置成30分钟。

jedis.set(userId, userInfo, 1800);

在Redis内部有专门的job,会将过期的数据删除,也有获取数据时实时删除的逻辑。

6. 限流

使用Redis还有一个非常常用的的业务场景是做限流

当然还有其他的限流方式,比如:使用nginx,但使用Redis控制可以更精细。

比如:限制同一个ip,1分钟之内只能访问10次接口,10分钟之内只能访问50次接口,1天之内只能访问100次接口。

如果超过次数,则接口直接返回:请求太频繁了,请稍后重试。

跟上面保存用户登录状态类似,需要在Redis中保存用户的请求记录。

比如:key是用户ip,value是访问的次数从1开始,后面每访问一次则加1。

如果value超过一定的次数,则直接拦截这种异常的ip。

当然也需要设置一个过期时间,异常ip如果超过这个过期时间,比如:1天,则恢复正常了,该ip可以再发起请求了。

或者限制同一个用户id。

7. 位统计

比如现在有个需求:有个网站需要统计一周内连续登陆的用户,以及一个月内登陆过的用户。

这个需求使用传统的数据库,实现起来比较麻烦,但使用Redis的bitmap让我们可以实时的进行类似的统计。

bitmap 是二进制的byte数组,也可以简单理解成是一个普通字符串。它将二进制数据存储在byte数组中以达到存储数据的目的。

保存数据命令使用setbit,语法:

setbit key offset value

具体示例:

setbit user:view:2024-01-17 123456 1

往bitmap数组中设置了用户id=123456的登录状态为1,标记2024-01-17已登录。

然后通过命令getbit获取数据,语法:

getbit key offset

具体示例:

getbit user:view:2024-01-17 123456

如果获取的值是1,说明这一天登录了。

如果我们想统计一周内连续登录的用户,只需要遍历用户id,根据日期中数组中去查询状态即可。

8. 缓存加速

我们在工作中使用Redis作为缓存加速,这种用法也是非常常见的。

如果查询订单数据,先从Redis缓存中查询,如果缓存中存在,则直接将数据返回给用户。

如果缓存中不存在,则再从数据库中查询数据,如果数据存在,则将数据保存到缓存中,然后再返回给用户。

如果缓存和数据库都不存在,则直接给用户返回数据不存在。

流程图如下:

但使用缓存加速的业务场景,需要注意一下,可能会出现:缓存击穿、穿透和雪崩等问题,感兴趣的小伙伴,可以看看我的另一篇文章《烂大街的缓存穿透、缓存击穿和缓存雪崩,你真的懂了?》,里面有非常详细的介绍。

9. 做消息队列

我们说起队列经常想到是:kafka、rabbitMQ、RocketMQ等这些分布式消息队列。

其实Redis也有消息队列的功能,我们之前有个支付系统,就是用的Redis队列功能。

PubSub(发布订阅)是Redis2.0版本引入的消息传递模型。

顾名思义,消费者可以订阅一个或多个channel,生产者向对应channel发送消息后,所有订阅者都能收到相关消息。对应channel发送消息后,所有订阅者都能收到相关消息。

在java代码中可以实现MessageListener接口,来消费队列中的消息。

@Slf4j
@Component
public class RedisMessageListenerListener implements MessageListener {
    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    @Override
    public void onMessage(Message message, byte[] pattern) {
        String channel = new String(pattern);
        RedisSerializer<?> valueSerializer = redisTemplate.getValueSerializer();
        Object deserialize = valueSerializer.deserialize(message.getBody());
        if (deserialize == null) return;
        String md5DigestAsHex = DigestUtils.md5DigestAsHex(deserialize.toString().getBytes(StandardCharsets.UTF_8));
        Boolean result = redisTemplate.opsForValue().setIfAbsent(md5DigestAsHex, "1", 20, TimeUnit.SECONDS);
        if (Boolean.TRUE.equals(result)) {
            log.info("接收的结果:{}", deserialize.toString());
        } else {
            log.info("其他服务处理中");
        }
    }
}

10. 生成全局ID

在有些需要生成全局ID的业务场景,其实也可以使用Redis。

可以使用incrby命令,利用原子性操作,可以执行下面这个命令:

incrby userid 10000

在分库分表的场景,对于有些批量操作,我们可以从Redis中,一次性拿一批id出来,然后给业务系统使用。

最后说一句(求关注,别白嫖我)

如果这篇文章对您有所帮助,或者有所启发的话,帮忙扫描下发二维码关注一下,您的支持是我坚持写作最大的动力。
求一键三连:点赞、转发、在看。

关注公众号:【苏三说技术】,在公众号中回复:面试、代码神器、开发手册、时间管理有超赞的粉丝福利,另外回复:加群,可以跟很多BAT大厂的前辈交流和学习。

Web Components从技术解析到生态应用个人心得指北 - zhoulujun - 博客园

mikel阅读(296)

来源: Web Components从技术解析到生态应用个人心得指北 – zhoulujun – 博客园

Web Components浅析

Web Components 是一种使用封装的、可重用的 HTML 标签、样式和行为来创建自定义元素的 Web 技术。

Web Components 自己本身不是一个规范,而是一套整体技术,包含下面3个独立规范:

  1. Custom Elements:允许开发者定义自己的 HTML 标签(考虑SEO,还是语义化为好)。
  2. Shadow DOM:用于封装样式和标记,不受外部 DOM 影响——天然自带Scope能力(本质是一组 JS API)。
  3. HTML Templates (<template> 和 <slot>):声明式的重用 HTML 代码片段。

     

但是,我觉得还应该包含:ES Modules

Custom Elements 和 Shadow DOM 的可靠性是确定的,毕竟是标准的一部分。

Custom Elements

在2008年W3C 发布了第一个HTML公开草案,其是就是可以使用自定义标签的——2000年W3C准备用XHTML来替代HTML4,结果被抛弃!

XHTML,或者更准确地说是 XHTML 1.0,是一种基于 XML 的标记语言,旨在在网页设计中取代HTML 4.01。它由 W3C 推出,其规范在2000年1月成为官方的推荐标准。XHTML1.0实际上是HTML 4.01的严格版本,并要求开发者遵循更加严格的语法规则——XHTML基于XML,它对标记的正确性有更高的要求:

  • XHTML 元素必须被正确地嵌套。
  • XHTML 元素必须被关闭
  • 标签名必须用小写字母。
  • XHTML 文档必须拥有根元素。
  • XHTML需要开发者在文档开头声明正确的DOCTYPE,而在实际的实践中,由于历史原因和混乱的标准,很多时候开发者并没有遵循正确的声明,导致页面以兼容模式而不是标准模式渲染。
  • 为了正确地作为XHTML传送,Web服务器需要设置MIME类型为application/xhtml+xml。不幸的是,一些浏览器对这种MIME类型的处理不理想,这使得开发者们更倾向于使用更通行的text/html,这实际上使XHTML变成了浏览器中被当作HTML解析的标记语言。

在 HTML5 之前,使用非标准标签通常会被视为不良实践,因为这可能导致不可预测的行为,尤其是在不同的浏览器之间。

然而,HTML5 引入了一种更加宽容的解析规则,允许这些非标准标签存在,浏览器不会因为碰到未知标签而破坏整个页面。即使如此,这些自定义标签没有任何默认的样式或行为,它们就像普通的 HTML 元素(默认为内联元素),除非通过 CSS 或 JavaScript 给予样式和行为。

自定义标签和自定义元素是两个相关但不同的概念。它们代表着 web 开发中自定义组件的不同方面和不同阶段的发展。

自定义标签与自定义元素

自定义标签(非标准标签)

自定义标签:Custom Tags、Non-standard Tags、User-defined Tags……

自定义标签仅在语义上是自定义的,而没有附加任何特殊的行为;

自定义元素(Custom Elements)

自定义元素是 Web Components 规范的一部分,它允许开发者创建完全定制化和可重用的 HTML 元素。

与仅仅创建一个新的标签名不同,自定义元素能够拥有自己独特的行为和属性。

Custom Elements 规范定义了如何注册新的元素、如何附加行为、以及如何处理元素的生命周期事件(如创建、连接到文档、断开连接和属性更改时)。

自定义元素通常使用 customElements.define() 方法在 JavaScript 中注册,这样,当元素被添加到 DOM 时,就会与一个 JavaScript 类关联起来。这个类继承自 HTMLElement,允许它具备 DOM 接口的所有特性,并添加自定义的逻辑和样式。这意味着自定义元素不仅仅是形式上的定制,而是实现了真正的封装和功能拓展。

区别总结

  • 语义:自定义标签仅在语义上是自定义的,而没有附加任何特殊的行为;相反,自定义元素通过 Custom Elements API 注册,并可以包括复杂的逻辑和状态。
  • 功能性:自定义元素支持完整的生命周期管理,提供创建时、附加到 DOM、属性变动等时机的钩子,而自定义标签则没有这些功能。
  • 标准化:自定义元素是 Web Components 的官方标准之一,得到了浏览器的广泛支持;而自定义标签顾名思义,是非标准的,它们允许存在,但并不是 HTML 规范的一部分。
  • 兼容性:自定义元素需要浏览器支持相关的标准,虽然现在大多数现代浏览器都提供了支持,但在一些旧的浏览器中可能需要 polyfills;而自定义标签通常哪种浏览器都能解析,只是作为普通的元素看待。

custom element生命周期

在custom element的构造函数中,可以指定多个不同的回调函数,它们将会在元素的不同生命时期被调用:

  1. connectedCallback:当 custom element首次被插入文档DOM时,被调用。
  2. disconnectedCallback:当 custom element从文档DOM中删除时,被调用。
  3. adoptedCallback:当 custom element被移动到新的文档时,被调用。
  4. attributeChangedCallback: 当 custom element增加、删除、修改自身属性时,被调用。

具体参看:https://developer.mozilla.org/zh-CN/docs/Web/API/Web_components/Using_custom_elements

 

Shadow DOM

Shadow DOM 主要目的:封装与隔离——相比iframe、frame更加轻量级。

  • IFrame是一个独立的html页面,shadow DOM是当前html页面的一个代码片段,
  • 不需要创建额外的渲染环境——不需要创建一个完整的文档环境,而是基于现有的上下文中创建封闭的DOM结构。

Shadow DOM接口是关键所在:它可以将一个隐藏的、独立的DOM附加到一个元素上,它以shadow root节点为起始根节点,在这个根节点的下方,可以是任意元素,和普通的DOM元素一样,但是这棵子树不在主DOM树中——即影子DOM是一种不属于主DOM树的独立的结构,所以Shadow DOM内部的元素始终不会影响到它外部的元素(除了:focus-within),这就为封装提供了便利

  • Shadow host: 一个常规DOM节点,Shadow DOM会被附加到这个节点上。
  • Shadow tree: Shadow DOM内部的DOM树。
  • Shadow boundary: Shadow DOM结束的地方,也是常规DOM开始的地方。
  • Shadow root: Shadow tree的根节点。

Shadow DOM都不是一个新事物,在过去的很长一段时间里,浏览器用它来封装一些元素的内部结构,以一个有着默认播放控制按钮的<video>元素为例,我们所能看到的只是一个<video>标签,实际上,在它的Shadow DOM中,包含来一系列的按钮和其他控制器。

chrome设置Show user agent shadow DOMshadow DOM标签示例

其结构如下:

而现在,我们可以来自己制造相关的标签(如video类似的功能模块)

怎么使用Shadow DOM

看这个就好:https://developer.mozilla.org/zh-CN/docs/Web/API/Web_components/Using_shadow_DOM

但是,https://github.com/Tencent/omi等框架应该更加适合你!

HTML templates(HTML 模板)

这个用过vue的理解应该不难:

  • <template>包含一个 HTML 片段,不会在文档初始化时渲染。<slot>插槽,类似占位符,可以填充自己的内容。、
  • <slot>插槽,类似占位符,可以填充自己的内容。

但是真的要用的话,还是用omi等类似的框架。

为什么不用原生API

这个问题就是,为什么要用JQuery?为什么放弃JQuery使用vue或react?

其是Web Components 了解一下就好。

为什么不推荐使用Web Components

React 和 Vue 在组件化开发方面有自己的实现,并没有直接采用 Web Components 作为内部实现——不过,它们两者都提供了与 Web Components 兼容的接口。

下面是我个人感觉他们放弃Web Components的原因:

React放弃Web Components

  • 封装性:React 组件经常需要和一个复杂的状态以及生命周期方法交互,这些都不是 Web Components 标准提供的。
  • 性能优化:React 的虚拟 DOM 可以通过最小化实际的 DOM 操作来提升性能,这一点在批量更新 UI 或大型应用中尤为明显。
  • 跨平台:React 不仅仅用于 web 开发(通过 React Native,它也被用于移动应用开发),而 Webb Components 专注于 web 标准和浏览器环境。
  • 生态系统:React 拥有非常庞大且成熟的生态系统,包括状态管理(如 Redux)、路由(如 React Router)等各种工具和库。

Vue3放弃Web Components

  • 响应式系统:Vue 的响应式系统使得数据和视图能够自动同步更新,而 Web Components 没有内建这样的响应式机制。
  • 模板语法:Vue 通过其简洁的模板语法扩展了普通的 HTML,使开发者可以更加容易地描述复杂的 UI 结构,而 Web Components 使用的是普通 HTML 搭配 JavaScript。
  • 工具链支持:Vue CLI 提供了非常强大的工具链支持,包括项目脚手架、开发服务器、热重载等,而这些在 Web Components 中不是直接可用的。
  • 生态系统:与 React 类似,Vue 也拥有广泛的插件和支持库,例如 Vuex、Vue Router 等,这些让 Vue 应用开发更为完善。

尽管 React 和 Vue 没有直接采用 Web Components 作为内部实现,但它们都提供了对 Web Components 的支持

2011年,Alex Russel首次提出了Web Components的概率并首次演示了demo,这时候整套技术包括三个方面:scoped css,shadow DOM和Web components。W3C也在此时开始推进Web Components规范。

2012年,HTML Template很快被实现,作为wrapper包裹内容,在页面加载时不使用,在之后运行时实例化。同时Shadow DOM V0标准发布并被实现,并且Ember和Angular开始计划支持Web Components,甚至基于它去做改造,但最终没有结果

至2018年,Web Components在主流浏览器中均被支持,但是并未达到普及程度,具体参看:https://caniuse.com/?search=Web%20Components%20

但是,比如视频播放器、SQL编辑器等超大件,还是非常适合Web Components的。不过这里还是推荐使用框架来做。

vue3项目Web Components案例

Vue 和 Web Components 是互补的技术,具体可以看官方文档:https://cn.vuejs.org/guide/extras/web-components

Vue 在 Custom Elements Everywhere 测试中取得了 100% 的分数。在 Vue 应用中使用自定义元素基本上与使用原生 HTML 元素的效果相同!

Vue 提供了一个和定义一般 Vue 组件几乎完全一致的 defineCustomElement 方法来支持创建自定义元素。这个方法接收的参数和 defineComponent 完全相同。

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import { defineCustomElement } from 'vue'
const MyVueElement = defineCustomElement({
  // 同平常一样的 Vue 组件选项——正常的 Vue 组件选项都有
  props: {},
  emits: {},
  template: `...`,
  // defineCustomElement 特有的:注入进 shadow root 的 CSS
  styles: [`/* inlined css */`]
})
// 注册自定义元素,注册之后,所有此页面中的 `<my-vue-element>` 标签 都会被升级
customElements.define('my-vue-element', MyVueElement)
// 你也可以编程式地实例化元素(必须在注册之后) :
document.body.appendChild(
  new MyVueElement({
    // 初始化 props(可选)
  })
)
// 也可以直接使用
export default defineComponent({
  setup(){
    return ()=>(<my-vue-element/>)
  }
})

这样用,是不是非常爽!

vue3 使用Web Components需要注意的点:

failed to resolve component

默认情况下,Vue 会优先尝试将一个非原生的 HTML 标签解析为一个注册的 Vue 组件,如果失败则会将其渲染为自定义元素。这种行为会导致在开发模式下的 Vue 发出“failed to resolve component”的警告。所以需要告诉 Vue 将某些确切的元素作为自定义元素处理并跳过组件解析。在 vite.config.ts 配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
{resolve: {
  alias: {//组件提供模板选项,但是在 Vue 这个构建中不支持运行时编译
    'vue''vue/dist/vue.esm-bundler.js',//需要配置你的 bundler 别名 vue: vue/dist/vue.esm-bundler.js
    '@': resolve(__dirname, 'src')
  }
},
plugins: [vue({
  template: {
    compilerOptions: {
      isCustomElement: tag => tag.startsWith('cus-')// 以 cus- 开头的作为自定义元素处理
    }
  }
})]}

 

Provide / Inject API

Provide / Inject API 和相应的组合式 API 在 Vue 定义的自定义元素中都可以正常工作。但是请注意,依赖关系只在自定义元素之间起作用

但是为推荐费必要

插槽

在组件内部,可以像往常一样使用 <slot/> 渲染插槽。但是在解析最终生成的元素时,它只接受原生插槽语法:

  • 不支持作用域插槽。
  • 传递命名插槽时,请使用 slot attribute 而非 v-slot 指令

React项目Web Components案例

说实话,react原生来写干嘛呢?

如果要在react项目里面写,推荐使用 https://lit.dev/

或者使用https://github.com/Tencent/omi/ 来写个项目,打包成组件库,然后再业务里面使用!

 

 

Web Components 生态

Lit:Lit是一个轻量的库,但它依然保留了web组件的所有特性。

Omi:Web Components 框架.

Vaadin: Vaadin 是以java作为开发语言的前端框架,它提供了一套以Web Components为基础的丰富的企业级UI组件库,关键他和spring结合的非常爽,比GWT用起来。

Ionic Framework: 本来是为Angular构建的(4.x适配Angular、Vue 、React),Ionic4 Web端基于Web Components——具有更好的运行速度,相比以前版本的Ionic框架性能提升很多!优异的性能则让 Ionic 成为了构建高性能 PWA 的最佳 UI 框架

说实话吧,Web Components 相比周边生态还是没有起来。可以作为大型项目某些模块的补充技术!

svelte:前端框架新秀,原生支持Web Components。个人不是很了解,跳过!

Google 从 2013 年开始一直在持续推进的基于 Web Components 封装的类库,同时还开放了基于 Polymer 开发的组件集合 PolymerElements · GitHub 和开发周边。 2015 年 Google 正式发布 Polymer 1.0 ,注意时间点,当时还是Custom Elements v0 版标准 2017年Custom Elements v1 版标准在各大浏览器落地,Polymer 发布了 2.0,并且不再封装 Custom Elements API,不再默认使用shadowDOM、目标兼容各种框架,开始变成轻量级类库。

  • 由于起步几乎最早以及 google 背书,可能到现在也是影响用户数最大的 Web Components 基础库,Youtube 基于Polymer 对整站做了重构,Google 很多产品包括 Android 和 ChromeOS 平台也都用了 Polymer。

但个人觉得总体上相比与彼时流行的其他框架 Polymer 还是不温不火,Google 似乎也有同感、随着 Polymer 的轻量化升级,于是在 2018 年又发布了更现代化的 lit GitHub – lit/lit: Lit is a simple library for building fast, lightweight web components.包括 lit-html 模板渲染库 lit/packages/lit-html at main · lit/lit · GitHub和基于 lit-html 的 lit-element  lit/packages/lit-element at main · lit/lit · GitHub 创建 Web Component 的 base class 。 Lit-html 基于 ES 的模板自变量和 template 标签,用注释节点去动态填充,没有JSX 转换虚拟 dom的过程,把大部分模板创建渲染的事都交给浏览器去做,提供了轻量的 api 让我们可以在 JS 中写 HTML-Templates。 Lit-Element 的 Reactive properties 、Scoped styles 等面向现代化 JS 语法的特点让他现在很受欢迎。 Google 推荐新用户使用 lit,但也将 Polymer 推到了 3.0 版本,放弃了 HTML Imports 转向 JS modules,并且支持 Polymer 跟 lit 混用,目前持续又维护和支持,Slack Channel 上一直很活跃。

除了 Google 自己, 微软的 PWA stater GitHub – pwa-builder/pwa-starter: Welcome to the PWABuilder pwa-starter! Looking to build a new Progressive Web App and not sure where to get started? This is what you are looking for!,选择 lit 框架和 封装的 Web Components 作为基础库。 Adobe 基于 LitElement 封装并开放了 Spectrum Web ComponentsSap 基于 Lit-html 封装并开源了 ui5-webcomponents/02-custom-UI5-Web-Components.md at master · SAP/ui5-webcomponents · GitHubRed hat  GitHub – 1-Platform/op-components: One platform component library.等众多公司使用了 lit 开发自己的组件库或平台。

另一个类库 GitHub – skatejs/skatejs: Effortless custom elements powered by modern view libraries. 也是基于 lit-html 的。

 

Web Components  头部案例

目前生成环境使用Web Components 的案例有这些(非全部使用!)

Twitter

Twitter 2016 年开始将自己的嵌入式推文  从 iframe 切换成  ShadowDOM,减少了内存消耗、加快了渲染速度,并批量渲染的时候保持丝滑。Upcoming Change to Embedded Tweet Display on Web

Youtube

Youtube 作为 google 系的产品,很早就在全站用上了 Web Cmponents,并且开源了自己播放器组件 GitHub – GoogleWebComponents/google-youtube: YouTube video playback web component此外 google 开源的 Web Components 还是很多的,Google Web Components · GitHub ,包括地图、drive、日历等等。

Google Earth:

Google Earth 的网页版使用了Web Components技术来创建用户交互界面的一部分。

EA

EA 的游戏工作室分布在全球各地,为了保证不同团队和工作室的设计开发体验统一,EA 基于 Web Components 构建了自己的 Network Design System,同时也支持这自己的 UIaaS。

Github

github 对 Web Components 的使用很早,具体可以看:  How we use Web Components at GitHub | The GitHub Blog2014 年 Custom Elements v0 specification 出现的时候 github 就开始关注:Search · topic:web-components org:github · GitHub,并且开源了其中一系列 Web Components GitHub – github/github-elements: GitHub’s Web Component collection.2017 年 Custom Elements v1 版本在 chrome 和 safari 上相继实现之后,github 开始大范围使用

要知道 github 2018 年才刚刚完全移除 JQueryRemoving jQuery from GitHub.com frontend | The GitHub Blog 这既得益于 github 自身项目组件化的架构,也 Web Components 本身与框架无关的特性非常识合作老项目升级。

github 还开源了 用于开发Web Components 的库 Catalyst:GitHub – github/catalyst: Catalyst is a set of patterns and techniques for developing components within a complex application.

而他的思路借鉴了  Stimulus  和  LitElement

  • 既然提到了 Stimulus,就叉开讲讲这个东西,Stimulus 很适合对老项目改造,尤其是 ruby on rails、jsp 服务端渲染、没有 webpack 之类的前端工具链,技术栈多且混乱的项目。Stimulus 的思路就是通过 MutationObserver 监控元素的变化, 然后取元素、补绑事件或者修改引用。他的定位就很轻盈,就是配合HTML页面,提供动态交互支持,不像现在的很多框架,动辄就是整站重写。

同时 github 还开源了一个 View Component 框架用来在 ruby on rails 里面构建同构应用GitHub – github/view_component: A framework for building reusable, testable & encapsulated view components in Ruby on Rails.

SalesForce

SalesForce 作为一家 ToB 服务的公司,面对各种不同技术栈的客户,选择 Web Components 原因有两点,一是需要一套统一的通用组件面向所有客户,二是在很多特定领域,很多客户很难对他们的传统技术体系做大规模升级,而引入 Web Components 可以避免这类技术改造风险。

他们开源了自己的 Web Components 组件库 Component Library,并提供一整套基于 的企业级研发工具 GitHub – salesforce/lwc: LWC – A Blazing Fast, Enterprise-Grade Web Components Foundation除了通过 LWC,让客户可以在自己的环境中基于组件库配置、开发、部署应用,SalesForce 还开放了自己的 SalesForce 工作平台 ,平台为所有客户提供一站式配置、部署和升级的能力。

Oracle

Oracle 在 2017 年开始在自己的  GitHub – oracle/oraclejet: Oracle JET is a modular JavaScript Extension Toolkit for developers working on client-side applications. 构建工具中增加了对 CustomElement 的支持,在此之前是用的是 jQueryUI。Oracle 对 WebComponents 对态度其实很值得 ToB 同行学习,他并没有刻意想拜托 jQuery,而是让 WebComponents 与现有的 jQuery、Knockout 并行使用,只在新功能上推进 WebComponents ,保持老项目稳定,在历史遗留和新技术之间保持了合理的平衡。而在 jet 的生态方面,他们也在持续建设 Web Component 驱动的共享组件中心 Building the future of Oracle JET Ecosystem | by João Tiago | Digital Transformation Research Group | Medium

ING:

荷兰国际集团(ING)在他们的网站和网上银行平台中大量使用了 Web Components,他们通过使用 Lion Web Components 库共享跨项目的UI组件。

Comcast:

Comcast 的 Xfinity产品线中的某些web应用使用了 Web Components。

Adobe Spectrum:

该站点是一个基于 Web Components 的 UI 框架产品

 

 

参考文章:

神奇的Shadow DOM https://jelly.jd.com/article/6006b1045b6c6a01506c87ac

Vue3.2 实现 Web Components https://ainyi.com/125

https://www.albertaz.com/blog/web-components-ststus

 

 

转载本站文章《Web Components从技术解析到生态应用个人心得指北》,
请注明出处:https://www.zhoulujun.cn/html/webfront/SGML/htmlBase/2012_0823_9020.html

mysql和redis库存扣减和优化 - Scotyzh - 博客园

mikel阅读(294)

来源: mysql和redis库存扣减和优化 – Scotyzh – 博客园

前言

大流量情况下的库存是老生常谈的问题了,在这里我整理一下mySQL和redis应对扣除库存的方案,采用jmeter进行压测。

JMETER设置

库存初始值50,线程数量1000个,1秒以内启动全部,一个线程循环2次,共2000个请求

MySQL方案

初始方案

    <update id="decreaseStock">
        UPDATE stock
        SET stock_num = stock_num - 1
        WHERE id = #{id}
    </update>

这种情况下,在并发条件肯定会出现超卖的

image-20240109153257263

进行修改:

    <update id="decreaseStock">
        UPDATE stock
        SET stock_num = stock_num - 1
        WHERE id = #{id} AND stock_num >= 1
    </update>

增加AND stock_num >= 1条件,即可避免超卖。

image-20240109153241745

相关代码:

    @PostMapping(value = "/decreaseStock/{id}")	
    public ResponseEntity<Object> decreaseStock(@PathVariable("id") Integer id) {
        int result = stockService.decreaseStock(id);
        return result == 1 ? new ResponseEntity<>("decreaseStock successfully", HttpStatus.OK) : new ResponseEntity<>("decreaseStock failed", HttpStatus.OK);
    }

压测情况:image-20240109170237724

根据Throught可知一秒可以处理200个事务(TPS)

如果说系统的并发量不高,则可以以这种方案进行防止库存超卖,但要注意,在可重复读隔离级别情况下,如果where的条件字段没有索引的话,进行update语句会使整个表被锁住,如果这里使用的where条件不是主键id而是product_name,那么需要给这个字段加索引。

在RR可重复读隔离级别下,如果where条件没有命中索引,那么会基于next-key lock(记录锁和间隙锁的组合)对整个表的所有记录加上这个锁,进行全表扫描,这个时候其他记录想要更新就会被阻塞。

但是不一定是有了索引就不会锁住整个表,这是由优化器决定的,可以使用Explain语句来查看当前语句是走的索引还是全表扫描,如果优化器走的还是全标扫描,可以使用 force index([index_name]) 强制使用某个索引。

改进

在MySQL情况下还能有其他方案来提升性能吗,在不借助Redis的情况(曾经面试招银网络被问了这道题)

我当时给出的回答是,把单个商品的库存比如50个库存,拆分成好几份,一份10个,5份库存,由于秒杀情况下流量很大,可以把这五份库存分别放到五个数据库里面,这样性能至少是原先方案的5倍,那么还会出现新的问题,就是有些问题,负载均衡上的问题,可能会出现某些库里还存在库存,但是请求却没有打进这个数据库,而是打到库存已经没有的数据库里面。我当时的想法是再搞个库存表,这个库存表采集各个商品的总库存以及商品在各个分库里面的库存数量,然后再写个服务,包含负载均衡的算法,将用户的请求平均打到各个分库去,当某个分库的库存达到0的时候,去通知该服务,服务将这个库剔除,使新的请求不会转发过去。实际这种情况也是存在问题的,高并发下库存为0的库来不及被剔除,也会导致请求被打到库存0的库。

Redis方案

将库存暂时放到Redis,然后从Redis进行库存扣减,能大大提升性能

压测结果:

image-20240109170010201

可见性能几乎是MySQL的10倍了,但是这样子在Redis里面会导致超卖

要确保Redis不超买,需要先查询当前的数量,如果大于0则进行扣减,并且查询和扣减需要为原子性,这里就需要借助lua脚本,将这两次操作写到一起。

加了Lua脚本的代码:

    private static final String LUA_DECRESE_STOCK_PATH = "lua/decreseStock.lua";

    @PostMapping(value = "/decreaseStockByRedis/{id}")
    public ResponseEntity<Object> decreaseStockByRedis(@PathVariable("id") Integer id) {

        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptSource(new ResourceScriptSource(new ClassPathResource(LUA_DECRESE_STOCK_PATH)));
        redisScript.setResultType(Long.class);
        
        // 执行Lua脚本
        Long result = (Long) redisTemplate.execute(redisScript, Collections.singletonList(id));

        // 返回结果判断
        return (result != null && result == 1) ? new ResponseEntity<>("decreaseStock successfully", HttpStatus.OK) : new ResponseEntity<>("decreaseStock failed", HttpStatus.OK);
    }

lua脚本放在resource/lua/decreseStock.lua

local key = KEYS[1]

-- 检查键是否存在
local exists = redis.call('EXISTS', key)
if exists == 1 then
    -- 键存在,获取值
    local value = redis.call('GET', key)
    if tonumber(value) > 0 then
        -- 如果值大于0,则递减
        redis.call('DECR', key)
        return 1  -- 表示递减成功
    else
        return 0  -- 表示递减失败,值不大于0
    end
else
    return -1  -- 表示递减失败,键不存在
end

Redis同步库存到MySQL

但是在Redis扣减了库存,总需要同步到MySQL里面

@PostMapping(value = "/decreaseStockByRedis/{id}")
    public ResponseEntity<Object> decreaseStockByRedis(@PathVariable("id") Integer id) {

        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptSource(new ResourceScriptSource(new ClassPathResource(LUA_DECRESE_STOCK_PATH)));
        redisScript.setResultType(Long.class);

        // 执行Lua脚本
        Long redisResult = (Long) redisTemplate.execute(redisScript, Collections.singletonList(id));
        int dataBaselResult = 0;
        if (redisResult == 1) {
            dataBaselResult = stockService.decreaseStock(id);
        }
        // 返回结果判断
        return (dataBaselResult == 1 && redisResult == 1) ? new ResponseEntity<>("decreaseStock successfully", HttpStatus.OK) : new ResponseEntity<>("decreaseStock failed", HttpStatus.OK);
    }

直接按照上述代码来写,删Redis后同时将库存同步到MySQL,相当于使用了Redis性能又没有提升。

其实选择了Redis来进行库存扣减,那么MySQL的库存并不需要去实时进行更新,只需要库存达到最终一致性即可,即先对Redis的库存进行更新,然后再异步同步到MySQL的库存。

如果使用spring的异步线程来解决,会不会出现同步MySQL失败导致数据最终不一致呢,在流量很多的情况下,系统本身就处于压力大的情况,再使用异步线程会占用额外的资源,最好的方法是引入MQ,把库存的同步信息交给MQ,MQ再交到消费系统,进行减库存的操作,由MQ保证消息被消费,实现最终一致性。

部分代码如下,由MQ product发出,再由consumer进行消费:

    private final DecreaseStockProduce decreaseStockProduce;

    @PostMapping(value = "/decreaseStockByRedis/{id}")
    public ResponseEntity<Object> decreaseStockByRedis(@PathVariable("id") String id) {

        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
        redisScript.setScriptSource(new ResourceScriptSource(new ClassPathResource(LUA_DECRESE_STOCK_PATH)));
        redisScript.setResultType(Long.class);

        // 执行Lua脚本
        Long redisResult = (Long) redisTemplate.execute(redisScript, Collections.singletonList(id));
        if (redisResult == 1) {
            // 发送消息
            try {
                DecreaseStockEvent decreaseStockEvent = DecreaseStockEvent.builder()
                        .id(id)
                        .build();
                SendResult sendResult = decreaseStockProduce.sendMessage(decreaseStockEvent);
                if (!Objects.equals(sendResult.getSendStatus(), SendStatus.SEND_OK)) {
                    log.error("消息发送错误,请求参数:{}", id);
                }
            } catch (Exception e) {
                log.error("消息发送错误,请求参数:{}", id, e);
            }
        }

        // 返回结果判断
        return (redisResult == 1) ? new ResponseEntity<>("decreaseStock successfully", HttpStatus.OK) : new ResponseEntity<>("decreaseStock failed", HttpStatus.OK);
    }

MQ [TIMEOUT_CLEAN_QUEUE] broker busy问题

这里直接压测会报下面的错误,并且这个时候查看redis库存已经减到0,到是MySQL只减到了37

针对MQ [TIMEOUT_CLEAN_QUEUE] broker busy问题,需要去修改MQ的broker.conf文件

image-20240111165139373

针对TIMEOUT_CLEAN_QUEUE broker busy问题,需要去修改MQ的broker.conf文件,上述的201ms超时了,我这里将等待时间改为400,并且将线程数设置为64,这个线程数可以根据实际压测情况进行调整。

# 发消息线程池数量
sendMessageThreadPoolNums=64
# 拉消息线程池数量
pullMessageThreadPoolNums=64
waitTimeMillsInSendQueue=400

现在再进行压测,发现tps能跑到1000,相比直接入库mysql的200已经是提升很大了。

虽然性能提高,也实现库存的同步,但这个性能下还是会存在一些问题:

比如MQ消息发送失败、或者MySQL库存扣减失败,并且实际情况还有订单的生成和库存之间的一致性也要考虑。

对于上述这些问题,可以查看我的另外一篇博客:

RocketMQ事务消息在订单创建和库存扣减的使用 – Scotyzh – 博客园 (cnblogs.com)

【经典问题】mysql和redis数据一致性问题 - Scotyzh - 博客园

mikel阅读(276)

来源: 【经典问题】mysql和redis数据一致性问题 – Scotyzh – 博客园

前言

MySQL和Redis数据一致性算是个很经典的问题,在之前也看到过很多相关的文章,最近心血来潮,想把一致性问题的解决方案和存在问题都总结一下。

不推荐方案

1 先更新MySQL,再更新Redis。

image-20240103204207546

如上图有两个请求要同时进行更新操作,在并发情况下,B请求虽然更新时间晚于A请求,但是可能因为网络延迟问题,导致本来A请求要先更新Redis的操作晚于B请求更新Redis的操作,最终导致了MySQL出现数据不一致。

2 先更新Redis,在更新MySQL。

image-20240103204224684

这种情况其实等同于第一种情况。

3 先删除Redis缓存,再更新MySQL。

image-20240103204235856

A请求对数据的更新操作晚于请求B的读取操作,导致B请求将数据库的旧值又写回缓存,删除缓存在这种情况下没有意义。

推荐方案

1 先删除Redis缓存,再更新MySQL,再删一次Redis缓存(延迟双删)

image-20240103205637142

在第三种情况中,出现了删除缓存后被其他请求更新为旧值的情况,那么在这种情况下,再删除一遍缓存不就可以解决问题了。这里第二次删除缓存的时间必须在B请求回写旧值之后,所以要社招好第二次删除缓存的等待时间,根据业务实际耗时来定,假设B请求回写缓存要300ms,那么A请求可以设置等待500ms再进行缓存删除。

但是上面这种情况也会出现问题,比如延迟双删的时候删除缓存失败怎么办。

这个时候可以借助MQ重试机制。如下图:

image-20240104092831624

将删除的请求放到MQ队列里面,然后系统再从MQ里面取出删除请求的操作,由于MQ支持失败重试,删除失败后会继续投递消息。

2 先更新MySQL,再删除Redis缓存。

image-20240104094222584

在上面这种情况下,请求B出现了读取了一次旧值,如果对于业务是一致性要求没那么强的话(比如秒杀,减库存),这种方案也是可以的,误差范围是可以接收的,只存在这么一次数值是旧的情况。

当然还有特殊情况如下:

image-20240104095635485

当B请求先查询Redis,这个时候redis刚好缓存失效,B请求就会去MySQL查询旧值,后续B请求回写旧值的请求又晚于A请求删除缓存的请求,导致缓存里面放的是旧值。

但是这种情况出现需要 同时满足以下两个条件:

(1)缓存刚好失效

(2)读请求回写缓存的时间晚于写请求回写缓存的时间

上述两个条件同时成立的概率是极小的,综上来说,这种方案还是不错的,复杂度也不高,但同时也是可能存在删除缓存失败的特殊情况导致误差。

3 先更新MySQL,通过 Binlog,异步更新 Redis

image-20240104101137111

A请求更新完MySQL,借助Canal进行监听并把相关的修改记录推送到MQ,MQ经过消费系统拉取消息对Redis进行更新,如果在Redis更新之前,有新的读请求,依然会导致数据不一致性的问题,但是这种方案能够实现最终一致性。

在这里Canal作为一个组件,监听binlog和发送消息到MQ都由Canal完成。

方案总结

前三种方案都是不推荐使用的。对于推荐使用的方案,从实时性和技术复杂度来说,先写数据库再删除缓存是比较好的选择。如果要确保最终一致性的话,可以用binlog异步更新缓存的方案。