分布式一致性

1：CAP理论核心 CAP理论的核心是：一个分布式系统不可能同时很好的满足 一致性，可用性和分区容错性 这三个需求， 最多只能同时较好的满足两个。 因此，根据CAP原理将NoSQL数据库分成了 满足CA原则、满足CP原则和满足AP原则 三大类: CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。 CP：满足一致性，分区容忍必的系统， 通常性能不是特别高 。 AP：满足可用性，分区容忍性的系统， 通常可能对一致性要求低一些 。 CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以 分区容忍性 是我们必须需要实现的。所以我们只能在 一致性和可用性 之间进行权衡，没有 NoSQL系統能同时保证这三点。 C:强一致性 A:高可用性 P:分布式容忍性 CA：传统Oracle数据库 AP：大多数网站架构的选择 CP ：Redis、Mongodb 注意:分布式架构的时候必须做出取舍。 2：一致性与可用性抉择 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地。 数据库事务一致性需求： 很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一 致性要求 并不高。允许实现最终一致性。 数据库的写实时性和读实时性需求： 对关系数据库来说，插入一 条数据之后立刻查询

引言 为什么写这篇文章? 博主的《分布式之消息队列复习精讲》得到了大家的好评，内心诚惶诚恐，想着再出一篇关于复习精讲的文章。但是还是要说明一下，复习精讲的文章偏面试准备，真正在开发过程中，还是脚踏实地，一步一个脚印，不要投机取巧。 考虑到绝大部分写业务的程序员，在实际开发中使用redis的时候，只会setvalue和getvalue两个操作，对redis整体缺乏一个认知。又恰逢博主某个同事下周要去培训redis，所以博主斗胆以redis为题材，对redis常见问题做一个总结，希望能够弥补大家的知识盲点。 复习要点? 本文围绕以下几点进行阐述 1、为什么使用redis 2、使用redis有什么缺点 3、单线程的redis为什么这么快 4、redis的数据类型，以及每种数据类型的使用场景 5、redis的过期策略以及内存淘汰机制 6、redis和数据库双写一致性问题 7、如何应对缓存穿透和缓存雪崩问题 8、如何解决redis的并发竞争问题 正文 1、为什么使用redis 分析:博主觉得在项目中使用redis，主要是从两个角度去考虑:性能和并发。当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等)代替，并不是非要使用redis。因此，这个问题主要从性能和并发两个角度去答。 回答:如下所示，分为两点 （一）性能

ZooKeeper理论基础 1 ZooKeeper简介 2 一致性 2.1 顺序一致性 2.2 原子性 2.3 单一视图 2.4 可靠性 2.5 最终一致性 3 ZAB协议 3.1 ZAB协议简介 3.2 ZAB与Paxos的关系 3.3 三类角色 3.4 三个数据 3.5 三种模式 3.6 四种状态 3.7 同步模式与广播模式 (1) 初始化广播 (2) 消息广播算法 (3) Observer的数据问题 3.8 恢复模式的三原则 (1) Leader的主动出让原则 (2) 已被处理过的消息不能丢原则 (3) 被丢弃的消息不能再现原则 3.9 Leader选举 (1) Leader选举中的基本概念 A. myid B.逻辑时钟 （2）Leader选举算法 A.集群启动中的Leader选举 B.宕机后的eader选举 4.高可用集群容灾 4.1 服务器数量的奇数与偶数 4.2 容灾设计方案 (1) 三机房部署 (2) 双机房部署 5.CAP定理 5.1 简介 5.2 BASE理论 (1) 基本可用 (2) 软状态 (3) 最终一致性 5.3 ZK与CP 6.zk可能会存在脑裂 1 ZooKeeper简介 ZooKeeper由雅虎研究院开发，后来捐赠给了Apache。ZooKeeper是一个开源得分布式应用程序协调服务器，其为分布式系统提供 一致性 服务

简介 该篇blog只是存储系列科普文章中的第四篇，所有文章请参考： 博客所有文章 在工程架构领域里，存储是一个非常重要的方向，这个方向从底至上，我分成了如下几个层次来介绍： 硬件层：讲解磁盘，SSD，SAS, NAS, RAID等硬件层的基本原理，以及其为操作系统提供的存储界面； 操作系统层：即文件系统，操作系统如何将各个硬件管理并对上提供更高层次接口； 单机引擎层：常见存储系统对应单机引擎原理大概介绍，利用文件系统接口提供更高级别的存储系统接口； 分布式层：如何将多个单机引擎组合成一个分布式存储系统； 查询层：用户典型的查询语义表达以及解析； 分布式系统主要分成存储模型和计算模型两类。本文主要描述的是存储模型的介绍。其中计算模型的分布式系统原理跟存储模型类似，只是会根据自身计算特点加一些特殊调度逻辑进去。 分布式层 分布式系统简介 任何一个分布式系统都需要考虑如下5个问题： 数据如何分布 就像把鸡蛋放进篮子里面。一般来说篮子大小是一样的，当然也有的系统支持不一样大小的篮子。鸡蛋大小也不一样，有很多系统就把鸡蛋给"切割"成一样大小然后再放。并且有的鸡蛋表示对篮子有要求，比如对机房/机架位的要求。 衡量一个数据分布算法好不好就看他是否分得足够均匀，使得所有机器的负载方差足够小。 如何容灾 分布式系统一个很重要的定位就是要让程序自动来管机器，尽量减少人工参与

转自： https://cs.xieyonghui.com/architecture/35.html Paxos是唯一的一致性算法，其他都是paxos不完整版，Google Chubby作者Mike Burrows曾这样评价Paxos。 解决的问题 Paxos算法解决的问题：分布式系统如何就某个值（决议）达成一致。 历史 1990年Leslie Lamport提交Paxos算法论文The Part-Time Parliament，未受太多关注。 2001年发布通俗简化版 Paxos Made Simple ，剔除公式部分。 场景 爱琴海paxos岛住着一群居民，通过议会形式取代神权政治，事情由议会选举决定。 议员总数确定，岛上每个提议都有一个编号，编号不断增长且不能回退。 提议超半数议员同意就会生效。 每个议员有一个记事本，记录曾经同意过或通过的提议编号，编号随提议不断更新。 每个议员只会同意大于当前编号的提议。 若收到小于或等于当前编号的提议会拒绝提议并通知提出方。 岛上议员以义工方式出现，所以，不保证每个提议的投票在同一时间完成。因此，一定时间内议员们手中的编号并不统一。 议会目标： 议员们对提议达成一致看法。 投票 议会开始时，议员们手中记事本编号统一为0。 当议员发出提议时，先查看自己的记事本，在当前记录基础上加1，作为新提议编号，然后，通知其他议员。 其他议员们收到通知

在弄清楚这个问题之前，我们先了解一下什么是分布式的CAP定理。 根据百度百科的定义，CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。 一、CAP的定义 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体

目录 1、数据分布 2、哈希方式 3、一致性哈希方式 笔记来自分布式原理一书，供个人学习。 数据分布 单机系统与分布式系统的最大的区别在于问题的规模，即计算、存储的数据量的区别。将一个单机问题使用分布式解决，首先要解决的就是如何将问题拆解为可以使用多机分布式解决，使得 分布式系统中的每台机器负责原问题的一个子集。由于无论是计算还是存储，其问题输入对象都是数据，所以如何拆解分布式系统的输入数据成为分布式系统的基本问题，我们称这样的数据拆解为数据分布方式。 哈希方式 哈希方式是最常见的数据分布方式，其方法是按照数据的某一特征计算哈希值，并将哈希值与机器中的机器建立映射关系，从而将不同哈希值的数据分布到不同的机器上。所谓数据特征可以是 key-value 系统中的 key，也可以是其他与应用业务逻辑相关的值。例如，一种常见的哈希方式是按数据属于的用户 id 计算哈希值，集群中的服务器按0到机器数减 1 编号，哈希值除以服务器的个数，结果的余数作为处理该数据的服务器编号。工程中，往往需要考虑服务器的副本冗余，将每数台（例如 3）服务器组成一组，用哈希值除以总的组数，其余数为服务器组的编号。图 2-1 给出了哈希方式分数据的一个例子，将数据按哈希值分配到 4 个节点上。 哈希方式特点 ： 1.每个节点只计算一部分数据；每个节点只存储一部分数据。 我们假设节点的数量没有变化（实际上不可能）

1、解决分布式单点问题 https://www.jianshu.com/p/08b76bd7a634 2、实现分布式环境数据的一致性、访问ZooKeeper树结构时，不同节点返回的数据是一致，不会引起脏读、重复读。 3、用以实现高吞吐、低延迟、一致性、可用性的应用。 来源： https://www.cnblogs.com/jx9527/p/12199493.html

原文: 分布式事务,EventBus 解决方案:CAP【中文文档】 最新文档地址： https://github.com/dotnetcore/CAP/wiki 前言 很多同学想对CAP的机制以及用法等想有一个详细的了解，所以花了将近两周时间写了这份中文的CAP文档，对 CAP 还不知道的同学可以先看一下 这篇文章 。 本文档为 CAP 文献（Wiki），本文献同时提供中文和英文版本，英文版本目前还在翻译中，会放到Github Wiki 中。 目录 前言 1、Getting Started 1.1 介绍 1.2 应用场景 1.3 Quick Start 2、API接口 2.1 发布/发送 2.1.1 事务 2.2 订阅/消费 2.2.1 例外情况 3、配置 3.1 Cap Options 3.2 RabbitMQ Options 3.3 Kafka Options 3.4 SqlServer Options 3.5 MySql Options 4、设计原理 4.1 动机 4.2 持久化 4.3 通讯数据流 4.4 一致性 5、实现 5.1 消息表 5.2 消息格式 5.3 EventBus 5.4 重试 6、分布式事务 6.1 异步确保 7、FAQ 1、Getting Started 1.1 介绍 CAP 是一个遵循 .NET Standard 标准库的C#库

问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。 强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如