研究院网站系统建设方案,wordpress手机访问,网站域名后缀意义,网站推广意义#x1f468;#x1f393;作者简介#xff1a;一位大四、研0学生#xff0c;正在努力准备大四暑假的实习 #x1f30c;上期文章#xff1a;详解SpringCloud微服务技术栈#xff1a;深入ElasticSearch#xff08;3#xff09;——数据同步#xff08;酒店管理项目作者简介一位大四、研0学生正在努力准备大四暑假的实习 上期文章详解SpringCloud微服务技术栈深入ElasticSearch3——数据同步酒店管理项目 订阅专栏微服务技术全家桶 希望文章对你们有所帮助 ElasticSearch本身就是分布式的在这里将要讨论如何用3个docker容器来模拟实现ElasticSearch的集群搭建并且提出集群会出现的脑裂问题并讨论解决方案。 但是这里集群的部署需要我们的Linux虚拟机至少拥有4G的内存空间内存有限就不要做了。 深入ElasticSearch4——ES集群 集群结构介绍搭建集群集群职责及脑裂分布式新增和查询流程故障转移 集群结构介绍
单机的ElasticSearch做数据存储会面临两个问题海量数据存储问题单点故障问题。 针对这两个问题不得不用集群来解决了 海量数据存储问题将索引库从逻辑上拆分为N个分片shard存储到多个节点 单点故障问题将分片数据在不同节点备份replica也就是说其主分片和副本分片不能在同一个节点 搭建集群
没有多台电脑所以这里会利用3个docker容器来模拟3个ES结点。
编写docker-compose文件里面包含了三个容器结点的部署方案大致看懂语句的意思是什么
version: 2.2
services:es01:image: elasticsearch:7.12.1 # 镜像container_name: es01 # 容器名与服务es01名称保持一致environment:- node.namees01 # 结点名称与服务es01名称保持一致- cluster.namees-docker-cluster # 集群名称三个节点的名称都要一样ES就会自动组装成集群- discovery.seed_hostses02,es03 # 集群中另外两个结点docker中可以直接在容器内互联不一定要ip地址- cluster.initial_master_nodeses01,es02,es03 # 初始化主节点这三个节点都可以参与主节点的选举- ES_JAVA_OPTS-Xms512m -Xmx512mvolumes:- data01:/usr/share/elasticsearch/dataports:- 9200:9200networks:- elastices02:image: elasticsearch:7.12.1container_name: es02environment:- node.namees02- cluster.namees-docker-cluster- discovery.seed_hostses01,es03- cluster.initial_master_nodeses01,es02,es03- ES_JAVA_OPTS-Xms512m -Xmx512mvolumes:- data02:/usr/share/elasticsearch/dataports:- 9201:9200networks:- elastices03:image: elasticsearch:7.12.1container_name: es03environment:- node.namees03- cluster.namees-docker-cluster- discovery.seed_hostses01,es02- cluster.initial_master_nodeses01,es02,es03- ES_JAVA_OPTS-Xms512m -Xmx512mvolumes:- data03:/usr/share/elasticsearch/datanetworks:- elasticports:- 9202:9200
volumes:data01:driver: localdata02:driver: localdata03:driver: localnetworks:elastic:driver: bridge这个docker-compose文件直接可以从百度网盘中下载并上传到虚拟机 链接https://pan.baidu.com/s/10By3MR6RYqqMmjBgwDOr7w?pwdmycu 提取码mycu ES运行需要修改一些Linux系统权限修改/etc/sysctl.conf文件
vi /etc/sysctl.conf添加下面内容
vm.max_map_count 262144再执行语句让配置生效
sysctl -p最后执行docker-compose up -d执行即可。
集群的状态监控这里不再推荐kibana了配置比较复杂推荐使用cerebro来监控ES集群的状态压缩包从网盘下载 链接https://pan.baidu.com/s/1kywnAFGyVbbpRN4weRF8Ag?pwdlaz2 提取码laz2 下载完就在本地解压然后进入其中的bin目录双击其中的cerebro.bat即可启动服务。访问9000端口就可以访问了。 在这里就可以创建索引库并且可以直接指定需要分片的数量为3每个分片锁被备份的数量为1。
集群职责及脑裂
ElasticSearch中节点的角色有4中
节点类型配置参数默认值节点职责master eligiblenode.mastertrue作为备选主节点一旦当选则管理和记录集群状态处理分片在哪个节点处理创建和删除索引库的请求datanode.datatrue数据节点存储数据、搜索、聚合、CRUDingestnode.ingesttrue数据存储之前的预处理coordinating上面3个参数都为false则为coordinating节点无路由请求到其它节点合并其它节点处理的结果返回给用户
这种方式把职责分开显然是很好的但是还是可能会出现问题即脑裂问题。 默认情况下每个节点都是master eligible节点因此一旦master节点宕机其它候选节点会选举一个成为主节点。当主节点与其他节点网络故障时可能会出现脑裂问题。如下 node1位主节点原先就是没有故障的但是和备选主节点node2、node3由于网络阻塞问题没办法互联了这时候node2或node3可能就会误认为node1宕机了自动选举出主节点。从而造成了集群中有2个主节点它们共同执行了系统的业务当网络恢复正常的时候访问节点的数据的时候就会发生数据不一致的问题。 为了避免脑裂需要要求选票超过eligible节点数量1/2才能当选为主因此eligible节点数量最好是奇数。对应配置项是discovery.zen.minimum_master_nodes但在ES7.0以后已经成为默认配置因此一般不会出现脑裂问题。 分布式新增和查询流程
当新增文档时应该保存到不同的分片保证数据均衡coordinating node可以确定数据该存储到哪个分片中。 例如配置好的三台ES从9200端口中保存3条文档可以发现9201和9202端口都可以查询到这三条文档同时三条消息分别分片到了三台不同的机器上。这就是协调结点起到的作用。 实际上这个数据分片是利用一个算法来实现的 s h a r d h a s h ( _ r o u t i n g ) % n u m b e r _ o f _ s h a r d s shard hash(\_routing) \% number\_of\_shards shardhash(_routing)%number_of_shards _routing默认是文档的id 算法与分片数量有关因此索引库一旦创建分片数量不能修改 这样的话3台机器运算后的结果只会是0、1、2中的一个从而实现数据的分布式新增。 查询分成2个阶段 scatter phase分散阶段coordinating node会把请求分发到每一个分片 gather phase聚集阶段coordinating node汇总data node的搜索结果并处理为最终结果集返回给用户 总结 1、分布式新增如何确定分片coordinating node根据id做hash运算得到结果对shard数量取余余数就是对应的分片 2、分布式查询分散阶段、聚集阶段
故障转移
故障转移是ES节点一个非常重要的功能集群的master节点会监控集群中的节点状态如果发现有节点宕机会立即将宕机节点的分片数据迁移到其它节点确保数据的安全即为故障转移。
也就是说当数据节点发生故障时主节点会监控到这种状态就会将节点中的所有分片和副本都转移到其它的节点确保数据的安全。 而主节点本身宕机的话EligibleMaster就会选举出新的主节点出来
