面向服务架构~全局配置文件也面向服务了~续(对性能的优化)

简介:

之所以写这一篇,是因为前一篇面向服务架构~全局配置文件也面向服务了提到了性能问题,所以在这一篇文章里,主要围绕着性能来对ConfigCache这个程序集进行重构。

要重构的点:

1 实例创建过多,引起不必要的性能消耗

2 将配置信息从文件读到内存时,然后在读内容时,去比较最后修改时间与内存中存储的时间是否相同 ,如果不同则重新从文件中读到信息到内存

解决第一个问题,很容易想到单例模式,这在我基础才是重中之重~延迟初始化文章中有对泛型单例的介绍,各位可以参考。

本例使用单例模式,创建配置信息实体对象,保存在使用这个对象时,只会被创建一次。

 1    /// <summary>
 2     /// 配置信息生产工厂
 3     /// </summary>
 4     public class ConfigFactory : Singleton<ConfigFactory>
 5     {
 6         private ConfigFactory()
 7         {
 8 
 9         }
10         #region 私有
11 
12         /// <summary>
13         /// 配置文件管理类
14         /// </summary>
15         static ConfigFilesManager cfm;
16 
17         #endregion
18 
19         #region 公开的属性
20         public T GetConfig<T>() where T : IConfiger
21         {
22             string configFilePath = string.Empty;
23             string filename = typeof(T).Name;
24 
25             HttpContext context = HttpContext.Current;
26             string siteVirtrualPath = string.IsNullOrEmpty(ConfigurationManager.AppSettings["SiteVirtrualPath"]) ?
27                 "/" : ConfigurationManager.AppSettings["SiteVirtrualPath"];
28             if (context != null)
29             {
30                 configFilePath = context.Server.MapPath(string.Format("{0}/Configs/{1}.Config", siteVirtrualPath, filename));
31             }
32             else
33             {
34                 configFilePath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"Configs\{0}.Config", filename);
35             }
36 
37             if (!File.Exists(configFilePath))
38             {
39                 throw new Exception("发生错误: 网站" +
40                     new FileInfo("fileName").DirectoryName
41                     + "目录下没有正确的.Config文件");
42             }
43 
44             cfm = new ConfigFilesManager(configFilePath, typeof(T));
45             return (T)cfm.LoadConfig();
46         }
47         #endregion
48 
49     }
 1 /// <summary>
 2     /// 泛型单例基类
 3     /// </summary>
 4     public abstract class Singleton<TEntity> where TEntity : class
 5     {
 6         private static readonly Lazy<TEntity> _instance
 7           = new Lazy<TEntity>(() =>
 8           {
 9               var ctors = typeof(TEntity).GetConstructors(
10                   BindingFlags.Instance
11                   | BindingFlags.NonPublic
12                   | BindingFlags.Public);
13               if (ctors.Count() != 1)
14                   throw new InvalidOperationException(String.Format("Type {0} must have exactly one constructor.", typeof(TEntity)));
15               var ctor = ctors.SingleOrDefault(c => c.GetParameters().Count() == 0 && c.IsPrivate);
16               if (ctor == null)
17                   throw new InvalidOperationException(String.Format("The constructor for {0} must be private and take no parameters.", typeof(TEntity)));
18               return (TEntity)ctor.Invoke(null);
19           });
20 
21         public static TEntity Instance
22         {
23             get { return _instance.Value; }
24         }
25     }

第二个问题,在ConfigFilesManager中已经处理的很完美,它会将上次读取文件的时间记录下来,与本次时间进行对比,如果相同,则直接从内容中取配置信息实体,否则,从文件中读取最新版本。

 1  #region 重设配置类实例
 2         /// <summary>
 3         /// 重设配置类实例
 4         /// </summary>
 5         /// <returns></returns>
 6         internal IConfiger LoadRealConfig()
 7         {
 8             lock (lockHelper)
 9             {
10                 DateTime newfileChangeTime = File.GetLastWriteTime(this.fileName);
11                 if (!newfileChangeTime.Equals(this.fileChangeTime))
12                 {
13                     IconfigInfo = ConfigSerialize.DeserializeInfo(ConfigFilePath, this.configType);
14                     this.fileChangeTime = newfileChangeTime;
15                 }
16             }
17             return IconfigInfo as IConfiger;
18         }
19         #endregion
 

本例中实体持久化到文件中,在读取信息时,是从文件到内存的反序列化的过程,对于双方的载体,其实也有其它实现的方式,如果文件持久化也可以用数据库来实现,而内存缓存机制也可以用Cache缓存来实现,下一篇,我会着重介绍一个.net Cache的用法。

相关文章:

面向服务架构~全局配置文件也面向服务了

面向服务架构~全局配置文件也面向服务了~续(对性能的优化)

面向服务架构~全局配置文件也面向服务了~再续(引入Cache机制)

本文转自博客园张占岭(仓储大叔)的博客,原文链接:面向服务架构~全局配置文件也面向服务了~续(对性能的优化),如需转载请自行联系原博主。

目录
相关文章
|
10天前
|
存储 数据挖掘 BI
2-5 倍性能提升,30% 成本降低,阿里云 SelectDB 存算分离架构助力波司登集团实现降本增效
波司登集团升级大数据架构,采用阿里云数据库 SelectDB 版,实现资源隔离与弹性扩缩容,查询性能提升 2-5 倍,总体成本降低 30% 以上,效率提升 30%,助力销售旺季高效运营。
60 1
|
2月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
165 0
|
4月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
12天前
|
机器学习/深度学习 存储 人工智能
RAG系统文本检索优化:Cross-Encoder与Bi-Encoder架构技术对比与选择指南
本文将深入分析这两种编码架构的技术原理、数学基础、实现流程以及各自的优势与局限性,并探讨混合架构的应用策略。
67 10
RAG系统文本检索优化:Cross-Encoder与Bi-Encoder架构技术对比与选择指南
|
5月前
|
机器学习/深度学习 人工智能 文件存储
Llama Nemotron:英伟达开源基于Llama架构优化的推理模型,253B参数持平DeepSeek R1!
NVIDIA推出的Llama Nemotron系列推理模型,基于Llama架构优化,包含Nano/Super/Ultra三款,在数学推理、编程和工具调用等任务中展现卓越性能。
144 5
Llama Nemotron:英伟达开源基于Llama架构优化的推理模型,253B参数持平DeepSeek R1!
|
5月前
|
数据采集 运维 Serverless
云函数采集架构:Serverless模式下的动态IP与冷启动优化
本文探讨了在Serverless架构中使用云函数进行网页数据采集的挑战与解决方案。针对动态IP、冷启动及目标网站反爬策略等问题,提出了动态代理IP、请求头优化、云函数预热及容错设计等方法。通过网易云音乐歌曲信息采集案例,展示了如何结合Python代码实现高效的数据抓取,包括搜索、歌词与评论的获取。此方案不仅解决了传统采集方式在Serverless环境下的局限,还提升了系统的稳定性和性能。
133 0
|
2月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
106 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
26天前
|
数据采集 机器学习/深度学习 运维
从数据感知到决策优化:MyEMS 开源能源管理系统的技术架构与实践效能解析
MyEMS 是一款开源能源管理系统,采用分层解耦与模块化设计,支持多能源协同监测与智能优化调度。系统具备数据采集、分析、预警、碳核算等功能,助力企业实现节能降耗、安全管控与低碳转型,已在百余家全球企业落地应用,具备自主可控、成本低、安全性强等优势,面向虚拟电厂、数字孪生等未来场景持续演进。
82 0
|
3月前
|
关系型数据库 MySQL 分布式数据库
Super MySQL|揭秘PolarDB全异步执行架构,高并发场景性能利器
阿里云瑶池旗下的云原生数据库PolarDB MySQL版设计了基于协程的全异步执行架构,实现鉴权、事务提交、锁等待等核心逻辑的异步化执行,这是业界首个真正意义上实现全异步执行架构的MySQL数据库产品,显著提升了PolarDB MySQL的高并发处理能力,其中通用写入性能提升超过70%,长尾延迟降低60%以上。

热门文章

最新文章