梦中世界

告别排班与调度难题：Timefold Solver 实战踩坑与性能调优心得

Sat, 25 Apr 2026 00:00:00 GMT

在处理企业级应用时，我们经常会遇到一类让人头疼的问题：规划与调度（Planning and Scheduling）。不管是员工排班、车辆路径规划（VRP）、还是会议室分配，这类问题在数学上通常属于 NP-Hard 问题。靠人工写 if-else 和贪心算法，不仅代码难以维护，而且很难找到最优解。

最近在项目中，我引入了 Timefold Solver（OptaPlanner 的继任者），它真的是解决这类资源分配问题的“降维打击”工具。今天不仅复盘一下我的使用心得，还会深入聊聊约束分级策略，以及一个极其容易踩中的性能大坑。

一、核心概念：捅破窗户纸的“顿悟”时刻#

Timefold 的核心逻辑其实就是三个词：Domain（领域模型）、Score（分数） 和 Solver（求解器）。理清以下三个角色就豁然开朗了：

Planning Entity（规划实体）：业务里需要被分配的对象。比如“值班任务”。
Planning Variable（规划变量）：实体中需要被求解器填入的属性。比如值班任务里的“员工”。
Planning Solution（规划方案）：整个问题的全局视图，包含所有实体和资源，以及计算出来的总得分。

二、深入理解分数体系：Hard、Medium 与 Soft#

在复杂的业务场景中，非黑即白的“硬约束”和“软约束”往往不够用。Timefold 提供了多级分数机制（如 HardMediumSoftScore），帮助求解器在不同的业务维度上权衡利弊。求解器的比较逻辑是严格向下压制的：只有在 Hard 分数相同时，才会去比较 Medium 分数；Medium 相同时，再去比较 Soft 分数。

1. Hard Score（硬约束）：不可逾越的红线#

硬约束代表了物理限制、法律合规或绝对的业务底线。任何破坏硬约束的方案都是不可行解（Infeasible Solution）。

场景举例：一个医生不能在同一时间段主刀两台手术；一辆卡车的装载量不能超过它的最大载重。
求解器行为：Solver 会拼尽全力把 Hard 分数提升到 0（或 0 以上）。

2. Medium Score（中等约束）：核心业务 KPI#

当我们满足了所有硬约束，得到了可行解后，往往会有多个方案摆在面前。Medium 约束通常用来衡量方案的核心业务价值，比如总成本、总利润或整体的公平性。

场景举例：在物流配送中，所有包裹都装上车了（Hard 满足），此时需要最小化所有车辆的总行驶里程；在排班中，保证各个团队分配到的资深员工数量大致均衡。
求解器行为：在确保 Hard 分数不下降的前提下，努力优化 Medium 分数。

3. Soft Score（软约束）：锦上添花的偏好#

这是优先级最低的约束，通常涉及用户体验或个人偏好。

场景举例：员工 A 希望周五能排早班以便提早回家；尽量把会议安排在带有白板的会议室。
求解器行为：在 Hard 和 Medium 都锁定的情况下，顺手做个人情，尽量满足这些条件。

三、性能避坑指南：为什么千万别用 BigDecimal 当分数？#

在编写 Java 领域模型时，由于经常涉及金额（如计算超时加班费、物流成本），很多开发者会本能地使用 BigDecimal，并在 Timefold 中配置对应的 BendableBigDecimalScore。这是一个极其致命的性能陷阱！

Timefold 的底层是一个启发式搜索殷勤，它在寻找最优解时，每秒钟需要进行数万次甚至数十万次的分数计算（Score Calculation）。

对象创建开销：BigDecimal 是不可变对象。在每秒数万次的运算循环中，频繁进行加减乘除会产生海量的短生命周期对象。这会导致 Java 的垃圾回收器（GC）压力骤增，频繁触发 GC 停顿，直接将求解速度拖慢几个数量级。
正确的优化姿势：永远优先使用基本数据类型！ 采用 int（对应 HardSoftScore）或 long（对应 HardSoftLongScore）。
如何处理小数？：使用整数放大法。如果成本精确到分，直接把金额乘以 100 存为 long 参与计算；如果需要三位小数精度，就乘以 1000。在最终向前端展示结果时，再除以对应的倍数还原即可。

四、给新手的几条实践建议#

从小数据集开始验证：千万不要一开始就把生产环境几万条数据扔进去跑。先搞一个极小的数据集（比如 5个任务，3个员工），验证你的 ConstraintProvider 写得对不对。
善用 ConstraintVerifier：这是 Timefold 提供的单元测试工具。一定要为每一条约束写单元测试！ 否则当你有 20 条约束混合在一起时，你根本不知道为什么求解器给出了一个奇怪的结果。
监控分数计算速度（Score Calculation Speed）：观察日志，如果每秒计算次数只有几百次，说明你的约束流写得太重了，或者误用了类似 BigDecimal 这样高开销的类型。

从爆内存到毫秒响应：回溯剪枝、启发式算法与运筹求解器选型指南

Wed, 17 Sep 2025 00:00:00 GMT

在软件开发中，我们经常遇到诸如“任务调度、路径规划、装箱问题、组合优化”等复杂计算场景。很多开发者遇到这类问题，第一反应是写个递归回溯，结果数据量一上来就抛出 StackOverflowError 或跑几个小时不出结果。

算法选型没有“万能灵药”。本文将从原理对比、数据量选型、实战剪枝技巧三个维度，帮助你在面对组合爆炸问题时做出最优架构选择。

一、三大主流求解方案对比#

在解决 NP-Hard / 组合优化问题时，通常有以下三大技术路线：

维度	准确回溯算法 (Backtracking)	元启发式算法 (Heuristics/Metaheuristics)	专业运筹求解器 (Timefold / OR-Tools / OR-Suite)
求解目标	必须找到全局最优解 / 绝对精确解	快速找到满意解 / 局部最优解	在规定时间内寻找尽可能最优的解
核心机制	深度优先搜索 (DFS) + 剪枝	贪心、遗传算法、禁忌搜索、模拟退火	增量计算 + 局部搜索 (Local Search) + 规则引擎
数据量承载	小规模（数十至上百）	中大规模（数千至数十万）	中大规模（复杂的约束多维问题）
开发与维护成本	简单直接，但剪枝逻辑易写错	算法调优繁琐，容易陷入局部最优	建模门槛略高，但业务规则扩展极其容易

二、如何根据数据量与场景进行选型？#

决策的本质是在算力成本、响应时间、求解质量之间做权衡。

1
数据规模/复杂度评估：
2
├─ 小规模数据（N ≤ 20~30）──────> 优先选【回溯 + 极简剪枝】
3
├─ 约束规则简单 + 大数据量 ───────> 优先选【贪心 / 局部搜索启发式算法】
4
└─ 复杂约束 + 动态业务逻辑 ──────> 优先选【Timefold / Google OR-Tools 等求解器】

1. 小数据量（N ≤ 30）：首选回溯剪枝#

适用场景：数独求解、凑零钱问题、小规模组合搜索、权限组合穷举。
优势：代码量少，零额外依赖，逻辑直观。
风险：若无有效剪枝，复杂度呈指数级 O(2N)O(2^N)O(2N) 或 O(N!)O(N!)O(N!) 爆发。

2. 中大规模数据 + 单一目标：选用传统启发式算法#

适用场景：简单迷宫寻路（A* 算法）、千万级数据的降维近邻查找、简单装箱。
优势：计算速度极快（通常为毫秒级），内存占用低。
劣势：一旦业务新增“临时规则”，启发式函数（Heuristic Function）需要重写，维护成本高。

3. 复杂业务约束 + 动态变化：首选 Timefold / OR-Tools 求解器#

适用场景：外卖派单（VRP）、医院护士排班、工厂生产线调度。
优势：业务规则与求解引擎解耦。业务人员今天加一条“A和B不能同班”，只需加一条约束规则，无需改动核心搜索算法。

三、实战：回溯算法如何高效“剪枝”？#

如果你选择了回溯算法，剪枝（Pruning） 是决定系统生死存亡的关键。剪枝的核心思想就是：尽早发现当前分支不可能产生有效解/最优解，并立即返回（砍掉这棵决策树的分枝）。

常用的三大剪枝绝招：

1. 可行性剪枝（Feasibility Pruning）#

原理：在搜索过程中，一旦发现当前状态已经违反了硬性约束，不再继续向下递归。
示例：在背包问题中，如果当前放入物品的总重量已经超过了背包容量限制，直接 return。

2. 最优性剪枝 / 限界剪枝（Bound Pruning）#

原理：维护一个全局已知的“历史最优解”。如果“当前已产生的代价 + 未来理论上的最佳估计”依然比不上“历史最优解”，直接剪枝。
示例：求解最短路径时，如果当前路径长度已经超过了之前找到的一条可行路径的总长，后面的节点就不必再走。

3. 顺序剪枝与去重剪枝（Ordering & Deduplication）#

原理：
- 顺序优化：先处理分支较少或约束最强的节点（最紧约束优先原则），可以极大地缩小整棵树的宽度。
- 去重：遇到完全等价的状态时，跳过重复分支（通常配合 HashSet 或记忆化 Bitmask）。

Java

1
// 剪枝伪代码模板
2
void backtrack(int level, State currentState) {
3
    // 1. 可行性剪枝：非法状态直接返回
4
    if (!isValid(currentState)) return;
5

6
    // 2. 最优性剪枝：当前花费已经不可能超越历史最佳，直接返回
7
    if (currentState.cost >= globalBestCost) return;
8

9
    // 达到终止条件
10
    if (level == MAX_LEVEL) {
11
        globalBestCost = Math.min(globalBestCost, currentState.cost);
12
        return;
13
    }
14

15
    for (Option option : getSortedOptions(level)) { // 3. 顺序优化：优先尝试更有可能的选项
16
        makeChoice(option);
17
        backtrack(level + 1, currentState);
18
        undoChoice(option); // 回溯恢复现场
19
    }
20
}

展开收起

四、总结与落地方案推荐#

不要一上来就写复杂的算法：先评估数据规模。如果是小集合处理，写个带剪枝的 DFS 足以胜任。
拒绝“硬编码”复杂规则：如果排班、调度类需求中的“软硬约束”多达几十条，且频繁变更，果断放弃纯手写回溯，直接接入 Timefold Solver 等成熟框架。
性能监控是关键：对回溯算法务必设置最大递归深度或超时中断机制；对求解器则需要合理配置终止条件（如 spentLimit）。

选对了算法与架构，不仅能把 CPU 利用率降下来，更能让你的代码在面对业务变更时游刃有余！

搞懂 MySQL 临时表：会话级、事务级与常见坑点解析

Sun, 30 Oct 2022 00:00:00 GMT

在处理复杂查询、中间数据暂存或报表生成时，MySQL 的临时表（Temporary Table）是我们经常用到的“利器”。但你真的了解它的生命周期和适用场景吗？为什么在 PostgreSQL 或 Oracle 里常见的“事务级临时表”，在 MySQL 里却不太一样？

本文将带你系统梳理 MySQL 临时表的概念、分类、用法以及实践中的注意事项。

一、什么是 MySQL 临时表？#

临时表是一种特殊的数据库表，主要用于存储临时数据。它最大的特点是只对当前连接（Session/会话）可见，当连接断开时，临时表会被数据库自动销毁并释放空间。

核心特性：#

隔离性：不同会话创建同名的临时表互不干扰。
同名覆盖：当前会话如果创建了与普通表同名的临时表，在此会话中普通表会被“隐匿”，所有操作作用于临时表；会话结束后，原普通表不受任何影响。
自动释放：会话关闭时自动删除，无需手动 DROP TABLE（但显式删除是更好的习惯）。

二、基础语法与使用#

创建临时表非常简单，只需要在 CREATE TABLE 中增加 TEMPORARY 关键字：

SQL

1
-- 创建内存/磁盘临时表
2
CREATE TEMPORARY TABLE tmp_user_stats (
3
    user_id INT PRIMARY KEY,
4
    login_count INT DEFAULT 0,
5
    last_login_time DATETIME
6
) ENGINE=InnoDB;
7

8
-- 插入数据与普通表无异
9
INSERT INTO tmp_user_stats VALUES (1, 10, NOW());
10

11
-- 查询数据
12
SELECT * FROM tmp_user_stats;
13

14
-- 手动删除（推荐）
15
DROP TEMPORARY TABLE IF EXISTS tmp_user_stats;

展开收起

三、会话级临时表 vs 事务级临时表#

对于临时表，不同数据库（如 Oracle、PostgreSQL、MySQL）的实现机制和生命周期定义有所不同，主要分为会话级（Session-level）*和*事务级（Transaction-level）。

1. 普通临时表（会话级临时表）#

MySQL 原生支持的 CREATE TEMPORARY TABLE 默认属于会话级临时表：

生命周期：贯穿整个会话。只要会话不关闭，表和其中的数据就一直存在（除非显式删除）。
跨事务性：在一个事务中插入的数据，在事务提交（COMMIT）后依然保留在临时表中，可以被后续事务继续使用。

2. 事务级临时表（Transaction-Level Temporary Table）#

事务级临时表的作用域仅限于当前事务：

生命周期：仅在当前事务内有效。
数据清理机制：一旦事务提交（COMMIT）或回滚（ROLLBACK），临时表中的数据会自动被清空（或表结构被清理）。

💡 MySQL 的情况说明：
MySQL（包括 InnoDB 引擎）原生并不直接支持类似 Oracle 那样 ON COMMIT DELETE ROWS 的标准事务级临时表语法。
如果需要在 MySQL 中实现“事务级临时表”的效果，通常有以下两种替代方案：

应用层手动维护：在事务提交或回滚前，显式调用 TRUNCATE TABLE tmp_table 或 DROP TEMPORARY TABLE tmp_table。

利用内存引擎+局部逻辑：结合存储过程或事务块，在事务结束时用程序控制数据清空。

四、内部临时表（Internal Temporary Tables）#

除了我们用 SQL 显式创建的临时表，MySQL 执行引擎在处理特定查询时，也会自动在后台创建“内部临时表”。

常见触发场景：

包含 GROUP BY 和 ORDER BY 的列不一致时
使用 DISTINCT 结合 ORDER BY 时
UNION 查询（非 UNION ALL）
子查询或复杂 Join 无法有效利用索引时

优化建议：

内部临时表优先建立在内存中（Memory / TempTable 引擎），如果超过 tmp_table_size 或 max_heap_table_size 限制，会退化为磁盘临时表（InnoDB / MyISAM），严重拖慢性能。在写复杂 SQL 时，应尽量通过合理索引和改写 SQL 避免触发磁盘临时表。

五、临时表的使用坑点与最佳实践#

主从复制（Replication）隐患：

在基于语句的复制（Statement-Based Replication, SBR）模式下，临时表的操作可能导致主从不一致。现代 MySQL 建议使用基于行的复制（Row-Based Replication, RBR）。
主从切换/连接池复用：

在短连接或高频连接池环境中，如果连接被重用且没有正确清理临时表，可能导致后续逻辑误用残余的临时表数据。建议在使用完毕后显式清理：

SQL
```
1
DROP TEMPORARY TABLE IF EXISTS tmp_table_name;
```
不能多次引用同一张临时表：

在同一个查询（如 JOIN 或子查询）中，MySQL 不允许两次引用同一个 InnoDB/Memory 临时表，否则会报错：Can't reopen table: 'tmp_table'。

六、总结#

临时表类型	生命周期	MySQL 是否原生支持	常用场景
会话级临时表	当前会话建立至连接断开	是 (`CREATE TEMPORARY TABLE`)	跨多个事务暂存中间计算结果
事务级临时表	当前事务开始至 `COMMIT`/`ROLLBACK`	否（需手动清理或借助程序实现）	单个事务内的短期计算、防止数据污染
内部临时表	单条 SQL 执行期间	是（由优化器自动生成）	`GROUP BY`、`DISTINCT`、`UNION` 等

合理使用临时表能大大简化复杂查询的开发逻辑，但也要时刻警惕内存占用和未显式销毁带来的潜在副作用！

认识docker以及如何使用

Tue, 22 Mar 2022 00:00:00 GMT

Docker是一款针对程序开发人员和系统管理员来开发、部署、运行应用的一款虚拟化平台。Docker 可以让你像使用集装箱一样快速的组合成应用，并且可以像运输标准集装箱一样，尽可能的屏蔽代码层面的差异。传统虚拟化方式是在硬件层面实现虚拟化，需要有额外的虚拟机管理应用和虚拟机操作系统层。而docker容器是在操作系统层面上实现虚拟化，直接复用本地主机操作系统，更加轻量。

docker#

Docker Engine概述#

Docker Engine是一种开源容器化技术，用于构建和容器化您的应用程序。Docker Engine通过以下方式充当客户端-服务器应用程序：

具有长时间运行的守护进程的服务器dockerd。
API，用于指定程序可以用来与Docker守护程序进行对话和指示的接口。
命令行界面（CLI）客户端docker。

为什么选择Docker？#

快速交付应用程序#

我们希望你的开发环境能够更好的提高你的工作效率。Docker容器能够帮助开发人员、系统管理员、QA和版本控制工程师在一个生产环节中一起协同工作。我们制定了一套容器标准，而这套容器标准能够使系统管理员更改容器的时候，程序员不需要关心容器的变化，而更专注自己的应用程序代码。从而隔离开了开发和管理，简化了开发和部署的成本。
我们使应用的构建方式更加简单，可以快速的迭代你的应用，并且可以可视化的来查看应用的细微更改。这能够帮助组织里边的成员来更好的理解一个应用从构建到运行的过程。
Docker 是一个轻量级的容器，所以它的速度是非常快的，而容器的启动时间只需要一秒钟，从而大大的减少了开发、测试和部署的时间。轻松部署和扩展
Docker 容器可以运行在大多数的环境中，你可以在桌面环境、物理主机、虚拟主机再到数据中，私有或者公有云中部署。
因为 Docker 可以从多平台下运行。你可以很容器的迁移你的应用程序。如果需要，你可以非常简单的将应用程序从测试环境迁移到云，或者从云迁移到测试环境。
Docker 是一个轻量级的容器，因此它可以在很短的时间内启动和关闭。当你需要的时候，你可以启动多个容器引擎，并且在不需要使用他们的时候，可以将他们全部关闭。

Docker的容器本身不需要额外创建虚拟机管理系统，因此你可以启动多套Docker容器，这样就可以充分发挥主机服务器的物理资源，也可以降低因为采购服务器licenses而带来的额外成本。

快速构建轻松管理#

因为Docker上述轻便，快速的特性。可以使您的应用达到快速迭代的目的。每次小的变更，马上就可以看到效果。而不用将若干个小变更积攒到一定程度再变更。每次变更一小部分其实是一种非常安全的方式。

镜像#

概念#

镜像是一种轻量级、可执行的独立软件包，用来打包软件运行环境和基于运行环境开发的软件，它包含运行某个软件所需的所有内容，包括代码、运行时、库、环境变量和配置文件。

加载原理#

（1）UnionFS(联合文件系统)

UnionFS（联合文件系统）：Union文件系统是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下，Union文件系统是Dokcer镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的镜像。

特性：一次同时加载多个文件系统，但从外面看起来，只能看到一个文件系统，联合加载会把各层文件系统加载起来，这样最终的文件系统会包含所有的底层文件和目录。

（2）Docker镜像加载原理

docker的镜像实际上是由一层一层的文件系统构成，这种层级的文件系统UnionFS。

主要包含bootloader和kernel，bootloader主要是引导加载kernel，Linux刚启动时会加载bootfs文件系统，在Docker镜像的最底层是bootfs。这一层与我们典型的linux/unix系统是一样的，包含boot加载器内核。当boot加载完之后整个内核就都在内存中了，此时内存的使用权已经由bootfs交给内核了，此时系统也会卸载bootfs。

rootfs：在 bootfs之上，包含的就是典型 Linux系统中的/dev、/proc、/bin、/etc等标准目录和文件，rootfs就是各种不同的操作系统发行版，比如：Ubuntu,、CentOS等等

简单理解：

对于Docker安装OS来说：就是Docker使用了Linux本身的bootfs，只需要安装自己所需的rootfs。
对于Docker安装普通镜像来说：就是Docker本身是分层下载镜像，所以可以提取出公共层镜像，进行复用。

可以看到，新镜像是从 base 镜像一层一层叠加生成的。每安装一个软件，就在现有镜像的基础上增加一层。为什么 Docker 镜像要采用这种分层结构呢？

最大一个好处就是——共享资源

比如：有多个镜像都从相同的base镜像构建而来，那么宿主机只需要在磁盘上保存一份base镜像，同时内存中也需要加载一份base镜像，就可以为所有服务器服务了。而且镜像的每一层都可以被共享。

平时我们安装进虚拟机的CentOS都是好几个G，为什么docker这里才200M？

对以一个精简的OS，rootfs可以很小，只需要包括最基本的命令、工具和程序库就行，因为底层直接用host和kernel，自己只需要提供rootfs就行。由此可见对于不同的Linux发行版，bootfs基本是一致的，rootfs会有差别，因此不同的发行版可以公用bootfs。

下图是docker下载镜像的日志，可以很清晰的看到是一层一层在下载的。

容器命令#

进入容器内部：docker run -it rongqiName/rongqiId /bin/bash#

退出容器：exit#

容器生命周期管理#

run: https://www.runoob.com/docker/docker-run-command.html
start/stop/restart: https://www.runoob.com/docker/docker-start-stop-restart-command.html
kill: https://www.runoob.com/docker/docker-kill-command.html
rm: https://www.runoob.com/docker/docker-rm-command.html
pause/unpause: https://www.runoob.com/docker/docker-pause-unpause-command.html
create：https://www.runoob.com/docker/docker-create-command.html
exec：https://www.runoob.com/docker/docker-exec-command.html

容器操作#

容器rootfs命令#

容器数据卷#

匿名挂载#

Terminal window展开收起

1
docker run -p 8080:80 --name nginx -v /etc/nginx -d nginx
2

3
# 查看docker镜像，可以看到刚刚创建的nginx的信息
4
[root@localhost ~]# docker ps
5
CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                  NAMES
6
942dba4d602b   nginx     "/docker-entrypoint.…"   5 minutes ago   Up 5 minutes   0.0.0.0:8080->80/tcp   nginx
7

8
# 查看数据卷列表，可以看到生成了一个随机名称的数据卷
9
[root@localhost ~]# docker volume ls
10
DRIVER    VOLUME NAME
11
local     4a1a16c05c8653f31cfbaf3d5839f69b734c81dcfb4254ef98f308d95dbe4192
12

13
# 查看该数据卷的详细信息
14
[root@localhost ~]# docker volume inspect 4a1a16c05c8653f31cfbaf3d5839f69b734c81dcfb4254ef98f308d95dbe4192
15
[
16
    {
17
        "CreatedAt": "2021-04-04T17:17:51+08:00",
18
        "Driver": "local",
19
        "Labels": null,
20
        "Mountpoint": "/var/lib/docker/volumes/4a1a16c05c8653f31cfbaf3d5839f69b734c81dcfb4254ef98f308d95dbe4192/_data",
21
        "Name": "4a1a16c05c8653f31cfbaf3d5839f69b734c81dcfb4254ef98f308d95dbe4192",
22
        "Options": null,
23
        "Scope": "local"
24
    }
25
]

展开收起

具名挂载#

Terminal window展开收起

1
docker run -p 8081:80 --name nginx1 -v nginx:/etc/nginx -d nginx
2

3
# 查看数据卷列表，可以看到生成了一个随机名称的数据卷
4
[root@localhost ~]# docker volume ls
5
DRIVER    VOLUME NAME
6
local     4a1a16c05c8653f31cfbaf3d5839f69b734c81dcfb4254ef98f308d95dbe4192
7
local     nginx
8

9
# 查看该数据卷的详细信息
10
[root@localhost ~]# docker volume inspect nginx
11
[
12
    {
13
        "CreatedAt": "2021-04-04T17:19:14+08:00",
14
        "Driver": "local",
15
        "Labels": null,
16
        "Mountpoint": "/var/lib/docker/volumes/nginx/_data",
17
        "Name": "nginx",
18
        "Options": null,
19
        "Scope": "local"
20
    }
21
]

展开收起

指定路径挂载#

Terminal window

1
docker run -p 8082:80 --name nginx2 -v /mydata/nginx/html:/usr/share/nginx/html -v /mydata/nginx/logs:/var/log/nginx -d nginx

数据同步#

—volumes-from ps：因为使用的是拷贝，当一个容器删除后，另一个容器中的数据不会消失。

Dockerfile#

Terminal window

1
FROM      # 基础镜像，第一条指令必须为 FROM 指令。并且，如果在同一个Dockerfile中创建多个镜像时，可以使用多个 FROM 指令（每个镜像一次）
2
MAINTAINER    # 指定维护者信息，一般是姓名 + 邮箱
3
RUN        # 镜像构建的时候需要的命令
4
ADD        # 压缩文件放在当前目录下，拷过去会自动解压
5
WORKDIR      # 镜像工作目录
6
VOLUME      # 挂载的目录
7
EXPOSE      # 暴露的端口
8
CMD        # 指定容器启动时要运行的命令，如果有多个该命令，只有最后一个生效，可被替代
9
ENTRYPOINT    # 指定容器启动时要运行的命令，可以追加命令
10
ONBUILD      # 当构建一个被继承 DockerFile ，这个时候就会运行 ONBUILD 的指令，触发命令
11
COPY      # 类似ADD，将我们的文件拷贝到容器中，当使用本地目录为源目录时，推荐使用
12
ENV        # 指定一个环境变量

Docker网络#

docker0#

Terminal window展开收起

1
docker pull 348491564/sentinel-dashboard:1.8.1
2

3
docker run -d -it -p 8858:8858 --name sentinel1 -v /mydata/sentinel/logs:/root/logs 348491564/sentinel-dashboard:1.8.1
4

5
docker run -d -it -p 8859:8858 --name sentinel2 -v /mydata/sentinel/logs:/root/logs 348491564/sentinel-dashboard:1.8.1
6

7
# 为容器安装ip addr命令和ping命令
8
apt-get install iproute2
9

10
[root@localhost ~]# ip addr
11
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
12
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
13
    inet 127.0.0.1/8 scope host lo
14
       valid_lft forever preferred_lft forever
15
    inet6 ::1/128 scope host
16
       valid_lft forever preferred_lft forever
17
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
18
    link/ether 00:0c:29:5a:e2:81 brd ff:ff:ff:ff:ff:ff
19
    inet 192.168.1.80/24 brd 192.168.1.255 scope global noprefixroute ens33
20
       valid_lft forever preferred_lft forever
21
    inet6 240e:390:c66:8960:822d:8305:95bd:8188/64 scope global noprefixroute dynamic
22
       valid_lft 258969sec preferred_lft 172569sec
23
    inet6 fe80::6f0d:e285:3e9a:f34d/64 scope link noprefixroute
24
       valid_lft forever preferred_lft forever
25
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
26
    link/ether 02:42:05:60:0b:d4 brd ff:ff:ff:ff:ff:ff
27
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
28
       valid_lft forever preferred_lft forever
29
    inet6 fe80::42:5ff:fe60:bd4/64 scope link
30
       valid_lft forever preferred_lft forever
31
23: veth0a5c9e6@if22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
32
    link/ether 96:22:79:da:e1:fe brd ff:ff:ff:ff:ff:ff link-netnsid 0
33
    inet6 fe80::9422:79ff:feda:e1fe/64 scope link
34
       valid_lft forever preferred_lft forever
35
25: veth52d47f8@if24: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
36
    link/ether aa:6b:a7:71:a6:64 brd ff:ff:ff:ff:ff:ff link-netnsid 1
37
    inet6 fe80::a86b:a7ff:fe71:a664/64 scope link
38
       valid_lft forever preferred_lft forever
39

40
# 使用容器1 ping 容器2 的ip，可以ping通
41
[root@localhost ~]# docker exec -it sentinel1 ping 172.17.0.3
42
PING 172.17.0.3 (172.17.0.3): 56 data bytes
43
64 bytes from 172.17.0.3: icmp_seq=0 ttl=64 time=0.062 ms
44
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.049 ms
45
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.048 ms
46
64 bytes from 172.17.0.3: icmp_seq=3 ttl=64 time=0.046 ms
47

48
# 使用容器1 ping 容器2 的域名，无法找到主机
49
[root@localhost ~]# docker exec -it sentinel1 ping sentinel2
50
ping: unknown host

展开收起

自定义Docker网络#

Terminal window展开收起

1
[root@localhost ~]# docker network create --driver bridge --subnet 192.168.0.0/16 --gateway 192.168.0.1 mynet
2

3
docker run -d -it -p 8858:8858 --name sentinel1 -v /mydata/sentinel/logs:/root/logs --net mynet 348491564/sentinel-dashboard:1.8.1
4

5
docker run -d -it -p 8859:8858 --name sentinel2 -v /mydata/sentinel/logs:/root/logs --net mynet 348491564/sentinel-dashboard:1.8.1
6

7
[root@localhost ~]# docker exec -it sentinel1 ping sentinel2
8
PING 4f7d49a86234 (192.168.0.2): 56 data bytes
9
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.050 ms
10
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=0.045 ms
11
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=0.046 ms
12
64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=0.048 ms
13
64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=0.047 ms
14
64 bytes from 192.168.0.2: icmp_seq=5 ttl=64 time=0.039 ms
15
64 bytes from 192.168.0.2: icmp_seq=6 ttl=64 time=0.062 ms

展开收起

Docker-compose#

介绍#

Docker-Compose 是 Docker 的一种编排服务，是一个用于在 Docker 上定义并运行复杂应用的工具，可以让用户在集群中部署分布式应用。通过 Docker-Compose 用户可以很容易地用一个配置文件定义一个多容器的应用，然后使用一条指令安装这个应用的所有依赖，完成构建。Docker-Compose 解决了容器与容器之间如何管理编排的问题。

Compose 中有两个重要的概念：

服务 (service) ：一个应用的容器，实际上可以包括若干运行相同镜像的容器实例。
项目 (project) ：由一组关联的应用容器组成的一个完整业务单元，在 docker-compose.yml 文件中定义。

一个项目可以由多个服务（容器）关联而成，Compose 面向项目进行管理，通过子命令对项目中的一组容器进行便捷地生命周期管理。

配置#

1
# 版本配置
2
version: '3'
3

4
# 服务配置
5
services:
6
  service1:
7
    ...
8
  service2:
9
    ...
10
# 其他配置，例如：网卡配置
11
networks:
12
  net1:
13
    name: net1
14
    driver: bridge
15
  net2:
16
    name: net2
17
    driver: bridge

展开收起

梦中世界

告别排班与调度难题：Timefold Solver 实战踩坑与性能调优心得

一、 核心概念：捅破窗户纸的“顿悟”时刻#

二、 深入理解分数体系：Hard、Medium 与 Soft#

1. Hard Score（硬约束）：不可逾越的红线#

2. Medium Score（中等约束）：核心业务 KPI#

3. Soft Score（软约束）：锦上添花的偏好#

三、 性能避坑指南：为什么千万别用 BigDecimal 当分数？#

四、 给新手的几条实践建议#

从爆内存到毫秒响应：回溯剪枝、启发式算法与运筹求解器选型指南

一、 三大主流求解方案对比#

二、 如何根据数据量与场景进行选型？#

1. 小数据量（N ≤ 30）：首选回溯剪枝#

2. 中大规模数据 + 单一目标：选用传统启发式算法#

3. 复杂业务约束 + 动态变化：首选 Timefold / OR-Tools 求解器#

三、 实战：回溯算法如何高效“剪枝”？#

1. 可行性剪枝（Feasibility Pruning）#

2. 最优性剪枝 / 限界剪枝（Bound Pruning）#

3. 顺序剪枝与去重剪枝（Ordering & Deduplication）#

四、 总结与落地方案推荐#

搞懂 MySQL 临时表：会话级、事务级与常见坑点解析

一、 什么是 MySQL 临时表？#

核心特性：#

二、 基础语法与使用#

三、 会话级临时表 vs 事务级临时表#

1. 普通临时表（会话级临时表）#

2. 事务级临时表（Transaction-Level Temporary Table）#

四、 内部临时表（Internal Temporary Tables）#

五、 临时表的使用坑点与最佳实践#

六、 总结#

认识docker以及如何使用

docker#

Docker Engine概述#

为什么选择Docker？#

快速交付应用程序#

快速构建 轻松管理#

镜像#

概念#

加载原理#

容器命令#

进入容器内部：docker run -it rongqiName/rongqiId /bin/bash#

退出容器：exit#

容器生命周期管理#

容器操作#

容器rootfs命令#

容器数据卷#

匿名挂载#

具名挂载#

指定路径挂载#

数据同步#

Dockerfile#

Docker网络#

docker0#

自定义Docker网络#

Docker-compose#

介绍#

配置#

一、核心概念：捅破窗户纸的“顿悟”时刻#

二、深入理解分数体系：Hard、Medium 与 Soft#

三、性能避坑指南：为什么千万别用 BigDecimal 当分数？#

四、给新手的几条实践建议#

一、三大主流求解方案对比#

二、如何根据数据量与场景进行选型？#

三、实战：回溯算法如何高效“剪枝”？#

四、总结与落地方案推荐#

一、什么是 MySQL 临时表？#

二、基础语法与使用#

三、会话级临时表 vs 事务级临时表#

四、内部临时表（Internal Temporary Tables）#

五、临时表的使用坑点与最佳实践#

六、总结#

快速构建轻松管理#