一 序
本文属于极客时间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/