厚积薄发

Zookeeper 是什么

　Zookeeper 是一个基于 Google Chubby 论文实现的一款解决分布式数据一致性问题的开源实现，方便了依赖 Zookeeper 的应用实现 数据发布 / 订阅、负载均衡、服务注册与发现、分布式协调、事件通知、集群管理、Leader 选举、 分布式锁和队列 等功能

基本概念

集群角色

　一般的，在分布式系统中，构成集群的每一台机器都有自己的角色，最为典型的集群模式就是 Master / Slave 主备模式。在该模式中，我们把能够处理所有写操作的机器称为 Master 节点，并把所有通过异步复制方式获取最新数据、提供读服务的机器称为 Slave 节点

　而 Zookeeper 中，则是引入了 领导者（Leader）、跟随者（Follower）、观察者（Observer） 三种角色 和 领导（Leading）、跟随（Following）、观察（Observing）、寻找（Looking） 等相应的状态。在 Zookeeper 集群中的通过一种 Leader 选举的过程，来选定某个节点作为 Leader 节点，该节点为客户端提供读和写服务。而 Follower 和 Observer 节点，则都能提供读服务，唯一的区别在于，Observer 机器不参与 Leader 选举过程 和 写操作的"过半写成功"策略，Observer 只会被告知已经 commit 的 proposal。因此 Observer 可以在不影响写性能的情况下提升集群的读性能（详见下文 “性能优化 - 优化策略 - Observer 模式” 部分）

什么是人工智能

　人工智能（Artificial Intelligence, AI）亦称机器智能，是指由人工制造出来的系统所表现出来的智能。 — wikipedia.org

　从 深蓝到 AlphaZero，人工智能的智力水平、普适性、学习能力 正在以爆炸式地速度快速发展；
　从 棋类到 医学，人工智能开始在各类应用领域，都在大展身手；
　从 CPU / GPU 到 TPU，人工智能的计算能力正向着无法穷举的极限不断逼近 …

　但是，我们并不浮躁，踏踏实实地点亮 AI 知识树的每个枝叶，才是我们每位富有科学精神的人所应该做的

关于本文

　我们将分为三块对 AI 进行诠释

　首先，将介绍人工智能的主流思想和实用技巧，通过一些耳熟能详的有趣定理，我们可以对人工智能有些直观、初步的认识；随后，言归正传，我们将开始接触 AI 领域的几大理论支柱，由浅入深地学习 统计学、微积分、线性代数、概率论 等知识体系；最后，落地到实践，我们需要紧跟人工智能的技术发展前沿，对重大的突破性项目进行了解、学习，以及运用。如此，对人工智能领域进行横向分层，可以很方便地找到我们学习的突破点

　不过，出于文章编排的考虑，可能部分编码就要放在其他博文中了，如有不便，还望见谅（Python、Prolog、R、Java）。本文持续更新中，若有不妥之处，还请不吝赐教哈 (^o^)/

主流思想

演绎法 & 溯因法 & 归纳法

实用技巧

Occam 剃刀原理

　奥卡姆剃刀（Occam´s Razor），意为简约之法，是由 14 世纪逻辑学家、圣方济各会修士奥卡姆的威廉提出的一个解决问题的法则，即"切勿浪费较多资源，去做'用较少的资源，同样可以做好'的事情"，相同思想见于郑板桥的删繁就简三秋树

基本概念

　Superset 是 Airbnb 开源的一个旨在视觉，直观和交互式的数据探索平台（曾用名 Panoramix、Caravel，现已进入 Apache 孵化器）

基础组件

Flask

　Python 几大著名 Web 框架之一，以其轻量级, 高可扩展性而著名

• Jinja2
  模板引擎

• Werkzeug
  WSGI 工具集

Gunicorn

　Gunicorn 是一个开源的 Python WSGI HTTP 服务器，移植于 Ruby 的 Unicorn 项目的采用 pre-fork 模式的服务器

WSGI

　WSGI，即 Python Web Server Gateway Interface，是专门用于 Python 应用程序或框架与 Web 服务器之间的一种接口，没有官方的实现，因为 WSGI 更像一个协议，只要遵照这些协议，WSGI 应用都可以在 任何服务器上运行，反之亦然

Pre-Fork

　一个进程处理一个请求，基于 select 模型，所以最多一次创建 1024 个进程
　预先创建进程，pre-fork 采用的是预派生子进程方式，用子进程处理不同的请求，每个请求对应一个子进程，进程之间是彼此独立的
　一定程度上加快了进程的响应速度

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

• 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 定理的情况下，能够接受 最终一致性

Welcome

　Welcome to My Blog!

博客介绍

　吾生有涯而学无涯，以有涯而逐无涯（有点断章取义，不过追寻知识的热情是必要的）

大事件纪实