博客 (39)

按这两篇文章部署即可：

ASP.NET Core 缓存（Cache）之 Redis 缓存

ASP.NET Core 会话状态（Session State）

存储内容示例：

图中，

第 1 项为浏览器 A 中，在 Session 中设置键 count 值为 1 的结果；

第 2 项为浏览器 B 中，在 Session 中设置键 count 值为 3 的结果；

而第 3 项为设置 Cache 键 count 值为 8 的结果。

按这两篇文章部署即可：

ASP.NET Core 缓存（Cache）之 SQL Server 缓存

ASP.NET Core 会话状态（Session State）

存储内容示例：

图中，

第 1 项为浏览器 A 中，在 Session 中设置键 count 值为 3 的结果；

第 3 项为浏览器 B 中，在 Session 中设置键 count 值为 1 的结果；

而第 2 项为设置 Cache 键 count 值为 5 的结果。

ASP.NET Core 缓存 Caching 提供了包括但不限于以下几种存储方式：

内存缓存：https://xoyozo.net/Blog/Details/aspnetcore-memory-cache

SQL Server 缓存：https://xoyozo.net/Blog/Details/aspnetcore-sql-cache

Redis 缓存：https://xoyozo.net/Blog/Details/aspnetcore-redis-cache

MySQL 缓存：https://xoyozo.net/Blog/Details/aspnetcore-mysql-cache

Nuget 安装：Microsoft.Extensions.Caching.SqlServer

执行 .NET Core CLI 命令，在数据库中创建表“TestCache”

dotnet sql-cache create "数据库连接字符串" dbo TestCache

若提示

找不到 "dotnet sql-cache" 命令，请运行以下命令进行安装

则运行

dotnet tool install --global dotnet-sql-cache

表和索引创建成功提示：

Table and index were created successfully.

表结构：

在 Startup.cs 文件的方法 ConfigureServices() 中添加：

services.AddDistributedSqlServerCache(options =>
{
    options.ConnectionString = "数据库连接字符串";
    options.SchemaName = "dbo";
    options.TableName = "TestCache";
});

在控制器中注入 IDistributedCache：

public class TestController : Controller
{
    private readonly IDistributedCache cache;

    public TestController(IDistributedCache cache)
    {
        this.cache = cache;
    }

    public IActionResult Index()
    {
        string k = "count";
        int v = Convert.ToInt32(cache.GetString(k));
        v++;
        cache.SetString(k, v.ToString());
        return Content(v.ToString());
    }
}

结果：

更多用法详见官方文档：https://docs.microsoft.com/zh-cn/aspnet/core/performance/caching/distributed?view=aspnetcore-3.0

若要实现将 Session 保存至 SQL Server 中，参此文：https://xoyozo.net/Blog/Details/aspnetcore-session-sql

ASP.NET Core 缓存 Caching 提供了包括但不限于以下几种存储方式：

内存缓存：https://xoyozo.net/Blog/Details/aspnetcore-memory-cache

SQL Server 缓存：https://xoyozo.net/Blog/Details/aspnetcore-sql-cache

Redis 缓存：https://xoyozo.net/Blog/Details/aspnetcore-redis-cache

MySQL 缓存：https://xoyozo.net/Blog/Details/aspnetcore-mysql-cache

Nuget 安装：Microsoft.Extensions.Caching.StackExchangeRedis

在 Startup.cs 文件的方法 ConfigureServices() 中添加：

services.AddStackExchangeRedisCache(options =>
{
    // 连接字符串
    options.Configuration = "192.168.111.134,password=aW1HAyupRKmiZn3Q";
    // 键名前缀
    options.InstanceName = "xoyozo_";
});

在控制器中注入 IDistributedCache：

public class TestController : Controller
{
    private readonly IDistributedCache cache;

    public TestController(IDistributedCache cache)
    {
        this.cache = cache;
    }

    public IActionResult Index()
    {
        string k = "count";
        int v = Convert.ToInt32(cache.GetString(k));
        v++;
        cache.SetString(k, v.ToString());
        return Content(v.ToString());
    }
}

结果：

更多用法详见官方文档：https://docs.microsoft.com/zh-cn/aspnet/core/performance/caching/distributed?view=aspnetcore-3.0

注：.NET 6 已不支持 Redis on Windows 3.0。

经过以上配置，Session 也会保存到 Redis 中，键名是 前缀_Guid 格式。

关于 Session，参此文：https://xoyozo.net/Blog/Details/aspnetcore-session-redis

要将 ASP.NET Core 中的会话存储在 Redis 中，可以按照以下步骤进行操作：

安装必要的 NuGet 包：

首先，确保你已经安装了 Microsoft.Extensions.Caching.StackExchangeRedis 包，这是与 Redis 集成的主要包。

在 Visual Studio 中，你可以使用 NuGet 包管理器控制台执行以下命令：

Install-Package Microsoft.Extensions.Caching.StackExchangeRedis

配置 Redis 连接：

在你的 ASP.NET Core 应用程序的 Startup.cs 文件中，使用 AddStackExchangeRedisCache 方法配置 Redis 连接。在 ConfigureServices 方法中添加以下代码：

services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = "your_redis_connection_string";
    options.InstanceName = "your_instance_name";
});

请将 "your_redis_connection_string" 替换为你的 Redis 连接字符串，并将 "your_instance_name" 替换为你的 Redis 实例名称。

配置会话中间件：

在 Startup.cs 的 ConfigureServices 方法中，使用 AddSession 方法配置会话中间件，并在 Configure 方法中启用它：

services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(30); // 设置会话超时时间
});

使用会话中间件：

在 Startup.cs 的 Configure 方法中，在调用 app.UseRouting() 之前添加以下代码来启用会话中间件：

app.UseSession();

在控制器或视图中使用会话：

现在，你可以在控制器或视图中使用会话来存储和检索数据。例如：

// 存储数据到会话
HttpContext.Session.SetString("Key", "Value");

// 从会话中检索数据
var value = HttpContext.Session.GetString("Key");

通过这种方式，你可以将会话数据存储在 Redis 中，而不是默认的内存中。

请确保根据你的应用程序的需求进行适当的配置和安全措施，以确保 Redis 连接的安全性和可靠性。

ASP.NET Core 缓存 Caching 提供了包括但不限于以下几种存储方式：

内存缓存：https://xoyozo.net/Blog/Details/aspnetcore-memory-cache

SQL Server 缓存：https://xoyozo.net/Blog/Details/aspnetcore-sql-cache

Redis 缓存：https://xoyozo.net/Blog/Details/aspnetcore-redis-cache

MySQL 缓存：https://xoyozo.net/Blog/Details/aspnetcore-mysql-cache

本文介绍内存缓存

Memory Caching

1.新建一个 ASP.NET Core 项目，选择 Web 应用程序，将身份验证 改为 不进行身份验证。

2.添加引用

Install-Package Microsoft.Extensions.Caching.Memory

3.使用

在 Startup.cs 中 ConfigureServices

public void ConfigureServices(IServiceCollection services)
{
    services.AddMemoryCache();
    // Add framework services.
    services.AddMvc();
}

然后在

public class HomeController : Controller
{
    private IMemoryCache _memoryCache;
    public HomeController(IMemoryCache memoryCache)
    {
        _memoryCache = memoryCache;
    }

    public IActionResult Index()
    {
        string cacheKey = "key";
        string result;
        if (!_memoryCache.TryGetValue(cacheKey, out result))
        {
            result = $"LineZero{DateTime.Now}";
            _memoryCache.Set(cacheKey, result);
        }
        ViewBag.Cache = result;
        return View();
    }
}

这里是简单使用，直接设置缓存。

我们还可以加上过期时间，以及移除缓存,还可以在移除时回掉方法。

过期时间支持相对和绝对。

下面是详细的各种用法。

public IActionResult Index()
{
    string cacheKey = "key";
    string result;
    if (!_memoryCache.TryGetValue(cacheKey, out result))
    {
        result = $"LineZero{DateTime.Now}";
        _memoryCache.Set(cacheKey, result);
        //设置相对过期时间2分钟
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .SetSlidingExpiration(TimeSpan.FromMinutes(2)));
        //设置绝对过期时间2分钟
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .SetAbsoluteExpiration(TimeSpan.FromMinutes(2)));
        //移除缓存
        _memoryCache.Remove(cacheKey);
        //缓存优先级 （程序压力大时，会根据优先级自动回收）
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .SetPriority(CacheItemPriority.NeverRemove));
        //缓存回调 10秒过期会回调
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .SetAbsoluteExpiration(TimeSpan.FromSeconds(10))
            .RegisterPostEvictionCallback((key, value, reason, substate) =>
            {
                Console.WriteLine($"键{key}值{value}改变，因为{reason}");
            }));
        //缓存回调 根据Token过期
        var cts = new CancellationTokenSource();
        _memoryCache.Set(cacheKey, result, new MemoryCacheEntryOptions()
            .AddExpirationToken(new CancellationChangeToken(cts.Token))
            .RegisterPostEvictionCallback((key, value, reason, substate) =>
            {
                Console.WriteLine($"键{key}值{value}改变，因为{reason}");
            }));
        cts.Cancel();
    }
    ViewBag.Cache = result;
    return View();
}

Distributed Cache Tag Helper

在 ASP.NET Core MVC 中有一个 Distributed Cache 我们可以使用。

我们直接在页面上增加 distributed-cache 标签即可。

<distributed-cache name="mycache" expires-after="TimeSpan.FromSeconds(10)">
    <p>缓存项10秒过期-LineZero</p>
    @DateTime.Now
</distributed-cache>
<distributed-cache name="mycachenew" expires-sliding="TimeSpan.FromSeconds(10)">
    <p>缓存项有人访问就不会过期，无人访问10秒过期-LineZero</p>
    @DateTime.Now
</distributed-cache>

这样就能缓存标签内的内容。

这是一篇可能解决困扰了 .NET 程序猿多年的文章！

首先，使用 Visual Studio 2019 创建一个 ASP.NET WEB 应用程序，直接选用了 MVC 模板。

直接发布项目，默认的设置如下图：

对于小型项目，按默认设置发布基本可满足正常运行，首次运行打开第一个页面基本在 5~6 秒（视服务器配置），其它页面的首次打开也基本在 1~2 秒完成，非首次瞬间打开。

一旦项目功能变得复杂，文件增多，会导致发布后首次运行打开第一个页面 30 秒以上，其它页面的首次打开 10 秒左右，非首次瞬间打开。

这是因为项目在发布时没有进行预编译，而是在用户访问网页时动态编译，一旦应用程序池回收，或项目文件改动，都会重新编译，再次经历缓慢的“第一次”，这是不能忍的。

于是咱们来研究一下“预编译”。

在发布页面勾选“在发布期间预编译”，这时发布会在“输出”窗口显示正在执行编译命令（编译时间会比较长）：

该选项对发布后的文件结构和内容影响不大，因此对首次执行效率的提升也不大，重要的在后面。

在“高级预编译设置”窗口中：

我们针对预编译选项和合并选项分别做测试。

不勾选“允许更新预编译站点”，会致 bin 目录中生成许多 .compiled 文件，而所有 .cshtml 文件的内容都是：

这是预编译工具生成的标记文件，不应删除!

如果是 Web From 网站，.aspx/.ashx 等文件内容同上。

尝试打开网站页面，你会发现，除了项目启动后的第一个页面仍然需要 1~2 秒（无 EF），其余每个页面的首次都是瞬间打开的（EF 的首次慢不在本文讨论范围）。这让我对预编译有一种相见恨晚的感觉！

这里偷偷地告诉你，把 Views 目录删掉也不影响网页正常打开哦~为什么不让删，咱也不敢问，咱也不敢删。

目的达到了，有一些后遗症需要解决，比如 bin 目录内杂乱无章。

选“不合并。为每个页面和控件创建单独的程序集”，结果是 bin 多出许多 App_Web_*.dll 文件。

选“将所有输出合并到单个程序集”，填写程序集名称。这时会发现“输出”窗口执行了命令：

如果程序集名称跟已有名称冲突，会发生错误：

合并程序集时出错: ILMerge.Merge: The target assembly '******' lists itself as an external reference.

查看 bin 目录，.compiled 文件还在，但 App_Web_*.dll 合并成了一个程序集。FTP 的“不合并”也是把所有 App_Web_*.dll 上传一遍，所以不存在相对于“合并”的增量发布优势。

是不是勾了“视为库组件删除(AppCode.compiled 文件)”.compiled 文件就会不见？意外之外，情理之中，bin 没有什么变化。

继续选择“将各个文件夹输出合并到其自己的程序集”，呃，bin 中文件数不降反增。

最后选择“将所有页和控件输出合并到单个程序集”，同样程序集名称不能冲突。结局令人失望，bin 中仍然一大堆 .compiled 和 App_Web_*.dll。

整理成表格：

bin 目录下，页面的程序集文件（App_Web_*.dll）增多的原因是编译后的文件名不固定，发布到会导致残留许多无用的程序集文件。

相比较，如果第 3 种能实现 FTP 稳定的增量上传的话是比较完美的（还有一个缺点是：如果页面有删除，目标 bin 内对应该页面的 .compiled 和 .dll 不会删除，这跟“允许更新预编译站点”是一个情况），那么第 4 种 或第 5 种也是不错的选择（同样有缺点：执行合并比较慢）。

测试一个有 300 个页面的项目，compiler 用时约 2 分钟，merge 用时约 5 分钟，发布用时约 4 分钟。

这里有个槽点，执行预编译和合并是佛系的，CPU 和磁盘使用率永远保持在最低水平。

所以如果是要经常修改的项目，那么建议选择“不合并”的第 3 种发布方式：

“视为库组件（删除 AppCode.compiled 文件）”：移除主代码程序集（App_Code 文件夹中的代码）的 .compiled 文件。 如果应用程序包含对主代码程序集的显式类型引用，则不要使用此选项。

补充：

• 不允许更新预编译站点发布后，因为前端页面没有内容，因此无法单独修改发布（单独发布一个页面后，在访问时不会生效！），只能全站发布，耗时较长；bin 目录有变动将导致使用 InProc 方式存储的 Session 丢失。

• 预编译的另一个优点是可以检查 .aspx / .cshtml 页面 C# 部分的错误（特别是命名空间和路径引用）。

• 改为预编译发布后，可以将服务器上残留的 .master / .ascx / .asax 删除，但不能删除 .aspx / .ashx /.config 等。
  

• VS 发布到 FTP 经常会遗漏一些页面文件，不合并时会遗漏独立文件，合并后也会遗漏合并后的 .dll 的文件，合并的好处就是方便检查是否完全上传发布。

• 慎选“在发布前删除所有现有文件”！一旦勾选发布，世界就清静了，所有网友上传的图片附件以及网站运行产生的其它文件，消失得无影无踪。不管发布到文件系统还是发布到 FTP 都一样。当然，如果是先发布到文件系统，再通过 FileZilla 等 FTP 软件上传到服务器的，建议勾选此项。

• .NET Core 应用程序部署：https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index

• 由于上传文件时 bin 目录文件较多，理论上 bin 目录内的文件有任何改动都会重启应用池，而且 VS 是单线程上传的，导致期间网站访问缓慢，服务器 CPU 升高，我的做法是：发布到文件系统，再使用专用 FTP 工具上传，上传用时约半分钟（如果大小不同或源文件较新则覆盖文件）。还嫌慢？那就打包上传，解压覆盖。

• 关于本文研究对象的官方解释：高级预编译设置对话框

• 出现“未能加载文件或程序集“***”或它的某一个依赖项。试图加载格式不正确的程序。”的问题时，先用改用 Debug 方式发布会报详细错误，一般是 .aspx 等客户端页面有 C# 语法问题，注意提示报错的是 /obj/ 目录下的克隆文件，应更改原文件。排除错误后关闭所有页面，再使用 Release 方式发布。

• 2025年9月补充：因预编译发布后生成的文件时间都是系统最新时间，通过 FTP 上传到服务器时都会覆盖文件，可能导致杀毒软件进程 MsMpEng.exe 占用 CPU 过高。尝试选择不进行预编译，即取消“发布期间预编译”前的勾，这样发布的的文件时间都是文件本身的最后修改时间，重复发布不会更新这个时间，而且 bin 目录中也不会出现大量编译后的文件。这样通过 FTP 上传时只要设置“大小不同且文件较新则覆盖”就不会重复上传文件了，杀毒软件的工作量就能大大减少。缺点就是本文开头说的，每个页面的第一次打开会比较慢，而是非常慢。所以仍然需要勾选“发布期间预编译”，同时勾上“允许更新预编译站点”，这样 bin 目录中不会发现很多文件（合并不合并都一样），打开每个页面的第一次耗时也能在接受范围内。
  

CloudFS 是一款将阿里云 OSS 对象存储挂载为 Linux 本地目录的工具软件，目前已经从阿里云市场下架了。

在云监控中查看到进程 cloudfs 占用大部分内存，可以打开文件 /usr/local/cloudfs/conf/cloudfs.conf 进行配置。

默认值：

BLOCK_SIZE=1048576

MAX_CACHE_LIMITS=10485760

根据实际情况进行修改，然后重启 cloudfs，相关命令：

启动：service cloudfs start

停止：service cloudfs stop

重启：service cloudfs restart

查看状态：service cloudfs status

在 MySQL 中，int 的取值范围是 [-2147483648, 2147483647]，占用 4 个字节。

int(M) 中 M 的默认值为 11，该值不影响取值范围和占用字节，仅表示最大显示宽度。

以某 int 字段存储的记录值为 2147483647 为例：

类型为 int(1) 时，SELECT 结果为 214
类型为 int(2) 时，SELECT 结果为 2147
……
类型为 int(7) 时，SELECT 结果为 214748364
类型为 int(8) ~ int(11) 时，SELECT 结果为 2147483647

测试结果跟网上的说法不同

如果添加了 zerofill 属性，当然是填充零的效果，仍以上述值为例：

类型为 int(1) 时，SELECT 结果为 214
类型为 int(2) 时，SELECT 结果为 2147
……
类型为 int(7) 时，SELECT 结果为 214748364
类型为 int(8) ~ int(10) 时，SELECT 结果为 2147483647
类型为 int(11) 时，SELECT 结果为 02147483647

结论，既然 M 值不影响取值范围和占用字节，那么何必去改它呢。除非有特殊业务需求，否则很容易引起逻辑混乱，特别是当你误认为它是用来限定取值范围或节省存储空间的时候。

Session 有多种存储模式，默认是 InProc，顾名思义是“在进程内”，即在 IIS 中，随网站重启而重启，网站发布后（或改动 .dll 文件）会导致应用重新运行，Session 清空。

Session 可以使用 StateServer 来保存，需要服务器开启 ASP.NET State Service 服务，此种方式要求保存在 Session 的信息必须序列化，然后从 Session 中获取的时候也要反序列化，这就导致性能有略微的损失。

Session 还可以配置为 SQLServer，将 Session 存储在数据库中，同样需要序列化。

当配置为 Custom 时，可以在使用 Memcached、Redis 等第三方缓存技术来实现 Session 的管理，本文不作讨论。

Off 模式即关闭 Session，这种方式如果要实现用户登录功能，就必须依赖 Cookie 等来实现。

下面针对常见的三种模式进行比较：

因此，如果你仅仅为了标题所述的“每次发布后丢失 Session”而烦恼，那么推荐使用 StateServer 模式来存储 Session。

注：

如果 Session 的 Key 是在应用启动时随机生成的话，使用 StateServer 和 SQLServer 还是会“丢失” Session。

这是对 Session 的配置，对 Cache 无效。