作者归档
译《The Part-Time Parliament》——终于读懂了Paxos协议!
原文发布在MessageQueue公众号,欢迎关注!
最近的考古发现表明,在Paxos小岛上,尽管兼职议会成员都有逍遥癖,但议会模式仍然起作用。他们依旧保持了一致的会议记录,尽管他们频繁的进出会议室并且他们的信使还很健忘。Paxon议会协议提供了一种新方法去实现设计分布式系统的状态机。
阅读全文Apache Pulsar介绍
Apache Pulsar
What is Pulsar
“Pulsar is a distributed pub-sub messaging platform with a very flexible messaging model and an intuitive client API.”
Pulsar是pub-sub模式的分布式消息平台,拥有灵活的消息模型和直观的客户端API。
Pulsar由雅虎开发并开源的下一代消息系统,目前是Apache软件基金会的孵化器项目。
解读Raft(四 成员变更)
将成员变更纳入到算法中是Raft易于应用到实践中的关键,相对于Paxos,它给出了明确的变更过程(实践的基础,任何现实的系统中都会遇到因为硬件故障等原因引起的节点变更的操作)。
显然,我们可以通过shutdown集群,然后变更配置后重启集群的方式达到成员变更的目的。但是这种操作会损失系统的可用性,同时会带来操作失误引起的风险。支持自动化配置,即配置可以在集群运行期间进行动态的变更(不影响可用性)显示是一个非常重要的特性。
解读Raft(三 安全性)
前言
之前的两篇文章更多的是在描述Raft算法的正常流程,没有过多的去讨论异常场景。
而实际在分布式系统中,我们更多的都是在应对网络不可用、机器故障等异常场景,所以本篇来讨论一下Raft协议的安全性,即在异常场景下是否会导致数据丢失、数据不一致等情况。
解读Raft(二 选举和日志复制)
Leader election
Raft采用心跳机制来触发Leader选举。Leader周期性的发送心跳(如果有正常的RPC的请求情况下可以不发心跳)包保持自己Leader的角色(避免集群中其他节点认为没有Leader而开始选举)。
Follower在收到Leader或者Candidate的RPC请求的情况下一直保持Follower状态。而当一段时间内(election timeout)没有收到请求则认为没有Leader节点而出发选举流程。
解读Raft协议(一 算法基础)
什么是RAFT
分布式系统除了提升整个体统的性能外还有一个重要特征就是提高系统的可靠性。
提供可靠性可以理解为系统中一台或多台的机器故障不会使系统不可用(或者丢失数据)。
保证系统可靠性的关键就是多副本(即数据需要有备份),一旦有多副本,那么久面临多副本之间的一致性问题。
一致性算法正是用于解决分布式环境下多副本之间数据一致性的问题的。
初探Kafka Streams
Kafka在0.10版本推出了Stream API,提供了对存储在Kafka内的数据进行流式处理和分析的能力。
本文将从流式计算出发,之后介绍Kafka Streams的特点,最后探究Kafka Streams的架构。
如何在MQ中实现支持任意延迟的消息?
什么是定时消息和延迟消息?
- 定时消息:Producer 将消息发送到 MQ 服务端,但并不期望这条消息立马投递,而是推迟到在当前时间点之后的某一个时间投递到 Consumer 进行消费,该消息即定时消息。
- 延迟消息:Producer 将消息发送到 MQ 服务端,但并不期望这条消息立马投递,而是延迟一定时间后才投递到 Consumer 进行消费,该消息即延时消息。
定时消息与延迟消息在代码配置上存在一些差异,但是最终达到的效果相同:消息在发送到 MQ 服务端后并不会立马投递,而是根据消息中的属性延迟固定时间后才投递给消费者。
《Kafka官方文档》实现
1. API Design
Producer APIs
Producer API封装了底层两个Producer:
- kafka.producer.SyncProducer
- kafka.producer.async.AsyncProducer