EF架构~通过EF6的DbCommand拦截器来实现数据库读写分离~再续~添加对各只读服务器的心跳检测

简介:

上一讲中基本实现了对数据库的读写分离,而在选择只读数据库上只是随机选择,并没有去检测数据库服务器是否有效,如服务器挂了,SQL服务停了,端口被封了等等,而本讲主要对以上功能进行一个实现,并对配置文件也进行了一些优化,让它更好的支持多个数据库服务器,分别配置各个的账号和密码及数据库服务端口等等,接下来,就来看一下主要的代码吧。

一 配置文件

    <!-- ef实现对sql读写分离的配置,sqlserver端采用发布与订阅实现 -->
    <add key="readDb" value="
         192.168.2.71|1433|background_read1|sa|zzl123,
         192.168.2.71|1433|TestWrite_Read_Zzl|sa|zzl123,
         192.168.2.29|1433|TestWrite_Read_Zzl|sa|1"
         />
    <!-- 只读服务器的sql连接串配置模版-->
    <add key ="readDbConnectioin" value="data source={0};initial catalog={1};persist security info=True;user id={2};password={3};multipleactiveresultsets=True;application name=EntityFramework"/>

二 数据库配置实体类

 /// <summary>
    /// 只读数据库配置实体
    /// </summary>
    public class ReadDbConfig
    {
        public ReadDbConfig()
        {
            Port = 1433;
            UserId = "sa";
        }
        public string Ip { get; set; }
        public int Port { get; set; }
        public string DbName { get; set; }
        public string UserId { get; set; }
        public string Password { get; set; }
    }

三 对SQL拦截器进行优化,添加了TCP的心跳检测

lock (lockObj)
            {
                if (readConnList != null && readConnList.Any())
                {
                    foreach (var item in readConnList)
                    {
                        //心跳测试,将死掉的服务器IP从列表中移除
                        var client = new TcpClient();
                        try
                        {
                            client.Connect(new IPEndPoint(IPAddress.Parse(item.Ip), item.Port));
                        }
                        catch (SocketException)
                        {
                            //异常,没有连接上
                            readConnList.Remove(item);
                        }
                        if (!client.Connected)
                        {
                            readConnList.Remove(item);
                        }
                    }
                }
            }

四 对于数据库库端还是这前通过发布和订阅实现的,需要注意的是,这些功能需要使用“机器名”进行链接,使用ip和域名都是无效的

五 下面贡献一下完成的拦截器代码

  View Code

本文转自博客园张占岭(仓储大叔)的博客,原文链接:EF架构~通过EF6的DbCommand拦截器来实现数据库读写分离~再续~添加对各只读服务器的心跳检测,如需转载请自行联系原博主。

目录
相关文章
|
3天前
|
机器学习/深度学习 弹性计算 人工智能
阿里云服务器ECS架构区别及选择参考:X86计算、ARM计算等架构介绍
在我们选购阿里云服务器的时候,云服务器架构有X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器、高性能计算可选,有的用户并不清楚他们之间有何区别,本文主要简单介绍下这些架构各自的主要性能及适用场景,以便大家了解不同类型的架构有何不同,主要特点及适用场景有哪些。
|
8天前
|
存储 人工智能 运维
面向AI的服务器计算软硬件架构实践和创新
阿里云在新一代通用计算服务器设计中,针对处理器核心数迅速增长(2024年超100核)、超多核心带来的业务和硬件挑战、网络IO与CPU性能增速不匹配、服务器物理机型复杂等问题,推出了磐久F系列通用计算服务器。该系列服务器采用单路设计减少爆炸半径,优化散热支持600瓦TDP,并实现CIPU节点比例灵活配比及部件模块化可插拔设计,提升运维效率和客户响应速度。此外,还介绍了面向AI的服务器架构挑战与软硬件结合创新,包括内存墙问题、板级工程能力挑战以及AI Infra 2.0服务器的开放架构特点。最后,探讨了大模型高效推理中的显存优化和量化压缩技术,旨在降低部署成本并提高系统效率。
|
2月前
|
机器学习/深度学习 弹性计算 人工智能
阿里云服务器架构有啥区别?X86计算、Arm、GPU异构、裸金属和高性能计算对比
阿里云ECS涵盖x86、ARM、GPU/FPGA/ASIC、弹性裸金属及高性能计算等多种架构。x86架构采用Intel/AMD处理器,适用于广泛企业级应用;ARM架构低功耗,适合容器与微服务;GPU/FPGA/ASIC专为AI、图形处理设计;弹性裸金属提供物理机性能;高性能计算则针对大规模并行计算优化。
|
2月前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
2月前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
2月前
|
存储 缓存 弹性计算
Codota的服务器存储架构
Codota的服务器存储架构
33 5
|
2月前
|
存储 NoSQL 分布式数据库
微服务架构下的数据库设计与优化策略####
本文深入探讨了在微服务架构下,如何进行高效的数据库设计与优化,以确保系统的可扩展性、低延迟与高并发处理能力。不同于传统单一数据库模式,微服务架构要求更细粒度的服务划分,这对数据库设计提出了新的挑战。本文将从数据库分片、复制、事务管理及性能调优等方面阐述最佳实践,旨在为开发者提供一套系统性的解决方案框架。 ####
|
2月前
|
消息中间件 数据库 云计算
微服务架构下的数据库事务管理策略####
在微服务架构中,传统的单体应用被拆分为多个独立的服务单元,每个服务维护自己的数据库实例。这种设计提高了系统的可扩展性和灵活性,但同时也带来了分布式环境下事务管理的复杂性。本文探讨了微服务架构下数据库事务的挑战,并深入分析了几种主流的事务管理策略,包括Saga模式、两阶段提交(2PC)以及基于消息的最终一致性方案,旨在为开发者提供一套适应不同业务场景的事务处理框架。 ####
|
2月前
|
存储 Cloud Native NoSQL
云原生时代的数据库选型与架构设计
云原生时代的数据库选型与架构设计
29 0
|
2月前
|
设计模式 存储 缓存
微服务架构下的数据库设计策略
本文探讨了在微服务架构中进行数据库设计时,如何平衡数据的一致性、独立性与系统整体性能之间的关系。文章首先介绍了微服务架构的基本概念及其对数据库设计的影响,随后深入分析了三种主流的数据库设计模式——集中式、去中心化和混合模式,并结合实际案例讨论了它们的适用场景与优缺点。此外,还提出了一系列最佳实践建议,旨在帮助开发者更好地应对微服务环境下的数据管理挑战。