Mirson - 多一些分享, 多一些进步

这里用到了OAUTH2的客户端模式和密码模式， 适合微服务场景大用户量的接入，采用Redis缓存， 能够保障较高的性能， JWT附带信息不能过多， 会增加传输资源开销， 加密方式也不能过于复杂， 影响CPU性能， 如果有较多额外信息需要传递， 可以采用TOKEN增强模式， 数据存储在缓存， 不会带来过多的IO开销。在实际项目当中， 要做仔细权衡，能加入缓存地方尽量加入， 保障安全的同时， 也要有较好的性能...

传统登陆方式是在每个服务进行登陆认证， 每个服务保存自己的用户数据， 并独立实现登陆认证逻辑。随着服务的不断扩展， 用户数据很难集中统一，开发成本不断增加， 用户交互也极为不便 。单点登陆是通过统一认证授权服务， 完成所有服务节点的登陆授权工作，需一台认证服务器，统一用户数据库， 完成用户认证授权， 控制资源访问， 支持其他服务或第三方应用接入， 扩展性强， 开发和运维成本降低。

一、安装与配置问题总结服务端的安装版本与客户端需要保持一致。（如果是在同一主机，安装服务端后， 会自带客户端。）etc/hosts下的IP与主机名称的映射， 不要存在多个映射，即IP与主机名称保持唯一性。如果IO瓶颈， 要注意dataDir是否配置多个存储路径，且在不同磁盘下面，配置新的目录时需清空原有数据，多个dataDir配置示例：dataDir /data/tdengine/data1 0 1dataDir /data/tdengine/data2 0 0dataDir /d

1. 基于主从+哨兵的集群模式说明：由一主双从 + Sentinel哨兵集群（三个节点）实现的高可用。为保证可用性，需要三台机器。适用场景：数据量不大、写入量少、扩展性要求不高部署结构拓扑图Redis主从安装部署说明：假定IP:MASTER: 192.168.0.1SLAVE1: 192.168.0.2SLAVE2: 192.168.0.3Redis的安装不做赘述，侧重讲解如何配置，这里主要列出差异性的配置：1） 主节点（master）配置：port

一、背景项目中使用日志的地方非常广泛， 如果要做统一的处理，比如调整格式， 增加信息打印， 要修改很多地方，难以维护，所以需要能够将日志做一个统一的封装， 便于扩展使用；同时想做到动态调整日志级别，在生产环境修改日志级别， 将开销降到最低， 在出现故障时， 又可以重新调整日志级别而不需要重新启动服务， 便于问题的排查定位。二、统一日志的封装如果实现统一日志， 需要自己封装一层实现，但在实际日志打印中，往往会打印出所封装的类信息， 而并非实际调用的类信息， 该如何解决这个问题？ 网上有很资料， 一般都是

1. 什么是Table API & SQLTable API& SQL 是一种关系型API，用户可以像操作MySQL数据库表一样的操作数据，而不需要写Java代码完成flink function，更不需要手工的优化Java代码调优。SQL对一个非程序员操作来讲，学习成本很低，如果一个系统提供SQL支持，将很容易被用户接受。总结来说，关系型API的好处：关系型API是声明式的查询能够被有效的优化查询可以高效的执行“Everybody” knows SQLFlink

1. Flink Table API的整体实现流程主要操作流程如下：// 创建表的执行环境val tableEnv = ... // 创建一张表，用于读取数据tableEnv.connect(...).createTemporaryTable("inputTable")// 注册一张表，用于把计算结果输出tableEnv.connect(...).createTemporaryTable("outputTable")// 通过 Table

1. Flink Connectors 介绍Flink 连接器包含数据源输入与汇聚输出两部分。Flink自身内置了一些基础的连接器，数据源输入包含文件、目录、Socket以及 支持从collections 和 iterators 中读取数据；汇聚输出支持把数据写入文件、标准输出（stdout）、标准错误输出（stderr）和 socket。官方地址Flink还可以支持扩展的连接器，能够与第三方系统进行交互。目前支持以下系统:Apache Kafka (source/sink)Apache Cas

1. 自定义序列化接入方案（Protobuf）在实际应用场景中， 会存在各种复杂传输对象，同时要求较高的传输处理性能， 这就需要采用自定义的序列化方式做相应实现， 这里以Protobuf为例做讲解。功能： kafka对同一Topic的生产与消费，采用Protobuf做序列化与反序列化传输， 验证能否正常解析数据。通过protobuf脚本生成JAVA文件syntax = "proto3";option java_package = "com.itcast.flink.

1. Flink大数据实时处理设计方案整套方案通过Canal + Kafka 连接器 + Protobuf，实现数据的同步接入， 由Flink服务负责对各类业务数据的实时统计处理。2. 热销商品的统计处理功能实现对热销商品的统计， 统计周期为一天， 每3秒刷新一次数据。核心代码 主逻辑实现： /** * 执行Flink任务处理 * @throws Exception */ private void executeFlinkTask() thr

1. 订单支付状态跟踪统计（CEP运用）功能实现对热销商品的统计， 统计周期为一天， 每3秒刷新一次数据。核心代码 主逻辑代码实现： /** * 执行Flink任务处理 * @throws Exception */ private void executeFlinkTask() throws Exception { // 1. 创建运行环境 StreamExecutionEnvironment env = Str

1. ZK选举算法代码实现剖析ZK内部有三种选举算法，分别是LeaderElection,FastLeaderElection和AuthLeaderElection，FastLeaderElection和AuthLeaderElection是类似的选举算法，唯一区别是后者加入了认证信息，但AuthLeaderElection已被ZK弃用， FastLeaderElection比LeaderElection更高效，LeaderElection在3.4.0之后的版本中已经不建议使用，后续的版本只保留Fast

1. 集群数据交互处理流程基于Leader的写操作流程：处理流程：客户端向Leader发起写请求Leader将写请求以Proposal的形式发给所有Follower并等待ACKFollower收到Leader的Proposal后返回ACKLeader得到过半数的ACK（Leader对自己默认有一个ACK）后向所有的Follower和Observer发送CommmitLeader将处理结果返回给客户端源码分析：源码处理流程：基于Follower/O

1. ZK集群架构设计与特性1. ZK集群架构设计：ZK主要分为三种角色：演示查看ZK的角色状态， 命令： bin/zkServer.sh status角色的主要职责与作用？Leader（领导者）：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。Follower（跟随者）：一个Zookeeper集群可能同时存在多个Follow

1. 高可用弹性伸缩实践背景弹性伸缩是云服务架构的重要优势，能够很好的解决高并发场景下的性能瓶颈， 同时节省运营成本。在 IaaS 端，能够弹性伸缩的最实用的产品形态，一般是虚拟机编组。阿里云提供了弹性伸缩的功能。要实现弹性伸缩服务， 还需要负载均衡器作为辅助组件，它可以将流量均匀地，或者按照一定权重或规则，分发到多台虚拟机上。 在峰值场景下，可以实现对应用服务的动态扩容， 在低峰下， 可以缩减节点， 降低运营成本。创建ECS实例实例创建完成之后， 需要绑定弹性IP 如果没有弹性公网

1. 概述RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标，RPC 框架需提供一种透明调用机制，让使用者不必显式的区分本地调用和远程调用。2. 优势RPC的设计让客户端对远程方法的调用是透明的，并不知道这个调用的方法是部署哪里。通过RPC能解耦服务。分布式设计部署灵活解耦服务扩展性强3. RPC框架六种主流RPC框架:Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外

RPC序列化流程序列化的作用在网络传输中，数据必须采用二进制形式， 所以在RPC调用过程中， 需要采用序列化技术，对入参对象和返回值对象进行序列化与反序列化。序列化原理自定义的二进制协议来实现序列化：一个对象是如何进行序列化? 下面以User对象例举讲解:User对象:package com.itcast;public class User { /** * 用户编号 */ private String userNo = "0001".

1. 动态代理调用流程RPC的调用对用户来讲是透明的，内部具体是如何实现呢？核心技术采用的就是动态代理，RPC 会自动给接口生成一个代理类，当我们在项目中注入初始化接口的时候，运行过程中实际绑定的是这个接口生成的代理类。在接口方法被调用的时候，它实际上是被生成代理类拦截到了，这样就可以在生成的代理类里面，加入其他调用处理逻辑。2. 为什么要加入动态代理如果没有动态代理, 服务端大量的接口将不便于管理，需要大量的if判断，如果扩展了新的接口，需要更改调用逻辑， 不利于扩展维护。动态代理可

服务注册发现的作用 在高可用的生产环境中，一般都以集群方式提供服务，集群里面的IP可能随时变化，也可能会随着维护扩充或减少节点，客户端需要能够及时感知服务端的变化，获取集群最新服务节点的连接信息。服务注册发现功能1）服务注册：在服务提供方启动的时候，将对外暴露的接口注册到注册中心内，注册中心将这个服务节点的 IP 和接口等连接信息保存下来。为了检测服务的服务端的有效状态，一般会建立双向心跳机制。2）服务订阅：在服务调用方启动的时候，客户端去注册中心查找并订阅服务提供方的 IP，然后缓存到本地，.

1. 为什么需要时间轮？在Dubbo中，为增强系统的容错能力，会有相应的监听判断处理机制。比如RPC调用的超时机制的实现，消费者判断RPC调用是否超时，如果超时会将超时结果返回给应用层。在Dubbo最开始的实现中，是将所有的返回结果（DefaultFuture）都放入一个集合中，并且通过一个定时任务，每隔一定时间间隔就扫描所有的future，逐个判断是否超时。这样的实现方式虽然比较简单，但是存在一个问题就是会有很多无意义的遍历操作开销。比如一个RPC调用的超时时间是10秒，而设置的超时判定的定时任务是

为什么要采用异步？ 影响到性能和吞吐量的根本原因是什么呢？ 其实就是RPC请求的整体耗时，如果采用同步调用， CPU 大部分的时间都在等待而没有去计算，从而导致 CPU 的利用率不够。这就好比工地里面搬砖，砌墙，捣水泥都由一个人干，其他人旁观， 那效率就十分低下。RPC 请求比较耗时的原因主要是在哪里？在大多数情况下，RPC 本身处理请求的效率是在毫秒级的。RPC 请求的耗时大部分都是业务耗时，比如业务逻辑中有访问数据库执行慢 SQL 的操作，核心是在I/O瓶颈。所以说，在大多数情况下，影响到 R.

为什么要采用路由？真实的环境中一般是以集群的方式提供服务，但对于服务调用方来说，一个接口会有多个服务提供方同时提供服务，所以 RPC 在每次发起请求的时候，都需要从多个服务节点里面选取一个用于处理请求的服务节点。每次上线应用的时候都不止运行一台服务器实例，上线就会涉及到变更，只要变更就可能导致原本正常运行的节点出现异常，尤其是发生重大变动或升级的时候，导致应用服务的不稳定因素就很多。为减少这种风险，一般会选择灰度方式发布应用实例，比如可以先发布部分实例观察是否存在异常，后续再根据使用的情况，选择发布.

一. 优雅启动什么是启动预热启动预热就是让刚启动的服务，不直接承担全部的流量，而是让它随着时间的移动慢慢增加调用次数，最终让流量缓和运行一段时间后达到正常水平。如何实现首先对于调用方来说，我们要知道服务提供方的启动时间，这里有两种获取方法：一种是服务提供方在启动的时候，主动将启动的时间发送给注册中心；另一种就是注册中心来检测， 将服务提供方的请求注册时间作为启动时间。这两者时间会有一些差异， 但并没有关系， 因为整个预热过程的时间是一个粗略值，即使多个机器节点之间存在 1 分钟的误差也不会影

1. 流量复制回放流量复制的作用 在开发新需求的过程中，我们可能会对应用进行重构和拆分，很难做到不改动老逻辑，只要有改动就有可能会出现问题。如果比较严谨的话，在开发完成后，会重新将 TestCase 都跑一遍，并同时补充新功能的 TestCase。如果是小改动的业务需求，这种做法一般不会出现大的问题。但对于大改动的应用，比如很多基础逻辑都被改动过，这时候如果还是通过已有的 Case 去做覆盖验证，很难保证应用上线后不出现故障，因为线上运行的真实环境要复杂很多， TestCase是很难覆盖所有细节场景

1. ElasticSearch集群介绍主节点（或候选主节点）主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作， 主节点负荷相对较轻， 客户端请求可以直接发往任何节点， 由对应节点负责分发和返回处理结果。一个节点启动之后， 采用 Zen Discovery机制去寻找集群中的其他节点， 并与之建立连接， 集群会从候选主节点中选举出一个主节点， 并且一个集群只能选举一个主节点， 在某些情况下， 由于网络通信丢包等问题， 一个集群可能会出现多个主节点， 称为“脑裂现象”， 脑裂会存在丢失

一、过滤查询（分页、模糊、filter）1. 搜索符合匹配条件的信息：创建数据：PUT account/_doc/1{ "account": 10001, "balance": 10000, "name": "test1"} PUT account/_doc/2{ "account": 10002, "balance": 20000, "name": &q

1. 分词查询操作创建索引：PUT /movies/_doc/1{ "name":"The film, filmed in 2021 & tells the story of children"}按分词搜索：GET /movies/_search{ "query": { "match": {"name": "story"} }}通过单个词，可

一、倒排索引原理ES采用的是倒排索引（Inverted Index）, 也称为反向索引。 有反向索引，也会有正向索引。正向索引正排索引是以文档的ID作为关键字，并且记录文档中每个字段的值信息，通过查询id来把整条文档拿出来。但是在查询某一个keyword存在于哪些文档的时候， 需要对所有文档进行扫描匹配。这样检索效率比较低下。 倒排索引倒排索引以字或词作为关键字索引， 倒排索引建立的是分词（Term）和文档（Document）之间的映射关系。 倒排索引表结构， 去除停用词

一、如何优化多字段查询1. 提升字段查询得分：将title字段查询比重提升10倍： GET /movies/_search{ "explain": true, "query":{ "multi_match":{ "query": "good hearts sea", "fields": ["title^10", &quo

1. 基本介绍ElasticSearch特色Elasticsearch不仅仅是Lucene和全文搜索， 还包括：分布式的实时文件存储，每个字段都被索引并可被搜索。分布式的实时分析搜索引擎。可以扩展到上百台服务器，处理PB级结构化或非结构化数据。各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。ElasticSearch使用场景ElasticSearch广泛应用于各行业领域， 比如维基百科， GitHub的代码搜索，电商网站的大数据日志统计分析， BI系统报

为什么要进行限流？RPC 是解决分布式系统架构通讯的一大利器，而分布式系统设计需要面临高并发问题。在这样的情况下，我们提供的每个服务节点都可能由于访问量过大而引起一系列问题，比如业务处理耗时过长、CPU 飚高、频繁 Full GC 以及服务进程假死宕机等问题。在实际生产环境中，我们要保证服务的稳定性和高可用特性，就需要业务提供方能够进行自我保护，从而保证在高访问量、高并发的场景下，系统依然能够稳定，高效运行。服务端的自我保护实现 在 RPC 框架中集成限流功能，可以根据实际情况配置限流阈值；我.

1. RPC调用流程具体调用过程：服务消费者（client客户端）通过本地调用的方式调用服务。客户端存根（client stub）接收到请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息体。客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端。服务端存根（server stub）收到消息后进行解码（反序列化操作）。服务端存根（server stub）根据解码结果调用本地的服务进行相关处理。本地服务执行具体业务逻辑并将处理结果返回给服务端存根