Solr + ZooKeeper

1.什么是Solr?
2.什么是倒排索引？
3.Solr和ElasticSerach有什么相同点和不同点？

1.Solr是基于Lucene的全文搜索平台。它使用倒排索引机制可以实现快速的全文搜索与查找。
2.倒排索引里有field和document的概念。想正常的搜索都是知道商品具体的名字后来进行查找，是先知道document这种，然后去查找对应的field。这是正排索引。（然后举自己项目具体的例子）倒排索引就是我们的输入和整理的索引是field，也就是每个商品的关键词。然后通过这个field索引就可以查询到所有包含该field的document，也就是所有复合条件的商品。
（索引是由分词器来提取的，常用的中文分词器有IK分词器）
3.
相同点：它们都是基于Lucene的全文搜索平台。
不同点：
1.Solr是用ZooKeeper作为分布式管理工具的，而ES它自己有自己的分布式管理工具。
2.Solr比较适合用于传统的，实时性没有那么强场景，比如电商平台。而ElasticSearch比较适合于实时性比较强的场景，如搜索引擎。

1.什么是ZooKeeper？它可以解决什么问题？
2.ZooKeeper结点是什么？它的类型有哪些？有什么作用？
3.ZK的结点有哪些角色？架构是怎样的？
4.ZooKeeper的Watcher机制？有什么应用场景？
5.什么是分布式中的2pc(two phase commit)，两阶段提交？（用来干什么？详细？优缺点？）然后自己引入三阶段提交？
6.paxos算法？哪些角色？为什么要过半请求？和ZAB有什么关系？
7.ZAB协议？
8.ZK中使用ZAB协议的实现过程（fastleaderelection）？
9.ZK作为dubbo的注册中心是怎么工作的？

1.ZooKeeper是一个分布式协调服务框架。它可以进行分布式同步和集群管理。
2.ZK的目录是树形结构。ZK的结点被称为znode。它的类型有短暂结点（ephemeral），持久结点（persistent）。短暂结点就是只在当前会话有效，是动态的。持久结点是会一直存在。
结点一旦被创建后类型无法改变。短暂结点会在会话结束后，自动被删除，而且短暂结点没有子节点。
短暂结点有很多用途，比如短暂结点和Watcher机制结合就可以实现集群结点健康状况的管理。
3.架构：

结点的角色有：follower，leader，observer。
leader是由follower选出来的，它负责事务操作的执行。（如修改和添加）
follower负责client的非事务操作的执行。（一般为查询）
observer被添加进来也执行非事务操作，但是它不参加leader的选举。

当follower收到client的事务操作请求时，由于只有leader才能执行事务操作，所以会把该请求转发给leader执行。
所以由此看来，ZK比较适合非事务操作多的，比如查询。而不太适合事务操作，比如修改和插入多的业务场景。ZK集群横向拓展（也就是增加server的数量），也只能增强非事务操作，如查询的能力。因为leader被选举出来只有一个，所以事务处理能力有限。

4.ZK的watcher机制是用来动态地监测节点的变化和健康情况的。watcher机制指的是对**结点目录及其子目录进行监听，**如果其中有变化，该结点上的watcher会到通知客户端，客户端就能很快的知道结点的变化与健康情况。

5.2pc(two phase commit)两阶段提交（协议）是分布式中用来协调事务执行的一个协议。是中心化的原子提交协议。中心化的意思就是这个协议需要有一个协调者的角色，和n个参与者。原因就是在分布式中，单个结点很容易可以知道自己是否执行事务成功，但是能难知道其它结点的事务执行情况，所以需要一个协调者。

第一阶段是提出请求，第二阶段是进行提交。

第一阶段中给协调者提出请求，然后协调者把请求分别给n个参与者进行发放执行。当所有参与者都执行成功后，返回OK标志。表示这个请求所有参与者都可以成功执行。如果有一个返回NO就说明请求不能正常执行。
第二阶段是当协调者都收到OK时，给所有参与者发送提交请求。然后参与者完成事务的提交（commit）。当协调者收到一个NO时，协调者便给所有参与者发送回滚请求。

这个方法有个特点就是如果其中有一个参与者由于网络或者自己挂掉了，返回结果很慢，则其它的参与者都需要阻塞等待，所以非常浪费时间和资源。

三阶段提交(3pc)解决了这个问题，它比第2pc前面加入了一个获取数据库锁的过程，如果返回OK则说明该参与者可以执行。然后也给参与者加入了超时机制，在一段时间内如果没有相应就自动释放占有的资源。（2pc是只有协调者有超时机制，但3pc是不论协调者还是参与者都有超时机制）

6.paxos算法是用来解决在分布式系统中，快速且正确地达到数据值的一致性（用来解决数据一致性问题的），它具有高容错性。
paxos算法里有三个角色，proposer accepter learner。分别是提建议的，和接收建议的。learner不参与这个过程，只是在最后建议确定好学习建议的信息。
paxos算法有两个阶段：1.生成题案 2.批准题案
1.生成题案
比如有3个提建议的，3个接收建议的。第一个提建议的给第一个接收建议的发送个请求，这个请求称为编号为W1的prepare请求。它有两个含义，一个是这个接收建议的需要保证自己不能批准编号小于W1的提案。另外一个就是一旦这个接收者批准了这个提案，那么如果有别的提案过来，它只能向别的提建议的人发请求，说自己已经接收了W1提案。

当一个提案收到了一半以上接受者的相应，那么这个提案就产生了。而且最后只能产生一个提案。如果提案没有收到一半以上接受者的相应，那么就继续这个过程。

2.批准提案
然后批准上述产生的提案。

之所以要过半请求时因为这个一致性的原则是少数服从多数的。如果一个集合超过一半后，那么这个结果就代表着一致性后的最终结果。是保证了分布式中数据最终一致性。

这个paxos算法是ZK的ZAB协议的基础。

7.ZK核心的是原子广播，它实现了server之间的同步。而这些正是ZK通过ZAB协议实现的。
ZAB协议是ZK中用来保持分布式事务最终一致性的。它包括两部分，第一个是消息广播，另一个是故障恢复。

注意：2pc 3pc 二次提交和三次提交都是client和server之前的同步。而ZK的ZAB协议则是同步内部不同server的，leader和其余follower的同步。

消息广播：
由leader把客户端的请求生成proposal提议，然后广播到剩下的follower，如果收到超过一半的相应，那么这个proposal就生效了，leader就向剩下的follower发送commit请求，把这个proposal提议，也就是事务提交。

故障恢复：
当leader挂掉后，会里面进行故障恢复。zxid最大的那个server将会成为准leader。
zxid是由高32位的epoch选举周期，和低32位的代表事务个数的递增计数器组成的。

过程为：每个follower把自己事务的epoch选举周期发送给准leader，然后leader选出最大的epoch选举周期进行加1（也就是最新的周期），然后把这个最新的epoch选举周期发送给每一个follower，每个follower更新后，给准leader发送ACK标志，并附带历史事务集合。然后准leader根据这些历史事务集合生成初始化事务集合。
准leader把初始化事务集合发送给每一个follower，follower会接收初始化事务集合中每一个事务，然后给准leader反馈，如果准leader收到一半以上的反馈后，就给follower发送commit请求。

8.ZK进行ZAB协议的实现（fastleaderelection）可以快速且正确地选出新leader。它在两个地方使用，一个是初始选leader的时候，一个是当前leader挂掉的时候。过程是：每个server对自己先投出内部投票（内部投票是每个server自初始时自己投给自己的选票，外部选票是除了自己别的server投给自己的票），然后每个server把自己的内部投票发送给其它的server，这个投票对于其它server来说是外部投票。（投票的形式是（myid,zxid））如果外部投票的zxid比自己的zxid大时，说明外部投票的server的epoch选举周期更新，那么自己的内部投票就要修改为该外部投票的server。同理，如果外部投票的zxid比自己的zxid小，那么自己的内部投票的选举周期epoch更新，就保持自己的投票不变。如果相等时，取myid更大的作为投票的选择。如果一个server的投票大于一半时，那么它就为新的leader。

9.ZK具有很好的集群管理的功能，可以作为dubbo的注册中心来协调和管理服务生产者和服务消费者的关系。ZK作为dubbo注册中心时，在dubbo启动时provider和consumer会分别向ZK注册中心进行注册和订阅相关服务。消费者会得到注册服务的列表并缓存在本地。其实现的原理是在ZK中每个服务提供者都是一个短暂结点，只在当前会话有效。并且ZK在该目录设置了Watcher监听机制（结点目录及其子节点目录发生变化就可以捕捉到，并发送提示请求）。当该服务提供者挂掉后，它们之前的心跳连接断开，会话结束，由于是短暂结点，所以也就消失了。同时通过watcher监听机制捕捉到了该结点的异常，同时通知服务消费者该服务提供者挂掉了。通过ZK就可以很好的满足注册中心的服务注册和发现的功能。