Kafka，Dubbed，ZooKeeper，GIT直白解释

Apache Kafka
Apache Kafka 简介
Apache Kafka 是一个分布式发布 - 订阅消息系统和一个强大的队列，可以处理大量的数据，并使你能够将消息从一个端点传递到另一个端点。 Kafka 适合离线和在线消息消费。 Kafka 消息保留在磁盘上，并在群集内复制以防止数据丢失。 Kafka 构建在 Zoo Keeper 同步服务之上。 它与 Apache Storm 和 Spark 非常好地集成，用于实时流式数据分析。
Kafka 是一个分布式消息队列，具有高性能、持久化、多副本备份、横向扩展能力。生产者往队列里写消息，消费者从队列里取消息进行业务逻辑。一般在架构设计中起到解耦、削峰、异步处理的作用。
Apache Kafka 总结要点
Kafka 是一个基于发布-订阅的分布式消息系统（消息队列）
Kafka 面向大数据，消息保存在主题中，而每个 topic 有分为多个分区
Kaffir 的消息数据保存在磁盘，每个 partition 对应磁盘上的一个文件，消息写入就是简单的文件追加，文件可以在集群内复制备份以防丢失
即使消息被消费，Kafka 也不会立即删除该消息，可以通过配置使得过一段时间后自动删除以释放磁盘空间
Kafka依赖分布式协调服务Zookeeper，适合离线/在线信息的消费，与storm和spark等实时流式数据分析常常结合使用
Apache Kafka基本原理
1、分布式和分区（distributed、partitioned）
我们说 Kafka 是一个分布式消息系统，所谓的分布式，实际上我们已经大致了解。消息保存在 Topic 中，而为了能够实现大数据的存储，一个 topic 划分为多个分区，每个分区对应一个文件，可以分别存储到不同的机器上，以实现分布式的集群存储。另外，每个 partition 可以有一定的副本，备份到多台机器上，以提高可用性。
  总结起来就是：一个 topic 对应的多个 partition 分散存储到集群中的多个 broker 上，存储方式是一个 partition 对应一个文件，每个 broker 负责存储在自己机器上的 partition 中的消息读写。
2、副本（replicated ）
Kafka 还可以配置 partitions 需要备份的个数(replicas),每个 partition 将会被备份到多台机器上,以提高可用性，备份的数量可以通过配置文件指定。
  这种冗余备份的方式在分布式系统中是很常见的，那么既然有副本，就涉及到对同一个文件的多个备份如何进行管理和调度。Kafka 采取的方案是：每个 partition 选举一个 server 作为“leader”，由 leader 负责所有对该分区的读写，其他 server 作为 follower 只需要简单的与 leader 同步，保持跟进即可。如果原来的 leader 失效，会重新选举由其他的 follower 来成为新的 leader。
  至于如何选取 leader，实际上如果我们了解 Zoo Keeper，就会发现其实这正是 Zookeeper 所擅长的，Kafka 使用 ZK 在 Broker 中选出一个 Controller，用于 Partition 分配和 Leader 选举。
  另外，这里我们可以看到，实际上作为 leader 的 server 承担了该分区所有的读写请求，因此其压力是比较大的，从整体考虑，从多少个 partition 就意味着会有多少个leader，Kafka 会将 leader 分散到不同的 broker 上，确保整体的负载均衡。
3、整体数据流程
Kafka 的总体数据流满足下图，该图可以说是概括了整个 Kafka 的基本原理。

（1）数据生产过程（Produce）
  对于生产者要写入的一条记录，可以指定四个参数：分别是 topic、partition、key 和 value，其中 topic 和 value（要写入的数据）是必须要指定的，而 key 和 partition 是可选的。
  对于一条记录，先对其进行序列化，然后按照 Topic 和 Partition，放进对应的发送队列中。如果 Partition 没填，那么情况会是这样的：a、Key 有填。按照 Key 进行哈希，相同 Key 去一个 Partition。b、Key 没填。Round-Robin 来选 Partition。

producer 将会和Topic下所有 partition leader 保持 socket 连接，消息由 producer 直接通过 socket 发送到 broker。其中 partition leader 的位置( host : port )注册在 zookeeper 中，producer 作为 zookeeper client，已经注册了 watch 用来监听 partition leader 的变更事件，因此，可以准确的知道谁是当前的 leader。
  producer 端采用异步发送：将多条消息暂且在客户端 buffer 起来，并将他们批量的发送到 broker，小数据 IO 太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率
（2）数据消费过程（Consume）
对于消费者，不是以单独的形式存在的，每一个消费者属于一个 consumer group，一个 group 包含多个 consumer。特别需要注意的是：订阅 Topic 是以一个消费组来订阅的，发送到 Topic 的消息，只会被订阅此 Topic 的每个 group 中的一个 consumer 消费。
  如果所有的 Consumer 都具有相同的 group，那么就像是一个点对点的消息系统；如果每个 consumer 都具有不同的 group，那么消息会广播给所有的消费者。
  具体说来，这实际上是根据 partition 来分的，一个 Partition，只能被消费组里的一个消费者消费，但是可以同时被多个消费组消费，消费组里的每个消费者是关联到一个 partition 的，因此有这样的说法：对于一个 topic,同一个 group 中不能有多于 partitions 个数的 consumer 同时消费,否则将意味着某些 consumer 将无法得到消息。
  同一个消费组的两个消费者不会同时消费一个 partition。

在 Kafka 中，采用了 pull 方式，即 consumer 在和 broker 建立连接之后，主动去 pull(或者说 fetch )消息，首先 consumer 端可以根据自己的消费能力适时的去 fetch 消息并处理，且可以控制消息消费的进度(offset)。
  partition 中的消息只有一个 consumer 在消费，且不存在消息状态的控制，也没有复杂的消息确认机制，可见 Kafka broker 端是相当轻量级的。当消息被 consumer 接收之后，需要保存 Offset 记录消费到哪，以前保存在 ZK 中，由于 ZK 的写性能不好，以前的解决方法都是 Consumer 每隔一分钟上报一次，在 0.10 版本后，Kafka 把这个 Offset 的保存，从 ZK 中剥离，保存在一个名叫 consumer offsets topic 的 Topic 中，由此可见，consumer 客户端也很轻量级。
消息传送机制
Kafka 支持 3 种消息投递语义,在业务中，常常都是使用 At least once 的模型。
At most once：最多一次，消息可能会丢失，但不会重复。
At least once：最少一次，消息不会丢失，可能会重复。
Exactly once：只且一次，消息不丢失不重复，只且消费一次。
Apache Kafka 工作流程
1、发布-订阅消息的工作流程
以下是 Pub-Sub 消息的逐步工作流程 -
生产者定期向主题发送消息。
Kafka 代理存储为该特定主题配置的分区中的所有消息。 它确保消息在分区之间平等共享。 如果生产者发送两个消息并且有两个分区，Kafka 将在第一分区中存储一个消息，在第二分区中存储第二消息。
消费者订阅特定主题。
一旦消费者订阅主题，Kafka 将向消费者提供主题的当前偏移，并且还将偏移保存在 Zookeeper 系综中。
消费者将定期请求 Kafka (如100 Ms)新消息。
一旦 Kafka 收到来自生产者的消息，它将这些消息转发给消费者。
消费者将收到消息并进行处理。
一旦消息被处理，消费者将向 Kafka 代理发送确认。
一旦 Kafka 收到确认，它将偏移更改为新值，并在 Zookeeper 中更新它。 由于偏移在 Zookeeper 中维护，消费者可以正确地读取下一封邮件，即使在服务器暴力期间。
以上流程将重复，直到消费者停止请求。
消费者可以随时回退/跳到所需的主题偏移量，并阅读所有后续消息。

2、点对点的工作流程
在队列消息传递系统而不是单个消费者中，具有相同组 ID 的一组消费者将订阅主题。 简单来说，订阅具有相同 Group ID 的主题的消费者被认为是单个组，并且消息在它们之间共享。 让我们检查这个系统的实际工作流程。
生产者以固定间隔向某个主题发送消息。
Kafka存储在为该特定主题配置的分区中的所有消息，类似于前面的方案。
单个消费者订阅特定主题，假设 Topic-01 为 Group ID 为 Group-1 。
Kafka 以与发布 - 订阅消息相同的方式与消费者交互，直到新消费者以相同的组 ID 订阅相同主题Topic-01 1 。
一旦新消费者到达，Kafka 将其操作切换到共享模式，并在两个消费者之间共享数据。 此共享将继续，直到用户数达到为该特定主题配置的分区数。
一旦消费者的数量超过分区的数量，新消费者将不会接收任何进一步的消息，直到现有消费者取消订阅任何一个消费者。 出现这种情况是因为 Kafka 中的每个消费者将被分配至少一个分区，并且一旦所有分区被分配给现有消费者，新消费者将必须等待。
此功能也称为使用者组。 同样，Kafka 将以非常简单和高效的方式提供两个系统中最好的。

3、Zoo keeper的作用
Apache Kafka 的一个关键依赖是 Apache Zookeeper，它是一个分布式配置和同步服务。Zookeeper 是 Kafka 代理和消费者之间的协调接口。Kafka 服务器通过 Zookeeper 集群共享信息。Kafka 在 Zookeeper 中存储基本元数据，例如关于主题，代理，消费者偏移(队列读取器)等的信息。
由于所有关键信息存储在 Zookeeper 中，并且它通常在其整体上复制此数据，因此Kafka代理/ Zookeeper 的故障不会影响 Kafka 集群的状态。Kafka 将恢复状态，一旦 Zookeeper 重新启动。 这为Kafka带来了零停机时间。Kafka 代理之间的领导者选举也通过使用 Zookeeper 在领导者失败的情况下完成。

消息系统
消息系统简介
发送者把自己想要发送的信息放入一个容器中（我们称之为Message），然后把它保存至一个系统公用空间的消息队列(Message Queue)中；本地或者是异地的消息接收程序再从该队列中取出发给它的消息进行处理。发送者把自己想要发送的信息放入一个容器中（我们称之为Message），然后把它保存至一个系统公用空间的消息队列(Message Queue)中；本地或者是异地的消息接收程序再从该队列中取出发给它的消息进行处理。
消息系统的分类
点对点消息系统
在点对点的消息系统中，消息保留在队列中，一个或者多个消费者可以消耗队列中的消息，但是消息最多只能被一个消费者消费，一旦有一个消费者将其消费掉，消息就从该队列中消失。这里要注意：多个消费者可以同时工作，但是最终能拿到该消息的只有其中一个。最典型的例子就是订单处理系统，多个订单处理器可以同时工作，但是对于一个特定的订单，只有其中一个订单处理器可以拿到该订单进行处理。
特点：单播；一般是基于polling(轮询)或pull(拉取)接受消息

订阅-发布消息系统
在发布 - 订阅系统中，消息被保留在主题中。 与点对点系统不同，消费者可以订阅一个或多个主题并使用该主题中的所有消息。在发布 - 订阅系统中，消息生产者称为发布者，消息使用者称为订阅者。 一个现实生活的例子是Dish电视，它发布不同的渠道，如运动，电影，音乐等，任何人都可以订阅自己的频道集，并获得他们订阅的频道时可用。
特点：多播，单播；支持push、pull、polling三种方式接受消息；解耦能力比点对点高。

Apache Dubbed
Apache Dubbed简介
Dubbed是一种分布式服务框架。 Serviceable也是一种服务框架，但是Serviceable并不是分布式的服务框架，他需要结合F5实现负载均衡。因此，Dubbed除了可以提供服务之外，还可以实现软负载均衡。它还提供了两个功能Monitor 监控中心和调用中心。这两个是可选的，需要单独配置。简单的说，Dubbed就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有Dubbed这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了Dubbed就是个远程服务调用的分布式框架。
Apache Dubbed架构

Provider：提供者，服务发布方
Consumer：消费者，调用服务方
Container：Dubbed容器，依赖于Spring容器
Registry：注册中心，当Container启动时，把所有可以提供的服务列表上Registry中进行注册
Monitor：监听器
虚线都是异步访问，实线都是同步访问
蓝色虚线：都是在启动的时候完成的功能
红色虚线（实线）：都是运行过程中执行的功能
所有的角色都是可以在单独的服务器上，所以必须遵守特定的协议
作用：告诉Consumer提供了什么服务和服务方在哪里
Apache Dubbed运行原理
（1）启动容器，相当于在启动Dubbed的Provider
（2）启动后回曲注册中心进行注册，注册所有可以提供的服务列表
（3）在Consumer启动后会去Registry中获取服务列表和Provider的地址
（4）当Provider有修改后，注册中心会把消息推送给Con summer，使用了观察者设计模
式
（5）根据获取到的Provider地址，真实调用Provider中的功能，在Con summer方使用了代理设计模式，创建了一个Provider方类的一个代理对象。通过代理对象获取Provider中的真实功能，起到保护Provider真实功能的作用。
（6）Consumer和Provider每隔一分钟会向Monitor发送统计信息，统计信息包括访问次数，频率等。
Apache Zoo Keeper
Apache Zoo Keeper简介
Zoo Keeper 是一个分布式服务框架，是Apache Hardtop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
Zookeeper能够在分布式环境下实现数据的一致。他就是一个工具，利用这一特性，可以实现集群中的分布式协调服务。
·　所谓的分布式协调服务，就是在集群的节点中进行可靠的消息传递，来协调集群的工作。
·　Zookeeper之所以能够实现分布式协调服务，是因为它能够保证分布式数据一致性。
· 所谓的分布式数据一致性，指的就是可以在集群中不同节点访问到的数据保持一致。
·　这样的分布式协调服务包括：数据发布订阅、负载均衡、命名服务、分布式协调/通知、集群管理、分布式锁、分布式队列等功能。
·　Zookeeper基于优良的设计，成为了分布式环境下最重要的分布式协调工具之一。
Apache Zoo Keeper特点
顺序一致性
·　从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到zookeeper中。
·　可以简单理解为：事务按照顺序发生。
原子性
·　所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的，即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，不会出现集群中部分服务器接收了事务，另外一部分服务器拒绝事务的情况。
·　可以简单理解为：要么都变，要么都不变
单一视图性
·　无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的。
·　简单理解为：找谁都一样
可靠性
·　一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变。
·　可以简单理解为：说话算数
实时性
·　zookeeper并不能做到真正的实时性，当zookeeper告诉客户端操作成功时，可以确信数据最终必然是一致，但是zookeeper集群仍需要一定的时间同步数据达成最终一致的效果，所以zookeeper只能保证数据的顺序一致和最终一致，做不到实时的一致，只有伪实时的特性。
·　可以简单理解为：说成了就是成了，但是需要点时间完成同步。

Zoo Keeper原理
不能一台机器
·　zookeeper为了保证可靠性，不能用一台机器，而应该是一个集群，避免单节点故障。
（2）有唯一的leader
·　为了保证zookeeper集群数据能够一致，必须有一个老大，这就是leader，其他的是follower。某一时刻集群里只能有且仅有一个leader。其中，leader可以执行增删改和查询操作，而follower只能进行查询操作。所有的更新操作都会被转交给leader来处理，leader批准的任务，再发送给follower去执行来保证和leader的一致性。
·　由于网络是不稳定的，为了保证执行顺序的一致，所有的任务都会被赋予一个唯一的顺序的编号，一定是按照这个编号来执行任务，保证任务顺序的一致性。
（3）机制
·　leader什么情况下可以认为一个客户端的请求处理成功？
· 只要集群中过半数量的zookeeper通过请求，leader就认为一个请求通过，通知所有同意和不同意的follower更新数据，最终集群中的所有数据更新成功。避免全部同意造成的单节点故障，也避免leader少数同意违反数据的可靠性。
·　因为采用过半同意机制，所以最极端的情况下集群中有过半的机器直到最新提案，而如果过半的机器挂掉，则剩下的机器可能不知道最新提案，则无法保证新选出的leader知道最新提案，所以zookeeper集群采用过半存活机制，否则停止服务。
Zoo Keeper leader选举机制
最开始集群启动时，会选择最先达到过半条件的机器作为leader。
当leader挂掉后，follower开始进入选举阶段，互相发送自己持有的数据的最高编号，进行投票，投票给最高版本的持有者，任何一个follower只要收到超过一半的额票就会自动成为新的leader，由于每个follower都只有一票，所以最多只有一个follower会通过过半投票选出具有最高任务编号（最新提案）的机器成为新的leader。
Zoo Keeper 过半机制总结
（1）过半选举：只有当一台服务器满足超过一半的服务器的时候才能选举为leader。
（2）过半存活：当集群中有一半的服务器宕机，那么整个集群会停止向外提供服务。
（3）过半服务：在Zookeeper集群中，任何一个请求都需要超过半数的节点同意才能执行.

Git
Git简介
GIT，全称是分布式版本控制系统，git通常在编程中会用到，并且git支持分布式部署，可以有效、高速的处理从很小到非常大的项目版本管理。分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者通过克隆（git clone），在本地机器上拷贝一个完整的Git仓库。
简单的说：目录里所有文件都被Git管理起来，每个文件的修改，删除，Git都会跟踪，以便任何时候都可以追踪历史或者在将来某一时刻可以还原修改。
Git原理

工作区间: 即我们创建的工程文件， 在编辑器可直观显示；
缓存区: 只能通过git GUI或git shell 窗口显示，提交代码、解决冲突的中转站；
本地仓库: 只能在git shell 窗口显示，连接本地代码跟远程代码的枢纽，不能联网时本地代码可先提交至该处；
远程仓库: 即保存我们代码的服务器，本文以公共版本控制系统：git hub为例，登录git hub账号后可直观显示；。