项目中常被问到的问题

Zookeeper

优点

1. 顺序一致性
   同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到ZooKeeper中。
2. 原子性
   所有事务请求的结果在集群中所有机器上的应用情况是一致的，也就是说要么整个集群所有集群都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。
3. 单一视图
   无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。
4. 可靠性
   一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。
5. 实时性
   通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

应用场景：分布式协调/通知

ZooKeeper是一个高可用的分布式数据管理与协调框架。基于对ZAB算法的实现，该框架能够很好地保证分布式环境中数据的一致性。也是基于这样的特性，使得ZooKeeper成为了解决分布式一致性问题的利器。
ZooKeeper中特有Watcher注册与异步通知机制，能够很好的实现分布式环境下不同机器，甚至不同系统之间的通知与协调，从而实现对数据变更的实时处理。使用方法通常是不同的客户端都对ZK上同一个ZNode进行注册，监听ZNode的变化（包括ZNode本身内容及子节点的），如果ZNode发生了变化，那么所有订阅的客户端都能够接收到相应的Watcher通知，并做出相应的处理。
ZK的分布式协调/通知，是一种通用的分布式系统机器间的通信方式。

如何实现数据一致性

ZAB，ZooKeeper原子广播协议作为其数据一致性的核心算法。所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而剩下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提案）并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，Leader就会再次向所有的Follower服务器分发Commit消息，要求对刚才的Proposal进行提交。

ZAB协议包括两种基本的模式，分别是崩溃恢复和消息广播。在整个ZooKeeper集群启动过程中，或是当Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader服务器。当选举产生了新的Leader服务器，同时集群中有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。

崩溃恢复模式包括两个阶段：Leader选举和数据同步。当集群中有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个集群就可以进入消息广播模式了。
详情请戳：https://www.jianshu.com/p/84ad63127cd1

Etcd

参考链接：https://blog.csdn.net/zlfprogram/article/details/79738184

应用场景

1. 服务发现
2. 消息发布与订阅
3. 负载均衡
4. 分布式通知与协调
5. 分布式锁
6. 分布式队列

对比Zookeeper

相较之下，ZooKeeper有如下缺点：

• 复杂。ZooKeeper的部署维护复杂，管理员需要掌握一系列的知识和技能；而Paxos强一致性算法也是素来以复杂难懂而闻名于世；另外，ZooKeeper的使用也比较复杂，需要安装客户端，官方只提供了Java和C两种语言的接口。
• Java编写。这里不是对Java有偏见，而是Java本身就偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望保持强一致、高可用的机器集群尽可能简单，维护起来也不易出错。
• 发展缓慢。Apache基金会项目特有的“Apache Way”在开源界饱受争议，其中一大原因就是由于基金会庞大的结构以及松散的管理导致项目发展缓慢。

而etcd作为一个后起之秀，其优点也很明显：

• 简单。使用Go语言编写部署简单；使用HTTP作为接口使用简单；使用Raft算法保证强一致性让用户易于理解。
• 数据持久化。etcd默认数据一更新就进行持久化。（zk里面还分临时节点、持久节点等等等）
• 安全。etcd支持SSL客户端安全认证。

Raft算法

raft会先选举出leader，leader完全负责replicated log的管理。leader负责接受所有客户端更新请求，然后复制到follower节点，并在“安全”的时候执行这些请求。如果leader故障，followes会重新选举出新的leader。
https://www.cnblogs.com/xybaby/p/10124083.html

如何实现Watch

https://www.jianshu.com/p/aedfb834614d

Kafka

Kafka和Zookeeper的关系（一时没看懂）

Kafka 选举机制

实现高容错：https://blog.csdn.net/qq_37142346/article/details/91349100

其他知识

原理： https://www.jianshu.com/p/0272d5e4ffad
详情请戳：https://www.cnblogs.com/qingyunzong/p/9004509.html

gRPC

优点

1. gRPC可以通过protobuf来定义接口，从而可以有更加严格的接口约束条件。
2. 通过protobuf可以将数据序列化为二进制编码，这会大幅减少需要传输的数据量，从而大幅提高性能。
3. gRPC可以方便地支持流式通信
4. proto文件生成目标代码，简单易用

缺点

1. GRPC尚未提供连接池,需要自行实现
2. 尚未提供“服务发现”、“负载均衡”机制
3. 因为基于HTTP2,绝大部多数HTTP Server、Nginx都尚不支持,即Nginx不能将GRPC请求作为HTTP请求来负载均衡,而是作为普通的TCP请求。(nginx1.9版本已支持)
4. Protobuf二进制可读性差(貌似提供了Text_Fromat功能)

WebRTC

交互连接建立过程

WebRTC中的QOS方法