可用性

1、 CAP 的来源 　　1998年，加州大学的计算机科学家EricBrewer提出，分布式系统有三个指标 C onsistency：一致性 A vailability：可用性 P artition tolerance：分区容错性 　　它们的第一个字母分别是 C、A、P，EricBrewer说这三个指标不可能同时做到，最多只能3选2，这个结论就叫做 CAP 定理。 2、如何取舍？ 　　 CA ： 如果不要求P（不允许分区），则C（一致性）和A（可用性）是可以保证的，CA系统基本上是单机系统，比如单机数据库。 　　 CP ：如果不要求A（可用性），相当于每个请求都需要在Server之间强一致，而P（分区容错性）会导致同步时间无限延长，如此CP也是可以保证的，很多传统的数据库分布式事务都属于这种模式。 　　 AP ：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。 来源： https://www.cnblogs.com/jackcto/p/11904605.html

简单阐述一下自己对分布式事物的理解，如有错误欢迎指正： 刚性事物：即ACID这里不做过多解释，有不明白的同学建议快速掌握。 柔性事物：简单来说为运行过程不一致但最终保持一致。 一、产生原因： 　　分布式(微服务)系统中之间的跨库访问(例：商城项目中的会员数据库，订单数据库，支付数据库等、、、)与同一项目多数据源不同，使用于分布式系统后类似SOA接口之间调用时产生。 二、解决原理： 1）、CAP原理(即：一致性，可用性，分区容错性) 一致性：当系统对一个数据进行写操作时成功后，在查询则必须是改动后的值，当写操作失败也就必须查不多新值，在单机项目中又叫原子性。 　　 可用性：服务可用性，就是说所有的读写请求在一定时间内要得到响应，不能一直等待下去。 　　 分区容错性：指在分布式、微服务系统中，当 部分服务宕机后，其他核心服务能够不受影响能够继续提供服务。 2）、BAS理论： 　 采用CAP演化而来，是对CAP中一致性和可用性权衡的结果，核心思想是：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一 　　致 性。主要有以下状态： 　　 基本可用：在分布式系统出现故障时，允许损失部分可用性，保证核心可用，例如：一个服务正常响应时间为：2秒之内，在访问量大时可采用可对部分用户进行降级处理 　　 软状态：允许系统存在中间状态，并且该状态不会允许系统整体可用性

RabbitMQ 即一个消息队列，主要是用来实现应用程序的异步和解耦，同时也能起到消息缓冲，消息分发的作用。 ①.通过异步处理提高系统性能 image.jpeg 通过异步处理提高系统性能 如上图，在不使用消息队列服务器的时候，用户的请求数据直接写入数据库，在高并发的情况下数据库压力剧增，使得响应速度变慢。但是在使用消息队列之后，用户的请求数据发送给消息队列之后立即 返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度快于数据库（消息队列也比数据库有更好的伸缩性），因此响应速度得到大幅改善。 通过以上分析我们可以得出消息队列具有很好的削峰作用的功能——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。 举例：在电子商务一些秒杀、促销活动中，合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击。如下图所示： image.jpeg | 合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击 因为用户请求数据写入消息队列之后就立即返回给用户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此使用消息队列进行异步处理之后，需要适当修改业务流程进行配合，比如用户在提交订单之后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后

https://www.cnblogs.com/wupeixuan/p/9302496.html 第一章主要讲的是分布式架构，主要包含以下内容： 集中式的特点 分布式的特点 分布式环境的各种问题 ACID 分布式事务 CAP和BASE理论 1 | 1 集中式与分布式的特点 集中式的特点：部署结构简单（因为基于底层性能卓越的大型主机，不需考虑对服务多个节点的部署，也就不用考虑多个节点之间分布式协调问题） 分布式的特点： 分布性 对等性 并发性 缺乏全局时钟 故障总是会发生 1 | 2 分布式环境的各种问题 分布式环境的各种问题： 通信异常：主要是因为网络本身的不可靠性 网络分区：当网络发生异常时，导致部分节点之间的网络延时不断增大，最终导致部分节点可以通信，而另一部分节点不能。 三态（成功、失败与超时） 节点故障：组成分布式系统的服务器节点出现宕机或“僵死”现象 1 | 3 ACID与分布式事务 事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。 事务有四个特性，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），简称为事务的ACID特性。 原子性（Atomicity）：必须是一个原子的操作序列单元，只允许出现两种状态之一（全部成功执行，全部不执行）。

Tag：可行性 测试 、测试流程、结果分析、案例分析 　　WhatsApp是一款面向 智能手机 的网络通讯服务，它可以通过网络传送短信、图片、音频和视频。WhatsApp在全球范围内被广泛使用，是最受欢迎的即时聊天软件。 　　虽然，在电脑上使用WhatsApp桌面版给联系人发消息也很方便。但是，通过用户测试，也呈现出了在使用某些功能时的几个痛点。 　　本文介绍了Guerrilla可用性测试的细节和结果，以及一些建议。 　 　目的 　　了解用户使用WhatsApp Web时的痛点。 　　 测试参数 　　l 测什么：WhatsApp上最常用的两个任务； 　　l 测试谁：WhatsApp的3个老用户和2个新用户； 　　l 怎么测：通过观察法和测试法。 　　 测试流程 　　可用性测试阶段 　 　1.识别用户任务 　　创建用户使用WhatsApp Web的任务清单。 　 　2.任务优先级 　　根据用户使用频率确定任务的优先顺序。 　　任务分为1-3分。 　　最常用的任务获3分，偶尔使用获2分，极少使用获1分。 　　其中，两项最常用的3分任务是： 　　l 发送消息给好友； 　　l 分享照片给好友。 　 　3.执行测试 　　将所选任务和说明一起提供给用户，并遵循这两种方式来收集用户反馈。 　　l 观察用户的操作行为； 　　l 关注他们在执行某些任务时所描述的经历。 　

转自： https://blog.csdn.net/pengjunlee/article/details/86517935 1998年，加州大学的计算机科学家 Eric Brewer 提出了分布式系统的三个指标： C：Consistency，一致性。在分布式系统中的所有数据备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本（all nodes see the same data at the same time）。 A：Availability ，可用性，好的响应性能。完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应（Reads and writes always succeed）。 P：Partition Tolerance ，分区容错性，即分布式系统在遇到某些节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。分区容错性要求一个分布式系统中有某一个或者几个节点故障时，其他剩下的节点还能够正常运转并对外提供服务，对于用户而言并没有什么体验上的影响。 Eric Brewer 指出任何分布式系统只可同时满足CAP三个指标中的两个，无法三者兼顾，这个结论就叫做 CAP 定理。 　　 定理解读 分布式的服务化系统都需要满足分区容忍性，那么我们必须在一致性（C）和可用性（A）之间进行权衡。在网络分区故障发生时

这一篇是从0开始搭建SQL Server AlwaysOn 的第三篇，这一篇才真正开始搭建AlwaysOn，前两篇是为搭建AlwaysOn 做准备的 步骤 这一篇依然使用step by step的方式介绍怎麽搭建AlwaysOn 请先使用本地用户Administrator登录这两个集群节点并执行下面的操作，先不要用域用户DCADMIN登录 1、两个集群节点都需先安装.NET Framework 3.5(在Windows Server 2012 R2中使用添加功能来安装)。 2、各个集群节点本地都要准备好相关软件，在各个节点上独立安装SQL Server 2012（不能使用群集方式安装），保证各个节点中使用相同的安装目录结构和排序规则！ 选择全新SQL Server独立安装，不要选择新的SQL Server故障转移集群安装 至于安装过程，默认下一步下一步就可以了，跟单机安装SQL Server没有区别，这里就忽略安装过程了 注意：因为本人的安装包已经 自带SP1补丁包 ，为了后续避免踩坑，如果没有安装SP1或以上补丁包的，请先安装 注意：如果一开始使用域用户DCADMIN来登录集群节点机器，并安装SQL Server的时候会遇到一个坑，SQL Server安装程序会连接故障转移集群，但是实际上单机安装SQL Server根本不需要连接故障转移集群 本人排查了很久都找不到原因

这一篇是从0开始搭建SQL Server AlwaysOn 的第四篇，这一篇开始搭建异地机房节点 注意点1 注意异地节点最好至少有2个AG节点，否则在本地节点进行手动故障转移的时候会出现仲裁警告，提示WSFC集群有脱机危险 在异地节点只有一个的情况下，虽然Windows2012R2有动态仲裁机制，但是，当本地节点非优雅宕机的情况下，整个WSFC集群有可能得不到任何票数 也就是异地节点也得不到票数而导致整个WSFC集群脱机！！ 注意点2 当进行手动故障转移的时候，更新DNS缓存需要10分钟，所以当进行手动故障转移之后，用侦听器ip连接SQL Server会很慢，这是因为还在更新DNS缓存 步骤 这一篇依然使用step by step的方式介绍怎麽搭建AlwaysOn异地机房节点 新加异地机房节点机器名： 1、在异地节点上安装故障转移集群 2、在本地机房节点机器上打开故障转移集群管理器，添加一个节点 3、验证配置 4、解决新加节点OU不同问题，只需修改组织单位ou，不需要修改站点site，因为如果本地机房和异地机房的域设置了site，在验证配置的时候会警告，当然可以忽略也可以修正 因为只是警告已而，忽略也无所谓 5、添加节点成功 6、在新节点上安装好SQL Server并优化SQL Server，这里忽略安装和优化步骤 7、把异地机房新节点添加到alwayson可用性组里

背景 LCN框架在2017年6月份发布第一个版本，从开始的1.0，已经发展到了5.0版本。 LCN名称是由早期版本的LCN框架命名，在设计框架之初的1.0 ~ 2.0的版本时框架设计的步骤是如下,各取其首字母得来的LCN命名。 锁定事务单元（lock） 确认事务模块状态(confirm) 通知事务(notify) 5.0以后由于框架兼容了LCN、TCC、TXC三种事务模式，为了避免区分LCN模式，特此将LCN分布式事务改名为TX-LCN分布式事务框架。 框架定位 LCN并不生产事务，LCN只是本地事务的协调工 TX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。 解决方案 在一个分布式系统下存在多个模块协调来完成一次业务。那么就存在一次业务事务下可能横跨多种数据源节点的可能。TX-LCN将可以解决这样的问题。 例如存在服务模块A 、B、 C。A模块是mysql作为数据源的服务，B模块是基于redis作为数据源的服务，C模块是基于mongo作为数据源的服务。若需要解决他们的事务一致性就需要针对不同的节点采用不同的方案，并且统一协调完成分布式事务的处理。 方案： 若采用TX-LCN分布式事务框架，则可以将A模块采用LCN模式、B/C采用TCC模式就能完美解决。 入门 随着互联化的蔓延，各种项目都逐渐向分布式服务做转换

kafka集群并测试其高可用性 介绍 Kafka 是由 Apache软件基金会 开发的一个开源流处理平台，由 Scala 和 Java 编写。Kafka是一种高吞吐量的 分布式 发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像 Hadoop 一样的 日志 数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过 Hadoop 的并行加载机制来统一线上和离线的消息处理，也是为了通过 集群 来提供实时的消息。 一、KAFKA 体系结构图： Producer： 生产者，也就是发送消息的一方。生产者负责创建消息，通过zookeeper找到broker，然后将其投递到 Kafka 中。 Consumer： 消费者，也就是接收消息的一方。通过zookeeper找对应的broker 进行消费，进而进行相应的业务逻辑处理。 Broker： 服务代理节点。对于 Kafka 而言，Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。大多数情况下也可以将 Broker 看作一台 Kafka 服务器，前提是这台服务器上只部署了一个 Kafka 实例。一个或多个