小菜鸟

进制转换：二进制、八进制、十进制、十六进制的转换方法

在计算机领域，二进制（B）、八进制（O）、十进制（D）和十六进制（H）是最常用的数制。掌握它们之间的转换规则，是理解计算机数据存储和运算的基础。以下是详细的转换方法：

十进制与其他进制的转换

1. 十进制转二进制（除 2 取余法）

核心步骤：将十进制数反复除以 2，记录每次的余数，直到商为 0，最后将余数从后往前排列。

示例：将十进制数94转为二进制

• 计算过程：

  94 ÷ 2 = 47  余数 0  
  47 ÷ 2 = 23  余数 1  
  23 ÷ 2 = 11  余数 1  
  11 ÷ 2 = 5   余数 1  
  5 ÷ 2 = 2    余数 1  
  2 ÷ 2 = 1    余数 0  
  1 ÷ 2 = 0    余数 1

• 结果：余数从后往前排列 → 1011110（即 94D = 1011110B）。

2. 十进制转八进制（除 8 取余法）

核心步骤：类似二进制转换，将十进制数反复除以 8，记录余数，最后从后往前排列。

广告系统的平台架构：核心模块与协同机制

广告系统是连接广告主（需求方）、媒体（流量方）和用户（受众）的复杂生态，其架构设计需满足高并发、精准定向、数据实时性等核心需求。一个完整的广告平台通常围绕业务支撑、数据处理、投放执行、效果监测四大核心模块展开，各模块协同实现广告从创建到投放再到效果分析的全生命周期管理。

核心参与角色与架构设计目标

核心角色

• 广告主：需求方，希望通过广告获取用户转化（如销售、下载、咨询），关注投放效果与成本。
• 媒体：流量方，提供广告展示位置（如 App、网站、短视频），关注流量变现效率。
• 平台：连接广告主与媒体的中间层，负责广告投放、数据统计、策略优化等核心功能。

架构设计目标

• 高效匹配：将合适的广告在合适的时机推送给合适的用户。
• 数据驱动：基于用户行为和投放数据优化策略，提升 ROI（投资回报率）。
• 稳定可靠：支持高并发请求（如峰值千万级 QPS），确保广告正常曝光。
• 灵活扩展：适配多类型媒体（图文、视频、信息流）和广告形式（横幅、原生、搜索）。

四大核心平台架构详解

业务平台：广告全生命周期的业务支撑

定位：面向运营 / 执行人员的操作入口，负责广告投放的全流程配置与管理。

Log4j2 自动删除日志文件：配置策略与最佳实践

线上系统日志文件持续增长，若不及时清理会导致磁盘空间耗尽，影响服务稳定性。Log4j2 的DefaultRolloverStrategy中内置了Delete操作，支持在日志滚动时自动清理过期文件，无需手动干预。本文详细解析自动删除配置的核心参数、注意事项及实战案例。

自动删除日志的核心原理

Log4j2 的自动删除功能依赖DefaultRolloverStrategy中的<Delete>标签，其工作机制是：
当日志滚动触发时（如达到时间或大小阈值），执行预定义的删除规则，清理符合条件的旧日志文件。

• 触发时机：与日志滚动同步，仅在滚动发生时执行删除（避免频繁检查磁盘）；
• 删除规则：通过<IfFileName>（文件名匹配）和<IfLastModified>（修改时间匹配）组合筛选文件；
• 安全性：支持配置目录扫描深度和文件匹配规则，避免误删非日志文件。

<Delete>标签核心配置参数

<Delete>标签的配置决定了删除范围和条件，关键参数如下：

自动删除配置示例与解析

以下是生产环境常用的自动删除配置，结合日志滚动策略实现 “按时间归档 + 大小限制 + 自动清理” 的完整流程：

Log4j2 日志文件滚动详解：触发策略与滚动策略的完整实践

在生产环境中，日志文件若持续写入会导致单文件体积过大，不仅占用大量磁盘空间，还会导致日志查询和分析效率低下。Log4j2 的RollingFileAppender通过日志滚动机制，按时间、大小等条件自动分割日志文件，是解决这一问题的核心方案。本文详细解析日志滚动的触发策略（TriggeringPolicy）和滚动策略（RolloverStrategy），并结合配置示例说明实战用法。

日志滚动的核心概念

日志滚动的本质是：当满足预设条件时，RollingFileAppender停止向当前日志文件（fileName指定）写入，转而创建新文件继续写入，并对旧文件按规则命名和归档。核心依赖两大组件：

• 触发策略（TriggeringPolicy）：决定 “何时” 触发滚动（如文件达到 1GB、时间到凌晨 0 点）；
• 滚动策略（RolloverStrategy）：决定 “如何” 滚动（如旧文件命名规则、保留数量、自动清理）。

触发策略（TriggeringPolicy）：何时触发滚动

触发策略定义滚动的触发条件，Log4j2 提供 5 种常用策略，可单独或组合使用（通过<Policies>标签组合）。

1. TimeBasedTriggeringPolicy：基于时间触发（最常用）

核心逻辑：根据日志文件命名格式（filePattern）中的时间粒度，定时触发滚动（如按天、按小时）。

关键特性：

• 依赖filePattern中的时间占位符（如%d{yyyyMMdd}表示按天，%d{yyyyMMddHH}表示按小时）；
• 滚动时机由时间粒度决定，与日志是否写入无关（即使无日志，到时间也会触发空文件滚动）；
• 支持interval（滚动间隔）和modulate（时间对齐）参数。

配置示例：

深入解析 “nf_conntrack: table full, dropping packet” 报错及解决方案

在高并发网络场景中，Linux 服务器有时会出现 nf_conntrack: table full, dropping packet 错误，导致应用连接失败（如 MySQL 通信链路中断）。本文将从原理、参数、解决方案三个维度详细解析该问题，帮助彻底解决此类网络故障。

问题本质：连接跟踪表耗尽

1. nf_conntrack 模块的作用

nf_conntrack 是 Linux 内核中的连接跟踪模块，主要用于：

• 跟踪网络连接的状态（如 TCP 连接的建立、关闭、超时等）；
• 在 NAT（网络地址转换）场景下，记录源 / 目标 IP、端口等信息，确保数据包能正确转发；
• 为防火墙（如 iptables）提供连接状态信息（如 --state ESTABLISHED 规则）。

该模块通过哈希表存储连接信息，每条记录包含连接的源地址、目标地址、端口、协议、状态等关键信息。

2. 报错原因：哈希表容量不足

当系统中的网络连接数量超过 nf_conntrack_max（哈希表最大条目数）时，哈希表会被填满，新的连接无法被跟踪，内核会丢弃新连接的数据包，从而触发 nf_conntrack: table full, dropping packet 错误。

在高并发场景下（如用户提到的 “访问量较高的项目”），默认参数极易触发该问题：

• 默认 nf_conntrack_max 通常为 65535（受系统内存限制，小内存机器可能更低）；
• 默认 nf_conntrack_tcp_timeout_established（已建立连接的超时时间）为 432000 秒（5 天），意味着即使连接已闲置，仍会在哈希表中保留 5 天，长期占用条目。

关键参数解析