殷亚云的博客

Overseer也可以称为cluster leader，也就是集群的主，与shard leader有着很大的区别，shard leader主要是为了保证collection数据的一致性，而Overseer则是为了保证集群操作以及数据的安全性。

本文翻译至:Segment Merging, Deleted Documents and Why Optimize May Be Bad For You,感兴趣的同学可以直接跳至原文阅读，体验会更好，因为下面有些内容会引起你的高度不适（胡编乱造）。

概述

• Transaction log(tlog) 记录原始文档用于recovery，solrcloud中每个节点都自己的tlog。在更新时整个文档会被写入tlog，对于原子（atomic）更新，不光要更新整个文档需要写入tlog，该文档的历史版本也会被写入。总的来说tlog主要是保证文档的一致性，当JVM意外停止的时候，保证索引时最新的。

  • 注意：如果服务没有优雅的终止的话，在下次启动的时候将使用tlog进行重演。所以如果tlog很大的话，实例启动将会变得很慢。

2018.09.05，深夜，最近因为各种事情，心烦意乱，睡不着，索性翻身起来，写一些没有营养的的东西。

个人认为，solr的分布式存在两种：

• 伪分布式，即单shard但存在主从。
• 真正的分布式

因为我认为真正意义上的分布式，不光是分流量，同样需要做到计算的分布式。但是呢，无论是哪一种，但凡涉及到数据的一致性的系统，基本都会考虑只允许主写，solr也是一样，只允许shard leader进行索引的索引的写入，再由主向从写入。

因转到人机对话项目上已经有一段时间了，甚是想念solr，所以特地来回顾一下solrcloud中的一些概念，内容不是很全，而且也没有逻辑，就当是备忘吧。

很多分布式系统都会选用zookeeper作为分布式的协调者，solr同样也不例外，在solr中zookeeper主要起到以下作用：

• 依托于znode，实现集中配置存储
• 依托于session以及watcher机制实现集群状态检测和提醒
• overseer和shard leader选举

如果你的索引量太小，不要折腾这些东西，个人觉得真心没必要，因为没有效果，不如把时间花在其他技术上。