可用性

ActiveMQ 　　 单机吞吐量： 万级 　　 topic数量对吞吐量的影响： 　　 时效性： ms级 　　 可用性： 高，基于主从架构实现高可用性 　　 消息可靠性： 有较低的概率丢失数据 　　 功能支持： MQ领域的功能极其完备 　　 总结： 　　　　非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用 　　　　偶尔会有较低概率丢失消息 　　　　现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本 　　　　主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用 RabbitMQ 　　 单机吞吐量： 万级 　　 topic数量对吞吐量的影响： 　　 时效性： 微秒级，延时低是一大特点。 　　 可用性： 高，基于主从架构实现高可用性 　　 消息可靠性： 　　 功能支持： 基于erlang开发，所以并发能力很强，性能极其好，延时很低 　　 总结： 　　 　　　　erlang语言开发，性能极其好，延时很低； 　　　　吞吐量到万级，MQ功能比较完备 　　　　开源提供的管理界面非常棒，用起来很好用 　　　　社区相对比较活跃，几乎每个月都发布几个版本分 　　　　在国内一些互联网公司近几年用rabbitmq也比较多一些 但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。 　　　

CAP CAP是一个已经经过证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 一致性 我们知道ACID中事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。也就是说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。 和ACID中的一致性不同，分布式环境中的一致性是指数据在多个副本之间是否能够保持一致的特性。 分布式系统中，数据一般会存在不同节点的副本中，如果对第一个节点的数据成功进行了更新操作，而第二个节点上的数据却没有得到相应更新，这时候读取第二个节点的数据依然是更新前的数据，即脏数据，这就是分布式系统数据不一致的情况。 在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。 可用性 可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果，如果超过了这个时间范围，那么系统就被认为是不可用的。 “有限的时间内”是在系统的运行指标，不同系统会有差别。例如搜索引擎通常在0.5秒内需要给出用户检索结果。 “返回结果”是可用性的另一个重要指标

数据保护：RAID RAID级别 RAID级别根据分条、数据镜像以及奇偶校验技术的不同而定义。 分条 条带 将磁盘上一块由若干地址连续的磁盘块构成的、大小固定的区域定义为条带。 位于RAID集所有磁盘上相同位置的条带构成了分条。 条带尺寸（分条深度） 描述构成条带的磁盘块数目。 如果数据访问总从条带的起始位置开始，那么条带尺寸等于单个磁盘单次所能读写的最大数据量，此后的读写将切换至下一块磁盘。 分条尺寸 =条带尺寸*RAID集中硬盘数量 分条宽度 =一个分条包含的数据条带的数目=硬盘个数 作用 可将数据分为几块，分块并发写入（读）各个磁盘，提升读写操作性能。 数据镜像 同一数据存储在两块不同硬盘，产生两个副本。 一个损坏另一个可以提供服务。当用新磁盘替换损坏磁盘后，数据会从幸存磁盘完整拷贝过去。这个过程对于主机是完全透明的。 作用 数据冗余； 磁盘故障恢复（但不适用于备份，因为备份要保存不同时间点的数据状态，而磁盘镜像只会不断更新最新的）； 提升读操作性能 场景 所需的磁盘容量为实际存储数据总量的两倍，因此只有在极端无法承受数据损坏的应用中才会考虑如此高昂的代价。此外，可以提高访问的性能，因为两块磁盘可以同时响应一个读请求。但每个写访问将导致两次写操作，其写访问性能会下降。 奇偶校验 在分条中增加一个硬盘（分条宽度+1）来存储校验值。 实际上，校验值计算采用 异或 操作

什么是大规模高并发？ 大规模高并发是两个词，前者表示有大量的流量访问，后者表示竞争状态下并发可能会遇到的一致性和可用性问题。 有什么问题？ 如果只是大规模的流量，我们可以简单的进行负载均衡和针对架构层面的优化就能解决，这一块和业务并无直接联系。 但是高并发就不一样了，就算只有不太多的流量，只要存在并发竞争关系，必然会牵扯到状态的一致性和业务流程的拆分优化。 最重要的是状态，由于状态需要被维护，因此针对状态的伸缩扩展一直以来很容易跟技术发生混淆，我们必须要明确的一点就是，如果状态竞争在业务层面没有得到有效的解决，在技术层面目前也是无法得到有效的解决的。 可以想象，无状态的服务很容易得到拓展，只需要增加处理节点，均匀的负载流量，路由到指定的节点处理即可。 所以关键在于业务要如何拆分？状态要如何维护？这是下面将要讲到的。 如何解决？ 大规模低并发 这种是最容易解决的，只需要增加处理节点即可，因为不需要牵扯到状态的维护，因此也无须担心会发生副作用。 一般来讲，HTTP请求将会被均匀的路由给不同的节点进行处理，我们可以做到无限拓展，只需要在适当的条件下进行伸缩即可。 因为不存在状态的维护，因此和业务关系不大，只需要在技术层面进行优化。 大规模高并发 有时间的可以读一下我之前写的这篇文章（ https://www.cnblogs.com/xingxueliao/p/11561263.html

RabbitMQ -高可用性(HA) HAProxy 是一个免费的负载均衡软件，可以运行于大部分主流的 Linux 操作系统上。 HAProxy 提供了 L4(TCP) 和 L7(HTTP) 两种负载均衡能力，具备丰富的功能。 HAProxy 的社区非常活跃，版本更新快速。最关键的是， HAProxy 具备媲美商用负载均衡器的性能和稳定性。它当前不仅仅是免费负载均衡软件的首选，更几乎成为了唯一选择。 因为 RabbitMQ 本身不提供负载均衡，下面我们就搭建 HAProxy ，用作 RabbitMQ 集群的负载均衡。 1: 安装 haproxy 在 node1 上面 [root@node1 ~]# yum install haproxy -y 2: 配置 haproxy [root@node1 ~]# cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak [root@node1 ~]# vim /etc/haproxy/haproxy.cfg 3: 将下面的配置添加到 /etc/haproxy/haproxy.cfg 文件中： global log 127.0.0.1 local0 info log 127.0.0.1 local1 notice daemon maxconn 4096 defaults log

分布式CAP理论( 来源 ) 一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。 如果能容忍后续的部分或者全部访问不到，则是弱一致性。 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。 CAP中说，不可能同时满足的这个一致性指的是强一致性。 CA without P 分布式环境下，分区是必然的，所以如果舍弃P，意味着要舍弃分布式系统 CP without A 如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。 AP wihtout C 要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。 孰优孰略，没有定论，只能根据场景定夺，适合的才是最好的。 对于涉及到钱财这样不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务，这是保证CP，舍弃A。比如前几年支付宝光缆被挖断的事件，在网络出现故障的时候，支付宝就在可用性和数据一致性之间选择了数据一致性，用户感受到的是支付宝系统长时间宕机

这个怎么说呢？？？网上说的天花乱坠，说什么的都有，很早以前我感觉我理解了，现在回过头完全不知.... 首先我先描述下CAP，然后再详细解释。 1、可用性，也就是所谓的A（Consistency） 是指系统中任何一个节点宕机，其他节点也可以继续对外正常（此处待议）提供服务。 2、一致性，也就是所谓的C（Availability） 这个是比较好理解的，是指数据在任何时候，读取数据都是一致的，此处一致性指的是强一致性。 3、分区容忍性，也就是所谓的P（Partition tolerance） 这个是比较抽象点，分区容忍性强调是指系统中的节点因网络原因中断连接，导致出现分区现象，可以理解原本是整体，节点之间相互交互。出现这个现象和可用性不同地方在于，都可对外提供服务，但因出现分区，如果数据分区存储，就会出现对外提供数据异常。 争议问题 可用性： 什么算可用？什么算不可用？我程序出现异常，返回一个程序异常提示，算可用？如果算，那这个可用性就好处理了，处理不了我就都返回，那我就可以说我的程序是可用的？？？还是说可用指的是可以正常的业务场景处理，A、B两节点，A节点宕掉，B节点可以继续处理请求。所以，理解不同导致网上说法也大不一样。 一致性： 一致性是指强一致性，虽然时间差距在毫秒也不可否认有差距。大部分主从结构都是这样的，写入主节点后，会有线程会将数据写一份给从库

开发单体应用时，相信大家都有使用过数据库的 本地事务 ，也就是在同一个数据库中，可以允许一组操作要么全都正确执行，要么全都不执行。这里特别指出了本地事务，也就是说明数据库事务只支持同一个数据库的操作。可随着技术和业务发展，一方面随着系统业务量增大，数据库存储东西越来越多。当达到一定数据量时，为了应对高并发，就会出现分库分表需求。另一方面，随着服务化方案的推广，越来越多的公司团队将原有的大项目拆分成一个个小应用，这也使得跨应用（JVM）数据库场景出现。可是目前数据库不支持跨库事务，我们应该如何实现分布式事务呢？本文首先会为大家梳理分布式事务的基本概念和理论基础，然后介绍几种目前常用的分布式事务解决方案。 一、定义 百度百科给出的定义：“分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。”简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 二、事务的四大特性 ACID 1.原子性 原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。 2.一致性 一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。 3.隔离性

历史优质文章： 可能是最漂亮的Spring事务管理详解 面试中关于Java虚拟机（jvm）的问题看这篇就够了 Java NIO 概览 分布式系统设计理念 分布式系统架构的第一原则是不要分布！这句话看似矛盾实则揭露了分布式系统的很多特征。 分布式系统的目标与要素 分布式系统的目标是提升系统的整体性能和吞吐量另外还要尽量保证分布式系统的容错性（假如增加10台服务器才达到单机运行效果2倍左右的性能，那么这个分布式系统就根本没有存在的意义）。 即使采用了分布式系统，我们也要尽力运用并发编程、高性能网络框架等等手段提升单机上的程序性能。 分布式系统设计两大思路：中心化和去中心化 1）中心化设计： 两个角色： 中心化的设计思想很简单，分布式集群中的节点机器按照角色分工，大体上分为两种角色： “领导” 和 “干活的” 角色职责： “领导”通常负责分发任务并监督“干活的”，发现谁太闲了，就想发设法地给其安排新任务，确保没有一个“干活的”能够偷懒，如果“领导”发现某个“干活的”因为劳累过度而病倒了，则是不会考虑先尝试“医治”他的，而是一脚踢出去，然后把他的任务分给其他人。其中微服务架构 Kubernetes 就恰好采用了这一设计思路。 中心化设计的问题 ： 中心化的设计存在的最大问题是“领导”的安危问题，如果“领导”出了问题，则群龙无首，整个集群就奔溃了。但我们难以同时安排两个“领导”以避免单点问题

【背景】 随着单体应用的缺陷日益明显，越多越多的公司都从传统的单体应用模式向新型的分布式应用模式转变。 实际上，在分布式应用带来巨大优势的同时，也伴随着各种挑战。例如，系统容错、网络延迟和分布式事务等。 本篇博客开始，将会对分布式事务做一系列学习总结。从本篇博客，我们可以了解到什么是分布式事务，关于分布式事务的相关理论以及处理分布式事务的解决方案。 【本地事务】 在没有接触分布式应用前，我们接触到的事务一般都是本地事务，即在单个数据库并且限制在单个进程内的事务。本地事务不涉及多个数据源。 若我们的系统使用了spring，一般加上@Transition注解即可保证事务正常运行。但如果是分布式系统应用下，若操作涉及不同的数据库，这样本地事务就失效了，从而就涉及到了分布式事务。 【分布式事务】 1. 什么是分布式事务 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2. 分布式事务的产生原因 从原来的单体应用到分布式应用的转变，便意味着从以前的一个系统到多个服务共同组成一个系统的转变。 如一个电商系统，拆分为订单