宇宙湾

大数据生态圈中，保证一致性的方式举不胜举

• Hadoop 用 ZooKeeper（Zab，即支持事务顺序的 Paxos）
• Elasticsearch 用 Hash 路由算法（而非一致性 Hash）
• Cassandra 用 Gossip 闲话算法
• Redis 用 Raft 选举算法

他们各有什么区别，为什么会如此选型？

Paxos 选举算法

　Paxos 是最先解决拜占庭将军问题的算法，利用过半选举的机制，保证了集群数据副本的一致性（微服务中服务注册与发现的场景，其实已经不再适用了）

Raft 选举算法

　Redis 使用 Raft 实现了自己的分布式一致性。Raft 本身和 Paxos 并没有场景上的区别。更多的是，协议上的简化、Term 概念的强化、Log 只会从 Leader 到 Follower 单向同步，使得实现起来会很方便

Zab 原子广播协议

　Hadoop 偏向于离线的海量数据处理，利用 ZooKeeper 来保证数据副本的一致性，是最为合适的

Hash 路由算法

　Elasticsearch 集群接收到为文档创建索引的请求时，需要选择在哪一个 shard（完整且独立的 Lucene 索引实例）上对文档进行索引。Elasticsearch 采用的是 djb2 哈希算法（俗称 times33），对要索引文档默认或指定的 key 进行哈希 hash(key)，然后再对 Elasticsearch 集群中 shard 的数量 n 进行取模，即 $hash(key) \, mod \, n$

一致性 Hash

　用于对数据存储进行负载均衡的算法。最新的进展，是在去年 Google 发表的一篇 有界负载的一致性 Hash 算法的论文。该算法保证了负载均衡一致性和稳定性的同时，在均匀性方面做出了实质性地改进。同时，Consistent Hashing with Bounded Loads 算法 也在 HaProxy 开源项目中得以应用，有效减少了其 8 倍的缓存带宽

Gossip 闲话算法

　Gossip 主要被 Cassandra 用于实现其分布式一致性。因为 Cassandra 框架，更看重 去中心化 和 容错 的特性，在不违背 CAP 定理的情况下，能够接受 最终一致性

Serverless 是什么？

Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. It can be a form of utility computing. — wikipedia.org

Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. — 《Serverless Architectures》

无服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如 AWS Lambda 服务），客户端逻辑和服务托管远程过程调用的组合。 — 亚马逊 AWS 官方博客

Serverless（无服务器架构）是指服务端逻辑由开发者实现，运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。 — 《无服务架构实践手册》

If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless. — Adrian Cockroft

优缺点

优势

低成本

运维成本

　服务器、中间件、数据库等均托管于 BaaS/FaaS 平台，用户无需再参与基础设施及软件的维护，省去了集群的运维成本

开发成本

　对比 IaaS 或者 PaaS 平台的服务器或者操作系统，Serverless 的架构中，用户操作的是服务化的组件，比如存储服务、授权服务等，可以缩短开发周期，节约时间成本

按需计费

　Serverless/FaaS 区别于 IaaS/PaaS 预先分配计算资源的计费方式，其计费方式通常是按请求次数及运行时间。如此一来，不仅可以最大程度地利用资源，还能实现真正的按需计费，以降低用户的使用成本

高扩展

　自动进行横向扩展（毫秒级部署，秒级生命周期）

高资源利用率

　提供细粒度的计算能力，最大限度满足实时需求，使得资源利用率大幅度提升

NoOps

　运维的发展经历了，人肉运维、自动化运维、DevOps、AiOps 等。而 Serverless 模式下，用户只需要关心业务编码，真正实现了零运维成本

《PySpark 大数据分析实战》兼备全面的理论知识，更具众多的实战案例，着实是一本不可多得的佳作。作者结合多年实战经验，从基础概念出发，循序渐进至高级应用，完整展示了 PySpark 的知识体系。无论你是大数据的初学者，还是经验丰富的领域专家，此书都能为你提供实用的参考和专业的指导。

关于本文

　虽然接触 Java 已经十余年之久，可惜学习之初的笔记文档没能很好地保存下来。本文是近几年工作学习中遇到的一些零散的知识点，包括了 基础概念、实用的编程技巧、代码可读性、设计模式、性能优化（工具 & 编码）、测试相关、JVM 相关、常用的工具和常见问题。本着好记性不如烂笔头的初衷，在不断地踩坑和爬坑的过程中，慢慢地记录成文。期待着本文能起到抛砖引玉的作用，以看到大家的真知灼见。

基础知识

注解

GuardedBy

　@GuardedBy 注解可以作用于某一个属性或者方法，约定在访问这些被注解标记的资源时，能被同步代码块保护着。简单的使用案例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@GuardedBy("obj")
private ConcurrentMap<String, String> map = new ConcurrentHashMap<>();
private final Object obj = new Object();

public void put(String k, String v) {
    synchronized (obj) {
        map.put(k, v);
    }
}

/**
 * If you use `error prone` tool to check this, this annotation should be `@SuppressWarnings("GuardedBy")`
 * {@see https://errorprone.info/bugpattern/GuardedBy}
 * {@see https://github.com/apache/druid/pull/6868#discussion_r249639199}
 */
@SuppressWarnings("FieldAccessNotGuarded")
public void remove(String k) {
    map.remove(k);
}

@Override
public String toString() {
    synchronized (obj) {
        return "GuardedByExample{" +
                "map=" + map +
                '}';
    }
}

Tips: Code Example from Apache Druid；另外，error-prone 工具支持对多种版本的 @GuardedBy 进行检查

关于本文

　本文主要是为了，记录给 Apache Druid / Apache Eagle / Apache Flink / Apache HBase / Apache Kafka / Apache Superset / Apache ZooKeeper & Apache Curator / TensorFlow / Alibaba DataX 等开源项目贡献代码，尽自己一点绵薄之力的过程

　文章最后，总结了一些经验之谈，期冀能帮助到同样热爱开源、也想成为 PMC 的小伙伴们