Review：分布式-CFANZ编程社区

缓存分类：

客户端缓存：页面缓存、浏览器缓存、APP客户端缓存；
网络缓存：代理缓存、CDN缓存；
服务器缓存：数据库缓存、平台缓存级缓存。

Ehcache：Ehcache是用来管理缓存的一个工具，其缓存的数据可以是存放在内存里面的，也可以是存放在硬盘上的。其核心是CacheManager，一切Ehcache的应用都是从CacheManager开始的，它是用来管理Cache（缓存）的，一个应用可以有多个CacheManager，而一个CacheManager下又可以有多个Cache。Cache内部保存的是一个个的Element，而一个Element中保存的是一个key和value的配对，相当于Map里面的一个Entry。

Ehcache的过期策略：

FIFO：First In First Out，先进先出。判断被存储的时间，离目前最远的数据优先被淘汰。
LRU：Least Recently Used，最近最少使用。判断最近被使用的时间，目前最远的数据优先被淘汰。
LFU：Least Frequently Used，最不经常使用。在一段时间内，数据被使用次数最少的，优先被淘汰。

EhCache从1.7版本开始，支持五种集群方案，分别是：Terracotta、RMI、JMS、JGroups、EhCache Server。

一般ehcache作为二级缓存，当redis服务器宕机后，可以查询ehcache缓存，这样能够有效的扛住服务器请求压力。

Redis：一款内存高速缓存数据库，基于内存采用的是单进程单线程模型的KV数据库，由C语言编写，redis线程是安全的，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。可以达到100000+的QPS(每秒查询率)。

Redis应用场景：

令牌生成：例：登录时生成token, 以token为键，以用户信息为值，存储在redis中，设置key过期时间。
短信验证码：调用阿里云发送短信，Redis保存手机号（Key）和值（Value）,并设置超时时间。
分布式锁
计数器：统计点击数等应用，由于单线程，可以避免并发问题，保证不会出错，而且100%毫秒级性能。
缓存热点数据
发布订阅：一般不建议使用

Redis的基本数据类型：

String（字符串）
List（列表）
Hash（字典）
Set（集合）
Sorted Set（有序集合）

Redis事务：

开始事务：MULTI
命令入队：
执行事务：EXEC
回滚：discard

Redis主从复制：一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。（实现方式：修改redis.conf文件，从节点配置slaveof）

Redis哨兵机制：用于管理多个 Redis 服务器,该系统执行以下三个任务:

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification)：当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

单个哨兵示例图如下：

Review：分布式_数据

Redis持久化：就是将内存数据保存到硬盘，Redis 持久化存储分为AOF 与 RDB 两种模式。

RDB（对数据要求不严谨的时候使用）：在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
AOF（对数据要求严谨的时候使用，文件比较大，恢复比较慢）：将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程。有3种记录同步方式：always、everysec、no。

Redis集群（3.0之后支持）：Redis Cluster将数据分为16384个槽（slot），每个槽负责存储一部分数据。这些槽被平均分配到集群中的各个节点上。节点之间通过Gossip协议交换集群信息，包括节点的状态、拥有的槽信息等。节点之间还通过PING/PONG消息来检测对方是否存活。采用主从复制机制，每个槽对应的主节点可以有零个或多个从节点。

支持动态扩展，如果增加实例，会自动重新分配槽，会自动启动数据迁移过程，将槽从现有的实例迁移到新的实例上，以实现数据的平均分布。

Review：分布式_Redis_02

缓存雪崩：缓存失效（或者数据未加载到缓存中）所有原本应该访问缓存的请求都去查询数据库了。

解决方式：过期时间分散、缓存预热、二级缓存、加锁或队列、做主备。

缓存穿透：指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

解决方式：空值缓存（设置默认值）、限制查询频率（如验证码）。

缓存击穿：指一个热点key在缓存中过期或被删除，此时有大量并发请求同时访问这个热点key，导致这些请求都穿透缓存，直接访问底层存储系统。

解决方式：互斥锁（Mutex Lock）或分布式锁来保证只有一个线程去加载缓存、在缓存过期时，使用异步方式去更新缓存，避免大量并发请求同时刷新缓存。

Zookeeper：一个分布式的开源协调服务。特点如下：

分布式协调： ZooKeeper提供了一个分布式协调服务，用于管理和协调多个节点之间的操作和通信。
命名服务： ZooKeeper为分布式系统提供了一个简单的命名空间，可以在其中注册和查找服务。这有助于在分布式环境中动态发现和使用服务。
配置管理： ZooKeeper可以用于集中管理配置信息，确保所有节点都使用相同的配置。
分布式锁： ZooKeeper提供了分布式锁的机制，使得多个节点能够协同地访问共享资源，而不会发生竞争条件。
负载均衡
强一致性：能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建/currentMaster节点，最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群选取了。

数据结构：层次化的目录结构，命名符合常规文件系统规范(类似文件系统），

Znode有两种类型：

短暂（ephemeral）（create -e /app1/test1 “test1” 客户端断开连接zk删除ephemeral类型节点）
持久（persistent）（create -s /app1/test2 “test2” 客户端断开连接zk不删除persistent类型节点）

Review：分布式_数据_03

实时性，在一定时间范围内，client能读到最新数据。

Review：分布式_数据_04

CuratorFramework

Review：分布式_分布式_05

分布式锁：

Review：分布式_数据_06

Zookeeper实现分布式锁的一般思路：每个参与者创建一个顺序临时节点、获取节点列表，判断是否获取锁（进程判断自己创建的节点是否是目录中最小的节点。如果是最小的节点，则说明该进程成功获取了锁；否则，进程监听比自己小的那个节点，等待其删除或释放锁。）、进程在完成任务后，删除自己创建的节点，表示释放锁。

对比Redis实现分布式锁：使用SETNX命令尝试获取锁（在Redis中设置一个指定的键（代表锁），并给该键设置一个唯一的值（例如UUID））、设置锁的过期时间

数据库锁、缓存锁、zk锁的比较：

从理解的难易程度角度（从低到高）: 数据库 > 缓存 > Zookeeper
从实现的复杂性角度（从低到高）: Zookeeper >= 缓存 > 数据库
从性能角度（从高到低）:缓存 > Zookeeper >= 数据库
从可靠性角度（从高到低）: Zookeeper > 缓存 > 数据库

Zookeeper选举：基于投票机制，节点通过相互通信进行投票，当某节点获得超过半数的投票时成为Leader，确保高可用性和一致性。

Leader-Follower 模式： ZooKeeper集群中的节点采用Leader-Follower模式，其中一个节点被选举为Leader，其他节点成为Followers。
Zab 协议： ZooKeeper使用Zab（ZooKeeper Atomic Broadcast）协议来实现一致性和选举。在Zab中，Leader负责处理写操作，然后将写操作广播给所有Followers，确保它们有相同的状态。
投票机制： 当Leader失效时，ZooKeeper会通过投票机制选举新的Leader。节点发起投票，需要超过半数节点的支持，包括自己。选举过程确保只有一个节点成为新的Leader。

对比下Redis选举机制，以下是Redis的特点：

主从复制模式： Redis的集群模式中采用主从复制，其中一个节点是Master，其他节点是Slaves。Master负责处理写操作，而Slaves通过复制Master的数据来保持一致性。
Sentinel 哨兵机制： Redis的哨兵机制用于监控和管理Redis集群中的节点。当Master节点失效时，哨兵会协助进行新的Master的选举。
Quorum（多数派）： Redis的Sentinel机制使用Quorum来进行投票，确保选举的唯一性。Quorum是一个节点数量的一半再加一，确保超过半数节点的支持。
自动故障迁移： Redis的哨兵机制不仅仅用于选举新的Master，还可以自动进行故障迁移，将Slave升级为新的Master。

网站跨域的解决方式：

使用jsonp解决网站跨域
使用HttpClient内部转发
使用设置响应头允许跨域
基于Nginx搭建企业级API接口网关
使用Zuul搭建微服务API接口网关

XXL-JOB：是一个分布式任务调度平台，基于调度中心和执行器架构，通过HTTP协议进行通信，实现任务的可视化管理、分布式调度和高可用性，支持任务分片、分布式锁等机制。

Apollo（阿波罗）：是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

Review：分布式_数据_07

ACID酸碱平衡：

原子性（Atomicity）:指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
一致性（Consistency）:事务前后数据的完整性必须保持一致。
隔离性（Isolation）：事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
持久性（Durability）:持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

CAP帽子原理：

一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本。
可用性（Availability）：好的响应性能。完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应。
分区容忍性（Partition tolerance）：尽管网络上有部分消息丢失，但系统仍然可继续工作。

CAP原理证明，任何分布式系统只可同时满足以上两点，无法三者兼顾。

Base碱：它满足 CAP 原理，通过牺牲强一致性获得可用性，一般应用于服务化系统的应用层或者大数据处理系统中，通过达到最终一致性来尽量满足业务的绝大多数需求。

基本可用（Basically Available） :指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。(比如：搜索引擎0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务等。
软状态（Soft State） ：指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性，即允许系统在不同节点间副本同步的时候存在时延。
最终一致（Eventually Consistent ） ：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性，最终一致性是弱一致性的一种特殊情况。

刚性事务：满足ACID理论

柔性事务：满足BASE理论（基本可用，最终一致），分为：

两阶段型
补偿型
异步确保型
最大努力通知型

分布式一致性相关协议：

XA接口：XA之所以需要引入事务管理器是因为两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如数据库或JMS队列）。
JTA规范：定义了对XA事务的支持，实际上，JTA是基于XA架构上建模的。**独立的JTA实现（**如JOTM，Atomikos）。
两段提交协议：第一阶段是 「表决阶段」 ，所有参与者都将本事务能否成功的信息反馈发给协调者；第二阶段是 「执行阶段」 ，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚。缺点：如果协调者宕机，参与者没有协调者指挥，则会一直阻塞。

Review：分布式_Redis_08

三段提交协议：是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题。「询问阶段」：协调者询问参与者是否可以完成指令，参与者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止。「准备阶段」：如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致成功。「提交阶段」：如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致。

Review：分布式_缓存_09

2PC与3PC提交区别:

增加了一个「询问阶段」，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生。在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，这也是根据概率统计上超时后默认成功的正确性最大。
三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。

TX-LCN事务协调框架：由两大模块组成, TxClient、TxManager。TxClient作为模块的依赖框架，提供TX-LCN的标准支持，TxManager作为分布式事务的控制方。事务发起方或者参与反都由TxClient端来控制。

Review：分布式_数据_10

LCN事务模式、TCC事务模式、TXC事务模式****：****

**LCN（链式事务）事务模式：**通过链式的服务调用，在调用链上传递事务上下文信息，并通过可靠消息机制实现最终一致性。
**TCC（Try-Confirm-Cancel）事务模式：**通过业务接口的定义和补偿逻辑的实现，保证了在分布式环境下的事务一致性。
**TXC（Transaction eXtending Components）事务模式：**将分布式事务划分为多个局部事务，通过消息通信确保各个局部事务的一致性。

Elasticsearch：一个基于Lucene构建的开源、分布式、RESTful 接口全文搜索引擎。它的优势如下：

**横向可扩展性：**只需要增加台服务器，做一点儿配置，启动一下Elasticsearch就可以并入集群。
**分片机制提供更好的分布性：**同一个索引分成多个分片(sharding), 这点类似于HDFS的块机制;分而治之的方式可提升处理效率。
**高可用：**提供复制( replica) 机制，一个分片可以设置多个复制，使得某台服务器在宕机的情况下，集群仍旧可以照常运行，并会把服务器宕机丢失的数据信息复制恢复到其他可用节点上。

Elasticsearch存储结构：是面向文档型数据库，一条数据在这里就是一个文档，用JSON作为文档序列化的格式。

关系数据库 ：数据库 ⇒ 表 ⇒ 行 ⇒ 列
Elasticsearch ：索引⇒ 类型⇒ 文档⇒ 字段

Elasticsearch正排和倒排索引：

正排索引：文档到字段值的映射，按照文档的顺序存储

正排索引：
Document 1:
  Title: Elasticsearch Basics
  Content: Elasticsearch is a distributed search and analytics engine.

Document 2:
  Title: Getting Started with Elasticsearch
  Content: Learn the basics of Elasticsearch for search and analytics.

......

倒排索引：字段值到文档的映射，用于快速检索包含特定字段值的文档

倒排索引：
Elasticsearch:
  Document IDs: 1, 2, 3

Basics:
  Document IDs: 1, 2

Getting:
  Document ID: 2

Started:
  Document ID: 2

Advanced:
  Document ID: 3

Queries:
  Document ID: 3

..

Elasticsearch查询方式：一种是简易版的查询，另外一种是使用JSON完整的请求体，叫做结构化查询（DSL）。DSL查询是POST过去一个JSON，由于POST的请求是JSON格式的，所以存在很多灵活性，所以大都使用这种方式。

GET /user_dao/user_table/_search
{
  "from": 0,
  "size": 3, 
  "query": {
    "match": {
        "name": "grand"
      }
  }
}

IK 分词器：是 Elasticsearch 中一个常用的中文分词器，主要用于处理中文文本的分词需求。IK Analyzer 是一个开源的分词器项目，提供了细粒度的中文分词能力。es-ik分词插件版本一定要和es安装的版本对应。安装位置举例：/usr/local/elasticsearch-6.4.3/plugins/ik

ES的数据类型：支持基础类型和复杂类型。

基础类型：

字符串：string，string类型包含 text 和 keyword。
text：该类型被用来索引长文本，在创建索引前会将这些文本进行分词，转化为词的组合，建立索引；允许es来检索这些词，text类型不能用来排序和聚合。
keyword：该类型不需要进行分词，可以被用来检索过滤、排序和聚合，keyword类型自读那只能用本身来进行检索（不可用text分词后的模糊检索）。注意: keyword类型不能分词，Text类型可以分词查询。
数指型：long、integer、short、byte、double、float
日期型：date
布尔型：boolean
二进制型：binary
数组类型:Array datatype

复杂类型：

地理位置类型（Geo datatypes）：地理坐标类型、地理形状类型
特定类型（Specialised datatypes）：Pv4 类型、Completion 类型、Token count 类型

ES集群：是由多个节点协同工作的分布式系统，其中主节点管理集群状态，数据节点存储和执行搜索操作，分片和副本确保数据分布和冗余，实现高可用、横向扩展的搜索和分析服务。

**Cluster：**代表一个集群，集群中有多个节点，其中有一个为主节点，这个主节点是可以通过选举产生的；
Shards： 代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上，构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。默认创建索引是分配5个分片进行存储，主分片对应的备分片不能存放在同一台服务器上。
Replicas：代表索引副本，es可以设置多个索引的副本，副本的作用一是提高系统的容错性，当某个节点某个分片损坏或丢失时可以从副本中恢复，二是提高es的查询效率，es会自动对搜索请求进行负载均衡。
**Recovery：**代表数据恢复或叫数据重新分布，es在有节点加入或退出时会根据机器的负载对索引分片进行重新分配，挂掉的节点重新启动时也会进行数据恢复。

ES集群总分片数计算：主分片为3、备分片为2 ，每个主分片对应2个备分片，3个主分片放在3个节点（服务器）的情况下。总分片数 = 3（仓库数）*1（主分片）+ 2（备份分片）*3 = 9个

Review：分布式_Redis_11

ES路由算法：当客户端发起创建document的时候，es需要确定这个document放在该index哪个shard上。这个过程就是数据路由。shard = hash(routing) % number_of_primary_shards

Review：分布式_Redis_12

备注：ES索引主分片数量不能改，因为如果number_of_primary_shards在查询的时候取余发生的变化，无法获取到该数据。

ELK日志采集流程：

每台服务器集群节点安装Logstash日志收集系统插件。
每台服务器节点将日志输入到Logstash中。
Logstash将该日志格式化为json格式，根据每天创建不同的索引，输出到ElasticSearch中。
浏览器使用安装Kibana查询日志信息。

Logstash举例：格式化使用json的格式在控制台输出myes.log

input {
    # 从文件读取日志信息 输送到控制台
    file {
        path => "/usr/local/elasticsearch-6.4.3/logs/myes.log"
        codec => "json" ## 以JSON格式读取日志
        type => "elasticsearch"
        start_position => "beginning"
    }
	
}

# filter {
#
# }

output {
    # 标准输出 
    # stdout {}
    # 输出进行格式化，采用Ruby库来解析日志   
     stdout { codec => rubydebug }
}

分布式全局id生成策略：