分布式专题-15、链路追踪
1. Open Tracing2. Skywalking2.1. ELK+Skywalkinghttps://juejin.cn/post/7012877514787799071#comment https://bbs.huaweicloud.com/blogs/273943 https://zhengjianfeng.cn/?p=578 2.2. skywalking VS Sleuth+ZipKinhttps://www.cnblogs.com/cbvlog/p/15770726.html 3. Zipkin官方网址： https://zipkin.io/pages/quickstart.html 参考项目： https://www.cnblogs.com/lori/p/11113665.html 对应 13 https://segmentfault.com/a/1190000020946622?utm_source=tag-newest 本地目录：D:\StudyWorkSpace\SpringCloudLearning\13 原文链接： ...
资源导航
1.JavaGuide: 一份涵盖大部分 Java 程序员所需要掌握的核心知识。2.CS-Notes: 技术面试必备基础知识3.advanced-java: 涵盖高并发、分布式、高可用、微服务4.miaosha:秒杀系统设计与实现5.architect-awesome:后端架构师技术图谱6.toBeTopJavaer:Java工程师成神之路7.technology-talk:Java生态圈常用技术8.JavaFamily：互联网一线大厂面试指南9.JCSprout：处于萌芽的Java核心知识库10.fullstack-tutorial:全栈学习11.JGrowing:Java 成长路线，但学到不仅仅是 Java12.3y:从Java基础、JavaWeb基础到常用的框架再到面试题都有完整的教程，几乎涵盖了Java后端必备的知识点13.interview_internal_reference:2019年最新总结，阿里，腾讯，百度，美团，头条等技术面试题目，以及答案，专家出题人分析汇总。14.effective-java-3rd-chinese:Effective Java中文版（第3版） ...
算法-0、汇总
1. 算法分析研究算法的最终目的就是如何花更少的时间，如何占用更少的内存去完成相同的需求，并且也通过案例演示了不同算法之间时间耗费和空间耗费上的差异，但我们并不能将时间占用和空间占用量化，因此，接下来我们要学习有关算法时间耗费和算法空间耗费的描述和分析。有关算法时间耗费分析，我们称之为算法的时间复杂度分析，有关算法的空间耗费分析，我们称之为算法的空间复杂度分析。 1.1. 时间复杂度分析-大O记法1.1.1. 定义在进行算法分析时，语句总的执行次数T(n)是关于问题规模n的函数，进而分析T(n)随着n的变化情况并确定T(n)的量级。算法的时间复杂度，就是算法的时间量度，记作:T(n)=O(f(n))。它表示随着问题规模n的增大，算法执行时间的增长率和f(n)的增长率相同，称作算法的渐近时间复杂度，简称时间复杂度，其中f(n)是问题规模n的某个函数。在这里，我们需要明确一个事情：执行次数=执行时间用大写O()来体现算法时间复杂度的记法，我们称之为大O记法。一般情况下，随着输入规模n的增大，T(n)增长最慢的算法为最优算法。 1.1.2. 常见的大O阶常数阶：O(1) ...
算法-1、题目解析
1. 数组1.1. 不用中间变量交换两个数1.2. 找到出现奇数次的数https://www.bilibili.com/video/BV1zu411X744?p=8&vd_source=c5b2d0d7bc377c0c35dbc251d95cf204 1.3. 找到 2 个出现奇数次的数1234567891011121314public static int bit1counts(int N) { int count = 0; // 011011010000 // 000000010000 1 // 011011000000 // while(N != 0) { int rightOne = N & ((~N) + 1); count++; N ^= rightOne; // N -= rightOne } return count; } 1.4. 数字中 1 的个数1234 ...
Kafka
1. Kafka 知识总结1.1. 一、讲讲 acks 参数对消息持久化的影响1.1.1. 目录 写在前面 如何保证宕机时数据不丢失？ 多副本之间数据如何同步？ ISR 到底指的是什么东西？ acks 参数的含义？ 最后的思考 1.1.2. 1.写在前面面试大厂时，一旦简历上写了 Kafka，几乎必然会被问到一个问题：说说 acks 参数对消息持久化的影响？ 这个 acks 参数在 kafka 的使用中，是非常核心以及关键的一个参数，决定了很多东西。 所以无论是为了面试还是实际项目使用，大家都值得看一下这篇文章对 Kafka 的 acks 参数的分析，以及背后的原理。 1.1.3. 2.如何保证宕机的时候数据不丢失？（或者 kafka 如何保证高可用、或者 Kafka 如何保证高可用） Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；创建一个 topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 就放一部分数据。 这就是 天然的分布式消息 ...
分布式专题-5、负载均衡-Ribbon
我们添加了@LoadBalanced 注解，即可实现负载均衡功能，这是什么原理呢？ 1. 负载均衡原理SpringCloud 底层其实是利用了一个名为 Ribbon 的组件，来实现负载均衡功能的。 那么我们发出的请求明明是 http://userservice/user/1，怎么变成了 http://localhost:8081 的呢？ 2. 源码跟踪为什么我们只输入了 service 名称就可以访问了呢？之前还要获取 ip 和端口。 显然有人帮我们根据 service 名称，获取到了服务实例的 ip 和端口。它就是 LoadBalancerInterceptor，这个类会对 RestTemplate 的请求进行拦截，然后从 Eureka 中根据服务 id 获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务 id。 我们进行源码跟踪： 2.1. LoadBalancerIntercepor 可以看到这里的 intercept 方法，拦截了用户的 HttpRequest 请求，然后做了几件事： request.getURI()：获取请求 uri，本例中就是 http ...
服务注册与发现-12、Zookeeper
1. 节点类型 2. 选举过程2.1. 概述 2.2. 初始化选举 2.3. 崩溃恢复 3. 写数据流程 如果是请求的 leader，则最后是由 leader 通知 Client 数据写成功了。 4. 数据同步 5. 监听器原理5.1. Watch 机制 5.1.1. 详细逻辑Zookeeper 是一个分布式协调组件，为分布式架构下的多个应用组件提供了顺序访问控制能力。它的数据存储采用了类似于文件系统的树形结构，以节点的方式来管理存储在 Zookeeper 上的数据。 Zookeeper 提供了一个 Watch 机制，可以让客户端感知到 Zookeeper Server 上存储的数据变化，这样一种机制可以让 Zookeeper 实现很多的场景，比如配置中心、注册中心等。 Watch 机制采用了 Push 的方式来实现，也就是说客户端和 Zookeeper Server 会建立一个长连接，一旦监听的指定节点发生了变化，就会通过这个长连接把变化的事件推送给客户端。Watch 的具体流程分为几个部分：首先，是客户端通过指定命令比如 exists、get，对特定路径增加 watch 然后服务 ...
面试专题-4、微服务
1. 微服务架构的优缺点1. 演变而来（从单体应用演变过来）2. 初期评估起手就上微服务 1.1. 面相服务 单一职责避免业务重复开发 1.2. 分工协作单体：影响开发效率,发布和迭代性差；项目启动慢， 每个人对整体的项目都要有所把握； 业务缩减后如果语言不一致开发人员面临流失。拆分：提高开发效率和敏捷性；单个服务启动快， 专人处理专事专注自己的服务； 充分利用项目开发人员（哪怕是不同的语言不同框架，不同存储技术，也可以） 1.3. 并发能力单体：整体集群，易造成系统资源浪费； 之前下单功能要去集群无法准确评测最大并发量， 因为所有的功能都在一起，无法准确预估扩容的服务器。拆分：服务集群，充分利用服务器资源；现在只需要针对下单服务进行压测就可以得到，下单功能具体能承受的并发量最高水位，从而更准确的进行扩容。 1.4. 隔离能力服务之间调用做好隔离、容错、降级，可以避免出现级联错误 1.5. 维护能力单体：随着业务量增加，应用慢慢膨胀，后续可能会变得牵一发而动全身，难以维护。拆分：根据功能垂直拆分，责任更加分明，维护更加精准。容错单体：单点故障，一个功能 OOM 导致整个 ...
面试专题-6、分布式组件
1. 服务注册与发现服务注册与发现-6、Nacos 2. 网关分布式专题-8、网关-GateWay 3. 服务熔断降级限流3.1. 服务雪崩 服务雪崩： 因服务提供者的不可用导致服务调用者的不可用, 并将不可用逐渐放大的过程，就叫服务雪崩效应解决方式：通过熔断机制，当一个服务挂了，被影响的服务能够及时熔断，使用 Fallback 数据保证流程在非关键服务不可用的情况下，仍然可以进行。通过线程池和消息队列机制实现异步化，允许服务快速失败，当一个服务因为过慢而阻塞，被影响服务可以在超时后快速失败，不会影响整个调用链路。 3.2. 服务限流是指在高并发请求下，为了保护系统，可以对访问服务的请求进行数量上的限制，从而防止系统不被大量请求压垮，在秒杀中，限流是非常重要的。 3.3. 服务熔断当服务 A 调用的某个服务 B 不可用时，上游服务 A 为了保证自己不受影响，及时切断与服务 B 的通讯。以防服务雪崩。防止服务雪崩一种措施。 3.4. 服务降级提前预想好另外一种兜底措施，可以进行后期补救。直到服务 B 恢复，再恢复和 B 服务的正常通讯。当被调用服务不可用时的一种兜底措施。 3.4. ...