* 使用类加载机制来优先使用自己类。 *

* Schema meta data loader. */ @NoArgsConstructor(access = AccessLevel.PRIVATE) @Slf4j(topic = "ShardingSphere-metadata") public final class SchemaMetaDataLoader { private static final String TABLE_TYPE = "TABLE"; private static final String TABLE_NAME = "TABLE_NAME"; /** * Load schema meta data. * * @param dataSource data source * @param maxConnectionCount count of max connections permitted to use for this query * @param databaseType database type * @return schema meta data * @throws SQLException SQL exception */ public static SchemaMetaData load(final DataSource dataSource, final int maxConnectionCount, final String databaseType) throws SQLException { boolean openNewLogic = Boolean.parseBoolean(SpringUtil.getProperty("schema-meta-data-load-logic")); log.info("[rewrite] openNewLogic:{}", openNewLogic); if(!openNewLogic){ log.info("old logic"); return loadBackup(dataSource,maxConnectionCount,databaseType); } List tableNames; try (Connection connection = dataSource.getConnection()) { tableNames = loadAllTableNames(connection, databaseType); } log.info("[rewrite] Loading {} tables' meta data.", tableNames.size()); if (0 == tableNames.size()) { return new SchemaMetaData(Collections.emptyMap()); } // 重写指定表 tableNames = SHARDING_TABLE_LIST.stream() .map(s -> String.format("%s_%s", s, OFFLINE_SHARDING_NUM)).collect( Collectors.toList()); List> tableGroups = Lists.partition(tableNames, Math.max(tableNames.size() / maxConnectionCount, 1)); Map queriedMetaDataMap = 1 == tableGroups.size() ? load(dataSource.getConnection(), tableGroups.get(0), databaseType) : asyncLoad(dataSource, maxConnectionCount, tableNames, tableGroups, databaseType); // 将重写其他分表 Map newTableMetaMap = Maps.newHashMap(); for (int i = 0; i <= OFFLINE_SHARDING_NUM; i++) { int seq = i; for (String shardingTable : SHARDING_TABLE_LIST) { // 查到的表,依次处理 queriedMetaDataMap.forEach((tableName, tableMetaData) -> { // tableName, tableMetaData 用不到 String newTableKey = String.format("%s_%s", shardingTable, seq); // 获取指定表的元数据,写入新表 TableMetaData newTableMeta = queriedMetaDataMap.get( String.format("%s_%s", shardingTable, OFFLINE_SHARDING_NUM)); newTableMetaMap.put(newTableKey, newTableMeta); }); } } return new SchemaMetaData(newTableMetaMap); } /** * Load schema meta data. * * @param dataSource data source * @param maxConnectionCount count of max connections permitted to use for this query * @param databaseType database type * @return schema meta data * @throws SQLException SQL exception */ public static SchemaMetaData loadBackup(final DataSource dataSource, final int maxConnectionCount, final String databaseType) throws SQLException { List tableNames; try (Connection connection = dataSource.getConnection()) { tableNames = loadAllTableNames(connection, databaseType); } log.info("Loading {} tables' meta data.", tableNames.size()); if (0 == tableNames.size()) { return new SchemaMetaData(Collections.emptyMap()); } List> tableGroups = Lists.partition(tableNames, Math.max(tableNames.size() / maxConnectionCount, 1)); Map tableMetaDataMap = 1 == tableGroups.size() ? load(dataSource.getConnection(), tableGroups.get(0), databaseType) : asyncLoad(dataSource, maxConnectionCount, tableNames, tableGroups, databaseType); return new SchemaMetaData(tableMetaDataMap); } private static Map load(final Connection connection, final Collection tables, final String databaseType) throws SQLException { try (Connection con = connection) { Map result = new LinkedHashMap<>(); for (String each : tables) { result.put(each, new TableMetaData(ColumnMetaDataLoader.load(con, each, databaseType), IndexMetaDataLoader.load(con, each, databaseType))); } return result; } } private static List loadAllTableNames(final Connection connection, final String databaseType) throws SQLException { List result = new LinkedList<>(); try (ResultSet resultSet = connection.getMetaData() .getTables(connection.getCatalog(), JdbcUtil.getSchema(connection, databaseType), null, new String[]{TABLE_TYPE})) { while (resultSet.next()) { String table = resultSet.getString(TABLE_NAME); if (!isSystemTable(table)) { result.add(table); } } } return result; } private static boolean isSystemTable(final String table) { return table.contains("$") || table.contains("/"); } private static Map asyncLoad(final DataSource dataSource, final int maxConnectionCount, final List tableNames, final List> tableGroups, final String databaseType) throws SQLException { Map result = new ConcurrentHashMap<>(tableNames.size(), 1); ExecutorService executorService = Executors.newFixedThreadPool( Math.min(tableGroups.size(), maxConnectionCount)); Collection>> futures = new LinkedList<>(); for (List each : tableGroups) { futures.add( executorService.submit(() -> load(dataSource.getConnection(), each, databaseType))); } for (Future> each : futures) { try { result.putAll(each.get()); } catch (final InterruptedException | ExecutionException ex) { if (ex.getCause() instanceof SQLException) { throw (SQLException) ex.getCause(); } Thread.currentThread().interrupt(); } } return result; } } ``` #### 第三种解决方案 [Section titled “第三种解决方案”](#第三种解决方案) 在sharding-jdbc的配置中,再配置一个库,只是不用而已,就不会获取每个分表的元数据了。这个是比较推荐的解决方案! *20250107更新:* 配置的另一个库和当前的库是一样的,则推荐采用第三种解决方案,没有一点问题。如果配置的库和现在不一样,则会有问题,sharding-jdbc会随机选择一个库来操作。那么当两个库中的表不一样,则会一会正常一会失败,因为是随机的。 那么如何解决呢? 配置默认的数据源； ```yml spring: shardingsphere: datasource: # xx-0 线下单主业务库,xx-1 线下单主业务归档库 names: xx-0,xx-1 xx-0: url: xxx username: xxx password: xxx type: xxx xx-1: url: xxx username: xxx password: xxx type: xxx driver-class-name: xxx sharding: default-data-source-name: xx-0 # 这里配置默认的库,就不会随机了 ``` 当配置了默认的数据源,则又回到启动慢的问题。此时按照第二种解决方案即可 # 刷数的最佳姿势 > 刷数的最佳姿势 #### 最佳实践 [Section titled “最佳实践”](#最佳实践) 游标  #### 伪代码 [Section titled “伪代码”](#伪代码) ```python max_id = 0 while True: # 使用max_id作为起始ID查询数据 data = query_data(start_id=max_id, limit=page_size) if not data: break # 没有数据，结束查询 process_data(data) # 更新max_id为当前批次的最大ID max_id = get_max_id(data) ``` [刷数代码抽象 ](/software-engineer/best-practices/general-ability/flash-data)落地的Java代码 #### 优缺点 [Section titled “优缺点”](#优缺点) 使用最大ID作为分页起始ID（通常称为”ID游标分页”）相比传统的 LIMIT 和 OFFSET 分页方法，有以下几个显著优势： 1. 性能优势 * 传统 LIMIT/OFFSET：随着页码增加，OFFSET 需要跳过大量记录，查询性能急剧下降 * ID游标分页：每次只查询大于上一批最大ID的数据，查询速度始终保持稳定 2. 数据一致性 * LIMIT/OFFSET：在分页过程中，如果有新数据插入，可能导致同一条记录重复出现或被遗漏 * ID游标分页：使用严格的ID范围，可以避免数据重复和遗漏问题 3. 扩展性 * 适合大数据量场景，特别是分布式数据库和海量数据查询 * 在数据量超过百万、千万级别时，性能优势更加明显 示例对比： 传统 LIMIT/OFFSET 方式： ```sql -- 查询第 N 页，每页 10 条 SELECT * FROM table LIMIT 10 OFFSET (N-1) * 10 ``` ID游标分页方式： ```sql -- 查询大于上一批最大ID的 10 条数据 SELECT * FROM table WHERE id > last_max_id LIMIT 10 ``` 实际应用中，ID游标分页特别适合： * 实时数据流处理 * 消息系统 * 日志查询 * 高并发场景下的数据获取 缺点是不直观，需要额外的业务逻辑来维护和传递”最后一个ID”。 #### 自己的实践 [Section titled “自己的实践”](#自己的实践) * 从mysql刷数据到es * 从mongodb读取历史数据,刷mysql — 使用游标很稳定,任务跑了6个多小时,没有性能问题。如果使用分页,十几分钟就会出现严重的性能问题。 所以在操作大批量的数据的时候,需要优先考虑游标形式。为了保持游标的连续性，建议在内存中做条件处理，否则可能导致下一次取出的数据为空，中断整个流程。 # Canal消息处理,写入ES > Canal消息处理,写入ES **序列图**  **流程图**  Canal消息处理,写入ES ```java import java.util.List; import javax.annotation.Resource; import lombok.extern.slf4j.Slf4j; import org.springframework.util.CollectionUtils; /** * 抽象Canal消息处理逻辑 */ @Slf4j public abstract class AbstractCanalHandler, Target extends BaseEsIndexModel> { @Resource private List> abstractEsOperateList; private final Class type; // Constructor to accept the Class type protected AbstractCanalHandler(Class type) { this.type = type; } private final ThreadLocal dataThreadLocal = new ThreadLocal<>(); protected T getData() { return dataThreadLocal.get(); } /** * 检查 * * @return */ protected abstract Boolean check(); /** * 组装ES数据模型 * * @return */ protected abstract List assemble(); private void deleteEsDoc(List esOrderModelList) { for (Target target : esOrderModelList) { abstractEsOperateList.forEach(item -> item.doBusiness(target, Type.DELETE)); } } // insert or update private void saveEsDoc(List esOrderModelList) { for (Target target : esOrderModelList) { abstractEsOperateList.forEach(item -> item.doBusiness(target, Type.SAVE)); } } /** * 处理流程 */ private void handle() { List targetList = assemble(); if (CollectionUtils.isEmpty(targetList)) { return; } String type = getData().getType(); if (OperateType.DELETE.name().equals(type)) { deleteEsDoc(targetList); } if (OperateType.INSERT.name().equals(type) || OperateType.UPDATE.name().equals(type)) { saveEsDoc(targetList); } } /** * 执行业务 */ public Boolean execBusiness(String message) { try { init(message); if (!check()) { return false; } handle(); return true; } finally { dataThreadLocal.remove(); } } private void init(String message) { dataThreadLocal.set(JsonUtils.toObject(message, type)); } /** * 手动刷数入口 */ public void manualFlash(T t) { try { // 初始化 dataThreadLocal.set(t); // 组装 List targetList = assemble(); if (CollectionUtils.isEmpty(targetList)) { return; } // 写入Es saveEsDoc(targetList); } catch (Exception e) { log.error("手动刷数失败", e); } finally { dataThreadLocal.remove(); } } } ``` # 数量一致性校验 > 数量一致性校验 **序列图**  **流程图**  数量一致性校验 ```java import com.alibaba.fastjson.JSONObject; import java.util.Date; import java.util.List; import javax.annotation.Resource; import lombok.extern.slf4j.Slf4j; import org.apache.shardingsphere.api.hint.HintManager; import org.springframework.beans.factory.annotation.Value; /** * 抽象数量一致性校验 */ @Slf4j public abstract class AbstractConsistencyCheck { protected Date endDate; protected Date startDate;//由endDate往前推指定分钟数获得 protected FlashParam flashParam; // 补偿参数 @Value("${consistencyCheckBeforeMinute:10}") private Integer consistencyCheckBeforeMinute; @Resource private AlertService alertService; protected Integer defaultMinuteAgo() { return consistencyCheckBeforeMinute; } /** * 数据库数据总数 * * @return */ private Long dbTotalCount() { return normalDbTotalCount() + shardingDbTotalCount(); } /** * 普通数据库库总数 * * @return */ protected abstract Long normalDbTotalCount(); /** * 分表数据库总数 * * @return */ protected abstract Long shardingDbCount(); /** * 是否处理非VIP数据 * * @return */ protected Boolean isHandleNonVipData() { return Boolean.FALSE; } private Long shardingDbTotalCount() { Long shardingTotal = 0L; List shardingValueList = ShardingUtils.shardingValueList(isHandleNonVipData()); // 获取所有分表值,这里仅做展示 for (String shardingValue : shardingValueList) { try (HintManager hintManager = HintManager.getInstance()) { DefineShardingHit hit = new DefineShardingHit(); hit.setQueryHit(QueryHit.builder().seq(shardingValue).build()); OfflineOrderTableShardingHintAlgorithm.setHintManager(hintManager, hit); shardingTotal = shardingTotal + shardingDbCount(); } } return shardingTotal; } protected void toCompensate() { // 组装补偿参数 FlashParam flashParam = new FlashParam(); flashParam.setStart(startDate); flashParam.setEnd(endDate); this.flashParam = flashParam; // 补偿 compensate(); } protected abstract void compensate(); /** * 一致性告警 * @return */ protected abstract ConsistencyNotify consistencyNotify(); /** * Es数据条数 * * @return */ protected abstract Long esCount(); public void consistencyAlarm(Long dbTotalCount, Long esTotalCount, String tips) { JSONObject req = new JSONObject(); req.put("startDate", formatYYMMDD(startDate)); req.put("endDate", formatYYMMDD(endDate)); ConsistencyNotify consistencyNotify = consistencyNotify(); String content = String.format("[%s]-参数:%s,数据库总条数:%s,ES总条数:%s。tips:%s", consistencyNotify.domain, JsonUtils.toJson(req), dbTotalCount, esTotalCount, tips); alertService.alert(content,consistencyNotify.domain); // 发出告警 } /** * 检查,如果不一样则补偿 */ public void checkIfCompensate(Date endDate) { init(endDate); Boolean checkOk = checkIfAlert("[第一次检查]正在执行补偿,若无后续消息则补偿成功"); if (!checkOk) { // 补偿 toCompensate(); // recheck checkIfAlert("[第二次检查]补偿后,依然不等!需要人工介入"); } } private Boolean checkIfAlert(String tips) { Long dbTotalCount = dbTotalCount(); Long esTotalCount = esCount(); boolean checkOk = dbTotalCount.equals(esTotalCount); if (!checkOk) { consistencyAlarm(dbTotalCount, esTotalCount, tips); } return checkOk; } private void init(Date endDate) { this.endDate = endDate; this.startDate = OrderDateUtils.previousDateForMinute(this.endDate, defaultMinuteAgo()); } public enum ConsistencyNotify { MAOTKON_ALERT_1("Moatkon告警示例") ; private final String domain; // 业务域 ConsistencyNotify(String domain) { this.domain = domain; } } } ``` 一致性校验获取有效计数 ```java import java.util.Date; import java.util.List; import lombok.Data; import org.springframework.util.CollectionUtils; /** * 抽象有效订单数目 */ public abstract class AbstractConsistencyCheckEfficientCount { protected Integer defaultLimit(){ return 200; } @Data public static class EfficientParam { private String startDate; private String endDate; private Long startId; public void refreshStartId(Long startId) { this.startId = startId; } } protected EfficientParam param; protected abstract List dataList(); /** * 暴露出去的方法 * * @param startDate * @param endDate * @return */ public Long fetchEfficientCount(Date startDate, Date endDate) { init(startDate, endDate); Long totalCount = 0L; for (; ; ) { List list = dataList(); if (CollectionUtils.isEmpty(list)) { break; } // 刷新最新的游标 freshStartId(list); // 累加有效总数 totalCount = totalCount + efficientCount(list); } return totalCount; } private void init(Date startDate, Date endDate) { EfficientParam init = new EfficientParam(); init.setStartDate(OrderDateUtils.formatYYMMDD(startDate)); init.setEndDate(OrderDateUtils.formatYYMMDD(endDate)); init.setStartId(0L); this.param = init; } /** * 刷新StartId */ protected abstract void freshStartId(List list); /** * 过滤后的有效数据条数 * * @return */ protected abstract Long efficientCount(List list); } ``` # 数据清理 > 数据清理 抽象清理逻辑 ```java import java.util.Date; import lombok.extern.slf4j.Slf4j; /** * 抽象清理逻辑 */ @Slf4j public abstract class AbstractClean { /** * 超过指定天数,过期 * * @return 过期天数 */ protected abstract Integer expireDays(); private Integer defaultMinutes(){return 5;} protected abstract void clean(String startDate, String endDate); protected abstract Boolean checkHasData(String endDate); protected abstract Date getLatestdEndDate(Date endDate); public void execClean() { Date endDate = previousDate(new Date(), expireDays()); Date startDate; while (true) { startDate = subtractMinutes(endDate,defaultMinutes()); // 每次清理很短时间区间内的数据(目前是defaultMinutes()内的数据) String startDateStr = formatYYMMDD(startDate); String endDateStr = formatYYMMDD(endDate); log.info("clean,startDate:{},endDate:{}",startDateStr,endDateStr); clean(startDateStr, endDateStr); // 校验是否还有数据 if(!checkHasData(endDateStr)){ log.info("clean finished,startDate:{},endDate:{}",startDateStr,endDateStr); break; } // 获取索引中在限定条件下最大的时间。 以前推的开始时间作为条件 endDate = getLatestdEndDate(startDate); } } } ``` # ES操作 > ES操作  抽象Es操作 ```java /** * 抽象Es操作 */ public abstract class AbstractEsOperate { private final ThreadLocal threadLocalT = new ThreadLocal<>(); private final ThreadLocal threadLocalType = new ThreadLocal<>(); // 获取当前线程的 t protected T getT() { return threadLocalT.get(); } // 获取当前线程的 type protected Type getType() { return threadLocalType.get(); } private final Class clazz; // Constructor to accept the Class type protected AbstractEsOperate(Class clazz) { this.clazz = clazz; } public enum Type { DELETE, SAVE } private Boolean check() { return clazz.equals(threadLocalT.get().getClass()); } private void init(T t, Type type) { threadLocalT.set(t); threadLocalType.set(type); } protected abstract Boolean exec(); public void doBusiness(T t, Type type) { try { init(t, type); if (!check()) { return; } exec(); } finally { threadLocalT.remove(); threadLocalType.remove(); } } } ``` # 刷数 > 刷数 **序列图**  **流程图**  抽象刷数逻辑 ```java import com.fasterxml.jackson.annotation.JsonFormat; import java.util.Date; import java.util.List; import java.util.Objects; import java.util.concurrent.TimeUnit; import joptsimple.internal.Strings; import lombok.Data; import lombok.extern.slf4j.Slf4j; import org.apache.shardingsphere.api.hint.HintManager; import org.springframework.util.CollectionUtils; import org.springframework.util.StringUtils; /** * 抽象刷数逻辑 * * @param 源数据类型 * @param Canal数据类型 * @param 业务场景类型（仅作为语义标记） */ @Slf4j public abstract class AbstractFlash { protected Integer defaultLimit() { return 500; } /** * 刷数入参 */ private static final ThreadLocal flashParamThreadLocal = new ThreadLocal<>(); protected FlashParam getFlashParam(){ return flashParamThreadLocal.get(); } /** * 获取数据源 * * @return */ protected abstract List getSourceList(); /** * 组装Canal目标数据 * * @param sourceList DB数据,需要转成目标CanalData * @return canalData */ protected abstract List assembleCanalData(List sourceList); /** * 刷数 */ protected abstract void flash(List canalDataList); /** * 私有执行 */ private void innerExec() { // 初始化游标 initCursor(); while (!getFlashParam().empty() && getFlashParam().getCursorStartId() <= getFlashParam().getCursorEndId()) { log.info("Flushing_{},{}",this.getClass().getName(), JsonUtils.toJson(getFlashParam())); List sourceList = getSourceList(); if (CollectionUtils.isEmpty(sourceList)) { refreshCursor();//防止物理删除造成的空洞,所以需要更新游标起始位置 continue; } // 更新游标起始位置 refreshCursor(); // 组装目标Canal数据 List canalDataList = assembleCanalData(sourceList); if (CollectionUtils.isEmpty(canalDataList)) { return; } // 基于Canal数据刷数 flash(canalDataList); } } private void initCursor() { Long cursorStartId = queryCursorStartId(); Long cursorEndId = queryCursorEndId(); getFlashParam().setCursorStartId(Objects.isNull(cursorStartId) ? 0L : cursorStartId); getFlashParam().setCursorEndId(Objects.isNull(cursorEndId) ? 0L : cursorEndId); } private void refreshCursor() { getFlashParam().setCursorStartId(getFlashParam().getCursorStartId() + defaultLimit()); } @Data public static class FlashParam { private Date start; // 开始时间 private Date end; // 结束时间 private List noList; // 单号列表 private Long cursorStartId; // 游标起始Id private Long cursorEndId; // 游标结束Id private String monitorKey = Strings.EMPTY; // 基于Redis实现监控key public Boolean empty() { return cursorStartId == 0L && cursorEndId == 0L; } } private void init(FlashParam flashParam) { flashParamThreadLocal.set(flashParam); } /** * 查询起始游标ID * @return */ protected abstract Long queryCursorStartId(); /** * 查询结束游标ID * @return */ protected abstract Long queryCursorEndId(); protected Boolean isSharding() { return Boolean.FALSE; } /** * 是否处理非会员数据 * * @return */ protected Boolean isHandleNonVipData() { return Boolean.FALSE; } /** * 【暴露接口】开始刷数 * * @param flashParam */ public void startFlush(FlashParam flashParam) { try { init(flashParam); monitor("刷数中"); flash(); monitor("刷数结束"); } finally { flashParamThreadLocal.remove(); } } private void monitor(String tips) { if(!StringUtils.isEmpty(getFlashParam().getMonitorKey())){ String flashKey = flashKey(); String message = tips + OrderDateUtils.formatYYMMDD(new Date()); String redisMonitorKey = String.format("%s_%s",getFlashParam().getMonitorKey(),flashKey); log.info("{}-{}",redisMonitorKey,message); RedisStringUtil.setValue(redisMonitorKey, message, 30L, TimeUnit.DAYS); } } private void flash() { if (isSharding()) { shardingExec(); } else { innerExec(); } } private String flashKey() { String key = String.format("Flash_%s", this.getClass().getName()); if (!CollectionUtils.isEmpty(getFlashParam().getNoList())) { key = key + "_" + getFlashParam().getNoList().get(0);// 取第一个简单标识一下 } return key; } /** * 分表执行 */ protected void shardingExec() { List shardingValueList = ShardingUtils.shardingValueList(isHandleNonVipData()); String no = Strings.EMPTY; List noList = getFlashParam().getNoList(); if(!CollectionUtils.isEmpty(noList) && noList.size() == 1){ String tableIndexByNo = ShardingHelper.getTableIndexByNo(noList.get(0)); // 根据单号获取分表位置 if(shardingValueList.contains(tableIndexByNo)){ no = noList.get(0); }else { log.info("忽略，{}",noList); return; } } for (String shardingValue : shardingValueList) { try (HintManager hintManager = HintManager.getInstance()) { OfflineOrderHit hit = new OfflineOrderHit(); if(!StringUtils.isEmpty(no)){ hit.setDefineNo(no); }else { hit.setQueryHit(QueryHit.builder().seq(shardingValue).build()); } OfflineOrderTableShardingHintAlgorithm.setHintManager(hintManager, hit); innerExec(); } // 指定了单号,就跳出,避免无效循环 if(!StringUtils.isEmpty(no)){ break; } } } } ``` # 接口超时治理 > 接口超时治理 ### 快速响应 [Section titled “快速响应”](#快速响应)  ### 1. 问题诊断专题（深度分析） [Section titled “1. 问题诊断专题（深度分析）”](#1-问题诊断专题深度分析) **服务维度超时分析：** 通过对504超时日志的细致梳理，我们需要构建一个多维度的服务超时画像。首先，按服务划分超时频次，识别出高风险服务。例如，可以建立一个热力图，纵轴为服务名称，横轴为时间段，用颜色深浅表示超时严重程度。这种可视化方法能直观地展现服务的性能波动特征。 **进一步，我们需要对每个服务的超时特征进行详细剖析：** * 超时发生的时间分布 * 超时的请求类型与接口特征 * 超时前后的系统负载情况 * 资源消耗（CPU、内存、网络）的关联性 通过这种深度分析，我们可以精准定位导致服务超时的潜在因素，为后续的优化提供数据支撑。 ### 2. 技术攻坚（根因诊断） [Section titled “2. 技术攻坚（根因诊断）”](#2-技术攻坚根因诊断) **链路追踪与性能分析：** 我们将采用全链路性能追踪技术，构建端到端的请求链路视图。这不仅仅是简单地记录日志，而是要建立一个能够还原请求完整生命周期的追踪系统。 **具体实施路径：** * 引入分布式追踪组件（如Skywalking、Zipkin） * 为每个请求生成唯一标识，实现请求全链路追踪 * 记录每个服务节点的处理时间、资源消耗 * 构建请求处理的关键路径分析模型 **通过这种细粒度的链路分析，我们可以：** * 精确定位性能瓶颈 * 识别服务间依赖关系 * 量化每个服务节点的性能开销 * 发现潜在的性能优化点 ### 3. 治理路径规划（系统性方案） [Section titled “3. 治理路径规划（系统性方案）”](#3-治理路径规划系统性方案) **短期应急机制：** 超时快速处理不仅仅是技术问题，更是业务连续性的保障。我们需要设计一个多层次的应急响应体系： **告警机制：** * 实时监控超时阈值 * 建立多级告警通道（钉钉、短信、邮件） * 根据超时严重程度触发不同级别的告警 **快速恢复策略：** * 自动降级：当某服务持续超时，自动切换到降级服务 * 流量削峰：通过网关实现精准的流量控制 * 故障隔离：快速隔离故障节点，preventing雪崩效应 ### 4. 性能监控体系 [Section titled “4. 性能监控体系”](#4-性能监控体系) **SLA指标设计：** 我们将制定一个多维度的服务等级协议(SLA)评估体系： **核心指标：** * 响应时间P99（99%请求的响应时间） * 可用性：服务可用率>99.9% * 错误率：低于0.1% * 吞吐量：峰值流量下的系统处理能力 **评估机制：** * 每日/周/月性能报告 * 季度性能评估 * 建立性能改进奖励机制 ### 5. 长期架构演进 [Section titled “5. 长期架构演进”](#5-长期架构演进) **微服务架构优化：** * 服务拆分：基于业务domain进行更细粒度拆分 * 组件解耦：减少服务间强依赖 * 引入服务治理平台 * 构建可观测的系统架构 通过这套comprehensive的治理方案，我们将从根本上提升系统的性能stability和可靠性。  # 数据迁移最佳实践 > 数据迁移最佳实践  最近，在忙数据迁移的事情。在数据迁移的过程中，有一些最佳实践。分享一下 1. 一定要基于游标去刷数,在游标的基础下可以过滤条件 2. 游标的获取在数据量比较小的时候可以实时获取,如果数据量比较大,建议在执行脚本前初始化好 3. 刷数过程中,监控资源使用情况。注意告警 刷数逻辑可以基于[flash-data](/software-engineer/best-practices/general-ability/flash-data)来说实现 # 从哪些地方可以优化现有系统? > 从哪些地方可以优化现有系统? ### 写这篇内容的背景 [Section titled “写这篇内容的背景”](#写这篇内容的背景) 业务发展,需要承载更多的流量。对主流程做了梳理,并提出优化目标 ### 优化前系统的一些表现 [Section titled “优化前系统的一些表现”](#优化前系统的一些表现) * 部分接口耗时过长 * 频繁有慢SQL告警 ### 策略 [Section titled “策略”](#策略) 优先解决主流程的问题,后面再去逐步解决非核心流程的问题。 ### 定位方法 [Section titled “定位方法”](#定位方法) * 根据SkyWalking找出耗时长的接口,根据链路再找出耗时长的操作 * 根据慢SQL定位到具体的代码行 * 走查代码。我自己在做这件事情的时候,核心接口的代码大概都过了一遍 ### 具体优化措施 [Section titled “具体优化措施”](#具体优化措施) * 慢SQL * 索引: 在DB层面,主要是通过explain解释计划查看是否有使用到索引。如果在有索引的情况下存在没有使用到索引的情况,要检查自己的SQL是否编写的正确,因为有些写法会让索引失效。如果没有索引,就直接加索引。加索引尽量在区分度高的字段加,如果区分度不高,对DB来说反而是一种压力。 * 业务: 业务需求是否合理。最常见的就是api请求响应日志、数据导出、日志等场景,要和业务沟通有效期 * 分批: CURD操作大量数据,应该分批操作。其实很简单,CURD都可以加limit最终限制下要操作的数据条数 * 缓存。堆内缓存、堆外缓存 * 索引 * 并行 * [限流](/software-engineer/best-practices/custom-annotations-to-limit-and-downgrade) * 大接口拆分 * 分库 * 分表。水平分表(平铺,要防止数据倾斜)、垂直拆分(冷热数据分离) * 服务拆分 * 动态扩缩容 * 重构 * 冗余存储 * 如果有锁,需要控制锁粒度 * 池化 优化的基本要求是无感,不能影响到已有的业务 ### 还有很多其他的优化思路 [Section titled “还有很多其他的优化思路”](#还有很多其他的优化思路) 1. 项目中有很多接口的职责不清晰,即有的接口多负责了与接口定义不相关事情,这部分应该做拆分,尽量让接口功能清晰,职责分离。 2. 项目中的api服务、定时任务、消息消费,严重耦合在一个项目中。应该做进一步拆分,公共部分只需要通过公共依赖来解决。最佳实践,我之前做过一个跨境电商系统,项目分的很细。toC是SOA服务,toB是MSOA服务。在SOA服务和MSOA服务又做了进一步拆分,分为聚合服务和原子服务。job是一个单独的服务,消息消费是一个单独的服务。 > 这样做的好处是: > > * 扩缩容的粒度可以控制的更细,不必因为某一个功能点需要承载大流量而把不需要扩容的功能也扩容了。因此,资源可以得到更加高效和合理的应用 > * 服务架构可以驱使业务和功能接口设计更加合理。 > * 单元测试覆盖率可以得到有效提升,代码质量渐渐可控 > * 在做升级或者重构等技术优化,可以直接聚焦到一个点,而不用担心会影响到其他地方 > > 弊端也是有的: > > * 运维成本高,对网络和资源规划有一定的要求 > * 因为拆分多个系统,系统之间的交互开始变得灵活且复杂。因某些业务对数据一致性有要求,就会有些兜底方案,比如使用MQ来解耦系统时会使用到的本地消息表等 3. 校验前置。将校验前置的目的是让线程尽快的结束,将资源快点释放,以此来提升系统的处理能力。还有另外一点,将校验前置,也可以尽量减少DB资源占用。在开发一个业务功能时,需要有一定的思考,如果做一步校验一步,虽然过程思路清晰,但是对于并发较高的项目来说是一种负担 4. 重构。在上面提到过,如果通过很多手段发现达不到预期目标,就要考虑重构。如果重构就有很多发挥空间,可以引入新的组件、使用新的技术等等。重构的基本要求是不影响现有功能。 5. [全链路超时梳理](/software-engineer/best-practices/timeout) # 移除图片中的元信息 > 移除图片中的元信息 因之前给奶奶的照片丢失了,需要重新给奶奶发送一些照片,考虑到未经处理过的照片含有GPS等元信息,涉及到隐私,故需要找工具清除这些元信息 在网上检索了一些工具,很麻烦,然后突然想到,是否可以写代码解决这个问题,于是我就找了[AI](/ai#claude)帮忙生成,2分钟就解决了我的问题,比在网上检索一堆信息快多了 脚本 ```bash # pip3 install Pillow import os from PIL import Image import sys def remove_metadata(image_path): try: # 打开图片 image = Image.open(image_path) # 创建一个新的图像,不包含元数据 data = list(image.getdata()) image_without_exif = Image.new(image.mode, image.size) image_without_exif.putdata(data) # 保存新图像 filename = os.path.splitext(image_path) new_filename = f"{filename[0]}1_{filename[1]}" image_without_exif.save(new_filename) print(f"已移除元数据并保存为: {new_filename}") except Exception as e: print(f"处理 {image_path} 时出错: {str(e)}") def process_directory(directory): image_extensions = ('.png', '.jpg', '.jpeg', '.gif', '.bmp', '.tiff') for root, dirs, files in os.walk(directory): for file in files: if file.lower().endswith(image_extensions): image_path = os.path.join(root, file) remove_metadata(image_path) if __name__ == "__main__": if len(sys.argv) != 2: print("使用方法: python script.py <图片目录路径>") else: directory_path = sys.argv[1] if os.path.isdir(directory_path): process_directory(directory_path) else: print("提供的路径不是一个有效的目录") ``` 依赖安装 ```bash pip3 install Pillow ``` 执行 ```bash python3 remove_meta.py <图片目录路径> ``` # ShardingJDBC实践 > ShardingJDBC实践 ### 背景 [Section titled “背景”](#背景) 因业务高速发展,线下渠道订单量高速增长,订单量每天50w+,据此计算,一个月的订单量有1500w+,一年就有1.8亿数据。 这已远远超过MySQL单表的存储极限。故急需分表 ### 技术方案 [Section titled “技术方案”](#技术方案) 根据自己前几年调研过的技术方案，选择使用ShardingJDBC来实现 > 各方案优缺点不再此展示,感兴趣的可以自行探索 ### 具体接入代码 [Section titled “具体接入代码”](#具体接入代码) 我们的ORM工具使用的是mybatis-plus,并且结合了多数据源,所以这次接入是在该背景下接入sharding-jdbc。如果需要单独接入sharding-jdbc可以自己截取部分粘贴到自己项目 依赖: ```xml org.apache.shardingsphere sharding-jdbc-spring-boot-starter 4.1.1 com.baomidou mybatis-plus-boot-starter 3.4.3.4 com.baomidou dynamic-datasource-spring-boot-starter 3.3.1 ``` yml配置: ```yml spring: shardingsphere: datasource: names: moatkon_sharding moatkon_sharding: url: jdbc:mysql://ip:port/moatkon_db?allowMultiQueries=true&serverTimezone=Asia/Shanghai&useSSL=false&connectTimeout=2000&socketTimeout=60000 #开发 username: xxxx password: xxxx type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver sharding: tables: table1: actual-data-nodes: moatkon_sharding.table1_$->{0..127} table-strategy: hint: algorithm-class-name: com.moatkon.MoatkonShardingHintAlgorithm table2: actual-data-nodes: moatkon_sharding.table2_$->{0..127} table-strategy: hint: algorithm-class-name: com.moatkon.MoatkonShardingHintAlgorithm props: sql.show: false max.connections.size.per.query: 50 # 这个可以解决启动慢的问题,在后续的版本,sharding-jdbc优化了此问题,在4.1.1需要配置这个参数 datasource: dynamic: primary: moatkon_ds strict: false datasource: moatkon_ds: url: jdbc:mysql://ip:port/moatkon_db?allowMultiQueries=true&serverTimezone=Asia/Shanghai&useSSL=false&connectTimeout=2000&socketTimeout=60000 username: xxxxx password: xxxxx driver-class-name: com.mysql.cj.jdbc.Driver type: com.alibaba.druid.pool.DruidDataSource druid: initial-size: 40 min-idle: 40 max-active: 100 max-wait: 10000 wall: multi-statement-allow: true druid: time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 FROM DUAL ``` Spring配置: ```java import com.baomidou.dynamic.datasource.DynamicRoutingDataSource; import com.baomidou.dynamic.datasource.provider.AbstractDataSourceProvider; import com.baomidou.dynamic.datasource.provider.DynamicDataSourceProvider; import com.baomidou.dynamic.datasource.spring.boot.autoconfigure.DataSourceProperty; import com.baomidou.dynamic.datasource.spring.boot.autoconfigure.DynamicDataSourceAutoConfiguration; import com.baomidou.dynamic.datasource.spring.boot.autoconfigure.DynamicDataSourceProperties; import org.apache.shardingsphere.shardingjdbc.jdbc.adapter.AbstractDataSourceAdapter; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.SpringBootConfiguration; import org.springframework.boot.autoconfigure.AutoConfigureBefore; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.Lazy; import org.springframework.context.annotation.Primary; import javax.annotation.Resource; import javax.sql.DataSource; import java.util.Map; @Configuration @AutoConfigureBefore({DynamicDataSourceAutoConfiguration.class,SpringBootConfiguration.class}) public class DataSourceConfiguration { // 分表数据源名称 private static final String SHARDING_DATA_SOURCE_NAME = "sharding"; //动态数据源配置项 @Autowired private DynamicDataSourceProperties properties; /** * shardingjdbc有四种数据源，需要根据业务注入不同的数据源 * *

1. 未使用分片, 脱敏的名称(默认): shardingDataSource; *

2. 主从数据源: masterSlaveDataSource; *

3. 脱敏数据源：encryptDataSource; *

4. 影子数据源：shadowDataSource */ @Lazy @Resource(name = "shardingDataSource") AbstractDataSourceAdapter shardingDataSource; @Bean public DynamicDataSourceProvider dynamicDataSourceProvider() { Map datasourceMap = properties.getDatasource(); return new AbstractDataSourceProvider() { @Override public Map loadDataSources() { Map dataSourceMap = createDataSourceMap(datasourceMap); // 将 shardingjdbc 管理的数据源也交给动态数据源管理 dataSourceMap.put(SHARDING_DATA_SOURCE_NAME, shardingDataSource); return dataSourceMap; } }; } /** * 将动态数据源设置为首选的 * 当spring存在多个数据源时, 自动注入的是首选的对象 * 设置为主要的数据源之后，就可以支持shardingjdbc原生的配置方式了 */ @Primary @Bean public DataSource dataSource(DynamicDataSourceProvider dynamicDataSourceProvider) { DynamicRoutingDataSource dataSource = new DynamicRoutingDataSource(); dataSource.setPrimary(properties.getPrimary()); dataSource.setStrict(properties.getStrict()); dataSource.setStrategy(properties.getStrategy()); dataSource.setProvider(dynamicDataSourceProvider); dataSource.setP6spy(properties.getP6spy()); dataSource.setSeata(properties.getSeata()); return dataSource; } } ``` 当且仅当需要使用分表时才需要切换数据源: `@DS(DataSourceConfiguration.SHARDING_DATA_SOURCE_NAME)` > `@DS` 是dynamic-datasource-spring-boot-starter的注解,用于切换动态数据源 ### 分表策略 [Section titled “分表策略”](#分表策略) 因为线下渠道的用户有非会员和会员。所以我们的分表策略是，非会员按照年月归档,会员用户按照用户id分表。我们期望的是会员用户可以通过用户ID和订单号都可以定位到具体的分表,所以我们对自己内部订单号做了一些设计。 规则是: 雪花算法 + 用户ID(后3位) 通过此设计就可以达到通过用户ID和订单号都可以定位到具体分表 #### 分表算法 [Section titled “分表算法”](#分表算法) 因为我们的使用场景需要按年月归档非会员订单和按照用户维度进行分表,所以我们采用了灵活性非常之高的强制分片算法,实现HintShardingAlgorithm即可。 com.moatkon.MoatkonShardingHintAlgorithm ```java import com.google.common.collect.Lists; import java.util.ArrayList; import java.util.Collection; import java.util.Date; import java.util.List; import java.util.Optional; import lombok.extern.slf4j.Slf4j; import org.apache.shardingsphere.api.hint.HintManager; import org.apache.shardingsphere.api.sharding.hint.HintShardingAlgorithm; import org.apache.shardingsphere.api.sharding.hint.HintShardingValue; import org.springframework.stereotype.Component; @Slf4j @Component public class MoatkonShardingHintAlgorithm implements HintShardingAlgorithm { @Override public Collection doSharding(Collection collection, HintShardingValue hintShardingValue) { // 分表结果 ArrayList shardingResult = Lists.newArrayList(); String logicTableName = hintShardingValue.getLogicTableName(); Collection values = hintShardingValue.getValues(); Optional first = values.stream().findFirst(); if (!first.isPresent()) { throw new RuntimeException( String.format("强制分片无数据,请检查使用方式!!! table:%s", logicTableName)); } MoatkonHit moatkonHit = first.get(); // 获取订单号 String orderNo = moatkonHit.getOrderNo(); // 获取用户Id后三位 String userIdLast3 = ShardingHelper.fetchLast3UserId(orderNo); if ("NaN".equals(userIdLast3)) { // NOT_MEMBER_ORDER_SUFFIX 非会员订单号的后三位是”NaN“,表示非会员 Date createTime = moatkonHit.getCreateTime(); String position = ShardingHelper.archiveByYearMonth(createTime); // 输出年月的字符串,例如 202401,202412之类的 shardingResult.add(logicTableName + "_" + position); // 拼接物理表名 return shardingResult; } String position = ShardingHelper.splitByUserIdLast3Str(userIdLast3); shardingResult.add(logicTableName + "_" + position); return shardingResult; } private static final List tableList = Lists.newArrayList("table1","table2"); /** * 有使用强制分表的地方,使用这个方法可以使用该算法。 注意: 这是使用了强制分片策略才会这么使用。如果是使用其他分表策略则不需要,按照官方文档接入即可 */ public static void setHintManager(HintManager hintManager, MoatkonHit moatkonHit) { for (String table : tableList) { hintManager.addTableShardingValue(table, moatkonHit); } } } ``` #### 数据倾斜问题 [Section titled “数据倾斜问题”](#数据倾斜问题) 主要是采用 Hash一致性算法 + 虚拟表 来解决。 ##### 为什么采用虚拟表? [Section titled “为什么采用虚拟表?”](#为什么采用虚拟表) 避免数据倾斜问题,如果出现了数据倾斜问题,而又没有采用虚拟表,大概率会将所有的数据都重新跑一遍新的分表算法(这个新的分表算法如果还没有采用虚拟表,估计也只能支撑一段时间,并不能彻底解决问题),这个成本太大了 ##### 实现原理 [Section titled “实现原理”](#实现原理)  ##### 算法实现 [Section titled “算法实现”](#算法实现) 1024张虚拟表,128张物理表 ```java public static String splitByUserIdLast3Str(String userId) { // 分片键hash 散列 HashCode hashCode = Hashing.murmur3_128().hashString(userId, StandardCharsets.UTF_8); //传入数据主键id(分片片键)和集群中机器数量buckets，返回一个固定的数字，表示数据应当落在第几个机器(虚拟表)上。 int virtualTable = Hashing.consistentHash(hashCode, 1024); // 一致性hash算法 // 计算物理表 int physicsTable = virtualTable / (1024 / 128); // 1024个环节/128表示可 物理表可使用的范围 8个表冗余，每8个表对应一个虚拟表,即步长 return String.valueOf(physicsTable); // 返回映射到的物理表 } ``` # SpringBoot集成多数据源 > SpringBoot集成多数据源 ```xml com.baomidou dynamic-datasource-spring-boot-starter 4.3.0 ``` 原来的配置: ```yaml # spring配置 spring: # 数据源配置 datasource: url: jdbc:mysql://localhost:3306/auto_works?useUnicode=true&useSSL=false&characterEncoding=utf8&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver # 连接池配置 druid: initial-size: 5 max-wait: 60000 max-active: 10 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false ``` 多数据源的配置: ```yaml # spring配置 spring: # 数据源配置 datasource: # 和原来的配置比对可以得出,这个层级的数据源不变 dynamic: # 追加一个dynamic的配置,在这里面配置多数据源 primary: master strict: false datasource: master: url: jdbc:mysql://localhost:3306/auto_works?useUnicode=true&useSSL=false&characterEncoding=utf8&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver # 连接池配置 druid: initial-size: 5 max-wait: 60000 max-active: 10 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false another: url: jdbc:mysql://localhost:3306/auto_works2?useUnicode=true&useSSL=false&characterEncoding=utf8&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver # 连接池配置 druid: initial-size: 5 max-wait: 60000 max-active: 10 time-between-eviction-runs-millis: 60000 min-evictable-idle-time-millis: 300000 validation-query: SELECT 1 test-while-idle: true test-on-borrow: false test-on-return: false ``` 使用方法: ```java @DS("master") @DS("another") ``` # 如何设置超时 > 如何设置超时 在平时的项目中,有很多网络之间的调用,我们通常都会设置一些超时时间,那么你有考虑过为什么要设置超时时间吗? 或者我们反过来想,如果不设置超时时间会发生什么? 如果不设置超时时间会发生: 1. 调用方会因为一直获取不到响应,一直在阻塞等待而不能处理其他请求 2. 长时间占用资源,如果继续有很多的请求过来就会导致内存不够,会发生频繁的GC,最终可能会导致OOM 3. 会达到连接上限,导致机器再也处理不了其他请求。即其他功能也被拖累了 如果设置了超时会有哪些好处: 1. 从无限等待变为有限等待,故可控。可控是软件一个重要的衡量指标。 2. 资源可以及时释放,不至于一直占用而影响软件其他正常的功能。 3. 可以更合理的分配资源,缩小影响范围 #### 有哪些超时可以设置呢? [Section titled “有哪些超时可以设置呢?”](#有哪些超时可以设置呢) * 连接超时 connectTimeout * 读取超时 readTimeout #### 网络请求的工具有很多,都怎么设置超时呢? [Section titled “网络请求的工具有很多,都怎么设置超时呢?”](#网络请求的工具有很多都怎么设置超时呢) ##### Feign [Section titled “Feign”](#feign) ###### Feign全局设置 [Section titled “Feign全局设置”](#feign全局设置) 全局设置 ```yaml feign: client: config: default: connectTimeout: 60000 readTimeout: 10000 ``` ###### 指定特定的FeignClient [Section titled “指定特定的FeignClient”](#指定特定的feignclient) ```java @FeignClient(value = "moatkon",contextId ="moatkon-feign-client") public interface MoatkonService { } ``` 设置特定的FeignClient超时 ```yaml feign: client: config: moatkon-feign-client: connectTimeout: 60000 readTimeout: 10000 ``` ##### OkHttp [Section titled “OkHttp”](#okhttp) > 这里是以okhttps3为准的 Github: [okhttp](https://github.com/square/okhttp) OkHttp官网: [square.github.io/okhttp/](square.github.io/okhttp/) 示例代码: [ConfigureTimeouts.java](https://github.com/square/okhttp/blob/master/samples/guide/src/main/java/okhttp3/recipes/ConfigureTimeouts.java) OkHttp设置超时 ```java private final OkHttpClient client; public ConfigureTimeouts() throws Exception { client = new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) // 超时时间 .writeTimeout(10, TimeUnit.SECONDS) // 写超时时间 .readTimeout(30, TimeUnit.SECONDS) // 读超时时间 .build(); } ``` 每一种超时的官方解释(英): > [OkHttpClient](https://github.com/square/okhttp/blob/00ac57e8c3a7920e7752f213d526a776415bc457/okhttp/src/main/kotlin/okhttp3/OkHttpClient.kt#L589) * The **write timeout** is applied for individual write IO operations. The default value is 10 * The **read timeout** is applied to both the TCP socket and for individual read IO operations including on \[Source] of the \[Response]. The default value is 10 seconds. * The **connect timeout** is applied when connecting a TCP socket to the target host. The default value is 10 seconds. ##### Gateway网关全局超时配置 [Section titled “Gateway网关全局超时配置”](#gateway网关全局超时配置) ```yaml spring: cloud: gateway: httpclient: connect-timeout: 45000 #毫秒 response-timeout: 10000 pool: type: elastic ``` 网关中路由的超时配置 ```yaml - id: moatkon_service uri: https://moatkon.com predicates: - name: Path args: pattern: /delay/{timeout} metadata: response-timeout: 200 connect-timeout: 200 ``` * connect-timeout是指网关到目标路由的连接超时时间 * response-timeout是指服务给网关返回响应的时间 ##### 服务端超时 [Section titled “服务端超时”](#服务端超时) 外部连接与gateway建立连接的超时时间 ```yaml server: netty: connection-timeout: 60000 ``` ##### 内嵌Tomcat超时 [Section titled “内嵌Tomcat超时”](#内嵌tomcat超时) ```yaml server: tomcat: accept-count: 100 threads: max: 200 max-connections: 8192 connection-timeout: 60000 keep-alive-timeout: 60000 max-keep-alive-requests: 100 ``` ##### URLConnection [Section titled “URLConnection”](#urlconnection) > 很原生的写法,实际项目开发中几乎不使用,所以这里只做展示 URLConnection设置超时 ```java URL url = new URL(url); HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection(); urlConnection.setReadTimeout(5000); urlConnection.setConnectTimeout(5000); ``` ##### alibaba DruidDataSource通用配置 [Section titled “alibaba DruidDataSource通用配置”](#alibaba-druiddatasource通用配置) [DruidDataSource配置,属性列表](https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8) 通用xml配置 ```xml ``` SpringBoot可以在yaml中配置,在yaml中配置,更加简洁 #### 最后 [Section titled “最后”](#最后) 可以设置超时的地方太多了,不可能都列完,哈哈 上面只是列出了常用的一些超时。我们只需要知道这个就行,在平时做研发时,要考虑到这些 # Redis > Redis ### 1.Redis基础 [Section titled “1.Redis基础”](#1redis基础) #### 1.1 Redis有哪些数据结构 [Section titled “1.1 Redis有哪些数据结构”](#11-redis有哪些数据结构) * String * Hash * List * Set * SortedSet(也称zset) #### 1.2 Redis数据结构详细说明 [Section titled “1.2 Redis数据结构详细说明”](#12-redis数据结构详细说明) ##### String [Section titled “String”](#string) 内部实现: 内部的实现是通过 SDS(Simple Dynamic String )来存储的。SDS 类似于 Java 中的 ArrayList，可以通过预分配冗余空间的方式来减少内存的频繁分配 ```c struct sdshdr { long len; long free; char buf[]; }; ``` 使用SDS的优点: 1. 获取字符串长度时间复杂度是O(1) 2. 二进制安全 > **什么是二进制安全？**\ > 通俗地讲，C语言中，用’0’表示字符串的结束，如果字符串本身就有’0’字符，字符串就会被截断，即非二进制安全；若通过某种机制，保证读写字符串时不损害其内容，则是二进制安全。 > > **SDS是怎么解决的?**\ > SDS使用len属性的值判断字符串是否结束，所以不会受’\0’的影响。 3. 杜绝缓冲区溢出 > **C字符串会溢出的原因**\ > 字符串的拼接操作是使用十分频繁的，在C语言开发中使用`char *strcat(char *dest,const char *src)`方法将src字符串中的内容拼接到dest字符串的末尾。由于C字符串不记录自身的长度，所以**strcat方法已经认为用户在执行此函数时已经为dest分配了足够多的内存**，足以容纳src字符串中的所有内容，而一旦这个条件不成立就会产生缓冲区溢出，会把其他数据覆盖掉。 比如用恶意的字符覆盖一些内容,就容易被攻击。这个就是常见的缓冲区溢出攻击 > > **SDS是怎么解决的?**\ > 与C字符串不同，SDS 的自动扩容机制完全杜绝了发生缓冲区溢出的可能性：当SDS API需要对SDS进行修改时，API会先检查 SDS 的空间是否满足修改所需的要求，如果不满足，API会自动将SDS的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改SDS的空间大小，也不会出现缓冲区溢出问题。 4. 内存重分配次数优化 > **空间预分配策略**\ > 因为 SDS 的空间预分配策略， **SDS字符串在增长过程中不会频繁的进行空间分配**。通过这种分配策略，SDS 将连续增长N次字符串所需的内存重分配次数从必定N次降低为最多N次。 > > **惰性空间释放机制**\ > 在SDS字符串缩短操作过程中， 多余出来的空间并不会直接释放，而是保留这部分空间，等待下次再用. 在更新字符串长度的过程中并没有涉及到内存的重分配策略，只是简单的修改sdshdr头中的len字段。 **总结:** SDS的结构还算是比较简单，Redis通过自己构建的SDS规避了传统C字符串潜在的性能问题，以及缓冲区溢出的风险，并且通过一系列策略以及数据结构的优化尽可能的节省了内存空间，此外，SDS为了和传统C字符串相兼容，在保存字符串的末尾也设置了空字符，使保存文本数据的SDS可以使用部分``库中的函数，而SDS自身也封装了一些修改字符串常见的操作，为Redis提供了简单可靠高性能的字符串操作API. String字符串应用场景: 1. 缓存功能 2. 计数器。实际的业务使用:在ads平台投放搜索广告时,批次号的自增，算一个计数,使用的incr 3. 分布式锁 4. 共享用户Session。实际的业务使用:在spring容器中将session存储改为redis就行,就会自动使用 ##### Hash [Section titled “Hash”](#hash) 是类似 Map 的一种结构，这个一般就是可以将结构化的数据，比如一个对象(前提是这个对象没嵌套其他的对象)给缓存在 Redis 里，然后每次读写缓存的时候，可以就操作 Hash 里的**某个**字段。(Hash可以只对某个字段修改) ##### List [Section titled “List”](#list) * 有序列表。通过 List 存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的东西 * 应用场景 * **基于 Redis 实现简单的高性能分页**。通过 lrange 命令，读取某个闭区间内的元素，可以基于 List 实现分页查询 * **简单的消息队列**。Redis的链表结构，可以轻松实现阻塞队列，可以使用左进右出的命令组成来完成队列的设计。比如：数据的生产者可以通过`lpush`命令从左边插入数据，多个数据消费者，可以使用Brpop命令阻塞的“抢”列表尾部的数据。基于异步消息队列List lpush-brpop(rpush-blpop) * 使用`rpush`和`lpush`操作入队列，lpop和rpop操作出队列。List支持多个生产者和消费者并发进出消息，每个消费者拿到都是不同的列表元素。但是当队列为空时，lpop和rpop会一直空轮训，消耗资源；所以引入阻塞读blpop和brpop(b代表blocking)，阻塞读在队列没有数据的时候进入休眠状态，一旦数据到来则立刻醒过来，消息延迟几乎为零。 > 如果线程一直阻塞在那里，Redis客户端的连接就成了闲置连接，闲置过久，服务器一般会主动断开连接，减少闲置资源占用，这个时候blpop和brpop或抛出异常， 所以在编写客户端消费者的时候要小心，如果捕获到异常，还要进行重试等操作处理异常。 * 缺点 * 做消费者确认ACK麻烦，不能保证消费者消费消息后是否成功处理(可能会有宕机或处理异常等)，通常需要维护一个Pending列表，保证消息处理确认。 * 不能重复消费，一旦消费就会被删除 * 不支持分组消费 ##### Set [Section titled “Set”](#set) 无序集合，会自动去重的那种 **应用场景**:\ 基于Set可以做交集、并集、差集的操作，比如交集，我们可以把两个人的好友列表整一个交集，看看俩人的共同好友是谁。等等 ##### Zset(也称SortedSet) [Section titled “Zset(也称SortedSet)”](#zset也称sortedset) 排序的Set，去重且可以排序，写进去的时候给一个分数，自动根据分数排序。 对于有序集合 ZSet 来说，每个存储元素相当于有两个值组成的，一个是有序集合的元素值，一个是排序值。 **应用场景** 1. 可以实现延时队列(根据分数来实现延时队列) 2. 排行榜 #### 1.3 Redis数据结构高级用法 [Section titled “1.3 Redis数据结构高级用法”](#13-redis数据结构高级用法) * **HyperLogLog**: 提供不精确的去重计数功能，比较适合用来做大规模数据的去重统计，例如统计 UV * **GEO**: 可以用来保存地理位置，并作位置距离计算或者根据半径计算位置等。业务场景:用Redis来实现附近的人、计算最优地图路径 * **BitMap**: 位图是支持按 bit 位来存储信息，Bitmap 类型非常适合二值状态统计的场景,例如可以用来实现 布隆过滤器(BloomFilter) #### 1.4 Redis其他知识 [Section titled “1.4 Redis其他知识”](#14-redis其他知识) * **Pipeline**: 可以批量执行一组指令，一次性返回全部结果，可以减少频繁的请求应答。 * **Lua**: Redis 支持提交 Lua 脚本来执行一系列的功能，原子性。用户积分、送优惠券之类的原子操作,要成功都成功 * **事务**: Redis 提供的不是严格的事务，Redis 只保证串行执行命令，并且能保证全部执行，**但是执行命令失败时并不会回滚**，而是会继续执行下去 * **Pub/Sub**:作简单的消息队列 * 优点: * 典型的广播模式，一个消息可以发布到多个消费者 * 多信道订阅，消费者可以同时订阅多个信道，从而接收多类消息 * 消息即时发送，消息不用等待消费者读取，消费者会自动接收到信道发布的消息 * 缺点: * 消息一旦发布，作为发送端的任务就结束了,至于消费端怎么样发送端是不管的。换句话就是发布时若客户端不在线，则消息丢失，不能寻回 * 不能保证每个消费者接收的时间是一致的 * 若消费者客户端出现消息积压，到一定程度，会被强制断开，导致消息意外丢失。通常发生在消息的生产远大于消费速度时 * 适用场景: Pub/Sub 模式不适合做消息存储，消息积压类的业务，而是擅长处理广播，即时通讯，即时反馈的业务。 ### 2. 使用缓存可能会出现的问题 [Section titled “2. 使用缓存可能会出现的问题”](#2-使用缓存可能会出现的问题) #### 2.1 缓存雪崩 [Section titled “2.1 缓存雪崩”](#21-缓存雪崩) A系统每天高峰期可以承受每秒1w个请求,其中被缓存承接过去9900个,但是有一天缓存宕机了,1w个请求全部打到数据库或者其他下游系统,导致数据库或者下游系统一个都起不来,都崩溃了。**如果系统没有预案,只能等这一波流量都过去之后,才能正常启动及恢复** **解决方案**: 在失效时间上加上随机时间，不让过多的缓存在同一个时间一起失效 或者 设置永不过期,有更新操作再更新就好了 #### 2.2 缓存击穿(击:有目的性的) [Section titled “2.2 缓存击穿(击:有目的性的)”](#22-缓存击穿击有目的性的) 缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，**当这个Key在失效的瞬间**，持续的大并发就**跳过**缓存，直接请求数据库，就像在一个完好无损的桶上瞬间凿开了一个洞。 **关键词**: 失效的瞬间,大量的请求打到数据库 **根据场景解决** 1. 若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。 2. 若缓存的数据更新不频繁，且**缓存刷新的整个流程耗时较少**的情况下，则可以采用基于Redis、Zookeeper等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。 3. 若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以**利用定时线程**在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。 #### 2.3 缓存穿透(绕过某些规则) [Section titled “2.3 缓存穿透(绕过某些规则)”](#23-缓存穿透绕过某些规则) 主要是一些恶意请求,比如说正常的业务Id是都是正数,但是有个黑客构造了恶意请求,全部使用负数来请求,那么这些负数在缓存中查询不到,就会穿透到数据库查询,给数据库造成了压力 **关键词**:\ 穿透,使用一些特殊的手段绕过缓存,直接查到数据库 **避免缓存穿透的利器之Bloom Filter**\ BloomFilter实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难 > 这部分误识别率,对于系统不会造成压力,所以可以很好的处理缓存击穿 **Bloom Filter原理**\ 当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，我们只要看看这些点是不是都是1就(大约)知道集合中有没有它了：如果这些点有任何一个0，则被检元素**一定不在**；如果都是1，则被检元素很可能在。这就是布隆过滤器的基本思想。 Bloom Filter跟单哈希函数BitMap不同之处在于：Bloom Filter使用了k个哈希函数，每个字符串跟k个bit对应。从而降低了冲突的概率 **Bloom Filter缺点** 1. 存在误判 2. 删除困难:一个放入容器的元素映射到bit数组的k个位置上是1，删除的时候不能简单的直接置为0，可能会影响其他元素的判断。可以采用Counting Bloom Filter **Bloom Filter场景** 1. **监控数据收集**: 在收集监控数据的时候, 有的监控数据量会很大, 需要检查一个监控项的名字是否已经被记录到DB过了, 如果没有的话就需要写入DB. 2. **爬虫URL**: 爬虫过滤已抓取的url就不再抓取，可用Bloom Filter过滤 3. **垃圾邮件过滤**: 如果用哈希表，每存储一亿个 email地址，就需要 1.6GB的内存**(用哈希表实现的具体办法是将每一个 email地址对应成一个八字节的信息指纹，然后将这些信息指纹存入哈希表，由于哈希表的存储效率一般只有 50%，因此一个 email地址需要占用十六个字节。一亿个地址大约要 1.6GB，即十六亿字节的内存)**。因此存贮几十亿个邮件地址可能需要上百 GB的内存。而Bloom Filter只需要哈希表 1/8到 1/4 的大小就能解决同样的问题。 ### 3. Redis使用场景 [Section titled “3. Redis使用场景”](#3-redis使用场景) 1. **热点数据缓存**\ 实际业务使用到的场景有:缓存订单不常用数据 2. **轻量级队列**\ 异步日志,订单操作日志记录 3. **分布式锁** ### 4. Redis持久化 [Section titled “4. Redis持久化”](#4-redis持久化) #### 4.1 RDB做镜像全量持久化(周期性的持久化) [Section titled “4.1 RDB做镜像全量持久化(周期性的持久化)”](#41-rdb做镜像全量持久化周期性的持久化) **原理(命令: bgsave)**:\ **fork**: fork是指redis通过创建子进程(该过程是阻塞的)来进行RDB操作\ **cow**: cow指的是copy on write > 子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来 **简单的描述原理**: RDB 是把内存中的数据集以快照形式写入磁盘，实际操作是通过 fork 子进程执行，采用二进制压缩存储； **场景**: 适合冷备 **优点**: * RDB对Redis的性能影响非常小,因为是fork了一个子线程来做的 * 数据恢复的时候速度比AOF来的快 **缺点**: * 因为是定时快照，数据丢失的多 * 如果快照文件很大,客户端会暂停几毫秒或者几秒 命令 save: 同步、阻塞 致命的问题，持久化的时候redis服务会阻塞(准确的说会阻塞当前执行save命令的线程，因为redis是单线程的，所以整个服务会阻塞)，不能继对外提供请求 copy on write Copy On Write(写时复制)是一种延迟复制的技术，用于在多个线程(或进程)之间共享资源时减少内存复制成本的。它的基本思想是，在创建拷贝或修改资源之前，不会真正的进行复制操作(懒汉模式)，而是共享同一份资源的只读副本，直到某个线程(或进程)试图修改资源时，才会对资源进行复制操作。 这种延迟复制的策略可以减少资源复制的开销，一定程度提高了性能和效率。 #### 4.2 AOF做增量持久化(append-only模式) [Section titled “4.2 AOF做增量持久化(append-only模式)”](#42-aof做增量持久化append-only模式) **简单的描述原理**: 以文本日志的形式记录 Redis 处理的每一个写入或删除操作。整体是通过一个后台的线程fsync来操作的。 Note Redis中的`fsync`是指文件同步操作，它用于将数据持久化到磁盘以确保数据的持久性。`fsync`的全称是”File Synchronization”，它通常用于将内存中的数据写入到持久性存储设备(如硬盘)中，以防止数据丢失或损坏。 在Redis中，`fsync`通常与持久性选项一起使用，以确保在发生故障或重新启动时，数据不会丢失。有两种常见的`fsync`选项： 1. `fsync always`：表示每次写入都会立即将数据同步到磁盘，提供最高级别的数据安全性，但可能会降低写入性能。 2. `fsync everysec`：表示Redis将每秒将数据同步到磁盘一次，这在一定程度上提高了写入性能，但在一秒内发生故障时可能会丢失一秒钟的数据。 这些选项可以通过Redis的配置文件进行设置，以满足不同应用场景的要求。 **场景**: 适合热备 **优点**: * 数据完整性比RDB高,最多丢失1s的数据 * append-only 追加写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。 **缺点**: * AOF文件比RDB还要大 * AOF开启后，Redis支持写的QPS会比RDB支持写的要低(*但是不影响Redis的高性能*) **其他**\ AOF的日志是通过一个叫非常可读的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复了，比如公司的实习生通过flushall清空了所有的数据，只要这个时候后台重写还没发生，你马上拷贝一份AOF日志文件，把最后一条flushall命令删了就完事了。 #### 4.3 RDB\&AOF都开启时 [Section titled “4.3 RDB\&AOF都开启时”](#43-rdbaof都开启时) RDB和AOF全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的。 ### 5. Redis为什么快？ [Section titled “5. Redis为什么快？”](#5-redis为什么快) 1. 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。它的数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1) 2. 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的 1. SDS简单动态字符串 2. 字典 3. 跳跃表。跳跃表是Redis特有的数据结构，就是在链表的基础上，增加多级索引提升查找效率 3. 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗； > 最新的一版已经是多线程了,利用现代计算机多核优势。网络处理是多线程，但是命令执行过程还是单线程处理的 4. 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM机制(类似Java的VM)，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求 > Redis 的 VM (虚拟内存)机制就是暂时把不经常访问的数据(冷数据)从内存交换到磁盘中，从而腾出宝贵的内存空间用于其它需要访问的数据(热数据)。通过VM功能可以实现冷热数据分离，使热数据仍在内存中、冷数据保存到磁盘。这样就可以避免因为内存不足而造成访问速度下降的问题。Redis 提高数据库容量的办法有两种：一种是可以将数据分割到多个 Redis Server上；另一种是使用虚拟内存把那些不经常访问的数据交换到磁盘上。「需要特别注意的是 Redis 并没有使用 OS 提供的 Swap，而是自己实现。」 > > Redis 为了保证查找的速度，只会将 value 交换出去，而在内存中保留所有的 Key。所以它非常适合 Key 很小，Value 很大的存储结构。如果 Key 很大，value 很小，那么vm可能还是无法满足需求。 5. 合理的线程模型。使用多路I/O复用模型，非阻塞IO > 多路I/O复用技术可以让单个线程高效的处理多个连接请求，而Redis使用epoll作为I/O多路复用技术的实现。并且，Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。 6. 合理的数据编码。Redis 支持多种数据类型，每种基本类型，可能对多种数据结构 提示 Redis的IO多路复用，Redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，然后到文件事件分派器，事件分派器将事件分发给事件处理器 **线程模型**\ 文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 Socket，根据 Socket 上的事件来选择对应的事件处理器进行处理。 > 最新版的Redis6支持多线程了，要看一下!!只是接收网络请求是多线程了，实际上Redis处理数据还是单线程 **文件事件处理器结构**:\ `多个 Socket` —> `IO 多路复用程序` —> `文件事件分派器` —> `事件处理器(连接应答处理器、命令请求处理器、命令回复处理器)` > 多个 Socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 Socket，会将 Socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。 ### 6.Redis内存块满时,会走淘汰策略 [Section titled “6.Redis内存块满时,会走淘汰策略”](#6redis内存块满时会走淘汰策略) #### 背景 [Section titled “背景”](#背景) 不管是本地缓存还是分布式缓存，为了保证较高性能，都是使用内存来保存数据，由于成本和内存限制，当存储的数据超过缓存容量时，需要对缓存的数据进行剔除。 `maxmemory` #### 有哪些策略 [Section titled “有哪些策略”](#有哪些策略) * FIFO: 淘汰**最早数据** * LRU(Least Recently Used): 剔除**最近最少使用** * allkeys-lru: 尝试回收最少使用的键(LRU)，使得新添加的数据有空间存放 * volatile-lru: 尝试回收最少使用的键(LRU)，但仅限于在过期集合的键,使得新添加的数据有空间存放。 * LFU(Least Frequently Used): 剔除**最近使用频率最低的数据** > LFU的全称是”Least Frequently Used”，它是一种缓存淘汰策略，用于确定在缓存空间不足时应该移除哪些项目。LFU策略的核心思想是淘汰那些被访问次数最少的项目，以腾出空间来存储更频繁访问的项目。这是一种基于访问频率的缓存淘汰策略。 * noeviction(不驱逐): `noeviction`是Redis中的一个配置选项，用于控制在内存不足时Redis服务器的行为。具体来说，`noeviction`选项决定了当Redis的内存使用达到了配置的最大内存限制时，服务器是否应该继续接受写入操作，还是应该拒绝写入操作以避免数据丢失 * `noeviction yes`：当Redis的内存使用达到最大内存限制时，服务器将拒绝任何写入操作，以确保数据的持久性和安全性。这意味着Redis不会自动删除任何数据以腾出空间，而是让客户端应用程序处理内存不足的情况。 * `noeviction no`：当Redis的内存使用达到最大内存限制时，服务器将尝试使用一种淘汰策略来删除一些数据，以腾出足够的空间来接受新的写入操作。Redis支持多种淘汰策略，例如LRU(Least Recently Used，最近最少使用)、LFU(Least Frequently Used，最不经常使用)等。使用这个选项，Redis将自动管理内存，但可能会删除一些数据以满足内存限制。 * allkeys-random: 回收随机的键使得新添加的数据有空间存放 * volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键 * volatile-ttl: 回收在过期集合的键，并且优先回收存活时间(TTL)较短的键,使得新添加的数据有空间存放。 ### 7.Redis高可用 [Section titled “7.Redis高可用”](#7redis高可用) #### Redis Sentinal [Section titled “Redis Sentinal”](#redis-sentinal) Redis Sentinal 着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务 它的作用是实现主从节点故障转移。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。 哨兵节点主要负责三件事情：**监控**主节点、**选主**、**通知**从节点和客户端。 为了减少误判的情况，哨兵在部署的时候不会只部署一个节点，而是用多个节点部署成哨兵集群(最少需要三台机器来部署哨兵集群)，通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。 ##### 哨兵的主要功能 [Section titled “哨兵的主要功能”](#哨兵的主要功能) * 集群监控：负责监控 Redis master 和 slave 进程是否正常工作。 * 消息通知：如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。 * 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。 * 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。 ##### 哨兵部署节点数 [Section titled “哨兵部署节点数”](#哨兵部署节点数) 哨兵必须用3️⃣个实例去保证自己的健壮性的，哨兵+主从并不能保证数据不丢失，但是可以保证集群的高可用。 ##### 经典的哨兵集群 [Section titled “经典的哨兵集群”](#经典的哨兵集群) ```plaintext - M1,S1 - R2,S2 - R3,S3 M: master主节点 S: 从节点 R: 另外的Redis节点,在同一网络中独立存在 ``` ##### 选举新的master策略 [Section titled “选举新的master策略”](#选举新的master策略) * 同等情况下，slave 复制的数据越多优先级越高 * slave 的 priority 设置的越低，优先级越高 * 相同的条件下 runid 越小越容易被选中 ##### 主从数据同步描述 [Section titled “主从数据同步描述”](#主从数据同步描述) 你启动一台slave 的时候，他会发送一个`psync`命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。 master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命令都发给slave。 ##### 数据传输的时候断网了或者服务器挂了怎么办啊？ [Section titled “数据传输的时候断网了或者服务器挂了怎么办啊？”](#数据传输的时候断网了或者服务器挂了怎么办啊) 传输过程中有什么网络问题啥的，会自动重连的，并且连接之后会把缺少的数据补上的(**psync指令会补数**) #### Redis Cluster [Section titled “Redis Cluster”](#redis-cluster) Redis Cluster 着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储 Redis Cluster功能: **负载均衡**、**故障切换**、**主从复制** Redis Cluster 使用分片机制，在内部分为16384个slot插槽，分布在所有master节点上，每个master节点负责一部分slot。数据操作时计算该key的CRC16结果再模16834来计算在哪个slot，由哪个master进行处理。数据的冗余是通过slave节点来保障。 进一步解释: **Redis Cluster包含多个主节点,去中心化，每个主节点负责管理一部分slot插槽**。主节点处理客户端的写入请求，并负责数据的分发。 ### 8.Redis双写一致性、并发竞争、线程模型 [Section titled “8.Redis双写一致性、并发竞争、线程模型”](#8redis双写一致性并发竞争线程模型) #### 双写一致性 [Section titled “双写一致性”](#双写一致性) 最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。 * 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。 * 更新的时候，先更新数据库，然后再删除缓存。不更新缓存的原因是你更新了可能很长一段时间没有被用到,所以白白浪费了系统资源，所以删掉最合适，等系统下一次用到就会触发计算然后缓存结果，这样可以节省系统资源,特别是对于那种需要经过大量计算才能得到结果的任务。反正无论如何保持一个原则，**用到缓存才去算缓存**，这也是懒加载的一个思想。CAP模式的lazy思想 > 不知道你发现了没有,上面这种处理方式是有问题的(下面有解释)。**先删缓存,再更新数据库就没有问题了** #### 不一致的场景 [Section titled “不一致的场景”](#不一致的场景) ##### 场景 [Section titled “场景”](#场景) 先更新数据库，再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致。 **解决方案**: 先删除缓存，再更新数据库。如果数据库更新失败了，那么数据库中是旧数据，缓存中是空的，那么数据**不会不一致**。因为读的时候缓存没有，所以去读了数据库中的旧数据，然后更新到缓存中 ##### 复杂的场景 [Section titled “复杂的场景”](#复杂的场景) 数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完成了数据库的修改。完了，数据库和缓存中的数据不一样了… **解决方案:** jvm队列。其实从场景描述中就可以感觉到如果顺序(串行)的来处理就不会出现这个问题。为什么使用jvm队列呢？因为速度足够快,会最大限度的让用户无感知 > * 这个一定要根据真实的线上场景数据测试好,不然会导致大量的请求超时 > * 当然不能紧着一个队列来,多搞几个队列，减少请求超时的情况(得确保同一个业务id hash到相同的队列上哈,不然数据还是乱的) #### 并发竞争 [Section titled “并发竞争”](#并发竞争) 这个也是线上非常常见的一个问题，就是多客户端同时并发写一个 key，可能本来应该先到的数据后到了，导致数据版本错了;或者是多客户端同时获取一个 key，修改值之后再写回去,只要顺序错了，数据就错了。(这就是典型的并发问题,用解决并发的方法来解决就好) **解决方案**: 使用zk分布式锁,Redis分布式锁等,谁获取到,谁操作 ### 9.做好保障 [Section titled “9.做好保障”](#9做好保障) * 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。 * 事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免数据库被打死。 * 事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 ### 10.为啥redis zset使用跳跃链表而不用红黑树实现 [Section titled “10.为啥redis zset使用跳跃链表而不用红黑树实现”](#10为啥redis-zset使用跳跃链表而不用红黑树实现) skiplist的复杂度和红黑树一样，而且实现起来更简单。 在并发环境下红黑树在插入和删除时需要rebalance，性能不如跳表。 ### 11.Redis [Section titled “11.Redis”](#11redis) * 与 Memcache 不同的是，Redis 采用单线程模式处理请求。这样做的原因有 2 个： * 一个是因为采用了非阻塞的异步事件处理机制； * 另一个是缓存数据都是内存操作 IO 时间不会太长，单线程可以避免线程上下文切换产生的代价。 * Redis 支持持久化，所以 Redis 不仅仅可以用作缓存，也可以用作 NoSQL 数据库 * 相比 Memcache，Redis 还有一个非常大的优势，就是除了 K-V 之外，还支持多种数据格式，例如 list、set、sorted set、hash 等。 * Redis 提供主从同步机制，以及 Cluster 集群部署能力，能够提供高可用服务 ### 12.Key失效机制 [Section titled “12.Key失效机制”](#12key失效机制) Redis 的 key 可以设置过期时间，过期后 Redis 采用主动和被动结合的失效机制，一个是和 Memcache一样在访问时触发被动删除，另一种是定期的主动删除。 #### Redis过期策略 [Section titled “Redis过期策略”](#redis过期策略) * 定期删除: 定期好理解，默认100ms就随机抽一些设置了过期时间的key，去检查是否过期，过期了就删了 * 惰性删除: 见名知意，惰性嘛，我不主动删，我懒，我等你来查询了我看看你过期没，过期就删了还不给你返回，没过期该怎么样就怎么样 总结 定期+惰性+内存淘汰 ### 13.关于Redis锁相关问题 [Section titled “13.关于Redis锁相关问题”](#13关于redis锁相关问题) * 死锁：设置过期时间 * 过期时间评估不好，锁提前过期：**守护线程(watch dog)，自动续期** * 使用分布式锁，如果锁内业务超时会怎么处理？使用守护线程自动处理, Redisson框架就实现了 * 锁被别人释放：锁写入唯一标识，释放锁先检查标识，再释放 * 如何解决主从切换后，锁失效问题？Redis 的作者提出一种解决方案，就是我们经常听到的 Redlock(红锁) ### 14. 有哪些缓存类型 [Section titled “14. 有哪些缓存类型”](#14-有哪些缓存类型) 1. 本地缓存 * Jvm堆中的缓存，可以使用LRUMap来实现,例如LRUMap * Ehcache > 优缺点: 本地缓存是内存访问，没有远程交互开销，性能最好，但是受限于单机容量，一般缓存较小且无法扩展。 2. 分布式缓存 > 优缺点: 可以解决本地缓存的问题,分布式缓存一般都具有良好的水平扩展能力，对较大数据量的场景也能应付自如。缺点就是需要进行远程请求，性能不如本地缓存。 3. 多级缓存 > 为了平衡本地缓存和分布式缓存,实际业务中一般采用多级缓存，本地缓存只保存访问频率最高的部分热点数据，其他的热点数据放在分布式缓存中 ### 15. 相关问题 [Section titled “15. 相关问题”](#15-相关问题) #### Redis大key如何处理? [Section titled “Redis大key如何处理?”](#redis大key如何处理) 大 key 并不是指 key 的值很大，而是 key 对应的 value 很大。 一般而言,String 类型的值大于 10 KB、Hash、List、Set、ZSet 类型的元素的个数超过 5000个就是大key了 ##### 如果存了大的value数据会带来哪些问题? [Section titled “如果存了大的value数据会带来哪些问题?”](#如果存了大的value数据会带来哪些问题) * 客户端超时阻塞。由于 Redis 执行命令是单线程处理，然后在操作大 key 时会比较耗时，那么就会阻塞 Redis，从客户端这一视角看，就是很久很久都没有响应。 * 引发网络阻塞。每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。 * 阻塞工作线程。如果使用 del 删除大 key 时，会阻塞工作线程，这样就没办法处理后续的命令。 * 内存分布不均。集群模型在 slot 分片均匀情况下，会出现数据和查询倾斜情况，部分有大 key 的 Redis 节点占用内存多，QPS 也会比较大。 ##### 如何找到大key？ [Section titled “如何找到大key？”](#如何找到大key) * `redis-cli --bigkeys` * 使用 SCAN 命令查找大 key。使用 SCAN 命令对数据库扫描，然后用 TYPE 命令获取返回的每一个 key 的类型。对于 String 类型，可以直接使用 STRLEN 命令获取字符串的长度。对于集合类型,就获取集合类型的元素个数了 * 第三方工具 RdbTools ##### 删除大key时要分批删除 [Section titled “删除大key时要分批删除”](#删除大key时要分批删除) 删除操作的本质是要释放键值对占用的内存空间，不要小瞧内存的释放过程。 释放内存只是第一步，为了更加高效地管理内存空间，在应用程序释放内存时，操作系统需要把释放掉的内存块插入一个空闲内存块的链表，以便后续进行管理和再分配。这个过程本身需要一定时间，而且会阻塞当前释放内存的应用程序。 所以，如果一下子释放了大量内存，空闲内存块链表操作时间就会增加，相应地就会造成 Redis 主线程的阻塞，如果主线程发生了阻塞，其他所有请求可能都会超时，超时越来越多，会造成 Redis 连接耗尽，产生各种异常。 * 删除大的Hash,先使用`hscan`获取一批,再使用`hdel`一个一个删 * 删除大的List,使用`ltrim`,每次删除少量元素 * 删除大的Set,先使用`sscan`获取一批,再使用`srem`一个一个删 * 删除大的ZSet,使用`zremrangebyrank`每次删除指定的top N个元素,这个N也是不要太大 ###### 大key异步删除 [Section titled “大key异步删除”](#大key异步删除) 从 Redis 4.0 版本开始，可以采用异步删除法，用 unlink 命令代替 del 来删除。 这样 Redis 会将这个 key 放入到一个异步线程中进行删除，这样不会阻塞主线程。 # MongoDB > MongoDB ### 背景 [Section titled “背景”](#背景) 公司有慢SQL,筛选出来后发现是MongoDB的。因为之前从来没有接触过MongoDB,所以正好可以趁着这次机会来学习下MongoDB ### 安装MongoDB [Section titled “安装MongoDB”](#安装mongodb) 我这边使用docker来安装 [官网教程](https://www.mongodb.com/compatibility/docker) ```sh docker run --name mongodb -d -p 27017:27017 -e MONGO_INITDB_ROOT_USERNAME=root -e MONGO_INITDB_ROOT_PASSWORD=123456 mongodb/mongodb-community-server:6.0-ubi8 ``` ### MongoDB 官方GUI工具 [Section titled “MongoDB 官方GUI工具”](#mongodb-官方gui工具) ### 使用MongoDB [Section titled “使用MongoDB”](#使用mongodb) [快速入门教程](https://www.runoob.com/mongodb/mongodb-create-database.html) MongoDB初见 ```sh # 创建数据库 # 当你使用 use 命令来指定一个数据库时，如果该数据库不存在，MongoDB将自动创建它。 # 如果此时执行show dbs 看不到数据库,需要添加数据才能看到 use db_moatkon # 创建集合,集合类似于关系数据库中的表 db.createCollection("moatkon_collection") # 此时执行show dbs就能看到了 > 注意: 在 MongoDB 中，集合只有在内容插入后才会创建，就是说，创建集合(数据表)后要再插入一个文档(记录)，集合才会真正创建。 # 查看当前数据库 db # 删除数据库 use db_moatkon db.dropDatabase() # 删除集合 db.moatkon_collection.drop() # 展示集合 show collections # 或者 show tables # 在 MongoDB 中，你不需要手动创建集合，当你插入文档时，MongoDB会自动创建集合。 db.moatkon_auto_createCollection.insertOne({"url" : "moatkon.com"}) ``` 创建索引,根据TTL过期; 索引关键字段必须是 Date 类型 ```sh db.moatkon_auto_createCollection.insertOne({"url" : "moatkon.com","createTime":new Date()}) db.moatkon_auto_createCollection.createIndex( { "createTime": 1 }, { expireAfterSeconds: 10 } ); // 这里演示的是10s过期 ``` > # MySQL > MySQL ### 1. 如何去分析一个MySQL语句 [Section titled “1. 如何去分析一个MySQL语句”](#1-如何去分析一个mysql语句) 使用Explain解释计划。 Explain解释计划有以下字段: * id: 表示查询中执行select子句或者操作表的顺序，id的值越大，代表优先级越高，越先执行 * select\_type: 表示 select 查询的类型，主要是用于区分各种复杂的查询，例如: 普通查询、联合查询、子查询等 * table: 输出行所引用的表 * partitions: 使用的哪个分区，需要结合表分区才可以看到 * type: 连接类型(“join type”),查询使用了何种类型，它在 SQL优化中是一个非常重要的指标,以下性能从好到坏依次是: `system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL` > * system: 系统表，少量数据，往往不需要进行磁盘IO > * const: 常量连接 > * eq\_ref: 主键索引(primary key)或者非空唯一索引(unique not null)等值扫描 > * ref: 非主键非唯一索引等值扫描 > * range: 范围扫描 > * index: 索引树扫描 > * ALL: 全表扫描(full table scan) > > `system > const > eq_ref > ref > range > index > ALL` * possible\_keys: 表示在MySQL中通过哪些索引，能让我们在表中找到想要的记录，一旦查询涉及到的某个字段上存在索引，则索引将被列出，但这个索引并不定一会是最终查询数据时所被用到的索引。`可能使用到的索引` * key: 区别于possible\_keys，key是查询中实际使用到的索引，若没有使用索引，显示为NULL. `实际的索引` * key\_len: 表示查询用到的索引长度(字节数)，原则上长度越短越好 * ref: 显示索引的哪一列被使用了，如果可能的话，是一个常数: 表示查询用到的索引长度(字节数)，原则上长度越短越好 * rows: 以表的统计信息和索引使用情况，估算要找到我们所需的记录，需要读取的行数. `只是一个估算值` * filtered: 这个是一个百分比的值，表里符合条件的记录数的百分比。简单点说，这个字段表示存储引擎返回的数据在经过过滤后，剩下满足条件的记录数量的比例 * Extra: 不适合在其他列中显示的信息,都显示在这，例如: using file sort ，using where， using join buffer，using index等 > **using file sort**: 如果索引不能用于满足 ORDER BY 子句，MySQL 将执行 filesort 操作来读取表行并对它们进行排序。 filesort 构成查询执行中的**额外排序阶段**。如果结果集太大而无法放入内存，文件排序操作将根据需要使用临时磁盘文件。某些类型的查询特别适合完全内存中的文件排序操作。例如，优化器可以使用 filesort 在内存中高效地处理ORDER BY的操作，而无需临时文件。[取自官网解释](https://dev.mysql.com/doc/refman/8.0/en/order-by-optimization.html)。配置排序缓存大小通过`sort_buffer_size`,这使得用户可以将 sort\_buffer\_size 设置为较大的值以加速较大的排序，而不必担心小型排序会使用过多的内存 ### 2. MySQL有哪些索引 [Section titled “2. MySQL有哪些索引”](#2-mysql有哪些索引) 1. 普通索引:只有普通索引可以使用 2. 唯一索引: 唯一索引的更新就不能使用**Change Buffer** 3. 前缀索引: 定义字符串的一部分作为索引。这个索引会回表查完整的信息 4. 覆盖索引: 简单理解就是【索引的字段就是我们查的字段】,可以直接获取，减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段。 5. 联合索引: 联合索引是指对表中的多个列创建的索引。 * 适合的场景: 由A即B的场景。将A和B建立联合索引，较少回表的操作 * 最佳实践: 一般都是设计联合索引，很少用单个字段做索引，因为还是要尽可能让索引数量少，避免磁盘占用太多，影响增删改性能 * **最**左匹配原则: * 如有索引 (a,b,c,d)，查询条件 a=1 and b=2 and c>3 and d=4，则会在每个节点依次命中a、b、c，无法命中d。(c已经是范围查询了，d肯定是排不了序了) * 例如，like ‘moatkon%‘,可以走到索引 6. 索引下推: 简单理解就是指在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数来提高查询效率。 7. 主键索引: 属于聚集(簇)索引,也属于稠密索引。聚集索引即索引结构和数据一起存放的索引。 **优点:** 聚集索引的查询速度非常的快，因为整个 B+树本身就是一颗多叉平衡树，叶子节点也都是有序的，定位到索引的节点，就相当于定位到了数据。 **缺点:** 1. 更新代价大,如果对索引列的数据被修改时，那么对应的索引也将会被修改，而且聚集索引的叶子节点还存放着数据，修改代价肯定是较大的，所以对于主键索引来说，主键一般都是不可被修改的。 2. 插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个自增的ID列为主键 8. 非聚集索引: 非聚集(簇)索引即索引结构和数据分开存放的索引,属于稀疏索引。(在聚簇索引之上创建的索引称之为辅助索引(也称非聚集索引),辅助索引访问数据总是需要二次查找,即回表,因为是分开的) **优点:** 更新代价比聚集索引要小。非聚集索引的更新代价就没有聚集索引那么大了，非聚集索引的叶子节点是不存放数据的 **缺点:** 1. 跟聚集索引一样，非聚集索引也依赖于有序的数据 2. 可能会二次查询(回表),这是非聚集索引最大的缺点了。当查到索引对应的指针或主键后，可能还需要根据指针或主键再到数据文件或表中查询。 普通索引,唯一索引,前缀索引 属于**二级索引**。二级索引又称为**辅助索引**,属于**非聚集索引**，是因为二级索引的叶子节点存储的数据是主键。也就是说，通过二级索引，可以定位主键的位置 Change Buffer 写缓存(Change Buffer) 是一种特殊的数据结构，用于在对数据变更时，如果数据所在的数据页没有在 buffer pool 中的话，在不影响数据一致性的前提下，InnoDB 引擎会将对数据的操作缓存在 Change Buffer 中，这样就省去了从磁盘中读入这个数据页。 ##### Change Buffer使用场景 [Section titled “Change Buffer使用场景”](#change-buffer使用场景) 写多读少的业务,例如账单类、日志类的业务场景 ##### 为什么唯一索引的更新不能使用Change Buffer? [Section titled “为什么唯一索引的更新不能使用Change Buffer?”](#为什么唯一索引的更新不能使用change-buffer) 唯一索引的更新通常不能使用Change Buffer。Change Buffer是一种用于延迟索引更新的技术，它主要用于非唯一索引，可以提高写入性能。Change Buffer会将索引更新操作**延迟到**后台异步执行，而不是立即执行。这意味着对于非唯一索引，可以将多个相同键值的更新操作合并，从而减少磁盘写入操作，提高性能。 然而，对于唯一索引，必须确保索引中的值是唯一的，因此无法将多个相同键值的更新操作合并。因此，对唯一索引的更新通常需要立即执行，而不是延迟到Change Buffer中。这可能会导致对唯一索引的写入操作相对较慢，因为需要确保唯一性约束。 总之，Change Buffer通常用于非唯一索引，以提高写入性能，而对唯一索引的更新通常不能延迟使用Change Buffer，因为需要确保唯一性。 ##### Change Buffer 和 redo log在更新普通索引时 [Section titled “Change Buffer 和 redo log在更新普通索引时”](#change-buffer-和-redo-log在更新普通索引时) Change Buffer 主要节省的是随机读磁盘的IO 消耗；如果没有 Change Buffer，则必须将数据读入内存，然后更新数据。此时节省了随机读磁盘的IO消耗； redo log 主要是节省随机写磁盘的IO消耗；如果没有 redo log，则更新完数据必须先将数据写入磁盘，再返回执行结果。此时节省了随机写磁盘的IO消耗； ### 3. 不走索引的场景 [Section titled “3. 不走索引的场景”](#3-不走索引的场景) 1. 对字段做了函数计算，就用不上索引了，这是MySQL的规定。因为对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。`使用了函数,不走索引` 2. 隐式类型转换不会走索引，因为mysql在隐式转换时会使用转换函数，而使用了函数就不会走索引。`使用了函数,不走索引` `生产遇到过,merchant_code = 1123,正确应该是merchant_code = '1123'` 3. 隐式字符编码转换不会走索引。`使用了函数,不走索引` 4. 在联合索引的场景下，查询条件不满足**最左**匹配原则。 > MySQL一定是遵循最左前缀匹配的，这句话在以前是正确的，没有任何毛病。但是在MySQL 8.0中，就不一定了。MySQL 8.0.13 版本中，对于range查询，引入了索引跳跃扫描（Index Skip Scan）优化，支持不符合组合索引最左前缀原则条件下的SQL，依然能够使用组合索引，减少不必要的扫描 5. 在联合索引下，使用了select \* 会导致索引失效 > 解决办法: 在联合索引下，尽量使用明确的查询列来趋向于走覆盖索引； 就是select具体的字段 6. 模糊查询时(like语句),模糊匹配的占位符位于条件的首部 7. 查询条件使用or关键字。 * 其中一个字段没有创建索引，则会导致整个查询语句索引失效;**只有两边都有索引才走索引** * or两边为“>”和“<”范围查询时，索引失效 8. 两列数据**做比较**，即便两列都创建了索引，索引也会失效。例如: id > age 9. 查询条件使用is null时正常走索引，使用is not null时，不走索引。 ### 4. 创建索引需要注意哪些事项 [Section titled “4. 创建索引需要注意哪些事项”](#4-创建索引需要注意哪些事项) * 被频繁查询的字段 : 我们创建索引的字段应该是查询操作非常频繁的字段。 * 被作为条件查询的字段 : 被作为 WHERE 条件查询的字段，应该被考虑建立索引。 * 频繁需要排序的字段 : 索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。 > 索引的本质是一种数据结构,而数据结构是有序的(这里只针对MySQL的索引哈) * 被经常频繁用于连接的字段 : 经常用于连接的字段可能是一些外键列，对于外键列并不一定要建立外键，只是说该列涉及到表与表的关系。对于频繁被连接查询的字段，可以考虑建立索引，提高多表连接查询的效率。 > 外键在实际的业务开发场景中,很少会被使用,反正我还没有碰到过,只是在学习的时候会接触到外键 * 不为 NULL 的字段 : 索引字段的数据应该尽量不为 NULL，因为对于数据为 NULL 的字段，数据库较难优化。如果字段频繁被查询，但又避免不了为 NULL，建议使用 0,1,true,false 这样语义较为清晰的短值或短字符作为替代。 #### 4.1 MySQL创建索引一定会锁表吗? [Section titled “4.1 MySQL创建索引一定会锁表吗?”](#41-mysql创建索引一定会锁表吗) 在 MySQL 5.6 之前，创建索引时会锁表，所以，在早期 MySQL 版本中一定要在线上慎用，因为创建索引时会导致其他会话阻塞（select 查询命令除外）。 在 MySQL 5.6.7 版本中得到了改变，因为在 MySQL 5.6.7 中引入了 Online DDL 技术（在线 DDL 技术），它允许在创建索引时，不阻塞其他会话（所有的 DML 操作都可以一起并发执行）。 * ALTER 语句中可以指定参数 ALGORITHM 和 LOCK 分别指定 DDL 执行的方式和 DDL 期间 DML 的并发控制。 * ALGORITHM=INPLACE,表示执行DDL的过程中不发生表拷贝，过程中允许并发执行DML（INPLACE不需要像COPY一样占用大量的磁盘I/O和CPU，减少了数据库负载。同时减少了buffer pool的使用，避免 buffer pool 中原有的查询缓存被大量删除而导致的性能问题） * ALGORITHM=COPY，DDL 就会按 MySQL 5.6 之前的方式，采用表拷贝的方式进行，过程中会阻塞所有的DML * ALGORITHM=DAFAULT，让 MySQL 以尽量保证 DML 并发操作的原则选择执行方式 * ALGORITHM=INSTANT，在数据字典中修改元数据。**生产环境中优先推荐此种方式**。[MySQL 8.0支持](https://dev.mysql.com/blog-archive/mysql-8-0-innodb-now-supports-instant-add-column/) * LOCK * **NONE**: 表示对 DML 操作不加锁，DDL 过程中允许所有的 DML 操作。 * EXCLUSIVE: 持有排它锁，阻塞所有的请求，适用于需要尽快完成DDL或者服务库空闲的场景 * SHARED: 允许SELECT，但是阻塞INSERT UPDATE DELETE，适用于数据仓库等可以允许数据写入延迟的场景 * DEFAULT: 根据DDL的类型，在保证最大并发的原则下来选择LOCK的取值 ### 5. MySQL的索引深入 [Section titled “5. MySQL的索引深入”](#5-mysql的索引深入) 索引本质上是一种的数据结构 #### 5.1 MySQL索引有哪些数据结构 [Section titled “5.1 MySQL索引有哪些数据结构”](#51-mysql索引有哪些数据结构) ##### **1. Hash(无序)** [Section titled “1. Hash(无序)”](#1-hash无序) 1. 可能会出现Hash冲突 2. 可以快速的精确查询，但是不支持范围查询,适合等值查询的场景,例如Redis、Memcached这些NoSQL的中间件。 > 如果是有序的数据结构，比如【有序数组】，支持范围和等值查询了。但是有序数据适合静态的数据，对于CUD的业务就不适合了，成本高 ##### **2. B+树** [Section titled “2. B+树”](#2-b树) **MySQL为什么要选择B+?** 同样的元素，B+树的表示要比B树要“胖”，原因在于B+树中的非叶子节点会冗余一份在叶子节点中，并且叶子节点之间用指针相连。 > 非叶子节点冗余的原因是为了提高范围查找的效率 **B+树的优势:** * 有序: 排序效率高 * 查询索引时的磁盘IO效率高(结构整体高度低) * 范围查询的效率高(有指针) **一个B+树的节点中到底存多少个元素最合适？** > (等同于问)B+树中一个节点到底多大合适？ B+树中一个节点为【一页或页的倍数】最为合适。 原因如下: * 如果一个节点的大小小于1页，那么读取这个节点的时候其实也会读出1页，造成资源的浪费 * 如果一个节点的大小大于1页，比如1.2页，那么读取这个节点的时候会读出2页，也会造成资源的浪费 > [这里详细说了为什么MySQL会采用B+树](/software-engineer/database/mysql-qa#mysql%E4%B8%BA%E4%BB%80%E4%B9%88%E4%BD%BF%E7%94%A8%E6%A0%91%E7%BB%93%E6%9E%84) ##### **3. 其他算法** [Section titled “3. 其他算法”](#3-其他算法) **二叉树**: 有序,所以支持范围查询。时间复杂度是O(log(N)),为了维持这个时间复杂度，更新的时间复杂度也得是O(log(N))，那就得保持这棵树是完全平衡二叉树了 **平衡二叉树**: 是否可以使用平衡二叉树做索引?不行! 索引也不只是在内存里面存储的，还是要落盘持久化的。如果数据多了，树高会很高，查询的成本就会随着树高的增加而增加。 **B树**: B树的表示要比完全平衡二叉树要“矮”，原因在于B树中的一个节点可以存储多个元素。 ### 6. MySQL InnoDB Redo Flush是什么 [Section titled “6. MySQL InnoDB Redo Flush是什么”](#6-mysql-innodb-redo-flush是什么) **将redo log更新到磁盘** [详细看redo log](#102-%E4%BA%8B%E5%8A%A1%E6%97%A5%E5%BF%97-redo-log%E9%87%8D%E5%81%9A%E6%97%A5%E5%BF%97) #### 6.1 脏页、干净页 [Section titled “6.1 脏页、干净页”](#61-脏页干净页) **脏页**: 内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为“脏页” > 理解脏页的前提是达成一致,即脏页是内存页,即最新的数据是在内存中 **干净页**: 内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页“ #### 6.2 什么时候会flush? [Section titled “6.2 什么时候会flush?”](#62-什么时候会flush) 1. InnoDB的redo log写满了，这时候系统会停止所有更新操作，把checkpoint往前推进，redo log留出空间可以继续写。 2. 系统内存不足，当需要新的内存页，而内存不够用的时候，就要淘汰一些数据页，空出内存给别的数据页使用。如果淘汰的是“脏页”，就要先将脏页写到磁盘。 > 如果刷【脏页】一定会写盘，就保证了每个数据页有两种状态: > > 1. 一种是内存里存在，内存里就肯定是正确的结果，直接返回； > 2. 另一种是内存里没有数据，就可以肯定数据文件上是正确的结果，读入内存后返回。 这样的效率最高。 3. MySQL认为系统“空闲”的时候，只要有机会就刷一点“脏页”。 4. MySQL正常关闭，这时候，MySQL会把内存的脏页都flush到磁盘上，这样下次MySQL启动的时候，就可以直接从磁盘上读数据，启动速度会很快。 #### 6.3 其他 [Section titled “6.3 其他”](#63-其他) 1. `innodb_io_capacity`参数设置: 它会告诉InnoDB你的磁盘能力，这个值建议设置成磁盘的IOPS，磁盘的IOPS可以通过fio这个工具来测试 2. 刷脏页的时候，旁边如果也是脏页，会一起刷掉的，并且如果周围还有脏页，这个连带责任制会一直蔓延，这种情况其实在机械硬盘时代比较好，一次IO就解决了所有问题 ### 7. 事务的特性: ACID [Section titled “7. 事务的特性: ACID”](#7-事务的特性-acid) ACID，是指在可靠数据库管理系统(DBMS)中，事务(transaction)所应该具有的四个特性: 1. 原子性(Atomicity): 事务中的所有操作要么全部执行成功，要么全部失败回滚，不能只执行其中一部分操作。 2. 一致性(Consistency): 事务执行前后，数据库的完整性约束没有被破坏，数据总是从一个一致性状态转移到另一个一致性状态。例如，如果一个事务要求将某个账户的金额从 A 转移到 B，那么无论事务是否成功，最终账户 A 和账户 B 的总金额应该保持不变。 3. 隔离性(Isolation): 事务之间是相互隔离的，每个事务对其他事务的操作是透明的，一个事务的中间结果对其他事务是不可见的。**隔离性可以防止并发执行的事务之间产生脏读、不可重复读和幻读等问题**。 4. 持久性(Durability): 事务完成后，对数据库的修改将永久保存在数据库中，即使系统故障也不会丢失。 #### 如何保证事务的四大特性? [Section titled “如何保证事务的四大特性?”](#如何保证事务的四大特性) 以默认的引擎 InnoDB 为例，它保证四大特性的手段分别是: 1. 原子性是通过 undo log(回滚日志) 来保证的，InnoDB 使用日志(undo log)来记录事务的操作，包括事务开始、修改数据和事务提交等。如果事务执行失败或回滚，InnoDB 可以使用日志来撤销已经执行的操作，确保事务的原子性。 2. 持久性是通过 redo log (重做日志)来保证的，在事务提交之前，InnoDB 会将事务的修改操作先写入事务日志(redo log)，然后再将数据写入磁盘。即使在系统崩溃或断电的情况下，InnoDB 可以通过重放事务日志来恢复数据，确保事务的持久性。 3. 隔离性是通过 MVCC(多版本并发控制) 和锁机制来保证的。 4. 一致性是通过各种约束，如主键、外键、唯一性约束等，加上事务的持久性、原子性和隔离性来保证的。 #### MySQL中的MVCC机制 [Section titled “MySQL中的MVCC机制”](#mysql中的mvcc机制) Multi-Version Concurrency Control(MVCC)，翻译过来就是多版本并发控制，MVCC是为提高MySQL数据库并发性能的一个重要设计。 同一行数据发生读写请求时，会通过锁来保证数据的一致性。MVCC可以在读写冲突时，**让其读数据时通过快照读，而不是当前读，快照读不必加锁**。 MySQL的InnoDB实现MVCC，就是在隔离级别为**读已提交**和**可重复读**，基于乐观锁理论，**通过事务ID和read-view的记录进行比较判断分析数据是否可见，从而使其大部分读操作可以无需加锁，从而提高并发性能**。但是在写数据的时候，InnoDB还是需要加排它锁的。 **总结，就是用乐观锁代替悲观锁，从而提高并发性能，这就是MVCC** ### 8. 并发事务带来的问题 [Section titled “8. 并发事务带来的问题”](#8-并发事务带来的问题) 在数据库执行中，多个并发执行的事务如果涉及到同一份数据的读写就容易出现数据不一致的情况，不一致的异常现象有以下几种。 1. 脏读(Dirty read): 一个事务**读到了**另一个**未提交事务修改过的数据**，这就是脏读 2. 幻读(Phantom read): 幻读与不可重复读类似。它发生在一个事务(T1)读取了几行数据，接着另一个并发事务(T2)插入了一些数据时。在随后的查询中，第一个事务(T1)就会发现多了一些原本不存在的记录，就好像发生了幻觉一样(或者变幻,这个词更有利于记住)，所以称为幻读。 > 重点在于新增或者删除,重点在于**数量**的变化。幻读的解决方案通常是使用间隙锁来解决 3. 不可重复读(Unrepeatable read): 在一个事务内**多次读取同一个数据**，如果出现前后两次读到的数据不一样的情况，这就是不可重复读。 > 例如:有A和B两个事务同时在处理，事务A先开始从数据库中读取数据，然后继续执行代码逻辑处理，**在这过程中如果事务B更新了这条数据，并提交了事务**，那么当事务A再次读取该数据时，就会发现前后两次读到的数据是不一致的，这种现象就被称为不可重复读。 > > 重点是修改,是值的变化,不是记录数的变化,记录数的变化是幻读。不可重复读的解决方案通常是使用行锁或者表锁来解决 脏读、不可重复读和幻读有以下的包含关系，如果发生了脏读，那么幻读和不可重复读都有可能出现。  ### 9. 事务隔离级别 [Section titled “9. 事务隔离级别”](#9-事务隔离级别) SQL 标准根据四种不一致的异常现象，将隔离性定义为四个隔离级别(Isolation Level)，隔离级别和数据库的性能呈反比，隔离级别越低，数据库性能越高；而隔离级别越高，数据库性能越差，具体如下: * READ-UNCOMMITTED(读取未提交的数据): 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致**脏读**、**幻读**或**不可重复读**。 * READ-COMMITTED(读取已提交的数据): 允许读取并发事务已经提交的数据，可以阻止脏读，但是**幻读**或**不可重复读**仍有可能发生 * REPEATABLE-READ(可重复读,可以一直读): 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，**但幻读仍有可能发生**。 * SERIALIZABLE(可串行化,依次按顺序操作): 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。 表格形式呈现: | 隔离级别 | 脏读 | 不可重复读 | 幻读 | | -------- | --- | ----- | --- | | **读未提交** | 出现 | 出现 | 出现 | | **读已提交** | 不出现 | 出现 | 出现 | | **可重复读** | 不出现 | 不出现 | 出现 | | **串行化** | 不出现 | 不出现 | 不出现 | MySQL的默认事务隔离级别是**可重复读** ##### 如何设置MySQL的事务隔离界别 [Section titled “如何设置MySQL的事务隔离界别”](#如何设置mysql的事务隔离界别) 1. 命令行 ```sh SET {SESSION | GLOBAL} TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}; ``` 2. 配置文件 my.conf ```sh [mysqld] transaction-isolation = REPEATABLE-READ ``` ### 10. MySQL日志 [Section titled “10. MySQL日志”](#10-mysql日志) #### 10.1 Binary Log 二进制日志 [Section titled “10.1 Binary Log 二进制日志”](#101-binary-log-二进制日志) binlog 日志有三种格式，可以通过`binlog_format`参数指定: 1. statement: 记录的内容是SQL语句原文。同步数据时，会执行记录的SQL语句，但是有个问题，update\_time=now()这里会获取当前系统时间，直接执行会导致与原库的数据不一致。 2. row: 记录的内容不再是简单的SQL语句了，还包含操作的具体数据。这样就能保证同步数据的一致性，**通常情况下都是指定为row，这样可以为数据库的恢复与同步带来更好的可靠性**。 3. mixed: 记录的内容是前两者的混合。MySQL会判断这条SQL语句是否可能引起数据不一致，如果是，就用row格式，否则就用statement格式。 ##### binlog写入机制: [Section titled “binlog写入机制:”](#binlog写入机制) binlog的写入时机也非常简单，事务执行过程中，先把日志写到binlog cache，**事务提交的时候**，再把binlog cache写到binlog文件中 > 其实就是缓存(Buffer)的思想,减少磁盘写IO #### 10.2 事务日志 redo log(重做日志) [Section titled “10.2 事务日志 redo log(重做日志)”](#102-事务日志-redo-log重做日志) 概念：重做日志用来实现事务持久性，主要有两部分文件组成，重做日志缓冲（redo log buffer）以及重做日志文件（redo log），前者是在内存中，后者是在磁盘中。 作用：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启 mysql 服务的时候，根据 redo log 进行重做，从而达到事务的持久性这一特性。 内容：物理格式的日志，记录的是物理数据页面的修改的信息，其 redo log 是顺序写入 redo log file 的物理文件中去的。 #### 10.3 undo log(回滚日志) [Section titled “10.3 undo log(回滚日志)”](#103-undo-log回滚日志) 概念：回滚日志，用来记录数据被修改前的信息。正好跟前面的重做日志进行相反操作。undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。 作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读； 内容：逻辑格式的日志，在执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于 redo log 的。 ### 11. redo log与binlog事务不一致解决方法 [Section titled “11. redo log与binlog事务不一致解决方法”](#11-redo-log与binlog事务不一致解决方法) #### 背景 [Section titled “背景”](#背景) redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入。所以redo log与binlog的写入时机不一样。在binlog提交事务准备写入时宕机了，在恢复的时候就会导致数据不一致 #### 解决方法 [Section titled “解决方法”](#解决方法) 为了解决两份日志之间的逻辑一致问题，InnoDB存储引擎使用**两阶段**提交方案。 原理很简单，将redo log的写入拆成了两个步骤prepare和commit，这就是两阶段提交。  ### 12. MySQL主从复制什么原因会造成不一致，如何预防及解决 [Section titled “12. MySQL主从复制什么原因会造成不一致，如何预防及解决”](#12-mysql主从复制什么原因会造成不一致如何预防及解决) 1. 从库写入: 人为原因导致从库与主库数据不一致 2. binlog非row格式,如果是基于binlog做一些操作就会导致数据不一致 3. 主从复制过程中，主库异常宕机 4. 设置了ignore/do/rewrite等replication等规则 5. 从库中断很久，binlog应用不连续，监控并及时修复主从 **解决** 1. 主库binlog采用ROW格式。 2. 主从实例数据库版本保持一致 3. 主库做好账号权限把控，不可以执行set sql\_log\_bin=0 4. 从库开启只读，不允许人为写入。 5. 定期进行主从一致性检验。 ### 13. canal - 伪装者 [Section titled “13. canal - 伪装者”](#13-canal---伪装者)  实现原理: canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送 dump请求, MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即canal), canal 解析 binary log 对象(原始为 byte 流) ##### canal如何做高可用,防止canal挂了 [Section titled “canal如何做高可用,防止canal挂了”](#canal如何做高可用防止canal挂了) Canal Server 和 Canal Adapter 依赖 Zookeeper 实现 HA 高可用. Zk可以自行安装 canal高可用主要配置: ```sh #Canal Server 地址 canal.register.ip = 11.8.36.104 #Canal Admin 连接信息 canal.admin.manager = 11.8.36.104:8089 canal.admin.port = 11110 canal.admin.user = admin #mysql5 类型 MD5 加密结果 -- admin canal.admin.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441 #自动注册 canal.admin.register.auto = true #集群名 canal.admin.register.cluster = canal-cluster-1 #Canal Server 名字 canal.admin.register.name = canal-server-1 ``` 另一台 Canal Server 也是一样的方式配置，修改 canal.register.ip = 11.8.36.105 和 canal.admin.register.name = canal-server-2 即可。 > Canal Adapter: Canal 最初只支持将数据从 MySQL 同步到 Kafka，RabbitMQ 等消息队列中，从 1.1.1 版本开始，Canal 实现了一个配套落地的模块 Canal Adapter，实现对 Canal Server 订阅的 binlog 消息进行消费，支持将数据输出至 HBase，MySQL，Elasticsearch，Kudu 中。 ### 14. MySQL主从同步 [Section titled “14. MySQL主从同步”](#14-mysql主从同步) MySQL 本身就自带有一个主从复制的功能，可以帮助我们实现负载均衡和读写分离  **基本原理**: 通过binlog来实现 **详细描述**: 主节点 log dump 线程: 当从节点连接主节点时，主节点会为其创建一个 log dump 线程，用于发送和读取 Binlog 的内容。在读取 Binlog 中的操作时，log dump 线程会对主节点上的 Binlog 加锁；当读取完成发送给从节点之前，锁会被释放。主节点会为自己的每一个从节点创建一个 log dump 线程。 从节点I/O线程: 当从节点上执行start slave命令之后，从节点会创建一个 I/O 线程用来连接主节点，请求主库中更新的Binlog。I/O 线程接收到主节点的 log dump 进程发来的更新之后，保存在本地 relay-log(中继日志)中。 从节点 SQL 线程: SQL 线程负责读取 relay log 中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。对于每一个主从连接，都需要这三个进程来完成。 当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个 log dump 进程，而每个从节点都有自己的 I/O 进程，SQL 进程。从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。比如，如果从节点没有运行，此时 I/O 进程可以很快从主节点获取更新，尽管 SQL 进程还没有执行。如果在 SQL 进程执行之前从节点服务停止，至少 I/O 进程已经从主节点拉取到了最新的变更并且保存在本地 relay log 中，当服务再次起来之后就可以完成数据的同步。 relay log 这里又引申出一个新的日志概念。MySQL 进行主主复制或主从复制的时候会在要复制的服务器下面产生相应的 relay log。 **relay log 是怎么产生的呢？** 从服务器 I/O 线程将主服务器的 Binlog 日志读取过来，解析到各类 Events 之后记录到从服务器本地文件，这个文件就被称为 relay log。然后 SQL 线程会读取 relay log 日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。中继日志充当缓冲区，这样 master 就不必等待 slave 执行完成才发送下一个事件。 #### 14.1 MySQL主从复制有哪些 [Section titled “14.1 MySQL主从复制有哪些”](#141-mysql主从复制有哪些) * 主从同步: 当用户写数据主服务器必须和从服务器同步了才告诉用户写入成功，等待时间比较长。 * 主从异步: 只要用户访问写数据主服务器，立即返回给用户。 * 主从半同步: 当用户访问写数据主服务器写入并同步其中一个从服务器就返回给用户成功。 ### 15. 深分页 [Section titled “15. 深分页”](#15-深分页) 当偏移量比较大的时候,查询效率就比较低，例如limit 10000,10。性能会急剧下降 **为什么会慢?** 1. limit语句会先扫描offset+n行，然后再丢弃掉前offset行，返回后n行数据。也就是说limit 100000,10，就会扫描100010行，而limit 0,10，只扫描10行。 2. limit 100000,10 扫描更多的行数，也意味着回表更多的次数。 **如何优化?** 基于慢点原因可以从减少回表次数做以下优化: 1. 已知范围使用between…and… 2. 子查询优化 3. inner join 延迟关联 4. 标签记录(分页游标),即将上一页的结果作为条件查下一页。适用场景: 无翻到指定页的情况，类似于App首页瀑布流的这种形式 # MySQL Buffer Pool > MySQL Buffer Pool * [x] 看了上面的文章,Buffer Pool设计的很精妙。 # MySQL死锁 > MySQL死锁 ### MySQL死锁是什么? [Section titled “MySQL死锁是什么?”](#mysql死锁是什么) 死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种**互相等待**的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等的进程称为死锁进程。 ### 什么情况下会出现MySQL死锁? [Section titled “什么情况下会出现MySQL死锁?”](#什么情况下会出现mysql死锁) > 场景设置: 基于 InnoDB存储引擎并且隔离级别为REPEATABLE-READ(可重复读) ##### 场景 AB BA [Section titled “场景 AB BA”](#场景-ab-ba) ```sql # session A select * from deadlock where id = 1 for update; # session B select * from deadlock where id = 2 for update; # session A select * from deadlock where id = 2 for update; # session B select * from deadlock where id = 1 for update; ## Deadlock found when trying to get lock; try restarting transaction ``` ### 怎么查有哪些MySQL死锁? [Section titled “怎么查有哪些MySQL死锁?”](#怎么查有哪些mysql死锁) 1. 查看当前的事务 ```sql SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX; ``` 获取 `trx_mysql_thread_id` 2. 查看当前锁定的事务 ```sql SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; ``` 3. 查看当前等锁的事务 ```sql SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; ``` 4. 查看是否锁表 ```plaintext SHOW OPEN TABLES where In_use > 0; ``` 在发生死锁时，这几种方式都可以查询到和当前死锁相关的信息。 5. 查看最近死锁的日志 ```plaintext show engine innodb status ``` ### 怎么解决MySQL死锁? [Section titled “怎么解决MySQL死锁?”](#怎么解决mysql死锁) 1. 设置事务等待锁的超时时间 2. 开启主动死锁检测。当系统检测到死锁时，通常会选择其中一个事务作为死锁牺牲者，并回滚该事务，释放资源以解除死锁。 3. 使用kill命令 ### 如何在业务开发中尽量去避免死锁 [Section titled “如何在业务开发中尽量去避免死锁”](#如何在业务开发中尽量去避免死锁) * ✅ 合理的设计索引，区分度高的列放到组合索引前面，**使业务 SQL 尽可能通过索引定位更少的行，减少锁竞争**。 * ✅ 优化 SQL 和表设计，减少同时占用太多资源的情况。比如说，减少连接的表，**将复杂 SQL 分解为多个简单的 SQL**。 * ✅ 避免大事务，**尽量将大事务拆成多个小事务来处理**，小事务发生锁冲突的几率也更小。 * 调整业务逻辑 SQL 执行顺序， 避免 update/delete 长时间持有锁的 SQL 在事务前面。 * 以固定的顺序访问表和行。比如两个更新数据的事务，事务 A 更新数据的顺序为 1，2;事务 B 更新数据的顺序为 2，1。这样更可能会造成死锁。 * 在并发比较高的系统中，不要显式加锁，特别是是在事务里显式加锁。如 select … for update 语句，如果是在事务里(运行了 start transaction 或设置了autocommit 等于0),那么就会锁定所查找到的记录。 * 尽量按主键/索引去查找记录，范围查找增加了锁冲突的可能性，也不要利用数据库做一些额外额度计算工作。比如有的程序会用到 “select … where … order by rand();”这样的语句，由于类似这样的语句用不到索引，因此将导致整个表的数据都被锁住。 # MySQL死锁排查案例 > MySQL死锁 ## 业务处理流程示意图 [Section titled “业务处理流程示意图”](#业务处理流程示意图)   ## 死锁日志 [Section titled “死锁日志”](#死锁日志) ```sh 2024-10-16 13:51:36 139636894508800 *** (1) TRANSACTION: TRANSACTION 4718724388, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2 MySQL thread id 82934132, OS thread handle 139633304270592, query id 35509253618 10.100.32.248 dscloud_agent update INSERT INTO order_detail_model ( order_no, commodity_code, commodity_name, commodity_count, total_actual_amount, bill_price, goods_type, is_joint, is_original, is_gift, status ) VALUES ( 1812845401680613892, '199965', '双黄连口服液_林宝_10ml*12支', 1, 15.80, 15.8000, 1, 0, 1, 0, 0 ) *** (1) HOLDS THE LOCK(S): RECORD LOCKS space id 26174 page no 590 n bits 824 index idx_order_no of table `dscloud`.`order_detail_model` trx id 4718724388 lock_mode X locks gap before rec Record lock, heap no 377 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 8; hex 992885f6a1323d07; asc ( 2= ;; 1: len 8; hex 800000000003f03f; asc ?;; *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 26174 page no 590 n bits 824 index idx_order_no of table `dscloud`.`order_detail_model` trx id 4718724388 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 377 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 8; hex 992885f6a1323d07; asc ( 2= ;; 1: len 8; hex 800000000003f03f; asc ?;; *** (2) TRANSACTION: TRANSACTION 4718724391, ACTIVE 0 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2 MySQL thread id 82934170, OS thread handle 139634086201088, query id 35509253624 10.100.39.10 dscloud_agent update INSERT INTO order_detail_model ( order_no, commodity_code, commodity_name, commodity_count, total_actual_amount, bill_price, goods_type, is_joint, is_original, is_gift, status ) VALUES ( 1812845401445735431, '169913', '清热解毒口服液_伊龍_10ml*10支', 1, 9.50, 9.5000, 1, 0, 1, 0, 0 ) *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 26174 page no 590 n bits 824 index idx_order_no of table `dscloud`.`order_detail_model` trx id 4718724391 lock_mode X locks gap before rec Record lock, heap no 377 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 8; hex 992885f6a1323d07; asc ( 2= ;; 1: len 8; hex 800000000003f03f; asc ?;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 26174 page no 590 n bits 824 index idx_order_no of table `dscloud`.`order_detail_model` trx id 4718724391 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 377 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 8; hex 992885f6a1323d07; asc ( 2= ;; 1: len 8; hex 800000000003f03f; asc ?;; *** WE ROLL BACK TRANSACTION (2) ``` ## 排查原因 [Section titled “排查原因”](#排查原因) 这个死锁问题涉及两个事务 (1) 和 (2)，它们都在尝试向同一个表 `order_detail_model` 插入数据，且都在等待锁。 ### 死锁原因分析： [Section titled “死锁原因分析：”](#死锁原因分析) 1. **事务 (1) 和 (2)** 都在同一索引 `idx_order_no` 上持有了 **“gap” 锁**，也即“间隙锁”（Gap Lock）。间隙锁通常用于阻止其他事务在索引的某个范围内插入新记录，以维持一致性。 2. **事务 (1)**: * 持有 `idx_order_no` 的 gap 锁，锁住了索引前的间隙。 * 但是它仍在等待该索引的一个位置上插入意图锁。 3. **事务 (2)**: * 同样持有 `idx_order_no` 的 gap 锁，锁住了索引前的间隙。 * 但也在等待该索引上的插入意图锁。 4. **死锁形成**: * 事务 (1) 和 (2) 都已经持有了 gap 锁，并且都在等待对方释放锁以完成插入操作。然而，由于双方都需要对方的锁，而各自持有锁，形成了死锁。 ### 解决方案建议： [Section titled “解决方案建议：”](#解决方案建议) 1. **减少并发插入的冲突**：可以考虑通过优化业务逻辑，减少并发事务同时对同一索引位置插入的情况。 2. **锁定策略调整**：考虑调整表的索引策略，或者在可能的情况下，使用更低隔离级别（如 `READ COMMITTED`）以减少 gap 锁的使用。 3. **批量插入**：如果可能，将多条插入操作批量执行，减少每次单条插入操作时加锁的次数。 4. **间隙锁的避免**：如果应用场景允许，减少唯一性约束，避免间隙锁的发生。 这样可以帮助缓解类似的死锁问题。如果问题频繁出现，建议增加监控和分析锁的使用情况。 ## 解决思路 [Section titled “解决思路”](#解决思路) 批量插入本身不会直接减少 **gap 锁**，但可以间接减少出现死锁的概率。以下是详细的分析： #### Gap 锁的作用 [Section titled “Gap 锁的作用”](#gap-锁的作用) Gap 锁通常在 **`REPEATABLE READ`** 隔离级别下，用于防止幻读（Phantom Reads），即防止其他事务在当前事务扫描的索引范围内插入新记录。尤其是在具有唯一性约束（如唯一索引）的情况下，插入操作会触发 gap 锁，来确保当前索引范围内的插入安全。 #### 为什么批量插入可能减少死锁： [Section titled “为什么批量插入可能减少死锁：”](#为什么批量插入可能减少死锁) 1. **减少事务次数**：批量插入将多次插入合并为一次事务，从而减少了每次插入时加锁和释放锁的频率。这降低了事务之间相互等待锁的机会，从而间接减少死锁的发生。 2. **减少并发锁冲突**：单次批量插入会一次性获取所需的锁，减少了多个事务同时请求锁的竞争，从而减少了并发场景下发生 gap 锁冲突的可能性。 3. **锁持有时间减少**：批量插入操作可以让事务更快地完成，从而缩短锁的持有时间，降低其他事务等待锁的时间。 #### 注意事项： [Section titled “注意事项：”](#注意事项) * **批量插入并不能完全避免 gap 锁**。如果多个批量插入操作同时执行，且插入的数据范围有重叠，仍然会发生 gap 锁。 * **表的设计和索引结构**也对 gap 锁有影响。如果索引结构不合理，即使是批量插入，仍然可能遇到 gap 锁。 #### 总结 [Section titled “总结”](#总结) 批量插入可以通过减少事务频率和锁的持有时间，降低死锁的发生率，但它并不会直接减少 gap 锁的使用。如果 gap 锁是死锁的主要原因，可以考虑其他措施，如调整表结构、索引设计，或选择不同的事务隔离级别（如 `READ COMMITTED`，该级别下不会产生 gap 锁）。 #### 最终执行动作 [Section titled “最终执行动作”](#最终执行动作) * 修改为update方式 * 缩小事务范围 * 对于某些场景可以不操作数据库 *** [参考](https://xiaolincoding.com/mysql/lock/deadlock.html#_1%E3%80%81%E8%AE%B0%E5%BD%95%E4%B9%8B%E9%97%B4%E5%8A%A0%E6%9C%89%E9%97%B4%E9%9A%99%E9%94%81) # INSTANT DDL次数上限 > INSTANT DDL次数上限 | 版本 | 位宽 | 可表示范围 | INSTANT DDL 上限 | 每行额外开销 | | ----------- | ----- | ----- | -------------- | -------- | | MySQL 8.0 | 6 bit | 0–63 | 64 次 | 实际占 1 字节 | | MySQL 9.1.0 | 8 bit | 0–255 | 256 次 | 同样 1 字节 | ### 一、MySQL8 INSTANT DDL可用次数上限为什么不能超过63次 [Section titled “一、MySQL8 INSTANT DDL可用次数上限为什么不能超过63次”](#一mysql8-instant-ddl可用次数上限为什么不能超过63次) 这个限制来自 InnoDB 物理行格式的存储设计。 #### 1. 根本原因：行版本号（Row Version）的位宽限制 [Section titled “1. 根本原因：行版本号（Row Version）的位宽限制”](#1-根本原因行版本号row-version的位宽限制) MySQL 8.0 的 INSTANT DDL 能快速执行的核心原理是：**不重建整张表，只在数据字典里记录新列的元数据**，然后在每行物理记录里额外存一个很小的”行版本号”（Row Version），用来告诉引擎”这行数据是按哪一个版本的表结构写入的”。 读取行时，InnoDB 拿行里的版本号对比数据字典里每一列的”加入版本”，就知道这行有没有该列、默认值是什么，不需要真正改过历史数据。 #### 2. 为什么偏偏是 64 [Section titled “2. 为什么偏偏是 64”](#2-为什么偏偏是-64) 行版本号被设计为 **6 位整数**，可表示的范围是 `0–63`，共 **64 个不同的值**： * 版本 `0` 表示”建表时的原始结构” * 每做一次 INSTANT DDL，版本号 +1 * 版本号到 `63` 后，6 位已经用尽，再往上就溢出了 MySQL 选 6 位是在行头空间开销和可用次数之间的权衡——放在 extra bytes 里，尽量小，但又能支持合理次数的变更。 #### 3. 超出后怎么办 [Section titled “3. 超出后怎么办”](#3-超出后怎么办) 执行一次表重建，版本号归零： ```sql -- 任选一种，都会触发全表重建并重置版本计数器 ALTER TABLE order_info FORCE; -- 或 ALTER TABLE order_info ALGORITHM=INPLACE; -- 或 OPTIMIZE TABLE order_info; ``` 重建之后所有历史行都被改写成当前最新结构，版本号重置为 0，64 次 INSTANT DDL 的配额重新开始计算。 #### 小结 [Section titled “小结”](#小结) | 关键点 | 说明 | | -------------- | ------------------------------- | | 版本号位宽 | 6 bit → 最大值 63 → 64 种状态 | | 每次 INSTANT DDL | 版本号 +1 | | 达到上限后 | 不报错建议，直接拒绝 INSTANT，需手动重建 | | 重置方式 | `ALTER TABLE ... FORCE` 或等价重建操作 | ### 二、MySQL9 INSTANT DDL可用次数上限为什么不能超过255次 [Section titled “二、MySQL9 INSTANT DDL可用次数上限为什么不能超过255次”](#二mysql9-instant-ddl可用次数上限为什么不能超过255次) 同样是行版本号的位宽变化，不过这次的逻辑更直接。 #### 1. 从 6 位扩展到 8 位（一个完整字节） [Section titled “1. 从 6 位扩展到 8 位（一个完整字节）”](#1-从-6-位扩展到-8-位一个完整字节) MySQL 8.0 用 6 位存储行版本号，能表示 0–63 共 64 个值，0 是建表原始状态，所以 INSTANT DDL 上限是 63 次。 9.1.0 把行版本号扩展到 **8 位（1 个字节）**，可表示 0–255 共 256 个值，0 保留给原始结构，所以 INSTANT DDL 可用次数变成 **255 次**。 #### 2. 为什么偏偏是 256，而不是 128 或 512？ [Section titled “2. 为什么偏偏是 256，而不是 128 或 512？”](#2-为什么偏偏是-256而不是-128-或-512) 关键在于存储对齐。 6 位在内存里并不能单独存放——实际上还是要占用一个完整的字节边界空间。既然无论如何都要”用掉”一个字节，MySQL 9.1.0 干脆把版本号字段对齐到 **1 字节**，把 6 位扩展到 8 位，**零额外存储成本，版本号容量直接翻 4 倍**。 选 8 位而不是 16 位，是因为： * 8 位已经足够绝大多数业务场景（正常表很少会 INSTANT DDL 超过 255 次而不做一次重建） * 每行多存一个字节和多存两个字节，对大表的总存储影响差异可观 * 1 字节是最自然的字节对齐单位，实现最简洁 #### 小结 [Section titled “小结”](#小结-1) 本质上是一次”既不花存储成本、又让上限翻倍”的改进——以前 6 位就已经占了一个字节的空间，那 2 位就别浪费了。 # MySQL锁 > MySQL锁 锁是计算机在执行多线程或线程时用于并发访问同一共享资源时的同步机制，MySQL中的锁是在服务器层或者存储引擎层实现的，保证了数据访问的一致性与有效性。 MySQL锁: * 按模式分类为: 乐观锁与悲观锁。 * 按粒度分可以分为: 全局锁、表级锁、页级锁、行级锁。 * 按属性可以分为: 共享锁、排它锁。 * 按状态分为: 意向共享锁、意向排它锁。 * 按算法分为: 间隙锁、临键锁、记录锁。 ### 全局锁 [Section titled “全局锁”](#全局锁) 全局锁就是对整个数据库实例加锁。 **应用场景:** 全库逻辑备份(mysqldump) **实现方式:** MySQL 提供了一个加全局读锁的方法，命令是`Flush tables with read lock` (FTWRL)。 当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句(数据的增删改)、数据定义语句(包括建表、修改表结构等)和更新类事务的提交语句。 **缺点:** * 如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就能停止。 * 如果在从库上备份，那么备份期间从库不能执行主库同步过来的binlog，会导致主从延迟。 **解决方法:** mysqldump使用参数`--single-transaction`，启动一个事务，确保拿到一致性视图。而由于MVCC的支持，这个过程中数据是可以正常更新的。 ### 表级锁 [Section titled “表级锁”](#表级锁) 当前操作的整张表加锁，最常使用的 MyISAM 与 InnoDB 都支持表级锁定 MySQL 里面表级别的锁有两种: 1. 表锁 `lock tables ... read/write` 2. 元数据锁(meta data lock，MDL)。MDL 不需要显式使用，在访问一个表的时候会被自动加上，在 MySQL 5.5 版本中引入了 MDL，当对一个表做增删改查操作的时候，加**MDL读锁**；当要对表做结构变更操作的时候，加**MDL写锁**。 **缺点:** 给一个表加字段，或者修改字段，或者加索引，需要扫描全表的数据。只要操作表,就要小心对线上服务造成影响,实际上是非常容易造成影响 ### 行级锁 [Section titled “行级锁”](#行级锁) 行级锁是粒度最低的锁，发生锁冲突的概率也最低、并发度最高。但是加锁慢、开销大，容易发生死锁现象。 MySQL中只有InnoDB支持行级锁，行级锁分为共享锁和排他锁。 #### 行级锁实现方式 [Section titled “行级锁实现方式”](#行级锁实现方式) **在MySQL中，行级锁并不是直接锁记录，而是锁索引**。 索引分为主键索引和非主键索引两种，如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。 在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key lock 临键锁. #### 排他锁(有在业务中使用) [Section titled “排他锁(有在业务中使用)”](#排他锁有在业务中使用) 排它锁，又称之为写锁，简称X锁(E**x**clusive)，当事务对数据加上写锁后，其他事务既不能对该数据添加读写，也不能对该数据添加写锁，写锁与其他锁都是互斥的。只有当前数据写锁被释放后，其他事务才能对其添加写锁或者是读锁。 MySQL InnoDB引擎默认update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型。 **应用场景:** 写锁主要是为了解决在修改数据时，不允许其他事务对当前数据进行修改和读取操作，从而可以有效避免”脏读”问题的产生。 **实现方式:** `select ... for update` #### 共享锁 [Section titled “共享锁”](#共享锁) 共享锁，又称之为读锁，简称S锁(**S**HARE)，当事务A对数据加上读锁后，其他事务只能对该数据加读锁，不能做任何修改操作，也就是不能添加写锁。只有当事务A上的读锁被释放后，其他事务才能对其添加写锁。 **应用场景:** 共享锁主要是为了支持并发的读取数据而出现的，读取数据时，不允许其他事务对当前数据进行修改操作，从而避免”不可重读”的问题的出现。 适合于两张表存在关系时的写操作。 例如parent表和child表,这类的业务类型 **实现方式:** `select ... lock in share mode` ### 页级锁 [Section titled “页级锁”](#页级锁) 页级锁是 MySQL 中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。因此，采取了折衷的**页级锁，一次锁定相邻的一组记录**。 ### MySQL乐观锁 [Section titled “MySQL乐观锁”](#mysql乐观锁) 一般使用数据版本(Version)记录机制实现，在数据库表中增加一个数字类型的“version”字段来实现 ### MySQL悲观锁 [Section titled “MySQL悲观锁”](#mysql悲观锁) `select ... for update` 是MySQL提供的实现悲观锁的方式，属于排它锁。可以保证当前的数据不会被其它事务修改 ### 意向共享锁和意向排它锁 [Section titled “意向共享锁和意向排它锁”](#意向共享锁和意向排它锁) **解释:** 意向锁是表锁，为了协调行锁和表锁的关系，支持多粒度(表锁与行锁)的锁并存。 **作用:** 当有事务A有行锁时，MySQL会自动为该表添加意向锁，事务B如果想申请整个表的写锁，那么**不需要遍历每一行判断是否存在行锁，而直接判断是否存在意向锁**，增强性能。 ### 间隙锁、临键锁、记录锁 [Section titled “间隙锁、临键锁、记录锁”](#间隙锁临键锁记录锁) **解释:** 记录锁、间隙锁、临键锁都是排它锁，而记录锁的使用方法跟排它锁一致。 #### 记录锁 [Section titled “记录锁”](#记录锁) 记录锁是封锁记录，记录锁也叫行锁。 `select ... for update` #### 间隙锁 [Section titled “间隙锁”](#间隙锁) 间隙锁基于非唯一索引，它锁定一段范围内的索引记录。使用间隙锁锁住的是一个区间，而不仅仅是这个区间中的每一条数据。 **1. 什么是间隙锁**:当我们采用范围条件查询数据时，InnoDB 会对这个范围内的数据进行加锁。比如有 id 为: 1、3、5、7 的 4 条数据，我们查找 1-7 范围的数据。那么 1-7 都会被加上锁。2、4、6 也在 1-7 的范围中，但是不存在这些数据记录，这些 2、4、6 就被称为间隙。 **2. 间隙锁的危害**:范围查找时，会把整个范围的数据全部锁定住，即便这个范围内不存在的一些数据，也会被无辜的锁定住，比如我要在 1、3、5、7 中插入 2，这个时候 1-7 都被锁定住了，根本无法插入 2。在某些场景下会对性能产生很大的影响 **3. 间隙锁可以解决幻读** 举例: 表中有一个范围 id 为（3，5）间隙锁，那么其他事务就无法插入 id = 4 这条记录了，这样就有效的防止幻读现象的发生。 #### 临键锁 [Section titled “临键锁”](#临键锁) 临键锁，是记录锁与间隙锁的组合，它的封锁范围，既包含索引记录，又包含索引区间，是一个**左开右闭区间**。临键锁的主要目的，也是为了避免幻读(Phantom Read)。如果把事务的隔离级别降级为RC，临键锁则也会失效。 每个数据行上的非唯一索引列上都会存在一把临键锁，当某个事务持有该数据行的临键锁时，会锁住一段左开右闭区间的数据。需要强调的一点是，InnoDB 中行级锁是基于索引实现的，临键锁只与非唯一索引列有关，在唯一索引列(包括主键列)上不存在临键锁。 举例: 表中有一个范围 id 为（3，5] 的 next-key lock，那么其他事务即不能插入 id = 4 记录，也不能修改 id = 5 这条记录 # MySQL QA > MySQL QA #### MySQL基础架构 [Section titled “MySQL基础架构”](#mysql基础架构)  从上图可以看出,MySQL主要分为Server层和存储引擎层 > Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数(如日期、时间、数学和加密函数等)，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。 > > 存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 **InnoDB**、MyISAM、Memory 等多个存储引擎 * 连接器: 管理链接,权限验证 * 查询缓存: 命中则直接返回结果 * 分析器: 词法分析,语法分析 * 优化器: 执行计划生成,索引选择 * 执行器: 操作引擎,返回结果 * 存储引擎: 存储数据,提供读写接口 #### MySQL表多大才算大? [Section titled “MySQL表多大才算大?”](#mysql表多大才算大) MySQL本身并没有对单表最大记录数进行限制。 阿里巴巴《Java 开发手册》提出单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。 事实上，MySql数据库一张表中能存储的最大数据量和实际记录的条数无关，而**与 MySQL 的配置以及机器的硬件有关**。因为，MySQL 为了提高性能，会将表的索引装载到内存中。InnoDB buffer size 足够的情况下，其能完成全加载进内存，查询不会有问题。 但是，当单表数据库到达某个量级的上限时，导致内存无法存储其索引，使得之后的 SQL 查询会产生磁盘 IO，从而导致性能下降。当然，这个还有具体的表结构的设计有关，最终导致的问题都是内存限制。 #### MySQL表里面的数据删除后,磁盘空间会立马释放吗? [Section titled “MySQL表里面的数据删除后,磁盘空间会立马释放吗?”](#mysql表里面的数据删除后磁盘空间会立马释放吗) 在MySQL中，删除数据的工作原理是**将数据标记为已删除**，而不是立即从磁盘上删除它们。这是因为磁盘上的数据需要被定期清理，以便数据库性能更好。删除大量数据会导致磁盘空间被占用，因此MySQL采用了一种称为“延迟清理”(delayed clean)的机制。 ##### MySQL延迟清理机制的优点 [Section titled “MySQL延迟清理机制的优点”](#mysql延迟清理机制的优点) MySQL使用延迟清理机制的主要优点是提高数据库性能。在删除大量数据时，如果MySQL立即从磁盘上删除数据，则会产生大量的I/O操作，这会影响数据库性能。因此，MySQL选择延迟清理机制来提高性能。 此外，MySQL使用延迟清理机制还可以减少磁盘碎片。磁盘碎片是指磁盘上分散的、不连续的数据块。当MySQL立即删除数据时，磁盘上会产生大量的碎片。然而，使用延迟清理机制可以减少磁盘碎片，并提高磁盘的读写效率。 ##### MySQL延迟清理机制的缺点 [Section titled “MySQL延迟清理机制的缺点”](#mysql延迟清理机制的缺点) 磁盘不足 当数据库中的数据不断增加时，磁盘空间也会相应减少。如果您使用DELETE语句删除数据，磁盘上的空间不会被立即释放，而是会被标记为可用空间。这意味着如果您不定期清理已删除的数据，数据库的磁盘空间将会不断减少，最终可能导致磁盘空间不足的问题。 ##### 如何让MySQL表中的数据立即减少呢? [Section titled “如何让MySQL表中的数据立即减少呢?”](#如何让mysql表中的数据立即减少呢) 1. 在MySQL中，解决磁盘空间不足问题的方法是定期清理已删除的数据。您可以使用`OPTIMIZE TABLE`命令来清理已删除的数据。`OPTIMIZE TABLE`命令会重新组织表，并删除已删除的数据。这样可以释放磁盘空间，并提高数据库性能。 即 `delete` + `optimize table` 的方式。 > `OPTIMIZE TABLE`只对MyISAM, BDB和InnoDB表起作用 2. 直接 `TRUNCATE TABLE` TRUNCATE TABLE命令可以快速删除表中的所有数据，并释放磁盘空间 ##### 如何配置MySQL主从? [Section titled “如何配置MySQL主从?”](#如何配置mysql主从) master机器上配置: ```sh server-id = 1 #[必须]服务器唯一ID，默认是1 log-bin = mysql-bin #[必须]启用二进制日志 #需要开启生成二进制日志记录相关配置，配置在需要被复制的服务器上，即：master binlog-do-db = my_test1 #指定对名称为test_db的数据库记录二进制日志 # binlog-ignore-db = mysql #指定不对名称为mysql的数据库记录二进制日 binlog_format = mixed #binlog日志格式，mysql默认采用，如果从服务器slave有别的slave要复制那么该slave也需要这一项 expire_logs_days = 7 #超过7天的binlog删除 ``` slave机器上配置: ```sh server-id = 2 # replicate-do-db 需要做复制的数据库,如果复制多个数据库，重复设置这选项即可master上不需要此项，slave上需要 replicate-do-db = my_test1 #复制名称为test_db的数据库 # replicate-ignore-db 不需要复制的数据库，如果要忽略复制多个数据库，重复设置这个选项即可 # replicate-ignore-db = mysql #不需要(忽略)复制名称为mysql的数据库 ``` ##### 如何配置MySQL集群? —— MHA [Section titled “如何配置MySQL集群? —— MHA”](#如何配置mysql集群--mha) MHA(Master High Availability)方案,该方案有两部分组成: MHA Manager(管理节点)和 MHA Node(数据节点) MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。 目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器. 具体配置可以参考 [MySQL集群高可用架构之MHA](https://mp.weixin.qq.com/s?__biz=MzI0MDQ4MTM5NQ==\&mid=2247484990\&idx=1\&sn=e6b5c0bde0b1f88cf5fe6a59b85a1d4c\&chksm=e91b6322de6cea34ba1ad08943fc33a5075481d04cbb48cce9af934efd6bf7c3152317a7d659\&scene=21#wechat_redirect) #### MySQL为什么使用树结构？ [Section titled “MySQL为什么使用树结构？”](#mysql为什么使用树结构) 1. 文件很大，不可能全部存储在内存中，故要存储到磁盘上 2. 索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数(为什么使用B-/+Tree，还跟磁盘存取原理有关) 3. 局部性原理与磁盘预读，预读的长度一般为页(page)的整倍数(根据操作系统的不同，操作系统有的页大小为4k，有的为16k)。其中MySQL B+树中的 叶/非叶节点 都是以MySQL的页为单位(大小通常也为16k)，存放完整行记录。 4. 数据库系统巧妙利用了磁盘预读原理，将一个节点大小设为操作系统内存页的整数倍(4倍)，这样每个节点只需要一次I/O就可以完全载入。而红黑树这种节构，高度明显要深的多。由于逻辑上很近的节点(父子)物理上可能很远，无法利用局部性。 磁盘读取 计算机系统是分页读取和存储的，一般一页为4KB(8个扇区，每个扇区512B，8\*512B=4KB)，每次读取和存取的最小单元为一页，而磁盘预读时通常会读取页的整倍数。 根据文章上述的【局部性原理】①当一个数据被用到时，其附近的数据也通常会马上被使用。②程序运行期间所需要的数据通常比较集中。由于磁盘顺序读取的效率很高(不需要寻道时间，只需很少的旋转时间)，所以即使只需要读取一个字节，磁盘也会读取一页的数据。 MySQL InnoDB默认的页大小为16k(可通常 innodb\_page\_size 参数设置)，而操作系统中的磁盘页大小通常为4k，所以这里可以认为MySQL InnoDB中的1页(1个磁盘块)相当于操作系统中的4页。 这也就符合MySQL InnoDB所利用到的磁盘预读通常会预读操作系统页的整数倍(4倍) **B+树每一层就是一次IO,3层的B+Tree可以表示2k万的数据，这种量级的数据只发生了三次I/O，时间提升是巨大的。** > **数据:** 一棵高度为2的B+树，能存放1170 \* 16=18720条这样的数据记录。同理一棵高度为3的B+树，能存放1170 \*1170 \*16 =21902400，也就是说，可以存放两千万左右的记录。B+树高度一般为1-3层，已经满足千万级别的数据存储。 #### MySQL一般怎么优化 [Section titled “MySQL一般怎么优化”](#mysql一般怎么优化) SQL优化方式有： * 索引优化 * 查询优化 * 数据表设计优化 ##### 一、索引优化 [Section titled “一、索引优化”](#一索引优化) 索引是提高数据库查询性能的关键因素之一。在SQL查询中，通过建立合理的索引，可以加快数据的检索速度。索引可以理解为数据库表格中的目录，它类似于书中的索引，帮助数据库系统快速定位所需数据。以下是索引优化的一些关键方式： * 主键索引：为每个表格设置主键索引，主键索引可以保证表格中的数据少数性，并且自带聚集索引的特性，能够有效加快查询速度。 * 少数索引：对于需要保证少数性的字段，可以创建少数索引，以防止重复数据的插入，提高数据插入的效率。 * 组合索引：对于经常同时查询多个字段的情况，可以创建组合索引，将多个字段一起构成索引，以提高联合查询的效率。 * 稀疏索引：对于稀疏数据列，可以使用稀疏索引，减少索引的存储空间。 * 避免过多索引：尽量避免在一个表格中创建过多的索引，过多的索引会增加数据库的维护成本，降低查询性能。 ##### 二、查询优化 [Section titled “二、查询优化”](#二查询优化) 查询优化是SQL优化的核心内容，合理优化查询语句可以大幅提高数据库的查询效率。以下是查询优化的一些关键方式： * 避免使用通配符：在查询语句中避免使用通配符（如“%”），通配符查询会导致全表扫描，降低查询性能。 * 使用JOIN语句：合理使用JOIN语句可以将多个表格连接在一起，减少查询次数，提高查询效率。 * 避免使用子查询：子查询会导致嵌套查询，降低查询性能，尽量避免使用不必要的子查询。 * 使用EXISTS或IN语句：在查询需要判断某个条件是否存在时，优先使用EXISTS或IN语句，它们的性能通常比COUNT()函数更高效。 * 优化WHERE条件：在WHERE条件中使用索引字段可以提高查询效率，避免使用函数操作符或类型转换，这会导致索引失效。 ##### 三、数据表设计优化 [Section titled “三、数据表设计优化”](#三数据表设计优化) 数据表的设计直接影响到SQL查询的性能，合理的数据表设计可以提高数据的存储效率和查询效率。以下是数据表设计优化的一些关键方式： * 规范化设计：遵循数据库规范化原则，将数据分解成多个相关联的表格，以避免数据冗余和更新异常。 * 避免使用过多的字段：在设计数据表时，避免使用过多的字段，将字段设计简洁明了，减少数据表的存储空间和查询成本。 * 使用合适的数据类型：选择合适的数据类型可以减少数据表的存储空间，提高数据插入和查询的效率。 * 分区表设计：对于大型数据表，可以采用分区表设计，将数据按照一定规则划分成多个分区，提高查询效率。 * 冗余表设计：对于频繁查询的数据，可以创建冗余表，避免频繁连接查询，提高查询速度。 ##### 除了索引优化、查询优化和数据表设计优化，还有其他一些优化技巧可以进一步提升SQL查询的性能。以下是一些其他优化技巧： [Section titled “除了索引优化、查询优化和数据表设计优化，还有其他一些优化技巧可以进一步提升SQL查询的性能。以下是一些其他优化技巧：”](#除了索引优化查询优化和数据表设计优化还有其他一些优化技巧可以进一步提升sql查询的性能以下是一些其他优化技巧) * 预编译查询：使用预编译查询可以将SQL语句编译为二进制代码，并缓存起来，减少重复编译的开销，提高查询性能。 * 使用连接池：连接池可以预先创建和管理数据库连接，避免频繁创建和销毁连接，提高连接的复用率和查询效率。 * 分批次查询：对于大数据量的查询，可以采用分批次查询的方式，分批次获取数据，减少内存开销和数据库负载。 * 定期维护：定期进行数据库的维护工作，如索引重建、表格优化、数据清理等，以保持数据库的良好性能。 * 使用缓存：对于频繁查询的数据，可以使用缓存技术，将数据缓存到内存中，提高数据访问速度。 在进行SQL优化时，需要根据具体场景和业务需求，综合考虑各种优化方式，确保数据库系统能够高效、稳定地处理大量数据和查询请求。优化SQL查询是一个持续优化的过程，只有不断优化和改进，才能保障数据库系统的稳定性、高效性和可靠性。 #### MySQL 8 新增了哪些特性 [Section titled “MySQL 8 新增了哪些特性”](#mysql-8-新增了哪些特性) > 8.0版本是5.7版本后的跨越大版本 以下新特性: * 大表秒级加列,只改数据字典表的元数据信息。5.7的版本加列需要重建表（消耗大量的IO资源和时间），8.0加列没有这个步骤。秒级加列(不要指定列位置，如after str1) * 文档数据库 * NoSQL + SQL = MySQL * 多文档事务，ACID特性 * 支持更新JSON中部分filed * SQL增强。共用表表达式(CTEs)和窗口函数是报表、OLAP业务一大利器 * 不可见索引。SQL执行时内部优化器忽略指定索引；验证删除索引后对查询性能影响。 ```sh Alter table t1 alter index idx_str invisible或者visible; ``` * 降序索引(Descending Indexes):索引按倒序存储，之前方式都是按顺序存储；使用到具有倒序、升序列的复合索引 * 函数索引(Functional Indexes): `select * from moatkon where year(date_str)=2023;` 也可以使用到索引 * 默认字符集为utf8mb4。更好的存储补充字符，如emojis表情符号;可变长度编码字符性能提升 * 一致性查询改进（Better Handling of Hot Rows): * SKIP LOCKED: 需要加锁的记录若被其它线程占有锁，则跳过，而不是等待 * NOWAIT: 需要加锁的记录有锁则报错 > SKIP LOCKED和NOWAIT的使用场景: 适合热行(Hot Rows)场景,例如秒杀,抢红包之类的业务 * 资源组（Resource Groups): 线程赋给不同的资源组;资源组和不同的内存、IO、CPU(现仅支持)进行关联;官方版多租户资源隔离成为了可能，更好提升在不同读写业务场景下的性能 * 新的数据字典:以前版本MySQL数据字典存放在多个地方，一机器多实例时存在大量文件描述符性能消耗，8.0版本都存放在事务性InnoDB表，MySQL异常挂掉后也不会再出现表损坏情况；DDL操作失败也不会再留下占空间的“临时文件” * 基于innodb的库表元数据信息 * 增强了MySQL crash-safe能力 * 原子DDL（ Atomic DDLs ） * MGR增强: MGR的增强大大提升了在网络异常(机房级故障)下的健壮、稳定性；之前多次的机房故障演练8.0 MGR也都符合预期，网络恢复后MGR节点自动加入group 恢复读写 # DDD-Domain-Driven Design > Domain-Driven Design > 有次面试被问到了 > 本文讨论的是及其复杂的场景下的解决方案,当然绝大多数公司压根就用不到DDD,也没有必要使用DDD。在业务初期,都是业务先行,普通的开发模式完全可以覆盖 DDD核心在 **领域建模** 和 **设计** ### 什么情况下启用DDD? [Section titled “什么情况下启用DDD?”](#什么情况下启用ddd) **过渡耦合** 系统已经达到牵一发而动全身的程度了。原本只想改一个小功能,却不曾想影响核心接口的功能了。虽然重构可以解决,但是确实暂时的,只是解决了庞大系统中的一小部分痛点,长期来看,类似的问题并没有被彻底解决。 用DDD则可以解决领域模型到设计模型的同步、演化，最后再将反映了领域的设计模型转为实际的代码。 模型是我们解决实际问题所抽象出来的概念模型 * 领域模型则表达与业务相关的事实 * 设计模型则描述了所要构建的系统 ### 什么是贫血症和失忆症 [Section titled “什么是贫血症和失忆症”](#什么是贫血症和失忆症) 贫血领域对象（Anemic Domain Object）是指仅用作数据载体，而没有行为和动作的领域对象。—— 在大部分公司都是这样,对象只是数据的载体，没有行为。 业务逻辑复杂时，业务逻辑、状态会散落到在大量方法中，原本的代码意图会渐渐不明确，我们将这种情况称为由贫血症引起的失忆症。因为我做电商系统做的比较多,就经常会遇到这个问题,一个订单的状态散落的到处都是,如果对系统代码不熟悉或者对业务不熟悉,经常会奔波在修Bug的途中,不是这里缺少,就是那里缺少 ### 解决大规模和复杂的软件可以通过哪些方法 [Section titled “解决大规模和复杂的软件可以通过哪些方法”](#解决大规模和复杂的软件可以通过哪些方法) * 分而治之。将大的问题划分。模板就是在每一个分支内实现高内聚低耦合 * 抽象。先不谈具体的实现,直接说出怎么可以做到。举一个简单的例子,我饿了,我要吃东西。而不是优先考虑我要吃什么,是吃面还是吃饭。这个就是一个抽象 * 框架。DDD就是一种,按照成熟的框架,在这个框架内做好该做的事。所谓的框架更多的是一种限制,是一种高效。在大的框架内做事,绝对比自己或者靠团队的臆想靠谱的多,会减少很多不必要的低级错误。 #### 分而治之 [Section titled “分而治之”](#分而治之) 一般通过2个维度进行,即技术维度和业务维度。技术维度就是分层,例如我们常用的MVC模式,业务维度则考研对于业务的理解,需要划分出业务领域。 我们经常聊的微服务其实就是从业务维度来划分的。例如订单服务、商品服务等等。那这里的DDD和微服务的区别在哪里呢? 我们一般做架构设计时,主要集中在一下3个方面:  * 业务架构: 根据业务需求设计业务模块及其关系 * 系统架构: 设计系统和子系统的模块 * 技术架构: 决定采用的技术及框架 熟悉了这3个方面之后,就可以说区别了。DDD的侧重点是业务架构,而微服务侧重于系统架构和技术架构,以一套系统架构和技术架构来承接所有的业务,在常规模式下会一直用很久;而DDD的业务架构,总是业务先行,在响应业务变化调整业务架构时,系统架构也会随着业务架构来调整,所以DDD是在一直服务着业务,一点点的逼迫技术靠近业务,而不是想微服务架构一样,吃老本。 不知道你们在日常工作中,会不会遇到这种场景,就是业务提一个需求,技术就是暂时的系统能力支撑不了。这个其实技术就很被动,也是微服务架构会带来的问题。如果使用DDD架构,则这种问题会少很多,也不是说完全没有哈,只是DDD这种模式的运行会让技术慢慢的贴合业务,所以当业务提出新的诉求时,才不会有那么多不能支撑的时候。 ### 设计领域模型的一般步骤 [Section titled “设计领域模型的一般步骤”](#设计领域模型的一般步骤) 1. 根据需求划分出初步的领域和限界上下文，以及上下文之间的关系； 2. 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象； 3. 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根； 4. 为聚合根设计仓储，并思考实体或值对象的创建方式； 5. 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。 #### 限界上下文 [Section titled “限界上下文”](#限界上下文) 一个由显示边界限定的特定职责。领域模型便存在于这个边界之内。在边界内，每一个模型概念，包括它的属性和操作，都具有特殊的含义。 #### 如何划分限界上下文 [Section titled “如何划分限界上下文”](#如何划分限界上下文) 实际操作过程中,要根据产品需求来,这是根本。当然这并不是一次就能搞定的事情,在后面的开发中可能还会不断的推翻及重构 #### 清晰的上下文划分的好处 [Section titled “清晰的上下文划分的好处”](#清晰的上下文划分的好处) 1. 任务拆分方便 2. 成员之间沟通方便 3. 如果是跨团队的,则沟通便利 ### 细化上下文 [Section titled “细化上下文”](#细化上下文) * 实体: 当一个对象由其标识（而不是属性）区分时，这种对象称为实体（Entity）。理解上来说就是id,例如,人可以通过身份证号这种独一无二的标识来进行区分。而不是人的属性,例如身高,年龄等 * 值对象: 当一个对象用于对事物进行描述而没有唯一标识时，它被称作值对象（Value Object）。例如年龄28岁。使用值对象,可以更好的做系统优化和设计的精简优化。在实践中，需要保证值对象创建后就不能被修改，即不允许外部再修改其属性。 * 聚合根: 聚合一组相关对象的集合，作为一个整体被外界访问，聚合根是这个聚合的根节点。聚合由根实体、值对象和实体构成。聚合是一个非常重要的概念，核心领域往往都需要用聚合来表达。其次，聚合在技术上有非常高的价值，可以指导详细设计。 * 领域服务: 一些重要的领域行为或操作，可以归类为领域服务。它既不是实体，也不是值对象的范畴。当我们采用了微服务架构风格，一切领域逻辑的对外暴露均需要通过领域服务来进行。如原本由聚合根暴露的业务逻辑也需要依托于领域服务。 * 领域事件: 领域事件是对领域内发生的活动进行的建模 #### 如何创建好聚合? [Section titled “如何创建好聚合?”](#如何创建好聚合) * **边界内的内容具有一致性**：在一个事务中只修改一个聚合实例。如果你发现边界内很难接受强一致，不管是出于性能或产品需求的考虑，应该考虑剥离出独立的聚合，采用最终一致的方式。 * **设计小聚合**：大部分的聚合都可以只包含根实体，而无需包含其他实体。即使一定要包含，可以考虑将其创建为值对象。 * **通过唯一标识来引用其他聚合或实体**：当存在对象之间的关联时，建议引用其唯一标识而非引用其整体对象。如果是外部上下文中的实体，引用其唯一标识或将需要的属性构造值对象。 如果聚合创建复杂，推荐使用工厂方法来屏蔽内部复杂的创建逻辑。 ### DDD的工程 [Section titled “DDD的工程”](#ddd的工程) 落地 #### 模块 [Section titled “模块”](#模块) 一般的工程中包的组织方式为{com.公司名.业务.上下文.\*}，这样的组织结构能够明确的将一个上下文限定在包的内部。 ```java import com.moatkon.bussiness.order.*; // 订单上下文 import com.moatkon.bussiness.goods.*; // 商品上下文 ``` 对于模块内的组织结构，一般情况下我们是按照领域对象、领域服务、领域资源库、防腐层等组织方式定义的。 ```java import com.moatkon.bussiness.order.domain.valobj.*; // 值对象 import com.moatkon.bussiness.order.domain.entity.*; // 对象 import com.moatkon.bussiness.order.domain.aggregate.*; // 聚合根 import com.moatkon.bussiness.order.domain.service.*; // 领域服务 import com.moatkon.bussiness.order.domain.repo.*; // 资源库 import com.moatkon.bussiness.order.domain.facade.*; // 防腐层 ``` #### 上下文集成 [Section titled “上下文集成”](#上下文集成) 通常集成上下文的手段有多种，常见的手段包括开放领域服务接口、开放HTTP服务以及消息发布-订阅机制等 *** * 防腐层(适配层): 通过适配器和转换,和另一个上下文交互。做隔离 * 在DDD的落地过程中,要灵活 参考: [领域驱动设计在互联网业务开发中的实践](https://tech.meituan.com/2017/12/22/ddd-in-practice.html?utm_source=moatkon.com) # DDD在公司的实践记录 > DDD在公司的实践记录 > 初步实践,有很多不足的地方,请多多指教 ### Domain Primitive [Section titled “Domain Primitive”](#domain-primitive) 可以理解为DDD的基础数据类型。 Primitive定义: 不从任何其他事物发展而来;初级的形成或生长的早期阶段。例如OrderNo数据类型。 DP在DDD中是一切模型、方法、架构的基础 #### 案例分析 [Section titled “案例分析”](#案例分析) 反例: ```java User register(String name, String phone, String address) User findByName(String name); User findByPhone(String phone); User findByNameAndPhone(String name, String phone); ``` 接口清晰度不够,在运行时其实是如下的内容: ```java User register(String, String, String); // 容易传错顺序 User findByName(String); // 只能靠方法名来知晓方法的意图 User findByPhone(String); User findByNameAndPhone(String, String); // 容易传错顺序 ``` 在编译时不会报错,只会在运行时可能会报错。如果用了DP就可以解决这个问题: 正例: ```java public User register(Name, PhoneNumber, Address) ``` > DRY原则: Don’t Repeat Yourself. 简单来讲，写代码的时候，如果出现雷同片段，就要想办法把他们提取出来，成为一段独立的代码。这样的抽象，可以保证任何调用这段代码的程序都能得到一致的结果；同时在需要修改时也能保证所有调用处都能获得更新。 #### 如何识别和提取DP? [Section titled “如何识别和提取DP?”](#如何识别和提取dp) 1. 将隐性的概念显性化(Make Implicit Concepts Explicit). 显性化的对象称之为Value Object,即VO。一般来说 VO 都是 Immutable 的。VO里面的属性使用final修饰 VO其实是生成了一个 Type（数据类型）和一个 Class（类）： * Type 指我们在今后的代码里可以通过 PhoneNumber 去显性的标识电话号这个概念 * Class 指我们可以把所有跟电话号相关的逻辑完整的收集到一个文件里 2. 将 隐性的 上下文 显性化(Make Implicit Context Explicit) 将相关的对象合并为一个VO。而这种相关的对象则称之为上下文 反例: ```java public void pay(BigDecimal money, Long recipientId) { BankService.transfer(money, "CNY", recipientId); } ``` 正例: ```java @Value public class Money { private BigDecimal amount; private Currency currency; public Money(BigDecimal amount, Currency currency) { this.amount = amount; this.currency = currency; } } ``` 将默认货币这个隐性的上下文概念显性化，并且和金额合并为 Money 3. 封装 多对象 行为 (Encapsulate Multi-Object Behavior) 反例: ```java public void pay(Money money, Currency targetCurrency, Long recipientId) { if (money.getCurrency().equals(targetCurrency)) { BankService.transfer(money, recipientId); } else { BigDecimal rate = ExchangeService.getRate(money.getCurrency(), targetCurrency); BigDecimal targetAmount = money.getAmount().multiply(new BigDecimal(rate)); Money targetMoney = new Money(targetAmount, targetCurrency); BankService.transfer(targetMoney, recipientId); } } ``` 这个case最大的问题在于，金额的计算被包含在了支付的服务中，涉及到的对象也有2个 Currency ，2 个 Money ，1 个 BigDecimal ，总共 5 个对象。这种涉及到多个对象的业务逻辑，需要用 DP 包装掉 正例: ```java @Value public class ExchangeRate { private BigDecimal rate; private Currency from; private Currency to; public ExchangeRate(BigDecimal rate, Currency from, Currency to) { this.rate = rate; this.from = from; this.to = to; } public Money exchange(Money fromMoney) { notNull(fromMoney); isTrue(this.from.equals(fromMoney.getCurrency())); BigDecimal targetAmount = fromMoney.getAmount().multiply(rate); return new Money(targetAmount, to); } } ``` ExchangeRate 汇率对象，通过封装金额计算逻辑以及各种校验逻辑,让原始代码 ```java public void pay(Money money, Currency targetCurrency, Long recipientId) { ExchangeRate rate = ExchangeService.getRate(money.getCurrency(), targetCurrency); Money targetMoney = rate.exchange(money); BankService.transfer(targetMoney, recipientId); } ``` #### DP、VO、DTO [Section titled “DP、VO、DTO”](#dpvodto) Domain Primitive 是 Value Object 的进阶版，在原始 VO 的基础上要求每个 DP 拥有概念的整体，而不仅仅是值对象。在 VO 的 Immutable 基础上增加了 Validity 和行为。当然同样的要求无副作用（side-effect free）。   * Entity: 一个实体（Entity）是拥有ID的域对象，**除了拥有数据之外，同时拥有行为**。Entity和数据库储存格式无关，在设计中要以该领域的通用严谨语言（Ubiquitous Language）为依据。(这里可以理解*聚合根*) > 例如,Account 是**基于领域逻辑的实体类**，它的字段和数据库储存不需要有必然的联系。Entity包含数据，同时也应该包含行为。在 Account 里，字段也不仅仅是String等基础类型，**而应该尽可能用Domain Primitive代替，可以避免大量的校验代码** * Repository只负责Entity对象的存储和读取. * Repository的修改方法出参和入参都应该是Entity. * 对于查询,Repository的入参可以是DP,例如AccountId,AccountNumber,UserId等 > DAO对应的是一个特定的数据库类型的操作，相当于SQL的封装。**所有操作的对象都是DO类**，所有接口都可以根据数据库实现的不同而改变 > > Repository对应的是**Entity对象**读取储存的抽象，在接口层面做统一，不关注底层实现。 Repository的具体实现类通过调用DAO来实现各种操作，通过Builder/Factory对象实现AccountDO 到 Account之间的转化 * DO: 单纯的和数据库表的映射关系，每个字段对应数据库表的一个column，这种对象叫Data Object。DO只有数据，没有行为。 #### 使用DP的场景 [Section titled “使用DP的场景”](#使用dp的场景) * 有格式限制的 String：比如Name，PhoneNumber，OrderNumber，ZipCode，Address等 * 有限制的Integer：比如OrderId（>0），Percentage（0-100%），Quantity（>=0）等 * 可枚举的 int ：比如 Status（一般不用Enum因为反序列化问题） * Double 或 BigDecimal：一般用到的 Double 或 BigDecimal 都是有业务含义的，比如 Temperature、Money、Amount、ExchangeRate、Rating 等 * 复杂的数据结构：比如 Map\ 等，尽量能把 Map 的所有操作包装掉，仅暴露必要行为 #### 总结 [Section titled “总结”](#总结) Domain Primitive 是一个在特定领域里，拥有精准定义的、可自我验证的、拥有行为的 Value Object * DP是一个传统意义上的Value Object，拥有Immutable的特性 * DP是一个完整的概念整体，拥有精准定义 * DP使用业务域中的原生语言 * DP可以是业务域的最小组成部分、也可以构建复杂组合 ### 防腐层Anti-Corruption Layer [Section titled “防腐层Anti-Corruption Layer”](#防腐层anti-corruption-layer) 很多时候我们的系统会去依赖其他的系统，而被依赖的系统可能包含不合理的数据结构、API、协议或技术实现，如果对外部系统强依赖，会导致我们的系统被”腐蚀“。这个时候，通过在系统间加入一个防腐层，能够有效的隔离外部依赖和内部逻辑，无论外部如何变更，内部代码可以尽可能的保持不变。 因为现在的DB独立为原子服务了,将原子服务也纳入到防腐层 建立ACL的优点: * 适配器：很多时候外部依赖的数据、接口和协议并不符合内部规范，通过适配器模式，可以将数据转化逻辑封装到ACL内部，降低对业务代码的侵入。 * 缓存：对于频繁调用且数据变更不频繁的外部依赖，通过在ACL里嵌入缓存逻辑，能够有效的降低对于外部依赖的请求压力。同时，很多时候缓存逻辑是写在业务代码里的，通过将缓存逻辑嵌入ACL，能够降低业务代码的复杂度。 * 兜底：如果外部依赖的稳定性较差，一个能够有效提升我们系统稳定性的策略是通过ACL起到兜底的作用，比如当外部依赖出问题后，返回最近一次成功的缓存或业务兜底数据。这种兜底逻辑一般都比较复杂，如果散落在核心业务代码中会很难维护，通过集中在ACL中，更加容易被测试和修改。 * 易于测试：类似于之前的Repository，ACL的接口类能够很容易的实现Mock或Stub，以便于单元测试。 * 功能开关：有些时候我们希望能在某些场景下开放或关闭某个接口的功能，或者让某个接口返回一个特定的值，我们可以在ACL配置功能开关来实现，而不会对真实业务代码造成影响。同时，使用功能开关也能让我们容易的实现Monkey测试，而不需要真正物理性的关闭外部依赖。 #### ACL防腐层的简单原理 [Section titled “ACL防腐层的简单原理”](#acl防腐层的简单原理) * 对于依赖的外部对象，我们抽取出所需要的字段，生成一个内部所需的VO或DTO类 * 构建一个新的Facade，在Facade中封装调用链路，将外部类转化为内部类 * 针对外部系统调用，同样的用Facade方法封装外部调用链路 在一些理论框架里ACL Facade也被叫做Gateway，含义是一样的 #### Repository和Entity [Section titled “Repository和Entity”](#repository和entity) * 通过Account对象，避免了其他业务逻辑代码和数据库的直接耦合，避免了当数据库字段变化时，大量业务逻辑也跟着变的问题。 * 通过Repository，改变业务代码的思维方式，让业务逻辑不再面向数据库编程，而是面向领域模型编程。 * Account属于一个完整的内存中对象，可以比较容易的做完整的测试覆盖，包含其行为。 * Repository作为一个接口类，可以比较容易的实现Mock或Stub，可以很容易测试。 * AccountRepositoryImpl实现类，由于其职责被单一出来，只需要关注Account到AccountDO的映射关系和Repository方法到DAO方法之间的映射关系，相对于来说更容易测试。 #### 通过Entity、Domain Primitive和Domain Service封装所有的业务逻辑 [Section titled “通过Entity、Domain Primitive和Domain Service封装所有的业务逻辑”](#通过entitydomain-primitive和domain-service封装所有的业务逻辑) 有很多业务逻辑是跟外部依赖的代码混合的，包括金额计算、账户余额的校验、转账限制、金额增减等。这种逻辑混淆导致了核心计算逻辑无法被有效的测试和复用。 Domain Service出现的场景可以参考以下描述: ```java sourceAccount.deposit(sourceMoney); //转入 targetAccount.withdraw(targetMoney); //转出 ``` 这两个账号的转出和转入实际上是一体的，也就是说这种行为应该被封装到一个对象中去。特别是考虑到未来这个逻辑可能会产生变化：比如增加一个扣手续费的逻辑。这个时候在原有的TransferService中做并不合适，在任何一个Entity或者Domain Primitive里也不合适，需要有一个新的类去包含跨域对象的行为。这种对象叫做Domain Service。 > 总结: 就是将一个统一的行为,且这个行为影响同一个实体的多个示例的的,应当提取为一个DomainService ### 六边型架构 [Section titled “六边型架构”](#六边型架构)  > 我们会发现每一个对外部的抽象类其实就是输入或输出，类似于计算机系统中的I/O节点。这个观点在CQRS架构中也同样适用，将所有接口分为Command（输入）和Query（输出）两种。 在这张图中： * I/O的具体实现在模型的最外层 * 每个I/O的适配器在灰色地带 * 每个Hex的边是一个端口 * Hex的中央是应用的核心领域模型 在Hex中，架构的组织关系第一次变成了一个二维的内外关系，而不是传统一维的上下关系。同时在Hex架构中我们第一次发现UI层、DB层、和各种中间件层实际上是没有本质上区别的，都只是数据的输入和输出，而不是在传统架构中的最上层和最下层。 ### DDD代码的演进/变化速度 [Section titled “DDD代码的演进/变化速度”](#ddd代码的演进变化速度) 在传统架构中，代码从上到下的变化速度基本上是一致的，改个需求需要从接口、到业务逻辑、到数据库全量变更，而第三方变更可能会导致整个代码的重写。但是在DDD中不同模块的代码的演进速度是不一样的： * Domain层属于核心业务逻辑，属于经常被修改的地方。比如：原来不需要扣手续费，现在需要了之类的。通过Entity能够解决基于单个对象的逻辑变更，通过Domain Service解决多个对象间的业务逻辑变更。 * Application层属于Use Case（业务用例）。业务用例一般都是描述比较大方向的需求，接口相对稳定，特别是对外的接口一般不会频繁变更。添加业务用例可以通过新增Application Service或者新增接口实现功能的扩展。 * Infrastructure层属于最低频变更的。一般这个层的模块只有在外部依赖变更了之后才会跟着升级，而外部依赖的变更频率一般远低于业务逻辑的变更频率。 所以在DDD架构中，能明显看出越外层的代码越稳定，越内层的代码演进越快，真正体现了 **领域“驱动”** 的核心思想。 *** ### 贫血模型 [Section titled “贫血模型”](#贫血模型) 很多Java开发对Entity的理解停留在了数据映射层面，忽略了Entity实体的本身行为，造成今天很多的模型仅包含了实体的数据和属性，而所有的业务逻辑都被分散在多个服务、Controller、Utils工具类中，这个就是Martin Fowler所说的的Anemic Domain Model（贫血领域模型）。 贫血模型的缺陷: * 无法保护模型对象的完整性和一致性：因为对象的所有属性都是公开的，只能由调用方来维护模型的一致性，而这个是没有保障的； * 对象操作的可发现性极差：单纯从对象的属性上很难看出来都有哪些业务逻辑，什么时候可以被调用，以及可以赋值的边界是什么； * 代码逻辑重复：比如校验逻辑、计算逻辑，都很容易出现在多个服务、多个代码块里，提升维护成本和bug出现的概率；一类常见的bug就是当贫血模型变更后，校验逻辑由于出现在多个地方，没有能跟着变，导致校验失败或失效。 * 代码的健壮性差：比如一个数据模型的变化可能导致从上到下的所有代码的变更 * 强依赖底层实现：业务代码里强依赖了底层数据库、网络/中间件协议、第三方服务等，造成核心逻辑代码的僵化且维护成本高。 贫血模型泛滥的原因: * 数据库思维：从有了数据库的那一天起，开发人员的思考方式就逐渐从“写业务逻辑“转变为了”写数据库逻辑”，也就是我们经常说的在写CRUD代码。 * 贫血模型“简单”：贫血模型的优势在于“简单”，仅仅是对数据库表的字段映射，所以可以从前到后用统一格式串通。这里简单打了引号，是因为它只是表面上的简单，实际上当未来有模型变更时，你会发现其实并不简单，每次变更都是非常复杂的事情 * 脚本思维：很多常见的代码都属于“脚本”或“胶水代码”，也就是流程式代码。脚本代码的好处就是比较容易理解，但长久来看缺乏健壮性，维护成本会越来越高。 要正确认识数据模型和领域模型: * 数据模型（Data Model）：指业务数据该如何持久化，以及数据之间的关系，也就是传统的ER模型； * 业务模型/领域模型（Domain Model）：指业务逻辑中，相关联的数据该如何联动。 #### 解决贫血模型根本方案 [Section titled “解决贫血模型根本方案”](#解决贫血模型根本方案) 就是要在代码里严格区分Data Model和Domain Model。在真实代码结构中，Data Model和 Domain Model实际上会分别在不同的层里，Data Model只存在于数据层，而Domain Model在领域层，而链接了这两层的关键对象，就是Repository。—— *这也是Repository的价值* ### Change-Tracking 变更追踪 [Section titled “Change-Tracking 变更追踪”](#change-tracking-变更追踪) * 基于Snapshot的方案：当数据从DB里取出来后，在内存中保存一份snapshot，然后在数据写入时和snapshot比较。常见的实现如Hibernate * 基于Proxy的方案：当数据从DB里取出来后，通过weaving的方式将所有setter都增加一个切面来判断setter是否被调用以及值是否变更，如果变更则标记为Dirty。在保存时根据Dirty判断是否需要更新。常见的实现如Entity Framework ### 在真实业务中使用DDD的特殊性 [Section titled “在真实业务中使用DDD的特殊性”](#在真实业务中使用ddd的特殊性) 在真实的业务逻辑里，我们的领域模型或多或少的都有一定的“特殊性”，如果100%的要符合DDD规范可能会比较累，所以最主要的是梳理一个对象行为的影响面，然后作出设计决策，即： * 是仅影响单一对象还是多个对象， * 规则未来的拓展性、灵活性， * 性能要求， * 副作用的处理，等等 当然，很多时候一个好的设计是多种因素的取舍，需要大家有一定的积累，真正理解每个架构背后的逻辑和优缺点。一个好的架构师不是有一个正确答案，而是能从多个方案中选出一个最平衡的方案。 #### 使用DDD后的开发方式 [Section titled “使用DDD后的开发方式”](#使用ddd后的开发方式) 我们可能先写Domain层的业务逻辑，然后再写Application层的组件编排，最后才写每个外部依赖的具体实现。**这种架构思路和代码组织结构就叫做Domain-Driven Design（领域驱动设计，或DDD）。所以DDD不是一个特殊的架构设计，而是所有Transction Script代码经过合理重构后一定会抵达的终点** ### Orchestration vs Choreography [Section titled “Orchestration vs Choreography”](#orchestration-vs-choreography) Orchestration：通常出现在脑海里的是一个交响乐团（Orchestra，注意这两个词的相似性），如下图。交响乐团的核心是一个唯一的指挥家Conductor，在一个交响乐中，**所有的音乐家必须听从Conductor的指挥做操作，不可以独自发挥**。所以在Orchestration模式中，所有的流程都是由一个节点或服务触发的。我们常见的业务流程代码，包括调用外部服务，就是Orchestration，由我们的服务统一触发。 Choreography：通常会出现在脑海的场景是一个舞剧（来自于希腊文的舞蹈，Choros），如下图。其中每个不同的舞蹈家都在做自己的事，但是没有一个中心化的指挥。通过协作配合，**每个人做好自己的事**，整个舞蹈可以展现出一个完整的、和谐的画面。所以在Choreography模式中，每个服务都是独立的个体，可能会响应外部的一些事件，**但整个系统是一个整体**。   业务流程设计模式： * 没有最好的模式，取决于业务场景、依赖关系、以及是否有业务“负责人”。避免拿着锤子找钉子。 *** 参考内容: * * 详细的示例 + 架构说明 + 包结构说明 * * * 完整的案例 这里提到最多的就是单一职责 # DDD分层规范文档 > DDD分层规范文档 ## **1. 引言** [Section titled “1. 引言”](#1-引言) 本文档旨在提供一套一心堂研发内部标准的领域驱动设计（DDD）分层架构规范。其核心目标是： * **统一架构认知**：在所有团队中建立一致的架构语言和设计准则。 * **明确职责边界**：通过更精细化的分层，清晰定义各模块的职责，防止业务逻辑泄露和代码腐化。 * **提升协作效率**：通过标准化的sdk契约模块，实现安全、高效的跨域（Bounded Context）交互。 * **保障系统演进**：使每个业务域能够独立、安全地进行开发、部署和扩展。 ## **2. 核心原则** [Section titled “2. 核心原则”](#2-核心原则) * **业务域独立 (Bounded Context First)**：每个业务域都是一个独立的Maven项目，拥有自己的代码仓库（Git Repo），代码仓库本身即定义了团队所有权。 * **精细化分层 (Fine-grained Layering)**：严格遵循表现层、应用层、领域层、基础设施层的四层架构思想。 * **依赖倒置 (Dependency Inversion Principle)**：高层模块不依赖于低层模块的具体实现。领域层是整个架构的核心，不依赖于任何其他层。 * **面向接口编程 (Programming to an Interface)**：所有跨层或需要灵活替换的服务，都应通过接口进行通信。 ## **3. 通用项目结构规范** [Section titled “3. 通用项目结构规范”](#3-通用项目结构规范) 为了实现规范的通用性，我们使用占位符 {business-domain}。在实际创建项目时，请替换为具体的业务名称（例如：order, product, user）。 ### **3.1 标准化多模块结构树** [Section titled “3.1 标准化多模块结构树”](#31-标准化多模块结构树) 一个独立的业务域项目 project-root 的标准结构如下： ```rust {business-domain}-{具体业务} (业务域根项目 - Git Repository Root) ├── pom.xml                           (Parent POM, 管理所有子模块和依赖) │ ├── {business-domain}-bootstrap/      (1. 启动与装配模块) │   ├── pom.xml │   └── src/main/java/com/moatkon/{business-domain}/bootstrap/ │       └── Bootstrap.java            (Spring Boot启动类) │ ├── {business-domain}-interface/      (2. 表现层/适配器模块) │   ├── pom.xml │   └── src/main/java/com/moatkon/{business-domain}/interfaces/ │       ├── controller/                 (RESTful Controllers) │       └── mq/                         (MQ Listeners) │ ├── {business-domain}-application/    (3. 应用层模块) │   ├── pom.xml │   └── src/main/java/com/moatkon/{business-domain}/application/ │       └── impl/                    (应用服务实现) │ ├── {business-domain}-sdk/         (4. 对外接口/契约模块) │   ├── pom.xml │   └── src/main/java/com/moatkon/{business-domain}/sdk/ │       ├── api/                        (供其他域调用的Feign/Dubbo接口) │       ├── dto/                        (数据传输对象 DTO) │       └── event/                      (领域事件定义) │ ├── {business-domain}-domain/        (5. 领域层模块) │   ├── pom.xml │   └── src/main/java/com/moatkon/{business-domain}/domain/ │       ├── aggregate/                 (聚合) │       ├── service/                  (领域服务) │       └── repository/                 (仓储接口) │ └── {business-domain}-infrastructure/ (6. 基础设施层模块)     ├── pom.xml     └── src/main/java/com/moatkon/{business-domain}/infrastructure/       ├── repository/               (持久化实现, 如JPA/MyBatis)       └── external/                (三方服务实现) ``` ### **3.2 模块职责详解** [Section titled “3.2 模块职责详解”](#32-模块职责详解) | | | | | -------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------ | | **模块名** | **核心职责** | **依赖关系** | | {business-domain}-bootstrap | **应用启动入口 (Composition Root)**。负责应用的启动、配置的组装和Bean的装配。这是应用的“main”函数所在。 | 依赖所有其他模块（interface, application, infrastructure） | | {business-domain}-interface | **表现层 (Presentation Layer)**。处理外部输入，如RESTful API请求、MQ消息订阅等。它将外部请求适配到应用层。 | 依赖 application | | {business-domain}-application | **应用层 (Application Layer)**。编排领域服务完成业务用例，管理事务、安全等横切关注点。**不包含业务规则**。 | 依赖 domain 和 sdk (用于调用其他域) | | {business-domain}-sdk | **跨域通信契约 (Anti-Corruption Layer)**。定义对外暴露的能力，供其他业务域调用。**这是团队间协作的边界**。 | **不依赖任何其他内部模块** | | {business-domain}-domain | **核心领域层 (Domain Layer)**。包含所有业务逻辑、规则和状态。**与技术框架完全解耦**。 | **不依赖任何其他层** | | {business-domain}-infrastructure | **基础设施层 (Infrastructure Layer)**。提供技术实现，如数据库访问、消息发送等。 | 依赖 domain (实现其接口) 和 sdk (契约) | ## **4. 分层架构定义与依赖关系** [Section titled “4. 分层架构定义与依赖关系”](#4-分层架构定义与依赖关系) ### **4.1 依赖规则** [Section titled “4.1 依赖规则”](#41-依赖规则) 1. **单向依赖**：依赖关系严格单向。例如 interface 模块依赖 application 模块。 2. **依赖倒置**：domain 层定义接口，infrastructure 层实现接口。应用层和表现层仅依赖于 domain 层的**抽象**。 3. **启动模块 (bootstrap)**：作为应用的“粘合剂”，它依赖所有实现模块，以完成整个应用的组装和启动。 4. **跨域依赖 (sdk)**：任何外部业务域 **必须且只能** 依赖本域的 sdk 模块来进行通信。 ## **5. 命名与协作规范** [Section titled “5. 命名与协作规范”](#5-命名与协作规范) ### **5.1 包名 (Package Name)** [Section titled “5.1 包名 (Package Name)”](#51-包名-package-name) com.moatkon.{business-domain}.{module-name-short} **示例**: * Controller: com.moatkon.archetype.interfaces * 应用服务: com.moatkon.archetype.application * 聚合根: com.moatkon.archetype.domain * 对外API: com.moatkon.archetype.sdk ### **5.2 团队协作与集成** [Section titled “5.2 团队协作与集成”](#52-团队协作与集成) * **契约(SDK)先行**: 在进行跨域功能开发前，提供方团队应先在 sdk 模块中定义好接口和DTO，并发布一个版本。 * **通信方式**: 1. **同步调用**: 通过 sdk 模块定义的 Feign。 2. **异步事件**: 在 sdk 模块中定义事件DTO，通过 infrastructure 层的MQ生产者发送。消费方在 interface 模块中创建MQ监听器。 ## **6. 共享内核 (Shared Kernel)** [Section titled “6. 共享内核 (Shared Kernel)”](#6-共享内核-shared-kernel) * 对于多域共享的核心模型（如UserId, Money），应建立独立的shared-kernel项目。 * shared-kernel 需严格评审。 例如: 订单侧的共享内核是order-framework项目,专注于订单内部共享。order-framework项目内部包含order-common、order-types等子module ## 感悟 [Section titled “感悟”](#感悟) * DDD的魅力在于代码纠错。前提是基于moudle构建的DDD服务,每个Module的代码都要物理隔离。发现一个功能实现不下去的时候，大概率是你写错module了 # DDD项目结构的演变 > DDD项目结构的演变 下图是我们最原始的订单DDD层级划分,第一版和第二版也是依据此来构建整体项目结构的。  一开始,我们是期望domain、infrastructure、通用域和types是被不同的应用通用的 #### 第一版 [Section titled “第一版”](#第一版) * order-service * order-starter/ * … * order-starter-job/ * … * order-starter-sync/ * … * order-interface/ * … * order-interface-job/ * … * order-interface-sync/ * … * order-application/ * … * order-application-job/ * … * order-application-sync/ * … * order-domain/ * … * order-infrastructure/ * … * order-types/ * … * order-common/ * … * pom.xml ##### 缺点 [Section titled “缺点”](#缺点) 可读性不高,和图对应不上,starter、interface、application都平铺开了,moudle很多,对于新同学不友好 #### 第二版 [Section titled “第二版”](#第二版) * order-service * order-starter-parent * order-starter/ * … * order-job-starter/ * … * order-sync-starter/ * … * pom.xml * order-interface-parent * order-interface/ * … * order-interface-job/ * … * order-interface-sync/ * … * pom.xml * order-application-parent * order-application/ * … * order-application-job/ * … * order-application-sync/ * … * pom.xml * order-domain/ * … * order-infrastructure/ * … * order-types/ * … * order-common/ * … * pom.xml ##### 优点 [Section titled “优点”](#优点) 解决了第一版可读性的问题 ##### 缺点 [Section titled “缺点”](#缺点-1) 会增加发版频率,例如只改了order-job应用,但是因为变动改到了domain或infrastructure等复用的moudle,会迫使其他两个应用也要同步发版。这个对于线上服务的稳定性来说是有一定的冲击。 但是换一个角度来思考,如果都发版也是合理的,因为当做bug处理就应该发版。 > 这个其实在我们团队内部是有争议的,经过团队的沟通,我们采用了第三版,拆分。拆分的原因思考后,也是合理的,具体见第三版 #### 第三版 [Section titled “第三版”](#第三版) * order-service * order-bootstrap/ * OrderServiceBootstrap.java * order-interface/ * OrderController.java * order-application/ * OrderApplicatonService.java * order-domain/ * OrderAggragate.java * order-infrastructure/ * … * order-types/ * … * order-common/ * … * pom.xml - order-sync * order-sync-bootstrap/ * … * order-sync-interface/ * … * order-sync-application/ * … * order-sync-domain/ * … * order-sync-infrastructure/ * … * order-sync-types/ * … * order-sync-common/ * … * pom.xml order-service单独拆成一个仓库,用于处理主线业务 order-sync和order-job合并为order-sync服务。处理非核心业务。将job合并到sync的原因经过评估后,差别不大,都是异步的,只不过一个是批处理异步、一个是消费消息的异步。 > 在我之前的公司job和sync是拆开的。所以这里我想说的一点是,符合公司、团队的才是最好的,不一定都要按照某个规范来。大家灵活变通即可 ##### 为什么要拆仓库?为什么不复用底层moudle了? [Section titled “为什么要拆仓库?为什么不复用底层moudle了?”](#为什么要拆仓库为什么不复用底层moudle了) 我先回答第二个问题,为什么不复用底层moudle了?因为每个应用所负责的功能侧重点不同,domain、infrastructure等都会渐渐的产生区别，会变得越来越符合当前应用的职责。故第一个问题也就自然有答案了，就是拆。 既然后面差别会越来越大,还不如趁早拆开。而拆开后就自然而然解决了第二版方案中缺点 #### 总结 [Section titled “总结”](#总结) DDD只是思想,每个人对DDD的理解不同,自然项目结构也会不同,只要能解决问题就行。如果严格按照DDD的规范来做,就有点矫枉过正了。在DDD的实践过程中,允许一定的妥协。 我这里也只是分享出来,仅供大家参考。如果有想法或者建议,欢迎留言讨论 #### 项目结构更新 2024.6.9 [Section titled “项目结构更新 ”](#项目结构更新-) 在实践过程中,发现 * order-types在order-sync服务和order-service中会经常会被使用到,而order-types在order-service中维护,会导致有时并不需要动order-service的代码却因为 需要动order-types而被动到 * order-common在order-sync和order-service中的高度相似,因此可以考虑独立出来 基于以上两点考虑,新建了一个仓库order-framework,用来管理order-types和order-common ##### order-framework [Section titled “order-framework”](#order-framework) * order-framework * order-types/ * … * order-common/ * … * pom.xml ##### order-sync和order-service代码组织结构变化 [Section titled “order-sync和order-service代码组织结构变化”](#order-sync和order-service代码组织结构变化) * order-sync * order-sync-bootstrap/ * … * order-sync-interface/ * … * order-sync-application/ * … * order-sync-domain/ * … * order-sync-infrastructure/ * … * pom.xml - order-service * order-bootstrap/ * … * order-interface/ * … * order-application/ * … * order-domain/ * … * order-infrastructure/ * … * pom.xml # DDD分享 > DDD分享 ## 现在的MVC开发模式有什么问题? [Section titled “现在的MVC开发模式有什么问题?”](#现在的mvc开发模式有什么问题) 现有的业务代码里经常包含了参数校验、数据读取存储、业务计算、调用外部服务、发送消息等多种逻辑。这样的代码样式叫做事务脚本Transaction Script。 事务脚本的写法在实现功能上没什么问题,长久来看主要存在以下几个问题: ##### 1.可维护性差 [Section titled “1.可维护性差”](#1可维护性差) 一个应用最大的成本一般都不是来自于开发阶段，而是应用整个生命周期的总维护成本。有个公式: **可维护性 = 当依赖变化时，有多少代码需要随之改变** * 数据结构的不稳定性。目前的数据结构是和表字段映射的(例如OrderInfo),而数据库的表结构和设计是应用的外部依赖，长远来看都有可能会改变,如果修改或者删除一个字段的可能要走查所有相关联的地方并做出修好。非常耗时且容易出bug * 依赖升级。例如订单的mapper是依赖mybatis的,如果要升级mybatis版本,可能会有一些用法不同,或者以后彻底换一个ORM来做，都是巨大的改动量。且升级版本可能会有一些隐性问题,这是不可预估的 * 第三方依赖不稳定。服务不稳定,接口入参和返回参数变化,这类都是可能会变的 * 中间件更换，从RabbitMQ换到Kafka之类的 * … 如果以上问题频繁出现,那么时间基本上都会被各种库升级、依赖服务升级、中间件升级、jar包冲突等占满，最终这个应用变成了一个不敢升级、不敢部署、不敢写新功能、并且随时会爆发的炸弹 ##### 2.可扩展性差 [Section titled “2.可扩展性差”](#2可扩展性差) **可扩展性 = 做新需求或改逻辑时，需要新增/修改多少代码** * 逻辑和数据存储的相互依赖。当业务逻辑增加变得越来越复杂时，新加入的逻辑很有可能需要对数据库schema或消息格式做变更。而变更了数据格式后会导致原有的其他逻辑需要一起跟着动。 * 业务逻辑无法复用。有的方法为了能复用、兼容多个场景,会添加入参、在里面增加if/else,一旦这种分支逻辑多且参数多就会导致分析代码困难,容易错过边界情况，造成bug。 * … 在事务脚本式的架构下，一般做第一个需求都非常的快，但是做第N个需求时需要的时间很有可能是呈指数级上升的，绝大部分时间花费在老功能的重构和兼容上，最终你的创新速度会跌为0，促使老应用被推翻重构。 ##### 3.可测试性差 [Section titled “3.可测试性差”](#3可测试性差) 除了部分工具类、框架类和中间件类的代码有比较高的测试覆盖之外，我们在日常工作中很难看到业务代码有比较好的测试覆盖，而绝大部分的上线前的测试属于人肉的“集成测试”。 **可测试性 = 运行每个测试用例所花费的时间 \* 每个需求所需要增加的测试用例数量** 可测试性差的原因有: 1. 设施搭建困难。特别是代码中依赖了数据库、第三方服务、中间件等,想跑成一个测试用例,成本非常大。另外也有可能由于依赖的某个节点问题会导致整体的测试时间延长 2. 运行耗时长。大多数的外部依赖调用都是I/O密集型，如跨网络调用、磁盘调用等，而这种I/O调用在测试时需要耗时很久。另一个经常依赖的是笨重的框架如Spring，启动Spring容器通常需要很久。当一个测试用例需要花超过10秒钟才能跑通时，绝大部分开发都不会很频繁的测试。 3. 业务迭代后期场景复杂度高。假如一段脚本中有A、B、C三个子步骤，而每个步骤有N个可能的状态，当多个子步骤耦合度高时，为了完整覆盖所有用例，最多需要有N \* N \* N个测试用例。当耦合的子步骤越多时，需要的测试用例呈指数级增长。一般的情况是可能只测试自己改动的那一小部分。容易导致边界bug #### 造成以上问题的原因主要是违背了以下原则: [Section titled “造成以上问题的原因主要是违背了以下原则:”](#造成以上问题的原因主要是违背了以下原则) * 单一性原则: 单一性原则要求一个对象/类应该只有一个变更的原因 * 依赖反转原则: 依赖反转原则要求在代码中依赖抽象，而不是具体的实现。在常见的写法，会发现KafkaTemplate、MyBatis的DAO实现都属于具体实现 * 开放封闭原则: 开放封闭原则指开放扩展，但是封闭修改 代码中的很多地方违背SRP单一职责原则(例如在Controller层写业务代码),代码复杂度增加、逻辑分支越来越多，最终造成bug或者没人敢重构 ## 订单中台DDD应用架构介绍 [Section titled “订单中台DDD应用架构介绍”](#订单中台ddd应用架构介绍) ### 应用架构图 [Section titled “应用架构图”](#应用架构图)  #### starter层 [Section titled “starter层”](#starter层) Start模块是SpringBoot的启动类 #### interface层 [Section titled “interface层”](#interface层) * 职责：主要负责承接网络协议的转化、Session管理、限流、前置缓存、日志等 * 接口数量：避免所谓的统一API，不必人为限制接口类的数量，每个/每类业务对应一套接口即可，接口参数应该符合业务需求，避免大而全的入参 > 刻意去追求接口的统一通常会导致方法中的参数膨胀，或者导致方法的膨胀,最终会导致越来越难维护 * 接口出参：统一返回ResponseBase * 异常处理：应该捕捉所有异常，避免异常信息的泄漏。可以通过AOP统一处理，避免代码里有大量重复代码。 > 入参转换器: DTO —> Command、Query、Event *规范1：interface层的HTTP和RPC接口，返回值为ResponseBase，捕捉所有异常* *规范2：一个interface层的类应该是“小而美”的，应该是面向“一个单一的业务”或“一类同样需求的业务”，需要尽量避免用同一个类承接不同类型业务的需求* > 规则2符合了Single Responsibility Principle单一职责原则，也就是说一个接口类仅仅会因为一个（或一类）业务的变化而变化,而不会影响其他类 *关于 **规范2*** : 因为在DDD分层架构里，接口类的核心作用仅仅是协议层，每类业务的协议可以是不同的，而真实的业务逻辑会沉淀到应用层。也就是说Interface和Application的关系是多对多的：  业务需求是快速变化的，所以接口层也要跟着快速变化，通过独立的接口层可以避免业务间相互影响。但是我们期望application是相对稳定的,所以没有和接口层一一对应 > 所以,回到订单的DDD应用架构图,也是类似的,starter、interface、application是为了符合SRP原则(module维度,非接口维度),后面的order-doman等是相对稳定的 #### application层 [Section titled “application层”](#application层) 负责**业务流程的编排**，但本身不负责任何业务逻辑,即**胶水代码**,剥离了校验逻辑、领域计算、持久化等逻辑之后的剩余流程。 * 入参：具像化Command、Query、Event对象作为ApplicationService的入参，唯一可以的例外是单ID查询的场景。 * CQE的语意化：CQE对象有语意，不同用例之间语意不同，即使参数一样也要避免复用。即CQE是有明确的”意图“的，所以这个对象必须保证其”正确性“,通过命名和校验来实现 * *规范：CQE对象的校验应该前置，避免在ApplicationService里做参数的校验。可以通过JSR303/380和Spring Validation来实现* * 出参：统一返回DTO，而不是Entity或DO。DTO对象只是数据容器，只是为了和外部交互，所以本身不包含任何逻辑，是贫血对象。 * ApplicationService应该永远返回DTO而不是Entity.因为: * ApplicationService的入参是CQE对象，出参是DTO，这些基本上都属于简单的POJO，来确保Application层的内外互相不影响。 * 降低规则依赖：Entity里面通常会包含业务规则，如果ApplicationService返回Entity，则会导致调用方直接依赖业务规则。如果内部规则变更可能直接影响到外部。 * 通过DTO组合降低成本：Entity是有限的，DTO可以是多个Entity、VO的自由组合，一次性封装成复杂DTO，或者有选择的抽取部分参数封装成DTO可以降低对外的成本。 * CQE的语意化：CQE对象有语意，不同用例之间语意不同，即使参数一样也要**避免复用**,禁止类似继承已有的CQE对象的操作。 * 异常处理：不统一捕捉异常，可以随意抛异常。 * DTO转化：用DTO Assembler负责Entity/VO到DTO的转化。 > 转换器: 领域模型转换为可以对外的DTO *规范：Application层的所有接口返回值为DTO，不负责处理异常。除非需要特殊处理，否则不需要刻意捕捉异常* 拓展补充 Command、Query、Event从本质上来看，这几种对象都是Value Object,但是从语义上来看有比较大的差异: * Command指令：指调用方明确想让系统操作的指令，其预期是对一个系统有影响，也就是写操作。通常来讲指令需要有一个明确的返回值（如同步的操作结果，或异步的指令已经被接受）。 * Query查询：指调用方明确想查询的东西，包括查询参数、过滤、分页等条件，其预期是对一个系统的数据完全不影响的，也就是只读操作。 * Event事件：指一件已经发生过的既有事实，需要系统根据这个事实作出改变或者响应的，通常事件处理都会有一定的写操作。事件处理器不会有返回值。这里需要注意一下的是，Application层的Event概念和Domain层的DomainEvent是类似的概念，但不一定是同一回事，这里的Event更多是**外部**一种通知机制而已。 **Value Object的概念** * 没有唯一标识 * 更关注其数据属性 故: * ValueObject不会「单独存在」，而是附属于某个Entity * ValueObject的生命周期会与所附属的Entity绑定在一起 Entity和Value Object的概念比较抽象，这里使用一个例子来解释: **如何判断application层是流程的编排,而不是业务逻辑** 1. 不要有if/else分支逻辑,让代码的Cyclomatic Complexity（循环复杂度）应该*尽量*等于1,不是一定等于1,因为某些场景可以包含if/else,例如中断条件,比如订单不存在,可以使用if/else,因为测试的终端属于Precondition 2. 不要有任何计算 3. 不要有具体的数据转换操作 **应用服务异常** Application层只返回DTO，可以直接抛异常，不用统一处理。所有调用到的服务也都可以直接抛异常，除非需要特殊处理，否则不需要刻意捕捉异常 异常的好处是能明确的知道错误的来源，堆栈等，在Interface层统一捕捉异常是为了避免异常堆栈信息泄漏到API之外，但是在Application层，异常机制仍然是信息量最大，代码结构最清晰的方法，避免了Result的一些常见且繁杂的Result.isSuccess判断。所以在Application层、Domain层，以及Infrastructure层，遇到错误直接抛异常是最合理的方法。 **应用服务总结** ApplicationService的代码通常有类似的结构：AppService通常不做任何决策（Precondition除外），仅仅是把所有决策交给DomainService或Entity，把跟外部交互的交给Infrastructure接口，如Repository或防腐层。 ApplicationService应该永远返回DTO而不是Entity * 构建领域边界：ApplicationService的入参是CQE对象，出参是DTO，这些基本上都属于简单的POJO，来确保Application层的内外互相不影响 * 降低规则依赖：Entity里面通常会包含业务规则，如果ApplicationService返回Entity，则会导致调用方直接依赖业务规则。如果内部规则变更可能直接影响到外部。 * 通过DTO组合降低成本：Entity是有限的，DTO可以是多个Entity、VO的自由组合，一次性封装成复杂DTO，或者有选择的抽取部分参数封装成DTO可以降低对外的成本。 #### domain层 [Section titled “domain层”](#domain层) 依赖反转原则（Dependency Inversion Principle）：依赖反转原则要求在代码中依赖抽象，而不是具体的实现。这个有一个架构,叫做六边形架构(或者端口和适配器架构)  > UI层、DB层、和各种中间件层实际上是没有本质上区别的，都只是数据的输入和输出，而不是在传统架构中的最上层和最下层。 #### infrastructure层 [Section titled “infrastructure层”](#infrastructure层) 基础设施层,负责抽象的具体实现 用ACL防腐层将外部依赖转化为内部代码，隔离外部的影响 #### types层 [Section titled “types层”](#types层) Types模块是保存可以对外暴露的Domain Primitives的地方。Domain Primitives因为是无状态的逻辑，可以对外暴露，所以经常被包含在对外的API接口中，需要单独成为模块。Types模块不依赖任何类库，纯 POJO 。 案例: 不使用DP对象: ```java public class User { // 定义user属性 Long userId; String name; String phone; String address; Long repId; } // 接口方法 User register(String name, String phone, String address) ``` 使用DP对象后: ```java public class User { // 使用DP UserId userId; Name name; PhoneNumber phone; Address address; RepId repId; } // 接口方法 User register( @NotNull Name name, @NotNull PhoneNumber phone, @NotNull Address address ) ``` DP是生成了一个 Type（数据类型）和一个 Class（类）（例如PhoneNumber）： * Type 指我们在今后的代码里可以通过 PhoneNumber 去显性的标识电话号这个概念 * Class 指我们可以把所有跟电话号相关的逻辑完整的收集到一个文件里 **DP的优点:** * 接口非常可读 * 校验逻辑内聚 * 不可变，线程安全 * 隐含概念显性化 参考: ## DDD应用架构有效的解决了传统架构中的问题 [Section titled “DDD应用架构有效的解决了传统架构中的问题”](#ddd应用架构有效的解决了传统架构中的问题) 1. 高可维护性：当外部依赖变更时，内部代码只用变更跟外部对接的模块，其他业务逻辑不变。 2. 高可扩展性：做新功能时，绝大部分的代码都能复用，仅需要增加核心业务逻辑即可。DDD有严格的分层及依赖关系,会写出SRP的类,扩展性会越来越好 3. 高可测试性：每个拆分出来的模块都符合单一性原则，绝大部分不依赖框架，可以快速的单元测试，做到100%覆盖。 1. order-types,order-domain模块都是属于无直接外部依赖的纯POJO，基本上都可以100%的被单元测试覆盖。 2. order-application模块的代码依赖的是外部抽象类，需要通过Mock掉所有的外部依赖，可以100%单元测试。 3. order-infrastructure模块的代码相对独立，接口数量比较少，相对比较容易写单测。但是由于依赖了外部I/O，速度上不可能很快，但好在模块的变动不会很频繁，属于一劳永逸。 4. order-interface模块的逻辑都后置到order-application中，Controller的逻辑变得极为简单，在测试时把Controller依赖的服务类都Mock掉,那么order-interface整体很容易100%覆盖。 5. Start模块：通常应用的集成测试写在start里。当其他模块的单元测试都能100%覆盖后，集成测试用来验证整体链路的真实性。 4. 代码结构清晰：通过POM module可以解决模块间的依赖关系， 所有外接模块都可以单独独立成Jar包被复用。形成规范后，可以快速的定位到相关代码。 ## DDD应用架构总结 [Section titled “DDD应用架构总结”](#ddd应用架构总结) 1. 独立于框架。不依赖某个外部的库或框架，不被框架的结构所束缚 2. 独立于UI。底层架构不会随着前台展示的变化而变化 3. 独立于底层数据源。不会因为不同的底层数据储存方式而产生巨大改变。因为核心领域在order-domain,且有基础设施层保证 4. 独立于外部依赖。无论外部依赖如何变更、升级，业务的核心逻辑不会有大幅变化 5. 可测试性。业务的逻辑应该都能够快速被验证正确性 基于DDD的思想,在承接业务时,我们可能会先写Domain层的业务逻辑，然后再写Application层的组件编排，最后才写每个外部依赖的具体实现。这种架构思路和代码组织结构就叫做**Domain-Driven** Design（**领域驱动**设计）,和之前我们MVC的编码思考方式不同 ## DDD中核心模块的代码的演进 [Section titled “DDD中核心模块的代码的演进”](#ddd中核心模块的代码的演进) * order-application层属于Use Case（业务用例）。业务用例一般都是描述比较大方向的需求，接口相对稳定，特别是对外的接口一般不会频繁变更。添加业务用例可以通过新增Application Service或者新增接口实现功能的扩展。 * order-domain层属于核心业务逻辑，属于经常被修改的地方。 * order-infrastructure层属于最低频变更的。一般这个层的模块只有在外部依赖变更了之后才会跟着升级，而外部依赖的变更频率一般远低于业务逻辑的变更频率。 # 使用DDD来重构现有系统 > 使用DDD来重构现有系统 #### 在使用DDD重构现有业务时,适合在在聚合根中调用Service方法来获取值吗? [Section titled “在使用DDD重构现有业务时,适合在在聚合根中调用Service方法来获取值吗?”](#在使用ddd重构现有业务时适合在在聚合根中调用service方法来获取值吗) 这是一个很好的问题。在使用领域驱动设计(DDD)重构现有业务时,是否应该在聚合根中调用Service方法来获取值,需要谨慎考虑。 一般来说,不推荐在聚合根中直接调用Service方法。原因如下: 1. 违反职责单一原则:聚合根应该专注于维护自身的一致性和不变性,而不是依赖外部服务。 2. 增加耦合:这样做会使聚合根与特定的服务实现耦合,降低了聚合根的独立性和可测试性。 3. 可能破坏领域模型的完整性:如果聚合根需要频繁调用外部服务获取数据,可能意味着当前的领域模型设计不够完善。 然而,在某些特殊情况下,可能确实需要在聚合根中获取外部数据。这时,可以考虑以下替代方案: 1. 依赖注入:通过构造函数将所需的服务注入聚合根,而不是直接在聚合根中调用服务方法。 2. 领域服务:如果某个操作涉及多个聚合,可以创建一个专门的领域服务来协调这些操作。 3. 事件驱动:使用领域事件来触发需要外部数据的操作,而不是在聚合根中直接获取。 4. 延迟加载:如果可能,考虑使用延迟加载策略,只在真正需要时才获取外部数据。 5. 重新审视边界:如果发现经常需要跨边界获取数据,可能需要重新考虑当前的领域边界划分是否合理。 总的来说,应该尽量保持聚合根的独立性和内聚性。如果确实需要在聚合根中获取外部数据,建议仔细评估替代方案,选择最适合你的特定场景的解决方法。 #### 基于DDD架构的项目提供查询接口时,返回参数适合使用DP对象吗? [Section titled “基于DDD架构的项目提供查询接口时,返回参数适合使用DP对象吗?”](#基于ddd架构的项目提供查询接口时返回参数适合使用dp对象吗) 不适合,如果DP对象中含有枚举,则在提供方新增枚举值且使用方未升级相关SDK时,则使用方会报错,解析异常。 特别是提供的SDK有多个使用方时,及时有的使用方不需要使用新的枚举,也要被迫升级。除非使用方自己解析,不依赖接口提供方的SDK 如果使用方要依赖提供方的SDK,建议SDK对象使用普通的POJO,更具通用性 #### 在构建聚合根的工厂类中,可以调用Repository方法吗? [Section titled “在构建聚合根的工厂类中,可以调用Repository方法吗?”](#在构建聚合根的工厂类中可以调用repository方法吗) 结论先说： > **不建议在 `AfterSaleAggregateFactory.create()` 内直接调用 `AfterSaleRepository` 或其他 Repository 去查数据库。** 如果确实需要外部数据来构建聚合根，**应该由 Application Service 查询好数据，组装必要的数据，再交给 Factory 构建聚合根**。 *** ##### 🧠 原因（DDD 原则） [Section titled “🧠 原因（DDD 原则）”](#-原因ddd-原则) | 原则 | 说明 | | -------------------------------- | --------------------------------------------------------------------------------- | | **领域层不依赖基础设施层** | Factory 在 domain 层，Repository 实现一般在 infrastructure，Factory 调 Repository 会导致依赖反转错误 | | **Factory 负责纯领域构建，不做外部 I/O** | 一旦 Factory 查 DB，它就变成应用/基础设施逻辑 | | **Application Service 是业务流程编排者** | 应用层负责查询外部信息、准备上下文数据 | *** ##### 🔧 正确做法：在 Application 层查数据，再交给 Factory [Section titled “🔧 正确做法：在 Application 层查数据，再交给 Factory”](#-正确做法在-application-层查数据再交给-factory) ###### Application 层 [Section titled “Application 层”](#application-层) ```java public void createAfterSale(AfterSaleCreateCommand command) { // 查询订单数据（或其它聚合） OrderAggregate order = orderRepository.findById(command.getOrderId()); // Application 层决定要哪些数据用于构建售后聚合 List items = order.getItems(); // 使用 Factory 构建聚合根，传递构建所需完整信息（不是只传 Command） AfterSaleAggregate aggregate = AfterSaleAggregateFactory.create(command, items); afterSaleRepository.save(aggregate); } ``` *** ###### Factory（纯构建） [Section titled “Factory（纯构建）”](#factory纯构建) ```java public class AfterSaleAggregateFactory { public static AfterSaleAggregate create( AfterSaleCreateCommand cmd, List orderItems ) { // 领域不变量校验 if (orderItems.isEmpty()) { throw new DomainException("订单明细不能为空"); } AfterSaleAggregate aggregate = new AfterSaleAggregate( cmd.getAfterSaleId(), cmd.getOrderId(), AfterSaleStatus.APPLIED ); // 根据订单明细构建聚合内部结构 for (OrderItem item : orderItems) { aggregate.addItem(item.getSkuId(), item.getQuantity()); } return aggregate; } } ``` *** ##### ❓ 为什么不能让 Factory 查数据库？ [Section titled “❓ 为什么不能让 Factory 查数据库？”](#-为什么不能让-factory-查数据库) ###### 如果 Factory 内部写： [Section titled “如果 Factory 内部写：”](#如果-factory-内部写) ```java orderRepository.findById(orderId) ``` 将造成： | 问题 | 结果 | | ------------------------------------ | ---------------- | | 违反 DDD 分层依赖（domain → infrastructure） | 项目结构混乱、无法测试、循环依赖 | | Factory 变成应用逻辑而不是领域逻辑 | 职责污染 | | 聚合根构造无法单元测试 | 构造会依赖数据库 | *** ##### 🧱 正确的 DDD 责任边界 [Section titled “🧱 正确的 DDD 责任边界”](#-正确的-ddd-责任边界) ```plaintext Controller -> Application Service (查数据 + 调用 Factory) -> Factory (构建聚合 root) -> Aggregate (执行业务) -> Repository.save() ``` *** ##### 📌 总结 [Section titled “📌 总结”](#-总结) | | | | ------------------------------ | -------------------------- | | 能不能在 Factory 调 Repository 查数据？ | ❌ 不可以 | | 应该在哪里查？ | ✔ Application Service | | Factory 接收哪些参数？ | ✔ 构建聚合所需完整信息，而不是只传 Command | *** ##### ⭐ 推荐扩展实践 [Section titled “⭐ 推荐扩展实践”](#-推荐扩展实践) 有时查询数据比较复杂，可以在 Application 层创建专用的： * **DomainPreparationService** * **DomainAssembler** 例如： ```java OrderContext context = orderContextService.loadOrderContext(command.getOrderId()); AfterSaleAggregate aggregate = AfterSaleAggregateFactory.create(command, context); ``` *** 如果你需要，我可以提供： * 带 `OrderContext` 的完整示例 * 支持领域事件的版本 * CQRS 场景下的构建方案 # 利用家里的电脑部署服务到公网 > 利用家里的电脑部署服务到公网 ### 目标 [Section titled “目标”](#目标) 在家里面的电脑运行一个服务,在其他地方可以访问 ### 整体架构 [Section titled “整体架构”](#整体架构)  ### 卸载CF Tunnel [Section titled “卸载CF Tunnel”](#卸载cf-tunnel) ```sh sudo cloudflared service uninstall ``` ### 进一步 [Section titled “进一步”](#进一步) 家用小型服务器,做7x24h无间断运行 已经开始建设了,详见: [HomeLab](/homelab/) # Docker > Docker [upupor](https://github.com/yangrunkang/upupor) 就是使用Docker部署的. 因为Docker属于运维范畴,我不能说对Dokcer有多熟悉,但是基本的使用还是OK,例如搭建开发环境,部署应用之类的。 ### 使用Docker可以带来哪些好处 [Section titled “使用Docker可以带来哪些好处”](#使用docker可以带来哪些好处) 1. 更高效的利用系统资源。由于容器不需要进行**硬件虚拟**以及运**行完整操作系统**等额外开销，Docker 对系统资源的利用率更高。无论是应用执行速度、内存损耗或者文件存储速度，都要比传统虚拟机技术更高效。因此，相比虚拟机技术，一个相同配置的主机，往往可以运行更多数量的应用。 2. 更快速的启动时间。传统的虚拟机技术启动应用服务往往需要数分钟，而 Docker 容器应用，由于**直接运行于宿主内核，无需启动完整的操作系统**，因此可以做到秒级、甚至毫秒级的启动时间。大大的节约了开发、测试、部署的时间。 3. 一致的运行环境。开发过程中一个常见的问题是环境一致性问题。由于开发环境、测试环境、生产环境不一致，导致有些 bug 并未在开发过程中被发现。而 Docker 的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性。 4. 持续交付和部署。使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。 5. 更轻松的迁移。由于 Docker 确保了执行环境的一致性，使得应用的迁移更加容易 6. 更轻松的维护和扩展。Docker 使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。 ### 基本概念 [Section titled “基本概念”](#基本概念) #### 镜像 [Section titled “镜像”](#镜像) Docker 镜像 是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像 不包含 任何动态数据，其内容在构建之后也不会被改变。 #### 容器 [Section titled “容器”](#容器) 镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。 容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的 命名空间。因此容器可以拥有自己的 root 文件系统、自己的网络配置、自己的进程空间，甚至自己的用户 ID 空间。容器内的进程是运行在一个隔离的环境里，使用起来，就好像是在一个独立于宿主的系统下操作一样。 #### 仓库 [Section titled “仓库”](#仓库) 镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务。 ### 使用 [Section titled “使用”](#使用) #### 获取镜像 [Section titled “获取镜像”](#获取镜像) ```sh docker pull [选项] [Docker Registry 地址[:端口号]/]仓库名[:标签] ``` #### 运行镜像 [Section titled “运行镜像”](#运行镜像) ```sh docker run -it --rm 镜像名 bash ``` * -it：这是两个参数，一个是 -i：交互式操作，一个是 -t 终端。我们这里打算进入 bash 执行一些命令并查看返回结果，因此我们需要交互式终端。 * —rm：这个参数是说容器退出后随之将其删除。默认情况下，为了排障需求，退出的容器并不会立即删除，除非手动 docker rm。我们这里只是随便执行个命令，看看结果，不需要排障和保留结果，因此使用 —rm 可以避免浪费空间。 * 镜像名：这是指用指定的镜像为基础来启动容器。 * bash：放在镜像名后的是 命令，这里我们希望有个交互式 Shell，因此用的是 bash。 #### 常用命令 [Section titled “常用命令”](#常用命令) * docker image ls 列出镜像 * docker system df 查看镜像、容器、数据卷所占用的空间 * docker image rm \[选项] <镜像1> \[<镜像2> …] 删除镜像 * docker ps 查看docker中有哪些服务在运行 * docker logs -f `qa_order-service_1` 实时查看容器日志 * docker exec -it `840ec90eade2` /bin/sh 进入容器 * docker cp `qa_order-service_1:/app/order-web-1.0-SNAPSHOT.jar` \~ 将docker中的文件拷贝出来 * docker update -m 1000M —memory-swap 1000M CONTAINER\_ID 更新docker应用镜像占用内存 * docker stats 查看状态 ### Compose [Section titled “Compose”](#compose) Compose 项目是 Docker 官方的开源项目，负责实现对 Docker 容器集群的快速编排。 Compose 恰好满足了这样的需求。它允许用户通过一个单独的 docker-compose.yml 模板文件（YAML 格式）来定义一组相关联的应用容器为一个项目（project）。 Compose 的默认管理对象是项目，通过子命令对项目中的一组容器进行便捷地生命周期管理。 # 使用Docker搭建开发环境 > 使用Docker搭建开发环境 ### PostgreSQL [Section titled “PostgreSQL”](#postgresql) ```sh docker pull postgres docker run --name mypostgres -d -p 5432:5432 -e POSTGRES_PASSWORD=123456 postgres ``` ### MySQL 5.7 [Section titled “MySQL 5.7”](#mysql-57) ```sh docker pull mysql:5.7 docker run --name mysql5.7 -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7 ``` 持久化数据 ```sh docker run --name mysql -v /home/moatkonbase/data/mysql/data:/var/lib/mysql -v /home/moatkonbase/data/mysql/conf:/etc/mysql/conf.d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=mysqlrootpwd -d mysql:lts ``` ### Redis [Section titled “Redis”](#redis) ```sh docker pull redis:latest docker run --name redis -p 6379:6379 -d redis:latest redis-server --appendonly yes --requirepass 'sDF234sdf#@@$@$fdd' ``` > 注意: 启动redis时,windows上 —requirepass 的密码可以使用""包起来,mac上要使用”包起来 ### Kafka [Section titled “Kafka”](#kafka) [Kafka安装及使用 ](/software-engineer/mq/kafka/use) ### RocketMQ [Section titled “RocketMQ”](#rocketmq) [RocketMQ安装及使用 ](/software-engineer/mq/rocketmq/use) ### ES安装 [Section titled “ES安装”](#es安装) ```sh docker pull elasticsearch:7.14.0 docker run --name es7.14 -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -d elasticsearch:7.14.0 ``` ### docker设置代理 [Section titled “docker设置代理”](#docker设置代理) ```plaintext # 编辑文件,没有则新增 vim /etc/systemd/system/docker.service.d/http-proxy.conf # 填写内容 [Service] Environment="HTTP_PROXY=http://10.4.1.182:7890" Environment="HTTPS_PROXY=http://10.4.1.182:7890" # 按需 Environment="NO_PROXY=localhost,127.0.0.1" # 重启 sudo systemctl daemon-reload sudo systemctl restart docker ``` ### 将用户添加到 docker 组 [Section titled “将用户添加到 docker 组”](#将用户添加到-docker-组) ```sh # 将当前用户添加到 docker 组 sudo usermod -aG docker $USER # 刷新组权限（或者重新登录/重启） newgrp docker # 验证是否生效 docker ps ``` 注意：添加到 docker 组后需要重新登录才能完全生效，或者使用 newgrp docker 临时刷新。 # K8s > K8s K8s我理解的就是基于Docker做的一整套服务。在Java开发的角度,类似于Spring Cloud之于Spring的区别. 虽然 Docker 已经很强大了，但是在实际使用上还是有诸多不便，比如集群管理、资源调度、文件管理等等。 kubernetes 已经成为容器编排领域的王者，它是基于容器的集群编排引擎，具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力 ### Kubernetes 解决的核心问题 [Section titled “Kubernetes 解决的核心问题”](#kubernetes-解决的核心问题) #### 服务发现和负载均衡 [Section titled “服务发现和负载均衡”](#服务发现和负载均衡) Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定 #### 自动部署和回滚 [Section titled “自动部署和回滚”](#自动部署和回滚) 您可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器 #### 自动二进制打包 [Section titled “自动二进制打包”](#自动二进制打包) Kubernetes 允许您指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源 #### 自我修复 [Section titled “自我修复”](#自我修复) Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端 #### 密钥与配置管理 [Section titled “密钥与配置管理”](#密钥与配置管理) Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥 # Base理论 > Base理论 * BA(Basically Available)：基本可用 * S(Soft State)：软状态 * E(Eventually Consistent)：最终一致性  Base 理论的核心思想是**最终一致性**，即使无法做到强一致性(Strong Consistency)，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual Consistency)。 接下来我们着重对 Base 理论中的三要素进行讲解。 ### 软状态 [Section titled “软状态”](#软状态) 软状态可以对应 ACID 事务中的原子性，在 ACID 的事务中，实现的是强制一致性，要么全做要么不做，所有用户看到的数据一致。其中的原子性(Atomicity)要求多个节点的数据副本都是一致的，强调数据的一致性。 原子性可以理解为一种“硬状态”，软状态则是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。 ### 最终一致性 [Section titled “最终一致性”](#最终一致性) 数据不可能一直是软状态，必须在一个时间期限之后达到各个节点的一致性，在期限过后，应当保证所有副本保持数据一致性，也就是达到数据的最终一致性。 在系统设计中，最终一致性实现的时间取决于网络延时、系统负载、不同的存储选型、不同数据复制方案设计等因素。 ### CAP及Base的关系 [Section titled “CAP及Base的关系”](#cap及base的关系) Base理论是在CAP上发展的，CAP理论描述了分布式系统中数据一致性、可用性、分区容错性之间的制约关系，当你选择了其中的两个时，就不得不对剩下的一个做一定程度的牺牲。 Base理论则是对 CAP 理论的实际应用，也就是在分区和副本存在的前提下，通过一定的系统设计方案，放弃强一致性，实现基本可用，这是大部分分布式系统的选择，比如 NoSQL 系统、微服务架构。 在这个前提下，如何把基本可用做到最好，就是分布式工程师们追求的, 这也是我一直追求的 ACID? ACID 是一种强一致性模型，强调原子性、一致性、隔离性和持久性，主要用于在数据库实现中。Base 理论面向的是高可用、可扩展的分布式系统，ACID 适合传统金融等业务，在实际场景中，不同业务对数据的一致性要求不一样，ACID 和 Base 理论往往会结合使用。 # CAP理论 > CAP理论 > 在一次面试经历中,被问到了Base理论和CAP理论,我没有想到会问的这么深,不仅仅是要把Base理论和CAP理论是什么讲出来,还要讲出来自己对这2个理论的理解及应用 ### CAP是什么? [Section titled “CAP是什么?”](#cap是什么)  * C(Consistency)：一致性。服务A、B、C三个节点都存储了用户数据，三个节点的数据都需要保持同一时刻数据一致性。(一致性被称为原子对象，任何的读写都应该看起来是“原子”的，或串行的，写后面的读一定能读到前面写的内容，所有的读写请求都好像被全局排序) * A(Availability)：可用性。服务A、B、C三个节点，其中一个节点如果宕机了，不能影响整个集群对外提供服务。云服务的SLA协议,即服务水平协议,99.9%类似的 * P(Partition Tolerance)：分区容忍性。指“当部分节点出现消息丢失或者分区故障的时候，分布式系统仍然能够继续运行”，即系统容忍网络出现分区，并且在遇到某节点或网络分区之间网络不可达的情况下，仍然能够对外提供满足一致性和可用性的服务。 Note 证明了 CAP 理论的 Lynch 教授此时给当时的 IT 界来了一记惊雷： Lynch 教授通过不可辩驳的证明告诉业界的工程师们，如果在一个不稳定(消息要么乱序要么丢了)的网络环境里(分布式异步模型)，想始终保持数据一致是不可能的。 这是个什么概念呢？就是她打破了那些既想提供超高质量服务，又想提供超高性能服务的技术人员的幻想。 CAP理论的本质是在告诉大家，在分布式系统里，需要妥协。 ### CAP理论的应用 [Section titled “CAP理论的应用”](#cap理论的应用) 以电商系统举例 * 对于商品价格要强一致性 * 对于用户对商品的评价,可以不追求强一致 #### CP架构: 放弃可用性，追求一致性和分区容错性。 [Section titled “CP架构: 放弃可用性，追求一致性和分区容错性。”](#cp架构-放弃可用性追求一致性和分区容错性) * ZooKeeper，就是采用了 CP 一致性，ZooKeeper 是一个分布式的服务框架，主要用来解决分布式集群中应用系统的协调和一致性问题。其核心算法是 Zab，所有设计都是为了一致性。在 CAP 模型中，ZooKeeper 是 CP，这意味着面对网络分区时，为了保持一致性，它是不可用的。 #### AP架构: 对于AP来说，放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的Base也是根据AP来扩展的 [Section titled “AP架构: 对于AP来说，放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的Base也是根据AP来扩展的”](#ap架构-对于ap来说放弃强一致性追求分区容错性和可用性这是很多分布式系统设计时的选择后面的base也是根据ap来扩展的) 和 ZooKeeper 相对的是 Eureka，Eureka 是 Spring Cloud 微服务技术栈中的服务发现组件，Eureka 的各个节点都是平等的，几个节点挂掉不影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，只要有一台 Eureka 还在，就能保证注册服务可用，只不过查到的信息可能不是最新的版本，不保证一致性。 [点击前往Base理论](/software-engineer/distributed/base) ### 架构设计思考路径图 [Section titled “架构设计思考路径图”](#架构设计思考路径图) ``` flowchart TD A[明确业务需求] --> B{是否需要强一致性?} B -->|是| C[选择CP模型] B -->|否| D{是否需要高可用性?} D -->|是| E[选择AP模型] D -->|否| F[其他设计] C --> G[实现方案, 如分布式锁] E --> H[实现方案, 如缓存、消息队列] ``` # 分布式锁 > 分布式锁 分布式场景下解决并发问题，需要应用分布式锁技术。分布式锁的目的是保证在分布式部署的应用集群中，多个服务在请求同一个资源时，只能被一台机器上的一个线程操作，避免出现并发问题。 ### 分布式锁的常用实现 [Section titled “分布式锁的常用实现”](#分布式锁的常用实现) 实现分布式锁目前有三种流行方案，即基于数据库、Redis和ZooKeeper #### 1. 基于数据库 [Section titled “1. 基于数据库”](#1-基于数据库) 基于关系型数据库实现分布式锁，是依赖数据库的唯一性来实现资源锁定，比如主键和唯一索引等。 **具体实现:** 创建一个独立的锁表,将锁表中的一个字段设置成唯一,然后多个请求尝试插入数据,如果插入成功则表明获取到锁。其他请求自然会因为唯一性而插入失败,即获取锁失败。 获取到锁的线程执行完之后,删除刚刚插入的记录,即释放锁。 ##### 1.1 基于数据库实现分布式锁的缺陷 [Section titled “1.1 基于数据库实现分布式锁的缺陷”](#11-基于数据库实现分布式锁的缺陷) ###### 存在单点故障风险 [Section titled “存在单点故障风险”](#存在单点故障风险) 数据库实现方式强依赖数据库的可用性，一旦数据库挂掉，则会导致业务系统不可用，为了解决这个问题，需要配置数据库主从机器，防止单点故障。 ###### 超时无法失效 [Section titled “超时无法失效”](#超时无法失效) 如果一旦解锁操作失败，则会导致锁记录一直在数据库中，其他线程无法再获得锁，解决这个问题，可以添加独立的定时任务，通过时间戳对比等方式，删除超时数据。 ###### 不可重入 [Section titled “不可重入”](#不可重入) 可重入性是锁的一个重要特性，以 Java 语言为例，常见的 Synchronize、Lock 等都支持可重入。在数据库实现方式中，同一个线程在没有释放锁之前无法再次获得该锁，因为数据已经存在，再次插入会失败。实现可重入，需要改造加锁方法，额外存储和判断线程信息，不阻塞获得锁的线程再次请求加锁。 ###### 无法实现阻塞 [Section titled “无法实现阻塞”](#无法实现阻塞) 其他线程在请求对应方法时，插入数据失败会直接返回，不会阻塞线程，如果需要阻塞其他线程，需要不断的重试 insert 操作，直到数据插入成功，这个操作是服务器和数据库资源的极大浪费。 #### 2. 基于 ZooKeeper 实现 [Section titled “2. 基于 ZooKeeper 实现”](#2-基于-zookeeper-实现) ZooKeeper有四种节点类型，包括持久节点、持久顺序节点、临时节点和临时顺序节点。 **临时:** 会自动失效,可以避免某些情况下锁无法删除而产生死锁的问题 主要是使用节点唯一性来实现(实际业务上如果创建失败，就丢到队列中去排队) 释放锁就是删除节点，删除后然后通知其他人过来创建节点,即加锁 > **如果机器宕机了,没有删除掉,资源就会一直被占着,怎么处理呢?** > > 创建临时节点就好,客户端断开，节点就自动删除了 > 在实际开发中，可以应用 Apache Curator 来快速实现分布式锁，Curator 是 Netflix 公司开源的一个 ZooKeeper 客户端，对 ZooKeeper 原生 API 做了抽象和封装 ###### 使用zk可能会造成的问题 [Section titled “使用zk可能会造成的问题”](#使用zk可能会造成的问题) 羊群效应,导致占用服务器资源 > 监听，是所有服务都去监听一个节点的，节点的释放也会通知所有的服务器，如果是900个服务器呢？ 这对服务器是很大的一个挑战，一个释放的消息，就好像一个牧羊犬进入了羊群，大家都四散而开，随时可能干掉机器，会占用服务资源，网络带宽等等。 这就是羊群效应。 **羊群效应处理方法**:\ 临时顺序节点,只监听前一个节点，以此类推，只关注自己前后，就不会出现羊群效应 ###### 使用zk实现分布式锁的缺点 [Section titled “使用zk实现分布式锁的缺点”](#使用zk实现分布式锁的缺点) * 性能没有缓存服务高。因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同步到所有的Follower机器上。 * 可能带来并发问题。由于网络抖动，客户端ZK集群的session连接断了，那么zk以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了。就可能产生并发问题了。 #### 3. 基于Redis(重点) [Section titled “3. 基于Redis(重点)”](#3-基于redis重点) 相比基于数据库实现分布式锁，缓存的性能更好，并且各种缓存组件也提供了多种集群方案，可以解决单点问题。 具体实现: 添加了 SETEX 命令，SETEX 支持 setnx 和 expire 指令组合的原子操作。 以上只是简单的实现,实际实现需要考虑更多的点,下面的板块就详细的介绍下 ### 分布式锁的常用实现之Redis [Section titled “分布式锁的常用实现之Redis”](#分布式锁的常用实现之redis) #### 1. 一个完备的分布式锁，需要支持以下特性 [Section titled “1. 一个完备的分布式锁，需要支持以下特性”](#1-一个完备的分布式锁需要支持以下特性)  > 该图片来自互联网 * 互斥性，互斥是锁的基本特征，同一时刻只能有一个线程持有锁，执行临界操作； * 超时释放，超时释放是锁的另一个必备特性，可以对比 MySQL InnoDB 引擎中的 innodb\_lock\_wait\_timeout 配置，通过超时释放，防止不必要的线程等待和资源浪费； * 可重入性，在分布式环境下，同一个节点上的同一个线程如果获取了锁之后，再次请求还是可以成功； * 高性能和高可用，加锁和解锁的开销要尽可能的小，同时也需要保证高可用，防止分布式锁失效； * 支持阻塞和非阻塞性，对比 Java 语言中的 wait() 和 notify() 等操作，这个一般是在业务代码中实现，比如在获取锁时通过 while(true) 或者轮询来实现阻塞操作。 实现一个相对完备的分布式锁，并不是锁住资源就可以了，还需要满足一些额外的特性，否则会在业务开发中出现各种各样的问题。 #### 2. 实现 [Section titled “2. 实现”](#2-实现) 1. 使用 setnx 实现分布式锁 ——— 不支持超时释放 2. 使用 setnx 和 expire 实现分布式锁 ——— setnx 和 expire 这两条命令不具备原子性。如果一个线程在执行完 setnx 之后突然崩溃，导致锁没有设置过期时间，那么这个锁就会一直存在，无法被其他线程获取。 3. 使用 setex 实现分布式锁。`SET key value expireTime nx` 同时解决了原子性和超时的问题 ——— 但在实际业务中，如果对超时时间设置不合理，存在这样一种可能：在加锁和释放锁之间的业务逻辑执行的太长，以至于超出了锁的超时限制，缓存将对应 key 删除，其他线程可以获取锁，出现对加锁资源的并发操作。 对于第三种实现方案中的问题如何解决呢? 可以使用Redisson中的Watch Dog,给锁续期。Redisson提供的分布式锁是支持锁自动续期的，也就是说，如果线程仍旧没有执行完，那么redisson会自动给redis中的目标key延长超时时间，这在Redisson中称之为 Watch Dog 机制。 ```java Config config = new Config(); config.useClusterServers() .addNodeAddress("redis://xx.xx.xx.xx:xxxx1") .addNodeAddress("redis://xx.xx.xx.xx:xxxx2") // 等等 ; RedissonClient redisson = Redisson.create(config); RLock lock = redisson.getLock("anyLock"); lock.lock(); lock.unlock(); ``` 只需要通过它的 API 中的 Lock 和 Unlock 即可完成分布式锁，可以看到非常简单，而且考虑了很多细节： * **Redisson 所有指令都通过 Lua 脚本执行，Redis 支持 Lua 脚本原子性执行。** * Redisson 设置一个 Key 的默认过期时间为 30s，但是如果获取锁之后，会有一个WatchDog每隔10s将key的超时时间设置为30s。 # 分布式事务 > 分布式事务 ### 一、什么是分布式事务 [Section titled “一、什么是分布式事务”](#一什么是分布式事务) 分布式事务关注的是分布式场景下如何处理事务，是指事务的参与者、支持事务操作的服务器、存储等资源分别位于分布式系统的不同节点之上。 简单来说，分布式事务就是一个业务操作，是由多个细分操作完成的，而这些细分操作又分布在不同的服务器上；事务，就是这些操作要么全部成功执行，要么全部不执行。 ### 二、什么时候会出现分布式事务 [Section titled “二、什么时候会出现分布式事务”](#二什么时候会出现分布式事务) 分布式事务是伴随着系统拆分出现的 * 存储层的拆分,例如订单库,商品库,用户库等等 * 服务层的拆分,例如订单服务,商品服务,营销服务,支付服务等等 ### 三、分布式事务的普遍缺点 [Section titled “三、分布式事务的普遍缺点”](#三分布式事务的普遍缺点) 1. 长时间锁定数据库资源，导致系统的响应不快，并发上不去。 2. 网络抖动出现脑裂情况，导致事物参与者，不能很好地执行协调者的指令，导致数据不一致 3. 单点故障：例如事物协调者，在某一时刻宕机，虽然可以通过选举机制产生新的Leader，但是这过程中，必然出现问题，而TCC，只有强悍的技术团队，才能支持开发，成本太高。 ### 四、分布式事务的解决方法 [Section titled “四、分布式事务的解决方法”](#四分布式事务的解决方法) **核心**: 需要统一的一个协调者来作统一的管理。\ **角色**: 协调者(Coordinator)、参与者(Participants) #### 1.两阶段提交(2PC) [Section titled “1.两阶段提交(2PC)”](#1两阶段提交2pc) Two-Phase Commit，2PC Note 二阶段提交算法的成立是基于以下假设的: 1. 在该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Participants)，且节点之间可以进行网络通信； 2. 所有节点都采用预写式日志，日志被写入后被保存在可靠的存储设备上，即使节点损坏也不会导致日志数据的丢失； 3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复。  > 该图片来自互联网 ###### 提交请求阶段(Commit-request) [Section titled “提交请求阶段(Commit-request)”](#提交请求阶段commit-request) 在提交请求阶段，协调者将通知事务参与者准备提交事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意(事务参与者本地事务执行成功)或取消(本地事务执行故障)，在第一阶段，参与节点并没有进行Commit操作。 > 参与者成功的话,其对应的资源就在占用着 ###### 提交阶段(Commit) [Section titled “提交阶段(Commit)”](#提交阶段commit) 在提交阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消这个事务。这个结果的处理和前面基于半数以上投票的一致性算法不同，必须当且仅当所有的参与者同意提交，协调者才会通知各个参与者提交事务，否则协调者将通知各个参与者取消事务。 参与者在接收到协调者发来的消息后将执行对应的操作，也就是本地 Commit 或者 Rollback。 提示 两阶段提交(2PC，Two-phase Commit Protocol)是非常经典的强一致性、中心化的原子提交协议，在各种事务和一致性的解决方案中，都能看到两阶段提交的应用。 ##### 2PC缺点 [Section titled “2PC缺点”](#2pc缺点)  > 该图片来自互联网 * 资源被同步阻塞: 在执行过程中，所有参与节点都是事务独占状态，当参与者占有公共资源时，那么第三方节点访问公共资源会被阻塞。 * 协调者可能出现单点故障: 一旦协调者发生故障，参与者会一直阻塞下去。 * 在 Commit 阶段出现数据不一致: 在第二阶段中，假设协调者发出了事务 Commit 的通知，但是由于网络问题该通知仅被一部分参与者所收到并执行 Commit，其余的参与者没有收到通知，一直处于阻塞状态，那么，这段时间就产生了数据的不一致性。 > 因此在某些高度可用性和性能要求较高的分布式系统中可能不是最佳选择。 #### 2.三阶段提交(3PC) [Section titled “2.三阶段提交(3PC)”](#2三阶段提交3pc) Three-Phase Commit，3PC 为了解决二阶段协议中的同步阻塞等问题，三阶段提交协议在协调者和参与者中都引入了超时机制，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。 三阶段中的 Three Phase 分别为 CanCommit、PreCommit、DoCommit 阶段。  > 该图片来自互联网 ###### CanCommit阶段 [Section titled “CanCommit阶段”](#cancommit阶段) 3PC 的 CanCommit 阶段其实和 2PC 的准备阶段很像。协调者向参与者发送 Can-Commit 请求，参与者如果可以提交就返回 Yes 响应，否则返回 No 响应。 ###### PreCommit阶段 [Section titled “PreCommit阶段”](#precommit阶段) 协调者根据参与者的反应情况来决定是否可以继续事务的 PreCommit 操作。根据响应情况，有以下两种可能。 A. 假如协调者从所有的参与者获得的反馈都是 Yes 响应，那么就会进行事务的预执行： * 发送预提交请求，协调者向参与者发送 PreCommit 请求，并进入 Prepared 阶段； * 事务预提交，参与者接收到 PreCommit 请求后，会执行事务操作； * 响应反馈，如果参与者成功执行了事务操作，则返回 ACK 响应，同时开始等待最终指令。 B. 假如有任何一个参与者向协调者发送了 No 响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就中断事务： * 发送中断请求，协调者向所有参与者发送 abort 请求； * 中断事务，参与者收到来自协调者的 abort 请求之后，执行事务的中断。 ###### DoCommit阶段 [Section titled “DoCommit阶段”](#docommit阶段) 该阶段进行真正的事务提交，也可以分为以下两种情况。 A. 执行提交 * 发送提交请求。协调者接收到参与者发送的 ACK 响应后，那么它将从预提交状态进入到提交状态，并向所有参与者发送 doCommit 请求。 * 事务提交。参与者接收到 doCommit 请求之后，执行正式的事务提交，并在完成事务提交之后释放所有事务资源。 * 响应反馈。事务提交完之后，向协调者发送 ACK 响应。 * 完成事务。协调者接收到所有参与者的 ACK 响应之后，完成事务。 B. 中断事务: 协调者没有接收到参与者发送的 ACK 响应，可能是因为接受者发送的不是 ACK 响应，也有可能响应超时了，那么就会执行中断事务。 C.超时提交: 参与者如果没有收到协调者的通知，超时之后会执行 Commit 操作。 ##### 三阶段提交做了哪些改进 [Section titled “三阶段提交做了哪些改进”](#三阶段提交做了哪些改进) 1. 引入超时机制\ 在 2PC 中，**只有协调者拥有超时机制**，如果在一定时间内没有收到参与者的消息则默认失败，3PC 同时在协调者和参与者中都引入超时机制。 2. 添加预提交阶段\ 在 2PC 的准备阶段和提交阶段之间，插入一个准备阶段，使 3PC 拥有 CanCommit、PreCommit、DoCommit 三个阶段，PreCommit 是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。 3. 三阶段提交协议存在的问题\ 三阶段提交协议同样存在问题，具体表现为，在阶段三中，如果参与者接收到了 PreCommit 消息后，出现了不能与协调者正常通信的问题，在这种情况下，参与者依然会进行事务的提交，在这段时间内就出现了数据的不一致性。 两阶段和三阶段提交的实际应用 两阶段提交是一种比较精简的一致性算法/协议，很多关系型数据库都是采用两阶段提交协议来完成分布式事务处理的，典型的比如 MySQL 的 XA 规范。 在事务处理、数据库和计算机网络中，两阶段提交协议提供了分布式设计中的数据一致性的保障，整个事务的参与者要么一致性全部提交成功，要么全部回滚。MySQL Cluster 内部数据的同步就是用的 2PC 协议。 MySQL 的主从复制 在 MySQL 中，二进制日志是 server 层，主要用来做主从复制和即时点恢复时使用的；而事务日志(Redo Log)是 InnoDB 存储引擎层，用来保证事务安全的。 在数据库运行中，需要保证 Binlog 和 Redo Log 的一致性，如果顺序不一致， 则意味着 Master-Slave 可能不一致。 在开启 Binlog 后，如何保证 Binlog 和 InnoDB redo 日志的一致性呢？MySQL 使用的就是二阶段提交，内部会自动将普通事务当做一个 XA 事务(内部分布式事务)来处理： Commit 会被自动的分成 Prepare 和 Commit 两个阶段； Binlog 会被当做事务协调者(Transaction Coordinator)，Binlog Event 会被当做协调者日志。 #### 3. 基于消息补偿的最终一致性 [Section titled “3. 基于消息补偿的最终一致性”](#3-基于消息补偿的最终一致性) 异步化在分布式系统设计中随处可见，基于消息队列的最终一致性就是一种异步事务机制，在业务中广泛应用。 **核心实现逻辑:** 基于第三方可靠的消息队列 + 本地消息表 + 补偿机制(例如定时扫表) > 这种一致性方案,自己在多家公司中实践 #### 4. 最大努力通知 [Section titled “4. 最大努力通知”](#4-最大努力通知) 不保证最终一致性的柔性事务,这种方式适合可以接受部分不一致的业务场景。 最大努力通知也称为定期校对，是对可靠消息服务的进一步优化。它引入了本地消息表来记录错误消息，然后加入失败消息的定期校对功能，来进一步保证消息会被下游服务消费。 本地消息表的方案最初是由 ebay 的工程师提出，核心思想是将分布式事务拆分成本地事务进行处理，通过消息日志的方式来异步执行。 本地消息表是一种业务耦合的设计，消息生产方需要额外建一个事务消息表，并记录消息发送状态，消息消费方需要处理这个消息，并完成自己的业务逻辑，另外会有一个异步机制来定期扫描未完成的消息，确保最终一致性。 #### 5.TCC(Try Confirm Cancel) [Section titled “5.TCC(Try Confirm Cancel)”](#5tcctry-confirm-cancel) **TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。**\ 即: TCC的特别之处在于它不依赖资源管理器(RM)对XA的支持，而是通过对业务逻辑(由业务系统提供的)的调度来实现分布式事务 它是属于**补偿型分布式事务**。它的核心思想是针对每个操作，都要注册一个与其对应的确认和补偿(撤销)操作 TCC在保证强一致性的同时，最大限度提高系统的可伸缩性与可用性。 ###### TCC(Try Confirm Cancel): [Section titled “TCC(Try Confirm Cancel):”](#tcctry-confirm-cancel) * Try：尝试待执行的业务。 这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的所有资源 * Confirm：确认执行业务。 确认执行业务的操作，不做任何业务检查，只使用Try阶段预留的业务资源。通常情况下，采用TCC则会认为 Confirm 阶段是不会出错的。只要 Try 成功，则 Confirm 一定成功。如果 Confirm 出错了，则需要引入重试机制或人工处理 * Cancel：取消待执行的业务。 取消 Try 阶段预留的业务资源。通常情况下，采用 TCC 则认为 Cancel 阶段也是一定能成功的，若 Cancel 阶段真的出错了，也要引入重试机制或人工处理 TCC 是**业务层面**的分布式事务，最终一致性，不会一直持有资源的锁。 * 优点: 把数据库层的二阶段提交上提到了**应用层**来实现，规避了数据库的2PC性能低下问题,TCC会根据具体业务来实现控制资源锁的粒度变小，不会锁定整个资源 * 缺点: TCC 的 Try、Confirm 和 Cancel 操作功能需业务提供，开发成本高。TCC 对业务的侵入较大和业务紧耦合，需要根据特定的场景和业务逻辑来设计相应的操作 ###### TCC在实现时需要考虑到以下几个设计要点: [Section titled “TCC在实现时需要考虑到以下几个设计要点:”](#tcc在实现时需要考虑到以下几个设计要点) 1. 空回滚 如果协调者的Try()请求因为网络超时失败，那么协调者在阶段二时会发送Cancel()请求，而这时这个事务参与者实际上之前并没有执行Try()操作而直接收到了Cancel()请求。 针对这个问题，TCC模式要求在这种情况下Cancel()能直接返回成功，也就是要允许「空回滚」 2. 防悬挂 接着上面的问题1，Try()请求超时，事务参与者收到Cancel()请求而执行了空回滚，但就在这之后网络恢复正常，事务参与者又收到了这个Try()请求，所以Try()和Cancel()发生了悬挂，也就是先执行了Cancel()后又执行了Try() 针对这个问题，TCC模式要求在这种情况下，事务参与者要记录下Cancel()的事务ID，当发现Try()的事务ID已经被回滚，则直接忽略掉该请求。 3. 幂等性 Confirm()和Cancel()的实现必须是幂等的。当这两个操作执行失败时协调者都会发起重试。 # 分布式事务之Seata > 分布式事务之Seata 它把一个分布式事务理解成一个包含了若干**分支事务**的全局事务。 而全局事务的职责是协调它管理的分支事务达成一致性，要么一起成功提交，要么一起失败回滚。  > 该图片来自互联网 ### Seata 中存在几种重要角色 [Section titled “Seata 中存在几种重要角色”](#seata-中存在几种重要角色) #### TC(Transaction Coordinator) [Section titled “TC(Transaction Coordinator)”](#tctransaction-coordinator) 事务协调者。管理全局的分支事务的状态，用于全局性事务的提交和回滚。 #### TM(Transaction Manager) [Section titled “TM(Transaction Manager)”](#tmtransaction-manager) 事务管理者。用于开启、提交或回滚事务。 #### RM(Resource Manager) [Section titled “RM(Resource Manager)”](#rmresource-manager) 资源管理器。用于分支事务上的资源管理，向 TC 注册分支事务，上报分支事务的状态，接收 TC 的命令来提交或者回滚分支事务。 > 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。 ### Seata工作流程 [Section titled “Seata工作流程”](#seata工作流程) 在 Seata 中，分布式事务的执行流程： 1. TM 开启分布式事务(TM 向 TC 注册全局事务记录)； 2. 按业务场景，编排数据库、服务等事务内资源(RM 向 TC 汇报资源准备状态 )； 3. TM 结束分布式事务，事务一阶段结束(TM 通知 TC 提交/回滚分布式事务)； 4. TC 汇总事务信息，决定分布式事务是提交还是回滚； 5. TC 通知所有 RM 提交/回滚 资源，事务二阶段结束； ### Seata事务模式 [Section titled “Seata事务模式”](#seata事务模式) #### Seata AT模式 [Section titled “Seata AT模式”](#seata-at模式) > 在生产环境上,我实际使用过的模式  > 该图片来自互联网 在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。 **Seata AT模式是如何做到对业务无侵入的?**\  > 该图片来自互联网 在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性 二阶段提交或回滚 * 二阶段提交：二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。 >  该图片来自互联网 * 二阶段回滚：二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。 >  该图片来自互联网 #### Seata TCC模式 [Section titled “Seata TCC模式”](#seata-tcc模式)  > 该图片来自互联网 TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法 * Try：资源的检测和预留； * Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功； * Cancel：预留资源释放； **TCC 设计** * TCC 设计 - 允许空回滚。Cancel 接口设计时需要允许空回滚。在 Try 接口因为丢包时没有收到，事务管理器会触发回滚，这时会触发 Cancel 接口，这时 Cancel 执行时发现没有对应的事务 xid 或主键时，需要返回回滚成功。让事务服务管理器认为已回滚，否则会不断重试，而 Cancel 又没有对应的业务数据可以进行回滚。 * TCC 设计 - 防悬挂控制。悬挂的意思是：Cancel 比 Try 接口先执行，出现的原因是 Try 由于网络拥堵而超时，事务管理器生成回滚，触发 Cancel 接口，而最终又收到了 Try 接口调用，但是 Cancel 比 Try 先到。按照前面允许空回滚的逻辑，回滚会返回成功，事务管理器认为事务已回滚成功，则此时的 Try 接口不应该执行，否则会产生数据不一致，所以我们在 Cancel 空回滚返回成功之前先记录该条事务 xid 或业务主键，标识这条记录已经回滚过，Try 接口先检查这条事务xid或业务主键如果已经标记为回滚成功过，则不执行 Try 的业务操作。(其实就是幂等) * TCC 设计 - 幂等控制。幂等性的意思是：对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。因为网络抖动或拥堵可能会超时，事务管理器会对资源进行重试操作，所以很可能一个业务操作会被重复调用，为了不因为重复调用而多次占用资源，需要对服务设计时进行幂等控制，通常我们可以用事务 xid 或业务主键判重来控制。**在写代码时,TCC三个方法均需保证幂等性** **与Seata AT模式比较**\ 相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。但就是需要业务端写很多代码，这个是缺点，强侵入性 #### Seata Saga模式 [Section titled “Seata Saga模式”](#seata-saga模式) 长事务解决方案。在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。 1. Saga模式适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。 2. 不能保证隔离。原因: Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性 > Saga 模式不保证事务的隔离性，在极端情况下可能出现脏写。比如在分布式事务未提交的情况下，前一个服务的数据被修改了，而后面的服务发生了异常需要进行回滚，可能由于前面服务的数据被修改后无法进行补偿操作。这时的一种处理办法可以是“重试”继续往前完成这个分布式事务。由于整个业务流程是由状态机编排的，即使是事后恢复也可以继续往前重试。所以用户可以根据业务特点配置该流程的事务处理策略是优先“回滚”还是“重试”，当事务超时的时候，Server 端会根据这个策略不断进行重试。 > > 由于 Saga 不保证隔离性，所以我们在业务设计的时候需要做到“宁可长款，不可短款”的原则，长款是指在出现差错的时候站在我方的角度钱多了的情况，钱少了则是短款，因为如果长款可以给客户退款，而短款则可能钱追不回来了，也就是说在业务设计的时候，一定是先扣客户帐再入帐，如果因为隔离性问题造成覆盖更新，也不会出现钱少了的情况。 ##### Seata Saga模式原理 [Section titled “Seata Saga模式原理”](#seata-saga模式原理) 基于状态机引擎的 Saga 实现: 它基于事件驱动架构，每个步骤都是异步执行的，步骤与步骤之间通过事件队列流转， 极大的提高系统吞吐量。每个步骤执行时会记录事务日志，用于出现异常时回滚时使用，事务日志会记录在与业务表所在的数据库内，提高性能。 ##### “向前” [Section titled ““向前””](#向前) Saga 服务设计经验和TCC类似，内容也是一致的，Saga多了一个 【自定义事务恢复策略】 由于Saga 事务不保证隔离性，在极端情况下可能由于脏写无法完成回滚操作，所以状态机引擎除了提供”回滚”能力还需要提供”向前“执行的恢复操作，让业务最终执行成功。 用户可以根据业务特点配置该流程的事务处理策略是优先“回滚”还是“重试”，当事务超时的时候，服务器端会根据这个策略不断进行重试。 #### Seata XA模式 [Section titled “Seata XA模式”](#seata-xa模式) **前提**: 1. 支持XA 事务的数据库。 2. Java 应用，通过 JDBC 访问数据库。 > XA 协议是由X/Open 公司于1991 年发布的一套标准协议。 XA 是eXtended Architecture 的缩写，因此该协议旨在解决如何在异构系统中保证全局事务的原子性。 在 Seata 定义的分布式事务框架内，利用事务资源(数据库、消息服务等)对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种 事务模式。 从编程模型上，XA 模式与 AT 模式保持完全一致。 ### 除了Seata还有哪些分布式事务框架? [Section titled “除了Seata还有哪些分布式事务框架?”](#除了seata还有哪些分布式事务框架) 1. ByteTCC:美团点评开源的分布式事务框架，基于TCC补偿机制实现，支持高性能和高可用，提供了丰富的API接口和工具支持 2. Nacos-AT:阿里巴巴开源的分布式事务框架，基于TCC补偿机制实现，可与Nacos和Spring Cloud等分布式框架无缝集成 3. SkyWalking-Tx: Apache SkyWalking社区开源的分布式事务框架，支持TCC和Saga等事务模式，提供了完善的监控和追踪功能。 4. TCC-Transaction:华为开源的分布式事务框架，基于TCC补偿机制实现，支持高性能和高可用，提供了简单易用的API接口和工具支持。 5. Atomikos:开源的Java事务管理器，支持XA协议，可用于实现分布式事务的控制和管理，提供了简单易用的API接口和工具支持。 ### 使用Seata会遇到哪些问题 [Section titled “使用Seata会遇到哪些问题”](#使用seata会遇到哪些问题) 1. 在高并发下出现的问题：AT模式获取全局锁失败 Seata的AT、XA模式都是基于全局事务实现的，在高并发的场景下会出现获取全局锁异常，因此这两种模式都不适用高并发场景； Seata TCC模式性能比AT模式的好一点，但是并发量大于100的话还是不适合； 如果基本没有什么并发量的话，可以选择AT模式；并发量在一百内的话可以使用TCC模式 高并发场景，不适合使用Seata，适合用中间件，例如用rocketmq替代Seata，可以弥补Seata的不足 2. 高并发超时 容易犯的错误: 服务调用->发现注解->创建事务->`等待锁->获取锁`->业务处理 调整代码顺序就可以解决: 用户请求`->等待锁->获取锁`->服务调用->发现注解->创建事务->业务处理 3. 还遇到一些字段长度的问题,调整表的字段长度。但是在最新版的Seata上想这些问题都已经解决了 # 雪花算法在分布式场景下生成重复的Id > 雪花算法在分布式场景下生成重复的Id [雪花算法 ](/software-engineer/algorithm/snow-flake-id)了解一下雪花算法 ### 背景 [Section titled “背景”](#背景) workId重复导致生成重复的ID ### 如何解决 [Section titled “如何解决”](#如何解决) 给每个节点分配不同的workId即可。 ### 实现途径 [Section titled “实现途径”](#实现途径) 1. 每个节点所在服务器预置不同的workId,然后由程序来读取。 2. 搞一个协调者,来统一记录已使用的workId,其他节点获取记录的最大值,自增后使用。另外需要将自增后的值回写到配置。全程需要使用分布式锁,防止并发问题 ### 方案分析 [Section titled “方案分析”](#方案分析) 1. 第一种方案需要在服务器上维护,不灵活,如果有什么变动(例如临时扩容)就需要修改服务器上的配置 2. 第二种方案不需要再服务器上维护任何数据,但是需要引入一个协调者和一个分布式锁来解决。 最终我们选择了第二种方案。原因如下: * 只在初始化时执行一次分配workId,后续都不需要执行 * 分布式配置中心和基于Redis的分布式锁在项目中是成熟的,可以直接使用 #### 流程图 [Section titled “流程图”](#流程图) 一图胜千言,直接上图 > 这里核心采用的是分布式配置中心做workId的注册抢占方案,而Redis只是做了一个分布式锁。当然这里完全也可以使用Redis做抢占注册。原理都是一样的,只是实现不同而已  # 分布式任务调度分片 > 分布式任务调度-多节点Job且Job的代码所有节点是一致 起因是这样的,我之前所在的公司(2023年之前)都是单实例的Job,所以不存在分布式场景下的问题需要处理。这也意味着如果有大量的数据需要处理,始终只有一个节点在哼哧哼哧的处理,效率非常低。 而我去面试的时候,不止一次被问到分布式场景下Job是怎么处理的。包括我现在所在的公司,他们在job的处理上也进行了分布式场景下的分片操作。 那么如何进行分片呢? 现在很有多分布式任务调度框架支持分片,例如xxl-job,支持在代码中获取当前分片和分片总数,在程序里对**固定区间**的数据根据总分片数做分片计算即可。 假设现在有3个Job实例,数据量为10:  #### 现在基于支持分片功能的分布式调度中心框架来实现分片 [Section titled “现在基于支持分片功能的分布式调度中心框架来实现分片”](#现在基于支持分片功能的分布式调度中心框架来实现分片) 分片总数(totalSharding)一般为有效的实例总数,这里为3, 即 `totalSharding = 3` 需要处理的数据量(total)为10,即 `total = 10` 每个分片需要处理的数据量为 `total / totalSharding`, 如果有余数,交给最后的一个Job节点处理(这里只是一个简单的策略,实际生产环境可能会根据谁处理更快、谁资源充足等各种条件来决策) 即: * JobA处理的数据量为: 1-3 * JobA处理的数据量为: 4-6 * JobA处理的数据量为: 7-10 #### 如果分布式调度框架不支持分片,每次都是所有的节点一起触发,又要怎么处理呢? [Section titled “如果分布式调度框架不支持分片,每次都是所有的节点一起触发,又要怎么处理呢?”](#如果分布式调度框架不支持分片每次都是所有的节点一起触发又要怎么处理呢) 其实很简单,我们模拟支持分片的分布式调度框架就好了。支持分片的分布式调度框架之所以支持分片,是因为框架在内存(或者其他地方)维护了实例数和用户期望的分片数据。基于这个思想我们就可以搞一个地方来存储,例如放到Redis、配置中心、DB、(甚至可以是)文件等等 在这里举一个例子,有10个店铺需要拉单,期望每个Job实例处理一部分店铺。我们只要把每个店铺所负责的店铺维护在Redis就可以了。在任务触发时根据实例所负责的店铺数据来拉单就好了,如果不是自己所负责的,则不用管。 即: 1. 每个Job实例都有一个唯一标识,例如 Job实例的 ip + 端口,如果还不能判断唯一,就继续添加标识,例如机器码,直到可以判断唯一即可。实在不行,就采用抢占式的方案来竞争,这样就不用费劲找唯一标识了 2. 将10个店铺按照实例数简单的切分一下(如果公司有切分规则,按照规则切分就好),放到一个数据结构里就好，例如放到`Map> instanceShopIdMap`, key是实例的唯一标识,value是实例所负责的店铺。将`instanceShopIdMap`转化为Json存储到Redis即可 3. 在每个job执行任务时,通过`instanceShopIdMap.get(实例的唯一标识)`来获取所负责的店铺,执行后续的业务逻辑即可 > instanceShopIdMap接口最好写一个定时任务,定时刷新,因为可能会存在新增、删除店铺之类的操作,或者Job实例扩容、缩容等操作 #### 最后 [Section titled “最后”](#最后) 现在基本上都是集群了,很少有单机。当然现在有很多框架帮我们做了分配,这篇文章的内容旨在告诉大家如何自己实现任务分配,对于平时看代码或者业务实现可能会有一定的帮助 # ZooKeeper > ZooKeeper zk是个数据库，文件存储系统，并且有监听通知机制(观察者模式). ### zk存储的节点 [Section titled “zk存储的节点”](#zk存储的节点) * 持久化节点(zk断开节点还在) * 持久化顺序编号目录节点 * 临时目录节点(客户端断开后节点就删除了) * 临时目录编号目录节点(可以实现分布式锁) > 节点名称都是唯一的 ### zk应用场景 [Section titled “zk应用场景”](#zk应用场景) * 服务注册与订阅(共用节点) * 分布式通知(监听znode) * 服务命名(znode特性) * 数据订阅、发布(watcher) * 分布式锁(临时节点) ### zk工作原理 [Section titled “zk工作原理”](#zk工作原理) ZooKeeper(后面简称zk)的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab (ZooKeeper Atomic Broadcast)协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。原子广播用于保证所有的变更操作按照相同的顺序在所有节点上被应用。 **细节:** * 数据模型: ZooKeeper维护一个分层的命名空间，类似于文件系统，其中每个节点称为”znode”。每个znode都可以存储一小段数据，同时每个znode都有一个版本号(version)，用于实现乐观并发控制 * 分布式存储: Zookeeper的数据存储分布在多个节点上，这些节点称为”ZooKeeper服务器”或”ZooKeeper集群”。数据的每次变更都需要经过多数节点的一致性确认，以确保数据的可靠性和一致性。 * **Zab协议**: Zab协议是ZooKeeper的核心组件，用于确保数据的一致性。它基于Paxos算法，但针对ZooKeeper的需求进行了定制。Zab协议分为**两个阶段(准备阶段&&提交阶段)**：Leader Election(领导者选举)和Atomic Broadcast(原子广播)。领导者选举阶段用于选举一个Leader节点，而原子广播阶段用于保证所有的变更操作按照相同的顺序在所有节点上被应用。 > Zab协议通过原子广播的方式，在分布式系统中实现了一致性和可靠性，保证了数据的一致性和正确性 * **Leader-Follower模型**: ZooKeeper集群中有一个Leader节点和多个Follower节点。Leader节点负责处理客户端的读写请求，而Follower节点负责复制Leader的数据。如果Leader节点发生故障，集群会重新选举一个新的Leader。**新的 Leader 通过比对已完成的事务日志和未完成的临时提案来进行恢复**。 * 客户端交互: 客户端通过连接到ZooKeeper集群中的任何一个节点来与ZooKeeper交互。客户端可以发送读取请求(例如get操作)和写入请求(例如create、set和delete操作)。 * 顺序性操作: Zookeeper保持客户端请求的顺序，以确保一致性。每个操作都会分配一个全局唯一的序列号(zxid)，并且只有在Leader节点成功将操作应用到大多数Follower节点后，才会被认为是提交成功。 * 事件通知: ZooKeeper支持事件通知机制，客户端可以注册对特定znode的事件关注，一旦该znode发生变化，ZooKeeper将通知相关客户端。 ### zk相关的问题 [Section titled “zk相关的问题”](#zk相关的问题) #### 在看zk的时候,突然想到Apollo配置中心,它的服务注册发现没有使用zk,而是使用了eureka。 [Section titled “在看zk的时候,突然想到Apollo配置中心,它的服务注册发现没有使用zk,而是使用了eureka。”](#在看zk的时候突然想到apollo配置中心它的服务注册发现没有使用zk而是使用了eureka)  > 该图片来自互联网 #### dubbo为什么选择zk作为注册中心? [Section titled “dubbo为什么选择zk作为注册中心?”](#dubbo为什么选择zk作为注册中心) 1. Zookeeper的数据模型很简单，有一系列被称为ZNode的数据节点组成，与传统的磁盘文件系统不同的是，zk将全量数据存储在内存中，可谓是高性能，而且支持集群，可谓高可用，另外支持事件监听。这些特点决定了zk特别适合作为注册中心(数据发布/订阅) 2. 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。 3. Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为Dubbox 服务的注册中心，工业强度较高，可用于生产环境。 4. 使用zk的优势: 1. 当提供程序意外停止时，注册表服务器可以自动删除其信息。 2. 注册表服务器重新启动时，可以自动恢复所有注册数据和订阅请求。 3. 会话过期后，可以自动恢复所有注册数据和订阅请求。  > 该图片来自互联网 #### zk与eureka区别 [Section titled “zk与eureka区别”](#zk与eureka区别) * zookeeper保证CP(一致性) > 所以在很多微服务上,用作注册中心,这样多个微服务的数据都是一致的 * zk在选举期间注册服务瘫痪，期间不可用 * eureka保证AP(可用性) * eureka各个节点平等关系，只要有一台就可保证服务可用(只不过查询到的数据可能不是最新的)，可以很好应对网络故障导致部分节点失联情况 * zk有leader和follower角色，eureka各个节点平等 * zk采用半数存活原则(避免脑裂)，eureka采用自我保护机制来解决分区问题 eureka本质是个工程，zk只是一个进程。 zk基于CP，不保证高可用，如果zk正在选主，或者zk集群中半数以上机器不可用，那么将无法获得数据。 Eureka基于AP，能保证高可用，即使所有机器都挂了，也能拿到本地缓存的数据。作为注册中心，其实配置是不经常变动的，只有发版(发布新的版本)和机器出故障时会变。对于不经常变动的配置来说，CP是不合适的，而AP在遇到问题时可以用牺牲一致性来保证可用性，既返回旧数据，缓存数据。 所以【理论上Eureka是更适合做注册中心】。而现实环境中大部分项目可能会使用ZooKeeper，那是因为集群不够大，并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题。 **eureka自我保护机制** * eureka不移除长时间没收到心跳而应该过期的服务 * 仍然接受新服务注册和查询请求，但是不会同步到其它节点(高可用) * 当网络稳定后，当前实例新注册信息会同步到其它节点(最终一致性) #### ZooKeeper 如何进行崩溃修复？ [Section titled “ZooKeeper 如何进行崩溃修复？”](#zookeeper-如何进行崩溃修复) 在 ZooKeeper 中有三种节点类型，它们分别是： * Leader(主节点)：能够处理读写请求，也同时负责同步写事务请求给其他节点且需要保证事务的顺序性，是整个集群的老大。 * Follower(跟随者)：只负责处理读请求，无权写，因此收到写请求需要转发给 Leader 处理，待 Leader 写完后再同步给 Follower。如果 Leader 挂了，那么 Follower 是有资格参与竞选的。 * Observer(观察者)：和 Follower 一样，唯一不同的是，不参与 Leader 的选举，可以利用不参与 Leader 选举的特性用来线性扩展读的 QPS。 也就是说，所有写操作会先到 Leader 节点，然后 Leader 节点在通过 2PC(两阶段提交：预提交、ACK、确认提交等流程)来进行数据同步，当写入成功过半就认为信息写入成功。而跟随者和观察者是为了增加读性能的，只不过跟随者还可以通过竞选主节点来保证集群的稳定性。 # 应用接入ES,通用逻辑抽象 > 应用接入ES,通用逻辑抽象 ### 接入ES,通用流程 [Section titled “接入ES,通用流程”](#接入es通用流程)  ### ES安装 [Section titled “ES安装”](#es安装) [docker](/software-engineer/deploy/docker-dev-env#es-docker-install) ### 操作ES ORM框架 [Section titled “操作ES ORM框架”](#操作es-orm框架) > 🚀ElasticSearch搜索引擎ORM框架 ### Canal数据解析基类 [Section titled “Canal数据解析基类”](#canal数据解析基类) Canal数据封装 ```java @Data public class BaseCanalData { // 这里使用泛型来替代不同的表实体 private String type; // 操作类型 INSERET、UPDATE、DELETE private String table; private String database; private List data; // 当前数据 private List old; // 旧数据 private Boolean isDdl; private String sql; } ``` ### 实时数据写入ES [Section titled “实时数据写入ES”](#实时数据写入es) [Canal消息处理,写入ES ](/software-engineer/best-practices/general-ability/canal-handler) ### 刷数脚本 [Section titled “刷数脚本”](#刷数脚本) [抽象刷数逻辑 ](/software-engineer/best-practices/general-ability/flash-data) # 正确的使用ES > 正确的使用ES 我遇见过的使用ES大部分的姿势是【数据】+【条件】揉在一起。其实这样做有这样做的好处，即不用回表。 正确的使用姿势是 【主数据唯一标识字段】+【条件】，主数据通过回表获取。 ### 索引迁移 [Section titled “索引迁移”](#索引迁移) ```bash curl -X POST "localhost:9200/_reindex" \ -u username:password \ -H 'Content-Type: application/json' \ -d '{ "source": { "index": "source_index" }, "dest": { "index": "target_index" } }' ``` ### 调整ES窗口大小 [Section titled “调整ES窗口大小”](#调整es窗口大小) ```sh PUT /索引名/_settings { "index": { "max_result_window": 500000 } } ``` ### 索引添加字段 [Section titled “索引添加字段”](#索引添加字段) ```plaintext PUT /索引名/_mapping { "properties": { "moatkonField": { "type": "keyword" } } } ``` `"type": "keyword"` 是字段类型,按照实际场景来 # 解决Elasticsearch请求不能执行 > 解决Elasticsearch报错: Request cannot be executed; I/O reactor status: STOPPED #### 异常报错 [Section titled “异常报错”](#异常报错) ```plaintext java.lang.RuntimeException: Request cannot be executed; I/O reactor status: STOPPED at org.elasticsearch.client.RestClient.extractAndWrapCause(RestClient.java:889) at org.elasticsearch.client.RestClient.performRequest(RestClient.java:283) at org.elasticsearch.client.RestClient.performRequest(RestClient.java:270) at org.elasticsearch.client.RestHighLevelClient.performClientRequest(RestHighLevelClient.java:2082) omit... ``` #### 原因排查 [Section titled “原因排查”](#原因排查) 主要参考以下Github issue: 1. [java.lang.IllegalStateException: Request cannot be executed; I/O reactor status: STOPPED](https://github.com/elastic/elasticsearch/issues/39946) 2. [LLRC should detect I/O Reactor failure and log the halting exception](https://github.com/elastic/elasticsearch/issues/49124) 3. [使用ElasticSearch的HLRC（High Level Rest Client）时，报出I/O Reactor STOPPED](https://support.huaweicloud.com/intl/zh-cn/trouble-css/css_10_0019.html) 关于原因分析,上面罗列的第[【3】](https://support.huaweicloud.com/intl/zh-cn/trouble-css/css_10_0019.html)个链接分析的分析的很详细,这里不再啰嗦 #### 尝试解决 [Section titled “尝试解决”](#尝试解决) 重启服务。因为之前从未报这个错误,按照分析重启会解决这个问题。但是实际情况是,重启只能支撑一会儿,后面又报了这个错误 #### 实际解决 [Section titled “实际解决”](#实际解决) 根据排查的原因,是连接被关闭了,那么只要在连接被关闭的时候重建一个连接不就好了吗? 依据这个思路就好办了。因为ElasticSearch客户端没有提供重建连接的方法,所以在Debug ElasticSearch连接建立的过程后,通过以下方法可以解决问题 最简代码 ```java @Resource private RestClientBuilder restClientBuilder; // 根据源码可以知道RestClientBuilder也是单实例,所以这里可以直接取出 @Resource private RestHighLevelClient esClient; // 在Spring中是单例的,这里取到单实例 // 最简单的代码,大家可以根据自己的情况来 public void reCreate(){ esClient = new RestHighLevelClient(restClientBuilder); // 使用新建的实例替代原来的实例 } ``` # Dubbo > Dubbo ### Dubbo工作流程(&原理) [Section titled “Dubbo工作流程(&原理)”](#dubbo工作流程原理)  **第一步**：provider 向注册中心去注册\ **第二步**：consumer 从注册中心订阅服务，注册中心会通知 consumer 注册好的服务\ **第三步**：consumer 调用 provider\ **第四步**：consumer 和 provider 都异步通知监控中心 ### Dubbo的10层架构 [Section titled “Dubbo的10层架构”](#dubbo的10层架构) **第一层**：service 层，接口层，给服务提供者和消费者来实现的\ **第二层**：config 层，配置层，主要是对 Dubbo 进行各种配置的\ **第三层**：proxy 层，服务代理层，无论是 consumer 还是 provider，Dubbo 都会给你生成代理，代理之间进行网络通信\ **第四层**：registry 层，服务注册层，负责服务的注册与发现\ **第五层**：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务\ **第六层**：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控\ **第七层**：protocal 层，远程调用层，封装 rpc 调用\ **第八层**：exchange 层，信息交换层，封装请求响应模式，同步转异步\ **第九层**：transport 层，网络传输层，抽象 mina 和 netty 为统一接口\ **第十层**：serialize 层，数据序列化层 ### 注册中心挂了可以继续通信吗？ [Section titled “注册中心挂了可以继续通信吗？”](#注册中心挂了可以继续通信吗) 可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。 ### SpringCloud和Dubbo的区别 [Section titled “SpringCloud和Dubbo的区别”](#springcloud和dubbo的区别) 1. Dubbo 采用的是传输层 tcp 协议，是二进制传输的，占用带宽较少，序列化采用的是 jdk 自带的序列化协议。 2. SpringCloud 是应用层 http 协议，占用带宽比较多，同时 springcloud 采用的是 json 报文传输，消耗会比较大。 3. Dubbo 调用使用的是长链接，适合传输数据量小的包，而对于 springcloud 是短连接，适合传输大数据量的信息，比如图片、文本之类的。 4. Dubbo 开发需要依赖 jar 包，对依赖的管理比较复杂。springcloud 的接口协议比较松散，约束性不强。 ##### 从其他角度的区别 [Section titled “从其他角度的区别”](#从其他角度的区别) * 初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理 * 生态环境不同：SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。 * 调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。 * 组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper > 开源社区里有许多优秀的 RPC 框架，还有其他的,例如Thrift、gRPC 等 ### Dubbo支持哪些通信协议? [Section titled “Dubbo支持哪些通信协议?”](#dubbo支持哪些通信协议) * Dubbo协议：默认的通信协议，采用单一长连接和NIO异步通信，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。 * REST协议：基于标准的Java REST API实现REST调用。 * Hessian协议：用于集成Hessian的服务，底层采用HTTP通讯，采用Servlet暴露服务。 * HTTP协议：用于应用程序和浏览器JS使用的服务。 * jsonrpc WebService协议：用于系统集成，跨语言调用。 * RMI协议：采用JDK标准的java.rmi.\*实现，采用阻塞式短连接和JDK标准序列化方式。 ### Dubbo支持哪些序列化协议? [Section titled “Dubbo支持哪些序列化协议?”](#dubbo支持哪些序列化协议) * Hessian协议：默认的序列化协议，基于Hessian进行序列化。 * Java二进制序列化：RMI协议使用的序列化方式。 * json序列化：HTTP协议使用的序列化方式。 * SOAP文本序列化：WebServices协议使用的序列化方式。 ### 为什么你们不使用Spring Cloud来做微服务 [Section titled “为什么你们不使用Spring Cloud来做微服务”](#为什么你们不使用spring-cloud来做微服务) * 直接原因是公司的技术架构是基于Dubbo来做的一整套微服务 * 另外的原因,是公司的业务特点决定的,使用Dubbo比较快[->](#springcloud%E5%92%8Cdubbo%E7%9A%84%E5%8C%BA%E5%88%AB) * 像我之前的一家公司,是做的电商ERP系统,这家公司是基于SpringCloud来做的 # RPC > RPC ### 什么是RPC？ [Section titled “什么是RPC？”](#什么是rpc) RPC(Remote Procedure Call): 远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。 RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，**RPC跨越了传输层和应用层**。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。现在业界有很多开源的优秀 RPC 框架，例如 Spring Cloud、Dubbo、Thrift 等。 ### RPC的实现基础 [Section titled “RPC的实现基础”](#rpc的实现基础) 1. 需要有非常高效的网络通信，比如一般选择Netty作为网络通信框架； 2. 需要有比较高效的序列化框架，比如谷歌的Protobuf序列化框架； 3. 可靠的寻址方式(主要是提供服务的发现)，比如可以使用Zookeeper来注册服务等等； 4. 如果是带会话(状态)的RPC调用，还需要有会话和状态保持的功能； ### RPC的主要作用 [Section titled “RPC的主要作用”](#rpc的主要作用) 1. 屏蔽远程调用跟本地调用的区别，让我们感觉就是调用项目内的方法 2. 隐藏底层网络通信的复杂性，让我们更专注于业务逻辑 ### RPC 工作原理 [Section titled “RPC 工作原理”](#rpc-工作原理) RPC的设计由Client，Client stub，Network ，Server stub，Server构成。 其中Client就是用来调用服务的，Cient stub是用来把调用的方法和参数序列化的(因为要在网络中传输，必须要把对象转变成字节)，Network用来传输这些信息到Server stub， Server stub用来把这些信息反序列化的，Server就是服务的提供者，最终调用的就是Server提供的方法。  1. Client像调用本地服务似的调用远程服务； 2. Client stub接收到调用后，将方法、参数序列化 3. 客户端通过sockets将消息发送到服务端 4. Server stub 收到消息后进行解码(将消息对象反序列化) 5. Server stub 根据解码结果调用本地的服务 6. 本地服务执行(对于服务端来说是本地执行)并将结果返回给Server stub 7. Server stub将返回结果打包成消息(将结果消息对象序列化) 8. 服务端通过sockets将消息发送到客户端 9. Client stub接收到结果消息，并进行解码(将结果消息反序列化) 10. 客户端得到最终结果。 ### RPC使用了哪些关键技术？ [Section titled “RPC使用了哪些关键技术？”](#rpc使用了哪些关键技术) 1. 动态代理。生成Client Stub(客户端存根)和Server Stub(服务端存根)的时候需要用到Java动态代理技术，可以使用JDK提供的原生的动态代理机制，也可以使用开源的：CGLib代理，Javassist字节码生成技术。 2. 序列化和反序列化。在网络中，所有的数据都将会被转化为字节进行传送，所以为了能够使参数对象在网络中进行传输，需要对这些参数进行序列化和反序列化操作。 > 序列化：把对象转换为字节序列的过程称为对象的序列化，也就是编码的过程。反序列化：把字节序列恢复为对象的过程称为对象的反序列化，也就是解码的过程。 目前比较高效的开源序列化框架：如Kryo、FastJson和Protobuf等。 > > 反序列化：把字节序列恢复为对象的过程称为对象的反序列化，也就是解码的过程。 目前比较高效的开源序列化框架：如Kryo、FastJson和Protobuf等。 > > Dubbo默认使用的是Hessian2.0框架 3. NIO通信。出于并发性能的考虑，传统的阻塞式IO显然不太合适，因此我们需要异步的IO，即NIO。Java提供了NIO的解决方案，Java 7 也提供了更优秀的NIO.2支持。可以选择Netty或者MINA来解决NIO数据传输的问题。 4. 服务注册中心。可选：Redis、Zookeeper、Consul 、Etcd。一般使用ZooKeeper提供服务注册与发现功能，解决单点故障以及分布式部署的问题(注册中心)。 ### RPC和Restful的对比 [Section titled “RPC和Restful的对比”](#rpc和restful的对比) * 面对对象不同：RPC 更侧重于动作。Restful 的主体是资源。Restful 是面向资源的设计架构，但在系统中有很多对象不能抽象成资源，比如登录，修改密码等而 RPC 可以通过动作去操作资源。所以在操作的全面性上 RPC 大于 Restful。 * **传输效率：RPC 效率更高。RPC使用自定义的 TCP 协议，可以让请求报文体积更小，或者使用 HTTP2 协议，也可以很好的减少报文的体积，提高传输效率。** * 复杂度：RPC实现复杂，流程繁琐。REST 调用及测试都很方便。RPC 实现需要实现编码，序列化，网络传输等。而 Restful 不要关注这些，Restful 实现更简单。 * 灵活性：HTTP 相对更规范，更标准，更通用，无论哪种语言都支持 HTTP 协议。RPC可以实现跨语言调用，但整体灵活性不如 Restful。 * 使用场景: RPC 主要用于公司内部的服务调用，性能消耗低，传输效率高，实现复杂。HTTP 主要用于对外的异构环境，浏览器接口调用，App 接口调用，第三方接口调用等 上面有提到HTTP2协议,那和HTTP1.0、HTTP1.1有啥区别 * 从HTTP/1.0到HTTP/2，都是利用TCP作为底层协议进行通信的。 * HTTP/1.1，引进了长连接(keep-alive)，减少了建立和关闭连接的消耗和延迟。 * HTTP/2，引入了多路复用：连接共享，提高了连接的利用率，降低延迟。 [网络相关的内容](/software-engineer/base/network) ### RPC 框架代表 [Section titled “RPC 框架代表”](#rpc-框架代表) 开源社区里有许多优秀的 RPC 框架，比如常用的有 阿里的[Dubbo](/software-engineer/framework/dubbo/)、google的gRPC、Go语言的rpcx、Apache的thrift等，下面简单介绍一下这几款组件。 ### 一个很常被问到的问题,为什么要使用RPC呢? [Section titled “一个很常被问到的问题,为什么要使用RPC呢?”](#一个很常被问到的问题为什么要使用rpc呢) > 这个从RPC的优点来说就好了 TCP 是有三个特点，面向连接、可靠、基于字节流。 TCP粘包问题: 主要是字节流导致的,字节流可以理解为一个双向的通道里流淌的数据，这个数据其实就是我们常说的二进制数据，简单来说就是一大堆 01 串。纯裸 TCP 收发的这些 01 串之间是没有任何边界的，你根本不知道到哪个地方才算一条完整消息。正因为这个没有任何边界的特点,导致了解析接收到的消息会存在不同的立即。例如当我们选择使用 TCP 发送”夏洛”和”特烦恼”的时候，接收端收到的就是”夏洛特烦恼”，这时候接收端没发区分你是想要表达”夏洛”+“特烦恼”还是”夏洛特”+“烦恼” 纯裸 TCP 是不能直接拿来用的，你需要在这个基础上加入一些自定义的规则，用于区分消息边界。于是我们会把每条要发送的数据都包装一下，比如加入消息头，消息头里写清楚一个完整的包长度是多少，根据这个长度可以继续接收数据，截取出来后它们就是我们真正要传输的消息体。而这里头提到的消息头，还可以放各种东西，比如消息体是否被压缩过和消息体格式之类的，只要上下游都约定好了，互相都认就可以了，这就是所谓的协议。 于是基于 TCP，就衍生了非常多的协议，比如 HTTP 和 **RPC**。  TCP 是传输层的协议，而基于 TCP 造出来的 HTTP 和各类 RPC 协议，它们都只是定义了不同消息格式的应用层协议而已。 HTTP 协议（Hyper Text Transfer Protocol），又叫做超文本传输协议。我们用的比较多，平时上网在浏览器上敲个网址就能访问网页，这里用到的就是 HTTP 协议。而 RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。 #### RPC底层连接形式 [Section titled “RPC底层连接形式”](#rpc底层连接形式) 以主流的 HTTP/1.1 协议为例，其默认在建立底层 TCP 连接之后会一直保持这个连接（Keep Alive），之后的请求和响应都会复用这条连接。 而 RPC 协议，也跟 HTTP 类似，也是通过建立 TCP 长链接进行数据交互，但不同的地方在于，RPC 协议一般还会再建个连接池，在请求量大的时候，建立多条连接放在池内，要发数据的时候就从池里取一条连接出来，用完放回去，下次再复用。 > 由于连接池有利于提升网络请求性能，所以不少编程语言的网络库里都会给 HTTP 加个连接池 #### 传输的内容 [Section titled “传输的内容”](#传输的内容) 基于 TCP 传输的消息，说到底，无非都是消息头 Header 和消息体 Body。 Header 是用于标记一些特殊信息，其中最重要的是消息体长度。 Body 则是放我们真正需要传输的内容。 > 对于主流的 HTTP/1.1，虽然它现在叫超文本协议，支持音频视频，但 HTTP 设计初是用于做网页文本展示的，所以它传的内容以字符串为主。Header 和 Body 都是如此  可以看到这里面的内容非常多的冗余，显得非常啰嗦。最明显的，像 Header 里的那些信息，其实如果我们约定好头部的第几位是 Content-Type，就不需要每次都真的把”Content-Type”这个字段都传过来，类似的情况其实在 body 的 Json 结构里也特别明显。 而 RPC，因为它定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。 HTTP/2 在前者的基础上做了很多改进，所以性能可能比很多 RPC 协议还要好，甚至连 gRPC 底层都直接用的 HTTP/2。由于 HTTP/2 是 2015 年出来的。那时候很多公司内部的 RPC 协议都已经跑了好些年了，基于历史原因，一般也没必要去换了。 #### http2相比于http1.1有哪些优势？ [Section titled “http2相比于http1.1有哪些优势？”](#http2相比于http11有哪些优势) ##### http1的缺点 [Section titled “http1的缺点”](#http1的缺点) * 线头阻塞：方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞； * 没有充分的利用TCP链接： HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8个的TCP链接请求限制 ##### http2优点 [Section titled “http2优点”](#http2优点) * 多路复用：最有价值的优点，解决了线头阻塞的问题，允许单一的http2连接可以发送多重的请求和响应，充分的利用TCP。 使得 资源分域名、雪碧图、内联样式等不再适用。 * header压缩：HTTP2.0可以在客户端和服务器端维护静态字典和动态字典用来压缩和差量更新HTTP头部，大大降低因头部传输产生的流量。非两个字典内的header可以适用哈夫曼压缩方式进行压缩。 * 新的二进制格式：http1.x 是文本格式传输，http2是二进制格式传输。 * 服务端推送：服务器端可以主动向客户端推送资源。 ##### 总结 [Section titled “总结”](#总结) * 纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义消息边界。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。 * RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。 * 从发展历史来说，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，所以对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC 协议进行通讯。 * RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP/1.1 性能要更好，所以大部分公司内部都还在使用 RPC。 * HTTP/2.0 在 HTTP/1.1 的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。 *** 参考: * [Dubbo官网](https://cn.dubbo.apache.org/zh-cn/blog/2019/01/07/%E6%B5%85%E8%B0%88-rpc/) * [既然有 HTTP 协议，为什么还要有 RPC？](https://www.xiaolincoding.com/network/2_http/http_rpc.html) # MyBatis > MyBatis ### MyBatis 的核心组件 [Section titled “MyBatis 的核心组件”](#mybatis-的核心组件) > 有次面试被问到了 * SqlSession: 表示与数据库交互的会话,完成对数据库的CURD功能。 * Executor: MyBatis执行器,调度核心,负责Mybatis的SQL语句生成和查询缓存的维护。 * StatementHandler: 封装了JDBC statement操作,负责对JDBC statement操作,如设置参数,将结果映射成集合。 * ParameterHandler: 负责将用户传递的参数转换成JDBC statement所需的参数。 * TypeHandler: 负责将Java类型和JDBC类型之间的映射和转换。 * MappedStatement: MappedStatement对象对应Mapper.xml配置文件中的一个select/update/insert/delete节点，描述的就是一条SQL语句。 * SqlSource: 负责根据用户传递的parametreObject动态生成SQL,将信息封装到BoundSQL对象并返回。 * BoundSql: 标识动态生成的SQL语句以及相应的参数信息。 * Configuration: Mybatis中所有的配置信息都存储在此处。 ### MyBatis 原理 [Section titled “MyBatis 原理”](#mybatis-原理) MyBatis 使用 JDK 的动态代理  > 该图片来自互联网 1. sqlsessionFactoryBuilder生成sqlsessionFactory(单例) 2. 工厂模式生成sqlsession执行sql以及控制事务 3. Mybatis通过动态代理使Mapper(sql映射器)接口能运行起来,即为接口生成代理对象,将sql查询到结果映射成pojo **sqlSessionFactory构建过程**: * 解析并读取配置中的xml创建Configuration对象 (单例) * 使用Configruation类去创建sqlSessionFactory(builder模式) ### Mybatis一级缓存与二级缓存 [Section titled “Mybatis一级缓存与二级缓存”](#mybatis一级缓存与二级缓存) #### 一级缓存 [Section titled “一级缓存”](#一级缓存) 是指 SqlSession 级别的缓存 原理：使用的数据结构是一个 map，如果两次中间出现 commit 操作 (修改、添加、删除)，本 sqlsession 中的一级缓存区域全部清空 > 默认情况下一级缓存是开启的，而且是不能关闭的 最多缓存1024条SQL > > STATEMENT: 只对当前执行的这一个Statement有效 > > > > 缺点: MyBatis的一级缓存最大范围是SqlSession内部，有多个SqlSession或者分布式的环境下，数据库写操作会引起脏数据，建议设定缓存级别为Statement。 #### 二级缓存(范围更广) [Section titled “二级缓存(范围更广)”](#二级缓存范围更广) 如果多个SqlSession之间需要共享缓存，则需要使用到二级缓存 二级缓存开启后，同一个namespace下的所有操作语句，都影响着同一个Cache，即二级缓存被多个SqlSession共享，是一个全局的变量。 当开启缓存后，数据的查询执行的流程就是 二级缓存 -> 一级缓存 -> 数据库。 > 有一个面试官说这个就是Mapper级别的缓存，也没有问题 二级缓存开启后速度快的原因是: 因为是Mapper级别的,A线程访问过会缓存下结果,如果B线程再次以同样的条件访问,就会使用缓存,就不会再去查库了 > 个人建议MyBatis缓存特性在生产环境中进行关闭，单纯作为一个ORM框架使用可能更为合适 Mapper 级别的缓存； 原理： 是通过 CacheExecutor 实现的。CacheExecutor其实是 Executor 的代理对象 ### MyBatis的设计模式 [Section titled “MyBatis的设计模式”](#mybatis的设计模式) 1. **建造者模式: SqlSessionFactoryBuilder** 2. **工厂模式: SqlSessionFactory** 3. **代理模式: MapperProxyFactory: MapperProxyFactory 的 newInstance() 方法就是生成一个具体的代理来实现某个功能** 4. **适配器模式: Mybatis的日志模块,可以支持slf4j、log4j等** 5. 单例模式: ErrorContext: ErrorContext是线程级别的的单例，每个线程中有一个此对象的单例，用于记录该线程的执行环境的错误信息。 6. 模板方法模式: BaseExecutor，在 MyBatis 中 BaseExecutor 实现了大部分SQL 执行的逻辑。 7. 装饰器(我理解的就是锦上添花)模式: Cache: Cache 除了有数据存储和缓存的基本功能外(由 PerpetualCache 永久缓存实现)，还有其他附加的 Cache 类，比如先进先出的 FifoCache、最近最少使用的 LruCache、防止多线程并发访问的 SynchronizedCache 等众多附加功能的缓存类 # Spring > Spring ### Spring 有哪些模块 [Section titled “Spring 有哪些模块”](#spring-有哪些模块) * Spring Core: 框架的最基础部分，提供 IoC 容器，对 bean 进行管理。 * Spring Context: 继承BeanFactory，提供上下文信息，扩展出JNDI、EJB、电子邮件、国际化等功能。 * Spring DAO: 提供了JDBC的抽象层，还提供了声明性事务管理方法 * Spring ORM: 提供了JPA、JDO、Hibernate、MyBatis 等ORM映射层. * Spring AOP: 集成了所有AOP功能 * Spring Web: 提供了基础的 Web 开发的上下文信息，现有的Web框架，如JSF、Tapestry、Structs等，提供了集成 * Spring Web MVC: 提供了 Web 应用的 Model-View-Controller 全功能实现。 ### Spring Bean定义了哪5中作用域 [Section titled “Spring Bean定义了哪5中作用域”](#spring-bean定义了哪5中作用域) * singleton(单例): singleton 是 Spring 中默认的 Bean 作用域，它表示在整个应用程序中只存在一个 Bean 实例。每次请求该 Bean 时，都会返回同一个实例。 * prototype: 表示每次请求该 Bean 时都会创建一个新的实例。每个实例都有自己的属性值和状态，因此它们之间是相互独立的。 * request: 表示在一次 HTTP 请求中只存在一个 Bean 实例。在同一个请求中，多次请求该 Bean 时都会返回同一个实例。不同的请求之间，该 Bean 的实例是相互独立的。 * session: 表示在一个 HTTP Session 中只存在一个 Bean 实例。在同一个 Session 中，多次请求该 Bean 时都会返回同一个实例。不同的 Session 之间，该 Bean 的实例是相互独立的。 * application: 表示在一个 ServletContext 中只存在一个 Bean 实例。该作用域只在 Spring ApplicationContext 上下文中有效。 * websocket: 表示在一个 WebSocket 中只存在一个 Bean 实例。该作用域只在 Spring ApplicationContext 上下文中有效。 ##### 关于Spring默认的singleton单例作用域 [Section titled “关于Spring默认的singleton单例作用域”](#关于spring默认的singleton单例作用域) * 大部分时候我们并没有在项目中使用多线程，所以很少有人会关注这个问题。单例 bean 存在线程问题，主要是因为当多个线程操作同一个对象的时候是存在资源竞争的。 * Spring的Controller默认是单例的，不要使用非静态的成员变量，否则会发生数据逻辑混乱。是因为单例所以不是线程安全的。 > **解决方案:** > > 1. 不要在controller中定义成员变量。 > 2. 万一必须要定义一个非静态成员变量时候，则通过注解@Scope(“prototype”)，将其设置为多例模式。 > 3. 在Controller中使用ThreadLocal变量 ##### 单例的bean是线程安全的吗? [Section titled “单例的bean是线程安全的吗?”](#单例的bean是线程安全的吗) 无状态的单例 Bean 是线程安全的，而有状态的单例 Bean 是非线程安全的，所以总的来说单例 Bean 还是非线程安全的。 有状态的 Bean 是指 Bean 中包含了状态，比如成员变量，而无状态的 Bean 是指 Bean 中不包含状态，比如没有成员变量，或者成员变量都是 final 的。 **如何保证单例bean的线程安全?** * 变为原型 Bean：在 Bean 上添加 @Scope(“prototype”) 注解，将其变为多例 Bean。这样每次注入时返回一个新的实例，避免竞争。 * 加锁：在 Bean 中对需要同步的方法或代码块添加同步锁 @Synchronized 或使用 Java 中的线程同步工具 ReentrantLock 等。 * 使用线程安全的集合：如 Vector、Hashtable 代替 ArrayList、HashMap 等非线程安全集合。 * 变为无状态 Bean：不在 Bean 中保存状态，让 Bean 成为无状态 Bean。无状态的 Bean 没有共享变量，自然也无须考虑线程安全问题。使用线程局部变量 ThreadLocal：在方法内部使用线程局部变量 ThreadLocal，因为 ThreadLocal 是线程独享的，所以也不存在线程安全问题。 ### Spring如解决Bean循环依赖问题? [Section titled “Spring如解决Bean循环依赖问题?”](#spring如解决bean循环依赖问题) #### 怎么检测是否存在循环依赖? [Section titled “怎么检测是否存在循环依赖?”](#怎么检测是否存在循环依赖) Bean在创建的时候可以给该Bean打标，如果递归调用回来发现正在创建中的话，即说明了循环依赖了 #### Spring中循环依赖场景有 [Section titled “Spring中循环依赖场景有”](#spring中循环依赖场景有) * 构造器的循环依赖 * 属性的循环依赖 #### Spring Bean 缓存 [Section titled “Spring Bean 缓存”](#spring-bean-缓存) * singletonObjects: 第一级缓存，里面放置的是实例化好的单例对象； * earlySingletonObjects: 第二级缓存，里面存放的是提前曝光的单例对象； * singletonFactories: 第三级缓存，里面存放的是要被实例化的对象的对象工厂 #### 解决过程 [Section titled “解决过程”](#解决过程) 创建bean的时候Spring首先从一级缓存singletonObjects中获取。如果获取不到，并且对象正在创建中，就再从二级缓存earlySingletonObjects中获取，如果还是获取不到就从三级缓存singletonFactories中取(Bean调用构造函数进行实例化后，即使属性还未填充，就可以通过三级缓存向外提前暴露依赖的引用值(提前曝光)，根据对象引用能定位到堆中的对象，其原理是基于Java的引用传递)，取到后从三级缓存移动到了二级缓存完全初始化之后将自己放入到一级缓存中供其他使用. > 因为加入singletonFactories三级缓存的前提是执行了构造器，所以构造器的循环依赖没法解决。 > > 构造器循环依赖解决办法：在构造函数中使用@Lazy注解延迟加载。在注入依赖时，先注入代理对象，当首次使用时再创建对象。 提示 局限性: Spring默认的Bean Scope是单例的，而三级缓存中都包含singleton，可见是对于单例Bean之间的循环依赖的解决，Spring是通过三级缓存来实现的 但是这也仅仅是解决了单例Bean的循环依赖，多例情况下，还是会有问题 ### Bean的生命周期?(创建Bean的过程) [Section titled “Bean的生命周期?(创建Bean的过程)”](#bean的生命周期创建bean的过程)  1. **实例化Bean： Ioc容器通过获取BeanDefinition对象中的信息进行实例化，实例化对象被包装在BeanWrapper对象中** 2. **设置对象属性(DI)：通过BeanWrapper提供的设置属性的接口完成属性依赖注入** 3. 注入Aware接口：Spring会检测该对象是否实现了xxxAware接口，并将相关的xxxAware实例注入给bean 4. BeanPostProcessor：自定义的处理(分前置处理和后置处理) 5. **InitializingBean和init-method：执行我们自己定义的初始化方法** 6. **使用** 7. **destroy：bean的销毁** ### Spring 中使用了哪些设计模式？ [Section titled “Spring 中使用了哪些设计模式？”](#spring-中使用了哪些设计模式) * 工厂模式: spring中的BeanFactory就是简单工厂模式的体现，根据传入唯一的标识来获得bean对象； * 观察者模式: spring中Observer模式常用的地方是listener的实现。如ApplicationListener。 * 代理模式: AOP功能的原理就使用代理模式。 1. JDK动态代理 2. CGLib字节码生成技术代理 * 单例模式: 提供了全局的访问点BeanFactory； * 装饰器模式: 依赖注入就需要使用BeanWrapper * 策略模式: Bean的实例化的时候决定采用何种方式初始化bean实例(反射或者CGLIB动态字节码生成) * 模板方法模式: Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式 ### SpringMVC [Section titled “SpringMVC”](#springmvc) **处理请求的流程** 1. 用户请求发送给DispatcherServlet，DispatcherServlet调用HandlerMapping处理器映射器； 2. HandlerMapping根据xml或注解找到对应的处理器，生成处理器对象返回给DispatcherServlet； 3. DispatcherServlet会调用相应的HandlerAdapter； 4. HandlerAdapter经过适配调用具体的处理器去处理请求，生成ModelAndView返回给DispatcherServlet 5. DispatcherServlet将ModelAndView传给ViewReslover解析生成View返回给DispatcherServlet； 6. DispatcherServlet根据View进行渲染视图； ### SpringBoot [Section titled “SpringBoot”](#springboot) #### 启动流程 [Section titled “启动流程”](#启动流程) * new SpringApplication对象，利用spi机制加载applicationContextInitializer，applicationListener接口实例(META-INF/spring.factories)； > Spring的SPI(Service Provider Interface)机制是一种用于实现扩展点的机制，允许开发者在不修改核心代码的情况下添加自定义实现或插件。SPI机制常用于模块化和扩展化的设计，让应用更加灵活和可扩展。 * 调run方法准备Environment，加载应用上下文(applicationContext)，发布事件 很多通过listener实现 * 创建spring容器， refreshContext() ，实现starter自动化配置，spring.factories文件加载， bean实例化 #### SpringBoot自动配置的原理 [Section titled “SpringBoot自动配置的原理”](#springboot自动配置的原理) * @EnableAutoConfiguration找到META-INF/spring.factories(需要创建的bean在里面)配置文件 * 读取每个starter中的spring.factories文件 #### Spring Boot 的核心注解 [Section titled “Spring Boot 的核心注解”](#spring-boot-的核心注解) @SpringBootApplication,由以下三种组成 * @SpringBootConfiguration：组合了 @Configuration 注解，实现配置文件的功能。 * @EnableAutoConfiguration：打开自动配置的功能。 * @ComponentScan：Spring组件扫描。 #### Spring Boot 的核心配置文件 [Section titled “Spring Boot 的核心配置文件”](#spring-boot-的核心配置文件) * application.yml 一般用来定义单个应用级别的，如果搭配 spring-cloud-config 使用 * bootstrap.yml(先加载) 系统级别的一些参数配置，这些参数一般是不变的 #### SpringBoot 自动装配原理 [Section titled “SpringBoot 自动装配原理”](#springboot-自动装配原理) 1. 什么是 SpringBoot 自动装配？ SpringBoot 定义了一套接口规范，这套规范规定：SpringBoot 在启动时会扫描外部引用 jar 包中的META-INF/spring.factories文件，将文件中配置的类型信息加载到 Spring 容器(此处涉及到 JVM 类加载机制与 Spring 的容器知识)，并执行类中定义的各种操作。对于外部 jar 来说，只需要按照 SpringBoot 定义的标准，就能将自己的功能装置进 SpringBoot。 2. SpringBoot 是如何实现自动装配的？ @EnableAutoConfiguration:实现自动装配的核心注解。 AutoConfigurationImportSelector:加载自动装配类 AutoConfigurationImportSelector 类实现了 ImportSelector接口，也就实现了这个接口中的 selectImports方法，该方法主要用于获取所有符合条件的类的全限定类名，这些类需要被加载到 IoC 容器中。 # AOP > AOP ### AOP实现的原理 [Section titled “AOP实现的原理”](#aop实现的原理) Spring AOP 的实现原理是基于动态代理和字节码操作的。 在编译时， Spring 会使用 AspectJ 编译器将切面代码编译成字节码文件。在运行时， Spring 会使用 Java 动态代理或 CGLIB 代理生成代理类，这些代理类会在目标对象方法执行前后插入切面代码，从而实现AOP的功能。 ### JDK动态代理、CGLIB代理 [Section titled “JDK动态代理、CGLIB代理”](#jdk动态代理cglib代理) 当bean的实现中存在接口或者是Proxy的子类，使用jdk动态代理；不存在接口，spring会采用CGLIB来生成代理对象 **JDK 动态代理主要涉及到 java.lang.reflect 包中的两个类：Proxy 和 InvocationHandler** * 通过bind方法建立代理与真实对象关系，通过Proxy.newProxyInstance(target)生成代理对象 * 代理对象通过反射invoke方法实现调用真实对象的方法 **Proxy 利用 InvocationHandler(定义横切逻辑) 接口动态创建 目标类的代理对象** Note ##### 动态代理与静态代理区别 [Section titled “动态代理与静态代理区别”](#动态代理与静态代理区别) 静态代理，程序运行前代理类的.class文件就存在了； 动态代理：在程序运行时利用反射动态创建代理对象 ##### CGLIB与JDK动态代理区别 [Section titled “CGLIB与JDK动态代理区别”](#cglib与jdk动态代理区别) Jdk动态代理必须提供接口才能使用; CGLIB不需要，只要一个非抽象类就能实现动态代理 故CGLIB的适用范围更广 ### AOP源码分析 [Section titled “AOP源码分析”](#aop源码分析) * `@EnableAspectJAutoProxy`给容器(beanFactory)中注册一个AnnotationAwareAspectJAutoProxyCreator对象； * AnnotationAwareAspectJAutoProxyCreator对目标对象进行代理对象的创建，对象内部，是封装JDK和CGlib两个技术，实现动态代理对象创建的(创建代理对象过程中，会先创建一个代理工厂，获取到所有的增强器(通知方法)，将这些增强器和目标类注入代理工厂，再用代理工厂创建对象)； * 代理对象执行目标方法，得到目标方法的拦截器链，利用拦截器的链式机制，依次进入每一个拦截器进行执行 ### AOP核心概念 [Section titled “AOP核心概念”](#aop核心概念) * 切面(aspect): 类是对物体特征的抽象，切面就是对横切关注点的抽象 * 横切关注点：对哪些方法进行拦截，拦截后怎么处理，这些关注点称之为横切关注点 * 连接点(joinpoint): 被拦截到的点，因为 Spring 只支持方法类型的连接点，所以在Spring 中连接点指的就是被拦截到的方法，实际上连接点还可以是字段或者构造器 * 切入点(pointcut): 对连接点进行拦截的定义 * 通知(advice): 所谓通知指的就是指拦截到连接点之后要执行的代码，通知分为前置、后置、异常、最终、环绕通知五类。 * 目标对象：代理的目标对象 * 织入(weave): 将切面应用到目标对象并导致代理对象创建的过程 * 引入(introduction): 在不修改代码的前提下，引入可以在运行期为类动态地添加方法或字段 ### AOP应用场景 [Section titled “AOP应用场景”](#aop应用场景) * 记录日志 * 监控性能 * 权限控制 * 事务管理 * 线程池关闭等 ### 注意事项 [Section titled “注意事项”](#注意事项) 从Spring5.2.x开始，Spring AOP不再严格按照AspectJ定义的规则来执行advice，而是根据其类型按照从高到低的优先级进行执行：@Around，@Before ，@After，@AfterReturning，@AfterThrowing 因为未指定顺序,所以比较切面类的字符串`str1.compareTo(str2)`。 所以在实际开发中,建议显式的指定好顺序 ### 最佳实践 [Section titled “最佳实践”](#最佳实践) [自定义注解实现限流](/software-engineer/best-practices/custom-annotations-to-limit-and-downgrade/) # IOC > IOC **IoC 是 Spring 框架的基石，是 Spring 框架众多特性的基础** 在 IoC(Inversion of Control)模式中，对象之间的依赖关系被反转了，即由开发人员手动控制对象之间的依赖关系变为由容器自动注入依赖。这种反转的控制使得应用程序的各个模块之间解耦，提高了代码的灵活性、可维护性和可测试性。 IoC 的实现依赖于一个称为 IoC 容器的组件。IoC 容器负责创建和管理对象，以及解决对象之间的依赖关系。开发人员只需在配置文件(如 XML 配置文件)或使用注解方式中指定对象的依赖关系和其他配置细节，容器就会根据这些配置信息动态地实例化对象、注入依赖并管理对象的生命周期。 ### IoC容器实现控制反转的方式 [Section titled “IoC容器实现控制反转的方式”](#ioc容器实现控制反转的方式) 1. 依赖注入(Dependency Injection，DI)：依赖注入是 IoC 的一种具体实现方式，通过将依赖关系注入到对象中，实现了对象之间的解耦。**容器负责查找依赖对象，并将其自动注入到相应的对象中**。依赖注入可以通过构造函数、Setter 方法或接口注入来完成。在 Spring 框架中，依赖注入通过注解或 XML 配置文件来实现。 2. 依赖查找(Dependency Lookup)：依赖查找是另一种 IoC 的实现方式，它通过容器提供的 API，开发人员手动查找和获取所需的依赖对象。开发人员在代码中通过容器提供的接口来获取所需的对象实例，从而实现了对象之间的解耦。在 Spring 框架中，依赖查找通过 ApplicationContext 接口的 getBean() 方法来实现。 ### DI实现的原理 [Section titled “DI实现的原理”](#di实现的原理) DI 的实现原理是通过**反射机制**实现的。在 Spring 框架中，当容器创建一个对象时，它会检查该对象的依赖关系，并使用反射机制查找依赖对象。然后，容器将依赖对象注入到该对象中。 具体来说，当使用 @Autowired 注释时，Spring 容器会自动查找与该类型匹配的 bean，并将其注入到该字段中。如果有多个匹配的 bean，则可以使用 @Qualifier 注释来指定要注入的 bean 的名称。 ### Spring IOC初始化流程 [Section titled “Spring IOC初始化流程”](#spring-ioc初始化流程) * resource**定位**: 即寻找用户定义的bean资源，由 ResourceLoader通过统一的接口Resource接口来完成 * beanDefinition**载入**: BeanDefinitionReader读取、解析Resource定位的资源成BeanDefinition 载入到ioc中(通过HashMap进行维护BD) * BeanDefinition**注册**: 即向IOC容器注册这些BeanDefinition， 通过BeanDefinitionRegistery实现  > 该图片来自互联网 ### Spring DI依赖注入流程(实例化，处理Bean之间的依赖关系) [Section titled “Spring DI依赖注入流程(实例化，处理Bean之间的依赖关系)”](#spring-di依赖注入流程实例化处理bean之间的依赖关系) #### 时机 [Section titled “时机”](#时机) 过程在Ioc初始化后，依赖注入的过程是用户第一次向IoC容器索要Bean时触发 #### 流程 [Section titled “流程”](#流程) * 如果设置lazy-init=true，会在第一次getBean的时候才初始化bean， lazy-init=false，会容器启动的时候直接初始化(singleton bean) * 调用BeanFactory.getBean() 生成bean的 * 生成bean过程运用装饰器模式产生的bean都是beanWrapper(bean的增强) #### 依赖注入怎么处理bean之间的依赖关系? [Section titled “依赖注入怎么处理bean之间的依赖关系?”](#依赖注入怎么处理bean之间的依赖关系) 其实就是通过在beanDefinition载入时，如果bean有依赖关系，通过**占位符**来代替，在调用getBean时候，如果遇到占位符，从ioc里获取bean注入到本实例来 ### @Autowired 和 @Resource 的区别 [Section titled “@Autowired 和 @Resource 的区别”](#autowired-和-resource-的区别) * @Autowired 是 Spring 定义的注解，而 @Resource 是 Java 定义的注解，它来自于 JSR-250(Java 250 规范提案)。 * @Autowired 是先根据类型(byType)查找，如果存在多个 Bean 再根据名称(byName)进行查找;@Resource 是先根据名称查找，如果(根据名称)查找不到，再根据类型进行查找 * 参数差异大。@Autowired 只支持设置一个 required 的参数，而 @Resource 支持 7 个参数(name,lookup,type,description等) * @Autowired 支持属性注入、 Setter 注入和**构造方法注入**，而 @Resource 只支持属性注入和 Setter 注入 # Spring Cloud > Spring Cloud ### Spring Cloud 实际用过哪些组件? [Section titled “Spring Cloud 实际用过哪些组件?”](#spring-cloud-实际用过哪些组件) * **服务注册中心 Euraka** * **声明式Http客户端 Feign** * **服务网关 Zuul** * 负载均衡 Ribbon * 熔断器 Hystrix ### Spring Cloud和Dubbo的区别 [Section titled “Spring Cloud和Dubbo的区别”](#spring-cloud和dubbo的区别) #### 主要区别 [Section titled “主要区别”](#主要区别) Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信; 而SpringCloud是基于Http协议+rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。 #### 定位区别 [Section titled “定位区别”](#定位区别) Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断;而Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。因此可以大胆地判断，Dubbo 未来会在服务治理方面更为出色，而 SpringCloud 在微服务治理上面无人能敌。 #### 模块区别 [Section titled “模块区别”](#模块区别) 1、Dubbo主要分为服务注册中心，服务提供者，服务消费者，还有管控中心； 2、相比起Dubbo简单的四个模块，SpringCloud则是一个完整的分布式一站式框架，他有着一样的服务注册中心，服务提供者，服务消费者，管控台，断路器，分布式配置服务，消息总线，以及服务追踪等； ### 常见有哪些注册中心 [Section titled “常见有哪些注册中心”](#常见有哪些注册中心)  ### 负载均衡怎么做? [Section titled “负载均衡怎么做?”](#负载均衡怎么做) Ribbon @LoadBalanced  > 该图片来自互联网 ### Hystrix原理 [Section titled “Hystrix原理”](#hystrix原理) Hystrix 是 Netflix 的一款开源的容错框架，通过服务隔离来避免由于依赖延迟、异常，引起资源耗尽导致系统不可用的解决方案 通过维护一个自己的线程池，当线程池达到阈值的时候，就启动服务降级，返回fallback默认值 **为什么需要hystrix熔断?** 防止雪崩，及时释放资源，防止系统发生更多的级联故障，需要对故障和延迟进行隔离，防止单个依赖关系的失败影响整个应用程序； ### Zuul与Gateway区别 [Section titled “Zuul与Gateway区别”](#zuul与gateway区别) * zuul则是netflix公司的项目集成在spring-cloud中使用而已， Gateway是spring-cloud的 一个子项目； * zuul不提供异步支持，流控等均由hystrix支持。 gateway提供了异步支持，提供了抽象负载均衡，提供了抽象流控； 理论上gateway则更适合于提高系统吞吐量(但不一定能有更好的性能)，最终性能还需要通过严密的压测来决定 * 两者底层实现都是servlet，但是gateway多嵌套了一层webflux框架 #### Zuul原理分析 [Section titled “Zuul原理分析”](#zuul原理分析) * 请求给zuulServlet处理(HttpServlet子类) zuulservlet中有一个zuulRunner对象，该对象中初始化了RequestContext(存储请求的数据)，RequestContext被所有的zuulfilter共享； * zuulRunner中有 FilterProcessor(zuulfilter的管理器)，其从filterloader 中获取zuulfilter； * 有了这些filter之后， zuulServelet执行的Pre-> route-> post 类型的过滤器，如果在执行这些过滤器有错误的时候则会执行error类型的过滤器，执行完后把结果返回给客户端. > 其实就是把请求拿到自己的处理器处理，不走默认的，这样可以新增很多功能 #### Gateway原理分析 [Section titled “Gateway原理分析”](#gateway原理分析) 请求到达DispatcherHandler， DispatchHandler在IOC容器初始化时会在容器中实例化HandlerMapping接口 用HandlerMapping根据请求URL匹配到对应的Route，然后有对应的filter做对应的请求转发最终response返回去 ### 微服务优缺点 [Section titled “微服务优缺点”](#微服务优缺点) * 每个服务高内聚，松耦合，面向接口编程 * 服务间通信成本，数据一致性，多服务运维难度增加，http传输效率不如rpc # Spring事务的实现原理 > Spring事务的实现原理 ### 事务的基本原理 [Section titled “事务的基本原理”](#事务的基本原理) Spring事务的本质就是数据库对事务的支持，如果数据库没有事务,那Spring的事务就无从说起 对于纯JDBC操作数据库，如果要用到事务，可以按照以下步骤进行: ```txt 1. 获取连接 Connection con = DriverManager.getConnection() 2. 开启事务con.setAutoCommit(true/false); 3. 执行CRUD 4. 提交事务/回滚事务 con.commit() / con.rollback(); 5. 关闭连接 conn.close(); ``` 使用Spring的事务管理功能后，我们可以不再写步骤 `2` 和 `4` 的代码，而是由Spring来完成。 ### Spring事务原理 [Section titled “Spring事务原理”](#spring事务原理) @Transactional基于Spring AOP实现 ### Spring事务管理方式 [Section titled “Spring事务管理方式”](#spring事务管理方式) * 编码式事务管理：将事务控制代码编写在业务代码之中。 * 声明式事务管理：基于AOP(面向切面编程)，事务管理与业务逻辑解耦。声明式事务管理的两种实现： * 在配置文件(xml)中配置 * 基于@Transactional注解 ### Spring的事务传播机制 [Section titled “Spring的事务传播机制”](#spring的事务传播机制) Spring事务的传播机制说的是，当多个事务同时存在的时候，Spring如何处理这些事务的行为。事务传播机制实际上是使用简单的ThreadLocal实现的，所以，如果调用的方法是在新线程调用的，事务传播实际上是会失效的。 1. **PROPAGATION\_REQUIRED**：（默认传播行为）如果当前没有事务，就创建一个新事务；如果当前存在事务，就加入该事务 2. **PROPAGATION\_REQUIRES\_NEW**：无论当前存不存在事务，都创建新事务进行执行 3. PROPAGATION\_SUPPORTS：如果当前存在事务，就加入该事务；如果当前不存在事务，就以非事务执行 4. PROPAGATION\_NOT\_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起 5. PROPAGATION\_NESTED：如果当前存在事务，则在嵌套事务内执行；如果当前没有事务，则按REQUIRED属性执行 6. PROPAGATION\_MANDATORY：如果当前存在事务，就加入该事务；如果当前不存在事务，就抛出异常 7. PROPAGATION\_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常 ### Spring中的隔离级别 [Section titled “Spring中的隔离级别”](#spring中的隔离级别) 1. ISOLATION\_DEFAULT：这是个 PlatfromTransactionManager 默认的隔离级别，使用数据库默认的事务隔离级别 2. ISOLATION\_READ\_UNCOMMITTED：读未提交，允许事务在执行过程中，读取其他事务未提交的数据 3. ISOLATION\_READ\_COMMITTED：读已提交，允许事务在执行过程中，读取其他事务已经提交的数据 4. ISOLATION\_REPEATABLE\_READ：可重复读，在同一个事务内，任意时刻的查询结果都是一致的 5. ISOLATION\_SERIALIZABLE：所有事务逐个依次执行 ### 在Spring中设置 [Section titled “在Spring中设置”](#在spring中设置) ```java @Transactional(propagation = Propagation.REQUIRES_NEW, isolation = Isolation.READ_UNCOMMITTED) ``` # Spring事务什么场景下会失效 > Spring事务什么场景下会失效 1. 访问权限问题。访问权限是private、default或protected的话，spring则不会提供事务功能。只有public方法才会提供事务 2. 方法用final修饰。 1. 如果你看过spring事务的源码，可能会知道spring事务底层使用了aop，也就是通过jdk动态代理或者cglib，帮我们生成了代理类，在代理类中实现的事务功能。但如果某个方法用final修饰了，那么在它的代理类中，就无法重写该方法，而添加事务功能。 2. 如果某个方法是static的，同样无法通过动态代理，变成事务方法 3. 方法内部调用。在普通方法A中，调用事务方法B，因为**这种方法直接调用了this对象的方法**(面试有被问到过\*2)，没有走spring代理 [分析及解决](#%E9%92%88%E5%AF%B9%E7%AC%AC3%E7%82%B9%E7%9A%84%E5%88%86%E6%9E%90%E5%8F%8A%E8%A7%A3%E5%86%B3) 4. 未被spring管理 5. 多线程调用 * 不在同一个线程中，获取到的数据库连接不一样，从而是两个不同的事务 * spring的事务是通过数据库连接来实现的。当前线程中保存了一个map，key是数据源，value是数据库连接 * 我们说的同一个事务，其实是指同一个数据库连接，只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。 6. 表不支持事务 7. 未开启事务 8. 错误的传播特性 9. 自己吞了异常 10. 手动抛了别的异常 11. 自定义了回滚异常 12. 嵌套事务回滚多了 13. 大事务问题。解决方案可以使用TransactionTemplate编程式事务 #### 针对第3点的分析及解决 [Section titled “针对第3点的分析及解决”](#针对第3点的分析及解决) Spring默认的是PROPAGATION\_REQUIRED机制,如果方法A标注了注解@Transactional 是完全没问题的,执行的时候传播给方法B,因为方法A开启了事务,线程内的connection的属性autoCommit=false,并且执行到方法B时,事务传播依然是生效的,得到的还是方法A的connection,autoCommit还是为false,所以事务生效;反之,如果方法A没有注解@Transactional 时,是不受事务管理的,autoCommit=true,那么传播给方法B的也为true,执行完自动提交,即使B标注了@Transactional。 Spring在扫描bean的时候会扫描方法上是否包含@Transactional注解，如果包含，spring会为这个bean动态地生成一个子类（即代理类，proxy），代理类是继承原来那个bean的。此时，当这个有注解的方法被调用的时候，实际上是由代理类来调用的，代理类在调用之前就会启动transaction。然而，如果这个有注解的方法是被同一个类中的其他方法调用的，那么该方法的调用并没有通过代理类，而是直接通过原来的那个bean，所以就不会启动transaction，我们看到的现象就是@Transactional注解无效。 ##### 具体解决 [Section titled “具体解决”](#具体解决) 就是根据分析的原因来具体解决 1. 把方法B抽离到另外一个ServiceC中去,并且在这个Service中注入ServiceC,使用ServiceC调用方法B 2. 通过在方法内部获得当前类代理对象的方式,通过代理对象调用方法B 1. 使用 ApplicationContext 上下文对象获取该对象 2. 使用 AopContext.currentProxy() 获取代理对象,但是需要配置exposeProxy=true。 ```sh @EnableAspectJAutoProxy(exposeProxy = true) ``` # Git > git 提示 分享自己在开发中最常用的几个git命令 ##### 完全回滚当前项目的所有改动 [Section titled “完全回滚当前项目的所有改动”](#完全回滚当前项目的所有改动) ```sh git reset --hard HEAD ``` ##### 重置到某一次提交 [Section titled “重置到某一次提交”](#重置到某一次提交) ```sh # 退到/进到 指定commit的sha码 git reset --hard # 强推到远程 git push origin HEAD --force ``` ##### 将本地分支与远程分支解绑 [Section titled “将本地分支与远程分支解绑”](#将本地分支与远程分支解绑) ```sh git branch --unset-upstream ``` ##### 修改.gitignore使之生效 [Section titled “修改.gitignore使之生效”](#修改gitignore使之生效) ```sh # 清楚tracked缓存 git rm -r --cached . # 重新添加文件 git add . ``` ##### 获取一个目录下的所有git项目的当前分支名和项目名 [Section titled “获取一个目录下的所有git项目的当前分支名和项目名”](#获取一个目录下的所有git项目的当前分支名和项目名) ```sh #!/bin/bash dir_path=`pwd` filelist=`ls $dir_path` for file in $filelist do # 检查目录和git目录是否存在 if [[ -d $file ]] && [[ -d $dir_path/$file/.git ]]; then branch=`cat $dir_path/$file/.git/HEAD` # 分支名 sub_branch=${branch: 16} # 打印 echo "$sub_branch $file" fi done ``` ##### 一个文件夹下的所有项目都创建相同的分支 [Section titled “一个文件夹下的所有项目都创建相同的分支”](#一个文件夹下的所有项目都创建相同的分支) ```sh #!/bin/bash dir_path=`pwd` filelist=`ls $dir_path` for file in $filelist do # 检查目录和git目录是否存在 if [[ -d $file ]] && [[ -d $dir_path/$file/.git ]]; then # 每行要加分号 ";" ,一开始没有加分号,就报错 cd $dir_path/$file; git checkout -b 你的分支名; cd $dir_path; fi done ``` ##### 将当前仓库的所有变动提交到仓库 [Section titled “将当前仓库的所有变动提交到仓库”](#将当前仓库的所有变动提交到仓库) ```sh #!/bin/bash # 拉取最新代码到本地仓库 echo "=========>>>拉取最新代码到本地仓库,开始fetch操作" git fetch echo "=========>>>fetch 成功" # 检查本地分支是否落后于远程分支,如果是,则先合并远程分支 if [ -n "$(git status -uno | grep 'Your branch is behind')" ]; then echo "=========>>>本地分支落后于远程分支,先合并远程分支" git pull echo "=========>>>合并远程分支完成" fi # 获取当前分支 branch=$(git rev-parse --abbrev-ref HEAD) # 检查是否存在未推送的本地 commit,如果有则先执行推送操作 if [ -n "$(git log origin/${branch}..HEAD --oneline)" ]; then echo "=========>>>存在未推送的本地 commit,先执行推送操作" git push echo "=========>>>push 完成" fi # 检查是否存在未提交的修改 if [ -z "$(git status --porcelain)" ]; then echo "=========>>>当前仓库没有未提交的修改,很干净" exit 1 fi timeValue=0 # 获取提交注释 if [ -z "$1" ] then echo "=========>>>请在 $timeValue s内输入提交注释,否则使用默认提交信息进行提交 | 快捷操作:直接回车:" read -t $timeValue message # echo "=========>>>请在输入提交注释 | 如需默认提交信息,请按回车键 " # read message if [ -z "$message" ] then # echo "必须输入提交注释!!!!!!!!!!!!" # exit 1 timestamp=$(date +%s) message="moatkon.com commit $timestamp" fi else message="$1" fi # 添加所有修改到 Git git add . # 提交修改 git commit -m "$message" --no-verify # 输出提交信息 echo "=========>>>提交注释: $message" # 推送代码到远程 Git 仓库 git push # 输出推送信息 echo "=========>>>已将代码推送到远程仓库" ``` ##### 使用命令将分支合并到指定分支,比如main [Section titled “使用命令将分支合并到指定分支,比如main”](#使用命令将分支合并到指定分支比如main) 1. 确保你在当前分支，并且已经提交了所有的更改： ```bash git status git add . git commit -m "Your commit message" ``` 2. 切换到 main 分支： ```bash git checkout main ``` 3. 更新 main 分支到最新状态： ```bash git pull origin main ``` 4. 合并当前分支到 main 分支： ```bash git merge <当前分支的名称> ``` > 从远程分支就是 git merge origin <当前分支的名称> 5. 如果合并过程中没有冲突，推送合并后的 main 分支到远程仓库： ```bash git push origin main ``` ##### 查看当前修改的地方 [Section titled “查看当前修改的地方”](#查看当前修改的地方) ```sh git diff ``` 如果要查看特定的commit id的变动,则使用 ```sh git show ``` ##### Git branch相关操作 [Section titled “Git branch相关操作”](#git-branch相关操作) ```sh git branch # 创建分支 git branch -b # 创建分支并切换到新分支 git checkout -b 分支名 origin/分支名 #直接 checkout 并跟踪远程分支 git fetch origin # 拉远处分支到本地,这样在本地就可以看到 git fetch # 我一般用这个 # 删除分支,删除分支前要先切换到其他分支,不然删除不了 git branch -d # 安全删除 git branch -D # 强制删除 git push origin HEAD # 在远程创建一个新分支,很你的本地分支一样 git branch -a #查看所有分支（本地 + 远程） git branch -r #只看远程分支 ``` #### Git代理设置 [Section titled “Git代理设置”](#git代理设置) ```bash git config --global http.https://github.com.proxy socks5://127.0.0.1:33211 ``` #### Git长路径支持 [Section titled “Git长路径支持”](#git长路径支持) ```bash git config --system core.longpaths true ``` #### Github access token 配置 [Section titled “Github access token 配置”](#github-access-token-配置) ```bash https://:@github.com//.git ``` 自己常用命令: :@github.com/moatkon/moatkon.git # Git分支管理 > Git分支管理 ### Git分支最佳实践 [Section titled “Git分支最佳实践”](#git分支最佳实践)  该分支管理是自己目前实践过程中相对比较成熟和稳定的分支管理方案 #### 优点 [Section titled “优点”](#优点) * 多需求并行 * 无需多套环境 * SDK版本管理无冲突 * 当前feature功能受其他feature监督,可以及时发现问题,推动相关feature分支方案调整 * 整体部署成本低 #### 缺点 [Section titled “缺点”](#缺点) * 如果dev、test或者pre分支被删除,已经合并进去的feature分支需要重新合并。*实际上,出现上述分支被删除的情况非常好,几乎不会发生.但是不排除,研发人员误操作等特殊情况,可以忽略* * 因为是先merge into main,如果有Bug需要回滚等操作,只能提交bugfix,不能将整体的feature code回滚 ### 历史采用的分支管理 [Section titled “历史采用的分支管理”](#历史采用的分支管理)  **优点:** * 环境物理隔离 * feature不受其他feature影响 * 因为是后merge into main,如果有Bug无回滚操作,可以在已有的release分支上fix bug **缺点:** * 环境物理隔离 * feature不受其他feature影响,在生产环境可能会导致Bug * 部署成本高 * SDK版本冲突严重,因为相互独立。经常发生在上线阶段临时升级版本号的情况 * 每次部署只能测试一个feature # JVM > JVM ## JVM内存结构 [Section titled “JVM内存结构”](#jvm内存结构)  #### a. 程序计数器 [Section titled “a. 程序计数器”](#a-程序计数器) 程序运行前，JVM会将程序编译后的字节码加载到内存中；程序运行时，字节码解析器会读取内存中的字节码，按照顺序将字节码的指令解析成固定的操作。在这过程中，程序计数器(Program Counter Register)保存当前线程正在执行的字节码地址。 从字节码运行的原理来看，单线程模型下的程序计数器貌似可有可无，字节码解析器会按照顺序将字节码翻译成固定操作，即使遇到分支跳转，也无碍程序正确运行下去。然而，现实中的程序往往是通过多线程协作来完成一个任务的，CPU会为每个线程分配一定的时间片，一个线程在其时间片耗尽之后会挂起，直到它再次获得时间片后才会重新运行。为了确保程序正确运行，线程必须从挂起的地方重新执行。有了程序计数器，就可以保证在涉及线程上下文切换的情景下，程序依然能够正确无误地运行下去。 程序计数器其他需要注意的地方 1. 如果一个线程执行的是native本地方法，它的程序计数器的值为undefined。因为JVM在执行native本地方法时，是通过JNI调用本地的其他语言来实现的，而非字节码。 2. JVM会为每个线程都分配一块非常小的内存空间用作程序计数器，这也是唯一一个Java虚拟机规范没有规定OutOfMemoryError的运行时区域。 #### b. Java 虚拟机栈 [Section titled “b. Java 虚拟机栈”](#b-java-虚拟机栈) JVM会给每个线程都分配一个私有的内存空间，称为Java虚拟机栈。 JVM只会对其执行两种操作：栈帧(Stack Frame)的入栈和出栈。也就是说，Java虚拟机栈是存储栈帧的后进先出队列(LIFO)。 栈帧是用来存储局部数据和部分过程结果的数据结构，主要包含 局部变量表(Local Variable Table)、操作数栈(Operand Stack)、指向当前方法所属类的运行时常量池的引用(Runtime Constant Pool Reference) #### c. 本地方法栈 [Section titled “c. 本地方法栈”](#c-本地方法栈) 本地方法栈则为native方法服务的 #### d. 方法区 [Section titled “d. 方法区”](#d-方法区) 方法区(Method Area)是线程间共享的区域，在JVM启动时创建，用于存储类的元信息、静态变量、常量、普通方法的字节码等内容。方法区可以被实现成大小固定或可动态扩展和收缩，如果内存空间不满足内存分配要求就会抛出OutOfMemoryError异常。 元空间 对于HotSpot虚拟机而言，在JDK 1.8以前，方法区被实现为“永久代”(Permanent Generation)，属于堆的逻辑组成部分，并提供了两个参数调节其大小，`-XX:PermSize` 用于设定初始容量，`-XX:MaxPermSize` 用于设定最大容量。JDK 1.8之后，HotSpot不再有“永久代”的概念，类的元信息数据迁移到被称为“元空间”(Metaspace)的新区域，而静态变量、常量等则存储于堆中。**元空间没有使用堆内存，而是分配在本地内存中，默认情况下其容量只受可用的本地内存大小限制**。类似地，HotShot虚拟机也提供了两个参数来调节其大小，`-XX:MetaspaceSize` 用于设定初始容量，`-XX:MaxMetaspaceSize` 用于设定最大容量。 ##### 方法区和永久代的区别 [Section titled “方法区和永久代的区别”](#方法区和永久代的区别) 方法区是《Java虚拟机规范》中定义的内存区域，用于存储类的结构信息(如类的字节码、常量池、字段和方法信息等) 而 Java 默认虚拟机 HotSpot 中，在 JDK 1.8 之前的版本中，是通过永久代来实现方法区的，但 JDK 1.8 之后，永久代被元空间(Metaspace)取代 所以,区别是 方法区是规范，而永久代(和元空间)是具体实现 ##### 运行时常量池(Runtime Constant Pool) [Section titled “运行时常量池(Runtime Constant Pool)”](#运行时常量池runtime-constant-pool) 运行时常量池(Runtime Constant Pool)属于方法区的一部分，class文件被加载到内存后，其中的常量池信息(包括符号引用和编译期可知的字面值常量)就被存储于此。 #### e. 堆 [Section titled “e. 堆”](#e-堆) Java堆是java虚拟机所管理内存中最大的一块内存空间，处于物理上不连续的内存空间，只要逻辑连续即可，主要用于存放各种类的实例对象。该区域被所有线程共享，在虚拟机启动时创建，用来存放对象的实例，几乎所有的对象以及数组都在这里分配内存(栈上分配、标量替换优化技术的例外)。 ##### 堆布局 [Section titled “堆布局”](#堆布局)  JVM将堆划分成这么多的区域，主要是为了方便垃圾收集器对对象进行管理，现代的垃圾收集器一般都采用了分代收集算法。 对于HotSpot而言，新生代的回收被称为Minor GC，老年代的回收称为Major GC，而同时对新生代、老年代和方法区的回收则称为Full GC。如果出现Full GC的频率过高，就说明目前堆内存已经不太够用了。 ##### 新生代(Young/New Generation) [Section titled “新生代(Young/New Generation)”](#新生代youngnew-generation) 1. 大多数新建的对象都位于Eden区。 2. 年轻代通过Minor GC进行回收，垃圾收集器会将Eden区域和S0区域中存活的对象复制到S1区域中，然后将前两个区域清空。当下次回收的时机到来时，则将Eden区域和S1区域中存活的对象复制到S0区域上，然后将前两个区域清空，依次交替进行。 3. 如果位于新生代中的对象经过几轮(模式是15岁)垃圾回收都存活了下来，JVM就会将这些对象转存到老年代中。通常这是在年轻代有资格提升到年老代前通过**设定年龄阈值**来完成的。(年龄阈值可以通过参数`-XX:MaxTenuringThreshold`来设置) > * 新生代上都是些 “小” 对象，而且存活率低，进而复制成本较低，因此通常采用**复制算法**进行垃圾回收 > * 一些 “大” 对象创建时，如果新生代没有足够的空闲内存，JVM也会在老年代中为其分配内存。(当对象过大时或特别大时，因为占用幸存者区空间过大或大于幸存者区，而造成反复GC，重复复制大对象增加GC时间问题,JVM在这方面有专门的优化,就是**大对象直接进入老年代**，使用JVM参数`-XX:PretenureSizeThreshold`(单位为字节)设置大对象的大小，如果对象超过设置的大小会直接进入老年代，防止大对象进入年轻代造成重复GC) **年轻代回收过程**  ##### 老年代 ( Old Generation) [Section titled “老年代 ( Old Generation)”](#老年代--old--generation) 什么样的对象可以进入老年代？ * Minor GC后S区容纳不下的对象 * 长期存活的对象 * 大对象。需要连续大量内存空间的Java对象 * 动态对象进行年龄判定进入老年代 > 老年代中的对象通常都是些生命周期较长或者占用空间较大的对象，其复制成本较大，因而垃圾收集器通常采用**标记-清除算法**进行垃圾回收 **老年代回收过程**  ##### 堆为什么这样划分？ [Section titled “堆为什么这样划分？”](#堆为什么这样划分) 1. 为了使jvm能够更好的管理内存中的对象，包括内存的分配以及回收 2. 新生代按eden和两个survivor的分法的优点有以下几个好处: 1. 有效空间增大，eden+1个survivor 2. 两个Survivor区可解决内存碎片化 3. 利于对象代的计算。当一个对象在S0/S1中达到设置的`XX:MaxTenuringThreshold`值后，会将其挪到老年代中，即只需扫描其中一个survivor。如果没有S0/S1,直接分成两个区，就没法计算对象经过了多少次GC还没被释放。 ## 堆(Heap)和JVM栈是程序运行的关键 [Section titled “堆(Heap)和JVM栈是程序运行的关键”](#堆heap和jvm栈是程序运行的关键) * 堆存储的是对象。 * 栈存储的是基本数据类型和堆中对象的引用(参数传递的值传递和引用传递) * 栈是【运行时】的单位(解决程序的运行问题，即程序如何执行，或者说如何处理数据)。 * 堆是【存储】的单位(解决的是数据存储的问题，即数据怎么放、放在哪儿) ##### 那为什么要把堆和栈区分出来呢？栈中不是也可以存储数据吗？ [Section titled “那为什么要把堆和栈区分出来呢？栈中不是也可以存储数据吗？”](#那为什么要把堆和栈区分出来呢栈中不是也可以存储数据吗) * 从软件设计的角度看，栈代表了处理逻辑，而堆代表了数据，分工明确，处理逻辑更为清晰体现了“分而治之”以及“隔离”的思想。 * 堆与栈的分离，使得堆中的内容可以被多个栈共享(也可以理解为多个线程访问同一个对象)。 这样共享的方式有很多收益：提供了一种有效的数据交互方式(如：共享内存)；堆中的共享常量和缓存可以被所有栈访问，节省了空间。 * 栈因为运行时的需要，比如保存系统运行的上下文，需要进行地址段的划分。由于栈只能向上增长，因此就会限制住栈存储内容的能力。而堆不同，堆中的对象是可以根据需要动态增长的，因此栈和堆的拆分，使得动态增长成为可能，相应栈中只需记录堆中的一个地址即可。 * 堆和栈的结合完美体现了面向对象的设计。当我们将对象拆开，你会发现，对象的属性即是数据，存放在堆中；而对象的行为(方法)即是运行逻辑，放在栈中。因此编写对象的时候，其实既编写了数据结构，也编写的处理数据的逻辑。 ## 堆栈相关参数 [Section titled “堆栈相关参数”](#堆栈相关参数) ##### 核心参数 [Section titled “核心参数”](#核心参数) * `-Xms` 堆内存初始大小，单位m、g * `-Xmx` 堆内存最大允许大小，一般不要大于物理内存的80% * `-Xmn` 年轻代内存初始大小 * `-Xss` 每个线程的堆栈大小，即JVM栈的大小 > -Xms 和 -Xmx 一般设置相等 ##### 设置参数的技巧 [Section titled “设置参数的技巧”](#设置参数的技巧) 1. 每次GC 后会调整堆的大小，【为了防止动态调整带来的性能损耗】，一般设置`-Xms`、`-Xmx` 相等 2. 推荐使用的是`-Xmn`参数，原因是这个参数很简洁，相当于一次性设定 `NewSize` 和 `MaxNewSize` ，而且两者相等 ## JVM对象 [Section titled “JVM对象”](#jvm对象) ##### 创建对象的方式 [Section titled “创建对象的方式”](#创建对象的方式) 1. 使用new关键字。调用无参或有参构造器函数创建 2. 使用Class的newInstance方法。调用无参或有参构造器函数创建，且需要是public的构造函数 3. 使用Constructor类的newInstance方法。调用有参和私有private构造器函数创建，实用性更广。可以调用私有的构造器是因为 Java 中的反射机制允许你访问和操作对象的私有成员，包括私有构造器 4. 使用Clone方法。不调用任何参构造器函数，且对象需要实现Cloneable接口并实现其定义的clone方法，且默认为浅复制 5. 第三方库Objenesis。利用了asm字节码技术，动态生成Constructor对象 ##### JVM对象分配 [Section titled “JVM对象分配”](#jvm对象分配) ###### 在虚拟机层面上创建对象的步骤 [Section titled “在虚拟机层面上创建对象的步骤”](#在虚拟机层面上创建对象的步骤)  ##### 对象分配内存的策略 [Section titled “对象分配内存的策略”](#对象分配内存的策略) 1. **空闲链表** 空闲列表是一种通用的内存分配策略，适用于堆内存中有不同大小的对象。 在这种策略中，堆内存被划分为多个内存块，每个内存块可以容纳不同大小的对象。 一个空闲列表维护了可用内存块的列表，分配器会在列表中查找合适大小的内存块来分配对象。 分配对象后，相应的内存块将从列表中移除，当对象不再使用时，内存块会返回到空闲列表。 空闲列表允许更灵活地管理内存，但可能需要更多的内存管理开销(因为需要维护一个列表)。 2. **指针碰撞** 这是一种内存分配策略，通常用于具有**固定大小**的堆内存区域，例如在使用”标记-清除”或”复制”垃圾回收算法时。 在指针碰撞中，**堆内存被看作是一个连续的内存块**，分配新对象时，分配器会维护一个指针，指向当前可用内存的位置。 当分配对象时，分配器会将指针向前移动到下一个可用内存块的位置，并返回对象的引用。 这种方法非常高效，但**要求堆内存必须是连续的，而且不适用于可变大小的对象**。 ## 如何判断一个对象是否存活 [Section titled “如何判断一个对象是否存活”](#如何判断一个对象是否存活) #### 引用计数 和 可达性分析 [Section titled “引用计数 和 可达性分析”](#引用计数-和-可达性分析) **引用计数法**：引用计数法是一种最简单的垃圾回收算法，其中每个对象都有一个与之关联的引用计数器。每当有一个引用指向对象时，计数器加1，引用失效时减1。当计数器为0时，对象被认为是垃圾。这个方法容易理解，但无法处理循环引用的情况，因此在Java中不常用。 **可达性分析算法**：可达性分析是Java主要采用的垃圾回收算法。它从一组称为”GC Roots”(通常是栈、静态变量、方法区中的类引用等)出发，通过一系列引用链追踪对象的可达性。如果一个对象无法从GC Roots访问到，它被认为是不可达的，即可被垃圾回收。这个算法能够处理循环引用和复杂的对象引用关系。 #### 什么对象可以被GC Root [Section titled “什么对象可以被GC Root”](#什么对象可以被gc-root) * 虚拟机栈中的引用对象：函数内的局部变量、参数、异常处理器等 * 方法区中的类静态属性引用的对象 * 方法区中的常量引用的对象 * 本地方法栈中JNI(Java Native Interface)引用的对象 #### 被判定为不可达对象后,会立即被判定为死亡吗? [Section titled “被判定为不可达对象后,会立即被判定为死亡吗?”](#被判定为不可达对象后会立即被判定为死亡吗) **不会立即被判定为死亡。而是在“缓刑”阶段。** 不可达对象**要经过至少2次标记过程**,才能宣告死亡: 1. 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被**第一次标记** 2. 随后进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法 1. 假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“没有必要执行”。直接死亡 2. 如果这个对象被判定为有必要执行finalize()方法，那么该对象将会被放置在一个名为`F-Queue`的队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去**执行**它们的finalize()方法。 —— 收集器将对`F-Queue`中的对象进行**第二次标记** > **“执行”** 是指虚拟机会触发这个方法开始运行，但并不承诺一定会等待它运行结束。这样做是因为，如果某个对象finalize()方法执行缓慢，或者更极端地发生了死循环，将很可能导致`F-Queue`队列中的其他对象永久处于等待，卡死在这里。甚至导致整个内存回收子系统的崩溃。 **在标记过程中,如果重新与引用链上的任何一个对象建立关联,即可复活** ## 触发GC的场景 [Section titled “触发GC的场景”](#触发gc的场景) ### 触发FullGC的原因 [Section titled “触发FullGC的原因”](#触发fullgc的原因) Full GC(Full Garbage Collection)是指对整个堆内存进行垃圾回收的过程。在进行 Full GC 时，会对年轻代和老年代(以及永久代或元数据区)中的所有对象进行回收。 * 显式调用`system.gc()` * 老年代空间不足 * 永久代(方法区)空间不足 * 通过Minor GC后进入老年代的平均大小大于老年代的可用内存 * JVM自身固定评率的Full GC * 堆内存中分配的很大的对象以致超过了老年代剩余的空间,此时会触发Full GC ### 触发Young GC的原因 [Section titled “触发Young GC的原因”](#触发young-gc的原因) * Eden空间不足 * Full GC ## JVM三种类加载器 ⭐️ [Section titled “JVM三种类加载器 ⭐️”](#jvm三种类加载器-️) 1. 启动类加载器(Bootstrap Class Loader)：这是JVM的内置类加载器，负责加载Java核心类库，如java.lang包中的类。它通常由JVM的实现提供，不会被Java应用程序直接引用。 2. 扩展类加载器(Extension Class Loader)：扩展类加载器负责加载Java平台的扩展库，位于JRE的lib/ext目录下。开发人员可以通过系统属性来扩展这个类加载器的搜索路径。它是启动类加载器的子类加载器。 3. 应用程序类加载器(Application Class Loader)：也称为系统类加载器，它负责加载应用程序中的类。这是大多数Java应用程序默认使用的类加载器，它会搜索CLASSPATH中指定的路径来加载类。它是扩展类加载器的子类加载器。 4. 除了这三种主要的类加载器，还可以通过编写自定义的类加载器来实现特定的类加载需求，例如从网络或非标准位置加载类。这些自定义类加载器必须继承自java.lang.ClassLoader类，并实现自己的类加载逻辑。类加载器在Java中起到了关键的作用，它们帮助实现了类的动态加载和隔离，使得Java应用程序更加灵活和安全。  #### 双亲委派机制工作流程 [Section titled “双亲委派机制工作流程”](#双亲委派机制工作流程) 1. 首先，应用程序类加载器尝试加载类。 2. 如果应用程序类加载器无法找到类，它会将请求委派给其父类加载器，即扩展类加载器。 3. 扩展类加载器再次尝试加载类，如果仍然找不到，它会将请求委派给启动类加载器。 4. 启动类加载器在自己的类路径中查找类，如果找到了，加载成功。 5. 如果启动类加载器也找不到该类，会抛出ClassNotFoundException。 ### Java类是如何被加载的 [Section titled “Java类是如何被加载的”](#java类是如何被加载的)  1. 加载(Loading)：类加载的第一步是加载类的字节码文件。这发生在类加载器查找类文件并将其读取到内存中的阶段。这个阶段不会执行类中的静态代码块或初始化变量 2. 验证(Verification)：在这一步，类加载器会验证加载的字节码文件是否符合Java虚拟机规范，以确保它是安全和合法的。(文件格式验证，元数据验证，字节码验证，符号引用验证) 3. 准备(Preparation)：在准备阶段,为类的静态变量分配内存并初始化为默认值(例如，**数值类型初始化为0，引用类型初始化为null**),不包括实例变量，实例变量将会在对象实例化的时候随着对象一起分配在Java堆中 4. 解析(Resolution)：在这一步，符号引用被替换为直接引用。这包括将类、方法和字段的引用解析为实际的内存地址 * 符号引用：字符串，能根据这个字符串定位到指定的数据，比如java/lang/StringBuilder * 直接引用：内存地址 5. 初始化(Initialization)：这是类加载的最后一步，也是最重要的一步。在这个阶段，类的静态初始化代码块(static代码块)会被执行，静态变量会被赋予初始值。初始化只会执行一次，确保在多线程环境下也只有一个线程执行初始化。 ###### 总结,上面可以步骤可以分为3大步骤: [Section titled “总结,上面可以步骤可以分为3大步骤:”](#总结上面可以步骤可以分为3大步骤) 1. 加载： 查找并加载类的二进制数据。 2. 链接： 将 Java 类的二进制数据合并到 JVM 运行状态之中。 1. 验证：验证加载的类是否符合 Java 虚拟机规范。 2. 准备：为类的静态变量分配内存，并设置默认初始值。 3. 解析：将类中的符号引用转换为直接引用。 3. 初始化： 执行类的初始化代码，包括静态变量赋值和静态代码块的执行。 ### 双亲委派机制 [Section titled “双亲委派机制”](#双亲委派机制) #### 双亲委派机制作用 [Section titled “双亲委派机制作用”](#双亲委派机制作用) 双亲委派机制(Parent Delegation Model)是Java类加载器的一种工作机制，用于保证类的加载和安全性。它的核心思想是父类加载器委派给子类加载器加载类，确保类的一致性和防止恶意类的加载。 这个机制的好处在于确保类加载的一致性，避免了同一个类被不同的类加载器多次加载，从而防止类的冲突和安全问题。它还有助于隔离不同类加载器加载的类，确保类加载器之间的互相影响最小化。这在Java的类加载和安全性方面发挥了重要作用。 #### 双亲委派机制缺陷? `ChatGPT` [Section titled “双亲委派机制缺陷? ChatGPT”](#双亲委派机制缺陷-chatgpt) * 限制类加载器的灵活性：双亲委派机制对于自定义类加载器的灵活性有一定限制。有些应用场景可能需要自定义类加载器以实现特定的加载需求，但双亲委派机制可能阻碍了这一自由度。 * 无法实现类加载的隔离：尽管双亲委派机制可以确保类加载器之间的类不会冲突，但在某些情况下，应用程序可能需要加载相同名称的类的多个版本。这是一种类加载隔离的需求，双亲委派机制无法轻松满足。 * 不适合模块化系统：在模块化系统中，例如Java 9引入的模块系统，双亲委派机制可能显得过于复杂。模块系统本身提供了更精细的类加载和依赖管理机制，与传统的双亲委派机制不太兼容。 * 破坏了动态类加载的一致性：在某些动态代码生成和加载类的场景中，双亲委派机制可能不太适用。动态生成的类可能不符合双亲委派机制的预期工作流程。 * 性能开销：双亲委派机制在类加载时需要进行一系列的委派和检查操作，这可能导致一些性能开销。对于某些需要高性能的应用程序，这可能会成为一个问题。 > 虽然双亲委派机制有上述缺陷，但它在大多数标准Java应用程序中仍然是一种有效的安全和类加载机制。然而，在某些特殊情况下，开发人员可能需要绕过双亲委派机制，使用自定义类加载器来满足特定需求。这需要开发人员谨慎考虑并了解潜在的安全和一致性风险。 #### 如何打破双亲委派模型？ [Section titled “如何打破双亲委派模型？”](#如何打破双亲委派模型) 1. 自定义类加载器，继承ClassLoader类重写loadClass方法； 2. SPI(Service Provider interface) 1. 服务提供接口(服务发现机制) 2. 通过加载ClassPath下META\_INF/services，自动加载文件里所定义的类 3. 通过ServiceLoader.load/Service.providers方法通过反射拿到实现类的实例 **SPI应用**: * JDBC获取数据库驱动连接过程就是应用这一机制,使用SPI server provider模式的JDBC JAXP都是破坏了双亲委托模式的，在核心类库rt.jar的加载过程中需要加载第三方厂商的类，直接指定使用线程上下文类加载器也就是应用程序类加载器来加载这些类 * apache最早提供的common-logging只有接口.没有实现..发现日志的提供商通过SPI来具体找到日志提供商实现类 * Tomcat中的web 容器类加载器也是破坏了双亲委托模式的，自定义的WebApplicationClassLoader除了核心类库外，都是优先加载自己路径下的Class； 总结: 在重写loadclass的过程中，**只要不遵从JVM的规范就行了，不盲目的优先向Parent 的ClassLoader进行查找就行了** #### Tomcat是如何打破双亲委派模型？ [Section titled “Tomcat是如何打破双亲委派模型？”](#tomcat是如何打破双亲委派模型) Tomcat有着特殊性，它需要容纳多个应用，需要做到应用级别的隔离，而且需要减少重复性加载，所以划分为： ```shell /common 容器和应用共享的类信息 /server 容器本身的类信息 /share 应用通用的类信息 /WEB-INF/lib 应用级别的类信息 ``` 整体可以分为：`BoostrapClassLoader->ExtensionClassLoader->ApplicationClassLoader->CommonClassLoader->CatalinaClassLoader(容器本身的加载器)/ShareClassLoader(共享的)->WebAppClassLoader`。 虽然第一眼是满足双亲委派模型的，但是不是的，因为双亲委派模型是要先提交给父类装载，**而Tomcat是优先判断是否是自己负责的文件位置，进行加载的**。 打破双亲委派模型：虽然Tomcat的Web应用程序类加载器遵循一定的委派机制，但它可以被配置为不完全遵循双亲委派模型。通过配置元素的delegate属性，可以控制类加载器是否首先尝试从父类加载器加载类。 ## JVM运行流程 [Section titled “JVM运行流程”](#jvm运行流程) 1. 程序在执行之前先要把 Java 代码转换成字节码(class 文件)，JVM 首先需要把字节码通过一定的方式**类加载器(ClassLoader) 把文件加载到内存中运行时数据区(Runtime Data Area)** 2. 字节码文件是 JVM 的一套指令集规范，并不能直接交个底层操作系统去执行，因此需要特定的命令解析器，也就是 JVM 的**执行引擎(Execution Engine)会将字节码翻译成底层系统指令再交由 CPU 去执行；** 3. 在执行的过程中，也需要调用其他语言的接口，如通过**调用本地库接口(Native Interface)** 来实现整个程序的运行 # JVM垃圾回收算法 > 垃圾回收算法 > 2024.1.1 突然想到的 > > 今天下午洗碗的时候,发现我洗碗的方式和垃圾回收的算法**好像**啊! 我的洗碗步骤如下: > > 1. 将所有的碗移到一个水池A中 (共有2个池子且里面都有碗) (只移动) > 2. 把每一个碗上的食物使用清水清洗掉,放到另一个池子B中 —— 轻量级清洗 > 3. 将B池子中的每一个碗使用洗洁精清洗后放到A池中 —— 精洗,但这步还没有使用清水冲洗 > 4. 将A池中的每一个盘子用清水清洗干净 (清理) > 5. 等都用清水冲洗完之后,碗就清洗干净了,放到厨台上备用 (整理) ## 有哪些垃圾回收算法? [Section titled “有哪些垃圾回收算法?”](#有哪些垃圾回收算法) ### 标记-清除(Mark—Sweep) [Section titled “标记-清除(Mark—Sweep)”](#标记-清除marksweep) 被誉为现代垃圾回收算法的思想基础 标记-清除算法采用从根集合进行扫描，对存活的对象标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收。 标记-清除算法不需要进行对象的移动，并且仅对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片  ### 复制算法(Copying) [Section titled “复制算法(Copying)”](#复制算法copying) 该算法的提出是为了克服句柄的开销和**解决堆碎片**的垃圾回收。建立在存活对象少，垃圾对象多的前提下。 此算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去后还能进行相应的内存整理，不会出现碎片问题。但缺点也是很明显，就是需要两倍内存空间。  ### 标记-整理 [Section titled “标记-整理”](#标记-整理) > 又叫标记-压缩算法(Mark-Compact),又或者叫 标记清除压缩(MarkSweepCompact) 此算法是结合了“标记-清除”和“复制算法”两个算法的优点。避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。 标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。 **标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题**。 ### 分代回收策略(Generational Collecting) [Section titled “分代回收策略(Generational Collecting)”](#分代回收策略generational-collecting) **算法思路**:\ 基于这样的事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的回收算法，以便提高回收效率 **实际操作**:\ 新生代由于其对象存活时间短，且需要经常gc，因此采用效率较高的**复制算法** 老年代和永久代因为其存活对象时间长，因此使用**标记清除**或**标记整理算法** ## JVM常用的垃圾收集器 [Section titled “JVM常用的垃圾收集器”](#jvm常用的垃圾收集器) 1. Serial/Serial Old：单线程垃圾回收器 2. ParNew：多线程的垃圾回收器(Serial 的多线程版本) 3. Parallel Scavenge/Parallel Old：吞吐量优先的垃圾回收器 **JDK8 默认的垃圾回收器** 4. CMS：**最小等待时间**优先的垃圾收集器 5. G1：**可控垃圾回收时间**的垃圾收集器 **JDK 9 之后(HotSpot)默认的垃圾回收器** 6. ZGC：停顿时间超短(不超过 10ms)的情况下尽量提高垃圾回收吞吐量的垃圾收集器 **JDK 15 之后默认的垃圾回收器** Note * 串行垃圾收集器：`-XX:+UseSerialGC` * **并行垃圾收集器**：`-XX:+UseParallelGC` * CMS 垃圾收集器：`-XX:+UseConcMarkSweepGC` * **G1 垃圾收集器**：`-XX:+UseG1GC` > 有次面试有被问到有哪些垃圾回收器 ## ZGC [Section titled “ZGC”](#zgc) ZGC(Z Garbage Collector)是一种低延迟的垃圾回收器，是 JDK 11 引入的一项垃圾回收技术。**它主要针对大内存、多核心的应用场景，旨在减少垃圾回收带来的停顿时间** #### ZGC核心技术 [Section titled “ZGC核心技术”](#zgc核心技术) 1. 并发标记：ZGC 采用增量式并发标记算法来实现并发垃圾回收。它不会在标记阶段产生长时间停顿，可以与用户线程并发运行。 2. 粉碎压缩：ZGC 采用粉碎压缩算法来避免产生内存碎片。它会将内存按照特定大小(例如 2MB)分为多个区域，然后将存活对象连续放置在相邻区域，释放掉边界外的内存空间。这可以最大限度减少内存碎片。 3. 直接内存映射：ZGC 会直接映射内存空间，而不需要进行内存分配。这可以避免统计堆内存碎片情况所带来的性能消耗。 4. 微任务：ZGC 采用了微任务(Microtasks)机制来增量完成垃圾回收工作，从而不会产生长时间停顿。它会将总工作分割为多个微任务，这些微任务会在安全点(Safepoint)之间执行。 5. 可扩展的堆内存：ZGC 不需要指定最小堆(Xmn)和最大堆(Xmx)大小，它可以跟踪堆内存变化并根据需要动态调整堆空间大小。这使得 ZGC 可以支持将近 4TB 的堆内存。 6. 可插拔组件：ZGC 是一个独立的 GC 组件，它不依赖于 Gradle 等构建工具，可以与不同的工具或框架一起使用，这增强了其可移植性。 以上技术使ZGC达成毫秒级的停顿和大内存的支持 # JVM排除、解决 > JVM ### CPU占用过高 [Section titled “CPU占用过高”](#cpu占用过高) #### 排查方向 [Section titled “排查方向”](#排查方向) * 是否新上线了版本后增高的,若果是且影响主流程,应该立马回滚 * 收集不同的指标(CPU、内存、磁盘 IO、网络等等) * 分析应用日志 * 分析 GC 日志 * 获取线程转储并分析 * 获取堆转储来进行分析 #### 排查方法 [Section titled “排查方法”](#排查方法) 1. top命令: 查看系统内存、CPU使用率等 2. jstat: 查看Java进程的情况，包括堆栈信息跟垃圾回收信息 3. jstack: 可以查看线程的堆栈情况、是否死锁等 4. jmap: 通过jmap可以查看jvm各项配置及使用情况 `jmap -heap Pid` 5. `jmap -histo[:live] pid` 查看堆内存中的对象数目、大小统计直方图，如果带上 live 则只统计活对象。 6. `jmap -dump:format=b,file=file Pid`: 把堆内存的使用情况 dump 到文件中 > 看堆 使用jmap > > 看线程 使用jstack > > 监控 使用jstat > > 在系统层面,全局看,使用 top ### 频繁Full GC [Section titled “频繁Full GC”](#频繁full-gc) 堆内存不够就会频繁Full GC,排除重点就在是否有内存泄漏,导致无法回收和应用程序里存在大对象 ### 线上实际排查经历 [Section titled “线上实际排查经历”](#线上实际排查经历) [Spring Cloud Gateway内存泄漏排查 ](/software-engineer/topics/spring-cloud-gateway-direct-memory-leak)Spring Cloud Gateway内存泄漏排查 # Linux命令 > Linux命令 Note 自己平时为了解决一些问题,花了时间和精力特地去网上查找的会在这里记录,以期望后续节省时间 #### 希望把所有权改成当前用户 [Section titled “希望把所有权改成当前用户”](#希望把所有权改成当前用户) ```sh sudo chown -R $(whoami) /path/to/dir ``` #### 权限处理 [Section titled “权限处理”](#权限处理) 将指定目录的rwx权限赋值给当前用户 ```sh chmod u=rwx /path/to/directory ``` #### Crontab [Section titled “Crontab”](#crontab) ```sh */1 * * * * /home/moatkon/demo_bash.sh >> /home/moatkon/demo_bash.log 2>&1 ``` # 自动维护文件的lastUpdated时间 > 使用Shell脚本自动维护本站的lastUpdated时间 使用Shell脚本自动维护本站的lastUpdated时间: ```diff #!/bin/bash # 获取当前日期和时间，格式为：年-月-日 时:分:秒 current_datetime=$(date +"%Y-%m-%d %H:%M:%S") # 指定目录 docs_dir="./src/content/docs" # 确保指定的目录存在 if [ ! -d "$docs_dir" ]; then echo "错误：目录 $docs_dir 不存在" exit 1 fi # 获取已修改的文件列表 modified_files=$(git status --porcelain "$docs_dir" | grep '^ M' | awk '{print $2}' | grep -E '\.(md|mdx)$' ) +# 检查是否有修改的文件 +if [ -z "$modified_files" ]; then +echo "没有找到已修改的 *.md 或 *.mdx 文件" +exit 0 +fi # 遍历修改过的 .md 和 .mdx 文件 echo "$modified_files" | while read -r file do +# 检查文件是否存在 +if [ ! -f "$file" ]; then +echo "警告：文件 $file 不存在，跳过" +continue +fi # 检查文件是否为空 if [ ! -s "$file" ]; then # 文件为空，添加frontmatter和lastUpdated字段 echo "---" > "$file" echo "lastUpdated: $current_datetime" >> "$file" echo "---" >> "$file" echo "更新了空文件: $file 的lastUpdated时间" else # 检查文件是否有frontmatter if grep -q "^---" "$file"; then # 文件有frontmatter，使用 awk 直接修改文件 awk -v datetime="$current_datetime" ' BEGIN {in_frontmatter=0; updated=0} /^---$/ { if (in_frontmatter == 0) { in_frontmatter = 1 } else { if (updated == 0) { print "lastUpdated: " datetime } in_frontmatter = 0 } print next } in_frontmatter == 1 { if ($0 ~ /^lastUpdated:/) { print "lastUpdated: " datetime updated = 1 } else { print } next } {print} ' "$file" > "${file}.tmp" && mv "${file}.tmp" "$file" else # 文件没有frontmatter，添加一个 sed -i '' '1i\ ---\ lastUpdated: '"$current_datetime"'\ ---\ ' "$file" fi echo "更新了文件: $file 的lastUpdated时间" fi done ``` > 脚本由[Claude](/ai#claude)生成 # 在Liunx上筛查日志技巧 > 在Liunx上筛查日志技巧 提示 日常工作中最常用的一些命令 #### 查找文件中的指定内容 [Section titled “查找文件中的指定内容”](#查找文件中的指定内容) ```sh grep '要查找的目标内容' 文件 cat 文件 | grep '要查找的目标内容' cat 文件 | grep '要查找的目标内容' | ... | ... > 导出到文件 ``` #### 在多个文件中查找指定内容 [Section titled “在多个文件中查找指定内容”](#在多个文件中查找指定内容) ```sh grep '你要查找的内容' 文件1 文件2 grep '你要查找的内容' 文件通配符 # 查看最后几行: tail -n 200 文件名 ``` #### Linux日志查看技巧 [Section titled “Linux日志查看技巧”](#linux日志查看技巧) 先必须了解两个最基本的命令: ```sh # 查询日志尾部最后10行的日志 tail -n 10 test.log # 查询10行之后的所有日志 tail -n +10 test.log # 查询日志文件中的头10行日志 head -n 10 test.log # 查询日志文件除了最后10行的其他所有日志 head -n -10 test.log ``` ##### 场景1: 按行号查看,过滤出关键字附近的日志 [Section titled “场景1: 按行号查看,过滤出关键字附近的日志”](#场景1-按行号查看过滤出关键字附近的日志) 因为通常时候我们用grep拿到的日志很少,我们需要查看附近的日志. 1. 首先: `cat -n test.log |grep Goods` 得到关键日志的行号 2. 得到`Goods`关键字所在的行号是102行. 此时如果我想查看`Goods`关键字前10行和后10行的日志: ```sh cat -n test.log |tail -n +92|head -n 20 # 上面命令的解释 # 表示查询92行之后的日志 tail -n +92 # 表示查倒数一行 tail -n 1 # 则表示在前面的查询结果里再查前20条记录 head -n 20 ``` ##### 场景2:那么按日期怎么查呢? 通常我们非常需要查找指定时间端的日志 [Section titled “场景2:那么按日期怎么查呢? 通常我们非常需要查找指定时间端的日志”](#场景2那么按日期怎么查呢-通常我们非常需要查找指定时间端的日志) ```sh # 特别说明:上面的两个日期必须是日志中打印出来的日志,否则无效. sed -n '/2014-12-17 16:17:20/,/2014-12-17 16:17:36/p' test.log ``` 关于日期打印,可以先 `grep '2014-12-17 16:17:20' test.log` 来确定日志中是否有该时间点,这个根据时间段查询日志是非常有用的命令. 如果我们查找的日志很多,打印在屏幕上不方便查看, 有两个方法: 1. 使用`more`和`less`命令, 如: `cat -n test.log |grep Goods |more` 这样就分页打印了,通过点击空格键翻页 2. 使用 `>xxx.txt` 将其保存到文件中,到时可以拉下这个文件分析.如: ```sh cat -n test.log |grep "Goods" >xxx.txt find -name '*.log' | xargs grep 'orderSn' cat -n common.log.tmp | grep 'orde' | grep 'execute time:[0-9][0-9][0-9][0-9]' ``` ##### 截取日志中指定内容 [Section titled “截取日志中指定内容”](#截取日志中指定内容) 比如现在有以下日志内容,且暂定日志文件名为demo.txt: ```java DemoService.demoMethod(..) input:[{"orderSn":"4352345","siteCode":"G5B","userId":234}] DemoService.demoMethod(..) input:[{"orderSn":"4563456345","siteCode":"G5B","userId":2345}] DemoService.demoMethod(..) input:[{"orderSn":"456343456","siteCode":"G5B","userId":2345}] DemoService.demoMethod(..) input:[{"orderSn":"34563456","siteCode":"G5B","userId":52345}] DemoService.demoMethod(..) input:[{"orderSn":"52323455","siteCode":"G5B","userId":23}] DemoService.demoMethod(..) input:[{"orderSn":"345634563456","siteCode":"G5B","userId":55}] DemoService.demoMethod(..) input:[{"orderSn":"23452345","siteCode":"G5B","userId":44}] DemoService.demoMethod(..) input:[{"orderSn":"23452345","siteCode":"G5B","userId":3454}] DemoService.demoMethod(..) input:[{"orderSn":"2346134531","siteCode":"G5B","userId":534}] DemoService.demoMethod(..) input:[{"orderSn":"2363462346","siteCode":"G5B","userId":2345}] DemoService.demoMethod(..) input:[{"orderSn":"1345324646","siteCode":"G5B","userId":2345}] ``` 需要截取orderSn值，可以使用如下命名: ```sh cat demo.txt | cut -d \" -f 4 | sort |uniq > ordeSnList.txt ``` 使用cut 的“域”操作 根据`"`分成不同的区域(`-d "`),获取第4个区域的值(` -f 4`),即订单号所在区域，得到订单号 uniq 去重 cut只能按照单个字符分割,如果要按照字符串分割,可以使用awk。下面就是按照elapsed来分割，然后取第二区域的字符 234 ```sh echo 'asd elapsed 234' | awk -F "elapsed" '{print $2}' ``` 执行结果(订单号:23452345已经去重): ```txt 4352345 4563456345 456343456 34563456 52323455 345634563456 23452345 2346134531 2363462346 1345324646 ``` ###### 两个文件的交集，并集 [Section titled “两个文件的交集，并集”](#两个文件的交集并集) 1. 取出两个文件的并集(重复的行只保留一份) ```sh cat file1 file2 | sort | uniq > file3 ``` 2. 取出两个文件的交集(只留下同时存在于两个文件中的文件) ```sh cat file1 file2 | sort | uniq -d > file3 ``` 3. 删除交集，留下其他的行 ```sh cat file1 file2 | sort | uniq -u > file3 ``` ###### 两个文件合并 [Section titled “两个文件合并”](#两个文件合并) 一个文件在上，一个文件在下 ```sh cat file1 file2 > file3 一个文件在左，一个文件在右 paste file1 file2 > file3 ``` ###### 一个文件去掉重复的行 [Section titled “一个文件去掉重复的行”](#一个文件去掉重复的行) ```sh sort file | uniq # 注意：重复的多行记为一行，也就是说这些重复的行还在，只是全部省略为一行！ sort file | uniq –u # 可以把重复的行全部去掉，仅保留文件中的非重复行！ ``` 反向截取 ```sh cat decrByUseCounter | cut -d ":" -f 1-4 --complement | more ``` #### grep [Section titled “grep”](#grep) 在当前目录下查找文件内容是否包含指定字符 ```sh grep -r "要搜索的字符串" . # 解释 -r: 递归搜索,包括所有子目录 "要搜索的字符串": 你想要查找的具体内容,用引号括起来 .: 表示从当前目录开始搜索 ## 其他参数 -i: 忽略大小写 -l: 只显示文件名,不显示匹配的内容 -n: 显示匹配内容所在的行号 ``` # 消息队列 > 消息队列 #### 一、为什么会出现消息队列? [Section titled “一、为什么会出现消息队列?”](#一为什么会出现消息队列) 削峰、解耦 > 为啥不使用线程?线程是当前应用内的,限制太多 #### 二、使用消息队列会出现哪些问题 [Section titled “二、使用消息队列会出现哪些问题”](#二使用消息队列会出现哪些问题) ##### 1. 系统可用性降低 [Section titled “1. 系统可用性降低”](#1-系统可用性降低) 系统引入的外部依赖越多,越容易挂掉 ##### 2. 系统复杂度提高 [Section titled “2. 系统复杂度提高”](#2-系统复杂度提高) ###### 消息的重复消费。哪些场景会产生重复的消息? [Section titled “消息的重复消费。哪些场景会产生重复的消息?”](#消息的重复消费哪些场景会产生重复的消息) * 网络闪断 * ack失败,队列以为没有消费 **解决方案:** * 业务端保持幂等,例如已取消的订单,又来了一个已取消的消息,则不处理,保持幂等 * 唯一的标识,类似uuid,对已经处理过的消息,不在做二次处理 * 消息表,使用msgId坐主键或者唯一约束 ###### 2. 消息丢失 [Section titled “2. 消息丢失”](#2-消息丢失) **消息会在哪些环节可能丢失?** * 消息在传入过程中丢失 * 队列收到消息,暂存在内存中,还没来得及被消费,队列挂掉了,内存中的数据丢失 * 消费者消费到了这个消息,但是还没有来得及处理,消费者就挂了,而队列以为消息已经被处理 **解决方案:** 先入事务表(消息表)。 如果事务表也满了呢,根据业务日志找回,因为在实际开发过程中都会打印日志,找到对应的日志,重新写入mq **2.1 针对RabbitMQ消息队列可以有以下措施解决:** 1. 对于生产者: * 开启RabbitMQ事务(同步,不推荐) * 开启confirm模式(异步推荐) 2. 对于队列: 开启RabbitMQ持久化 3. 对于消费者： 关闭RabbitMQ自动ack,采用手动ack 4. 数据一致性问题。使用消息表兜底,如果消息表兜底措施也有问题,人工介入,系统并不能解决所有的问题 #### 三、消息队列是天然的广播(发布) [Section titled “三、消息队列是天然的广播(发布)”](#三消息队列是天然的广播发布) 消费者可各取所需(订阅) #### 四、天然的涉及到分布式 [Section titled “四、天然的涉及到分布式”](#四天然的涉及到分布式) 队列的解耦、异步,就会催生天然的分布式 #### 五、Kafka 和 RabbitMQ 消息队列比对 [Section titled “五、Kafka 和 RabbitMQ 消息队列比对”](#五kafka-和-rabbitmq-消息队列比对) 1. 消息传递模型： RabbitMQ：RabbitMQ是一个消息代理,它实现了高级消息队列协议（AMQP）。它支持多种消息传递模型,包括点对点和发布-订阅模型。 Kafka：Kafka是一个分布式流处理平台,主要用于处理实时数据流。它采用发布-订阅模型,消息被持久化保存在日志中,允许多个消费者以不同的速率消费消息。 2. 持久性： RabbitMQ：RabbitMQ默认将消息保存在内存中,可以配置为将消息持久化到磁盘。这使得RabbitMQ在一些情况下可能会有较低的持久性。 Kafka：Kafka将消息持久化到磁盘,因此能够保证数据的持久性。它适用于需要高吞吐量和持久性的场景,如日志处理和事件溯源。 3. 适用场景： RabbitMQ：适用于传统的消息队列场景,如任务队列、事件驱动等。它提供了更多的消息处理模式,适合需要灵活性的应用。 Kafka：适用于大规模的数据管道和实时数据处理,特别是在日志聚合、事件溯源、和流处理方面表现出色。 4. 性能： RabbitMQ：RabbitMQ的性能也很好,但在某些情况下可能会受到单一队列的限制,因此在需要水平扩展性的场景下可能需要一些额外的配置。 Kafka：Kafka旨在提供高吞吐量和水平扩展性,适用于大规模的数据处理和分布式系统。 5. 一致性和可用性： RabbitMQ：RabbitMQ也提供了高可用性的配置选项,但可能需要一些复杂的设置来实现。 Kafka：Kafka设计为具有高可用性和容错性,可以容忍节点故障。它保证消息的有序性和一致性。 #### 六、消息的顺序消费 [Section titled “六、消息的顺序消费”](#六消息的顺序消费) 保证消息顺序消费的前提是生产者的消息是顺序生产的 顺序消费由消费者业务保证(Hash等操作都可以完成),例如: 对于订单的场景,可以让同一个订单消息根据某个规则(例如hash)都发到一个队列中。 ###### 如果是多消费者呢?又如何保证消息消费的顺序性? `from chatGPT` [Section titled “如果是多消费者呢?又如何保证消息消费的顺序性? from chatGPT”](#如果是多消费者呢又如何保证消息消费的顺序性-from-chatgpt) * 单一消费者： 如果你的应用程序结构允许，考虑使用单一消费者来处理消息。这样可以确保消息的顺序性。然而，这可能会影响系统的吞吐量。 —— 在我的工作经历中,都是采用这种方式,虽然部署了多个job节点,但是实际触发运行的只要一个节点,即单线程消费。如果是并行任务,应该单独起一个job项目专门处理这一类的任务,通过多消费者来提升处理能力 * 消息预处理： 在消费者处理消息之前，可以在多线程环境中进行预处理，将消息按照一定的规则排序，然后再交给各个线程处理。这样可以保持消息的顺序性。 * 多个队列，按顺序分发： 将消息分发到多个队列，每个队列由一个单独的消费者线程处理。确保消息根据某个规则（例如，消息的顺序号）发送到相应的队列。这样每个队列内的消息是有序的，但不同队列的消息可以并行处理。 > 在网上我看到一个观点,即业务系统真正需要的是**业务事件顺序**。 > > 要按业务事件顺序处理消息，您实际上并不需要全局锁或只启动单个consumer，或者只选举一个consumer leader，这些解决方案提供了线性化级别的一致性(Linearizability Consistency)，但是在大多数情况下它们太慢且不必要。 实际上，我们只关心因果级别的一致性(Causal Consistency), 只要能找出业务相关的消息，就可以按照事件顺序处理。 为此，我们可以在消费者端为那些因果相关的消息提供状态机，如果消息出现故障（过早），我们可以将其本地存储在“收件箱”中。 稍后，当延迟的消息到达时，我们将状态机触发到下一个状态，然后检查收件箱以查看是否存在下一条期望的消息，或者继续等待下一个消息。 > > **自己的理解**: “收件箱”其实就是类似一种共享变量,所有的消费者在消费时都要来访问一下“收件箱”再做逻辑 > > 参考链接: #### 七、消息产生积压如何处理? [Section titled “七、消息产生积压如何处理?”](#七消息产生积压如何处理) * 临时紧急扩容(如果是docker就很简单,再起几个容器) ——增加消费者 * 建多队列,写分发程序把queue中积压的数据分发到新建的队列中,然后在写多个指定的消费者,消费指定的新建的队列数据。处理完成后再恢复到之前的常规配置 * 消费者开启线程池加快消息处理速度 * 如果是RabbitMQ,可以扩大队列容积,提高堆积上限,采用惰性队列(在声明队列时设置属性 `x-queue-mode` 为 `lazy`,即惰性队列) > 惰性队列的特点:接收到消息后直接存储到磁盘而非内存;消费者要消费消息时才从磁盘读取到内存;支持百万条消息的存储 # Kafka > Kafka * **主题(Topic)**: 主题是消息的逻辑容器，用于将消息进行分组。每个主题可以有一个或多个分区(Partitions)。 * **分区(Partition)**: 分区是主题的物理存储单元，每个分区都是一个有序的消息日志。消息在分区内按照添加顺序进行存储，并且每个消息都有一个唯一的偏移量(Offset)来标识其在分区内的位置。分区可以分布在不同的服务器上，以实现水平扩展和负载均衡。 > Kafka 中 Partition(分区)是真正保存消息的地方，我们发送的消息都被放在了这里。而我们的 Partition(分区) 又存在于 Topic(主题) 这个概念中，并且我们可以给特定 Topic 指定多个 Partition * **偏移量(Offset)**: 偏移量是消息在分区内的唯一标识符，用于确定消息在分区内的位置。消费者可以通过指定偏移量来读取分区内的消息。 * **复制(Replication)**: Kafka支持分区的复制，每个分区可以有多个副本(Replica)。这些副本可以分布在不同的服务器上，以提供冗余和高可用性。 * **日志文件(LogSegment)**: 每个分区内的消息都被存储在一个或多个日志文件中，每个日志文件称为日志段。当一个日志段达到一定大小或时间限制时，Kafka会创建一个新的日志段。这些日志段组成了-分区的持久化消息存储。 * **索引文件(IndexFile)**: 为了支持快速查找消息，Kafka还维护了索引文件，用于存储消息偏移量和物理偏移量之间的映射关系。 * **日志段刷写和清理(LogSegmentFlushAndCompaction)**: Kafka定期将消息写入磁盘，并在需要时清理过期的日志段，以释放磁盘空间。 ### Kafka怎么做到基于磁盘却比内存还快？ [Section titled “Kafka怎么做到基于磁盘却比内存还快？”](#kafka怎么做到基于磁盘却比内存还快) 1. 顺序写入 > Kafka的写入模型非常简单，它通过**追加方式**将消息写入磁盘，这导致了顺序写入(Sequential Writes)。顺序写入比随机写入(Random Writes)更加高效，因为磁盘通常能够更快地处理顺序写入操作 2. 消息压缩 3. 分批发送 4. 零拷贝 —— 解放CPU #### 零拷贝 [Section titled “零拷贝”](#零拷贝) 主要是通过splice的方式实现两个普通文件的数据零拷贝。**splice 系统调用可以在内核缓冲区和 socket 缓冲区之间建立管道来传输数据**，避免了两者之间的 CPU 拷贝操作 > splice 系统调用是 Linux 在 2.6 版本引入的 > 参考: [零拷贝原理](https://juejin.cn/post/6995519558475841550) 、[彻底搞懂零拷贝（Zero-Copy）技术](https://juejin.cn/post/7083793623594041375) > DMA: 直接内存访问（Direct Memory Access），是一种硬件设备绕开CPU,独立直接访问内存的机制。所以 DMA 在一定程度上解放了 CPU，把之前 CPU 的杂活让硬件直接自己做了，提高了 CPU 效率。 ### Kafka消息确认机制 [Section titled “Kafka消息确认机制”](#kafka消息确认机制) ##### 生产者确认机制 [Section titled “生产者确认机制”](#生产者确认机制) 消息从生产者客户端发送至broker服务端topic，需要ack确认。`acks`与`min.insync.replicas`是两个配置参数.其中`acks`是producer的配置参数，`min.insync.replicas`是Broker端的配置参数，这两个参数对于生产者不丢失数据起到了很大的作用 ###### No Reply(acks = 0) [Section titled “No Reply(acks = 0)”](#no-replyacks--0) 生产者不等待来自broker的任何确认,直接返回成功。这是最快的方式,但消息可靠性最低。 ```java ProducerConfig config = new ProducerConfig(props); config.setAcks(0); Producer producer = new KafkaProducer<>(config); ``` ###### Leader Only(acks = 1)(默认) [Section titled “Leader Only(acks = 1)(默认)”](#leader-onlyacks--1默认) 生产者仅等待leader分区已经接收成功后返回。不等待其他副本也接受成功。这提供了更高的吞吐量和较低的延迟。 ```java config.setAcks(1); ``` ###### All ISR(同步副本)(acks = -1) [Section titled “All ISR(同步副本)(acks = -1)”](#all-isr同步副本acks---1) 生产者等待所有在ISR列表中的节点接受成功后才返回。这提供了最高的可靠性。 ```plaintext config.setAcks(-1); ``` ##### 消费者确认机制 [Section titled “消费者确认机制”](#消费者确认机制) 在Kafka中，**消费者确认是通过消费者位移的提交实现的**。类似RabbitMQ的ACK机制。 每个 consumer 实例都会为它消费的分区维护属于自己的位置信息来记录当前消费了多少条消息。这在 Kafka 中有一个特有的术语：位移(offset)。 默认情况下，consumer是自动提交位移的，自动提交间隔是5秒。这就是说若不做特定的设置，consumer程序在后台自动提交位移。通过设置`auto.commit.interval.ms`参数可以控制自动提交的间隔。 手动位移提交就是用户自行确定消息何时被真正处理完并可以提交位移。在一个典型的 consumer 应用场景中，用户需要对 poll 方法返回的消息集合中的消息执行业务级的处理。用户想要确保只有消息被真正处理完成后再提交位移。如果使用自动位移提交则无法保证这种时序性，因此在这种情况下必须使用手动提交位移。设置使用手动提交位移非常简单，仅仅需要在构建 KafkaConsumer 时设置`enable.auto.commit=false`，然后调用 `commitSync`或`commitAsync`方法即可。 * commitSync 异步确认机制 * commitAsync 同步确认机制 ### Kafka 的多副本机制了解吗？带来了什么好处？ [Section titled “Kafka 的多副本机制了解吗？带来了什么好处？”](#kafka-的多副本机制了解吗带来了什么好处) 副本机制就是备份机制，指的是**在分布式集群机器中保存着相同的数据备份**。  副本机制的好处: * **提供数据冗余** * 提供高伸缩性 * 改善数据局部性 1. Kafka 为分区(Partition)引入了多副本(Replica)机制。分区(Partition)中的多个副本之间会有一个叫做 leader 的家伙，其他副本称为 follower。我们发送的消息会被发送到 leader 副本，然后 follower 副本才能从 leader 副本中**拉取消息**进行同步。 2. Kafka 通过给特定 Topic 指定多个 Partition, 而各个 Partition 可以分布在不同的 Broker 上, 这样便能提供比较好的并发能力(负载均衡)。 3. Partition 可以指定对应的 Replica 数, 这也极大地提高了消息存储的安全性, 提高了容灾能力，不过也相应的增加了所需要的存储空间。 配置 `acks = all` 代表则所有副本都要接收到该消息之后该消息才算真正成功被发送 我们不能默认在调用send方法发送消息之后消息消息发送成功了。为了确定消息是发送成功，我们要判断消息发送的结果。但是要注意的是 Kafka 生产者(Producer) 使用 send 方法发送消息实际上是异步的操作，我们可以通过 get()方法获取调用结果 ### Kafka是如何保证副本当中的数据都是一致的呢？ [Section titled “Kafka是如何保证副本当中的数据都是一致的呢？”](#kafka是如何保证副本当中的数据都是一致的呢) **领导者副本机制**  在kafka中，副本分成两类：领导者副本和追随者副本。 每个分区在创建时都要选举一个副本，成为领导者副本，其余的副本自动称为追随者副本。 kafka中，追随者副本是不会对外提供服务的，所有的请求都必须由领导者副本来处理。**(这也是kafka没能提供读操作横向扩展的根本原因，而且它也不像mysql副本一样有”抗读“的作用，帮助领导者减轻压力)** 它唯一的任务就是从领导者副本异步拉去消息，并写入到自己提交日志中，从而实现与领导者副本的同步。 当领导者副本挂掉了，或者说所在Broker宕机了，kafka可以通过Zookeeper提供的监控功能能够实时感知到，并开启新一轮领导者选举，从追随者副本中选一个作为新的领导者。老Leader副本重启回来后，只能作为追随者副本加入到集群中。 **那么这种副本机制设计究竟有什么好处呢？** 1. **方便实现“Read-your-writes”**。顾名思义，就是当你使用生产者api向kafka成功写入消息后，就马上使用消费者api去读取刚才的消息。 如果追随者副本对外提供服务的话，由于副本同步是异步的，因此有可能发生追随者副本还没有及时从领导者副本中拉取最新消息，从而使客户端看不到最新的消息。 2. **方便实现单调读**。单调读就是消费者在多次读消息时候，不会看到一条消息一会儿存在一会儿不存在。 如果允许追随者副本提供读服务，那么假设当前有两个追随者副本F1,F2。生产者往领导者中发送了消息后，F1，F2开始异步拉取消息。若F1拉取成功了，而F2还未拉取成功。此时消费者第一次消费F1副本获取最新消息，第二次消费的时候消费到了F2副本。就获取不到该条消息了。这就不是单调读一致性。所以都由Leader副本来处理请求的话，就能实现单调读。 ### 追随者副本到底在什么条件之下才算与Leader同步? [Section titled “追随者副本到底在什么条件之下才算与Leader同步?”](#追随者副本到底在什么条件之下才算与leader同步) 追随者副本不对外提供服务，只是定期的异步拉取消息。既然是异步的，那么就存在着不可能与Leader实时同步的风险。 基于此，kafka引入了**In-sync Replicas(ISR)同步副本**集合(集合代表多个副本,包含追随者副本和领导者副本)，即它实际上不是依靠与消息条数来进行判断的。而是根据Broker端参数`replica.lag.time.max.ms`参数值来的,这个参数的含义是Follower副本能够落后Leader副本的最长时间间隔，当前默认值是10秒。 这就是说，只要一个 Follower 副本落后 Leader 副本的时间不超过10秒，那么 Kafka 就认为该 Follower 副本与 Leader 是同步的，即使此时 Follower 副本中保存的消息明显少于 Leader 副本中的消息。若是同步过程的速度持续慢于Leadr副本的写入速度，那么在`replica.lag.time.max.ms`时间后，kafka就会自动收缩ISR集合，将该副本踢出集合。 若该副本后面慢慢追上了Leader的进度。那么它是可以被重新放入ISR集合中的。这也表明ISR是一个动态调整的集合，而非静态不变的。 > 单词: lag 落后 、In-sync Replicas 同步副本 **Unclean 领导者选举** 既然ISR可以动态调整，那么就会出现ISR为空的情况。ISR为空的情况就代表Leader副本也挂掉了(落后太多,不是宕机)。那么kafka就需要重新选举新的Leader。 kafka把所有不在ISR的存活副本都称之为非同步副本。 * 通常来说，非同步副本落后Leader太多，因此，如果选择这些副本为新的Leader，就可能出现数据的丢失。在kafka，选举Leader这种过程被成为Unclean。由Broker端参数`unclean.leader.election.enable`控制是否允许Unclean领导者选举。 * **开启 Unclean 领导者选举**可能会造成数据丢失，但**好处是**，它使得分区 Leader 副本一直存在，**不至于停止对外提供服务，因此提升了高可用性**。反之，禁止 Unclean 领导者选举的好处在于维护了数据的一致性，避免了消息丢失，但牺牲了高可用性。 > 一般不建议开启Unclean 领导者选举,因为如果为了这点高可用性的改善，牺牲了数据一致性，是很严重的 ### 基于Zookeeper搭建Kafka高可用集群 [Section titled “基于Zookeeper搭建Kafka高可用集群”](#基于zookeeper搭建kafka高可用集群) ##### Zookeeper集群搭建 [Section titled “Zookeeper集群搭建”](#zookeeper集群搭建) 为保证集群高可用，Zookeeper 集群的节点数最好是奇数，最少有三个节点，所以这里搭建一个三个节点的集群。 拷贝配置样本 zoo\_sample.cfg 为 zoo.cfg 并进行修改内容,核心是 ```sh # server.1 这个1是服务器的标识，可以是任意有效数字，标识这是第几个服务器节点，这个标识要写到dataDir目录下面myid文件里 # 指名集群间通讯端口和选举端口 server.1=127.0.0.1:2287:3387 server.2=127.0.0.1:2288:3388 server.3=127.0.0.1:2289:3389 ``` 分别在三个节点的数据存储目录下新建 myid 文件,并写入对应的节点标识,类似: ```sh #server1 echo "1" > /usr/local/zookeeper-cluster/data/01/myid #server2 echo "2" > /usr/local/zookeeper-cluster/data/02/myid #server3 echo "3" > /usr/local/zookeeper-cluster/data/03/myid ``` zk集群验证: `zkServer.sh status` ##### Kafka集群搭建 [Section titled “Kafka集群搭建”](#kafka集群搭建) 下载并按照3个节点的kafka 3个kafka节点的配置文件主要是: ```sh # The id of the broker. 集群中每个节点的唯一标识 broker.id=0 // 另外2个就是broker.id=1、broker.id=2 # 监听地址 listeners=PLAINTEXT://hadoop001:9092 // 另外2个就是9093、9094 # 数据的存储位置 log.dirs=/usr/local/kafka-logs/00 // 另外2个就是01,02 # Zookeeper连接地址 zookeeper.connect=hadoop001:2181,hadoop001:2182,hadoop001:2183 ``` 顺序启动即可,创建一个主题,然后可以验证下集群: ```sh bin/kafka-topics.sh --create --bootstrap-server hadoop001:9092 \ --replication-factor 3 \ --partitions 1 --topic my-replicated-topic ``` 验证: ```sh bin/kafka-topics.sh --describe --bootstrap-server hadoop001:9092 --topic my-replicated-topic ``` 会输出刚创建的主题信息,里面就包含领导者，同步副本等信息。里面的标识是broke.id的值 ### 我之前做过广告流量系统,为什么选用Kafka而没有选择RabbitMQ [Section titled “我之前做过广告流量系统,为什么选用Kafka而没有选择RabbitMQ”](#我之前做过广告流量系统为什么选用kafka而没有选择rabbitmq) * 直接原因是大数据的架构设计只支持Kafka * 另一个原因是,业务时间要求,要求在20分钟内更新一次广告效果数据,即要求快。而Kafka的一些特性恰好可以满足[→](#kafka%E6%80%8E%E4%B9%88%E5%81%9A%E5%88%B0%E5%9F%BA%E4%BA%8E%E7%A3%81%E7%9B%98%E5%8D%B4%E6%AF%94%E5%86%85%E5%AD%98%E8%BF%98%E5%BF%AB) # Kafka安装及使用 > Kafka安装及使用 #### 使用Docker安装kafka [Section titled “使用Docker安装kafka”](#使用docker安装kafka) docker-compose.yml ```yml version: '3.5' services: zookeeper: image: wurstmeister/zookeeper ## 镜像 container_name: zookeeper ports: - "2181:2181" ## 对外暴露的端口号 kafka: image: wurstmeister/kafka ## 镜像 container_name: kafka volumes: - /etc/localtime:/etc/localtime ## 挂载位置（kafka镜像和宿主机器之间时间保持一直） ports: - "9092:9092" environment: KAFKA_ADVERTISED_HOST_NAME: 192.168.3.21 ## 修改:宿主机IP KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 ## kafka运行是基于zookeeper的 KAFKA_ADVERTISED_PORT: 9092 KAFKA_LOG_RETENTION_HOURS: 120 KAFKA_MESSAGE_MAX_BYTES: 10000000 KAFKA_REPLICA_FETCH_MAX_BYTES: 10000000 KAFKA_GROUP_MAX_SESSION_TIMEOUT_MS: 60000 KAFKA_NUM_PARTITIONS: 3 KAFKA_DELETE_RETENTION_MS: 1000 kafka-manager: image: sheepkiller/kafka-manager ## 镜像：开源的web管理kafka集群的界面 container_name: kafka-manager environment: ZK_HOSTS: 192.168.3.21 ## 修改:宿主机IP ports: - "9009:9000" ## 暴露端口9000这个端口冲突太多 ``` #### 启动 [Section titled “启动”](#启动) ```plaintext docker-compose up -d --build ``` #### 访问 kafka-manager [Section titled “访问 kafka-manager”](#访问-kafka-manager) #### kafka-mangager 如果觉得不好用可以使用 [Section titled “kafka-mangager 如果觉得不好用可以使用”](#kafka-mangager-如果觉得不好用可以使用) ```sh docker run -p 8080:8080 -e KAFKA_BROKERS=192.168.3.21:9092 docker.redpanda.com/redpandadata/console:latest ``` #### 使用 [Section titled “使用”](#使用) ##### 创建一个名称为 moatkon 的 topic [Section titled “创建一个名称为 moatkon 的 topic”](#创建一个名称为-moatkon-的-topic) ```sh kafka-topics.sh --create --topic moatkon \ --zookeeper zookeeper:2181 --replication-factor 1 \ --partitions 3 ``` ##### 查看刚刚创建的 topic 信息 [Section titled “查看刚刚创建的 topic 信息”](#查看刚刚创建的-topic-信息) ```sh kafka-topics.sh --zookeeper zookeeper:2181 --describe --topic moatkon ``` ##### 打开生产者发送消息 [Section titled “打开生产者发送消息”](#打开生产者发送消息) ```sh kafka-console-producer.sh --topic=netsurfingzone-topic-1 --broker-list kafka:9092 ``` ##### 消费者接收消息 [Section titled “消费者接收消息”](#消费者接收消息) ```sh kafka-console-consumer.sh \ --bootstrap-server kafka:9092 \ --from-beginning --topic moatkon ``` ### Java程序 [Section titled “Java程序”](#java程序) 发送到指定分区 ```java /** * p: 指定分区 * d: 消息 */ @GetMapping("/message/{p}/{d}") public String sendMessage(@PathVariable("p")Integer p,@PathVariable("d")String d) { try { kafkaTemplate.send(ApplicationConstant.TOPIC_NAME, p, UUID.randomUUID().toString(),d); } catch (Exception e) { e.printStackTrace(); return e.getMessage(); } return "message send succuessfully"; } ``` 监听指定分区 ```java // 监听全部 // @KafkaListener(groupId = ApplicationConstant.GROUP_ID_JSON, topics = ApplicationConstant.TOPIC_NAME, containerFactory = ApplicationConstant.KAFKA_LISTENER_CONTAINER_FACTORY) // public void receivedMessage(String message) { // logger.info("message received using Kafka listener:" + message); // } @KafkaListener(groupId = ApplicationConstant.GROUP_ID_JSON, containerFactory = ApplicationConstant.KAFKA_LISTENER_CONTAINER_FACTORY, topicPartitions = {@TopicPartition(topic = ApplicationConstant.TOPIC_NAME, partitions = {"0"})}) public void partition0(String message) { logger.info("message received using Kafka listener p0: " + message); } @KafkaListener(groupId = ApplicationConstant.GROUP_ID_JSON, containerFactory = ApplicationConstant.KAFKA_LISTENER_CONTAINER_FACTORY, topicPartitions = {@TopicPartition(topic = ApplicationConstant.TOPIC_NAME, partitions = {"1"})}) public void partition1(String message) { logger.info("message received using Kafka listener p1: " + message); } ``` # RabbitMQ > RabbitMQ **Channel(信道)**: 多路复用连接中的一条独立的双向数据流通道。**信道是建立在真实的TCP连接内的虚拟连接，复用TCP连接的通道**。 **Producer(消息的生产者)**: 向消息队列发布消息的客户端应用程序。 **Consumer(消息的消费者)**: 从消息队列取得消息的客户端应用程序。 **Message(消息)**: 消息由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key(路由键)、priority(消息优先权)、delivery-mode(是否持久性存储)等。 **Routing Key(路由键)**: 消息头的一个属性，用于标记消息的路由规则，决定了交换机的转发路径。最大长度255 字节。 **Queue(消息队列)**: 存储消息的一种数据结构，用来保存消息，直到消息发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将消息取走。**需要注意，当多个消费者订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理，每一条消息只能被一个订阅者接收**。 **Exchange(交换器|路由器)**: **提供Producer到Queue之间的匹配**，接收生产者发送的消息并将这些消息按照路由规则转发到消息队列。交换器用于转发消息，它不会存储消息 ，如果没有 Queue绑定到 Exchange 的话，它会直接丢弃掉 Producer 发送过来的消息。交换器有四种消息调度策略，分别是fanout, direct, topic, headers。 **Binding(绑定)**: 用于建立Exchange和Queue之间的关联。一个绑定就是基于Binding Key将Exchange和Queue连接起来的路由规则，所以可以将交换器理解成一个由Binding构成的路由表。 **Binding Key(绑定键)**: Exchange与Queue的绑定关系，用于匹配Routing Key。最大长度255 字节。 **Broker**：RabbitMQ Server，服务器实体。 ### RabbitMQ工作机制 [Section titled “RabbitMQ工作机制”](#rabbitmq工作机制) **生产者**、**消费者**、**代理** 生产者：消息的创建者，负责创建和推送数据到消息服务器； 消费者：消息的接收方，用于处理数据和确认消息； 代理：就是RabbitMQ本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。 ### RabbitMQ消息发送原理 [Section titled “RabbitMQ消息发送原理”](#rabbitmq消息发送原理) **AMQP信道即Channel** 应用程序和Rabbit Server之间会创建一个TCP连接，一旦TCP打开，并通过了认证(即用户名和密码)，应用程序和Rabbit就创建了一条AMQP信道(Channel)。 **信道(Channel)是创建在“真实”TCP上的虚拟连接**，AMQP命令都是通过信道发送出去的，每个信道都会有一个唯一的ID，不论是发布消息，订阅队列或者消费消息都是通过信道完成的。 ###### 为什么不通过TCP直接发送命令？ [Section titled “为什么不通过TCP直接发送命令？”](#为什么不通过tcp直接发送命令) 因为对于操作系统来说创建和销毁TCP会话是非常昂贵的开销，假设高峰期每秒有成千上万条连接，每个连接都要创建一条TCP会话，这就造成了TCP连接的巨大浪费，而且操作系统每秒能创建的TCP也是有限的，因此很快就会遇到系统瓶颈。 使用一条TCP连接,再通过信道Channel处理消息，既满足了性能的需要，又能确保每个连接的私密性，这就是引入信道概念的原因。 ### RabbitMQ的交货模式 DeliveryMode [Section titled “RabbitMQ的交货模式 DeliveryMode”](#rabbitmq的交货模式-deliverymode) 1. delivery-mode = 1 表示**非持久化** 2. delivery-mode = 2 表示持久化 ##### 非持久化 [Section titled “非持久化”](#非持久化) 非持久化的消息在服务宕机的时候会丢失数据，但是由于不需要磁盘IO，尽可能地降低消息投递的延迟性，性能较高 ##### 持久化 [Section titled “持久化”](#持久化) > Rabbit队列和交换器在默认情况下重启服务器会导致消息丢失。所以为了保证在重启时不丢失,就需要持久化 持久化的消息安全性较高，尽管服务宕机，数据也不会丢失，但是在投递消息的过程中需要发生磁盘IO，性能相对纯内存投递的方式低。**但是尽管是产生了磁盘IO，由于日志的记录方式是直接追加到消息日志文件的末尾，属于顺序IO，没有随机IO，所以性能还是可以接受的**。 **原理:** 所有队列中的消息都以append的方式写到一个文件中，当这个文件的大小超过指定的限制大小后，关闭这个文件再创建一个新的文件供消息的写入。文件名(\*.rdq)从0开始然后依次累加。 当某个消息被删除时，并不立即从文件中删除相关信息，**而是做一些记录，当垃圾数据达到一定比例时，启动垃圾回收处理**，将逻辑相邻的文件中的数据合并到一个文件中。 ### RabbitMQ的交换机 [Section titled “RabbitMQ的交换机”](#rabbitmq的交换机) 1. **Fanout 广播模式** Fanout交换器会把所有发送到该交换器的消息路由到所有与该交换器绑定的消息队列中。订阅模式与Binding Key和Routing Key无关，交换器将接受到的消息分发给有绑定关系的所有消息队列队列(不论Binding Key和Routing Key是什么)。类似于子网广播，子网内的每台主机都获得了一份复制的消息。Fanout交换机转发消息是最快的 2. **Direct 路由模式** Direct交换器需要消息的Routing Key与 Exchange和Queue 之间的Binding Key完全匹配，如果匹配成功，将消息分发到该Queue。 只有当Routing Key和Binding Key完全匹配的时候，消息队列才可以获取消息。 **Direct是Exchange的默认模式**。 RabbitMQ默认提供了一个Exchange，名字是空字符串，类型是Direct，绑定到所有的Queue(每一个Queue和这个无名Exchange之间的Binding Key是Queue的名字)。这也是为什么有时候我们感觉不需要交换器也可以发送和接收消息，但是实际上是使用了RabbitMQ默认提供的Exchange。 3. **Topic 通配符模式** Topic交换器**按照正则表达式模糊匹配**：用消息的Routing Key与 Exchange和Queue 之间的Binding Key进行模糊匹配，如果匹配成功，将消息分发到该Queue。 Routing Key是一个句点号“. ”分隔的字符串(我们将被句点号“. ”分隔开的每一段独立的字符串称为一个单词)。Binding Key与Routing Key一样也是句点号“. ”分隔的字符串。 Binding Key中可以存在两种特殊字符“ \* ”与“#”，用于做模糊匹配，其中“\*”用于匹配一个单词，“#”用于匹配多个单词(也可以是零个或一个)。 4. **Headers** headers交换器允许你匹配AMQP消息的header而非路由键，除此之外headers交换器和direct交换器完全一致，但性能却很差，几乎用不到 ### 高可用队列(HA) [Section titled “高可用队列(HA)”](#高可用队列ha) 在生产环境下，一般都不会允许RabbitMQ这种消息中间件单点，以免单点故障导致服务不可用，那么RabbitMQ同样可以集群部署来保证服务的可用性，在RabbitMQ集群中，我们可以定义HA队列，可以在web管理平台设置，也可以通过AMQP接口设置，**当我们定义某个HA队列的时候，会在集群的各个节点上都建立该队列，发布消息的时候，直接发送至master服务，当master服务受到消息后，把消息同步至各个从节点**，假如开启事务的情况下，是需要在消息被同步到各个节点之后才算完成事务，所以会带来一定的性能损耗 ### RabbitMQ如何搭建高可用? [Section titled “RabbitMQ如何搭建高可用?”](#rabbitmq如何搭建高可用) ##### 普通集群模式 [Section titled “普通集群模式”](#普通集群模式) 在普通集群模式下，集群中各个节点之间**只会相互同步元数据**，也就是说，消息数据不会被同步。那么问题就来了，假如我们连接到 A 节点，但是消息又存储在 B 节点又怎么办呢？ 不论是生产者还是消费者，假如连接到的节点上没有存储队列数据，**那么内部会将其转发到存储队列数据的节点上进行存储**。虽然说内部可以实现转发，但是因为消息仅仅只是存储在一个节点，那么假如这节点挂了，消息是不是就没有了？这个问题确实存在，所以这种普通集群模式并没有达到高可用的目的。 ##### 镜像队列模式 [Section titled “镜像队列模式”](#镜像队列模式) 镜像队列模式下，节点之间不仅仅会同步元数据，消息内容也会在镜像节点间同步，可用性更高。这种方案提升了可用性的同时，因为同步数据之间也会带来网络开销从而在一定程度上会影响到性能。 ##### 搭建方法 [Section titled “搭建方法”](#搭建方法) 加入集群方法 ```sh rabbitmqctl -n rabbit2 join_cluster --ram rabbit1@`hostname -s` // --ram 表示这是一个内存节点 // --disc 表示磁盘节点（默认也是磁盘节点） ``` 如果配置成镜像集群,可以: ```sh rabbitmqctl -n rabbit1 set_policy ha-all "^" '{"ha-mode":"all"}' ``` ##### 基于 HAProxy + Keepalived 高可用集群 [Section titled “基于 HAProxy + Keepalived 高可用集群”](#基于-haproxy--keepalived-高可用集群) 假如一个 RabbitMQ 集群中，有多个内存节点，我们应该连接到哪一个节点呢？这个选择的策略如果放在客户端做，那么会有很大的弊端，最严重的的就是每次扩展集群都要修改客户端代码，所以这种方式并不是很可取，所以我们在部署集群的时候就需要一个中间代理组件，这个组件要能够实现服务监控和转发 在 RabbitMQ 集群中，通过 Keepalived 和 HAProxy 两个组件实现了集群的高可用性和负载均衡功能。 HAProxy 是一个开源的、高性能的负载均衡软件，同样可以作为负载均衡软件的还有 nginx，lvs 等。 HAproxy 支持 7 层负载均衡和 4 层负载均衡。 ###### 高可用 HAProxy [Section titled “高可用 HAProxy”](#高可用-haproxy) HAProxy 虽然实现了负载均衡，但是假如只是部署一个 HAProxy，那么其本身也存在宕机的风险。一旦 HAProxy 宕机，那么就会导致整个集群不可用，所以我们也需要对 HAProxy 也实现集群，那么假如 HAProxy 也实现了集群，客户端应该连接哪一台服务呢？问题似乎又回到了起点，陷入了无限循环中… 为了实现 HAProxy 的高可用，需要再引入一个 Keepalived 组件，Keepalived 组件主要有以下特性: 1. 具有负载功能，可以监控集群中的节点状态，如果集群中某一个节点宕机，可以实现故障转移。 2. 其本身也可以实现集群，但是只能有一个 master 节点。 3. master 节点会对外提供一个**虚拟IP**，应用端只需要连接这一个 IP 就行了。可以理解为集群中的 HAProxy 节点会同时争抢这个虚拟 IP，哪个节点争抢到，就由哪个节点来提供服务。 > **VRRP 协议**即虚拟路由冗余协议（Virtual Router Redundancy Protocol）。Keepalived 中提供的虚拟 IP 机制就属于 VRRP，它是为了避免路由器出现单点故障的一种容错协议。 ### RabbitMQ事务 - 保证消息不丢 [Section titled “RabbitMQ事务 - 保证消息不丢”](#rabbitmq事务---保证消息不丢) 对事务的支持是AMQP协议的一个重要特性。 假设当生产者将一个持久化消息发送给服务器时，因为consume命令本身没有任何Response返回，所以服务器崩溃，没有持久化该消息，生产者是无法获知该消息已经丢失的。 如果此时使用事务，即通过`txSelect()`开启一个事务，然后发送消息给服务器，然后通过`txCommit()`提交该事务，就可以解决上面的问题。 如果`txCommit()`提交了，则该消息一定会持久化，如果`txCommit()`还未提交,服务器就崩溃了，则该消息不会被服务器接收。当然Rabbit MQ也提供了`txRollback()`命令用于回滚某一个事务。 核心: * `txSelect()` 开启一个事务 * `txCommit()` 提交事务 * `txRollback()` 回滚事务 ##### RabbitMQ事务的缺点 [Section titled “RabbitMQ事务的缺点”](#rabbitmq事务的缺点) 使用事务机制的话会降低RabbitMQ的性能，那么有没有更好的方法既能保障producer知道消息已经正确送到，又能基本上不带来性能上的损失呢？RabbitMQ提供了一个更好的方案，即将channel信道设置成confirm模式(即ack)。 ###### 小问题: 假设消费者模式中使用了事务，并且在消息确认之后进行了事务回滚,RabbitMQ会怎么处理消息? [Section titled “小问题: 假设消费者模式中使用了事务，并且在消息确认之后进行了事务回滚,RabbitMQ会怎么处理消息?”](#小问题-假设消费者模式中使用了事务并且在消息确认之后进行了事务回滚rabbitmq会怎么处理消息) 1. 如果`autoAck=false`,即关闭了自动ack,由开发人员处理,那开发人员肯定是收到了消息的才能处理,所以此时回滚,消息是重新放回队列的 2. 如果`autoAck=true`,即自动确认,那么在消费者收到消息后就已经自动ack了,既然ack了,队列就会把消息删除,所以此时回滚是没啥用的 ### RabbitMQ消息的可靠性如何保证? [Section titled “RabbitMQ消息的可靠性如何保证?”](#rabbitmq消息的可靠性如何保证) 1. Message durability(消息持久化) 元数据、消息需要持久化到磁盘； 2. **生产者**消息确认机制 * 通过AMQP提供的**事务**机制实现(*上面有说RabbitMQ的事务*) * 通过生产者消息确认机制(PublisherConfirm)实现 3. **消费者**消息确认机制 --- Confirm模式 通过ACK。每个Message都要被acknowledged(确认，ACK)。我们可以显示的在程序中去ACK，也可以自动的ACK。如果有数据没有被ACK，那么RabbitMQ Server会把这个信息发送到下一个Consumer 4. 消费者自行定义失败重试机制,例如使用Spring的Retry功能，多次重试失败后将消息投递到异常交换机，交由人工处理 ###### Confirm发送方确认模式 [Section titled “Confirm发送方确认模式”](#confirm发送方确认模式) Confirm的三种实现方式： * 方式一：`channel.waitForConfirms()` 普通发送方确认模式； ```java channel.confirmSelect();// 开启发送方确认模式 String message = "Moatkon"; channel.basicPublish("", queueName, null, message.getBytes("UTF-8")); if (channel.waitForConfirms()) { System.out.println("Moatkon消息发送成功" ); } ``` * 方式二：`channel.waitForConfirmsOrDie()` 批量确认模式； ```java channel.confirmSelect();// 开启发送方确认模式 for (int i = 0; i < 10; i++) { String message = "Moatkon" + i; channel.basicPublish("", queueName, null, message.getBytes("UTF-8")); } channel.waitForConfirmsOrDie(); //直到所有信息都发布，只要有一个未确认就会IOException ``` * 方式三：`channel.addConfirmListener()`异步监听发送方确认模式； ```java channel.confirmSelect();// 开启发送方确认模式 for (int i = 0; i < 10; i++) { String message = "Moatkon" + i; channel.basicPublish("", queueName, null, message.getBytes("UTF-8")); } //异步监听确认和未确认的消息 channel.addConfirmListener(new ConfirmListener() { // nack == no ack,哈哈哈 @Override public void handleNack(long deliveryTag, boolean multiple) throws IOException { // do something } @Override public void handleAck(long deliveryTag, boolean multiple) throws IOException { // do something } }); ``` ### Rabbit vhost [Section titled “Rabbit vhost”](#rabbit-vhost) 每个Rabbit都能创建很多vhost，我们称之为虚拟主机，每个虚拟主机其实都是mini版的RabbitMQ，拥有自己的队列，交换器和绑定，拥有自己的权限机制。 ###### vhost的特性: [Section titled “vhost的特性:”](#vhost的特性) 1. RabbitMQ默认的vhost是“/”开箱即用； 2. 多个vhost是隔离的，多个vhost无法通讯，并且不用担心命名冲突(队列和交换器和绑定)，实现了多层分离； 3. 创建用户的时候必须指定vhost； ### 什么样的消息会进入死信队列 [Section titled “什么样的消息会进入死信队列”](#什么样的消息会进入死信队列) 死信交换机和死信队列其实都只是普通的交换机和队列，只不过接受、转发的信息是死信，其他操作并没有区别。 #### 死信的条件 [Section titled “死信的条件”](#死信的条件) * 消息被消费者拒绝（通过basic.reject 或者 back.nack），并且设置 requeue=false。 * 消息过期，因为队列设置了TTL（Time To Live）时间。—— 可以基于此做延时队列 * 超过了队列的长度限制,消息被丢弃 #### 死信队列的消息处理 [Section titled “死信队列的消息处理”](#死信队列的消息处理) 因为和普通的队列和交换机并无差别,启动一个任务重复消费即可。(要避免循环消息哈,所以在消费时要注意适当的处理) ### 延时队列 [Section titled “延时队列”](#延时队列) 延时队列，顾名思义就是存放延时消息的队列，也就是说消费者在一定的延时后才会收到消息。典型的应用场景就是如上所述的订单超时未支付自动取消。 #### 使用死信队列实现延时队列 [Section titled “使用死信队列实现延时队列”](#使用死信队列实现延时队列) 使用消息的TTL 属性，将过期的消息转发到死信队列中，业务监听死信队列的消息就行了。 但是这种实现会有消息阻塞的问题。比如按顺序发送msg1和msg2两条消息，msg1的过期时间为5s，msg2的过期时间为2s。正常理解下，结果肯定是msg2先到死信队列被消费，但是结果却是两条消息都在5s时转发到死信队列被消费。 这是可以借助RabbitMQ插件来实现 #### 延时队列插件 [Section titled “延时队列插件”](#延时队列插件) rabbitmq提供了一个插件 `rabbitmq_delayed_message_exchange` 让我们能够实现 延迟队列 的效果，同时能够解决 通过死信队列实现延迟队列 出现的消息阻塞问题。该插件从RabbitMQ的3.6.12开始支持 交换机类型: `x-delayed-message`,在发消息的时候加一个 header ：x-delay=xxx ，表示延时xxx毫秒。 ### 同样的功能, Kafka可以实现死信队列、延时队列吗 [Section titled “同样的功能, Kafka可以实现死信队列、延时队列吗”](#同样的功能-kafka可以实现死信队列延时队列吗) 原生 Kafka 是不支持 Retry Topic 和 DLT （Dead Letter Topic，死信队列）。但是 Spring Kafka 在客户端实现了这两个功能。 ```xml org.springframework.kafka spring-kafka 2.8.6 ``` * 使用注解的方式启用 Retry Topic，在 @KafkaListener 方法上添加 @RetryableTopic 即可 * @DltHandler 方法自定义死信消费逻辑 # RocketMQ > RocketMQ > RocketMQ 官网: [https://rocketmq.apache.org/zh/](https://rocketmq.apache.org/zh/?utm_source=moatkon.com) ### RocketMQ 领域模型 [Section titled “RocketMQ 领域模型”](#rocketmq-领域模型) > 取自官网  从这张图可以清晰的看出RocketMQ的核心功能。实际使用下来,确实比较易用(相比较于我之前用过的rabbitmq、kafka)。 其余的内容,可以看官网,官网比我写的好多了,阿里出品,不存在语言障碍 # RocketMQ安装及使用 > RocketMQ安装及使用 #### docker-compose.yml [Section titled “docker-compose.yml”](#docker-composeyml) ```yml version: '3.5' services: rmqnamesrv: image: apache/rocketmq:4.9.6 container_name: rmqnamesrv ports: - 9876:9876 volumes: - ./rmqs/logs:/home/rocketmq/logs - ./rmqs/store:/home/rocketmq/store environment: JAVA_OPT_EXT: "-Duser.home=/home/rocketmq -Xms512M -Xmx512M -Xmn128m" command: ["sh","mqnamesrv"] networks: rmq: aliases: - rmqnamesrv rmqbroker: image: apache/rocketmq:4.9.6 container_name: rmqbroker ports: - 10909:10909 - 10911:10911 volumes: - ./rmq/logs:/home/rocketmq/logs - ./rmq/store:/home/rocketmq/store - ./rmq/brokerconf/broker.conf:/etc/rocketmq/broker.conf environment: JAVA_OPT_EXT: "-Duser.home=/home/rocketmq -Xms512M -Xmx512M -Xmn128m -Drocketmq.broker.diskSpaceWarningLevelRatio=0.99" command: ["sh","mqbroker","-c","/etc/rocketmq/broker.conf","-n","rmqnamesrv:9876","autoCreateTopicEnable=true"] depends_on: - rmqnamesrv networks: rmq: aliases: - rmqbroker rmqconsole: image: apacherocketmq/rocketmq-dashboard container_name: rmqconsole ports: - 8180:8080 environment: JAVA_OPTS: "-Drocketmq.namesrv.addr=rmqnamesrv:9876 -Xms128M -Xmx128M -Xmn128m -Dcom.rocketmq.sendMessageWithVIPChannel=false" depends_on: - rmqnamesrv networks: rmq: aliases: - rmqconsole networks: rmq: name: rmq driver: bridge ``` #### 新建文件夹 [Section titled “新建文件夹”](#新建文件夹) ```sh #!/usr/bin/env bash # 创建目录 mkdir -p ./rmqs/logs mkdir -p ./rmqs/store mkdir -p ./rmq/logs mkdir -p ./rmq/store # 设置目录权限 chmod -R 777 ./rmqs/logs chmod -R 777 ./rmqs/store chmod -R 777 ./rmq/logs chmod -R 777 ./rmq/store ``` #### ./rmq/brokerconf/broker.conf [Section titled “./rmq/brokerconf/broker.conf”](#rmqbrokerconfbrokerconf) ```sh # Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information regarding copyright ownership. # The ASF licenses this file to You under the Apache License, Version 2.0 # (the "License"); you may not use this file except in compliance with # the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. #所属集群名字 brokerClusterName=DefaultCluster #broker名字，注意此处不同的配置文件填写的不一样，如果在broker-a.properties使用:broker-a, #在broker-b.properties使用:broker-b brokerName=broker-a #0 表示Master，>0 表示Slave brokerId=0 #nameServer地址，分号分割 #namesrvAddr=rocketmq-nameserver1:9876;rocketmq-nameserver2:9876 namesrvAddr=rmqnamesrv:9876 #启动IP,如果 docker 报 com.alibaba.rocketmq.remoting.exception.RemotingConnectException: connect to <192.168.0.120:10909> failed # 解决方式1 加上一句producer.setVipChannelEnabled(false);，解决方式2 brokerIP1 设置宿主机IP，不要使用docker 内部IP brokerIP1=192.168.3.21 #在发送消息时，自动创建服务器不存在的topic，默认创建的队列数 defaultTopicQueueNums=4 #是否允许 Broker 自动创建Topic，建议线下开启，线上关闭 ！！！这里仔细看是false，false，false #原因下篇博客见~ 哈哈哈哈 autoCreateTopicEnable=true #是否允许 Broker 自动创建订阅组，建议线下开启，线上关闭 autoCreateSubscriptionGroup=true #Broker 对外服务的监听端口 listenPort=10911 #删除文件时间点，默认凌晨4点 deleteWhen=04 #文件保留时间，默认48小时 fileReservedTime=120 #commitLog每个文件的大小默认1G mapedFileSizeCommitLog=1073741824 #ConsumeQueue每个文件默认存30W条，根据业务情况调整 mapedFileSizeConsumeQueue=300 #destroyMapedFileIntervalForcibly=120000 #redeleteHangedFileInterval=120000 #检测物理文件磁盘空间 diskMaxUsedSpaceRatio=99 #存储路径 #storePathRootDir=/home/ztztdata/rocketmq-all-4.1.0-incubating/store #commitLog 存储路径 #storePathCommitLog=/home/ztztdata/rocketmq-all-4.1.0-incubating/store/commitlog #消费队列存储 #storePathConsumeQueue=/home/ztztdata/rocketmq-all-4.1.0-incubating/store/consumequeue #消息索引存储路径 #storePathIndex=/home/ztztdata/rocketmq-all-4.1.0-incubating/store/index #checkpoint 文件存储路径 #storeCheckpoint=/home/ztztdata/rocketmq-all-4.1.0-incubating/store/checkpoint #abort 文件存储路径 #abortFile=/home/ztztdata/rocketmq-all-4.1.0-incubating/store/abort #限制的消息大小 maxMessageSize=65536 #flushCommitLogLeastPages=4 #flushConsumeQueueLeastPages=2 #flushCommitLogThoroughInterval=10000 #flushConsumeQueueThoroughInterval=60000 #Broker 的角色 #- ASYNC_MASTER 异步复制Master #- SYNC_MASTER 同步双写Master #- SLAVE brokerRole=ASYNC_MASTER #刷盘方式 #- ASYNC_FLUSH 异步刷盘 #- SYNC_FLUSH 同步刷盘 flushDiskType=ASYNC_FLUSH #发消息线程池数量 #sendMessageThreadPoolNums=128 #拉消息线程池数量 #pullMessageThreadPoolNums=128 ``` #### 下载并启动容器，且为 后台 自动启动 [Section titled “下载并启动容器，且为 后台 自动启动”](#下载并启动容器且为-后台-自动启动) ```sh docker-compose up -d ``` #### 清除已创建的docker [Section titled “清除已创建的docker”](#清除已创建的docker) ```sh docker-compose down ``` #### 删除产生的日志及临时文件 [Section titled “删除产生的日志及临时文件”](#删除产生的日志及临时文件) ```sh rm -rf ./rmqs/logs/* rm -rf ./rmqs/store/* rm -rf ./rmq/logs/* rm -rf ./rmq/store/* ``` # React Step0 > React学习 ### 学习React的原因 [Section titled “学习React的原因”](#学习react的原因) 因为一直想系统地学习一下前端 ### 为什么选择React [Section titled “为什么选择React”](#为什么选择react) 其实,我自己之前学习过Vue,Vue学习和使用很简单,但是对于Vue的语法,让我很难受。 也学习过Angular，Angular对于Java程序员比较友好,因为里面的一些思想和Spring很类似,所以这也是我上手最快的一个框架。但是不够自由，社区也不是很活跃,感觉随时会落寞,就没有投入太多的时间。所以,并不是Angular不好,只是出现问题解决问题的成本太高了。 后来我接触到Facebook,被Facebook的页面所震撼,了解了一下是React构建的。随后,简单看了一下React官网,就已经有答案了——React就是我一直想要找的,和我的想法很契合。所以最终决定学习React ### 学习资源 [Section titled “学习资源”](#学习资源) * [中文网站](https://zh-hans.react.dev/learn) * [React 开发者工具](https://chromewebstore.google.com/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en\&pli=1) ### 学习笔记 [Section titled “学习笔记”](#学习笔记) #### 基础知识 [Section titled “基础知识”](#基础知识) * **组件**: 在 React 中，组件是一段可重用代码 #### 基础规则 [Section titled “基础规则”](#基础规则) * React 组件必须以大写字母开头，而 HTML 标签则必须是小写字母。 * `export default` 关键字指定了文件中的**主要**组件，JavaScript 的 `export` 关键字使此函数可以在此文件之外访问。`default` 关键字表明它是文件中的主要函数。类似于Java里面的`public class`。 * JSX 比 HTML 更加严格,标签必须闭合 * 组件也不能返回多个 JSX 标签，必须将它们包裹到一个共享的父级中。比如 `

*** 突然冒出来的 react的哲学: 拆解。大问题拆解成一个一个小问题 # React Step2 > React 2/n ### 知识点 [Section titled “知识点”](#知识点) * state 只是为交互提供的保留功能，即数据会随着时间变化 * 记住：React 使用单向数据流，通过组件层级结构从父组件传递数据至子组件。要搞清楚哪个组件拥有哪个 state。 * 用 `useState()` Hook 为组件添加`state`。Hook 可以“钩住”组件的 渲染周期。 ### 是否是state判别 [Section titled “是否是state判别”](#是否是state判别) * 随着时间推移 保持不变？如此，便不是 state。 * 通过 props 从父组件传递？如此，便不是 state。 * 是否可以基于已存在于组件中的 state 或者 props 进行计算？如此，它肯定不是state！ Note 在 React 中有两种“模型”数据：props 和 state。下面是它们的不同之处: * props 像是你传递的参数 至函数。它们使父组件可以传递数据给子组件，定制它们的展示。举个例子，Form 可以传递 color prop 至 Button。 * state 像是组件的内存。它使组件可以对一些信息保持追踪，并根据交互来改变。举个例子，Button 可以保持对 isHovered state 的追踪。 props 和 state 是不同的，但它们可以共同工作。父组件将经常在 state 中放置一些信息（以便它可以改变），并且作为子组件的属性 向下 传递至它的子组件。 ### NEXT TODO [Section titled “NEXT TODO”](#next-todo) * [x] 安装: # React Step3 > React 3/n * React 组件使用 props 来进行组件之间的通讯。每个父组件都可以通过为子组件提供 props 的方式来传递信息。props 可能会让你想起 HTML 属性，但你可以通过它们传递任何 JavaScript 的值，包括对象、数组、函数、甚至是 JSX! * ```js import { getImageUrl } from './utils.js' export default function Profile() { return ( ); } function Avatar({ person, size }) { return ( ); } function Card({ children }) { return (

{children}

); } ``` * JSX 可以让你在 JavaScript 文件中编写类似 HTML 的标签语法，使渲染逻辑和内容展示维护在同一个地方。有时你会想在标签中添加一点 JavaScript 逻辑或引用一个动态属性。在这种情况下，你可以在 JSX 中使用花括号来为 JavaScript “开辟通道 * ```js const person = { name: 'Gregorio Y. Zara', theme: { backgroundColor: 'black', color: 'pink' } }; export default function TodoList() { return (

{person.name}'s Todos

• Improve the videophone
• Prepare aeronautics lectures
• Work on the alcohol-fuelled engine

); } ``` * React 允许你将标签、CSS 和 JavaScript 组合成自定义“组件”，即 应用程序中可复用的 UI 元素 * React 最为重视交互性且使用了相同的处理方式：React 组件是一段可以 使用标签进行扩展 的 JavaScript 函数 * 导出组件。export default 前缀是一种 JavaScript 标准语法（非 React 的特性）。它允许你导出一个文件中的主要函数以便你以后可以从其他文件引入它。 * **React 组件是常规的 JavaScript 函数**，但 **组件的名称必须以大写字母开头**，否则它们将无法运行！ * ```js

是小写的，所以 React 知道我们指的是 HTML 标签。 以大写 P 开头，所以 React 知道我们想要使用名为 Profile 的组件。 ``` * ```js // 这个组件返回一个带有 src 和 alt 属性的 标签。 写得像 HTML，但实际上是 JavaScript！这种语法被称为 JSX，它允许你在 JavaScript 中嵌入标签。 // 返回语句可以全写在一行上，如下面组件中所示： return ; // 但是，如果你的标签和 return 关键字不在同一行，则必须把它包裹在一对括号中，如下所示： return (

); // 没有括号包裹的话，任何在 return 下一行的代码都 将被忽略！ ``` * 🔴 永远不要在组件中定义组件. * ```js export default function Gallery() { // 🔴 永远不要在组件中定义组件 function Profile() { // ... } // ... } ``` * ```js import Gallery from './Gallery.js'; import Gallery from './Gallery'; // 无论是 './Gallery.js' 还是 './Gallery'，在 React 里都能正常使用，只是前者更符合 原生 ES 模块。 ``` * 默认导出 vs 具名导出  同一文件中，有且仅有一个默认导出，但可以有多个具名导出！ 提示 为了减少在默认导出和具名导出之间的混淆，一些团队会选择只使用一种风格（默认或者具名），或者禁止在单个文件内混合使用。这因人而异，选择最适合你的即可！ *** JSX 是 JavaScript 语法扩展,JSX规则: * 只能返回一个根元素 > <> 和 \ 元素,这个空标签被称作 Fragment * 标签必须闭合 * 使用驼峰式命名法给 ~~所有~~ 大部分属性命名！ * 在这里可以找html与jsx属性的写法映射: * 转换器: * 在 JSX 中通过大括号使用 JavaScript * 使用引号传递字符串 * 用 `{` 和 `}` 替代 `"` 和 `"` 以使用 JavaScript 变量 * 大括号内的任何 JavaScript 表达式都能正常运行，包括像 formatDate() 这样的函数调用 * 可以在哪使用大括号 * 用作 JSX 标签内的文本：`

{name}'s To Do List

` 是有效的，但是 `<{tag}>Gregorio Y. Zara's To Do List` 无效。 * 用作紧跟在 = 符号后的 属性：src={avatar} 会读取 avatar 变量，但是 src=“{avatar}” 只会传一个字符串 {avatar}。 * 使用 “双大括号”：JSX 中的 CSS 和 对象。除了字符串、数字和其它 JavaScript 表达式，你甚至可以在 JSX 中传递对象。对象也用大括号表示，例如 { name: “Hedy Lamarr”, inventions: 5 }。因此，为了能在 JSX 中传递，你**必须用另一对额外的大括号**包裹对象：person={{ name: “Hedy Lamarr”, inventions: 5 }}。 > 所以当你下次在 JSX 中看到 {{ 和 }}时，就知道它只不过是包在大括号里的一个对象罢了！ 提示 内联 style 属性 使用驼峰命名法编写。例如，HTML `

` 在你的组件里应该写成 `
`。 ### TODO NEXT [Section titled “TODO NEXT”](#todo-next) * [x] # React Step4 > React 4/n React 组件使用 props 来互相通信。每个父组件都可以提供 props 给它的子组件，从而将一些信息传递给它。Props 可能会让你想起 HTML 属性，但你可以通过它们传递任何 JavaScript 值，包括对象、数组和函数。 提示 在声明 props 时， 不要忘记 `(` 和 `)` 之间的一对花括号 `{` 和 `}` ： ```js function Avatar({ person, size }) { // ... } ``` 这种语法被称为 “解构”，等价于于从函数参数中读取属性： ```js function Avatar(props) { let person = props.person; let size = props.size; // ... } ``` 给 prop 指定一个默认值 如果你想在没有指定值的情况下给 prop 一个默认值，你可以通过在参数后面写 = 和默认值来进行解构： ```js function Avatar({ person, size = 100 }) { // ... } ``` 现在， 如果 `` 渲染时没有 `size` prop， `size` 将被赋值为 100。 默认值仅在缺少 `size` prop 或 `size={undefined}` 时生效。 但是如果你传递了 `size={null}` 或 `size={0}`，默认值将 **不** 被使用。 #### 使用 JSX `展开语法`传递 props [Section titled “使用 JSX 展开语法传递 props”](#使用-jsx-展开语法传递-props) 语法: … (展开语法是三个点) ```js function Profile(props) { return (
); } ``` #### 一个组件可能会随着时间的推移收到不同的 props。 Props 并不总是静态的！Props 反映了组件在任何时间点的数据，并不仅仅是在开始时。 #### 摘要 [Section titled “摘要”](#摘要) * 要传递 props，请将它们添加到 JSX，就像使用 HTML 属性一样。 * 要读取 props，请使用 function Avatar({ person, size }) 解构语法。 * 你可以指定一个默认值，如 size = 100，用于缺少值或值为 undefined 的 props 。 * 你可以使用 \ JSX 展开语法转发所有 props，但不要过度使用它！ * 像 这样的嵌套 JSX，将被视为 Card 组件的 children prop。 * Props 是只读的时间快照：每次渲染都会收到新版本的 props。 * 你不能改变 props。当你需要交互性时，你可以设置 state。 #### TODO NEXT [Section titled “TODO NEXT”](#todo-next) * [x] # React Step5 > 条件/列表渲染 ### 条件渲染 [Section titled “条件渲染”](#条件渲染) * 在 React 中，你可以通过使用 JavaScript 的 `if` 语句、`&&` 和 `? :` 运算符来选择性地渲染 JSX * 选择性地返回 null。在一些情况下，你不想有任何东西进行渲染，可以直接返回 null。 > 实际上，在组件里返回 null 并不常见，因为这样会让想使用它的开发者感觉奇怪。通常情况下，你可以在父组件里选择是否要渲染该组件。 * 在 React 里，标签也是你代码中的一部分，所以你可以使用变量和函数来整理一些复杂的表达式。 * 当 JavaScript `&&` 表达式 的左侧（我们的条件）为 true 时，它则返回其右侧的值（在我们的例子里是勾选符号）。但条件的结果是 false，则整个表达式会变成 false。在 JSX 里，React 会将 false 视为一个“空值”，就像 null 或者 undefined，这样 React 就不会在这里进行任何渲染。 * 使用 `let` 进行重复赋值 ### 列表渲染 [Section titled “列表渲染”](#列表渲染) 在 React 中使用 filter() 筛选需要渲染的组件和使用 map() 把数组转换成组件数组。 ```js const listItems = people.map(person =>
• {person}
); const chemists = people.filter(person => person.profession === '化学家' ); ``` 直接放在 map() 方法里的 JSX 元素一般都需要指定 key 值！ 这些 key 会告诉 React，每个组件对应着数组里的哪一项，所以 React 可以把它们匹配起来。这在数组项进行移动（例如排序）、插入或删除等操作时非常重要。一个合适的 key 可以帮助 React 推断发生了什么，从而得以正确地更新 DOM 树。 > 用作 key 的值应该在数据中提前就准备好，而不是在运行时才随手生成 > 一个精心选择的 key 值所能提供的信息远远不止于这个元素在数组中的位置。即使元素的位置在渲染的过程中发生了改变，它提供的 key 值也能让 React 在整个生命周期中一直认得它 > 有一点需要注意，组件不会把 key 当作 props 的一部分。Key 的存在只对 React 本身起到提示作用。如果你的组件需要一个 ID，那么请把它作为一个单独的 prop 传给组件： ``。 # React Step6 > 保持组件纯粹/UI=树 ### 保持组件纯粹 [Section titled “保持组件纯粹”](#保持组件纯粹) 部分 JavaScript 函数是 纯粹 的，这类函数通常被称为纯函数。纯函数仅执行计算操作，不做其他操作。你可以通过将组件按纯函数严格编写，以避免一些随着代码库的增长而出现的、令人困扰的 bug 以及不可预测的行为。 React 便围绕着这个概念进行设计。React 假设你编写的所有组件都是纯函数。也就是说，对于相同的输入，你所编写的 React 组件必须总是返回相同的 JSX。 React 提供了 “严格模式”，在严格模式下开发时，它将会调用每个组件函数两次。通过重复调用组件函数，严格模式有助于找到违反这些规则的组件。严格模式在生产环境下不生效，因此它不会降低应用程序的速度。如需引入严格模式，你可以用 `` 包裹根组件。一些框架会默认这样做。 *** 局部 mutation：组件的小秘密。都是在组件内操作的，组件之外并不知道发生了什么——如同藏在组件里的小秘密。 *** 函数式编程在很大程度上依赖于纯函数，但 某些事物 在特定情况下不得不发生改变。这是编程的要义！这些变动包括更新屏幕、启动动画、更改数据等，它们被称为 副作用。它们是 “额外” 发生的事情，与渲染过程无关。 在 React 中，副作用通常属于 事件处理程序。事件处理程序是 React 在你执行某些操作（如单击按钮）时运行的函数。即使事件处理程序是在你的组件 内部 定义的，它们也不会在渲染期间运行！ 因此事件处理程序无需是纯函数。 如果你用尽一切办法，仍无法为副作用找到合适的事件处理程序，你还可以调用组件中的 useEffect 方法将其附加到返回的 JSX 中。这会告诉 React 在渲染结束后执行它。然而，这种方法应该是你最后的手段。 如果可能，请尝试仅通过渲染过程来表达你的逻辑。你会惊讶于这能带给你多少好处！ *** ### UI=树 [Section titled “UI=树”](#ui树) > 路由=关键字符+if,if返回不同的jsx 尽管渲染树可能在不同的渲染过程中有所不同，但通常这些树有助于识别 React 应用程序中的顶级和叶子组件。顶级组件是离根组件最近的组件，它们影响其下所有组件的渲染性能，通常包含最多复杂性。叶子组件位于树的底部，没有子组件，通常会频繁重新渲染。 识别这些组件类别有助于理解应用程序的数据流和性能。 #### 模块依赖树 [Section titled “模块依赖树”](#模块依赖树) 在 React 应用程序中，可以使用树来建模的另一个关系是应用程序的模块依赖关系。当 拆分组件 和逻辑到不同的文件中时，就创建了 JavaScript 模块，在这些模块中可以导出组件、函数或常量。 模块依赖树中的每个节点都是一个模块，每个分支代表该模块中的 import 语句。 依赖树对于确定运行 React 应用程序所需的模块非常有用。在为生产环境构建 React 应用程序时，通常会有一个构建步骤，该步骤将捆绑所有必要的 JavaScript 以供客户端使用。负责此操作的工具称为 bundler（捆绑器），并且 bundler 将使用依赖树来确定应包含哪些模块。 #### TODO NEXT [Section titled “TODO NEXT”](#todo-next) * [x] # React Step7 > 交互 ### 响应事件 [Section titled “响应事件”](#响应事件) > #### 添加事件处理函数 [Section titled “添加事件处理函数”](#添加事件处理函数) 如需添加一个事件处理函数，你需要先定义一个函数，然后 **将其作为 prop 传入** 合适的 JSX 标签。 事件处理函数有如下特点: * 通常在你的组件 内部 定义。 * 名称以 handle 开头，后跟事件名称。 #### 在事件处理函数中读取 props [Section titled “在事件处理函数中读取 props”](#在事件处理函数中读取-props) 由于事件处理函数声明于组件内部，因此它们可以直接访问组件的 props ```js function AlertButton({ message, children }) { return ( alert(message)}> {children} ); } export default function Toolbar() { return (
播放电影 上传图片
); } ``` #### 将事件处理函数作为 props 传递 [Section titled “将事件处理函数作为 props 传递”](#将事件处理函数作为-props-传递) 通常，我们会在父组件中定义子组件的事件处理函数。比如：置于不同位置的 Button 组件，可能最终执行的功能也不同 ```js function Button({ onClick, children }) { return ( {children} ); } function PlayButton({ movieName }) { function handlePlayClick() { alert(`正在播放 ${movieName}！`); } return ( 播放 "{movieName}" ); } function UploadButton() { return ( alert('正在上传！')}> 上传图片 ); } export default function Toolbar() { return (
); } ``` #### 命名事件处理函数 prop [Section titled “命名事件处理函数 prop”](#命名事件处理函数-prop) 内置组件（` 和
`）仅支持 浏览器事件名称，例如 onClick。但是，当你构建自己的组件时，你可以按你个人喜好命名事件处理函数的 prop。这种处理非常优雅,因为是使程序非常可读 > 按照惯例，事件处理函数 props 应该以 on 开头，后跟一个大写字母。例如，Button 组件的 onClick prop 本来也可以被命名为 onSmash ```js function Button({ onSmash, children }) { return (
{children} ); } export default function App() { return (
alert('正在播放！')}> 播放电影 alert('正在上传！')}> 上传图片
); } // 上述示例中， 代表浏览器内置的 （小写）仍然需要使用 onClick prop，而自定义的Button 组件接收到的 prop 名称可由你决定！ ``` 提示 确保为事件处理程序使用适当的 HTML 标签。例如，要处理点击事件，请使用 `` 而不是 `
`。使用真正的浏览器 `
` 启用内置的浏览器行为，如键盘导航。如果你不喜欢按钮的默认浏览器样式，并且想让它看起来更像一个链接或不同的 UI 元素，你可以使用 CSS 来实现。 #### 事件传播 [Section titled “事件传播”](#事件传播) 事件处理函数还将捕获任何来自子组件的事件。通常，我们会说事件会沿着树向上“冒泡”或“传播”：它从事件发生的地方开始，然后沿着树向上传播。 ```js export default function Toolbar() { return (
{ alert('你点击了 toolbar ！'); }}>
alert('正在播放！')}> 播放电影 ); } // “正在播放！”先出现,再出现 “你点击了 toolbar ！” ``` 提示 在 React 中所有事件都会传播，除了 onScroll，它仅适用于你附加到的 JSX 标签。 #### 阻止传播 [Section titled “阻止传播”](#阻止传播) > 事件处理函数接收一个 事件对象 作为唯一的参数。按照惯例，它通常被称为 e ，代表 “event”（事件）。你可以使用此对象来读取有关事件的信息 这个事件对象还允许你阻止传播。如果你想阻止一个事件到达父组件，可以调用 e.stopPropagation(): > 捕获阶段事件 极少数情况下，你可能需要捕获子元素上的所有事件，即便它们阻止了传播。例如，你可能想对每次点击进行埋点记录，传播逻辑暂且不论。那么你可以通过在事件名称末尾添加 Capture 来实现这一点： > > ```js >
{ /* 这会首先执行 */ }}> > e.stopPropagation()} /> > e.stopPropagation()} /> >
> ``` #### 阻止默认行为 [Section titled “阻止默认行为”](#阻止默认行为) 某些浏览器事件具有与事件相关联的默认行为。例如，点击 `
` 表单内部的按钮会触发表单提交事件，默认情况下将重新加载整个页面。可以调用事件对象中的 `e.preventDefault()` 来阻止这种情况发生 * `e.stopPropagation()` 阻止触发绑定在外层标签上的事件处理函数。 * `e.preventDefault()` 阻止少数事件的默认浏览器行为。 ### state: 组件的记忆 [Section titled “state: 组件的记忆”](#state-组件的记忆) 要使用新数据更新组件，需要做两件事： * 保留 渲染之间的数据。 * 触发 React 使用新数据渲染组件（重新渲染）。 useState Hook 提供了这两个功能： * State 变量 用于保存渲染间的数据。 * State setter 函数 更新变量并触发 React 再次渲染组件。 ```js const [index, setIndex] = useState(0); // index 是一个 state 变量，setIndex 是对应的 setter 函数。（每次你的组件渲染时，useState 都会给你一个包含两个值的数组）。 // 这里的 [ 和 ] 语法称为数组解构，它允许你从数组中读取值。 useState 返回的数组总是正好有两项。 ``` > 在 React 中，useState 以及任何其他以“use”开头的函数都被称为 Hook。 Hook 是特殊的函数，只在 React 渲染时有效。它们能让你 “hook” 到不同的 React 特性中去。 提示 Hooks ——以 use 开头的函数——只能在组件或自定义 Hook 的最顶层调用。 你不能在条件语句、循环语句或其他嵌套函数内调用 Hook。Hook 是函数，但将它们视为关于组件需求的无条件声明会很有帮助。在组件顶部 “use” React 特性，类似于在文件顶部“导入”模块。 #### State 是隔离且私有的 [Section titled “State 是隔离且私有的”](#state-是隔离且私有的) State 是屏幕上组件实例内部的状态。换句话说，如果你渲染同一个组件两次，每个副本都会有完全隔离的 state！改变其中一个不会影响另一个。 state的作用域“只限于”屏幕上的某块特定区域 ### 渲染和提交 [Section titled “渲染和提交”](#渲染和提交) ```js import Image from './Image.js'; import { createRoot } from 'react-dom/client'; const root = createRoot(document.getElementById('root')) root.render(); //当应用启动时，会触发初次渲染。框架和沙箱有时会隐藏这部分代码，但它是通过调用 createRoot 方法并传入目标 DOM 节点，然后用你的组件调用 render 函数完成的 ``` > 不要过早进行优化！ ```js import { useState } from 'react'; export default function Counter() { const [number, setNumber] = useState(0); return ( <>
{number}
{ setNumber(number + 5); setTimeout(() => { alert(number); }, 3000); }}>+5 ) } // 用户与之交互时状态的*快照*进行调度的。alert的值为0 ``` 一个 state 变量的值永远不会在一次渲染的内部发生变化， 即使其事件处理函数的代码是异步的。在 那次渲染的 onClick 内部，number 的值即使在调用 setNumber(number + 5) 之后也还是 0。它的值在 React 通过调用你的组件“获取 UI 的快照”时就被“固定”了。 #### React 会对 state 更新进行批处理 [Section titled “React 会对 state 更新进行批处理”](#react-会对-state-更新进行批处理) setNumber(n => n + 1) 使用更新函数 总而言之，以下是你可以考虑传递给 setNumber state 设置函数的内容： * 一个更新函数（例如：n => n + 1）会被添加到队列中。 * 任何其他的值（例如：数字 5）会导致“替换为 5”被添加到队列中，已经在队列中的内容会被忽略。 事件处理函数执行完成后，React 将触发重新渲染。在重新渲染期间，React 将处理队列。更新函数会在渲染期间执行，因此 更新函数必须是 纯函数 并且只 返回 结果。不要尝试从它们内部设置 state 或者执行其他副作用。在严格模式下，React 会执行每个更新函数两次（但是丢弃第二个结果）以便帮助你发现错误。 命名惯例: 通常可以通过相应 state 变量的第一个字母来命名更新函数的参数 ```js setEnabled(e => !e); setLastName(ln => ln.reverse()); setFriendCount(fc => fc * 2); ``` ### 更新 state 中的对象 [Section titled “更新 state 中的对象”](#更新-state-中的对象) state 中可以保存任意类型的 JavaScript 值，包括对象。但是，你不应该直接修改存放在 React state 中的对象。相反，当你想要更新一个对象时，你需要**创建一个新的对象（或者将其拷贝一份），然后将 state 更新为此对象**。 你应该像处理数字、布尔值、字符串一样将对象视为不可变的。因此你应该替换对象的值，而不是对对象进行修改。=> 将 state 视为只读的 **把所有存放在 state 中的 JavaScript 对象都视为只读的** 局部 mutation 是可以接受的 像这样的代码是有问题的，因为它改变了 state 中现有的对象： ```js position.x = e.clientX; position.y = e.clientY; ``` 但是像这样的代码就 没有任何问题，因为你改变的是你刚刚创建的一个新的对象： ```js const nextPosition = {}; nextPosition.x = e.clientX; nextPosition.y = e.clientY; setPosition(nextPosition); ``` 事实上，它完全等同于下面这种写法： ```js setPosition({ x: e.clientX, y: e.clientY }); ``` 只有当你改变已经处于 state 中的 现有 对象时，mutation 才会成为问题。而修改一个你刚刚创建的对象就不会出现任何问题，因为 还没有其他的代码引用它。改变它并不会意外地影响到依赖它的东西。这叫做“局部 mutation”。你甚至可以 在渲染的过程中 进行“局部 mutation”的操作。这种操作既便捷又没有任何问题！ ##### 使用展开语法复制对象 [Section titled “使用展开语法复制对象”](#使用展开语法复制对象) > 重点: 使用展开语法,方便 ```js setPerson({ ...person, // 复制上一个 person 中的所有字段 firstName: e.target.value // 但是覆盖 firstName 字段 }); ``` 请注意 … 展开语法本质是是“浅拷贝”——它只会复制一层。这使得它的执行速度很快，但是也意味着当你想要更新一个**嵌套属性**时，你必须得多次使用展开语法。 ```js setPerson({ ...person, // 复制其它字段的数据 artwork: { // 替换 artwork 字段 ...person.artwork, // 复制之前 person.artwork 中的数据 city: 'New Delhi' // 但是将 city 的值替换为 New Delhi！ } }); ``` 如果想简洁可以可以使用 Immer原理: 由 Immer 提供的 draft 是一种特殊类型的对象，被称为 Proxy，它会记录你用它所进行的操作。这就是你能够随心所欲地直接修改对象的原因所在！从原理上说，Immer 会弄清楚 draft 对象的哪些部分被改变了，并会依照你的修改创建出一个全新的对象。 可以看使用案例: ### 更新 state 中的数组 [Section titled “更新 state 中的数组”](#更新-state-中的数组) 学习文档: 数组是另外一种可以存储在 state 中的 JavaScript 对象，它虽然是可变的，但是却应该被视为不可变。同对象一样，当你想要更新存储于 state 中的数组时，你需要创建一个新的数组（或者创建一份已有数组的拷贝值），并使用新数组设置 state。 在 JavaScript 中，数组只是另一种对象。同对象一样，你需要将 React state 中的数组视为只读的。这意味着你不应该使用类似于 arr\[0] = ‘bird’ 这样的方式来重新分配数组中的元素，也不应该使用会直接修改原始数组的方法，例如 push() 和 pop()。 相反，每次要更新一个数组时，你需要把一个新的数组传入 state 的 setting 方法中。为此，你可以通过使用像 filter() 和 map() 这样不会直接修改原始值的方法，从原始数组生成一个新的数组。然后你就可以将 state 设置为这个新生成的数组。  使用 map 在没有 mutation 的前提下将一个旧的元素替换成更新的版本。 结论: 请使用 Immer 来保持代码简洁 ### TODO NEXT [Section titled “TODO NEXT”](#todo-next) * [x] # React Step8 > 状态管理 在组件间共享状态: 就是状态提升 对于每个独特的状态，都应该存在且只存在于一个指定的组件中作为 state。这一原则也被称为拥有 “可信单一数据源”。 只要一个组件还被渲染在 UI 树的相同位置，React 就会保留它的 state。 如果它被移除，或者一个不同的组件被渲染在相同的位置，那么 React 就会丢掉它的 state。 记住 **对 React 来说重要的是组件在 UI 树中的位置**,而不是在 JSX 中的位置！ 提示 核心就是组件在树的位置已经是不是同一个组件，来决定是否需要重置state 永远要将组件定义在最上层并且不要把它们的定义嵌套起来.否则会导致state丢失，因为嵌套起来,每次处罚,都是新的，自然会丢失 你可能在 渲染列表 时见到过 key。但 key 不只可以用于列表！你可以使用 key 来让 React 区分任何组件。默认情况下，React 使用父组件内部的顺序来区分组件。 ```js {isPlayerA ? ( ) : ( )} // 请记住 key 不是全局唯一的。它们只能指定 父组件内部 的顺序。 ``` 使用 key 来重置 state 在处理表单时特别有用。 #### 为被移除的组件保留 state [Section titled “为被移除的组件保留 state”](#为被移除的组件保留-state) * 与其只渲染现在这一个聊天，你可以把 所有 聊天都渲染出来，但用 CSS 把其他聊天隐藏起来。这些聊天就不会从树中被移除了，所以它们的内部 state 会被保留下来。这种解决方法对于简单 UI 非常有效。但如果要隐藏的树形结构很大且包含了大量的 DOM 节点，那么性能就会变得很差。 * 你可以进行 状态提升 并在父组件中保存每个收件人的草稿消息。这样即使子组件被移除了也无所谓，因为保留重要信息的是父组件。这是最常见的解决方法。 * 除了 React 的 state，你也可以使用其他数据源。例如，也许你希望即使用户不小心关闭页面也可以保存一份信息草稿。要实现这一点，你可以让 Chat 组件通过读取 localStorage 对其 state 进行初始化，并把草稿保存在那里。 ### 迁移状态逻辑至 Reducer 中 [Section titled “迁移状态逻辑至 Reducer 中”](#迁移状态逻辑至-reducer-中) 对于拥有许多状态更新逻辑的组件来说，过于分散的事件处理程序可能会令人不知所措。对于这种情况，你可以将组件的所有状态更新逻辑整合到一个外部函数中，这个函数叫作 reducer。 Reducer 是处理状态的另一种方式。你可以通过三个步骤将 useState 迁移到 useReducer： 1. 将设置状态的逻辑 修改 成 dispatch 的一个 action； 2. 编写 一个 reducer 函数； 3. 在你的组件中 使用 reducer。 使用 Immer 简化 reducer: ### 使用 Context 深层传递参数 [Section titled “使用 Context 深层传递参数”](#使用-context-深层传递参数) 通常来说，你会通过 props 将信息从父组件传递到子组件。但是，如果你必须通过许多中间组件向下传递 props，或是在你应用中的许多组件需要相同的信息，传递 props 会变的十分冗长和不便。**Context 允许父组件向其下层无论多深的任何组件提供信息，而无需通过 props 显式传递**。 Context：传递 props 的另一种方法 。Context 让父组件可以为它下面的整个组件树提供数据。 ```js ``` Context 的工作方式可能会让你想起 CSS 属性继承。在 CSS 中，你可以为一个 手动指定 color: blue，并且其中的任何 DOM 节点，无论多深，都会继承那个颜色，除非中间的其他 DOM 节点用 color: green 来覆盖它。类似地，在 React 中，覆盖来自上层的某些 context 的唯一方法是将子组件包裹到一个提供不同值的 context provider 中。 在 CSS 中，诸如 color 和 background-color 之类的不同属性不会覆盖彼此。你可以设置所有 的 color 为红色，而不会影响 background-color。类似地，**不同的 React context 不会覆盖彼此**。你通过 createContext() 创建的每个 context 都和其他 context 完全分离，只有使用和提供 那个特定的 context 的组件才会联系在一起。一个组件可以轻松地使用或者提供许多不同的 context。 #### 在使用 context 之前，你可以考虑以下几种替代方案： [Section titled “在使用 context 之前，你可以考虑以下几种替代方案：”](#在使用-context-之前你可以考虑以下几种替代方案) 1. 从 **传递 props** 开始。 如果你的组件看起来不起眼，那么通过十几个组件向下传递一堆 props 并不罕见。这有点像是在埋头苦干，但是这样做可以让哪些组件用了哪些数据变得十分清晰！维护你代码的人会很高兴你用 props 让数据流变得更加清晰。 2.抽象组件并 将 JSX 作为 children 传递 给它们。 如果你通过很多层不使用该数据的中间组件（并且只会向下传递）来传递数据，这通常意味着你在此过程中忘记了抽象组件。举个例子，你可能想传递一些像 posts 的数据 props 到不会直接使用这个参数的组件，类似 ``。取而代之的是，让 Layout 把 children 当做一个参数，然后渲染 ``。这样就减少了定义数据的组件和使用数据的组件之间的层级。 #### Context 的使用场景 [Section titled “Context 的使用场景”](#context-的使用场景) * 主题： 如果你的应用允许用户更改其外观（例如暗夜模式），你可以在应用顶层放一个 context provider，并在需要调整其外观的组件中使用该 context。 * 当前账户： 许多组件可能需要知道当前登录的用户信息。将它放到 context 中可以方便地在树中的任何位置读取它。某些应用还允许你同时操作多个账户（例如，以不同用户的身份发表评论）。在这些情况下，将 UI 的一部分包裹到具有不同账户数据的 provider 中会很方便。 * 路由： 大多数路由解决方案在其内部使用 context 来保存当前路由。这就是每个链接“知道”它是否处于活动状态的方式。如果你创建自己的路由库，你可能也会这么做。 * 状态管理： 随着你的应用的增长，最终在靠近应用顶部的位置可能会有很多 state。许多遥远的下层组件可能想要修改它们。通常 将 reducer 与 context 搭配使用来管理复杂的状态并将其传递给深层的组件来避免过多的麻烦。 Context 不局限于静态值。如果你在下一次渲染时传递不同的值，React 将会更新读取它的所有下层组件！这就是 context 经常和 state 结合使用的原因。 一般而言，如果树中不同部分的远距离组件需要某些信息，context 将会对你大有帮助。 ### 使用 Reducer 和 Context 拓展你的应用 [Section titled “使用 Reducer 和 Context 拓展你的应用”](#使用-reducer-和-context-拓展你的应用) Reducer 可以整合组件的状态更新逻辑。Context 可以将信息深入传递给其他组件。你可以组合使用它们来共同管理一个复杂页面的状态。 将state和函数都放入context # React Step9 > 脱围机制（Escape Hatches） 有些组件可能需要控制和同步 React 之外的系统。例如，你可能需要使用浏览器 API 聚焦输入框，或者在没有 React 的情况下实现视频播放器，或者连接并监听远程服务器的消息。在本章中，你将学习到一些脱围机制，让你可以“走出” React 并连接到外部系统。大多数应用逻辑和数据流不应该依赖这些功能。 当你希望组件“记住”某些信息，但又不想让这些信息 触发新的渲染 时，你可以使用 ref： ```js const ref = useRef(0); ``` ref 就像组件的一个不被 React 追踪的秘密口袋。例如，可以使用 ref 来存储 timeout ID、DOM 元素 和其他不影响组件渲染输出的对象。 Effect 是 React 范式中的一种脱围机制。它们可以“逃出” React 并使组件和一些外部系统同步。如果没有涉及到外部系统（例如，需要根据一些 props 或 state 的变化来更新一个组件的 state），不应该使用 Effect。移除不必要的 Effect 可以让代码更容易理解，运行得更快，并且更少出错。 有两种常见的不必使用 Effect 的情况： * 不必为了渲染而使用 Effect 来转换数据。 * 不必使用 Effect 来处理用户事件。 # README > 软件工程师 #### 主要路线 [Section titled “主要路线”](#主要路线) 学习、总结、输出、Positive cycle #### 面向的群体 [Section titled “面向的群体”](#面向的群体) * 对代码感兴趣 * 正在学习编程 * 进阶 #### 为什么要写软件工程师相关的内容 [Section titled “为什么要写软件工程师相关的内容”](#为什么要写软件工程师相关的内容) 1. 可以让我对基础技术的理解更加透彻 2. 期望通过护城河系列聚集一批志同道合的人 3. 帮助他人,帮助自己 #### 内容 [Section titled “内容”](#内容) 内容来源: * 互联网,如有雷同,[点此联系](mailto:moatkon@gmail.com?subject=%E5%86%85%E5%AE%B9%E9%9B%B7%E5%90%8C\&body=%E9%BA%BB%E7%83%A6%E8%AF%B7%E5%91%8A%E7%9F%A5%E5%86%85%E5%AE%B9%E9%9B%B7%E5%90%8C%E7%9A%84url%E5%8F%8A%E5%86%85%E5%AE%B9%E6%88%AA%E5%9B%BE,moatkon%E4%BC%9A%E5%8F%8A%E6%97%B6%E5%A4%84%E7%90%86) * 个人经验、理解 内容难免会出现错误,如有错误,麻烦指出: * [内容勘误](mailto:moatkon@gmail.com?subject=%E5%86%85%E5%AE%B9%E5%8B%98%E8%AF%AF\&body=%E5%A6%82%E6%9E%9C%E5%8F%AF%E4%BB%A5%E7%9A%84%E8%AF%9D,%E9%BA%BB%E7%83%A6%E9%80%9A%E8%BF%87%E6%88%AA%E5%9B%BE%E5%B9%B6%E6%A0%87%E6%B3%A8%E7%9A%84%E5%BD%A2%E5%BC%8F%E6%9D%A5%E7%9B%B4%E6%8E%A5%E6%8C%87%E5%87%BA%E9%94%99%E8%AF%AF%E7%9A%84%E5%9C%B0%E6%96%B9) * [其他联系方式](/contact) # Spring Cloud Gateway内存泄漏排查 > Spring Cloud Gateway 内存泄漏排查排查 ### 背景 [Section titled “背景”](#背景) 线上Spring Cloud Gateway网关运行一段时间后会自动重启。通过Prometheus监控可以观察到现象是内存使用量持续上升 ### 前期排查 [Section titled “前期排查”](#前期排查) 前期排查主要使用[Arthas](https://arthas.aliyun.com/doc/install-detail.html)获取最忙的线程,观察最忙的线程在做什么。在这一步我们只能获取到与feign的请求有关。 因为我们在网关上做了一层转发,使用的是feign,并不是单独起一个服务来通过route路由来实现的。 在这一步,我们只能获取到这些信息。 后面我在线上机器使用命令转储了一份hprof二进制Heap Dump文件 ```sh jmap -dump:live,format=b,file=moatkon_heap.hprof [pid] ``` 后面使用[MAT](https://eclipse.dev/mat/)工具分析后并未查到具体原因。 ### 验证 [Section titled “验证”](#验证) 既然前面猜测可能与feign调用有关,那就尝试在本地复现。在本地使用Jmeter来并发调用,看能否复现。 > Jmeter并发线程数为600,一直循环下去  在使用Jmeter并发调用前根据 这篇文章在本地开启ADVANCED的泄露检测级别 ```sh -Dio.netty.leakDetection.level=advanced ``` 开启后使用Jmeter开启600个线程来并发调用。刚调用就抛出异常 ```java ERROR io.netty.util.ResourceLeakDetector - LEAK: ByteBuf.release() was not called before it's garbage-collected. Recent access records: 1 #1: io.netty.buffer.AdvancedLeakAwareByteBuf.toString(AdvancedLeakAwareByteBuf.java:697) io.netty.handler.codec.xml.XmlFrameDecoderTest.testDecodeWithXml(XmlFrameDecoderTest.java:157) io.netty.handler.codec.xml.XmlFrameDecoderTest.testDecodeWithTwoMessages(XmlFrameDecoderTest.java:133) ... Created at: io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:55) io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:155) io.netty.buffer.UnpooledUnsafeDirectByteBuf.copy(UnpooledUnsafeDirectByteBuf.java:465) io.netty.buffer.WrappedByteBuf.copy(WrappedByteBuf.java:697) io.netty.buffer.AdvancedLeakAwareByteBuf.copy(AdvancedLeakAwareByteBuf.java:656) io.netty.handler.codec.xml.XmlFrameDecoder.extractFrame(XmlFrameDecoder.java:198) io.netty.handler.codec.xml.XmlFrameDecoder.decode(XmlFrameDecoder.java:174) io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:227) io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:140) io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:74) io.netty.channel.embedded.EmbeddedEventLoop.invokeChannelRead(EmbeddedEventLoop.java:142) io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:317) io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846) io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:176) io.netty.handler.codec.xml.XmlFrameDecoderTest.testDecodeWithXml(XmlFrameDecoderTest.java:147) io.netty.handler.codec.xml.XmlFrameDecoderTest.testDecodeWithTwoMessages(XmlFrameDecoderTest.java:133) ``` 从这里可以看出,是有泄露的。上面的堆栈信息只是贴了其中的一段。在完整的堆栈中可以看到自有的项目代码,包括具体的行数。标识的行数就是泄露的位置。 后面根据行数找到代码后,发现调用一个方法 ```java DataBufferUtils.retain(dataBuffer) ``` 看到这行代码,再结合这篇内容中的示例代码,瞬间就明白了 ```c ByteBuf buf = ctx.alloc().directBuffer(); // 只要变量能获取到,就说明是可达的,即计数是大于0的 assert buf.refCnt() == 1; buf.retain(); // 如果在逻辑中retain一下,会将引用计数再一次加1,即使后面调用了释放,也只是从2变为1,而不是变为0。 // 那么垃圾回收永远都不会回收这个对象,也就造成了内存泄漏 assert buf.refCnt() == 2; boolean destroyed = buf.release(); assert !destroyed; assert buf.refCnt() == 1; ``` 在程序中,只要使用到变量,就说明是已达的,不然你是不会使用到的。那么就说明其引用计数是大于0的。那么如果现在主动去retain()就会将引用计数再次增加1,即使后面调用release方法,也只是从2变为1,并不是0,所以不会被回收,也就是一直占用着。这也就解释了为什么内存会逐步上升直到资源消耗完。 ### 资源不足时的其他表现 [Section titled “资源不足时的其他表现”](#资源不足时的其他表现) 在排查问题的过程中,有很多其他的表现,在当时都立马解释了,下面做一个分享 ##### 网关的Prometheus监控为什么会存在断点 [Section titled “网关的Prometheus监控为什么会存在断点”](#网关的prometheus监控为什么会存在断点) * 网关重启,重启需要时间,所以在重启的时间段内无数据,故会造成断点,呈现出来的数据就是不连续 * 网关资源枯竭,可能导致无法上报数据 ##### 在网关Error日志中,除了feign调用的异常外,还有其他异常,正常情况下应该是没有的 [Section titled “在网关Error日志中,除了feign调用的异常外,还有其他异常,正常情况下应该是没有的”](#在网关error日志中除了feign调用的异常外还有其他异常正常情况下应该是没有的) 因为资源枯竭,会导致程序无法正常处理业务,故会出现类似的错误 > 在排查这些问题时,其实很容易被这些“周边”问题带偏。用通俗的话来讲,就是”病急乱投医”,没有找到真正的病因,就会盲目的去试,从而浪费了大量的时间和精力。 ### 最后 [Section titled “最后”](#最后) 技术问题排查和业务问题排查是两个不同的方向。业务问题排查只需要跟着代码一步一步走就OK,实在不行还可以和产品、测试沟通。总之,有很多途径能够获取信息来辅助判断。技术问题的排查,绝大部分是在学习和探索,对于知识面的广度有一定的要求,因为思维要足够的发散。同时,也需要对某一块的技术有一定的聚焦,这是解决问题的核心能力。所以现在可以理解为啥有很多专家了吧,例如Java专家、Redis专家等,因为他们可以在有限的时间内解决一些核心问题。我以前就不太理解为啥有技术专家,现在我理解了 **最最最**后,贴一下优化的结果  # Spring Cloud Gateway Reactive > Spring Cloud Gateway Reactive ## 背景 [Section titled “背景”](#背景) 之前网关在遭遇流量洪峰时会重启 ## 分析 [Section titled “分析”](#分析) 经过AI分析得出原因是因为网关的过滤器逻辑中使用了同步逻辑导致。因为Spring Cloud Gateway 底层是基于 **Netty** 和 **Reactor 异步非阻塞模型** 构建的,如果在过滤器中使用了同步调用，会阻塞 Reactor 的工作线程（通常称为 Event Loop 线程）。一旦Reactor的工作线程被阻塞会导致以下问题: * 整个事件循环被挂起，不能继续处理其他请求 * 吞吐量下降，响应变慢，网关处理能力大幅降低 * JVM 的 GC 压力加大。系统负载升高 因为不能处理其他请求,k8s的健康检查探针探测到服务异常,就会杀死网关服务。 #### 阻塞代码分析方法 [Section titled “阻塞代码分析方法”](#阻塞代码分析方法) 借助开源项目 [BlockHound](https://github.com/reactor/BlockHound) 来检查阻塞代码。 [BlockHound文档](https://github.com/reactor/BlockHound/blob/master/docs/quick_start.md)  使用BlockHound检测出了项目中主要是同步Redis阻塞了工作线程 ## 优化方案 [Section titled “优化方案”](#优化方案) 1. **主要**: 同步代码修改为响应式，使用ReactiveRedis来替代同步Redis 2. **次要**: 移除无效代码,减少无效的网络请求 3. 代码整理。移除无效代码,减少过滤器中的无效逻辑调用。例如: 从请求中解析相关用户信息,最后却什么也不做、请求耗时统计等 #### 依赖 [Section titled “依赖”](#依赖) 响应式Redis核心依赖 ```xml org.springframework.boot spring-boot-starter-data-redis-reactive ``` ## 压测方案 [Section titled “压测方案”](#压测方案) 因为需要压测网关本身优化效果,需要消除下游服务对网关的测试结果的影响,所以让请求在网关内部闭环，不涉及其他服务。 #### 实现 [Section titled “实现”](#实现) ```java package com.moatkon; import java.nio.charset.StandardCharsets; import org.springframework.cloud.gateway.filter.GatewayFilterChain; import org.springframework.cloud.gateway.filter.GlobalFilter; import org.springframework.core.Ordered; import org.springframework.http.HttpStatus; import org.springframework.stereotype.Component; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Mono; @Component public class MoatkonEndpointFilter implements GlobalFilter, Ordered { @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { String path = exchange.getRequest().getURI().getPath(); if ("/dummy".equals(path)) { byte[] data = "OK".getBytes(StandardCharsets.UTF_8); exchange.getResponse().setStatusCode(HttpStatus.OK); exchange.getResponse().getHeaders().setContentLength(data.length); return exchange.getResponse().writeWith(Mono.just(exchange.getResponse() .bufferFactory().wrap(data))); } return chain.filter(exchange); } @Override public int getOrder() { return -1; // 保证早期执行 } } ``` ```java package com.moatkon; import org.springframework.cloud.gateway.route.RouteLocator; import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder; import org.springframework.context.annotation.Bean; import org.springframework.stereotype.Component; @Component public class MoatkonRouteLocator { @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("dummy_test", r -> r .path("/dummy") .filters(f -> f .addResponseHeader("X-Test", "gateway") ) .uri("no://backend")) // 注意：使用一个不会被解析的uri .build(); } } ``` ### 压测环境 [Section titled “压测环境”](#压测环境) * 测试环境 、 2个网关节点 * 压测时间选择在晚上,测试环境流量少。(公司没有压测环境…有压测环境就不用这么麻烦了) ### 压测脚本 [Section titled “压测脚本”](#压测脚本) 为了方便测试不同并发下的网关表现,写了一个脚本,方便数据收集与处理。 * 压测工具使用ab * 固定请求总数 创建请求数据文件 ```sh echo '{"hello":"Hello World"}' > post_data.json ``` 压测脚本——AI生成的 ```sh #!/bin/bash # 响应式优势测试策略 - 带错误处理版本 # 目标：找到响应式Redis相比同步Redis的性能拐点 TOKEN="Authorization: 自定义token" POST_DATA="post_data.json" # 固定总请求数，测试不同并发级别的性能 TOTAL_REQUESTS=8000 ## 压测 URL="http://moatkon-gateway-test.com/dummy" GATEWAY_HOST="moatkon-gateway-test" GATEWAY_PORT="80" # 同步redis RESULT_FILE="k8s_reactive_performance_test_sync.log" # 响应式redis # RESULT_FILE="k8s_reactive_performance_test_reactive.log" echo "响应式Redis性能测试开始..." | tee $RESULT_FILE echo "测试时间: $(date)" | tee -a $RESULT_FILE echo "========================================" | tee -a $RESULT_FILE # 测试函数 - 增强错误处理 run_test() { concurrency=$1 requests=$2 test_name=$3 echo "[$test_name] 并发: $concurrency, 请求: $requests" | tee -a $RESULT_FILE # 运行压测 echo "🚀 开始压测..." | tee -a $RESULT_FILE result=$(ab -n $requests -c $concurrency -T "application/json" -H "$TOKEN" -p $POST_DATA $URL 2>&1) ab_exit_code=$? # 检查ab命令执行结果 if [ $ab_exit_code -ne 0 ]; then echo "❌ 压测执行失败 (退出码: $ab_exit_code)" | tee -a $RESULT_FILE echo "错误信息:" | tee -a $RESULT_FILE echo "$result" | grep -E "(apr_socket_recv|Connection refused|Connection timed out|failed|error)" | tee -a $RESULT_FILE return 1 fi # 提取关键指标 qps=$(echo "$result" | grep "Requests per second" | awk '{print $4}') avg_time=$(echo "$result" | grep "Time per request" | head -1 | awk '{print $4}') failed=$(echo "$result" | grep "Failed requests" | awk '{print $3}') p95_time=$(echo "$result" | grep "95%" | awk '{print $2}') connect_errors=$(echo "$result" | grep "Connect:" | awk '{print $2}') # 检查是否有严重错误 if [ ! -z "$connect_errors" ] && [ "$connect_errors" -gt 0 ]; then echo "⚠️ 连接错误: $connect_errors 个" | tee -a $RESULT_FILE fi if [ ! -z "$failed" ] && [ "$failed" -gt 0 ]; then failure_rate=$(echo "scale=2; $failed * 100 / $requests" | bc 2>/dev/null || echo "N/A") echo "⚠️ 失败请求: $failed (${failure_rate}%)" | tee -a $RESULT_FILE fi # 记录结果 if [ ! -z "$qps" ] && [ ! -z "$avg_time" ]; then echo " ✅ QPS: $qps" | tee -a $RESULT_FILE echo " ✅ 平均响应时间: ${avg_time}ms" | tee -a $RESULT_FILE echo " 📊 95%响应时间: ${p95_time}ms" | tee -a $RESULT_FILE echo " 📊 失败请求: $failed" | tee -a $RESULT_FILE else echo "❌ 无法解析测试结果" | tee -a $RESULT_FILE echo "完整输出:" | tee -a $RESULT_FILE echo "$result" | tee -a $RESULT_FILE return 1 fi echo " ---" | tee -a $RESULT_FILE return 0 } # 阶段1：低并发基准测试 echo "📊 阶段1：低并发基准测试 (总请求数: $TOTAL_REQUESTS)" | tee -a $RESULT_FILE run_test 10 $TOTAL_REQUESTS "低并发基准" || echo "⚠️ 低并发测试失败" sleep 3 run_test 20 $TOTAL_REQUESTS "低并发基准" || echo "⚠️ 低并发测试失败" sleep 3 run_test 50 $TOTAL_REQUESTS "低并发基准" || echo "⚠️ 低并发测试失败" sleep 5 # 阶段2：中等并发测试（响应式开始显现优势） echo "📊 阶段2：中等并发测试 (总请求数: $TOTAL_REQUESTS)" | tee -a $RESULT_FILE # run_test 100 $TOTAL_REQUESTS "中等并发" || echo "⚠️ 中等并发测试失败" # sleep 5 run_test 200 $TOTAL_REQUESTS "中等并发" || echo "⚠️ 中等并发测试失败" sleep 5 run_test 300 $TOTAL_REQUESTS "中等并发" || echo "⚠️ 中等并发测试失败" sleep 8 # 阶段3：高并发测试（响应式优势明显） echo "📊 阶段3：高并发测试 (总请求数: $TOTAL_REQUESTS)" | tee -a $RESULT_FILE run_test 500 $TOTAL_REQUESTS "高并发" || echo "⚠️ 高并发测试失败，可能接近服务极限" sleep 10 run_test 800 $TOTAL_REQUESTS "高并发" || echo "⚠️ 高并发测试失败，可能接近服务极限" sleep 10 run_test 1000 $TOTAL_REQUESTS "高并发" || echo "⚠️ 高并发测试失败，可能接近服务极限" sleep 10 # 阶段4：极高并发测试（找到性能瓶颈） echo "📊 阶段4：极高并发测试 (总请求数: $TOTAL_REQUESTS)" | tee -a $RESULT_FILE echo "⚠️ 开始极限测试，请监控服务状态..." | tee -a $RESULT_FILE run_test 2000 $TOTAL_REQUESTS "极高并发" || echo "❌ 极高并发测试失败，已达到服务极限" sleep 15 run_test 3000 $TOTAL_REQUESTS "极高并发" || echo "❌ 极高并发测试失败，已达到服务极限" sleep 15 run_test 4000 $TOTAL_REQUESTS "极高并发" || echo "❌ 极高并发测试失败，已达到服务极限" echo "测试完成！详细结果请查看: $RESULT_FILE" | tee -a $RESULT_FILE echo "测试结束时间: $(date)" | tee -a $RESULT_FILE ``` ## 压测结果 [Section titled “压测结果”](#压测结果) | 并发数 | QPS（同步） | 平均响应时间（同步） | 95%响应时间（同步） | QPS（响应式） | 平均响应时间（响应式） | 95%响应时间（响应式） | | ---- | -------- | ---------- | ----------- | -------- | ----------- | ------------ | | 10 | 71.2 | 140.445 | 485 | 176.93 | 56.519 | 157 | | 20 | 60.18 | 332.329 | 986 | 243.52 | 82.128 | 246 | | 50 | 失败 | 失败 | 失败 | 252.08 | 198.353 | 508 | | 100 | 72.43 | 1380.56 | 4332 | 240.29 | 416.168 | 814 | | 200 | 74.3 | 2691.857 | 7655 | 309.46 | 646.285 | 1112 | | 300 | 71.21 | 4212.883 | 10943 | 133.24 | 2251.537 | 1149 | | 500 | 68.26 | 7324.498 | 17332 | 455.8 | 1096.98 | 1268 | | 800 | 74.61 | 10722.655 | 24476 | 598.16 | 1337.427 | 2115 | | 1000 | 73.73 | 13563.109 | 31676 | 682.45 | 1465.309 | 1649 | | 2000 | 186.24 | 10739.042 | 29671 | 121.05 | 16522.11 | 4578 | | 3000 | 失败(服务宕机) | 失败(服务宕机) | 失败(服务宕机) | 1612.74 | 1860.185 | 4137 | | 4000 | 失败(服务宕机) | 失败(服务宕机) | 失败(服务宕机) | 1855.99 | 2155.183 | 2489 | * 阻塞式代码在3000,4000并发都失败时网关服务重启了,和之前线上表现一致。 * 如果要体现响应式Redis的优势必须上大并发,如果并发过低,同步和异步的差异不明显甚至会出现异步性能低于同步的情况(这个是我遇到的实际情况,花了点时间查了资料) #### 图表展示 [Section titled “图表展示”](#图表展示) > **图表说明：** > > * X轴表示并发数 > * 实线表示同步实现的性能数据 > * 虚线表示响应式实现的性能数据 > * 值为0的测试点表示测试失败 > * QPS越高表示性能越好，响应时间越低表示性能越好    ## 经验 [Section titled “经验”](#经验) 响应式的优势在高并发、I/O密集型场景下才明显。如果并发不高,同步模式的线程池（通常几十到几百个线程）完全够用 Note 为什么低并发(例如10个)下响应式QPS更低： 1. 响应式编程的开销：在低并发时，响应式框架的异步调度、事件循环、回调管理等开销比直接同步调用更大 2. 没有达到响应式的优势区间：响应式的优势在于高并发时不阻塞线程，但10个并发远未达到线程池瓶颈 响应式Redis的优势体现在： * 高并发场景（通常>100并发）：当同步方式的线程池耗尽时，响应式仍能保持性能 * I/O密集型操作：Redis操作本身就是I/O密集型，响应式在这种场景下优势明显 * 资源利用率：响应式使用更少的线程处理更多请求 # Spring Cloud Gateway 网关压测 > Spring Cloud Gateway 网关压测 #### 背景 [Section titled “背景”](#背景) 公司的API网关出现了重启 #### 排查经历 [Section titled “排查经历”](#排查经历) 1. 确认业务层面有无促销等场景造成的流量暴增 `无` 2. 确认程序上有无疯狂刷接口的行为 `无` 3. 确认流量分配是否均衡 `无` 4. 确认最近有无上线行为 `无` #### 排查结果 [Section titled “排查结果”](#排查结果) 以上排查都无果 #### 尝试复现 [Section titled “尝试复现”](#尝试复现) 压测场景: 1. 写一个超时接口,超时时间40s,大于网关全局超时,模拟连接被hold的场景 2. 压测监控检测接口。因为k8s健康监测功能,会监测这个接口来判定服务是否健康。不健康则会重启pod 使用Jmeter来压测网关。使用6000个的线程来并发压测网关,可以复现 #### 解决方案 [Section titled “解决方案”](#解决方案) 修改配置,新增绿色部分 ```diff spring: cloud: discovery: +client: +health-indicator: +enabled: false gateway: httpclient: connect-timeout: 2000 -response-timeout: 30s +response-timeout: 6s +pool: +max-idle-time: PT10S #线程最大空闲时间,超时回收 +eviction-interval: PT30S #定期回收频率 routes: - id: moatkon uri: lb://moatkon-service predicates: - Path=/moatkon/** +metadata: +connect-timeout: 5000 +response-timeout: 30000 management: +endpoint: +health: +enabled: true +show-details: always +health: +defaults: +enabled: false endpoints: web: exposure: include: ["*"] ``` 在启动应用时添加JVM参数: ```sh -Dreactor.netty.pool.leasingStrategy=lifo ``` #### 压测结果 [Section titled “压测结果”](#压测结果) 结果显示,6000并发持续压测3h+无重启现象 # Spring Cloud Gateway网关使用规范 > Spring Cloud Gateway网关使用规范 ### 1. 引言 [Section titled “1. 引言”](#1-引言) 本文档旨在为公司内部所有基于Spring Cloud Gateway 3.0.3版本进行微服务网关开发与运维的团队和个人，提供一套统一、专业的技术与业务规范。本规范主要侧重于通过**配置文件 (YAML/Properties)** 进行网关的路由、过滤器及其他高级功能的配置。 遵循本规范有助于确保网关系统在微服务架构中作为流量入口的核心地位，实现其高可用性、高性能、可维护性、可扩展性及高安全性，有效承载和分发请求。 ### 2. 网关概述 [Section titled “2. 网关概述”](#2-网关概述) Spring Cloud Gateway 是 Spring 生态系统中的一个现代化、响应式、非阻塞式的 API 网关解决方案。 它构建于 Spring Framework 5、Project Reactor 和 Spring Boot 2 之上，旨在为微服务架构提供灵活的路由配置、强大的过滤器链以及出色的性能表现。其核心设计理念是：通过谓词（Predicates）匹配请求，通过过滤器（Filters）对请求进行预处理或后处理，最终将请求路由到目标服务。 ### 3. 技术栈与版本要求 [Section titled “3. 技术栈与版本要求”](#3-技术栈与版本要求) 为确保网关服务的兼容性、稳定性以及与配置文件优先策略的良好配合，请严格遵循以下技术栈与版本要求： * **Spring Cloud Gateway Version:** `3.0.3` * **Spring Boot Version:** `2.4.6` * **Spring Cloud Version:** `2020.0.x` (与 Spring Boot 2.4.x 兼容的最新稳定版本，如 `2020.0.6`) * **JDK Version:** `1.8+` * **构建工具:** Maven (`3.6+`) 或 Gradle (`6.x+`) ### 4. Spring Cloud Gateway 核心使用规范 [Section titled “4. Spring Cloud Gateway 核心使用规范”](#4-spring-cloud-gateway-核心使用规范) #### 4.1. 路由定义 (Routes) [Section titled “4.1. 路由定义 (Routes)”](#41-路由定义-routes) 路由是网关的核心组成部分，定义了如何将客户端请求匹配并转发到后端的微服务实例。 ##### 4.1.1. 路由配置方式 (优先使用 YAML) [Section titled “4.1.1. 路由配置方式 (优先使用 YAML)”](#411-路由配置方式-优先使用-yaml) 根据公司要求，我们优先采用 YAML 文件进行路由定义。这种方式配置直观、易于部署，但也需注意配置的复杂性和可读性。Java DSL 可作为复杂业务逻辑或动态路由的补充，但在此规范中不作为主要推荐方式。 **a) YAML 配置 (推荐)** 在 `application.yml`文件中定义路由。 application.yml ```yml spring: cloud: gateway: routes: # ========================= 示例路由一：路径匹配路由 ========================= # id: 定义路由的唯一标识符，应具有业务含义，遵循命名规范。 # uri: 目标URI，lb:// 表示通过服务发现（如Eureka）进行负载均衡到 USER-SERVICE 服务。 # predicates: 谓词列表，匹配所有以 /user-api/ 开头的请求。 # filters: 应用于此路由的局部过滤器，这里移除了路径中的 /user-api/ 前缀。 - id: user_service_api_route uri: lb://USER-SERVICE predicates: - Path=/user-api/** filters: - StripPrefix=1 # 移除第一个路径段 '/user-api' # ========================= 示例路由二：组合谓词路由 ========================= # host: Predicate 谓词，匹配请求的 Host 头为 api.company.com。 # Method: 组合谓词，要求请求方法为 GET。 # uri: 目标服务为 HTTPBIN (一个常用的测试API服务)。 - id: httpbin_get_route uri: http://httpbin.org:80 predicates: - Host=api.company.com - Method=GET # ========================= 示例路由三：带断路器和降级的路由 ========================= # path: 匹配所有以 /slow-service/ 开头的请求。 # filters: 应用断路器过滤器。 # - name: CircuitBreaker (过滤器工厂名称) # - args: 断路器配置参数 # name: slowServiceBreaker (断路器名称，用于监控和配置 Resilience4J) # fallbackUri: forward:/fallback/slow-service (当断路器打开或发生错误时，请求转发到的降级URI) # uri: 目标URI，负载均衡到 SLOW-SERVICE 服务。 - id: slow_service_circuitbreaker_route uri: lb://SLOW-SERVICE predicates: - Path=/slow-service/** filters: - name: CircuitBreaker args: name: slowServiceBreaker fallbackUri: forward:/fallback/slow-service # 转发到网关内部的 /fallback/slow-service 路径 # ========================= 示例路由四：限流路由 (结合 Java Bean) ========================= # path: 匹配所有以 /rate-limit-example/ 开头的请求。 # filters: 应用请求限流器。 # - name: RequestRateLimiter (过滤器工厂名称) # - args: 限流配置参数 # redis-rate-limiter.replenishRate: 10 (每秒允许的令牌数) # redis-rate-limiter.burstCapacity: 20 (令牌桶的容量) # key-resolver: '#{@ipKeyResolver}' (限流的维度，引用 Spring Context 中的 @ipKeyResolver Bean) - id: rate_limit_route uri: lb://ANOTHER-SERVICE predicates: - Path=/rate-limit-example/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20 key-resolver: '#{@ipKeyResolver}' # 引用 Java 中定义的 KeyResolver Bean ``` **配套 Java Bean (针对 `KeyResolver` 和 `FallbackController`)** 尽管路由主要使用 YAML，但某些高级过滤器（如 `RequestRateLimiter`）的参数可能需要引用 Spring Context 中的 Java Bean。此外，`fallbackUri` 通常会转发到网关内部的 Spring Controller。 ```java import org.springframework.cloud.gateway.filter.ratelimit.KeyResolver; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import reactor.core.publisher.Mono; @Configuration public class GatewayBeansConfig { /** * 定义限流Key的解析器，这里基于客户端IP地址进行限流。 * 该 Bean 将通过 SpEL 表达式 '#{@ipKeyResolver}' 在 YAML 中引用。 * 实际应用中可以根据用户ID、API路径等定义 KeyResolver。 * * @return KeyResolver 实例。 */ @Bean public KeyResolver ipKeyResolver() { return exchange -> Mono.just( exchange.getRequest().getRemoteAddress() != null ? exchange.getRequest().getRemoteAddress().getAddress().getHostAddress() : "unknown"); } /** * 网关内部的降级控制器，用于处理来自断路器或错误路由的转发请求。 */ @RestController public static class GatewayFallbackController { @RequestMapping("/fallback/slow-service") public Mono slowServiceFallback() { return Mono.just("{\"code\": 50001, \"message\": \"服务繁忙，请稍后再试。\"}"); } @RequestMapping("/fallback/payment-service") public Mono paymentServiceFallback() { return Mono.just("{\"code\": 50002, \"message\": \"支付服务暂时不可用，请联系客服。\"}"); } @RequestMapping("/fallback/default") public Mono defaultFallback() { return Mono.just("{\"code\": 50000, \"message\": \"系统暂时不可用。\"}"); } } } ``` ##### 4.1.2. 路由ID命名规范 [Section titled “4.1.2. 路由ID命名规范”](#412-路由id命名规范) * **唯一性:** 每个路由 `id` 必须在网关应用中唯一。 * **可读性与业务含义:** 使用小写字母、数字和中划线 (`-`) 组成，清晰表达路由所代理的业务域或服务。 * **格式:** 推荐 `[业务域/服务名]_[功能/API前缀]_route` * **正例:** `user_service_profile_api_route`, `order_management_query_route`, `admin_dashboard_summary_route` * **反例:** `route1`, `my_api`, `test_route` ##### 4.1.3. URI 规范 [Section titled “4.1.3. URI 规范”](#413-uri-规范) * **服务发现 (推荐):** `lb://{SERVICE_ID}` * 示例: lb://USER-SERVICE * 这是微服务架构中的标准做法，利用 Spring Cloud LoadBalancer 进行客户端负载均衡。 * **直连 HTTP/HTTPS (特殊场景):** 或 * 示例: * 仅用于代理非注册到服务发现的服务或外部API。 * **内部转发 (Internal Forward):** forward:/path * 示例: forward:/fallback/default * 用于将请求转发到网关内部的另一个 Controller 或处理器，不进行外部 HTTP 调用。常用于统一错误处理或降级逻辑。 * **WebSocket (WebSocket):** ws\://host:port 或 wss\://host:port * 示例: ws\://websocket-service.company.com * 用于代理 WebSocket 连接。 #### 4.2. 谓词 (Predicates) [Section titled “4.2. 谓词 (Predicates)”](#42-谓词-predicates) 谓词是路由规则的一部分，用于判断一个请求是否应该被当前的路由处理。多个谓词可以通过在 YAML 中列出进行逻辑与 (AND) 组合。 ##### 4.2.1. 常用内置谓词详解 (YAML 配置) [Section titled “4.2.1. 常用内置谓词详解 (YAML 配置)”](#421-常用内置谓词详解-yaml-配置) * **`Path` 谓词:** * 用途: 根据请求路径匹配。 * 语法: ```yml - Path=/users/{id} 或 - Path=/files/** ``` * 支持 Ant 风格路径匹配 (`*`, `**`, `?`) 和 URI 模板 (`{segment}`)。 * **注意事项:** 路径匹配的顺序很重要，更精确的路径规则（例如 `/users/detail/{id}`）应在更宽泛的规则（例如 `/users/**`）之前定义，以避免路由混淆。 * **`Method` 谓词:** * 用途: 根据 HTTP 请求方法 (GET, POST, PUT, DELETE, etc.) 匹配。 * 语法:  ```yml - Method=GET,POST (匹配 GET 或 POST 请求) ``` * **`Host` 谓词:** * 用途: 根据请求头中的 `Host` 字段匹配域名。 * 语法:  ```yml - Host=**.company.com 或 - Host=api.my-domain.com ``` * 支持 Ant 风格模式匹配。 * **`Header` 谓词:** * 用途: 根据请求头中的特定字段及其值匹配。 * 语法:  ```yml - Header=X-Requested-With, XMLHttpRequest (匹配 X-Requested-With 头且值为 XMLHttpRequest) ``` * 支持正则表达式 (`- Header=X-Custom-Header, .+` 匹配非空 `X-Custom-Header` 头)。 * **`Query` 谓词:** * 用途: 根据请求参数 (Query Parameters) 匹配。 * 语法:  ```yml - Query=param1 (匹配存在 param1 参数), - Query=param2, value2 (匹配 param2 且值为 value2) ``` * 支持正则表达式。 * **`Cookie` 谓词:** * 用途: 根据请求中的 Cookie 匹配。 * 语法:  ```yml - Cookie=name, value (匹配名为 name 且值为 value 的 Cookie) ``` * 支持正则表达式。 * **`After`/`Before`/`Between` 谓词:** * 用途: 基于时间戳的谓词，限制请求只能在特定时间段内被路由。 * 语法:  ```yml - After=2025-06-01T12:00:00+08:00[Asia/Shanghai] (ISO-8601 格式)。 ``` * 常用于灰度发布或特定时间段的活动。 * **`RemoteAddr` 谓词:** * 用途: 根据客户端的 IP 地址匹配。 * 语法:  ```yml - RemoteAddr=192.168.1.1/24 (支持 CIDR 表示法) ``` * 用于 IP 白名单/黑名单。 ##### 4.2.2. 谓词组合逻辑 [Section titled “4.2.2. 谓词组合逻辑”](#422-谓词组合逻辑) 在 YAML 中，多个 `predicates` 项之间默认是逻辑与 (AND) 关系。这意味着所有列出的谓词都必须满足才能匹配路由。 ```yml - id: complex_predicate_route uri: lb://ITEM-SERVICE predicates: - Path=/v1/items/** # 路径匹配 - Method=GET,POST # 方法为 GET 或 POST - Header=X-Auth-Token, .+ # 必须存在 X-Auth-Token 头 (正则表达式匹配非空) - Query=status, active # 查询参数 status=active ``` #### 4.3. 过滤器 (Filters) [Section titled “4.3. 过滤器 (Filters)”](#43-过滤器-filters) 过滤器是网关对请求和响应进行修改的机制。它们可以应用于单个路由（局部过滤器）或所有路由（全局过滤器）。 ##### 4.3.1. 常用内置 GatewayFilterFactories (YAML 配置) [Section titled “4.3.1. 常用内置 GatewayFilterFactories (YAML 配置)”](#431-常用内置-gatewayfilterfactories-yaml-配置) Spring Cloud Gateway 提供了大量开箱即用的 `GatewayFilterFactory`，通过它们可以轻松实现请求/响应的修改。在 YAML 中，过滤器通过 `name` 字段指定工厂名称，`args` 字段提供参数。 * **`AddRequestHeader`/`AddResponseHeader`**: 添加请求/响应头。 * 语法:  ```yml - AddRequestHeader=X-Tenant-Id, my_tenant (添加请求头) ``` * 语法:  ```yml - AddResponseHeader=X-Gateway-Processed, true (添加响应头) ``` * **`RemoveRequestHeader`/`RemoveResponseHeader`**: 移除请求/响应头。 * 语法:  ```yml - RemoveRequestHeader=Authorization (移除请求头) ``` * **`RewritePath`**: 重写请求路径。 * 语法:  ```yml - RewritePath=/api/(?.*), /${segment} (使用正则表达式重写路径) ``` * **`PrefixPath`**: 给请求路径添加前缀。 * 语法:  ```yml - PrefixPath=/internal (/api/users 变为 /internal/api/users) ``` * **`StripPrefix`**: 剥离请求路径的前缀。 * 语法:  ```yml - StripPrefix=1 (剥离第一段路径，如 /api/users 变为 /users) ``` * **`Retry`**: 重试机制。 * 语法: ```yml - name: Retry args: retries: 3 # 最大重试次数 statuses: INTERNAL_SERVER_ERROR # 触发重试的 HTTP 状态码 methods: GET # 触发重试的 HTTP 方法 ``` * **注意事项:** 仅对幂等操作（GET, PUT, DELETE）使用，POST 通常不幂等，需谨慎。 * **`CircuitBreaker`**: 断路器。 * 语法: ```yml - name: CircuitBreaker args: name: myBreaker # 断路器名称 fallbackUri: forward:/fallback # 降级 URI addStatusCode: 500, 502 # 额外触发熔断的状态码 ``` * **`RequestRateLimiter`**: 请求限流器。 * 语法: ```yml - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 # 每秒补充令牌数 redis-rate-limiter.burstCapacity: 20 # 桶容量 key-resolver: '#{@ipKeyResolver}' # 限流维度，引用 Java Bean ``` * **`RequestSize`**: 限制请求体大小。 * 语法:  ```yml - RequestSize=10485760 (限制为 10MB，单位字节) ``` ##### 4.3.2. 局部过滤器 (GatewayFilter) [Section titled “4.3.2. 局部过滤器 (GatewayFilter)”](#432-局部过滤器-gatewayfilter) 在路由定义中 `filters` 下方直接列出，仅作用于当前定义的路由。 ```yml - id: specific_route uri: lb://PRIVATE-SERVICE predicates: - Path=/private/** filters: - StripPrefix=1 - AddRequestHeader=X-Correlation-ID, my-correlation-id # 硬编码值，也可以通过 SpEL 动态生成 - AddResponseHeader=X-Gateway-Processed, true ``` ##### 4.3.3. 全局过滤器 (GlobalFilter) [Section titled “4.3.3. 全局过滤器 (GlobalFilter)”](#433-全局过滤器-globalfilter) 全局过滤器应用于所有路由，通过实现 `GlobalFilter` 接口和 `@Order` 注解或实现 `Ordered` 接口来定义。这部分需要通过 Java 代码实现。 ```java import org.springframework.cloud.gateway.filter.GatewayFilterChain; import org.springframework.cloud.gateway.filter.GlobalFilter; import org.springframework.core.Ordered; import org.springframework.stereotype.Component; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Mono; import org.slf4j.Logger; import org.slf4j.LoggerFactory; @Component public class GlobalRequestLoggingFilter implements GlobalFilter, Ordered { private static final Logger log = LoggerFactory.getLogger(GlobalRequestLoggingFilter.class); @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { // 请求进入网关时的前置处理逻辑 String requestPath = exchange.getRequest().getPath().value(); String method = exchange.getRequest().getMethodValue(); log.info("Incoming Request: {} {}", method, requestPath); long startTime = System.currentTimeMillis(); return chain.filter(exchange).then(Mono.fromRunnable(() -> { // 请求经过下游服务处理后，响应返回客户端时的后置处理逻辑 long duration = System.currentTimeMillis() - startTime; int statusCode = exchange.getResponse().getStatusCode() != null ? exchange.getResponse().getStatusCode().value() : 0; log.info("Outgoing Response: {} {} - Status: {} - Duration: {}ms", method, requestPath, statusCode, duration); })); } @Override public int getOrder() { // 优先级设置，数字越小优先级越高。 // 这里设置为最高优先级，确保日志在所有其他过滤器之前和之后执行。 return Ordered.HIGHEST_PRECEDENCE; // -2147483648 } } ``` ##### 4.3.4. 过滤器执行顺序 [Section titled “4.3.4. 过滤器执行顺序”](#434-过滤器执行顺序) 过滤器按照 `Ordered` 接口定义的 `order` 值（数字越小，优先级越高）进行执行。Spring Cloud Gateway 内部的过滤器也有其默认顺序，例如 `LoadBalancerClientFilter` 通常在路由之前执行，`NettyRoutingFilter` 通常在最后执行以进行实际的HTTP转发。 * 自定义全局过滤器应谨慎设置 `order` 值，以确保其在期望的阶段执行。 * 局部过滤器在全局过滤器之后执行。 #### 4.4. 负载均衡 (Load Balancing) [Section titled “4.4. 负载均衡 (Load Balancing)”](#44-负载均衡-load-balancing) Spring Cloud Gateway 通过集成 `Spring Cloud LoadBalancer` 实现客户端负载均衡。 * 当 URI 使用 `lb://{SERVICE_ID}` 形式时，`LoadBalancerClientFilter` 会拦截请求，并通过服务发现机制（如 Eureka, Nacos, Consul）获取 `SERVICE_ID` 对应的服务实例列表。 * 然后，它会使用负载均衡策略（如轮询、随机、响应时间加权等）选择一个健康的实例，并将请求转发到该实例。 * 默认的负载均衡策略是 `RoundRobinLoadBalancer`。可以通过配置或实现 `ReactorServiceInstanceLoadBalancer` 接口来自定义负载均衡策略。 #### 4.5. 服务注册与发现集成 [Section titled “4.5. 服务注册与发现集成”](#45-服务注册与发现集成) Spring Cloud Gateway 能够无缝集成主流的服务注册与发现组件。只需添加相应的 Starter 依赖并在 `application.yml` 中配置服务注册中心地址： * **Eureka:** 添加 `spring-cloud-starter-netflix-eureka-client` 依赖并配置 Eureka Server 地址。 * **Nacos:** 添加 `spring-cloud-starter-alibaba-nacos-discovery` 依赖并配置 Nacos Server 地址。 * **Consul:** 添加 `spring-cloud-starter-consul-discovery` 依赖并配置 Consul Server 地址。 ```yml # application.yml 服务注册发现配置 (以 Nacos 为例) spring: cloud: nacos: discovery: server-addr: http://10.4.3.210:8848; namespace: 63b6732e-80fc-49c2-ac83-4b09e119d48c metadata: department: NR ``` 确保网关能够正确发现并获取下游服务的实例信息，这是 `lb://`URI 正常工作的基石。 ### 5. 业务规范 [Section titled “5. 业务规范”](#5-业务规范) 除了 Spring Cloud Gateway 本身的功能，为了确保网关在业务层面的统一性、可管理性和安全性，需要制定严格的业务规范。 #### 5.1. 路由规则 [Section titled “5.1. 路由规则”](#51-路由规则) ##### 5.1.1. 统一 API 前缀与服务域绑定 (强制) [Section titled “5.1.1. 统一 API 前缀与服务域绑定 (强制)”](#511-统一-api-前缀与服务域绑定-强制) 为实现 API 的标准化管理和清晰的职责划分，所有业务域的 API 必须通过网关暴露，并遵循统一的前缀规则。网关负责剥离这些外部前缀，将请求转发到后端服务。 ###### 通用开放 API: [Section titled “通用开放 API:”](#通用开放-api) * **外部访问路径:** `/api/{version}/{业务模块}/{资源}` * **目的:** 面向内部前端、移动App 或第三方合作伙伴的通用 API。 * **示例:** * 用户服务: `/api/v1/users/{id}` (网关剥离 `/api/v1/` 后转发至 `/users/{id}` 给 USER-SERVICE) * 商品服务: `/api/v2/products/{id}` (网关剥离 `/api/v2/` 后转发至 `/products/{id}` 给 PRODUCT-SERVICE) * **网关配置示例 (YAML):** ```yml - id: user_api_v1_route uri: lb://USER-SERVICE predicates: - Path=/api/v1/users/** filters: - StripPrefix=2 # 剥离 /api/v1 - id: product_api_v2_route uri: lb://PRODUCT-SERVICE predicates: - Path=/api/v2/products/** filters: - StripPrefix=2 # 剥离 /api/v2 ``` ###### 管理后台 API: [Section titled “管理后台 API:”](#管理后台-api) * **外部访问路径:** `/admin/{version}/{业务模块}/{资源}` * **目的:** 仅供内部运营管理平台访问的 API * **示例:** * 用户管理: `/admin/v1/user-management/list` (网关剥离 `/admin/v1/` 后转发至 `/user-management/list` 给 ADMIN-SERVICE) * **网关配置示例 (YAML):** ```yaml - id: admin_user_management_route uri: lb://ADMIN-SERVICE predicates: - Path=/admin/v1/user-management/** filters: - StripPrefix=2 # 剥离 /admin/v1 ``` ###### 内部服务间 API (特殊情况) [Section titled “内部服务间 API (特殊情况)”](#内部服务间-api-特殊情况) * **外部访问路径:** `/internal/{service-name}/{资源}` * **目的:** 仅供公司内部其他微服务通过网关代理访问，不对外暴露。需配合 IP 白名单或其他安全机制。 * **示例:** `/internal/inventory-service/deduct-stock` * **网关配置示例 (YAML):** ```yml - id: internal_inventory_route uri: lb://INVENTORY-SERVICE predicates: - Path=/internal/inventory-service/** - RemoteAddr=10.0.0.0/8,192.168.0.0/16 # 仅允许内网 IP 访问 filters: - StripPrefix=2 # 剥离 /internal/inventory-service ``` ###### 特定业务线 API: [Section titled “特定业务线 API:”](#特定业务线-api) * 对于特殊的业务线或合作伙伴集成，可以定义专属前缀，例如 `/crm/{version}/`, `/oms/{version}/`。 * 这需要与业务线负责人协商并明确约定。 ##### 5.1.2. API 版本控制 [Section titled “5.1.2. API 版本控制”](#512-api-版本控制) * **路径版本化 (推荐):** 在 API 路径中显式包含版本信息 (`/api/v1/resource`, `/api/v2/resource`)。这是最直观和易于理解的方式。 * **请求头版本化 (可选):** 通过自定义请求头 (`X-API-Version`) 来传递版本信息。 * **网关处理:** * 当采用路径版本化时，网关通过 `StripPrefix` 或 `RewritePath` 过滤器将版本信息剥离，转发给后端服务。 * 当采用请求头版本化时，网关可以根据请求头的值，结合 `Header` 谓词，将请求路由到不同版本的后端服务实例。 ##### 5.1.3. 错误路由与降级策略 [Section titled “5.1.3. 错误路由与降级策略”](#513-错误路由与降级策略) * 定义统一的全局错误处理路由，当后端服务不可用、熔断触发或发生特定 HTTP 错误时，将请求转发到网关内部的降级服务或统一的错误响应处理器。 * 结合 `CircuitBreaker` 过滤器的 `fallbackUri` 和 `ErrorWebExceptionHandler` 实现。 #### 5.2. 请求与响应处理规范 [Section titled “5.2. 请求与响应处理规范”](#52-请求与响应处理规范) ##### 5.2.1. 统一认证与授权 [Section titled “5.2.1. 统一认证与授权”](#521-统一认证与授权) * 网关是进行认证和授权的集中式入口，应在网关层面完成大部分安全校验。 * **认证 (Authentication):** * 通过全局过滤器集成 OAuth2、JWT、SSO 等认证机制。 * 认证成功后，从令牌中解析用户信息（如用户 ID、角色、租户 ID 等）。 * 将解析后的关键用户信息注入到请求头中（例如 `X-User-Id`, `X-User-Roles`），传递给下游微服务。 * **授权 (Authorization):** * 对于简单的权限校验，可以在网关层通过全局过滤器实现基于角色的访问控制 (RBAC) 或基于资源的访问控制 (ABAC)。 * 对于复杂的业务权限，网关进行初步校验后，将请求转发给下游服务，由下游服务进行更细粒度的业务授权。 * **禁止:** 严禁下游服务再次进行重复认证，下游服务仅需基于网关传递的认证信息进行授权校验。 ##### 5.2.2. 链路追踪 (Trace ID) [Section titled “5.2.2. 链路追踪 (Trace ID)”](#522-链路追踪-trace-id) * 所有进入网关的请求，必须通过全局过滤器生成并注入一个全局唯一的链路追踪 ID (例如 `X-B3-TraceId` 或 `X-Request-ID`)。 * 此 ID 必须在整个微服务调用链中透传，并通过日志系统记录，以便进行分布式链路追踪和故障排查。 * 推荐使用 Spring Cloud Sleuth 与 Zipkin/Jaeger 集成，它会自动处理 Trace ID 的生成与传递。 * **自定义实现示例 (参考 Section 4.3.3 GlobalFilter 示例)。** ##### 5.2.3. 敏感信息处理 [Section titled “5.2.3. 敏感信息处理”](#523-敏感信息处理) * **传输层加密:** 所有外部流量必须强制通过 HTTPS/TLS，确保数据传输的加密性。 * **请求体加密:** 对于包含敏感业务数据（如身份证号、银行卡号、密码等）的请求，建议在客户端进行加密，并在后端服务进行解密。网关在此过程中不应尝试解密或记录这些敏感信息。 * **日志脱敏:** 严禁在网关日志中记录任何敏感信息（如密码、API Key 等），必须进行脱敏处理。 ##### 5.2.4. CORS (跨域资源共享) 策略 [Section titled “5.2.4. CORS (跨域资源共享) 策略”](#524-cors-跨域资源共享-策略) * CORS 配置应在网关层面统一处理，避免各个微服务重复配置。 * 通过 `CorsWebFilter` 或在 `application.yml` 中配置 `spring.cloud.gateway.globalcors` 属性。 * **严格控制 `allowedOrigins`:** 仅允许已知的、合法的客户端域进行跨域访问。避免使用 `*`。 * **控制 `allowedMethods` 和 `allowedHeaders`:** 仅开放必需的 HTTP 方法和请求头。 ```yml # application.yml CORS配置示例 spring: cloud: gateway: globalcors: cors-configurations: '[/**]': # 针对所有路径 allowedOrigins: # 允许的源站列表 - "https://www.company.com" - "http://localhost:3000" allowedMethods: - GET - POST - PUT - DELETE - OPTIONS allowedHeaders: "*" # 允许所有请求头 allowCredentials: true # 允许发送Cookie maxAge: 3600 # 预检请求的缓存时间 (秒) ``` ### 5.3. 网关设计与操作限制 (强制) [Section titled “5.3. 网关设计与操作限制 (强制)”](#53-网关设计与操作限制-强制) 为了确保网关的极高性能、稳定性和职责单一性，所有网关的设计与操作必须严格遵守以下强制性限制： ##### 5.3.1. 禁止文件、图片等大文件上传下载代理 [Section titled “5.3.1. 禁止文件、图片等大文件上传下载代理”](#531-禁止文件图片等大文件上传下载代理) * **限制内容:** 网关不允许作为文件、图片、视频等大文件上传和下载的直接代理。所有涉及大文件传输的业务，必须绕过网关，直连独立的文件存储服务（如：MinIO、FastDFS、AWS S3、阿里云 OSS 等对象存储服务）或专用的文件服务器。 * **强制级别:** 强制 * **详细说明:** Spring Cloud Gateway 基于 Netty 和 Project Reactor 构建，是一个非阻塞、响应式架构。其核心优势在于处理高并发的短连接和轻量级请求转发。然而，大文件传输会长时间占用网关的连接和内存资源，即使是非阻塞的，也可能导致以下问题： * **资源耗尽:** 长时间的文件传输可能导致网关的连接池、内存或线程池资源被长时间占用，影响其他正常请求的处理，甚至引发 OOM（内存溢出）。 * **性能下降:** 大文件传输会增加网关的 I/O 负载和 CPU 消耗，降低整体的吞吐量和响应速度。 * **职责混淆:** 网关的主要职责是路由、认证、授权、限流、熔断等，而不是作为文件存储代理。将文件传输功能置于网关会使其职责变得复杂，不利于维护和扩展。 * **安全性考虑:** 文件传输链路若经过网关，可能增加额外的安全审计和漏洞暴露面。 * **替代方案:** * **上传:** 客户端直接将文件上传到文件存储服务，并将文件存储服务的 URL 或 ID 返回给业务服务，业务服务再将此信息存储到数据库。 * **下载:** 业务服务返回文件的下载 URL（指向文件存储服务），客户端直接从文件存储服务下载。在需要认证授权的场景下，可以生成带有时效性签名的下载 URL。 ##### 5.3.2. 禁止任何同步 IO 阻塞操作 [Section titled “5.3.2. 禁止任何同步 IO 阻塞操作”](#532-禁止任何同步-io-阻塞操作) * **限制内容:** 网关内部（包括自定义的 GlobalFilter、GatewayFilter 或任何扩展组件）严禁进行任何形式的同步 IO 阻塞操作（如传统的 `[java.io](http://java.io/)` 操作、JDBC 同步数据库访问、同步的 HTTP 客户端调用等）。 * **强制级别:** 强制 * **详细说明:** Spring Cloud Gateway 的核心设计哲学是基于 Project Reactor 的完全非阻塞和响应式。任何同步阻塞操作都会立即破坏这种非阻塞特性，导致 Netty 的 I/O 线程阻塞，进而影响整个网关的吞吐量和并发处理能力，甚至造成系统假死。 * **实现要求:** * 所有对外部服务的调用（如 Redis、数据库、HTTP 外部 API）必须使用响应式客户端（如 `Spring WebClient`、`Spring Data Reactive Redis`、`R2DBC` 等）。 * 自定义过滤器或任何扩展开发，必须采用 `Mono` 或 `Flux` 返回类型，并遵循响应式编程范式。 * **备注:** 我们强制要求所有相关开发（包括集成 `redis`、`feign` 等）全部采用 `webflux` 异步开发模式。 ##### 5.3.3. 禁止进行请求 Body 解析处理 [Section titled “5.3.3. 禁止进行请求 Body 解析处理”](#533-禁止进行请求-body-解析处理) * **限制内容:** 网关在过滤器扩展开发等场景下，通常不允许对请求体 (Request Body) 进行解析或修改。 * **强制级别:** 强制 * **详细说明:** * **性能影响:** 请求体解析是一个 I/O 密集型和 CPU 密集型操作。在网关层面进行 Body 解析会导致额外的内存拷贝和序列化/反序列化开销，严重影响网关的转发性能，特别是在高并发和请求体较大的场景下。 * **响应式流中断:** Spring Cloud Gateway 处理的是 `DataBuffer` 的响应式流。一旦读取并解析了 Body，这个流就会被消费。如果需要重新放回 Body 供下游服务使用，通常需要将 Body 缓存起来，这会增加内存压力和复杂度。 * **职责单一:** 网关的职责是快速路由和转发，以及执行通用的横切关注点（认证、限流等），业务数据的详细解析和处理应是下游微服务的职责。 * **替代方案:** * **使用 Header 传递信息:** 如果需要在网关层面获取请求的某些信息用于路由或过滤决策，且这些信息通常存在于 Body 中，应考虑将这些关键信息提取并添加到请求头中进行传递。这要求客户端或上游系统配合，或者在网关前置的代理层（如 Nginx + Lua）进行轻量级处理。 * **Header 优先级:** 通常，对于路由和过滤决策，优先使用请求头 (Header) 和查询参数 (Query Parameter) 进行处理。 * **特殊场景处理:** 如果确实存在少量、极端特殊且无法规避的业务场景，需要在网关层面读取请求 Body（例如，进行签名验证），则必须经过严格的架构评审，并采取熔断、限流、请求大小限制等严格的保护措施，确保其不会影响网关的整体性能和稳定性。此时，必须使用 `ServerRequest.bodyToMono()` 或 `ServerRequest.bodyToFlux()` 等响应式方式，且处理完成后确保 Body 可以被下游服务再次读取（例如通过 `CachedBodyOutputMessage` 等方式）。 ##### 5.3.4. 禁止处理静态资源 [Section titled “5.3.4. 禁止处理静态资源”](#534-禁止处理静态资源) * **限制内容:** 网关不允许直接处理或代理静态资源（如 CSS、JavaScript 文件、图片、字体等）。 * **强制级别:** 强制 * **详细说明:** * **职责混淆:** 网关的主要职责是动态请求的路由和流量控制，而不是作为静态文件服务器。 * **效率低下:** 专门的 Web 服务器（如 Nginx、Apache Httpd）或内容分发网络 (CDN) 在处理静态资源方面具有更高的效率、更好的缓存机制和更优化的网络传输能力。让网关处理静态资源会增加不必要的负载，降低其处理核心业务流量的效率。 * **缓存与优化:** 静态资源通常需要大量的缓存策略（如 Expires/Cache-Control 头、CDN 缓存），这些都不是网关的核心功能。 * **替代方案:** * **独立 Web 服务器:** 将所有静态资源部署到专用的高性能 Web 服务器（如 Nginx）上。 * **CDN (内容分发网络):** 对于面向全球用户的静态资源，强烈推荐使用 CDN 服务，以提高用户访问速度并分担服务器压力。 * **对象存储服务:** 对于需要存储大量静态文件的场景，可以使用对象存储服务（如阿里云 OSS、AWS S3），并配合 CDN。 ### 6. 性能优化与监控 [Section titled “6. 性能优化与监控”](#6-性能优化与监控) #### 6.1. 连接池配置 [Section titled “6.1. 连接池配置”](#61-连接池配置) 优化 Netty HttpClient 的连接池参数，以提高并发处理能力和资源利用率。 ```yaml # application.yml Netty HttpClient 连接池配置示例 spring: cloud: gateway: httpclient: pool: type: FIXED # 连接池类型：FIXED (固定大小) 或 ELASTIC (弹性) max-connections: 2000 # 最大连接数 acquire-timeout: 5000ms # 从连接池获取连接的超时时间 max-idle-time: 30000ms # 连接在连接池中的最大空闲时间 connect-timeout: 2000 # 与目标服务建立连接的超时时间 (毫秒) response-timeout: 10s # 从目标服务接收响应的超时时间 (时间单位：s, ms, m, h, d) # wiretap: false # 生产环境禁用，仅用于调试。默认为 false ``` #### 6.2. 限流 (Rate Limiting) [Section titled “6.2. 限流 (Rate Limiting)”](#62-限流-rate-limiting) 通过 `RequestRateLimiter` 过滤器对流量进行控制，保护下游服务，防止过载。 * **策略:** * **全局限流:** 针对所有进入网关的请求。 * **IP 限流:** 针对客户端 IP 地址。 * **用户限流:** 针对认证后的用户 ID。 * **API 限流:** 针对特定 API 路径。 * **算法:** Spring Cloud Gateway 默认集成 Redis 实现了令牌桶 (Token Bucket) 算法。 * **KeyResolver:** 这是限流的关键，定义了限流的维度。虽然在 YAML 中配置，但 `KeyResolver` 本身需要通过 Java Bean 提供。 * **IP 地址:** 引用 `#{@ipKeyResolver}` * **用户 ID:** 引用 `#{@userKeyResolver}` (假设您有解析用户 ID 的 Java Bean) * **API 路径 + 方法:** 引用 `#{@pathMethodKeyResolver}` #### 6.3. 熔断与降级 (Circuit Breaking & Fallback) [Section titled “6.3. 熔断与降级 (Circuit Breaking & Fallback)”](#63-熔断与降级-circuit-breaking--fallback) 使用 `CircuitBreaker` 过滤器集成 Resilience4j (推荐) 或 Hystrix，实现服务熔断机制，防止服务雪崩。 * **配置参数:** * `name`: 熔断器实例的唯一名称。 * `fallbackUri`: 熔断发生时的降级处理 URI。 * `setFallbackHeaders`: 降级时是否传递请求头到降级 URI。 * `addStatusCode`: 除了默认异常，额外触发熔断的状态码（如 `500`, `429`）。 * **降级策略:** * 返回默认值或友好提示信息。 * 从缓存中读取数据。 * 跳转到静态错误页面。 * **示例 (YAML):** ```yml - id: payment_service_breaker_route uri: lb://PAYMENT-SERVICE predicates: - Path=/payment/** filters: - name: CircuitBreaker args: name: paymentServiceBreaker # 断路器名称 fallbackUri: forward:/fallback/payment-service # 降级URI allowCircuitBreakerOpenWhenNoWorkers: false # 推荐设置为 false addStatusCode: 500,502 # 当下游返回 500 或 502 时也触发熔断 ``` **对应的 Java 降级控制器 (见 4.1.1 b) 配套 Java Bean 部分)** #### 6.4. 监控与告警 [Section titled “6.4. 监控与告警”](#64-监控与告警) * **集成 Spring Boot Actuator:** 暴露 `/actuator/health`, `/actuator/metrics`, `/actuator/threaddump` 等端点，提供应用健康状态和运行时信息。 * **Metrics (指标):** * 通过 Micrometer 集成 Prometheus、Grafana 等监控系统，收集网关的关键业务和系统指标。 * **关键指标:** * **网关请求量 (TPS):** `gateway.requests.total` * **请求响应时间 (Latency):** `gateway.requests.duration` (平均、P90、P99) * **错误率:** `gateway.requests.failed` (HTTP 5xx 错误) * **路由匹配成功率:** * **过滤器执行耗时:** * **限流/熔断触发次数:** `resilience4j.circuitbreaker.calls`, `spring.cloud.gateway.rate-limiter.throttled` * JVM 指标 (CPU 使用率、内存使用量、GC 次数/时间、线程数)。 * **分布式链路追踪 (Distributed Tracing):** * 集 成 Spring Cloud Sleuth，结合 Zipkin 或 Jaeger 等追踪系统，实现请求在网关和下游微服务之间的完整调用链追踪。 * 这对于定位跨服务的性能瓶颈和故障非常有帮助。 * **告警:** 基于关键指标设置告警规则，及时发现和响应潜在问题。 ### 7. 安全实践 [Section titled “7. 安全实践”](#7-安全实践) 网关作为系统的第一道防线，其安全性至关重要。 #### 7.1. HTTPS/TLS (强制) [Section titled “7.1. HTTPS/TLS (强制)”](#71-httpstls-强制) * 所有暴露给外部的网关入口必须强制使用 HTTPS，配置有效的 SSL/TLS 证书。 * 建议在网关层面进行 SSL/TLS 卸载，并将请求转发给内部服务（内部服务可以继续使用 HTTPS 或 HTTP，但推荐内部也使用 HTTPS 以实现端到端加密）。 #### 7.2. Web 应用防火墙 (WAF) & DDoS 防护 [Section titled “7.2. Web 应用防火墙 (WAF) & DDoS 防护”](#72-web-应用防火墙-waf--ddos-防护) * 在网关前端部署 WAF (Web Application Firewall) 和 DDoS 防护服务（例如云服务商提供的 WAF 或 CDN），以抵御常见的 Web 攻击（如 SQL 注入、XSS、CSRF）和分布式拒绝服务攻击。 * 网关的限流和熔断机制是对 WAF/DDoS 防护的有效补充。 #### 7.3. 输入验证与净化 [Section titled “7.3. 输入验证与净化”](#73-输入验证与净化) * 尽管大部分输入验证应在下游服务进行，但对于可能影响网关性能或安全的基础性验证（如 URL 路径、请求头长度等），网关可以进行初步校验。 * 避免将未经验证的用户输入直接用于重写路径或作为动态参数。 #### 7.4. 日志审计与安全审计 [Section titled “7.4. 日志审计与安全审计”](#74-日志审计与安全审计) * **日志记录:** * 详细记录所有进入网关的请求和响应的关键信息，包括：请求 URL、HTTP 方法、客户端 IP、用户标识 (如果已认证)、请求头 (选择性)、响应状态码、请求耗时、错误信息。 * 确保日志具有可追溯性，并与链路追踪 ID 关联。 * **日志存储与分析:** 将网关日志集中存储到日志管理平台（如 ELK Stack, Splunk），并进行实时分析和安全审计。 * **敏感信息脱敏:** 严格执行日志脱敏策略，绝不允许在日志中出现明文密码、个人身份信息、银行卡号等敏感数据。 ### 8. 错误处理与容错 [Section titled “8. 错误处理与容错”](#8-错误处理与容错) #### 8.1. 全局异常处理 [Section titled “8.1. 全局异常处理”](#81-全局异常处理) * 实现 `ErrorWebExceptionHandler` 接口，对网关层面产生的异常进行统一处理，返回友好的、统一的 JSON 格式错误响应。 * 避免将原始的 Java 异常堆栈信息直接暴露给客户端。 * 根据 HTTP 状态码和业务错误码，提供清晰的错误描述。 * **对应的 Java 实现 (见 4.3.3 全局过滤器 部分后的 Java 代码示例)。** #### 8.2. 重试机制 [Section titled “8.2. 重试机制”](#82-重试机制) * 对于下游服务的短暂网络波动或瞬时错误，可以配置 `Retry` 过滤器进行重试。 * **重要原则:** 仅对幂等操作（GET, PUT, DELETE）启用重试。POST 请求通常不幂等，重试可能导致数据重复或业务异常，需特别谨慎或仅在特定业务场景下使用。 * 设置合理的重试次数和重试间隔，避免对下游服务造成过大压力。 ### 9. 开发与部署规范 [Section titled “9. 开发与部署规范”](#9-开发与部署规范) #### 9.1. 配置管理 [Section titled “9.1. 配置管理”](#91-配置管理) * **配置中心 (推荐):** 使用 Spring Cloud Config、Nacos Config 或 Apollo 等配置中心来集中管理网关的配置，实现动态刷新和版本控制。 * **环境隔离:** 区分开发、测试、生产环境配置，并通过 Profile 进行管理。 * **敏感信息加密:** 数据库密码、API Key、证书等敏感配置必须加密存储在配置中心，并通过 Jasypt 或配置中心自身的加密功能进行解密。 #### 9.2. 代码规范 [Section titled “9.2. 代码规范”](#92-代码规范) * 遵循公司的 Java 代码规范，包括但不限于命名规范、注释规范、代码格式化等。 * 即使主要使用 YAML 配置路由，自定义的全局过滤器、`KeyResolver` 和异常处理器等 Java 代码也应确保清晰、可读、易于维护，并编写详细的 Javadoc 注释。 #### 9.3. 自动化测试策略 [Section titled “9.3. 自动化测试策略”](#93-自动化测试策略) * **单元测试:** 对自定义的 `GlobalFilter`、`KeyResolver`、`ErrorWebExceptionHandler` 等组件编写单元测试。 * **集成测试:** 编写针对 YAML 配置的路由、谓词和过滤器的集成测试，模拟实际请求流，验证路由是否正确匹配、过滤器是否按预期修改请求/响应。 * **性能测试:** 在部署前进行压力测试和性能基准测试，验证网关在高并发下的性能表现。 #### 9.4. 部署策略 [Section titled “9.4. 部署策略”](#94-部署策略) * **容器化部署:** 推荐使用 Docker 镜像化打包网关应用，并通过 Kubernetes (K8s)、Docker Swarm 等容器编排平台进行部署。 * **高可用性:** 部署多个网关实例，通过负载均衡器（如 Nginx, F5, 云厂商的 LB）进行分发，实现高可用。 * **弹性伸缩:** 利用容器编排平台的自动扩缩容能力，根据流量变化弹性调整网关实例数量。 * **灰度发布/蓝绿部署:** 利用网关的路由能力，结合容器编排工具实现灰度发布或蓝绿部署，实现平滑升级和回滚。 * **健康检查:** 配置 Kubernetes 或负载均衡器的健康检查，确保只有健康的网关实例才接收流量。 ### 10. 附录 [Section titled “10. 附录”](#10-附录) #### 10.1. 常用配置示例 [Section titled “10.1. 常用配置示例”](#101-常用配置示例) ```yml # application.yml 基础配置示例 server: port: 8080 # 网关监听端口 spring: application: name: gateway-service # 应用名称 profiles: active: dev # 默认激活的配置文件 cloud: gateway: # 全局默认过滤器配置 default-filters: - DedupeResponseHeader=Vary Access-Control-Allow-Origin, RETAIN_FIRST # 去重响应头 - PreserveHostHeader # 转发时保留原始的 Host 头 # 全局 CORS 配置 (推荐在单独的 CorsWebFilter Bean 中配置，或见 5.2.4) globalcors: cors-configurations: '[/**]': allowedOrigins: "*, null" # 仅用于开发测试，生产环境需指定具体域名 allowedMethods: - GET - POST - PUT - DELETE allowedHeaders: "*" allowCredentials: true maxAge: 3600 # Netty HttpClient 配置 (见 6.1) httpclient: connect-timeout: 2000 response-timeout: 10s pool: type: FIXED max-connections: 1000 # 服务注册发现配置 (以 Eureka 为例) eureka: client: serviceUrl: defaultZone: http://localhost:8761/eureka/ # Eureka Server 地址 # Resilience4J (断路器) 配置示例 resilience4j: circuitbreaker: instances: # 定义名为 slowServiceBreaker 的断路器实例配置 (在路由中 CircuitBreaker 过滤器的 name 参数引用) slowServiceBreaker: registerHealthIndicator: true # 注册健康指标 failureRateThreshold: 50 # 失败率阈值 (50%) waitDurationInOpenState: 5s # 断路器打开后的等待时间 (5秒) slidingWindowType: COUNT_BASED # 滑动窗口类型：基于次数 slidingWindowSize: 10 # 滑动窗口大小：10次请求 minimumNumberOfCalls: 5 # 最小请求数：至少5次请求才开始计算失败率 permittedNumberOfCallsInHalfOpenState: 3 # 半开状态下允许的请求数 # 定义名为 paymentServiceBreaker 的断路器实例配置 paymentServiceBreaker: registerHealthIndicator: true failureRateThreshold: 60 # 支付服务失败率阈值 (60%) waitDurationInOpenState: 10s # 断路器打开后的等待时间 (10秒) slidingWindowType: TIME_BASED # 滑动窗口类型：基于时间 slidingWindowSize: 60s # 滑动窗口大小：60秒 minimumNumberOfCalls: 10 # 最小请求数：至少10次请求才开始计算失败率 permittedNumberOfCallsInHalfOpenState: 5 # 半开状态下允许的请求数 # Redis RateLimiter 配置 (需引入 spring-boot-starter-data-redis-reactive 依赖) spring: redis: host: localhost port: 6379 ``` #### 10.2. 常见问题排查 [Section titled “10.2. 常见问题排查”](#102-常见问题排查) * **路由不匹配:** * 检查谓词 (`Path`, `Method`, `Host` 等) 配置是否正确，是否存在拼写错误。 * YAML 配置格式是否正确，缩进是否准确。 * 路径匹配顺序：更具体的路径谓词应定义在更通用的谓词之前。 * 检查 `StripPrefix` 或 `RewritePath` 是否正确处理了路径。 * **过滤器不生效:** * 检查过滤器是否已正确配置到目标路由的 `filters` 列表或全局默认过滤器中。 * 检查 `GlobalFilter` 的 `@Order` 值，确保其在期望的顺序执行。 * 检查过滤器逻辑是否有异常抛出，导致链式调用中断。 * **服务无法发现:** * 检查服务发现客户端依赖是否正确引入。 * 检查服务注册中心地址配置是否正确。 * 确保下游服务已成功注册到服务注册中心。 * 检查服务 ID (`[lb://SERVICE_ID](lb://SERVICE_ID)`) 是否与下游服务注册的 ID 完全一致。 * **性能瓶颈:** * 监控网关的 CPU、内存、网络 I/O 使用情况。 * 检查 Netty HttpClient 的连接池配置是否合理。 * 检查是否有长时间运行的自定义过滤器或阻塞操作。 * 分析 Micrometer 指标，特别是请求响应时间、GC 时间等。 * **内存泄漏:** * 使用 Java 内存分析工具 (如 JVisualVM, JProfiler) 检查堆内存使用情况，查找是否有对象无法被垃圾回收。 * 检查自定义过滤器中是否有资源未释放或 Reactor Stream 未正确订阅/取消。 * **断路器/限流不工作:** * 检查 Redis 连接是否正常，Redis 服务是否可用。 * 检查 `KeyResolver` 是否正确返回了限流 Key，以及在 YAML 中引用 SpEL 表达式 `#{@yourKeyResolverBeanName}` 是否正确。 * 检查 Resilience4j 的配置是否正确，特别是 `failureRateThreshold`, `slidingWindowSize` 等参数。 # 如何遍历链表 > 如何遍历链表 使用迭代器或者递归 简单的代码: ```java Iterator iter = linkedKist.iterator(); while(iter.hasNext()) { String element = iter.next(); System.out.println(element); } ``` ```java public void traverseLinkedList(Node node) { if (node != null) { // do something traverseLinkedList(node.next); } } ```