zookeeper vs Eureka

1.介绍

现在提到做服务发现、分布式协调同步可以想到很多工具:zookeeper、eureka、etcd、Consul(直接集成了服务发现的系统,不用自己实现)等等。很多时候选择哪一个,关键是看对CAP的选择。

本篇主要简单讨论下zk和eureka这两个。

2. 关于服务发现

根据 服务发现方案梳理及NetflixEureka简介一文可知,做分布式下的服务发现还是使用eure......

再谈分布式场景下的一致性

1. 介绍

之前也写过一些文章总结分布式场景下的一致性处理:

最终一致性的保证策略

分布式事务的典型处理方式:2PC、TCC、异步确保和最大努力型

事务与分布式事务原理与实现2(笔记)

从分布式数据复制一致性问题到paxos算法的理解(第一部分)

从分布式数据复制一致性问题到paxos算法的理解(第二部分)

今天群里小伙伴,拿着paxos的论文来文一致性问题,正好我也借机复习了下。本文将以比较简单的语言总结下分布式场景下如何处理一致性。本文不介绍具体的实现细节,侧重在实用的解决方案上。

2. 分布式一致性的三种需求场景

分布式对一致性有需求的场景可以归纳为......

zookeeper有哪些坑?

1. 介绍

不得不说ZK的出现是解决分布式一致性问题的一道曙光。但是事务都是发展的,即使是ZK也不是十全十美的。

今天和小伙伴聊了点ZK的问题。一些ZK使用攻略也希望在此跟大家分享下。

2. ZK的缺点

读写性能不佳(这个还需要再验证,我也只是听说):ZK的读写性能测试可以参考ZooKeeper service latencies under various loads & configurations

不适合主数据存储:zk的quorum选举适用在共享集群配置而不是主数据存储。因为其吞吐量低,容忍故障所需要的冗余副本比较多

只容忍(N-1)/2的故障

ZK......

跨语言通信方案比较——thrift、protobuf和avro

1. 介绍

常用的跨语言通信方案:

基于SOAP消息格式的WebService

基于JSON消息格式的RESTful 服务

以上两种方案的弊端:

XML体积太大,解析性能极差

JSON体积相对较小,解析相对较快,但表达能力较弱

现在比较流行的跨语言通信方案:

Google protobuf

Apache Thrift

Apache Avro

2. thrift

是由 Facebook 主导开发的一个跨平台、支持多语言的,通过定义 IDL 文件,自动生成 RPC 客户端与服务端通信代码的工具,以构建在 C++, Java, Pytho......

spark streaming、flink和storm区别浅析

1. 介绍

这三个计算框架常常被拿来比较。从我的角度来看,三者的比较可以分为两类(mini-batches vs. streaming)。spark streaming属于微批量的伪流式准实时计算框架(spark本身属于批处理框架)。而flink和storm则作为典型的实时流处理框架。

2. spark vs flink

两者虽然有很多设计实现思路上比较接近以及互相学习,但是主要区别还是mini-batch和streaming的选择上。根据实际场景在吞吐量和实时性上做权衡。

3. flink vs storm

名称

批处理

数据处理保证

api level

容错机制......