paxos

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 实例。一个或多个

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 问题: I am implementing Paxos in a cluster simulator application, using the documentation available in Wikipedia . Unfortunately, it leaves several doors open to interpretation and does not provide much information on key implementation issues. It is unclear and incomplete. Assuming a cluster divided in 3 regions, each containing 3 nodes (total = 9 nodes). What happens if communication is broken between regions? There is no way any leader can reach quorum (which is 5). Isn't Paxos going to enter an infinite loop? I guess one should not initiate

Paxos作用：取值一致性 Paxos应用：分布式多副本的更新操作序列[opration1，opration2，opration3]需要相同，用Paxos确定操作序列。Google的Chubby、Megastore和Spanner都采用了Paxos来对数据副本的更新序列达成一致。 Paxos组成：系统内由多个Acceptor组成，负责存储和管理变量var；外部有多个Proposer任意并发调用API，向系统提交不同的var值；learner记录最终确定的值。 Paxos容错性：可以容忍任意Proposer故障；可以容忍半数以下的Acceptor故障。 Paxos一致性：如果var的值没有确定，则为null；一旦确定，则不可更改，后者认同前者。 Paxos算法详解： 实现一（锁方式） 实现： Proposer向Accpetor申请互斥访问权，一旦Acceptor接收了某个Proposer的值，则var确定，其它proposer不可更改此值。 如果一个proposer获取到了Acceptor的访问权，且Acceptor的值不为null，此proposer不可修改此值并应用此值。 缺点： 一个Proposer首先获取到一个Acceptor的互斥锁，接着在这个proposer释放此锁之前自己挂掉了，因为它的锁还没有释放，所以其它的Proposer都永远不能获取到锁，出现了死锁问题。 实现二

随承载用户数量的增加和容灾的需要，越来越多互联网后台系统从单机模式切换到分布式集群。回顾自己毕业五年来的工作内容，同样有这样的转变。 毕业头两年负责维护运行在刀片机上的业务，在机房里拔插单板的日子是我逝去的青春。设备之间通过VCS组成冷备，但即使有双机软件保护，宕机、网络丢包等问题发生时业务仍会受影响。这样的系统架构下为保证SLA，有时候需要深入Linux系统内核或硬件层面分析机器重启的原因。 接下来负责维护承载在分布式集群上的业务，相比前面的工作，这个阶段主要关注点不是单节点的异常，更多是系统整体的稳定和健壮。面对纷繁复杂的系统，刚开始的时候有这样的感觉： 庞大复杂的分布式系统前，应该从哪方面入手提升对其的认识和理解、提升专业性？网上可以找到很多分布式系统相关的论文和资料，但归纳起来要表达的主要意思是什么？ 结合自己这几年的工作经验，总结分布式系统的核心就是解决一个问题：不同节点间如何达成共识。 看似简单的问题因网络丢包、节点宕机恢复等场景变得复杂，由此才衍生出很多概念、协议和理论。为探究共识问题最大能解决的程度，于是有FLP、CAP边界理论；为在特定条件和范围内解决该问题，于是有一致性协议Paxos、Raft、Zab和Viewstamped Replication；为构建这些协议，于是有多数派、Leader选举、租约、逻辑时钟等概念和方法。

1. 二阶段提交算法 1.1 算法描述： 在分布式系统中，事务往往包含有多个参与者的活动，单个参与者上的活动是能够保证原子性的，而多个参与者之间原子性的保证则需要通过两阶段提交来实现，两阶段提交是分布式事务实现的关键。 　　很明显，两阶段提交保证了分布式事务的原子性，这些子事务要么都做，要么都不做。而数据库的一致性是由数据库的完整性约束实现的，持久性则是通过commit日志来实现的，不是由两阶段提交来保证的。至于两阶段提交如何保证隔离性，可以参考Large-scale Incremental Processing Using Distributed Transactions and Notifications中两阶段提交的具体实现。 　　两阶段提交的过程涉及到协调者和参与者。协调者可以看做成事务的发起者，同时也是事务的一个参与者。对于一个分布式事务来说，一个事务是涉及到多个参与者的。具体的两阶段提交的过程如下： 第一阶段： 　　首先，协调者在自身节点的日志中写入一条的日志记录，然后所有参与者发送消息prepare T，询问这些参与者（包括自身），是否能够提交这个事务； 　　参与者在接受到这个prepare T 消息以后，会根据自身的情况，进行事务的预处理，如果参与者能够提交该事务，则会将日志写入磁盘，并返回给协调者一个ready T信息，同时自身进入可提交状态；如果不能提交该事务

Could someone give me a list of real use cases of Paxos. That is real problems that require consensus as part of a bigger problem. Is the following a use case of Paxos? Suppose there are two clients playing poker against each other on a poker server. The poker server is replicated. My understanding of Paxos is that it could be used to maintain consistency of the inmemory data structures that represent the current hand of poker. That is, ensure that all replicas have the exact same inmemory state of the hand. But why is Paxos necessary? Suppose a new card needs to be dealt. Each replica running

Can someone explain me simply the main differences between Operational Transform and CRDT? As far as I understand, both are algorithms that permits data to converge without conflict on different nodes of a distributed system. In which usecase would you use which algorithm? As far as I understand, OT is mostly used for text and CRDT is more general and can handle more advanced structures right? Is CRDT more powerful than OT? I ask this question because I am trying to see how to implement a collaborative editor for HTML documents, and not sure in which direction to look first. I saw the ShareJS

Zookeeper简介 Zookeeper是一个高效的分布式协调服务，可以提供配置信息管理、命名、分布式同步、集群管理、数据库切换等服务。它 不适合用来存储大量信息，可以用来存储一些配置、发布与订阅等少量信息。Hadoop、Storm、消息中间件、RPC服务框架、分布式数据库同步系统，这些都是Zookeeper的应用场景。 Zookeeper集群中节点个数一般为奇数个（>=3），若集群中Master挂掉，剩余节点个数在半数以上时，就可以推举新的主节点，继续对外提供服务。 客户端发起事务请求，事务请求的结果在整个Zookeeper集群中所有机器上的应用情况是一致的。不会出现集群中部分机器应用了该事务，而存在另外一部分集群中机器没有应用该事务的情况。在Zookeeper集群中的任何一台机器，其看到的服务器的数据模型是一致的。Zookeeper能够保证客户端请求的顺序，每个请求分配一个全局唯一的递增编号，用来反映事务操作的先后顺序。Zookeeper将全量数据保存在内存中，并直接服务于所有的非事务请求，在以读操作为主的场景中性能非常突出。 Zookeeper使用的数据结构为树形结构，根节点为"/"。Zookeeper集群中的节点，根据其身份特性分为leader、follower、observer。leader负责客户端writer类型的请求

#0 系列目录# 分布式设计与开发 CAP原理和最终一致性(Eventually Consistency) 分布式算法 [分布式Paxos算法] 分布式一致性Hash算法 轮循算法（Round Robin） Hash求余算法（Hash） 最少连接算法（Least Connection） 响应速度算法（Response Time） 加权算法（Weighted） 分布式消息 分布式发布订阅消息系统Kafka架构设计 分布式缓存 Redis 分布式 Memcached 分布式 分布式存储 分布式事务 #1 分布式介绍# 分布式可繁也可以简，最简单的分布式就是大家最常用的， 在负载均衡服务器后加一堆web服务器，然后在上面搞一个缓存服务器来保存临时状态 ，后面共享一个数据库， 其实很多号称分布式专家的人也就停留于此 ，大致结构如下图所示： 这种环境下 真正进行分布式的只是web server而已 ，并且web server之间没有任何联系，所以结构和实现都非常简单。 有些情况下，对分布式的需求就没这么简单，在每个环节上都有分布式的需求，比如Load Balance、DB、Cache和文件等等，并且当分布式节点之间有关联时，还得考虑之间的通讯，另外，节点非常多的时候，得有监控和管理来支撑。这样看起来， 分布式是一个非常庞大的体系 ，只不过你 可以根据具体需求进行适当地裁剪

In Multi-Paxos algorithm, consider this message flow from the viewpoint of an acceptor: receive: Prepare(N) reply: Promise(N, null) receive: Accept!(N, V1) reply: Accepted(N, V1) receive: Accept!(N+1, V2) reply: ? What should the acceptor's reaction be in this case, according to the protocol? Should it reply with Accepted(N+1, V2), or should it ignore the second Accept!? I believe this case may happen in Multi-Paxos when a second proposer comes online and believes he is (and always was) leader, therefore he sends his Accept without Preparing. Or if his Prepare simply did not reach the acceptor