分布式一致性

本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎，进行各种聚合运算，产生输出结果，并且写入下游。 现代的一些处理框架

Spring Cloud Cluster将取代Spring Integration。提供在分布式系统中的集群所需要的基础功能支持，如：选举、集群的状态一致性、全局锁、tokens等常见状态模式的抽象和实现。 如果把不同的帮派组织成统一的整体，Spring Cloud Cluster已经帮你提供了很多方便组织成统一的工具。 出处： https://www.cnblogs.com/ityouknow/p/6791221.html 来源： https://www.cnblogs.com/cag2050/p/11640569.html

　　Consul 是一套开源的分布式服务发现和配置管理系统，由 HashiCorp 公司用 Go 语言开发。它具有很多优点。包括：基于 raft 协议，比较简洁； 支持健康检查, 同时支持 HTTP 和 DNS 协议 支持跨数据中心的 WAN(广域网) 集群 提供图形界面 跨平台，支持 Linux、Mac、Windows。 　　consul是使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。 　　raft（分布式一致性协议）：见《 一致性算法之：Raft 》　 　　@client 　　CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。 　　@server 　　SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样

MQ背景&选型 消息队列作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。主要具有以下优势： 削峰填谷（主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题） 系统解耦（解决不同重要程度、不同能力级别系统之间依赖导致一死全死） 提升性能（当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统） 蓄流压测（线上有些链路不好压测，可以通过堆积一定量消息再放开来压测） 目前主流的MQ主要是Rocketmq、kafka、Rabbitmq，Rocketmq相比于Rabbitmq、kafka具有主要优势特性有： • 支持事务型消息（消息发送和DB操作保持两方的最终一致性，rabbitmq和kafka不支持） • 支持结合rocketmq的多个系统之间数据最终一致性（多方事务，二方事务是前提） • 支持18个级别的延迟消息（rabbitmq和kafka不支持） • 支持指定次数和时间间隔的失败消息重发（kafka不支持，rabbitmq需要手动确认） • 支持consumer端tag过滤，减少不必要的网络传输（rabbitmq和kafka不支持） • 支持重复消费（rabbitmq不支持，kafka支持） Rocketmq、kafka、Rabbitmq的详细对比，请参照下表格： RocketMQ集群概述 RocketMQ集群部署结构 image

分布式一致性理论 CAP 理论 一个分布式系统 不可能同时满足 一致性（ C:Consistency )，可用性（ A: Availability ）和分区容错性（ P：Partition tolerance ）这三个基本需求， 最多只能同时满足其中的 2 个 。 如下： 选项 描述 C(Consistence) 一致性 ，指数据在多个副本之间能够保持一致的特性（ 严格的一致性 ）。 A(Availability) 可用性 ，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。 P(Network partitioning) 分区容错性 ，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。 Base 理论 BASE 是 Basically Available (基本可用) ，Soft state （软状态）,和 Eventually consistent （最终一致性）三个短语的缩写。 既是无法做到 强一致性 （ Strong consistency ），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到 最终一致性 （ Eventual consistency ） 基本可用 允许出现响应时间损失或者功能损失。 软状态 允许系统中的数据存在中间状态

 介绍常见的分布式一致性协议 一．CAP/BASE 1. CAP理论  CAP理论又称之为布鲁尔定理（Brewer’S theorem），认为在设计一个大规模可扩放的网络服务时候不能同时兼容：一致性（consistency）、可用性（Availability）、分区容错（Partition-tolerance）。  一致性：在分布式系统中的所有数据备份，在同一时刻是否有同样的值。（等同于所有节点访问同一份最新的数据副本）  可用性：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。  分区容忍性：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择  CAP理论容易理解，网上也有关于该理论的说明，包括模型的简易证明；弱条件下模型的成立等。  参考资料： http://www.cnblogs.com/mmjx/archive/2011/12/19/2290540.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html 2. BASE理论  BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写

Zookeeper使用了一种称为Zab（Zookeeper Atomic Broadcast）的协议作为其一致性复制的核心，据其作者说这是一种新发算法，其特点是充分考虑了Yahoo的具体情况：高吞吐量、低延迟、健壮、简单，但不过分要求其扩展性。下面将展示一些该协议的核心内容： 另，本文仅讨论Zookeeper使用的一致性协议而非讨论其源码实现 Zookeeper的实现是有Client、Server构成，Server端提供了一个一致性复制、存储服务，Client端会提供一些具体的语义，比如分布式锁、选举算法、分布式互斥等。从存储内容来说，Server端更多的是存储一些数据的状态，而非数据内容本身，因此Zookeeper可以作为一个小文件系统使用。数据状态的存储量相对不大，完全可以全部加载到内存中，从而极大地消除了通信延迟。 Server可以Crash后重启，考虑到容错性，Server必须“记住”之前的数据状态，因此数据需要持久化，但吞吐量很高时，磁盘的IO便成为系统瓶颈，其解决办法是使用缓存，把随机写变为连续写。 考虑到Zookeeper主要操作数据的状态，为了保证状态的一致性，Zookeeper提出了两个安全属性（Safety Property） 全序（Total order）：如果消息a在消息b之前发送，则所有Server应该看到相同的结果 因果顺序（Causal order）

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

来自：51CTO技术栈 例如：单表中出现了，动辄百万甚至千万级别的数据。“分表分库”就成为解决上述问题的有效工具。 今天和大家一起看看，如何进行分表分库以及期间遇到的问题吧。 为什么会分表分库 数据库数据会随着业务的发展而不断增多，因此数据操作，如增删改查的开销也会越来越大。 再加上物理服务器的资源有限（CPU、磁盘、内存、IO 等）。最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。 换句话说需要合理的数据库架构来存放不断增长的数据，这个就是分库分表的设计初衷。目的就是为了缓解数据库的压力，最大限度提高数据操作的效率。 数据分表 如果单表的数据量过大，例如千万级甚至更多，那么在操作表的时候就会加大系统的开销。 每次查询会消耗数据库大量资源，如果需要多表的联合查询，这种劣势就更加明显了。 以 MySQL 为例，在插入数据的时候，会对表进行加锁，分为表锁定和行锁定。 无论是哪种锁定方式，都意味着前面一条数据在操作表或者行的时候，后面的请求都在排队，当访问量增加的时候，都会影响数据库的效率。 那么既然一定要分表，那么每张表分配多大的数据量比较合适呢？这里建议根据业务场景和实际情况具体分析。 一般来说 MySQL 数据库单表记录最好控制在 500 万条（这是个经验数字）。既然需要将数据从一个表分别存放到多个表中，那么来看看下面两种分表方式吧。 垂直分表 根据业务把一个表中的字段

项目常见面试问题 阅读目录 项目常见面试问题 回到目录 项目常见面试问题 一、你的项目中缓存粒度是如何选择的? 缓存粒度一共分为4种. 1.缓存某个数值:一个键只保存一个值,性价比较低,使用率低,如果存储的话我们使用redis的String 2.缓存数据对象:数据库记录对应的具体数据,优点是可以多次复用,String,hash 3.缓存数据集合:数据库查询对应的结果集,可以和数据对象配合使用,方便数据对象的重用,hash,list,set,zset,String(zset,String) 4.缓存试图响应:试图返回的相应数据,复用性比较差,String 所以我们项目中主要对数据集合+数据对象进行缓存,他们的优点是复用性强,节省内存空间. 二、使用过redis的那些格式做过缓存,其他应用场景和优缺点是什么? 包括list,zset,set,hash和json字符串 其中我们使用过json字符串和zset set用来存放无序去重的数据, 如果有判断是否存在的需求 zset有排序的需要list,如果说是按时间查询, 查询的结果固定, 不需要分页的情况下,我们使用list因为查询的比较快 但如果有额外排序要求, 而且需要分页, 我们使用zset(查询时间跟查询的长度和数据量有关,跟查询区别无关, 查询速度比较均衡), 增加数据效率和存储的数据量负相关,数据量越大,添加时间越长