转载自：https://blog.csdn.net/csdnnews/article/details/90093190
https://www.cnblogs.com/IT-Evan/p/CloudNative.html
[toc]
自 2013 年容器（虚拟）技术（Docker）成熟后，后端的架构方式进入快速迭代的阶段，出现了很多新兴概念：
- 微服务
- k8s
- Serverless
- IaaS：基础设施服务，Infrastructure-as-a-service
- PaaS：平台服务，Platform-as-a-service
- SaaS：软件服务，Software-as-a-service
- Cloud Native： 云原生
- Service Mesh
后端架构的变迁和云计算的发展密切相关，架构其实在不断地适应云计算，特别是云原生，被誉为未来架构，在 2019 年，云原生落地方案 Service Mesh 在国内外全面开花，我认为，未来已来。
[toc]
二叉查找树（BST）又叫二叉排序树，二叉搜索树。二叉排序树或者是一棵空树，或者是具有下列性质的二叉树：
- 若左子树不空，则左子树上所有结点的值均小于它的根节点的值；
- 若右子树不空，则右子树上所有结点的值均大于它的根结点的值；
- 左、右子树也分别为二叉排序树；
- 没有键值相等的节点。
平均情况下查找时间复杂度为O(logn)；最坏情况则是退化成一个链表，查找时间复杂度为O(n)。
二叉树结构其查找的时间复杂度与树高相关。那么降低树高自然对查找效率是有所帮助的。另外还有一个比较实际的问题：对大数据存储的查询，平衡二叉树由于树深度过大而造成磁盘IO读写过于频繁，进而导致效率低下。那么如何减少树的深度，一个基本的想法就是：
[toc]
针对不同场景把监控系统分为三类，分别是：
通常我们在系统和业务级别上加入一些日志代码，记录一些日志信息，方便我们在发现问题的时候查找。
这些信息会与事件做相关，例如：用户登录，下订单，用户浏览某件商品，一小时以内的网关流量，用户平均响应时间等等。
这类以日志的记录和查询的解决方案比较多。比如 ELK 方案（Elasticsearch+Logstash+Kibana），使用ELK（Elasticsearch、Logstash、Kibana）+ Kafka/Redis/RabbitMQ 来搭建一个日志系统。
ELK 结合 Redis/Kafka/RabbitMQ 实现日志类监控
程序内部通过 Spring AOP 记录日志，Beats 收集日志文件，然后用 Kafka/Redis/RabbitMQ 将其发送给 Logstash，Logstash 再将日志写入 Elasticsearch。
最后，使用 Kibana 将存放在 Elasticsearch 中的日志数据显示出来，形式可以是实时数据图表。
[toc]
编程最基本的原则就是要追求高内聚和低耦合的解决方案和代码模块设计。SOLID 是面向对象设计5大重要原则的首字母缩写：
| SRP | Single Responsibility Principle | 单一责任原则 |
| OCP | Open Closed Principle | 开放封闭原则 |
| LSP | Liskov Substitution Principle | 里氏替换原则 |
| ISP | Interface Segregation Principle | 接口分离原则 |
| DIP | Dependency Inversion Principle | 依赖倒置原则 |
[toc]
在硅谷一线大厂所维护的系统服务中，我们经常可以看见SLA这样的承诺。
例如，在谷歌的云计算服务平台Google Cloud Platform中，他们会写着“99.9% Availability”这样的承诺。那什么是“99.9% Availability”呢？
要理解这个承诺是什么意思，首先，你需要了解到底什么是SLA？
SLA（Service-Level Agreement），也就是服务等级协议，指的是系统服务提供者（Provider）对客户（Customer）的一个服务承诺。这是衡量一个大型分布式系统是否“健康”的常见方法。
在开发设计系统服务的时候，无论面对的客户是公司外部的个人、商业用户，还是公司内的不同业务部门，我们都应该对自己所设计的系统服务有一个定义好的SLA。
因为SLA是一种服务承诺，所以指标可以多种多样。根据我的实践经验，给你介绍最常见的四个SLA指标，可用性、准确性、系统容量和延迟。
[toc]
TCP协议保证数据传输可靠性的方式主要有：
校验和
发送的数据包的二进制相加然后取反，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。
确认应答+序列号
TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
超时重传
当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
流量控制
TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。
接收方有即时窗口（滑动窗口），随ACK报文发送
拥塞控制
当网络拥塞时，减少数据的发送。
发送方有拥塞窗口，发送数据前比对接收方发过来的即使窗口，取小
慢启动、拥塞避免、拥塞发送、快速恢复
应用数据被分割成TCP认为最适合发送的数据块。
TCP的接收端会丢弃重复的数据。
[toc]
NameServer是RocketMQ的命名服务（路由中心、注册中心），提供更新和发现Broker服务的功能，是几乎无状态节点，可集群部署。NameServer节点之间互不通信，路由变化也不会马上通知客户端（生产者和消费者）。
既然NameServer的节点之间互不通信，变更也不发送通知，那又是如何保证数据最终一致的呢？
Broker节点在启动时，轮询NameServer集群，与每个NameServer节点建立长连接，发起注册请求。
Broker节点注册成功后，每隔30s定期向NameServer上报Topic路由信息，NameServer收到心跳包后记录Broker的最新时间戳。
Broker节点正常下线时，会与NameServer断开长连接，Netty的通道关闭，监听器会监听到连接断开事件，然后将这个Broker剔除掉。
NameServer中有一个定时任务，每隔10s扫描Broker列表，如果Broker的最新时间戳距离当前时间超过120s，会判定Broker失效并将其剔除掉。
