一.什么是Cap    CAP 是一个基于 .NET Standard 的 C# 库,它是一种处理分布式事务的解决方案,同样具有 EventBus 的功能,它具有轻量级.易使用.高性能等特点. 在我们构建 SOA 或者 微服务系统的过程中,我们通常需要使用事件来对各个服务进行集成,在这过程中简单的使用消息队列并不能保证数据的最终一致性, CAP 采用的是和当前数据库集成的本地消息表的方案来解决在分布式系统互相调用的各个环节可能出现的异常,它能够保证任何情况下事件消息都是不会丢失的. 你同样可以把

博客开通已经7年多了,也没写过什么东西,最近,突然想记录下自己的软件开发生涯,于是,找回账户,登录一看,还是当时还是在学校的时候学习的时候记录过一个sql批量到数据的Demo,近两年来,微服务架构火起来了,前端VUE.React等框架也变得很流行,在此,利用业余时间谈谈我对.netcore微服务架构看法及如何使用.netcore实现一个中小企业架构,如果有写得不对的地方,欢迎大家指正!好了,不多说了,今天,先大概理一下目录. 一.浅谈微服务架构与.NetCore 二.通用中小企业架构设计思路 三

事物的隔离级别与并发完美体现了cap理论(确保数据完整.安全.一致性,在此基础上实现高性能访问(鱼和熊掌不可兼得)

CAP是什么? CAP是由我们园子里的杨晓东大神开发出来的一套分布式事务的决绝方案,是.Net Core Community中的第一个千星项目(目前已经1656 Start),具有轻量级.易使用.高性能等特点. https://github.com/dotnetcore/CAP 本博客主要针对易用性这一点,展开叙述,一起看看CAP如何结合EF Core和RabbitMQ带领小白轻松走入分布式消息队列的世界. 准备 首先,你需要搭建一套RabbitMQ系统,搭建过程在此不再叙述,如果大家觉得麻烦,

来自CAP原作者yang-xiaodong的原理图: 本文撰写者:cmliu,部分内容引用自官方文档,部分内容待更新# .NetCore CAP # 1,简介 CAP 是一个遵循 .NET Standard 标准库的C#库,用来处理分布式事务以及提供EventBus的功能,她具有轻量级,高性能,易使用等特点. 目前 CAP 使用的是 .NET Standard 1.6 的标准进行开发,目前最新预览版本已经支持 .NET Standard 2.0 ## CAP 的应用场景主要有以下两个: ###

业务场景需要锁住指定的字符串下的代码,防止并发创建多个订单 这里我们使用 ConcurrentDictionary 首先初始化一个字典 private static readonly ConcurrentDictionary<string, string> _dictLock = new ConcurrentDictionary<string, string>(); 然后使用定义一个要锁代码的的key,这里为保证每个订单唯一,使用微信的订单号作为key 对同一微信支付订单的回调进行

注册服务发现 需要使用Cap中的UseDiscovery方法 具体用法如下 var capConsulConfig = Configuration.GetSection("CapConsulConfig").Get<CapConsulConfig>(); if (capConsulConfig.UseConsul) { capOptions.UseDiscovery(discovery => { discovery.CurrentNodeHostName = capC

问题还原 引用了 DotNetCore.CAP.MySql MySql.Data.EntityFrameworkCore 在使用MySql相关对象的时候会出现如下冲突,在命名空间加入伪空间名称是不能解决这个问题的(注:如果直接用这个Pomelo.EntityFrameworkCore.MySql是不会有问题的) 解决问题 出现上面的问题肯定要改造代码,那么我们在只能不用这些对象了 不用这些对象怎么来实现操作数据库呢? 所以只用调用上下文对象了,获取连接只能使用 上下文对象中的操作 之前做了一个C

开源分布式消息框架 Cap 可以在GitHub上拉也可以通过nuget添加 上一篇博文写了 Windows RabbitMQ的安装使用 Cap支持事务,通过捕获数据库上下文连接对象实现 消息事务,消息持久化 怎么来实现消息订阅 消费? 使用起来非常简单,主要通过这个类来实现 发布:ICapPublisher . 订阅:CapSubscribe DNC的注入就不做介绍了,引用好相关的Cap类,并注入如下,如果需要事务请注入数据库访问上下文对象 public ValuesController(App

问题的提出 在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景. 1.火车站售票 假如说我们的终端用户是一位经常坐火车的旅行家,通常他是去车站的售票处购买车票,然后拿着车票去检票口,再坐上火车,开始一段美好的旅行----一切似乎都是那么和谐.想象一下,如果他选择的目的地是杭州,而某一趟开往杭州的火车只剩下最后一张车票,可能在同一时刻,不同售票窗口的另一位乘客也购买了同一张车票.假如说售票系统没有进行一致性的保障,两人都购票成功了.而在检票口检票的时候,其中一

本文主要讲述分布式系统开发的一些相关理论基础. 一.ACID 事务的四个特征: 1.Atomic原子性 事务必须是一个原子的操作序列单元,事务中包含的各项操作在一次执行过程中,要么全部执行成功,要么全部不执行,任何一项失败,整个事务回滚,只有全部都执行成功,整个事务才算成功. 2.Consistency一致性 事务的执行不能破坏数据库数据的完整性和一致性,事务在执行之前和之后,数据库都必须处于一致性状态. 3.Isolation隔离性 在并发环境中,并发的事务是相互隔离的,一个事务的执行不能被其

一 CAP理论简述 CAP (Consistency, Availability, Partition  Tolerance,) 理论是NoSQL数据库管理系统构建的基础.     强一致性:等同于所有节点访问同一份最新的数据副本   可用性:每一个操作总是能够在一定的时间内返回结果,这里需要注意的是"一定时间内"和"返回结果".一定时间指的是,在可以容忍的范围内返回结果,结果可以是成功或者失败.   分区容错性:理解为在存在网络分区的情况下,仍然可以接受请求(满足

任老师第一节主要讲了分布式系统实现时候面临的八个问题,布置的作业就是这个,查询CAP理论. 笔者初次接触分布式,所以本文主要是一个汇总. 一.CAP起源 CAP原本是一个猜想,2000年PODC大会的时候大牛Brewer提出的,他认为在设计一个大规模可扩放的网络服务时候会遇到三个特性:一致性(consistency).可用性(Availability).分区容错(partition-tolerance)都需要的情景,然而这是不可能都实现的.之后在2003年的时候,Mit的Gilbert和Lync

大约在五六年前,第一次接触到了当时已经是hot topic的NoSql.不过那个时候学的用的都是mysql,Nosql对于我而言还是新事物,并没有真正使用,只是不明觉厉.但是印象深刻的是这么一张图片(后来google到图片来自这里):     这张图片是讲数据库(包括传统的关系型数据库和NOSQL)与CAP理论的关系.由于并NoSql并没有实践经验,也没有去深入了解,对于CAP理论更是一知半解.因此,为什么某一款数据库被划分到哪一个阵营,并不清楚.     工作之后对MongoDB使用得比较多,

本文主要讲述分布式系统开发的一些相关理论基础. 一.ACID ACID是一系列对系统中数据进行访问与更新的操作所组成的一个程序执行的逻辑单元,狭义上的事务特指数据库事务. 1.Atomic原子性 事务必须是一个原子的操作序列单元,事务中包含的各项操作在一次执行过程中,要么全部执行成功,要么全部不执行,任何一项失败,整个事务回滚,只有全部都执行成功,整个事务才算成功. 2.Consistency一致性 事务的执行不能破坏数据库数据的完整性和一致性,事务在执行之前和之后,数据库都必须处于一致性状态.

问题的解读 对于上面三个例子,相信大家一定看出来了,我们的终端用户在使用不同的计算机产品时对于数据一致性的需求是不一样的: 1.有些系统,既要快速地响应用户,同时还要保证系统的数据对于任意客户端都是真实可靠的,就像火车站售票系统 2.有些系统,需要为用户保证绝对可靠的数据安全,虽然在数据一致性上存在延时,但最终务必保证严格的一致性,就像银行的转账系统 3.有些系统,虽然向用户展示了一些可以说是"错误"的数据,但是在整个系统使用过程中,一定会在某一个流程上对系统数据进行准确无误的检查,从

背景 一致性是一个抽象的.具有多重含义的计算机术语,在不同应用场景下,有不同的定义和含义.在传统的IT时代,一致性通常指强一致性,强一致性通常体现在你中有我.我中有你.浑然一体:而在互联网时代,一致性的含义远远超出了它原有的含义,在我们讨论互联网时代的一致性之前,我们先了解一下互联网时代的特点,互联网时代信息量巨大.需要计算能力巨大,不但对用户响应速度要求快,而且吞吐量指标也要向外扩展(既:水平伸缩),于是单节点的服务器无法满足需求,服务节点开始池化,想想那个经典的故事,一只筷子一折就断,一把筷

CAP理论 Consistency(一致性), 数据一致更新,所有数据变动都是同步的 Availability(可用性), 好的响应性能 Partition tolerance(分区容错性) 可靠性,分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障. 一个分布式系统不可能同时满足一致性(C:Consistency).可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求

.NetCore 下开发独立的(RPL)含有界面的组件包 (一)准备工作 .NetCore 下开发独立的(RPL)含有界面的组件包 (二)扩展中间件及服 务 .NetCore 下开发独立的(RPL)含有界面的组件包 (三)构建界面 .NetCore 下开发独立的(RPL)含有界面的组件包 (四)授权过滤 .NetCore 下开发独立的(RPL)含有界面的组件包 (五)授权过滤参数处 理 .NetCore 下开发独立的(RPL)含有界面的组件包 (六)实现业务功能 相信很多人都nuget包,一般自

问题的提出 在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景. 1.火车站售票 假如说我们的终端用户是一位经常坐火车的旅行家,通常他是去车站的售票处购买车票,然后拿着车票去检票口,再坐上火车,开始一段美好的旅行----一切似乎都是那么和谐.想象一下,如果他选择的目的地是杭州,而某一趟开往杭州的火车只剩下最后一张车票,可能在同一时刻,不同售票窗口的另一位乘客也购买了同一张车票.假如说售票系统没有进行一致性的保障,两人都购票成功了.而在检票口检票的时候,其中一