实体列表缓存(最土的办法实现百万级性能)

NewLife.XCode是一个有10多年历史的开源数据中间件,支持nfx/netcore,由新生命团队(2002~2019)开发完成并维护至今,以下简称XCode。

整个系列教程会大量结合示例代码和运行日志来进行深入分析,蕴含多年开发经验于其中,代表作有百亿级大数据实时计算项目。

开源地址:https://github.com/NewLifeX/X (求star, 765+)

 

全表缓存

在实际项目开发中,经常遇到有一些表数据很少(1000行以内),不会频繁修改(平均每行几个小时才会修改一次),例如配置表、分类表等。

这样的表,往往可以接受三五秒甚至更长的延迟,正是最适合使用缓存的地方。

 

实体缓存:一次性加载全表数据进入内存,供上层多维度查询!

 

来看一个例程:

实体列表缓存(最土的办法实现百万级性能)

实体列表缓存(最土的办法实现百万级性能)

实体列表缓存(最土的办法实现百万级性能)

根据查询日志可以看到,虽然执行了1000万次查询,实际上只有一行select日志输出,也就是只查了一次数据库,其它9,999,999次从缓存中查找。

实体缓存的查询速度只取决于 CPU主频,在这台AMD古董机上也可以轻松得到百万级速度。

最后一行是实体缓存统计日志,10秒输出第一次,然后每10分钟输出一次,统计了缓存数、请求数、命中率。

实体列表缓存(最土的办法实现百万级性能)

如上,7亿多次查询,命中率在99%以上。

 

使用实体缓存

实体缓存本质上就是一个实体列表 IList<TEntity>,可通过 Meta.Cache 快速访问。

该列表位于 Meta.Cache.Entities,在 Meta.Cache 上提供了 Find/FindAll 方法。

因为是 IList<TEntity>,所以适用所有Linq方法,如上面例子可以改为:Meta.Cache.Entities.FirstOrDefault(e => e.Name.EqualIgnoreCase(name))

 

XCode在生成实体类扩展查询代码时,默认都会带有实体缓存用法,当表行数小于1000时,走实体缓存:

if (Meta.Count < 1000) return Meta.Cache.Find(e => e.Name.EqualIgnoreCase(name));

如果不想使用实体缓存,注释这一行即可。除此之外,XCode内部任何地方不会主动使用实体缓存。

 

使用缓存的阈值

1000是一个大量实践得到的值:

小于1000时,内存搜索远胜于数据库,毕竟数据库还有网络开销和序列化为实体对象的开销;

大于10000时,内存搜索就不如数据库了;

1000到10000之间,内存搜索速度逐步下降,可根据场景决定阈值大小,例如数据极少修改且又需要进行范围搜索时甚至可以设为大于10000;

 

扩展属性优化

在前面《扩展属性》中提到过,XCode不支持多表关联,而是建议拆分为多次单表查询。查询简单化以后,就可以更容易的实现缓存优化。

还是学生班级的例子,为了在学生列表页展示班级名称,而学生表student只有班级编号classid字段,当时的做法是建立Class扩展属性,借助Class.FindByID查询。

因为班级数量不会特别多,更是极少修改,因此我们可以在Class.FindByID内部使用实体缓存,把所有班级都缓存起来。

至此,学生班级的多表关联查询,借助扩展属性和列表缓存,成功转化成为学生表单表查询,班级名称的匹配几乎毫无压力!

 

过期策略

所有缓存都必须有过期策略。实体缓存的过期策略有以下:

  • 初始化。首次访问缓存时,加锁阻塞所有访问线程,直到加载完全表数据。
  • 定时过期。缓存过期后,开异步线程更新并同时返回旧数据,确保应用层性能。设置文件的 EntityCacheExpire, 默认10秒
  • 添删改过期。对实体类的添删改操作完成后,都会直接修改实体缓存对应项,而不会清空整个列表。

显然,首次加载以后,将来访问的永远是定时更新的缓存数据,应用层可以得到非常好的性能!

由于实体缓存的添删改过期跟实体操作绑定在一起,因此,越过实体类直接DAL执行更新操作,或者其它服务器修改数据,此时无法影响实体缓存,导致数据更新不及时。

早期版本XCode实体缓存默认过期时间60秒,随着数据库性能提升,默认值修改为10秒,可根据实际场景设置。

上一篇:对象字典缓存(百万军中取敌首级)


下一篇:数据层缓存(网站性能翻10倍)