gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

月度归档3月 2025

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  2025   /  
  • 3月
Java 3月 31,2025

SpringBoot打包冲突导致找不到主类问题分析与解决

在Java开发中,使用Maven构建SpringBoot应用时,经常会遇到”找不到或无法加载主类”的错误。这个问题通常与打包配置有关,特别是当项目同时使用了多个打包插件时。本文将深入分析这一问题的原因和解决方案。

问题现象

当我们使用命令java -cp target/xxx-jar-with-dependencies.jar com.example.MainClass 运行应用时,出现以下错误:

错误: 找不到或无法加载主类 com.example.MainClass

这表明Java虚拟机无法在指定的JAR包中找到主类,即使该类确实存在于源代码中。

原因分析

1. SpringBoot打包机制与传统打包的冲突

SpringBoot应用使用spring-boot-maven-plugin 打包时,会将类文件放在BOOT-INF/classes 目录下,而不是传统JAR包的根目录。这导致使用-cp 参数指定类路径时,JVM无法在预期位置找到主类。

2. 多插件打包导致的结构混乱

当项目同时配置了spring-boot-maven-plugin 和maven-assembly-plugin 时,两个插件会各自执行打包逻辑,可能导致最终JAR包结构不符合预期。特别是,maven-assembly-plugin 可能无法正确处理SpringBoot的特殊目录结构。

3. 主类声明位置不正确

在Maven配置中,主类可以在多个位置声明:

  • spring-boot-maven-plugin 的<configuration><mainClass> 元素
  • maven-assembly-plugin 的<archive><manifest><mainClass> 元素
  • maven-jar-plugin 的<archive><manifest><mainClass> 元素
    如果这些配置不一致或缺失,可能导致生成的JAR包中没有正确的主类信息。

解决方案

1. 禁用SpringBoot重新打包功能

如果使用maven-assembly-plugin 创建包含依赖的JAR包,可以禁用SpringBoot的重新打包功能:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <skip>true</skip>
    </configuration>
</plugin>

2. 使用正确的运行命令

对于SpringBoot应用,应使用java -jar 命令而非java -cp 命令:

java -jar target/application.jar

3. 统一打包策略

选择一种打包策略并坚持使用:

  • 使用SpringBoot的打包机制:依赖spring-boot-maven-plugin
  • 使用传统打包:依赖maven-assembly-plugin 或maven-shade-plugin
    避免混合使用多种打包插件,以防止目录结构冲突。

4. 检查类路径和包名

确保源代码中的包名与Maven配置中声明的主类包名完全一致,包括大小写。同时,验证编译后的类文件确实存在于JAR包中的预期位置。

作者 east
bug清单 3月 23,2025

解决error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

问题分析

libc.so.6 是 Linux 系统中 GNU C 库(glibc)的核心动态链接库,几乎所有基础命令(如 ls、mv、cp 等)都依赖此库。若因误操作将其重命名或删除,会导致系统命令无法运行,并报错:

basherror while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

解决方案

1. ​若当前终端会话未断开

如果仍能通过 SSH 或其他方式登录系统(未关闭当前终端窗口),可通过以下步骤直接修复:

  1. ​临时指定动态库路径:
    使用 LD_PRELOAD 环境变量强制指定一个可用的 glibc 库(如原文件的备份)
export LD_PRELOAD=/lib64/libc-2.xx.so.backup  # 替换为你的备份文件路径
  1. ​恢复原文件名:
    通过 mv 或 ln 命令将重命名的文件恢复为 libc.so.6
mv /lib64/libc.so.6.backup /lib64/libc.so.6 # 或重建软链接(适用于软链接被破坏的情况) 
ln -sf /lib64/libc-2.xx.so /lib64/libc.so.6

2. ​若终端会话已断开或系统崩溃

如果已无法登录系统(如 SSH 断开或系统重启后无法进入),需通过 ​救援模式(Rescue Mode)​ 或 ​Live CD 修复:

  1. ​进入救援模式:
    • 使用系统安装盘或 Live CD 启动,选择 “Rescue installed system” 或类似选项。
    • 挂载原系统的根分区到 /mnt/sysimage。
  2. ​手动修复文件:
chroot /mnt/sysimage  # 切换到原系统环境
 mv /lib64/libc.so.6.backup /lib64/libc.so.6  # 恢复文件名 # 或重建软链接 ln -sf /lib64/libc-2.xx.so /lib64/libc.so.6

  1. ​重启系统:
    执行 reboot 并移除安装介质5。

3. ​注意事项与预防措施

  • ​避免直接覆盖系统库:
    如通过 scp 或其他方式覆盖 libc.so.6,可能导致版本不兼容(如高版本替换低版本),进而引发系统崩溃5。
  • ​备份关键文件:
    对 /lib64 目录下的核心库(如 libc.so.6、ld-linux-x86-64.so.2)定期备份。
  • ​使用容器隔离风险:
    在测试或生产环境中,优先使用 Docker 容器运行依赖高版本 glibc 的应用,避免直接修改系统库2。
作者 east
bug清单, 运维 3月 23,2025

解决Error: /usr/lib64/libc.so.6: version `GLIBC_2.18′ not found

在centos运行node应用,分析下面报错并给出解决方案:node:internal/modules/cjs/loader:1282 return process.dlopen(module, path.toNamespacedPath(filename)); ^ Error: /usr/lib64/libc.so.6: version `GLIBC_2.18′ not found (required by /home/wwwroot/gitweixin/tool/svg2jpgApi/node_modules/canvas/build/Release/librsvg-2.so.2) at Object.Module._extensions..node (node:internal/modules/cjs/loader:1282:18) at Module.load (node:internal/modules/cjs/loader:1076:32) at Function.Module._load (node:internal/modules/cjs/loader:911:12) at Module.require (node:internal/modules/cjs/loader:1100:19) at require (node:internal/modules/cjs/helpers:119:18) at Object.<anonymous> (/home/wwwroot/gitweixin/tool/svg2jpgApi/node_modules/canvas/lib/bindings.js:3:18) at Module._compile (node:internal/modules/cjs/loader:1198:14) at Object.Module._extensions..js (node:internal/modules/cjs/loader:1252:10) at Module.load (node:internal/modules/cjs/loader:1076:32) at Function.Module._load (node:internal/modules/cjs/loader:911:12) { code: ‘ERR_DLOPEN_FAILED’

在CentOS上运行Node应用时遇到的GLIBC版本问题,可以通过以下步骤解决:

错误分析

  • 根本原因:应用依赖的canvas模块需要GLIBC_2.18,但当前系统的GLIBC版本过低(如CentOS 7默认使用GLIBC 2.17)。
  • 影响:系统缺失所需GLIBC版本,导致Node无法加载原生模块(librsvg-2.so.2)。

解决方案

方法1:重新构建canvas模块(推荐优先尝试)

  1. 安装构建依赖:bash复制sudo yum install -y gcc-c++ cairo cairo-devel libjpeg-turbo-devel pango pango-devel giflib-devel
  2. 重新编译canvas:bash复制# 删除现有模块并重新安装 rm -rf node_modules npm install
    • 如果问题依旧,尝试强制重建原生模块:bash复制npm rebuild canvas –update-binary

方法2:升级GLIBC(谨慎操作)

警告:升级GLIBC可能导致系统不稳定,仅建议在测试环境中使用。

  1. 下载并编译GLIBC 2.18:bash复制# 安装依赖 sudo yum install -y bison make gcc # 下载源码 wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.gz tar -xzf glibc-2.18.tar.gz cd glibc-2.18 # 编译安装(指定目录避免覆盖系统文件) mkdir build && cd build ../configure –prefix=/opt/glibc-2.18 make -j4 sudo make install
  2. 临时指定GLIBC路径运行Node应用:bash复制LD_LIBRARY_PATH=/opt/glibc-2.18/lib node your-app.js

方法3:使用Docker容器(推荐生产环境)

通过Docker隔离环境,避免修改宿主机GLIBC。

  1. 创建Dockerfile:Dockerfile复制FROM centos:7 # 安装依赖 RUN yum install -y gcc-c++ cairo cairo-devel libjpeg-turbo-devel pango pango-devel giflib-devel # 安装Node.js RUN curl -sL https://rpm.nodesource.com/setup_14.x | bash – RUN yum install -y nodejs # 复制应用代码 WORKDIR /app COPY package*.json ./ RUN npm install COPY . . CMD [“node”, “your-app.js”]
  2. 构建并运行容器:bash复制docker build -t node-app . docker run -it –rm node-app

方法4:使用第三方仓库(如SCL)

CentOS 7可通过Software Collections(SCL)获取较新工具链。

  1. 启用SCL仓库:bash复制sudo yum install -y centos-release-scl
  2. 安装高版本开发工具链:bash复制sudo yum install -y devtoolset-8
  3. 使用新工具链编译应用:bash复制scl enable devtoolset-8 bash rm -rf node_modules npm install

总结建议

  • 推荐方案:优先尝试方法1(重新构建)或方法3(Docker),避免直接升级GLIBC的风险。
  • 生产环境:强烈建议使用Docker容器化部署,确保环境一致性。
  • 备用方案:若必须升级GLIBC,务必在测试环境中验证稳定性。
作者 east
前端 3月 11,2025

分享一款自己开发并觉得好用的SVG转图片在线工具

​

 最近用Cursor利用Claude 3.7生成流程图、框架图,Cursor生成的只是svg代码,不是直接生成jpg等格式的图片,但有时候我们需要把它们转换成更常见的图片格式,比如JPG、PNG或者WebP,方便在各种地方使用。比如发个朋友圈、插个文档,或者上传到那些“老古董”网站(你懂的,它们还不支持SVG)。找了一下现在的svg转图片,基本都是上传文件的,不能直接粘贴复制cursor的svg代码的,觉得有些麻烦,根据自己需求开发这款SVG转图片在线工具,觉得简单好用。

SVG转图片在线工具

​

作者 east
总线 3月 9,2025

UART、SPI 和 I2C深度探索

通信接口是电子设备之间数据交换的基础,常见的接口如 UART、SPI 和 I2C 各有独特的技术特性和适用场景。以下是对这些接口的详细技术分析。

UART(通用异步收发传输器)

UART 是一种异步串行通信协议,广泛用于简单的点对点通信。

  • 波特率
    波特率是 UART 通信的核心参数,表示每秒传输的位数,常见值包括 9600、19200、38400、57600 和 115200 bps。波特率的选择需要权衡传输速度和可靠性。例如,低波特率(如 9600 bps)适用于长距离通信,因为信号衰减和噪声干扰较少;而高波特率(如 115200 bps)适合短距离高速传输,但对时钟精度要求更高。
  • 数据帧格式
    UART 的数据帧由以下部分组成:
    • 起始位:1 位,标志数据帧开始,通常为低电平。
    • 数据位:5 到 8 位,承载实际数据,8 位最为常见。
    • 奇偶校验位:可选,用于错误检测,可以是奇校验、偶校验或无校验。
    • 停止位:1 或 2 位,标志数据帧结束,通常为高电平。
      例如,一个典型配置可能是“8N1”,即 8 位数据、无校验、1 位停止位。
  • 流控制
    UART 支持两种流控制机制:
    • 硬件流控制:使用 RTS(请求发送)和 CTS(允许发送)信号线,避免数据溢出。
    • 软件流控制:使用 XON/XOFF 字符控制数据流,适用于无额外引脚的场景。
  • 错误检测
    UART 的错误检测主要依赖奇偶校验,但仅能发现错误,无法纠正。对于更高可靠性需求的应用,可引入 CRC(循环冗余校验)等机制。

SPI(串行外设接口)

SPI 是一种同步串行通信协议,以其高速度和简单性著称,适用于主从架构。

  • 时钟极性和相位
    SPI 有四种工作模式,由时钟极性(CPOL)和时钟相位(CPHA)定义:
    • CPOL=0, CPHA=0:时钟空闲为低电平,数据在上升沿采样。
    • CPOL=0, CPHA=1:时钟空闲为低电平,数据在下降沿采样。
    • CPOL=1, CPHA=0:时钟空闲为高电平,数据在下降沿采样。
    • CPOL=1, CPHA=1:时钟空闲为高电平,数据在上升沿采样。
      这些模式需在主从设备间保持一致。
  • 传输模式
    SPI 支持:
    • 全双工:MOSI(主出从入)和 MISO(主入从出)同时传输数据。
    • 半双工:MOSI 或 MISO 交替传输。
    • 单工:仅使用一条数据线传输。
  • 片选信号
    SPI 通过片选信号(SS/CS)选择从设备。主设备拉低 SS 激活从设备,拉高 SS 释放从设备。多从设备场景下,每个从设备需独立 SS 引脚。
  • 数据传输
    SPI 以字节为单位传输,SCLK(时钟信号)控制传输速率,无需帧间间隔,适合高速连续数据传输。

I2C(内部集成电路)

I2C 是一种多主多从的串行通信协议,以引脚少和灵活性著称。

  • 总线结构
    I2C 使用两条线:
    • SDA(数据线):传输数据。
    • SCL(时钟线):同步时钟。
      两者采用开漏设计,需上拉电阻维持高电平。
  • 地址机制
    I2C 支持:
    • 7 位地址:范围 0x00 到 0x7F,支持 128 个设备。
    • 10 位地址:范围 0x000 到 0x3FF,支持更多设备。
      主设备通过地址帧选择从设备。
  • 通信过程
    • 起始条件:SDA 从高到低跳变,SCL 保持高电平。
    • 数据传输:每字节后,从设备发送 ACK(应答位,低电平表示成功)。
    • 停止条件:SDA 从低到高跳变,SCL 保持高电平。
  • 时钟同步
    I2C 支持多主竞争,总线上的主设备通过拉低 SCL 同步时钟,确保通信稳定。
  • 错误检测
    通过 ACK 机制检测传输错误,若从设备未应答(NACK),主设备可重试或中止通信。
作者 east
自媒体 3月 8,2025

《纳瓦尔宝典》解密自媒体盈利困境与破局策略

《纳瓦尔宝典》强调“复制边际成本为零的产品”是普通人致富的核心杠杆,而自媒体作为典型的媒介杠杆工具,理论上能突破时间和空间限制,实现“睡后收入”。然而现实中,自媒体行业呈现明显的“二八效应”,大部分从业者难以盈利。结合书中观点与行业现状,具体原因及破局方法如下:

一、原因分析

  1. 同质化竞争与低价值内容泛滥
    自媒体门槛低导致大量内容集中在浅层领域(如娱乐、搬运、鸡汤),缺乏独特价值。纳瓦尔强调“专长”需通过兴趣和热爱培养,且必须提供社会“有需求但无从获得的东西”。多数人未能找到差异化定位,陷入低水平重复竞争。
  2. 缺乏持续输出与复利积累
    自媒体需要长期投入,但多数人追求短期爆款,忽视复利效应。纳瓦尔指出“生活中所有回报(财富、知识等)都来自复利”,而自媒体内容的累积流量、品牌信任度需时间沉淀。许多人因初期收益低而放弃,未能等到拐点。
  3. 流量分配机制与算法依赖
    平台算法倾向于头部创作者,新人获客成本高。纳瓦尔提出“独辟蹊径才能避开竞争压力”,但多数人选择热门赛道(如美妆、带货),未探索垂直细分领域或创新形式。
  4. 变现路径模糊与商业思维缺失
    自媒体盈利依赖广告、带货、知识付费等模式,但许多人缺乏产品化思维。纳瓦尔认为“财富是睡后收入的资产”,需将内容转化为可复用的产品(如课程、版权、IP授权),而非单纯依赖流量分成。

二、破局策略

  1. 定位差异化:从“泛领域”转向“垂直专长”
    • 挖掘个人禀赋:结合纳瓦尔提出的“专长=兴趣+市场需求”,找到自身技能与受众痛点的交集(如小众技能、行业经验、独特视角)。例如,程序员分享AI工具实操,而非泛泛而谈科技趋势。
    • 内容稀缺性:提供高信息密度内容(如深度行业报告、独家方法论),避免同质化。例如,财经博主可聚焦“普通人可复制的投资策略”,而非泛泛解读政策。
  2. 构建产品化内容矩阵
    • 分层变现体系:免费内容引流(如短视频)、中阶付费产品(专栏、社群)、高阶服务(咨询、培训),形成漏斗模型。
    • 边际成本为零的产品:将内容封装为电子书、模板工具包、音频课等,一次创作多次销售。
  3. 利用复利效应与平台协同
    • 跨平台分发:同一内容适配不同形式(文字→视频→直播),覆盖多场景用户。例如,知乎长文可拆解为抖音脚本,再转化为直播案例。
    • 品牌化运营:通过统一人设、视觉符号(如LOGO、Slogan)强化记忆点,提升用户黏性。
  4. 提升商业判断力与杠杆组合
    • 混合杠杆策略:结合劳动力杠杆(团队分工)、资本杠杆(广告投放)、媒介杠杆(内容IP),例如头部博主组建MCN机构,放大规模效应。
    • 数据驱动决策:分析用户行为数据(完播率、转化率),迭代内容策略,而非依赖主观经验。
  5. 长期主义与反脆弱心态
    • 接受非线性质变:纳瓦尔强调“99%的努力可能白费”,但1%的关键突破足以改变轨迹。例如,“半佛仙人”早期默默写作多年,最终因一篇爆款破圈。
    • 风险对冲机制:多元化收入来源(如广告+版权+咨询),降低对单一平台的依赖615。

三、典型案例参考

  • 知识付费领域:博主“L先生说”通过心理学深度文章积累粉丝,后推出高价课程,年营收超千万,验证了“高价值内容+产品化”路径。
  • 小众垂类突围:B站UP主“老师好我叫何同学”以硬核科技评测+人文视角差异化定位,单条广告报价超百万,证明垂直领域的商业潜力。

总结

自媒体的核心矛盾在于“低门槛与高成功率的不可兼得”,破局需回归纳瓦尔提出的底层逻辑:专长×杠杆×判断力。通过差异化定位、产品化思维和复利积累,普通人仍有机会在红海市场中构建可持续的财富管道。正如书中所言:“现代人的二分法是‘利用杠杆的人’和‘没有利用杠杆的人’”。


作者 east
doris 3月 6,2025

Apache Doris内存与超时参数配置详解

以下是根据你的需求整理的Apache Doris内存与超时参数配置详解,结合了相关技术文档和实践经验:

一、查询任务内存限制调整

1. ​默认内存限制与问题定位

Apache Doris默认限制单个BE节点上的查询任务内存使用不超过2GB(即exec_mem_limit=2147483648字节)。当复杂查询或大规模数据操作超过此限制时,会触发Memory limit exceeded错误。通过以下命令可查看当前配置:

SHOW VARIABLES LIKE "%mem_limit%";

输出示例:

+----------------+------------+
| Variable_name  | Value      |
+----------------+------------+
| exec_mem_limit | 2147483648 |  -- 默认2GB
| load_mem_limit | 0          |  -- 导入任务内存限制(0表示无限制)
+----------------+------------+

2. ​调整内存限制的方法

  • ​临时调整(当前会话生效)​​
    通过SET命令修改会话级参数,适用于单次查询优化:sqlSET exec_mem_limit = 8589934592; -- 设置为8GB
  • ​永久生效(全局配置)​​
    添加GLOBAL参数以全局生效,需在FE节点配置中持久化:sqlSET GLOBAL exec_mem_limit = 8589934592;​
  • 注意事项:
    • 若集群资源有限,需结合BE节点的总内存(通过mem_limit参数控制)合理分配,避免单任务占用过高导致节点OOM6。
    • 高并发场景建议通过资源标签(Resource Label)隔离关键任务,防止资源争用6。

二、查询超时时间优化

1. ​默认超时机制与配置查询

Doris默认查询超时时间为300秒(5分钟),可通过以下命令查看:

sqlSHOW VARIABLES LIKE "%query_timeout%";

输出示例:

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| query_timeout | 300   |
+---------------+-------+

2. ​延长超时时间的操作

  • ​临时调整(当前会话生效)​​sqlSET query_timeout = 600; -- 设置为600秒(10分钟)
  • ​永久生效(全局配置)​​sqlSET GLOBAL query_timeout = 600;​动态生效特性:与内存参数不同,超时参数修改后通常无需重启集群即可生效7。

三、关联参数与调优实践

1. ​内存管理联动配置

  • ​BE节点总内存限制(mem_limit)​​
    控制单个BE进程的最大内存使用,默认根据物理内存自动计算(如物理内存的90%或物理内存-6.4GB)。建议在be.conf中显式设置,避免资源竞争4。bashmem_limit = 80% # 或具体值如32G
  • ​Compaction内存限制(compaction_memory_bytes_limit)​​
    控制数据合并任务的内存使用上限,默认值根据系统配置动态调整。若频繁因Compaction导致查询内存不足,可适当调低此参数5。

2. ​高并发场景优化策略

  • ​并行度与资源分配​
    提升查询并行度(parallel_degree)可加速处理,但需平衡CPU和内存消耗。例如:sqlSET GLOBAL parallel_degree = 16; -- 根据CPU核心数调整
  • ​物化视图与分区优化​
    对高频查询创建物化视图或合理分区,减少单次查询的数据扫描量,间接降低内存需求6。

四、操作验证与监控

  1. ​验证参数生效​
    修改后通过SHOW VARIABLES确认新值是否生效,并执行测试查询观察内存使用情况。
  2. ​日志与监控工具​
    • ​FE日志:检查fe.log中内存超限或超时任务记录3。
    • ​BE监控:通过curl http://BE_IP:8040/api/compaction/show?tablet_id=XXX查看Tablet状态3。
    • ​系统视图:使用SHOW PROC '/admin/stats'实时监控资源使用6
作者 east
自媒体 3月 5,2025

自媒体收入达到多少时需要注册公司及运营公司成本

在中国,注册公司运营自媒体并利用公司资质进行税务优化,需综合考虑注册成本、维护费用及税费临界点。以下分析基于财税政策及临界点信息:

一、最低成本注册及维护公司的方案

  1. 公司类型选择
    • 推荐注册有限责任公司(小微企业),可享受小型微利企业税收优惠(年利润≤300万,企业所得税5%1923)。
    • 注册资本:采用认缴制,无需实缴,建议填写10万元以下。
  2. 注册成本
    • 注册地址:使用家庭地址或租赁虚拟地址(年费用约1000-3000元)[需结合当地政策]。
    • 代办费用:委托代理公司办理约500-2000元(含营业执照、刻章等)。
    • 银行开户:免费或收取少量手续费(约300-500元)。
  3. 每月维护成本
    • 代理记账:200-500元/月(含税务申报)。
    • 社保公积金:若仅法人参保,按最低基数缴纳约1500-2000元/月(可暂缓缴纳,但需符合政策要求)。
    • 其他费用:年检、残保金(职工≤30人免缴11223)等。

二、注册公司的必要性分析:收入临界点

是否需要注册公司,主要取决于收入规模及税负优化需求。结合财税政策,关键临界点如下:

  1. 增值税临界点
    • 小规模纳税人:季度销售额≤30万(普票)免征增值税;超过则全额缴税(税率1%)1918。
    • 建议:若季度收入接近30万(年120万),注册公司可拆分收入或控制开票额以享受免税。
  2. 企业所得税临界点
    • 年利润≤300万:税率5%;超过300万:税率25%1923。
    • 建议:若年利润接近300万,需通过公司形式分散利润(如多注册个体户或关联公司)。
  3. 个人所得税优化
    • 个人自媒体收入按“劳务报酬”计税(最高税率45%),而公司可通过分红(税率20%)或合理工资发放优化税负1118。

三、注册公司的收入临界值建议

  1. 收入≥10万元/年
    • 若收入稳定且需开具发票,建议注册公司以合规经营并享受小规模纳税人免税政策。
  2. 收入≥50万元/年
    • 需注册公司以规避高额个人所得税(劳务报酬税负高于企业所得税+分红)。
  3. 收入≥120万元/年(季度30万)
    • 必须注册公司,避免因超过小规模纳税人季度30万免税额度导致全额缴税11823。

四、综合建议

  • 低风险方案:收入较低时(如年收入<50万),可暂以个人名义运营;若需开票或品牌化,注册个体户(成本更低,但无分红优势)。
  • 高增长方案:收入快速增长或预计年利润接近300万时,尽早注册公司,利用小型微利企业税率及增值税免税政策优化税负。
作者 east
bug清单, Flink 3月 5,2025

解决Flink SQL:Exception in thread “main” org.apache.flink.table.api.ValidationException: Rowtime attribute ‘ptime’ must be of type TIMESTAMP or TIMESTAMP_LTZ but is of type ‘BIGINT’.

在开发Flink SQL时报错:

在flink 1.16版本中执行报错:Exception in thread "main" org.apache.flink.table.api.ValidationException: Rowtime attribute 'ptime' must be of type TIMESTAMP or TIMESTAMP_LTZ but is of type 'BIGINT'.

	at org.apache.flink.table.api.TableSchema.validateColumnsAndWatermarkSpecs(TableSchema.java:535)

	at org.apache.flink.table.api.TableSchema.access$100(TableSchema.java:73)

	at org.apache.flink.table.api.TableSchema$Builder.build(TableSchema.java:802)

	at org.apache.flink.table.planner.operations.MergeTableLikeUtil$SchemaBuilder.build(MergeTableLikeUtil.java:534)

	at org.apache.flink.table.planner.operations.MergeTableLikeUtil.mergeTables(MergeTableLikeUtil.java:154)

	at org.apache.flink.table.planner.operations.SqlCreateTableConverter.createCatalogTable(SqlCreateTableConverter.java:171)

	at org.apache.flink.table.planner.operations.SqlCreateTableConverter.convertCreateTable(SqlCreateTableConverter.java:74)

	at org.apache.flink.table.planner.operations.SqlToOperationConverter.convertValidatedSqlNode(SqlToOperationConverter.java:330)

	at org.apache.flink.table.planner.operations.SqlToOperationConverter.convert(SqlToOperationConverter.java:282)

	at org.apache.flink.table.planner.delegation.ParserImpl.parse(ParserImpl.java:106)

	at org.apache.flink.table.api.internal.TableEnvironmentImpl.executeSql(TableEnvironmentImpl.java:758)

	at com.chuneng.saas.doris.FlinkDorisExtremeValueCalculation.main(FlinkDorisExtremeValueCalculation.java:44)

原因分析

错误的核心在于:Flink 要求用于定义 WATERMARK 的字段必须是 TIMESTAMP 或 TIMESTAMP_LTZ 类型,但你的 ptime 字段被定义为 BIGINT 类型。尽管你在 WATERMARK 中尝试将 ptime 转换为 TIMESTAMP,但 Flink 的 WATERMARK 语法要求直接引用一个已经存在的 TIMESTAMP 类型字段,而不是在 WATERMARK 定义中动态转换类型。

解决方案

你需要通过 计算列(Computed Column) 将 ptime 的 BIGINT 类型转换为 TIMESTAMP 类型,然后将 WATERMARK 绑定到计算列上。

例如像下面这样:

String sourceDDL = "CREATE TABLE ods_t_iot_data (" +
        "pid STRING," +
        "pvalue DECIMAL(13,3)," +
        "ptime BIGINT," +
        "ds DATE," +
        // 定义计算列,将 BIGINT 类型的 ptime 转换为 TIMESTAMP
        "event_time AS TO_TIMESTAMP(FROM_UNIXTIME(ptime / 1000))," + 
        // 绑定 WATERMARK 到计算列 event_time
        "WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND" +
        ") WITH (" +
        "'connector' = 'doris'," +
        "'fenodes' = '10.0.0.1:8030'," +
        "'table.identifier' = 'cnsaas.ods_t_iot'," +
        "'username' = 'root'," +
        "'password' = ''" +
        ")";
作者 east
bug清单, Flink 3月 5,2025

解决Flink SQL报错”Exception in thread “main” java.lang.IllegalStateException: please declare primary key for sink table when query contains update/delete record”

在开发Flink SQL时报错”Exception in thread “main” java.lang.IllegalStateException: please declare primary key for sink table when query contains update/delete record”

这个错误表明您的Flink作业涉及更新或删除操作(如CDC场景),而JDBC Sink表没有定义主键。以下是详细分析和解决方案:

错误原因分析

当Flink作业涉及UPDATE/DELETE操作时(常见于CDC场景或使用Retract流),JDBC Sink表必须显式声明主键,因为:

  1. 主键用于定位目标数据库中需要更新的记录
  2. 没有主键时,Flink无法确定如何执行更新/删除操作

解决方案

在表定义中添加 PRIMARY KEY 声明(需与目标数据库表主键一致),例如:

val sinkDDL =
  """
    |CREATE TABLE dws_iot_extreme_info_min (
    |  device_code STRING,
    |  `day` DATE,
    |  ptime BIGINT,
    |  station_sn STRING,
    |  unit STRING,
    |  cu_device_code STRING,
    |  max_u_value DECIMAL(5,3),
    |  min_u_value DECIMAL(5,3),
    |  max_t_value DECIMAL(5,2),
    |  min_t_value DECIMAL(5,2),
    |  max_soc_value DECIMAL(5,2),
    |  min_soc_value DECIMAL(5,2),
    |  max_u_time BIGINT,
    |  min_u_time BIGINT,
    |  max_t_time BIGINT,
    |  min_t_time BIGINT,
    |  max_soc_time BIGINT,
    |  min_soc_time BIGINT,
    |  dt DATE,
    |  PRIMARY KEY (device_code, `day`) NOT ENFORCED  -- 添加主键声明
    |) WITH (
    |  'connector' = 'jdbc',
    |  'url' = 'jdbc:mysql://10.0.2.2:3306/cnsaas',
    |  'table-name' = 'dws_bigdata_device_extreme_info_min',
    |  'driver' = 'com.mysql.cj.jdbc.Driver',
    |  'username' = 'root',
    |  'password' = '',
    |  'sink.buffer-flush.max-rows' = '1000',    
    |  'sink.buffer-flush.interval' = '1s',      
    |  'sink.max-retries' = '3'                 
    |)
    |""".stripMargin

关键修改点说明

  1. 主键声明:PRIMARY KEY (device_code, `day`) NOT ENFORCED
    • 主键字段需与目标数据库表的主键一致
    • NOT ENFORCED 表示Flink不会校验数据主键约束,由数据库负责
  2. 目标表要求:
    • MySQL数据库中 dws_iot_extreme_info_min 表必须有相同的主键定义
    • 可通过以下SQL确保主键存在:
    • ALTER TABLE dws_iot_extreme_info_min ADD PRIMARY KEY (device_code, day);
作者 east
Flink 3月 5,2025

Flink Checkpoint 详解

一、Checkpoint 的原理

  1. 核心概念
    Checkpoint 是 Flink 的容错机制,通过定期生成分布式快照,记录流处理应用的全局状态(算子状态、键控状态等)。当发生故障时,Flink 可从最近的 Checkpoint 恢复,保证 Exactly-Once 语义。
  2. 实现机制
    • Chandy-Lamport 算法:基于 Barrier 的分布式快照。
    • 流程:
      1. 触发:JobManager 定期触发 Checkpoint,向所有 Source 发送 Barrier。
      2. Barrier 传播:Source 插入 Barrier 到数据流,算子接收到 Barrier 后暂停处理新数据,将当前状态异步持久化。
      3. 状态存储:状态写入外部存储(如 HDFS、S3)。
      4. 确认机制:所有算子确认状态保存后,Checkpoint 完成。
  3. 一致性语义
    • EXACTLY_ONCE:精确一次,通过对齐 Barrier 确保状态与数据流严格一致。
    • AT_LEAST_ONCE:至少一次,可能重复处理数据。

二、Checkpoint 的使用方法

  1. 基础配置
    在 Flink 作业中启用 Checkpoint,设置间隔、存储路径和模式:
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// 启用 Checkpoint,间隔 60 秒
env.enableCheckpointing(60000);
// 配置 Exactly-Once 语义
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
// 设置 Checkpoint 存储路径
env.getCheckpointConfig().setCheckpointStorage("hdfs:///checkpoints/");
// 其他配置(超时时间、最小间隔等)
env.getCheckpointConfig().setCheckpointTimeout(30000);
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500);
  1. 状态后端选择
    • FsStateBackend:状态存储在内存,快照存于文件系统(适合状态较小场景)。
    • RocksDBStateBackend:状态存储在 RocksDB,支持超大状态(需权衡性能)。
  2. 恢复作业
    通过命令行或 API 从指定 Checkpoint 恢复作业:bash复制./bin/flink run -s hdfs:///checkpoints/1234 …

三、Checkpoint 的应用场景

  1. 容错恢复
    节点故障、网络中断时,从 Checkpoint 恢复状态,避免数据丢失。
  2. 有状态计算
    • 窗口聚合(如每小时销售额统计)。
    • 复杂事件处理(CEP)中的模式状态。
    • 连接操作(如流-流 Join 的中间状态)。
  3. 作业升级与扩缩容
    通过 Savepoint(手动触发的 Checkpoint)暂停作业,修改并行度或代码后恢复。

四、Flink SQL 流式写入数据到表时为何需要 Checkpoint

  1. 保障 Exactly-Once 语义
    • 当使用 Flink SQL 写入 Kafka、JDBC 表等外部系统时,Checkpoint 通过**两阶段提交协议(2PC)**协调事务:
      1. 预提交阶段:数据写入外部系统,但未提交。
      2. 提交阶段:Checkpoint 完成后,所有事务统一提交。
    • 若故障发生,Flink 回滚到上一个 Checkpoint,确保数据不重复、不丢失。
  2. 维护内部状态一致性
    • 即使目标表不支持事务(如 HBase),Checkpoint 仍保障 Flink 内部状态(如去重状态、窗口状态)的正确恢复。
  3. 避免数据丢失
    • 未启用 Checkpoint 时,若作业崩溃,可能丢失未持久化的状态和数据,导致写入结果不完整。

五、示例:Flink SQL 写入 Kafka

-- 启用 Checkpoint(隐式通过 ExecutionConfig)
SET 'execution.checkpointing.interval' = '60s';

-- 定义 Kafka Sink 表
CREATE TABLE kafka_sink (
    user_id STRING,
    count BIGINT
) WITH (
    'connector' = 'kafka',
    'topic' = 'output_topic',
    'properties.bootstrap.servers' = 'kafka:9092',
    'format' = 'json',
    'sink.transactional-id-prefix' = 'tx-' -- 启用 Kafka 事务
);

-- 流式写入
INSERT INTO kafka_sink 
SELECT user_id, COUNT(*) FROM clicks GROUP BY user_id;
  • 依赖 Checkpoint:Kafka Sink 通过事务提交机制与 Checkpoint 绑定,确保每条数据仅写入一次。

总结

  • Checkpoint 原理:基于 Barrier 的分布式快照,保障状态一致性。
  • 使用场景:容错、有状态计算、作业维护。
  • Flink SQL 写入表:Checkpoint 是保证端到端 Exactly-Once 的核心机制,协调外部系统事务与内部状态恢复。
作者 east
程序员网赚 3月 5,2025

AI时代,程序员优先做AI+应用还是用AI做付费课程?

在大模型各种神奇功能层出不穷的时代,程序员无疑是最早接触,全天候使用AI的群体,除了AI能加快开发效率,程序员怎样使用它来实现副业创收?

一、AI+应用开发

1. ​前景

  • ​技术红利期:2025年被认为是AI应用规模化落地元年,行业大模型、垂类工具(如智能客服、自动化办公)需求激增5。AI技术门槛降低(如调用成本降至2元/百万tokens),开源生态成熟,个人开发者可通过API快速集成功能。
  • ​细分领域机会:医疗、教育、金融等传统行业对AI工具需求明确(如自动代码生成、数据分析插件),小而美的工具型应用(如AI写作助手、营销素材生成器)更易切入4。

2. ​用户规模

  • ​潜力大但需精准定位:全球AI应用市场规模预计达千亿美元级,但需聚焦垂直场景(如电商、本地生活)。例如,AI营销工具可触达中小商家(中国超1亿市场主体),而个人效率工具(如笔记整理、代码优化)面向程序员群体本身即有天然用户池。

3. ​成本

  • ​初始投入低:利用云服务(如阿里云、AWS)和开源框架(如Hugging Face),硬件成本几乎为零;API调用成本可控(如DeepSeek输入成本2元/百万tokens)。
  • ​推广成本较高:需投入时间或资金进行产品冷启动(如GitHub开源引流、SEO优化),但可通过精准社群(如开发者论坛)降低获客难度。

4. ​时间付出

  • ​开发周期灵活:MVP(最小可行产品)可在1-3个月内完成,适合碎片化时间迭代。例如,基于现有大模型封装一个自动化脚本或插件,无需从头训练模型。
  • ​维护需求中等:需定期更新功能、修复BUG,但可通过自动化测试和用户反馈机制减少工作量。

5. ​可能收益

  • ​变现路径多元:SaaS订阅(如月费10-50元/用户)、一次性付费(工具包售卖)、API调用分成等。典型案例:某AI补光灯应用Pro版上线8小时收入16万元。
  • ​规模化潜力:成功案例单月收入可达数万元至数十万元,若切入高需求场景(如企业级自动化工具),收益天花板较高。

二、AI付费课程

1. ​前景

  • ​需求旺盛但竞争激烈:职场焦虑推动学习需求,2024年AI课程支出达14亿美元6,但课程同质化严重(如提示词教学、工具操作)。差异化方向:结合程序员优势开发技术向课程(如AI模型微调、私有化部署)。
  • ​政策风险:部分平台整治“割韭菜”课程,需注重内容合规性。

2. ​用户规模

  • ​目标人群明确:职场人士、转行群体、技术爱好者为主。例如,AI编程课可覆盖数百万开发者,但需与泛知识课程(如AI绘画)区分。
  • ​天花板较低:头部IP(如李一舟)占据大部分市场,普通人需依赖长尾流量或细分领域(如垂直行业解决方案)。

3. ​成本

  • ​内容制作成本低:录播课、文档教程制作门槛低,可利用ChatGPT辅助生成课件。
  • ​营销成本高:需投入时间运营社群、投放广告(如信息流广告单次点击成本约2-5元),或依赖平台分佣(如知识星球抽成30%)。

4. ​时间付出

  • ​前期投入集中:课程大纲设计、录制、剪辑需1-2个月全职等效时间,但后期可复用(如多平台分发)。
  • ​持续运营压力:需定期更新内容(如跟进新技术)、答疑互动,否则易被淘汰。

5. ​可能收益

  • ​初期收益快但天花板明显:入门课定价6.6-300元,转化率约1%-5%。典型案例:某AI写作课单价279元,17天售出1万份。
  • ​长尾效应有限:除非建立品牌IP,否则课程生命周期较短(通常3-6个月),需不断开发新课。

三、综合对比与建议

​维度​​AI+应用开发​​AI付费课程​
​技术壁垒​高(需编程能力+行业洞察)低(侧重内容包装)
​变现速度​中(需产品验证期)快(可预售课程)
​长期潜力​高(产品可规模化、复购率高)中(依赖持续获客)
​风险​技术迭代风险、市场竞争政策风险、同质化竞争
​适合人群​有技术积累、愿深耕细分领域的开发者擅长内容营销、能快速捕捉热点的创作者

​推荐策略:

  1. ​技术型程序员优先选应用开发:可结合自身技能开发工具(如代码优化插件、数据分析自动化脚本),利用GitHub、Product Hunt等平台冷启动,逐步迭代至商业化。
  2. ​兼顾两者:开发轻量AI工具后,配套录制使用教程(如《如何用AI自动化你的代码审查》),通过课程引流+工具付费变现。
  3. ​风险提示:避免选择重投入领域(如训练大模型),优先选择API集成型应用;课程需规避夸大宣传,侧重实战案例(如Kaggle竞赛解决方案)。

通过合理分配时间(如周末开发核心功能、工作日晚上维护),程序员可最大化利用技术优势,在AI浪潮中实现副业收益。

作者 east

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?
  • 嵌入式电机:如何在低速和高负载状态下保持FOC(Field-Oriented Control)算法的电流控制稳定?
  • C++如何在插件式架构中使用反射实现模块隔离?
  • C++如何追踪内存泄漏(valgrind/ASan等)并定位到业务代码?
  • C++大型系统中如何组织头文件和依赖树?

文章归档

  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (43)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (4)
  • 大数据开发 (488)
    • CDH (6)
    • datax (4)
    • doris (30)
    • Elasticsearch (15)
    • Flink (78)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (40)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (99)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (34)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (70)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (6)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.