java静态测试工具，深度好文

前言

最近刷到了一句耐人寻味的话，“解决雪崩问题的最好办法是不发生雪崩”。

不论是在硅谷互联网公司里还是在国内的互联网平台上，曾多次遇到过海量规模的交易瞬间吞噬平台的悲惨故事。

核心的解决方案大同小异，都是通过缓存，逐层减少流量的冲击，保护用户的体验和平台的服务可用。

金融、财务行业有现金为王的说法，互联网技术行业用“缓存为王"清楚地概括了缓存的重要性。

而本文深入浅出地讨论了Ehcache、Memcached、Redis、 Tair、 EVCache等各种常用缓存开源系统的方案及精粹。

虽然读过不少国外有关缓存的技术专著，大多数偏原则和理论，具体实施方案和案例较少，特别是结合中国互联网技术实践的更少。

所以本文实际上填补了缓存技术文献在这方面的空白。尤其是结合微博、社交和电商平台的应用实践探讨，对想学习如何利用缓存技术解决实践中具体问题的读者大有裨益。

CAP原则

在分布式系统要满足CAP原则，一个提供数据服务的存储系统无法同时满足：数据一致性、数据可用性、分区耐受性。

C数据一致性：所有应用程序都能访问到相同的数据。 A数据可用性：任何时候，任何应用程序都可以读写访问。 P分区耐受性：系统可以跨网络分区线性伸缩。（通俗来说就是数据的规模可扩展） 在大型网站中通常都是牺牲C，选择AP。为了可能减小数据不一致带来的影响，都会采取各种手段保证数据最终一致。

• 数据强一致：各个副本的数据在物理存储中总是一致的。

• 数据用户一致：数据在物理存储的各个副本可能是不一致的，但是通过纠错和校验机制，会确定一个一致的且正确的数据返回给用户。

• 数据最终一致：物理存储的数据可能不一致，终端用户访问也可能不一致，但是一段时间内数据会达成一致。

一致性算法

• 使一组服务器在一个值上达成一致，所以活跃的特征在于最终每个服务器都可以决定一个值。

• 通过值的一致能够实现对同一个数据的请求会让同一个服务器来处理。

• Paxos和Raft都是通过选取master来实现多节点下值的一致性，从而借助一致性hash算法来分配请求。

一致性Hash算法 一致性Hash算法可以根据不同的属性参数（通常是IP和端口号），生成一串不相同的Hash值，并将Hash值转换成0-2^32-1的整数， 不同范围的值由不同服务器进行处理。（B-C之间的由B处理）。

Raft算法和Paxos算法

Raft算法是在Paxos算法的基础上的进行优化。 Raft在Paxos的基础上主要做了两个方向的优化： 1.将复杂的分布式共识问题拆分成领导选举、日志复制和安全性三个问题 2.压缩状态空间：相对于Paxos施加了更合理的限制，减少了系统状态过多而产生的不确定因素。

领导选举(具体以zookeeper举例) 其基本的特性有：

• zookeeper在配置集群时节点数不可小于3

• 节点只有获得半数以上的投票才能当选Leader

• zookeeper在启动时会通过广播机制来把投票结果告诉其他的节点

• zookeeper在启动时首先会给自己投票，然后与其他已启动的节点进行通信，通过比较id从而判断是否能获取其他节点的投票

zookeeper在选举过程中的角色：领导者、跟随者、观察者、竞选者

日志复制 在共识算法中，所有服务器节点都会包含一个有限状态自动机，名为复制状态机（replicated state machine）。每个节点都维护着一个复制日志（replicated logs）的队列，复制状态机会按序输入并执行该队列中的请求，执行状态转换并输出结果。可见，如果能保证各个节点中日志的一致性，那么所有节点状态机的状态转换和输出也就都一致。

可见，日志由一个个按序排列的entry组成。每个entry内包含有请求的数据，还有该entry产生时的领导任期值。每个节点上的日志队列用一个数组log[]表示。

领导节点选举出来后，集群就可以开始处理客户端请求了。当客户端发来请求时，领导节点首先将其加入自己的日志队列，再并行地发送AppendEntries RPC消息给所有跟随节点。最终实现节点数据的一致性。

安全性 Raft安全保障机制有5种：

• 选举安全性：节点要3个以上，避免“脑裂”的方式

• 领导者只追加：客户端发出的请求都是插入领导者日志队列的尾部，没有修改或删除的操作。

• 日志匹配：每条AppendEntries都会包含最新entry之前那个entry的下标与任期值，如果跟随节点在对应下标找不到对应任期的日志，就会拒绝接受并告知领导节点。（避免追随者故障，导致数据不一致）

• 领导者完全性:如果有一条日志在某个任期被提交了，那么它一定会出现在所有任期更大的领导者日志里。（master会优先获取日志的更新）

• 状态机安全性:如果一个节点已经向其复制状态机应用了一条日志中的请求，那么对于其他节点的同一下标的日志，不能应用不同的请求。(避免master宕机时，重新选举，导致部分节点数据不一致)

Raft算法和Paxos算法在分布式中的使用

Consul vs Eureka vs Zookeeper

注： CAP: 数据一致性、数据可用性、分区耐受性 AP: 牺牲强一致性，部分节点宕机，不会影响正常工作的节点。 CP: 牺牲数据可用性,为了保证数据的一致性，当一台机器出现故障时，所有节点的数据都不能使用。

资料分享

这是我从某优质机构弄来的一些资料，内容我认为确实称得上优质二字，如需领取，请点赞这篇文章，关注我然后点击这里即可免费领取

首先分享一份学习大纲，内容较多，涵盖了互联网行业所有的流行以及核心技术，以截图形式分享：

（亿级流量性能调优实战+一线大厂分布式实战+架构师筑基必备技能+设计思想开源框架解读+性能直线提升架构技术+高效存储让项目性能起飞+分布式扩展到微服务架构…实在是太多了）

其次分享一些技术知识，以截图形式分享一部分：

Tomcat架构解析：

算法训练+高分宝典：

Spring Cloud+Docker微服务实战：

最后分享一波面试资料：

切莫死记硬背，小心面试官直接让你出门右拐

1000道互联网Java面试题：

Java高级架构面试知识整理：

1000道互联网Java面试题：

[外链图片转存中…(img-muN75vlc-1621487970953)]

Java高级架构面试知识整理：

[外链图片转存中…(img-NToQsYAJ-1621487970954)]