HTTPS如何保证传输安全
一. 什么是 HTTPSHTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。
所以安全上存在以下三个风险：
窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
冒充风险，比如冒充淘宝网站，用户钱容易没。
HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。
二. HTTPS 加密流程HTTPS 主要是通过在 HTTP 协议基础上加入 SSL/TLS 协议来实现加密，HTTPS 是应用层协议，需要先建立 TCP 连接，并完成 TLS 握手后，才能建立通信安全的连接。其加密过程分为对称加密和非对称加密两个阶段。非对称加密阶段主要目的是为了交换对称加密密钥，我们也称之为 TLS 协议握手，TLS 握手成功后，就会使用对称机密的方式进行加密传输。
在非对称加密阶段，服务器拥有一对公钥和私钥（非对称加密特性：公钥加密的数据只有私钥能解密，私钥加密的数据只有公钥能解密）。服务器将公钥发送给客户端，客户端使用公钥对一 ...
RocketMQ实现原理十问十答
RocketMQ 架构RocketMQ 主要有两大组件，一个是 NameServer，相当于注册中心，内部暂存着 Broker 相关信息；另一个是 Broker，它是消息处理、存储的组件。一个 Topic 消息数据可以分片在多个 Broker 上，这样消息的存储就能做到横向扩展，如果现有的 broker 性能不能满足要，只需要扩展 broker 节点数量即可。每一个 broker 上可以有多个 queue，队列的数量决定着消费者实例的数量，本质上决定着消费能力的上限（一个队列通常情况下只会被一个 Consumer 消费，如果多个消费者消费一个队列，就会有并发问题，需要加锁，这样与整体高性能的设计目标背道而驰）。
Broker在启动时，会将自身保存的 topic 信息全部注册至NameServer，然后每隔30s会向NameServer通过心跳更新自身的Topic信息。NameServer 每隔10s 会扫描 brokerLiveTable，检测表中上次收到心跳包的时间，比较当前时间与上一次时间，如果超过120s，则会认为broker不可用，移除路由表中该broker相关的所有信息。
...
深入剖析RocketMQ消息消费原理
本文参考转载至《RocketMQ技术内幕 第2版》
一. 消息消费概述消息消费以组的模式开展，一个消费组可以包含多个消费者，每个消费组可以订阅多个主题，消费组之间有集群模式和广播模式两种消费模式。集群模式是当前主题下的同一条消息只允许被其中一个消费者消费。广播模式是当前主题下的同一条消息将被集群内的所有消费者消费一次。
消息服务器与消费者之间的消息传送也有两种方式：推模式和拉模式。所谓的拉模式，是消费端主动发起拉取消息的请求，而推模式是消息到达消息服务器后，再推送给消息消费者。RocketMQ消息推模式基于拉模式实现，在拉模式上包装一层，一个拉取任务完成后开始下一个拉取任务。
集群模式下，多个消费者如何对消息队列进行负载呢？消息队列负载机制遵循一个通用的思想：一个消息队列同一时间只允许被一个消费者消费，一个消费者可以消费多个消息队列。
RocketMQ 支持局部顺序消息消费，也就是保证同一个消息队列上的消息按顺序消费。不支持消息全局顺序消费，如果要实现某一主题的全局顺序消息消费，可以将该主题的队列数设置为1，牺牲高可用性。RocketMQ支持两种消息过滤模式：表达式（TAG、SQL ...
Raft协议深度解析：RocketMQ中基于DLedger的日志主从复制
本文所涉及的注释源码：bigcoder84/dledger
Raft 协议主要包含两个部分：Leader选举和日志复制。
前面我们在 Raft协议深度解析：RocketMQ中的自动Leader选举与故障转移 一文中已经详细介绍了DLedger如何实现Leader选举的，而本文主要聚焦于Leader选举完成后的日志复制的过程。
一. RocketMQ DLedger 存储实现说起日志的复制，就必须要从日志存储实现说起，它约束着Raft每一个结点如何存储数据。下面先介绍一次Raft存储的核心实现类：
1.1 存储实现核心类
DLedgerStore：存储抽象类，该类有如下核心抽象方法：
getMemberState： 获取节点状态机
appendAsLeader：向主节点追加日志（数据）
appendAsFollower：向从节点广播日志（数据）
get：根据日志下标查找日志
getLedgerEndTerm：获取Leader节点当前最大的投票轮次
getLedgerEndIndex：获取Leader节点下一条日志写入的日志序号
truncate：删除日志
getFirst ...
Raft协议深度解析：RocketMQ中的自动Leader选举与故障转移
本文所涉及的注释源码：bigcoder84/dledger
RocketMQ 4.5版本之前，可以采用主从架构进行集群部署，但是如果 master 节点挂掉，不能自动在集群中选举出新的 master 节点，需要人工介入，在4.5版本之后提供了 DLedger 模式，DLedger 是 Open Messaging 发布的一个基于 Raft 协议实现的Java类库，可以方便引用到系统中，满足其高可用、高可靠、强一致的需求，其中在 RocketMQ 中作为消息 Broker 存储高可用实现的一种解决方案。使用Raft算法，如果 master 节点出现故障，可以自动选举出新的 master 进行切换。
在阅读本文之前，建议先仔细了解Raft协议的思路，具体可移步至：深度解析 Raft 分布式一致性协议
一. Raft协议概述在分布式系统应用中，高可用、一致性是经常面临的问题，针对不同的应用场景，我们会选择不同的架构方式，比如master-slave、基于ZooKeeper 选主。随着时间的推移，出现了基于Raft算法自动选主的方式，Raft 是在 Paxos 的基础上，做了一些 ...
深度解析 Raft 分布式一致性协议
本文参考转载至：
浅谈 Raft 分布式一致性协议｜图解 Raft - 白泽来了 - 博客园 (cnblogs.com)
深度解析 Raft 分布式一致性协议 - 掘金 (juejin.cn)
raft-zh_cn/raft-zh_cn.md at master · maemual/raft-zh_cn (github.com)
本篇文章将模拟一个KV数据读写服务，从提供单一节点读写服务，到结合分布式一致性协议（Raft）后，逐步扩展为一个分布式的，满足一致性读写需求的读写服务的过程。
其中将配合引入Raft协议的种种概念：选主、一致性、共识、安全等，通篇阅读之后，将帮助你深刻理解什么是分布式一致性协议。
一. 单机Key-Value数据读写服务
DB Engine这里可以简单看成对数据的状态进行存储（比如B+树型的组织形式），负责存储Key-Value的内容 ，并假设这个Key-Value服务将提供如下接口：
Get(key) —> value
Put([key, value])
思考此时Key-Value服务的可靠性：
容错：单个数据存储节点，不 ...
手把手教你改造 Sentinel Dashboard 实现配置持久化
一. 概述Sentinel客户端默认情况下接收到 Dashboard 推送的规则配置后，可以实时生效。但是有一个致命缺陷，Dashboard和业务服务并没有持久化这些配置，当业务服务重启后，这些规则配置将全部丢失。
Sentinel 提供两种方式修改规则：
通过 API 直接修改 (loadRules)
通过 DataSource 适配不同数据源修改
通过 API 修改比较直观，可以通过以下几个 API 修改不同的规则：
12FlowRuleManager.loadRules(List<FlowRule> rules); // 修改流控规则DegradeRuleManager.loadRules(List<DegradeRule> rules); // 修改降级规则
手动修改规则（硬编码方式）一般仅用于测试和演示，生产上一般通过动态规则源的方式来动态管理规则。
上述 loadRules() 方法只接受内存态的规则对象，但更多时候规则存储在文件、数据库或者配置中心当中。DataSource 接口给我们提供了对接任意配置源的能力。相比直接通过 API 修改规则 ...
一文读懂Apollo客户端配置加载流程
本文基于 apollo-client 2.1.0 版本源码进行分析
Apollo 是携程开源的配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
Apollo支持4个维度管理Key-Value格式的配置：
application (应用)
environment (环境)
cluster (集群)
namespace (命名空间)
同时，Apollo基于开源模式开发，开源地址：https://github.com/ctripcorp/apollo
一. SpringBoot集成Apollo1.1 引入Apollo客户端依赖12345<dependency> <groupId>com.ctrip.framework.apollo</groupId> <artifactId>apollo-client</artifactId> <version>2.1.0</version></dependency> ...
Java21 GA新特性-虚拟线程详解（转）
本文转载至：虚拟线程 - VirtualThread源码透视 - throwable - 博客园 (cnblogs.com)
一. 前提JDK19于2022-09-20发布GA版本，该版本提供了虚拟线程的预览功能。下载JDK19之后翻看了一下有关虚拟线程的一些源码，跟早些时候的Loom项目构建版本基本并没有很大出入，也跟第三方JDK如鹅厂的Kona虚拟线程实现方式基本一致，这里分析一下虚拟线程设计与源码实现。
二. Platform Thread 与 Virtual Thread因为引入了虚拟线程，原来JDK存在java.lang.Thread类，俗称线程，为了更好地区分虚拟线程和原有的线程类，引入了一个全新类java.lang.VirtualThread（Thread类的一个子类型），直译过来就是”虚拟线程”。
题外话：在Loom项目早期规划里面，核心API其实命名为Fiber，直译过来就是”纤程”或者”协程”，后来成为了废案，在一些历史提交的Test类或者文档中还能看到类似于下面的代码：
123456789101112// java.lang.FiberFiber f = ...
RocketMQ主从同步原理
一. 主从同步概述主从同步这个概念相信大家在平时的工作中，多少都会听到。其目的主要是用于做一备份类操作，以及一些读写分离场景。比如我们常用的关系型数据库mysql，就有主从同步功能在。
主从同步，就是将主服务器上的数据同步到从服务器上，也就是相当于新增了一个副本。
而具体的主从同步的实现也各有千秋，如mysql中通过binlog实现主从同步，es中通过translog实现主从同步，redis中通过aof实现主从同步。那么，rocketmq又是如何实现的主从同步呢？
另外，主从同步需要考虑的问题是哪些呢？
数据同步的及时性？（延迟与一致性）
对主服务器的影响性？（可用性）
是否可替代主服务器？（可用性或者分区容忍性）
前面两个点是必须要考虑的，但对于第3个点，则可能不会被考虑。因为通过系统可能无法很好的做到这一点，所以很多系统就直接忽略这一点了，简单嘛。即很多时候只把从服务器当作是一个备份存在，不会接受写请求。如果要进行主从切换，必须要人工介入，做预知的有损切换。但随着技术的发展，现在已有非常多的自动切换主从的服务存在，这是在分布式系统满天下的当今的必然趋势。
二. RocketMQ ...