一 序
本文属于极客时间Elasticsearch核心技术与实战学习笔记系列。
二 常见的集群部署方式
2.1节点类型
不同角色的节点
- Master eligible / Data / Ingest / Coordinating / Machine Learning
在开发环境中,一个节点可承担多种角色
在生产环境中
- 根据数据量,写入和查询的吞吐量,选择适合的部署方式
- 建议设置单一角色的节点(dedicated node)
2.2 节点参数配置
一个节点在默认情况下会同时扮演: master eligible ,data node 和 ingest node
2.3单一职责的节点
单一角色:职责分离的好处
Dedicated master eligible nodes:负责集群状态(cluster state)的管理
- 使用低配置的 CPU ,RAM 和磁盘
Dedicated data nodes: 负责数据存储及处理客户端请求
- 使用高配置的 CPU,RAM 和磁盘
Dedicated ingest nodes: 负责数据处理
- 使用高配置的 CPU ; 中等配置的 RAM; 低配置的磁盘
Dedicate Coordinating Only Node (Client Node)
配置:将 Master ,Data ,Ingest 都配置成 Flase
- Medium / High CUP; Medium / High RAM;Low Disk
生产环境中,建议为一些大的集群配置 Coordinating Only Nodes
- 扮演 Load Balancers。 降低 Master 和 Data Nodes 的负载
- 负载搜索结果的 Gather / Reduce
- 有时候无法预知客户端会发生怎样的请求
- 大量占用内存的结合操作,一个深度聚合可能引发 OOM
Dedicate Master Node
从高可用 & 避免脑裂的角色出发
- 一般在生产环境中配置 3 台
- 一个集群只有 1 台活跃的主节点
负载分片管理,索引创建,集群管理等操作
如果和数据节点或者 Coordinate 节点混合部署
- 数据节点相对有比较大的内存占用
- Coordinate 节点有时候可能会有开销很高的查询,导致 OOM
- 这些都有可能影响 Master 节点,导致集群的不稳定
基本部署:增减节点,水平扩展
当磁盘容量无法满足需求时,可以增加数据节点;磁盘读写压力大时,增加数据节点
水平扩展:Coordinating Only Node
当系统中有大量的复杂查询及聚合时候,增加 Coordinating 节点,增加查询的性能
读写分离
ingest node可以通过pipeline对写入数据进行预处理。
在集群里部署 Kibana
讲kibana部署在coordinating节点,实现了kibana集群的高可用。
异地多活的部署
集群处在三个数据中心;数据三写;GTM 分发读请求
这里异地就是指地理位置上不同的地方,多活呢就是指不同地理位置上的系统都能够提供业务服务.
这里老师一带而过,其实是很复杂的。参照下大佬的文章补充下相关知识:
正常情况外,某个地方业务异常的时候,用户访问其他地方正常的业务系统,能够得到正确的业务服务。
根据地理位置上的距离来划分,架构分为:同城异区、跨城异地。
因为距离越近,网络延迟越小,但是抗风险能力越低。所以需要综合考虑。
跨城网络传输延迟问题导致的数据不一致,导致业务不会正常。
如果业务比如金融类对于数据一致性要求高的业务,推荐同城异区(逻辑上我们看做同一个机房)
同城的看做同一个机房(业务上不做特殊处理),跨国的异地的非全球业务可以先不用考虑了。
所以异地多活主要是关注跨城异地的核心点。
1 保证核心业务的异地多活
作者介绍了”注册“,”登录“,”用户信息“的例子,指出核心功能是用户登录恰恰这个是难度最低的。
这里就是要梳理一个观念不是全部业务都要异地多活,成本复杂度都太高。所以理清楚核心业务是前提。
2:保证核心数据最终一致性
异地多活本质上是通过异地的数据冗余,来保证在极端异常的情况下业务也能够正常提供给用户,因此数据同步是异地多活架构设计的核心。收物理条件限制:达不到本地机房一样的速度。
那么这个做项目管理一样的:
- 效果好,就是高速光纤,花钱多。
- 尽量减少数据同步,只同步核心业务相关的数据(降低了质量)
- 保证最终一致性,不保证实时一致性(牺牲了用户体验,中间过程数据还没同步过去)
3:采用多种手段同步数据
有些中间件比如MySQL、Redis自带了主从同步机制,在跨城极端情况下,存储系统本身的同步功能可能难以满足业务需求。
还是以前面的“用户子系统”为例,我们可以采用如下几种方式同步数据:
- mq: 数据通过消息队列同步到其他业务中心。
- 二次读取方式: 第一次读取本地,本地失败后第二次读取对端。
- 存储系统同步方式: 利用存储系统同步机制,同步不常变化的数据。
- 回源读取方式:跟二次读取类似。
- 重新生成数据方式: 针对回源读取的方式,登录失败的情况,重新生成session数据。
技巧4:只保证绝大部分用户的异地多活
不能保证100%的业务可用。
但是为了用户体验,可以挂通知,事后补偿,事后异步通知等。
核心思想:采用多种手段,保证绝大部分用户的核心业务异地多活!
跨城架构设计步骤
第1步:业务分级
按照一定的标准将业务进行分级,挑选出核心的业务,只为核心业务设计异地多活,降低方案整体复杂度和实现成本。
常见的做法有:访问量大的业务、核心业务、产生大量收入的业务。
第2步:数据分类
挑选出核心业务后,需要对核心业务相关的数据进一步分析,目的在于识别所有的数据及数据特征,这些数据特征会影响后面的方案设计。
常见的数据特征分析维度有:
数据量:包括总的数据量和新增、修改、删除的量。
唯一性:唯一性指数据是否要求多个异地机房产生的同类数据必须保证唯一。一个点产生或者设计全局唯一ID生成。
实时性: 网络延迟大小,如果在A机房修改了数据,要求多长时间必须同步到B机房。
可丢失性:指数据是否可以丢失。
可恢复性:可恢复性指数据丢失后,是否可以通过某种手段进行恢复,如果数据可以恢复,至少说明对业务的影响不会那么大,这样可以相应地降低异地多活架构设计的复杂度。
第3步:数据同步
确定数据的特点后,我们可以根据不同的数据设计不同的同步方案。常见的数据同步方案有:
存储系统同步 这是最常用也是最简单的同步方式。例如,使用MySQL的数据主从数据同步、主主数据同步。 这类数据同步的优点是使用简单,缺点:这类同步方案都是通用的,无法针对业务数据特点做定制化的控制。
消息队列同步
重复生成:数据不同步到异地机房,每个机房都可以生成数据,这个方案适合于可以重复生成的数据。
第4步:异常处理
无论数据同步方案如何设计,一旦出现极端异常的情况,总是会有部分数据出现异常的。例如,同步延迟、数据丢失、数据不一致等。异常处理就是假设在出现这些问题时,系统将采取什么措施来应对。异常处理主要有以下几个目的:
问题发生时,避免少量数据异常导致整体业务不可用。 问题恢复后,将异常的数据进行修正。 对用户进行安抚,弥补用户损失。
常见的异常处理措施有这几类:
1. 多通道同步:mq+mysql
多通道同步设计的方案关键点有:
- 一般情况下,采取两通道即可,采取更多通道理论上能够降低风险,但付出的成本也会增加很多。
- 数据库同步通道和消息队列同步通道不能采用相同的网络连接,否则一旦网络故障,两个通道都同时故障;可以一个走公网连接,一个走内网连接。
- 需要数据是可以重复覆盖的,即无论哪个通道先到哪个通道后到,最终结果是一样的。例如,新建账号数据就符合这个标准,而密码数据则不符合这个标准。
2. 同步和访问结合
这里的访问指异地机房通过系统的接口来进行数据访问。例如业务部署在异地两个机房A和B,B机房的业务系统通过接口来访问A机房的系统获取账号信息。
同步和访问结合方案的设计关键点有:
- 接口访问通道和数据库同步通道不能采用相同的网络连接,不能让数据库同步和接口访问都走同一条网络通道,可以采用接口访问走公网连接,数据库同步走内网连接这种方式。
- 数据有路由规则,可以根据数据来推断应该访问哪个机房的接口来读取数据。例如,有3个机房A、B、C,B机房拿到一个不属于B机房的数据后,需要根据路由规则判断是访问A机房接口,还是访问C机房接口。
- 由于有同步通道,优先读取本地数据,本地数据无法读取到再通过接口去访问,这样可以大大降低跨机房的异地接口访问数量,适合于实时性要求非常高的数据。
3. 日志记录
日志记录主要用于用户故障恢复后对数据进行恢复,其主要方式是每个关键操作前后都记录相关一条日志,然后将日志保存在一个独立的地方,当故障恢复后,拿出日志跟数据进行对比,对数据进行修复。
不同的日志保存方式,应对的故障越严重,方案本身的复杂度和成本就会越高,实际选择时需要综合考虑成本和收益情况。
4. 用户补偿
原文地址:http://matianchi.com/2018/09/19/%E5%BC%82%E5%9C%B0%E5%A4%9A%E6%B4%BB%E6%9E%B6%E6%9E%84/