11g的alert日志文件会自动拆分

最新推荐文章于 2025-11-26 13:50:39 发布
转载 最新推荐文章于 2025-11-26 13:50:39 发布 · 183 阅读 · 0
文章标签：

#数据库

本文记录了一次发现日志文件自动拆分的过程。原本单一的日志文件因大小超过限制而被数据库自动拆分为多个文件，每个历史文件大小固定为1M。此现象解释了为何近期的日志无法在原有位置查询到。

前几天查看这个文件的时候，文件大小差不多在6M左右，今年去看的时候，居然自己拆分成9个文件了，估计是太大了，数据库自动拆分了。

文件名的规则是：历史的文件名为log_1.xml,log_2.xml....，在用的文件名是log.xml。每个历史文件的大小为1M,难怪我在em里一直查不到半个月之间的日志了。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/67798/viewspace-1019353/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/67798/viewspace-1019353/

csdn20142014
关注
如何解决日志文件过大问题
weixin_34128237的博客
05-25 2464
2019独角兽企业重金招聘Python工程师标准>>> ...
oracle alert日志每天截断truncate_alert.sh
cizongzhic79075的博客
11-27 238
[oracle@shanxi ORCL]$ cat /home/oracle/admin/truncate_alert.sh#!/bin/bash# Filename: truncate_alert.sh# Date: 2012...
oracle alart.log日誌分割
congyun2180的博客
08-14 150
[oracle@eslhdb01 oracle]$ vi /data/autorun/chkalertlog.sh ######################################################...
oracle日志alter.log每天切割脚本
05-14
oracle 的alter日志切割脚本，有需要的可自行改造
Oraclｅalert日志切换
tomcatlhj的博客
09-21 1275
日积月累，oracle的alert_<sid>.log文件越来越庞大，查看很不方便 我们可以利用操作系统自带的logrotate功能，配置计划任务在零点进行日志切换，如下所示： echo " 0 0 * * * root /usr/sbin/logrotate -f /etc/logrotate.d/oracle_alert&
oracle alert文件路径,Oracle 11g Alert log 文件位置的问题
weixin_39606361的博客
04-05 514
Oracle至11g后的alert log有所变动，oracle数据库以XML与传统的文本两种格式提供Alert log日志了。新的日志位置由Automatic Diagnostic Repository(ADR)决定存放目录，可以通过信的初始化参数DIAGNOSTIC_DEST控制ADR base的位置。SQL> show parameter diagnostic_dest;NAME ...
Oracle 11g升级的日志管理：日志文件优化策略的深入剖析
文章首先介绍了Oracle 11g日志文件的类型和作用，随后分析了配置参数对日志管理的影响。在优化实践中，本文讨论了监控、调优以及容量规划的方法，并提供了备份与恢复的最佳实践。接着，文章详细介绍了从Oracle 11g到...
【系统日志自动化处理】：告别繁琐，这5个自动化工具提升日志处理效率
本文首先概述了系统日志自动化处理的基本概念和重要性，然后详细介绍了日志自动化工具的选择标准、理论基础、工作原理及其部署配置方法。通过实践应用章节，本文深入探讨了日志数据实时监控、分析、可视化以及安全...
Linux日志文件查看技巧揭秘：一文教你快速定位关键信息！
![Linux日志文件的查看与分析]...在这一章节中，我们会简要介绍Linux日志系统的工作原理及其核心组件，为接下来的章节中详细探索日志文件
大型Arduino项目如何不乱？模块化编程与多文件拆分的工程级组织策略
模块化编程与多文件拆分的工程级组织策略](https://support.tmatesoft.com/uploads/default/original/1X/0e1e75346a40b9f94e57ec1c670fd58ddccddb25.png) # 1. 大型Arduino项目中的代码混乱根源分析 在中小型...
alert日志按天切割脚本 alertlog_byday.sh
一醉轻王侯的技术博客
03-29 1022
alert告警日志管理： 路径 /u01/app/oracle/diag/rdbms/orcl/orcl/trace/   将alert log 按天存放，每天一个alert log 文件 [oracle@ijx ~]$ cat alertlog_byday.sh ############################# # alertlog_bydat.sh         #
Oracle按天切割alert Log日志
hbhe0316的专栏
10-18 441
1.编写切割脚本 https://www.cndba.cn/hbhe0316/article/4943 https://www.cndba.cn/hbhe0316/article/4943 https://www.cndba.cn/hbhe0316/article/4943 https://www.cndba.cn/hbhe0316/article/4943ht...
ORACLE清理、截断监听日志文件（listener.log）
weixin_33957648的博客
01-16 595
       在ORACLE数据库中，如果不对监听日志文件（listener.log）进行截断,那么监听日志文件（listener.log）会变得越来越大，想必不少人听说过关于“LISTENER.LOG日志大小不能超过2GB，超过会导致LISTENER监听器无法处理新的连接”，当然这个不是真理，不会绝对出现，只是发生在老旧的32bit Linux或Unix系统下面，真实的原因是一些32bit O...
在线重做日志组的切换
yinzhipeng123的博客
12-05 1315
日志组的切换： 1.自动切换：当日志组被写满之后，自动发生切换行为； 2.手动切换：alter system switch logfile; 改变日志组的状态？ SYS@orcl11g> alter system flush buffer_cache; --手动发生检查点，将当前的脏块全部写入数据文件（active-->inactive)                     
alert日志文件过大的处理
在路上
08-28 5340
1.清空 cat /dev/null > alert_sid.log 2.截断 tail -n 1000 alert_sid.log > alert_sid.log 3.使用echo echo "" > alert_sid.log
对Docker部署的MySQL中的数据进行备份恢复
2509_94228395的博客
11-25 299
使用Docker部署的MySQL进行备份/恢复与传统方式类似，但需要考虑Docker容器的特殊性。以下是详细的步骤，帮助你在Docker环境中进行MySQL的全量备份。
面试必问——Redis 主从同步
最新发布
2301_79966297的博客
11-26 212
偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。salve完成同步时也会记录当前同步的offset。如果salve的offset小于master的offset，说明salve的数据落后于master，需要更新。：简称replid,是数据集的标记，id一致则说明是同一个数据集。每个master都有唯一的replid,salve则会继承master节点的replid。：单点的Redis的并发能力是有限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。
PostgreSQL 17 发布了！非常稳定的版本
2509_94007342的博客
11-23 250
这些新特性和改进不仅提升了数据库的性能和功能，也增强了数据库的可用性和灵活性，使得 PostgreSQL 17 成为一个值得期待的版本。
如果我要把這兩個整合在一起呢 ## 目錄 1. 引言 2. 自動化部署與策略映射 3. YAML 結構整合與語意重構 4. CI/CD 流水線設計與實踐 5. Kubernetes 自動化與驗證架構 6. 前後端技術選型與程式碼組合方案 7. 結論 --- ## 1. 引言 在現代軟體交付與雲原生架構領域，整合多個上傳文件並生成一套最佳實作代碼配置方案已成為企業數位轉型的重要課題。隨著自動化部署、策略即程式碼及 CI/CD 流程的不斷演進，如何利用統一的 YAML 檔案結構來管理配置、編排各環節，並與 Kubernetes、Helm、OPA（Open Policy Agent）等技術緊密結合，成為系統穩定運行和安全合規的核心要求。本研究文章綜合來自 AI 自動部署、YAML 結構整合、DevSecOps CI 流水線以及 Kubernetes 自動化驗證等多份文件，探討如何從多源數據中抽取關鍵配置參數，並透過現代化的工具鏈構建出一個模組化、可追溯且高效的代碼配置方案。本文還將討論如何在後端採用 Golang 實現高性能服務，前端利用 Angular 等框架構建管理界面，以滿足前後端分離架構下的實際應用需求。 --- ## 2. 自動化部署與策略映射 ### 2.1 自動化部署的重要性 在自動化部署專案中，資料來源的多元以及文件內容結構整合是成功落地的第一步。透過對 DOCX、Markdown 以及其他文本格式的統一轉換與解析，不僅能夠實現源文件標準化，更能夠使後續的自動化流程免於因格式錯誤而發生部署失敗。在 ai-deployment-dev 文件中提到，正確的資料整合對於避免決策誤差與快速回滾流程具有決定性意義。 ### 2.2 策略映射與多層 Gate 機制 在 Kubernetes 自動化部署方案中，利用多層 Gate（閘門）來控制 CI/CD 流程是一項最佳實踐。文件中提出，Gate 機制不僅能夠分層次審核每一個部署任務，也有助於確保整個流水線的安全性與透明度。具體而言，在部署發生異常或策略違規時，自動化機制將觸發回滾操作，並記錄詳細的審計日誌。 ### 2.3 自動化工具鏈的技術支持 在自動化部署中，YAML 檔案作為配置描述語言的應用已經十分成熟。工具如 yq 被廣泛用於處理 YAML/JSON 文件的互轉、合併與拆分，這使得複雜的配置文件能夠保持結構和語意的一致性。此外，使用 Helm、Kustomize 等聲明式資源定義工具對於處理環境變量及資源回滾機制提供了良好的支持，這些工具通常以 Golang 編寫，進一步體現了 Go 語言在自動化工具鏈中的關鍵地位。 ### 2.4 可視化流程圖示 下麵是一個描述自動化部署與策略映射流程的 Mermaid 流程圖： ```mermaid flowchart TD A["開始：源文件整合"] --> B["標準化文件格式"] B --> C["解析並抽取 YAML 結構"] C --> D["自動化策略映射模組"] D --> E["設定多層 Gate 權限"] E --> F["執行 CI/CD 流水線"] F --> G["部署失敗觸發回滾"] G --> H["生成審計日誌與 SBOM"] H --> END["流程結束"] ``` **圖 1：自動化部署與策略映射流程** 該流程圖展示了從源文件整合、格式標準化、YAML 結構解析，到自動化策略映射、Gate 配置與最終 CI/CD 流水線執行的完整過程，由失敗回滾、審計日誌生成組成閉環控制系統。 --- ## 3. YAML 結構整合與語意重構 ### 3.1 YAML 變革與文件整合的必要性 隨著資訊系統的日益龐大，傳統的配置管理方法已難以滿足現代化開發需求。YAML 作為一種簡潔、易讀的數據描述格式，不僅能夠以縮進的方式自然地表示層級結構，還能在合併多個來源文件時保持語意與結構一致性。在 yaml-integration-stg 文件中，針對巨型 YAML 文件進行語意重構和結構整合的步驟被詳細論述，涵蓋文件解析、內容提取、模組融合以及敏感信息管理等方面。 ### 3.2 語意重構的具體步驟 重構巨型 YAML 文件時，需要遵循以下主要步驟： 1. **文件解析與結構抽取** 使用 Python-docx 及相關自動化工具批量提取文件中的標題、段落以及表格內容，然後依據預定的命名規範進行分類與分段。 2. **合併與分割操作** 異質資料的合併必須根據語意進行深度合併或陣列合併，並在合併後保留原始文件的追溯路徑與 metadata 注釋，方便日後追查。 3. **結構驗證與格式修正** 利用 yamllint、yamlfmt 等工具對最終生成的 YAML 文件做語法與格式驗證，確保所有資料均符合 UTF-8 編碼與國際化配置要求。 ### 3.3 表格展示：YAML 文件重構關鍵步驟 下表展示了 YAML 文件重構的主要步驟及其對應工具和技巧： | 步驟 | 描述 | 使用工具/技術 | |--------------------|--------------------------------------------------------------|------------------------------------------| | 文件解析 | 提取段落、標題和表格內容，進行初步分類 | Python-docx、pandoc | | 合併與分割 | 根據語意進行深度合併或陣列合併，保留來源 metadata | yq、tableconvert | | 結構驗證與格式修正 | 檢查 YAML 語法、縮排、命名規範及重複鍵 | yamllint、yamlfmt、PyYAML | | 敏感信息管理 | 將敏感密碼、token 替換為環境變數或通過秘密管理工具處理 | Helm Secret、K8s Secret、Vault Key 管理 | **表 1：YAML 文件重構關鍵步驟與使用工具** 此表清晰列出了實現 YAML 文件語意重構的流程及關鍵技術，從初步解析、合併操作到格式驗證與敏感信息管理，這是現代資訊系統整合與 DevOps 基礎建設中的關鍵步驟。 ### 3.4 自動化驗證工具的重要性 自動化工具的應用不僅減少人工配置錯誤，還能通過持續驗證保證配置文件的一致性與安全性。例如，在合併操作後保留原文件 metadata 注釋，有助於未來調試和版本控制。這種從源頭到最終驗證的自動化流程，保證了 YAML 文件在多環境下的一致性和可靠性。 --- ## 4. CI/CD 流水線設計與實踐 ### 4.1 流水線與 DevSecOps 的理念 隨著軟體供應鏈安全問題日益突出，CI/CD 流水線不僅需要實現自動化構建與部署，更要融合安全測試、政策閘道（Policy Gate）以及審計日誌記錄。DevSecOps 強調[安全左移]，將安全測試從開發階段延伸到整個流水線中，降低安全風險。例如，在 ci-pipeline-dev 文件中提到，每個 stage 結束後必須自動輸出審計日誌，並在失敗時觸發相應的錯誤處理機制。 ### 4.2 YAML 流水線配置與最佳實踐 CI/CD 流水線的 YAML 配置中，關鍵欄位包括 metadata、trigger（觸發規則）、stages（階段）、artifacts（產物）、fail_action（失敗處理）與 audit_log（審計日誌）。以下是一段示範 YAML 配置片段，展現了基本的流水線設計原則： ```yaml default: image: python:3.11 before_script: - pip install --upgrade pip setuptools wheel after_script: - echo "CI pipeline completed for ${CI_PROJECT_NAME} at $(date)" retry: 2 interruptible: true workflow: rules: - if: '$POLICY_GATE_PASSED == "true"' when: always - when: never stages: - build - unit_test - integration_test - security_scan - coverage - evidence - audit ``` **圖 2：CI/CD 流水線 YAML 配置示例** 該配置定義了流水線的基本環境、觸發規則以及多個構建與測試階段，展示了如何利用 YAML 文件實現分層管理和安全驗證。 ### 4.3 流程中 Artifact 管理與 SBOM 產出 Artifacts 是軟體供應鏈信任的基本單位。CI 流程中需妥善保存建置產物、測試報告與 SBOM 文件，以便後續進行 Provenance、簽章與不可變性校驗。例如，在 unit_test 和 integration_test 階段，透過 junit 報告與測試覆蓋率數據，流水線能自動生成安全、準確的測試報告，並透過 artifact 保存來形成完整的證據鏈。 ### 4.4 異常處理與審計日志 在失敗時，fail_action 區塊能夠明確規範流水線中斷或僅記錄警告，並結合通知與錯誤追蹤機制形成一個完整的異常處理閉環。同時，審計日誌（audit_log）記錄整個階段操作、資源校驗信息，這對於事後審計與安全合規檢查具有重要意義。 --- ## 5. Kubernetes 自動化與驗證架構 ### 5.1 Kubernetes 部署與自動回滾 Kubernetes 在現代自動化部署中扮演著重要角色，其聲明式資源定義、橫向擴展及分層管理模型，為大規模系統部署提供了靈活性與可擴展性。在 ai-deployment-dev 文件中明確指出，將 legacy YAML 內容映射至治理策略（如 Policy 控制），再由部署任務自動觸發 K8s rollback 指令，是保障系統穩定運行的關鍵。 ### 5.2 策略即程式碼與 Gate 映射 在 k8s-automation-prod 文件中，強調了策略即程式碼的理念，並通過多層 Gate 映射來實現從開發到生產環境的全流程自動化。這包括對各個 Gate 的定義、對應策略組合（如 attestation 與 provenance 策略）以及在部署過程中使用 hash lock 校驗的機制，從而形成一個完整的安全閉環。 例如，幾個 YAML 檔案分別定義了 Gate 映射（ops_gates.mapping.yaml）、作業職責與溯源驗證（ops_jobs__attestation-provenance.bundle.v1.yaml）以及 Hash Lock 模組（ops_jobs__canonical-hash-lock.bundle.v1.yaml），這些文件共同協作，保證了在 CI/CD 流程中所有變更均可追蹤、驗證與凍結。 ### 5.3 YAML 管理的安全與審計 利用 YAML 配置文件實現資源管理的優勢在於其可追溯性與透明性。通過對各個文件結構、版本控制與 metadata 注釋的自動化管理，不僅可以在出現部署異常時迅速回滾，還能輕鬆追溯到每個變更的來源。因此，對於 Kubernetes 自動化部署而言，正確、嚴謹的 YAML 文件管理是提升整體系統安全性與穩定性的基本要求。 ### 5.4 圖表展示：Kubernetes 部署流程與自動回滾機制 下表概述了 Kubernetes 自動化部署中各核心組件與功能模塊的對應關係： | 組件/模塊 | 核心功能 | 關鍵點與驗證機制 | |-----------------------------|----------------------------------------------------------------|------------------------------------------| | Gate 映射 | 根據策略定義動態調度部署流程 | 多層 Gate 分段審核，觸發回滾指令 | | Attestation 與 Provenance | 生成並管理安全認證和 SBOM 文件 | 使用 hash lock、簽章與審計日誌 | | Hash Lock | 自動計算與校驗產物完整性 | SHA256 校驗，防止中途篡改 | | Kubernetes 資源配置 | 聲明式管理應用資源、支持橫向擴展與高效回滾 | Helm/Kustomize 模板化管理，支持多環境配置 | **表 2：Kubernetes 自動化部署關鍵模塊對照表** 此表說明了各模塊間如何相互配合，構建出一個高效且安全的部署流程，並在發現異常時及時啟動回滾程序，以確保整體系統的穩定性. --- ## 6. 前後端技術選型與程式碼組合方案 ### 6.1 後端技術選型：為什麼選擇 Golang 在自動化部署與 DevOps 工具鏈的建設中，後端系統需要具備高效能、可移植以及與 Kubernetes 生態系統無縫整合的能力。從上傳的文件內容來看，許多工具如 yq、OPA、Kyverno 等均採用 Golang 寫成，這為後端系統的技術選型提供了充分理由。 **Golang 的優勢包括：** - 高性能：能夠迅速處理大量並發任務，適合用於微服務和命令行工具。 - 良好的支持：Go 語言在 Kubernetes 以及雲原生工具中的廣泛應用，使其更容易與現有工具鏈集成。 - 靜態編譯：生成的二進位文件對於分發與部署具有極大優勢。 因此，在建立自動化部署服務、策略執行模塊、日誌記錄與審計系統等後端核心服務時，選擇 Golang 作為主要語言是較為理想的方案。 ### 6.2 前端技術選型：Angular 與其他選項 文件中雖未直接推薦前端框架，但在建立管理界面以展示 CI/CD 流水線狀態、安全報告與部署統計上，前端技術的選型同樣關鍵。在現代前端領域，Angular、React 以及 Vue 都是成熟的方案，其中： - **Angular**：提供完善的組件化架構和雙向數據綁定，適合構建複雜的管理後台。 - **React/Vue**：具有輕量化以及快速開發的特點，也常被用於實現靈活的前端界面。 針對本系統的需求，後端 API 由 Golang 提供服務，前端則負責展示數據及交互操作。基於項目規模與團隊熟悉度，Angular 是一個較為成熟且全面的選擇，但具體選擇可根據實際需求靈活調整。 ### 6.3 前後端分離架構與實施方案 採用前後端分離架構可以使整個系統具有更高的擴展性與維護性。具體方案包括： 1. **後端服務**： - 使用 Golang 編寫微服務，負責處理自動化部署、策略驗證、資源管理、日誌記錄等核心業務邏輯； - 提供 RESTful API 或 gRPC 接口，以便前端進行數據交互。 2. **前端管理平台**： - 使用 Angular 搭建統一的管理界面，展示 CI/CD 流水線狀態、部署進程、審計日誌與安全報告； - 通過 API 調用後端服務，實現實時數據刷新與可視化操作。 3. **整合與自動化部署**： - 利用 GitHub、GitLab 等版本管理工具進行代碼托管與版本控制； - 配合 Kubernetes、Helm 等工具實現自動化部署、版本回滾與多環境配置管理。 ### 6.4 可視化圖示：前後端分離架構流程圖 下圖展示了後端採用 Golang 與前端使用 Angular 的前後端分離架構流程： ```mermaid flowchart TD A["客戶端（Angular 前端）"] -->|API 調用| B["後端服務（Golang）"] B --> C["自動化部署核心模塊"] C --> D["Kubernetes 控制器"] D --> E["Helm/Kustomize 管理"] E --> F["部署與回滾管理"] B --> G["日誌與審計服務"] G --> H["審計日誌數據庫"] C --> I["策略驗證與 Gate 映射"] I --> J["安全審計模組"] ``` **圖 3：基於 Golang 與 Angular 的前後端分離架構圖** 該流程圖展示了前端通過 API 與後端服務進行互動，後端再通過自動化部署模組與 Kubernetes 生態系統實現數據處理與審計記錄，從而構成一個閉環的 DevSecOps 解決方案。 --- ## 7. 結論 本文綜合多份文件內容，深入探討了從文件整合、 YAML 重構，到 CI/CD 流水線設計與 Kubernetes 自動化部署的完整解決方案。主要結論如下： - **自動化部署與策略映射**：透過統一文件解析、標準化 YAML 結構以及多層 Gate 機制，可實現從源文件到最終部署的全流程自動化，並確保部署異常時及時回滾與審計。 - **YAML 結構整合與語意重構**：使用工具（如 yq、yamllint、yamlfmt 等）進行文件合併、語法驗證與敏感信息管理，是實現巨型 YAML 文件一致性和可維護性的關鍵。 - **CI/CD 流水線設計與實踐**：流暢的 CI/CD YAML 配置設計不但涵蓋元數據、觸發規則、階段管理與 Artifact 產出，同時引入 fail_action 與 audit_log 記錄，構成了一個抗失敗、可追溯的流水線系統。 - **Kubernetes 自動化與驗證架構**：通過合理劃分 Gate 映射、策略即程式碼與 Hash Lock 校驗機制，實現了 Kubernetes 部署中從策略驗證到資源管理的全自動化流程，確保系統穩定運行與安全合規。 - **前後端技術選型與程式碼組合方案**：基於文件中的工具鏈與自動化部署實踐，建議後端使用 Golang 以充分發揮其高性能和與 Kubernetes 生態系統的良好整合，而前端則可根據團隊熟悉度選擇 Angular、React 或 Vue，實現前後端分離架構並透過 API 進行數據交互。 總結來看，整合上傳文件生成最佳實作代碼配置的核心在於以 YAML 為依據的統一配置管理、全流程自動化部署與安全審計，並依靠現代 DevSecOps 工具鏈實現各階段功能模組的動態調度。這不僅提高工作效率，還能在系統異常時迅速進行回滾與資源追溯，從而保障企業應用的高效性和安全性。 **主要發現與建議：** - 使用自動化工具（如 yq、yamllint）統一多源配置，確保資料格式標準化； - 透過多層 Gate 映射和策略即程式碼機制，建立完善的安全審計與自動回滾流程； - 後端建議採用 Golang 以構建高效、穩定的自動化服務； - 前端可考慮 使用 Angular 等成熟框架，實現用戶友好的管理界面； - 整合 CI/CD、Kubernetes 等工具鏈，形成從開發到部署全流程自動化與安全審計的閉環解決方案。 該方案在當前快速變化的雲原生與 DevOps 生態中具備顯著優勢，能夠有效幫助企業推動數位轉型，並在自動化部署與安全管理上建立起堅實的技術基礎。 --- **參考文獻摘要：** 本文引用了來自 ai-deployment-dev、yaml-integration-stg、ci-pipeline-dev 與 k8s-automation-prod 等文件中的關鍵技術與方法，確保每一技術環節都有充足的依據。通過系統性地整合多源配置文件與現代 DevSecOps 工具鏈，提出了一個兼具自動化、模組化以及高效安全性的代碼配置方案，為業界提供一個可參考的最佳實踐模型。
10-30
我们正在讨论如何将Artifact Contract驱动与GitHub Actions实现整合到更广泛的技术栈中，包括自动化部署、YAML结构整合、CI/CD流水线设计、Kubernetes自动化等。以下将分步骤详细阐述整合方案： ### 一、整体架构...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值