Category Archives: .Net Core

分布式最终一致方案梳理

摘要： 前言目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总… 前言 目前的应用系统，不管是企业级应用还是互联网应用，最终数据的一致性是每个应用系统都要面临的问题，随着分布式的逐渐普及，数据一致性更加艰难，但是也很难有银弹的解决方案，也并不是引入特定的中间件或者特定的开源框架能够解决的，更多的还是看业务场景，根据场景来给出解决方案。根据笔者最近几年的了解，总结了几个点，更多的应用系统在编码的时候，更加关注数据的一致性，这样系统才是健壮的。 基础理论相关 说起事务，目前的几个理论，ACID事务特性，CAP分布式理论，以及BASE等，ACID在数据库事务中体现，CAP和BASE则是分布式事务的理论，结合业务系统，例如订单管理，例如仓储管理等，可以借鉴这些理论，从而解决问题。 ACID 特性 A（原子性）事务的原子操作单元，对数据的修改，要么全部执行，要么全部不执行； C（一致性）在事务开始和完成时，数据必须保持一致状态，相关的数据规则必须应用于事务的修改，以保证数据的完整性，事务结束时，所有的内部数据结构必须正确； I（隔离性）保证事务不受外部并发操作的独立环境执行； D（持久性）事务完成之后，对于数据的修改是永久的，即使系统出现故障也能够保持； CAP C（一致性）一致性是指数据的原子性，在经典的数据库中通过事务来保障，事务完成时，无论成功或回滚，数据都会处于一致的状态，在分布式环境下，一致性是指多个节点数据是否一致； A（可用性）服务一直保持可用的状态，当用户发出一个请求，服务能在一定的时间内返回结果； P（分区容忍性）在分布式应用中，可能因为一些分布式的原因导致系统无法运转，好的分区容忍性，使应用虽然是一个分布式系统，但是好像一个可以正常运转的整体 BASE BA: Basic Availability 基本业务可用性； S: Soft state 柔性状态； E: Eventual consistency 最终一致性； 最终一致性的几种做法 单数据库情况下的事务 如果应用系统是单一的数据库，那么这个很好保证，利用数据库的事务特性来满足事务的一致性，这时候的一致性是强一致性的。对于java应用系统来讲，很少直接通过事务的start和commit以及rollback来硬编码，大多通过spring的事务模板或者声明式事务来保证。 基于事务型消息队列的最终一致性 借助消息队列，在处理业务逻辑的地方，发送消息，业务逻辑处理成功后，提交消息，确保消息是发送成功的，之后消息队列投递来进行处理，如果成功，则结束，如果没有成功，则重试，直到成功，不过仅仅适用业务逻辑中，第一阶段成功，第二阶段必须成功的场景。对应上图中的C流程。 基于消息队列+定时补偿机制的最终一致性 前面部分和上面基于事务型消息的队列，不同的是，第二阶段重试的地方，不再是消息中间件自身的重试逻辑了，而是单独的补偿任务机制。其实在大多数的逻辑中，第二阶段失败的概率比较小，所以单独独立补偿任务表出来，可以更加清晰，能够比较明确的直到当前多少任务是失败的。对应上图的E流程。 业务系统业务逻辑的commit/rollback机制 这一点说的话确实不难，commit和rollback是数据库事务中的比较典型的概念，但是在系统分布式情况下，需要业务代码中实现这种，成功了commit，失败了rollback。 业务应用系统的幂等性控制 为啥要做幂等呢？ 原因很简单，在系统调用没有达到期望的结果后，会重试。那重试就会面临问题，重试之后不能给业务逻辑带来影响，例如创建订单，第一次调用超时了，但是调用的系统不知道超时了是成功了还是失败了，然后他就重试，但是实际上第一次调用订单创建是成功了的，这时候重试了，显然不能再创建订单了。 查询 查询的API，可以说是天然的幂等性，因为你查询一次和查询两次，对于系统来讲，没有任何数据的变更，所以，查询一次和查询多次一样的。 MVCC方案 多版本并发控制，update with condition，更新带条件，这也是在系统设计的时候，合理的选择乐观锁，通过version或者其他条件，来做乐观锁，这样保证更新及时在并发的情况下，也不会有太大的问题。例如update table_xxx set name=#name#,version=version+1 where version=#version# ,或者是 update table_xxx set quality=quality-#subQuality# where quality-#subQuality# >= 0 。 单独的去重表 如果涉及到的去重的地方特别多，例如ERP系统中有各种各样的业务单据，每一种业务单据都需要去重，这时候，可以单独搞一张去重表，在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。 分布式锁 还是拿插入数据的例子，如果是分布是系统，构建唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。 删除数据 删除数据，仅仅第一次删除是真正的操作数据，第二次甚至第三次删除，直接返回成功，这样保证了幂等。 插入数据的唯一索引 插入数据的唯一性，可以通过业务主键来进行约束，例如一个特定的业务场景，三个字段肯定确定唯一性，那么，可以在数据库表添加唯一索引来进行标示。 API层面的幂等 这里有一个场景，API层面的幂等，例如提交数据，如何控制重复提交，这里可以在提交数据的form表单或者客户端软件，增加一个唯一标示，然后服务端，根据这个UUID来进行去重，这样就能比较好的做到API层面的唯一标示。 状态机幂等 在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。 异步回调机制的引入 A应用调用B，在同步调用的返回结果中，B返回成功给到A，一般情况下，这时候就结束了，其实在99.99%的情况是没问题的，但是有时候为了确保100%，记住最起码在系统设计中100%，这时候B系统再回调A一下，告诉A，你调用我的逻辑，确实成功了。其实这个逻辑，非常类似TCP协议中的三次握手。上图中的B流程。 类似double check机制的确认机制 还是上图中异步回调的过程，A在同步调用B，B返回成功了。这次调用结束了，但是A为了确保，在过一段时间，这个时间可以是几秒，也可以是每天定时处理，再调用B一次，查询一下之前的那次调用是否成功。例如A调用B更新订单状态，这时候成功了，延迟几秒后，A查询B，确认一下状态是否是自己刚刚期望的。上图中的D流程。 总结 上面的几点总结，更多的在业务系统中体现，在超复杂的系统中，数据的一致性，不是说简单的引入啥中间件能够解决的，更多的是根据业务场景，来灵活应对。 from:https://www.cnblogs.com/BrightMoon/p/5622618.html

全面理解 ASP.NET Core 依赖注入

DI在.NET Core里面被提到了一个非常重要的位置， 这篇文章主要再给大家普及一下关于依赖注入的概念，身边有工作六七年的同事还个东西搞不清楚。另外再介绍一下.NET  Core的DI实现以及对实例生命周期的管理（这个是经常面试会问到的问题）。最后再给大家简单介绍一下在控制台以及Mvc下如何使用DI，以及如何把默认的Service Container 替换成Autofac。 我录了一些关于ASP.NET Core的入门视频：有兴趣的同学可以去看看。  http://www.cnblogs.com/jesse2013/p/aspnetcore-videos.html 一、什么是依赖注入 1.1 依赖 1.2 什么注入 为什么反转 何为容器 二、.NET Core DI 2.1 实例的注册 2.2 实例生命周期之单例 2.3 实例生命周期之Tranisent 2.4 实例生命周期之Scoped 三、DI在ASP.NET Core中的应用 3.1 在Startup类中初始化 3.2 Controller中使用 3.3 View中使用 3.4 通过HttpContext来获取 四、如何替换其它的Ioc容器 一、什么是依赖注入（Denpendency Injection) 这也是个老身常谈的问题，到底依赖注入是什么？ 为什么要用它？ 初学者特别容易对控制反转IOC(Iversion of Control)，DI等概念搞晕。 1.1依赖 当一个类需要另一个类协作来完成工作的时候就产生了依赖。比如我们在AccountController这个控制器需要完成和用户相关的注册、登录 等事情。其中的登录我们由EF结合Idnetity来完成，所以我们封装了一个EFLoginService。这里AccountController就有一个ILoginService的依赖。 这里有一个设计原则：依赖于抽象，而不是具体的实现。所以我们给EFLoginService定义了一个接口，抽象了LoginService的行为。 1.2 什么是注入 注入体现的是一个IOC（控制反转的的思想）。在反转之前 ，我们先看看正转。 AccountController自己来实例化需要的依赖。 1 2 3 4 5 private ILoginService<ApplicationUser> _loginService; public AccountController() {   _loginService = new EFLoginService() }   大师说，这样不好。你不应该自己创建它，而是应该由你的调用者给你。于是你通过构造函数让外界把这两个依赖传给你。 1 2 3 4 5 public  AccountController(ILoginService<ApplicationUser> loginService) {   _loginService = loginService; }   把依赖的创建丢给其它人，自己只负责使用，其它人丢给你依赖的这个过程理解为注入。 1.3 为什么要反转？ 为了在业务变化的时候尽少改动代码可能造成的问题。 比如我们现在要把从EF中去验证登录改为从Redis去读，于是我们加了一个 RedisLoginService。这个时候我们只需要在原来注入的地方改一下就可以了。 1 2 […]

Orchard Core一分钟搭建ASP.NET Core CMS

Orchard Core 是Orchard CMS的ASP.NET Core版本。 Orchard Core是全新一代的ASP.NET Core CMS。 官方文档介绍：http://orchardcore.readthedocs.io/en/latest/ GitHub: https://github.com/OrchardCMS/OrchardCore 下面快速开始搭建CMS 新建项目 打开VS2017 新建一个CMSWeb的ASP.NET Core Web应用程序 然后选择空模板 安装OrchardCore包 NuGet包命令 目前预览版需加 -Pre Install-Package OrchardCore.Application.Cms.Targets -Pre 或者在NuGet搜索 OrchardCore.Application.Cms.Targets   项目开发 打开Startup.cs ,在ConfigureServices加入

然后删除Configure 中的

加入

最终如下：

然后运行程序，打开浏览会看到初始化安装界面。输入对应信息，然后完成安装。   注意密码必须包含大小写数字和字符才能成功提交。如上图中出现红色是不行的。 安装好后配置一下，最终如下：   后台为/Admin ，可以进入查看相关设置。 Orchard Core Framework：ASP.NET Core 模块化，多租户框架。 《ASP.NET Core跨平台开发从入门到实战》 京东淘宝亚马逊当当 博客示例代码GitHub：https://github.com/linezero/Blog from:https://www.cnblogs.com/linezero/p/OrchardCore.html

C# 获取文件名及扩展名

string aFirstName = aFile.Substring(aFile.LastIndexOf("\\") + 1, (aFile.LastIndexOf(".") – aFile.LastIndexOf("\\") – 1)); //文件名 string aLastName = aFile.Substring(aFile.LastIndexOf(".") + 1, (aFile.Length – aFile.LastIndexOf(".") – 1)); //扩展名 string strFilePaht="文件路径"; Path.GetFileNameWithoutExtension(strFilePath);这个就是获取文件名的 还有的就是用Substring截取 strFilePaht.Substring(path.LastIndexOf("\\") + 1, path.Length – 1 – path.LastIndexOf("\\")); strFilePaht.Substring(path.LastIndexOf("."), path.Length – path.LastIndexOf(".")); 或者用openFileDialog1.SafeFileName 这样就能取到该文件的所在目录路径 string path1 = System.IO.Path.GetDirectoryName(openFileDialog1.FileName) + @"\"; string path = Path.GetFileName("C:\My Document\path\image.jpg"); //只获取文件名image.jpg ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// string fullPath = @"\WebSite1\Default.aspx"; string filename = System.IO.Path.GetFileName(fullPath);//文件名 “Default.aspx” string extension = System.IO.Path.GetExtension(fullPath);//扩展名 “.aspx” string fileNameWithoutExtension = System.IO.Path.GetFileNameWithoutExtension(fullPath);// 没有扩展名的文件名 “Default” ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// System.IO.Path.GetFileNam(filePath) //返回带扩展名的文件名 System.IO.Path.GetFileNameWithoutExtension(filePath) //返回不带扩展名的文件名 System.IO.Path.GetDirectoryName(filePath) //返回文件所在目录 ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// //获取当前进程的完整路径，包含文件名(进程名)。 string str = this.GetType().Assembly.Location; […]

StringComparison枚举

public enum StringComparison { CurrentCulture, CurrentCultureIgnoreCase, InvariantCulture, InvariantCultureIgnoreCase, Ordinal, OrdinalIgnoreCase } CurrentCulture 使用区域敏感排序规则和当前区域比较字符串。 CurrentCultureIgnoreCase 使用区域敏感排序规则、当前区域来比较字符串，同时忽略被比较字符串的大小写。 InvariantCulture 使用区域敏感排序规则和固定区域比较字符串。 InvariantCultureIgnoreCase 使用区域敏感排序规则、固定区域来比较字符串，同时忽略被比较字符串的大小写。 Ordinal 使用序号排序规则比较字符串。 OrdinalIgnoreCase 使用序号排序规则并忽略被比较字符串的大小写，对字符串进行比较。   1.首先是StringComparison.Ordinal 在进行调用String.Compare(string1,string2,StringComparison.Ordinal)的时候是进行非语言(non-linguistic)上的比较,API运行时将会对两个字符串进行byte级别的比较,因此这种比较是比较严格和准确的,并且在性能上也很好,一般通过StringComparison.Ordinal来进行比较比使用String.Compare(string1,string2)来比较要快10倍左右.(可以写一个简单的小程序验证,这个挺让我惊讶,因为平时使用String.Compare从来就没想过那么多).StringComparison.OrdinalIgnoreCase就是忽略大小写的比较,同样是byte级别的比较.性能稍弱于StringComparison.Ordinal. 2.StringComparison.CurrentCulture 是在当前的区域信息下进行比较,这是String.Compare在没有指定StringComparison的时候默认的比较方式.例子如下:  Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US"); //当前的区域信息是美国             string s1 = "visualstudio";             string s2 = "windows";             Console.WriteLine(String.Compare(s1, s2,StringComparison.CurrentCulture)); //输出"-1"             Thread.CurrentThread.CurrentCulture = new CultureInfo("sv-SE"); //当前的区域信息是瑞典             Console.WriteLine(String.Compare(s1, s2,StringComparison.CurrentCulture)); //输出"1" StringComarison.CurrentCultureIgnoreCase指在当前区域信息下忽略大小写的比较. 3.StringComarison.InvariantCulture 使用StringComarison.InvariantCulture来进行字符串比较,在任何系统中(不同的culture)比较都将得到相同的结果,他是使用CultureInfo.InvariantCulture的静态成员CompareInfo来进行比较操作的.例子如下:             Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US"); //当前的区域信息是美国             string s1 = "visualstudio";             string s2 = "windows";             Console.WriteLine(String.Compare(s1, s2,StringComparison.InvariantCulture)); //输出"-1"             Thread.CurrentThread.CurrentCulture = new CultureInfo("sv-SE"); //当前的区域信息是瑞典             Console.WriteLine(String.Compare(s1, s2,StringComparison.InvariantCulture)); //输出"-1" 参考文章:http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dndotnet/html/StringsinNET20.asp   from:http://www.cnblogs.com/zhw511006/archive/2010/07/09/1774591.html

HttpApplication 事件

命名空间:   System.Web 程序集:  System.Web（位于 System.Web.dll） 事件 名称 说明 · AcquireRequestState 当 ASP.NET 获取与当前的请求相关联的当前状态 （例如，会话状态）。 · AuthenticateRequest 当安全模块已建立的用户标识时出现。 · AuthorizeRequest 安全模块已验证用户身份验证时发生。 · BeginRequest 作为执行的 HTTP 管道链中的第一个事件发生，当 ASP.NET 的请求做出响应。 · Disposed 释放应用程序时发生。 · EndRequest 作为执行的 HTTP 管道链中的最后一个事件发生，当 ASP.NET 的请求做出响应。 · Error 当引发未处理的异常时发生。 · LogRequest ASP.NET 执行当前请求的任何日志记录之前发生。 · MapRequestHandler 此 API 支持 产品 基础结构，不应从代码直接使用。 在选择该处理程序对请求作出响应时发生。 · PostAcquireRequestState 获取与当前的请求相关联的请求状态 （例如，会话状态） 时发生。 · PostAuthenticateRequest 当安全模块已建立的用户标识时出现。 · PostAuthorizeRequest 当前请求的用户已被授权时发生。 · PostLogRequest 当 ASP.NET 已完成处理的事件处理程序时发生 LogRequest 事件。 · PostMapRequestHandler 当 ASP.NET 已映射到相应的事件处理程序的当前请求时出现。 · PostReleaseRequestState 当 ASP.NET 已完成执行所有请求事件处理程序和存储数据的请求状态时发生。 · PostRequestHandlerExecute 当 ASP.NET 事件处理程序 （例如，一个页面或 XML Web 服务） 完成执行时发生。 · PostResolveRequestCache ASP.NET […]

C# 字符串按 ASCII码 排序，注意其中的小坑

在和银行做数据对接时，涉及到数据传输时的验签及加密。其中数据签名方案中就要求数据项根据属性名按 ASCII码 进行升序排序。C#中的ASCII码排序并不是表面上那么简单，一不小心就入坑了。因为C#的排序默认并不是按照ASCII码进行排序的。举个例子， 我有这样一个字符串数组，然后对其排序。

  如果是按照ASCII码进行排序的话，顺序应该是： 1, 2, A, B, a, b  而实际排序后的结果则是：1, 2, a, A, b, B . 这也就是说Sort()方法默认情况下并不是按ASCII码进行排序的。之后我也同样测试了C#中的OrderBy()的排序，发现它默认情况下也并不是按照ASCII码进行的排序。

  那么既然默认排序不是按ASCII码进行的排序，我们要怎么做呢？ 看下面代码，只需要在原来排序方法上再加个参数: string.CompareOrdinal。string.CompareOrdinal会把每个字符先转成相应的数值（如 a 转为数值 97），然后再对数值进行比较。

  注：掉入这个坑是因为起初不知道如何对字符做ASCII码排序，于是百度了一把。得到的结果就是这个 C# 参数按照ASCII码从小到大排序（字典序）  而当我采用这种方式时，银行验签那步始终通不过，调试发现我排序后的结果和银行那边的不同。这篇博文的博主可能自己也没发现这个坑吧。   from:http://www.cnblogs.com/similar/p/6739293.html

ASP.NET Core 使用 Redis 和 Protobuf 进行 Session 缓存

前言 上篇博文介绍了怎么样在 asp.net core 中使用中间件，以及如何自定义中间件。项目中刚好也用到了Redis，所以本篇就介绍下怎么样在 asp.net core 中使用 Redis 进行资源缓存和Session缓存。 如果你觉得对你有帮助的话，不妨点个【推荐】。 目录 Redis 介绍 asp.net core Session 介绍 Redis & Session 实例讲解 Session的使用 使用 Protobuf 给 Session添加扩展方法 Redis 介绍 下面是Redis官网的介绍： Redis is an open source (BSD licensed), in-memory data structure store, used as database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides […]

ASP.NET Core 数据保护（Data Protection 集群场景）【下】

前言 接【中篇】，在有一些场景下，我们需要对 ASP.NET Core 的加密方法进行扩展，来适应我们的需求，这个时候就需要使用到了一些 Core 提供的高级的功能。 本文还列举了在集群场景下，有时候我们需要实现自己的一些方法来对Data Protection进行分布式配置。 加密扩展 IAuthenticatedEncryptor 和 IAuthenticatedEncryptorDescriptor IAuthenticatedEncryptor是 Data Protection 在构建其密码加密系统中的一个基础的接口。 一般情况下一个key 对应一个IAuthenticatedEncryptor，IAuthenticatedEncryptor封装了加密操作中需要使用到的秘钥材料和必要的加密算法信息等。 下面是IAuthenticatedEncryptor接口提供的两个 api方法：

其中接口中的参数additionalAuthenticatedData表示在构建加密的时候提供的一些附属信息。 IAuthenticatedEncryptorDescriptor接口提供了一个创建包含类型信息IAuthenticatedEncryptor实例方法。

密钥管理扩展 在密钥系统管理中，提供了一个基础的接口IKey，它包含以下属性：

IKey还提供了一个创建IAuthenticatedEncryptor实例的方法CreateEncryptorInstance。 IKeyManager接口提供了一系列用来操作Key的方法，包括存储，检索操作等。他提供的高级操作有： 创建一个Key 并且持久存储 从存储库中获取所有的 Key 撤销保存到存储中的一个或多个键 XmlKeyManager 通常情况下，开发人员不需要去实现IKeyManager来自定义一个 KeyManager。我们可以使用系统默认提供的XmlKeyManager类。 XMLKeyManager是一个具体实现IKeyManager的类，它提供了一些非常有用的方法。

IAuthenticatedEncryptorConfiguration 主要是规定新 Key 使用的算法。 IXmlRepository 主要控制 Key 在哪里持久化存储。 IXmlRepository IXmlRepository接口主要提供了持久化以及检索XML的方法，它只要提供了两个API: GetAllElements() : IReadOnlyCollection StoreElement(XElement element, string friendlyName) 我们可以通过实现IXmlRepository接口的StoreElement方法来定义data protection xml的存储位置。 GetAllElements来检索所有存在的加密的xml文件。 接口部分写到这里吧，因为这一篇我想把重点放到下面，更多接口的介绍大家还是去官方文档看吧～ 集群场景 上面的API估计看着有点枯燥，那我们就来看看我们需要在集群场景下借助于Data Protection来做点什么吧。 就像我在【上篇】总结中末尾提到的，在做分布式集群的时候，Data Protection的一些机制我们需要知道，因为如果不了解这些可能会给你的部署带来一些麻烦，下面我们就来看看吧。 在做集群的时，我们必须知道并且明白关于 ASP.NET Core Data Protection 的三个东西： 1、程序识别者 “Application discriminator”，它是用来标识应用程序的唯一性。 为什么需要这个东西呢？因为在集群环境中，如果不被具体的硬件机器环境所限制，就要排除运行机器的一些差异，就需要抽象出来一些特定的标识，来标识应用程序本身并且使用该标识来区分不同的应用程序。这个时候，我们可以指定ApplicationDiscriminator。 在services.AddDataProtection(DataProtectionOptions option)的时候，ApplicationDiscriminator可以作为参数传递，来看一下代码：

可以看到这个扩展返回的是一个IDataProtectionBuilder，在IDataProtectionBuilder还有一个扩展方法叫 SetApplicationName ,这个扩展方法在内部还是修改的ApplicationDiscriminator的值。也就说以下写法是等价的：

也就是说集群环境下同一应用程序他们需要设定为相同的值（ApplicationName or ApplicationDiscriminator）。 2、主加密键 […]