elasticsearch - 集群,原理

本文详细介绍了Elasticsearch的工作原理,包括集群架构、分片机制、文档ID管理、并发控制及版本管理,还探讨了批量操作和性能优化策略。

 

一般集群中会自动选出一个节点来作为master节点,它负责维护集群中的元数据信息,索引的创建和删除,节点的增加和移除

一个index可能会被分成多个shard,primary shard的数量一旦确定就不会修改了,但是replica shard的数量会。primary shard不会和自己的replica shard存放在同一个机器上,但是可以和别的replica shard放在一起

可以在创建index的时候设置分片数量。默认是5主5从

分配了3主3从

 

 

集群可以动态扩容,单数primary shard 的数量是不会改变的,只能增加 replica  shard,这样就提升了性能。

扩容的时候还有考虑到系统的吞吐量和容错性

 

容错机制;

如果master宕机之后,系统会重新选取一个node来作为master,或者是普通的primary shard宕机了,这个时期集群的状态都是red。之后会选取一个replica shard来作为 primary shard,此时集群的状态为 yellow 。之后重启机器,会同步之间缺失的数据,整个系统的状态变为 green

 

 

手动创建document id:

一般情况下,,如果es中的数据是从其他的地方过来的,本身已经有id了,那么我们可以使用数据本身的id。

自动创建document id:

如果是只用es来作为存储的话,也可以使用es来自动创建id

自动生成的id,长度为20个字符,URL安全,base64编码,GUID,分布式系统并行生成时不可能会发生冲突

 

es的更新文档和创建类似,如果id存在就全量替换,不存在就创建新的document,在替换的时候会将老的document添加delete的标记,当创建的document越来越多的时候,es会在恰当的时机删除这些document。

es的删除也不是立刻删除,会先标记delete,然后在后台适当的时机删除。

 

es是基于version字段使用乐观锁来解决并发中存在的问题。

例如:有一个id为7的数据,现在对他进行更新

带有version字段的更新

如果在有其他的线程更新的时候,会出现错误

 

 

以上是使用es自带的_version字段进行更新,那么也可以不用这个es自己内部维护的版本号,而使用自己维护的一个版本号。

区别:

唯一的区别在于,_version,只有当你提供的version与es中的_version一模一样的时候,才可以进行修改,只要不一样,就报错;当version_type=external的时候,只有当你提供的version比es中的_version大的时候,才能完成修改

原来的额version是2,传入的是3的时候也更新成功了 。

如果使用内部的version的时候,传入的version的值必须和数据一致

 

partial update;

局部更新发生在shard的内部,相比于全量更新更迅速。高并发的时候减少了再次查询修改的过程,提高了性能

partial update的时候也是设置retry的次数。即如果version的字段发生了变化重新获取version再进行更新的次数。

 

 

 

批量查询:

查询不同的index下的数据

查询相同的index下不同type;

查询同一个index,同一个type下:

 

 

 

bulk语法;批量操作

每一个操作要两个json串,语法如下:

{"action": {"metadata"}}
{"data"}

举例,比如你现在要创建一个文档,放bulk里面,看起来会是这样子的:

{"index": {"_index": "test_index", "_type", "test_type", "_id": "1"}}
{"test_field1": "test1", "test_field2": "test2"}

有哪些类型的操作可以执行呢?
(1)delete:删除一个文档,只要1个json串就可以了
(2)create:PUT /index/type/id/_create,强制创建
(3)index:普通的put操作,可以是创建文档,也可以是全量替换文档
(4)update:执行的partial update操作

bulk api对json的语法,有严格的要求,每个json串不能换行,只能放一行,同时一个json串和一个json串之间,必须有一个换行

bulk操作中,任意一个操作失败,是不会影响其他的操作的,但是在返回结果里,会告诉你异常日志

bulk size最佳大小:

bulk request会加载到内存里,如果太大的话,性能反而会下降,因此需要反复尝试一个最佳的bulk size。一般从1000~5000条数据开始,尝试逐渐增加。另外,如果看大小的话,最好是在5~15MB之间。

 

 

 

 

 

 

 

 

天猫商城是一个基于SSM框架的综合性B2C电商平台,需求设计主要参考天猫商城的购物流程:用户从注册开始,到完成登录,浏览商品,加入购物车,进行下单,确认收货,评价等一系列操作。 作为模拟天猫商城系统的核心组成部分之一,采用SSM框架的天猫数据管理后台包含商品管理,订单管理,类别管理,用户管理和交易额统计等模块,实现了对整个商城的一站式管理和维护。本课程是一门专业的Java微服架构开发实战课程,主要讲解了当下流行的SpringBoot框架、SpringCloud架构以及与第三方技术整合开发实战内容。通过本课程的学习,能够理解并掌握SpringBoot的基础知识,同时能够掌握SpringBoot与常用的第三方技术整合实现实际开发中的业务需求,包括实现Web开发、数据访问、缓存管理、安全管理、消息服务、任务管理等;了解并掌握SpringCloud微服务架构的基础知识及相关组件的应用,掌握微服务架构在企业级开发的实践,建立起微服架构思想。项目技术栈:采用SpringBoot简化商城系统的初始搭建以及开发过程采用SpringMVC+Spring+IBatis完成项目的整合采用Mysql作为数据库存储,Druid配置数据库连接池采用SpringCloud+Netflix 微服务技术栈的实战开发使用Redis完成缓存的数据存储,搭建Redis搭建主从、哨兵、集群应用,保证Redis的高可用使用ElasticSearch全文检索系统进行商品数据搜索,使用ElasticSearch搭建搜索服务的高可用使用Ngnix实现页面动静分离与负载均衡的配置采用FastDFS文件储存系统文件存储,完成广告图片、商品图片的上传和存储系统使用采用CAS+shiro单点登录系统实现用户认证使用ECharts根据后台查询数据生成图表使用POI实现了商城盈利状况的Excel表格导出。商品的详情页使用Thymeleaf完成页面静态化,减少页面数据展示延迟项目中使用SpringBoot下的Aop + 自定义注解完成用户行为记录,日志采集后台管理系统使用Shiro实现登录验证和权限管理(超级管理员、管理员、产品编辑员)项目整合微信完成订单的支付使用Redission完成分布式锁,生成订单的编号使用SpringCloud Alibaba Seat完成下订单模块的分布式事务(新增订单表,库存减少,库存超卖设计)使用RabbitMQ 做消息队列,完成订单未支付自动取消和模块直接的解耦合使用Quartz任务调度,完成缓存的定时刷新,保证缓存的一致性使用本地消息表机制完成消息然队列RabbitMQ消息可靠性传输订单支付模块使用微信扫码支付,并设置订单超时自动取消通过Jquery实现前端校验,通过基于Hibernate的Valida注解实现后端的校验功能使用Base64编码对Json数据传输进行编码和解码项目使用RESTful设计风格实现资源的访问,实现前后端分离项目使用聚合数据第三方短信平台完成用户的登陆功能项目使用SpringBoot整合JavaMail完成邮件的发送项目使用SpringBoot整合Swagger2生成接口文档使用PostMan完成接口的测试项目的测试:SpringTest、dbunit、EasyMock使用Docker 进行应用的自动化打包和发布、自动化测试和持续集成、部署和调整其他应用使用 PowerDesigner,完成数据库的建模项目使用禅道进行BUG管理环境采用Maven实施多模块项目构建,采用Git进行项目版本管理 架构解读:  项目部分截图:              讲义部分截图:          
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值