分布式搜索引擎（二）

前面已经有一篇分布式搜索引擎了&＃xff0c;主要介绍的是搜索引擎的索引分片和数据同步&＃xff0c;实际上是解决的分布式的问题&＃xff0c;最后我给出了一个图

这个图最后出来的是一个低可用的分布式搜索引擎&＃xff0c;今天我们要解决的问题是把这个低变成高&＃xff0c;今天这篇非常简单&＃xff0c;没有任何高级技术&＃xff0c;看完你就知道了。

1. 为什么会是低可用

我们得知道为什么这个系统会是一个低可用的系统&＃xff1f;

• 没有一个机制让所有节点知道其他节点的状态&＃xff0c;按上面的架构图&＃xff0c;只能是启动节点的时候通过配置文件告知节点其他节点的状态。

• 新增或者移除一个节点&＃xff0c;没有机制让其他节点感知到。

• 同样的&＃xff0c;如果某个节点挂了&＃xff0c;其他节点也没有机制知道

2. 最简单的解决方案

首先&＃xff0c;我们说一个最简单的解决方案

2.1 方案说明

如果我们在上图中加一个服务&＃xff0c;叫Master服务的话&＃xff0c;然后每个节点都和Master进行通讯&＃xff0c;获取其他节点的信息&＃xff0c;那么&＃xff0c;这个问题就解决了&＃xff0c;就像下图&＃xff0c;紫色的部分就是我们说的Master

Master都做什么事呢&＃xff1f;怎么和各个节点交互呢&＃xff1f;作为一个Master&＃xff0c;至少需要做到下面这些个事情&＃xff1a;

• Master必须首先启动&＃xff0c;然后往外广播他的地址和端口信息

• Master必须打开一个端口&＃xff0c;用来和各个节点通讯

• 每新增加一个从节点&＃xff0c;首先接收广播包&＃xff0c;得到Master的地址和端口&＃xff0c;然后连接上&＃xff0c;在Master注册&＃xff0c;注册信息包括本节点的职责和索引状态。

• Master要为每个从节点启动一个协程进行连接的维护&＃xff0c;保持和节点的心跳连接。

• 每新增一个从节点&＃xff0c;Master要负责通知其他节点有新节点上线并告知新节点的职责。

• 如果有节点意外掉线或者正常下线&＃xff0c;Master也要负责通知其他所有节点这个信息。

仔细一看&＃xff0c;其实也没多少事情要做&＃xff0c;这就是一个标准的状态机类型的服务&＃xff0c;整个逻辑代码也很简单&＃xff0c;配合一个安装在每个节点内部的客户端&＃xff0c;就可以完成上面6个交互过程&＃xff0c;这样的话&＃xff0c;每个节点实际上都知道其他任意一个节点的状态&＃xff0c;不管是在数据更新还是在搜索查询的时候都可以从容面对了。

2.1 性价比如何&＃xff1f;

其实这是一个比较完美的解决方案&＃xff0c;分布式方面的逻辑&＃xff0c;需要多个节点配合的逻辑都可以在这个Master节点上来实现&＃xff0c;但这个Master是个单点&＃xff0c;如果他一挂了&＃xff0c;就全挂了。

这算不上是高可用的解决方案&＃xff0c;但是&＃xff0c;我们来分析一下

• 由于Master的逻辑其实比较简单&＃xff0c;无非就是存储一些数据&＃xff0c;然后把数据分发到所有节点上&＃xff0c;再有一个就是定时检查每个节点是否在线&＃xff0c;这样的逻辑写好了&＃xff0c;通过了严格的测试的情况下&＃xff0c;本身出问题的概率还是比较小的。

• 搜索引擎都是部署在内网中&＃xff0c;一般不跨机房的话&＃xff0c;网络问题不会很大

所以&＃xff0c;如果这个搜索引擎不是非常重要的业务场景&＃xff0c;那么这么设计下来就可以了&＃xff0c;没有必要为了一个不是非常非常重要的业务场景而把设计复杂化了&＃xff0c;我实现的第一版就是这样的&＃xff0c;先能用了再说。Master单点就单点吧。

稍微复杂点的解决方案

如果我们使用上一篇的Log大法&＃xff0c;很容易将这个Master变成一个集群&＃xff0c;那么单点挂了就不担心了&＃xff0c;但是还需要解决以下几个问题。

• 当主节点挂了以后&＃xff0c;所有的节点需要把Master节点切换到从节点上。

  • 这个相对好解决&＃xff0c;首先需要主节点把从节点的信息也分发给其他节点&＃xff0c;告诉他们当本节点无响应的时候切换到从节点

  • 其次&＃xff0c;只要其他节点和主节点保持一个心跳链接就互相知道是否还在线了。

• 如果主节点只是暂时性休克了&＃xff0c;所有节点已经把Master节点切换到从节点上了&＃xff0c;结果这时候主节点复活了怎么弄&＃xff1f;

  • 这个也比较好解决&＃xff0c;当Master集群中的某台机器重新连接网络以后也要走注册流程&＃xff0c;看是否已经有人代替了本身职能了。

• Log同步不管怎么样都有延迟&＃xff0c;所以一旦主节点挂了&＃xff0c;有可能有些信息还没有同步到从节点上&＃xff0c;这样会造成不可预知的错误。

  • 这个问题靠Log已经比较难解决了&＃xff0c;只能放弃Log方式&＃xff0c;用强同步模式&＃xff0c;当主节点收到会影响整个集群的请求时&＃xff0c;只有当每个从节点都同步以后才返回请求。

  • Log作用在这里退化成当有新的Master节点要加入Master集群的时候做数据重建使用。

我实现的搜索引擎最后也就用到了这个解决方案的程度&＃xff0c;没有更深入了&＃xff0c;最后整个FalconEngine的集群长成这样子。

还有更好的办法吗&＃xff1f;

有&＃xff0c;当然有。为什么我最后没有用呢&＃xff1f;

首先我们看看在一个搜索引擎一般的使用场景&＃xff1a;

• 搜索引擎主要是为了快速的数据检索。

• 对数据的强一致性要求其实没有那么高&＃xff0c;偶尔一两次搜索结果不太一样对整体的影响不大&＃xff0c;只要你的数据不是错的&＃xff0c;少一点数据一般感觉不到&＃xff0c;当然&＃xff0c;要是长期少了那还是不行的。

所以为了这个去实现一个强一致算法我个人认为没有太大的必要&＃xff0c;毕竟这不是一个交易系统&＃xff0c;不能出一点错。

至于更好的办法&＃xff0c;下一篇会用一整篇的篇幅来说一下分布式系统中如何保持数据的一致性。

总结

这是分布式的第二篇&＃xff0c;分布式的部分还有几篇文章没有出来&＃xff0c;写完以后我目前写的这个搜索引擎&＃xff0c;基本上所有的东西都讲得差不多了&＃xff0c;目前代码还在整理&＃xff0c;最近公司事情太忙了&＃xff0c;暂时还没有全放出来&＃xff0c;我整理完并做完性能测试以后会将在github上放出来&＃xff0c;欢迎关注这个项目&＃xff0c;我写了这么多篇文章&＃xff0c;自己也不想自己做的东西太监掉。

最开始写第一篇文章的时候没有想到会写这么多&＃xff0c;而且这写文章写下来也发现了很多人也比较感兴趣&＃xff0c;所以我还是会一直写下去&＃xff0c;因为搜索推荐广告能写的东西实在是太多了&＃xff0c;也不怕没有东西写。

后面的文章会以一个一个点的模式来写&＃xff0c;偶尔也会瞎扯一下&＃xff0c;欢迎大家留言&＃xff0c;欢迎互相交流。&＃xff1a;&＃xff09;由于要工作&＃xff0c;还要改代码&＃xff0c;还要带两个娃&＃xff0c;还要看书&＃xff0c;所以写文章频度会慢一些&＃xff0c;希望大家不要取消关注哦&＃xff0c;后面还是有很多有意思的东西&＃xff0c;提纲很多我都列好了只是还没动笔写。

最后&＃xff0c;做个小调查&＃xff0c;编程基础部分&＃xff0c;架构部分&＃xff0c;算法部分&＃xff0c;搜索部分&＃xff0c;推荐部分你希望看到哪些呢&＃xff1f;可以在微信后台留言&＃xff08;留言请勿带数字&＃xff0c;那样会变成自动回复&＃xff0c;我就看不到了&＃xff09;&＃xff0c;或者在本篇文章下留言&＃xff0c;就不做问卷调查了&＃xff0c;我公众号上没那么多人。呵呵。。。

欢迎关注我的公众号&＃xff0c;主要聊聊搜索&＃xff0c;推荐&＃xff0c;广告技术&＃xff0c;还有瞎扯。。文章会在这里首先发出来&＃xff1a;&＃xff09;扫描或者搜索微信号XJJ267或者搜索西加加语言就行